Omeka on Solaris 10

Hi All,

we are trying to set up Omeka 0.9.2 on a Solaris 10 machine.
Our configurations are as follows.

Apache - 2.2.8
PHP - 5.2.6
MySQL - 5.0.51b
ImageMagick - 6.3.8

1)
When we follow "add an item" to add a JPG or a TIFF after the final step an empty page is displayed with no html source code. But when we check the archive folder the image has been properly resized and square and thumbnails have been produced. So Imagemagick seems to be working fine. In the public site the submission is been shown with all the meta data but without the image.

When we follow "add an item" to add a PDF file system works perfectly and you can see the submission with the PDF file from the public site.

Can someone please direct us in the appropriate direction to solve this problem.

2)
Where does the admin\themes\default\items\form.php submits to?

Thanks in advance.

1) Try editing the config.ini file in the/application/config/ folder, and change debug.exceptions on line 24 to true instead of false. That should (hopefully) print out some helpful information -- try causing the same error again and let us know what it says.

2) The form submits to the ItemsController, located in /application/controllers/

Hi Dave,

We enabled the error log, but it doesn't report any errors. And just to make sure our ImageMagick is working fine, we installed Gallery2 on the same server and it works fine. So it can't be a problem with ImageMagick, unless Omeka needs a very specific version of ImageMagick.

Any thoughts?

Thanks.

You can try setting the display_errors flag in your .htaccess to 1 instead of 0. If you're getting a blank screen it may show you the error message instead. Let us know if that works.

Dhanu is a colleague of mine, so this issue has been resolved for us, but I hope this helps out anyone else having similar issues regarding the installation of Omeka on Solaris 10. Please note that these are solutions that worked for us; they may not provide a solution for your particular environment, but hopefully might point you in the right direction. Sorry it's lengthy, but I wanted to be thorough.

Error:

"ImageMagick is not properly configured. Please check your settings and then try again."

Possible solution:

Could be that the wrong location is set for your convert. When logged in as admin, go to the "Settings" tab, and make sure that the "Path to Convert" field has the entire path to a working copy of convert. The path MUST include the convert executable.

Right:

/usr/local/bin/convert

Wrong:

/usr/local/bin/

I know this has been brought up in a few other places in the forums, but it can't hurt to repeat it.

Error:

"Something went wrong with image creation. Please notify an administrator."

Possible Solution:

The first problem we ran into was ImageMagick itself. The version of ImageMagick that ships with Solaris was too old for Omeka. If you run:

/usr/sfw/bin/convert --version

Against the default ImageMagick that shipped with Solaris, we got:

Version: @(#)ImageMagick 5.4.7 07/01/02 Q:16 http://www.imagemagick.org
Copyright: Copyright (C) 2002 ImageMagick Studio LLC

The default version shipped with Solaris is REALLY old, so we pointed Omeka to the newer version we installed:

/usr/local/bin/convert --version

Which shows:

Version: ImageMagick 6.3.8 02/26/08 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC

Which seems to work.

Not sure what the minimum version requirement of ImageMagick is, but if you have your convert pointed to the right place, and it's giving this error, try upgrading to a new version.

Problem:

The dreaded "Blank Screen" after you attempt to upload an image

Possible solution:

This was the one that caused us grief. It turns out that when we compiled PHP from source we didn't include exif. It's important to remember to configure PHP with --enable-exif or Omeka will give you a blank screen when you attempt to upload images.

It doesn't trap an error (we had all error messaging turned on, at maximum verbosity, and still not a single error), so it can be really frustrating. I guess most people install PHP from packages, which come compiled with exif, so they don't encounter this.

If this could be added to the installation documents, I think it would help out those of us in a highly customized environment who do compile from source.

Problem:

"file: illegal option -- b" listed in error logs

Possible solution:

We installed the latest gnu version of file, and that fixed this issue. It appears that our version was either too old, or (more likely) Omeka expects the gnu version of file, but the version of file that ships with Solaris simply doesn't support the -b option. Omeka seems to work fine, even though it throws this error to the error log, so it may not be a big issue to you, and you may not even have noticed it. But, I like my error logs to be clean, so I'm including it.

Thanks for updating us on the situation. We previously posted a ticket about this bug (https://omeka.org/trac/ticket/390), and it has been fixed for the upcoming 0.10 beta release of Omeka.