ImageMagick is not properly configured

Hi! As I wrote in another post (http://omeka.org/forums/topic/zend-file-transfer-exception), I installed Omeka a few weeks ago but I've been having problems trying to upload new items.

After some days, I managed to solve the "Zend_File_Transfer_Exception" problem but now I get this error when I try to upload an item with an associated file
2013-05-06T11:50:41+02:00 WARN (4): Omeka_Storage_Adapter_Filesystem: Tried to delete missing file 'original/fbbf36a9f8b425a12808a911b2b83cc9.jpg'.
2013-05-06T11:50:41+02:00 ERR (3): exception 'Omeka_File_Derivative_Exception' with message 'ImageMagick is not properly configured: invalid directory given for the ImageMagick command!' in /usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Omeka/File/Derivative/Image/Creator.php:44
Stack trace:
#0/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Omeka/File/Derivative/Image/Creator.php(26): Omeka_File_Derivative_Image_Creator->setImageMagickDirPath('/usr/local/home...')
#1/usr/home/catalegmuseuarta.com/web/omeka/application/models/File.php(362): Omeka_File_Derivative_Image_Creator->__construct('/usr/local/home...')
#2/usr/home/catalegmuseuarta.com/web/omeka/application/models/Job/FileProcessUpload.php(22): File->createDerivatives()
#3/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Omeka/Job/Dispatcher/Adapter/Synchronous.php(25): Job_FileProcessUpload->perform()
#4/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Omeka/Job/Dispatcher/Default.php(136): Omeka_Job_Dispatcher_Adapter_Synchronous->send('{"className":"J...', Array)
#5/usr/home/catalegmuseuarta.com/web/omeka/application/models/File.php(209): Omeka_Job_Dispatcher_Default->send('Job_FileProcess...', Array)
#6 [internal function]: File->afterSave(Array)
#7/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Omeka/Record/AbstractRecord.php(277): call_user_func(Array, Array)
#8/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Omeka/Record/AbstractRecord.php(550): Omeka_Record_AbstractRecord->runCallbacks('afterSave', Array)
#9/usr/home/catalegmuseuarta.com/web/omeka/application/models/Item.php(322): Omeka_Record_AbstractRecord->save()
#10/usr/home/catalegmuseuarta.com/web/omeka/application/models/Item.php(235): Item->saveFiles()
#11 [internal function]: Item->afterSave(Array)
#12/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Omeka/Record/AbstractRecord.php(277): call_user_func(Array, Array)
#13/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Omeka/Record/AbstractRecord.php(550): Omeka_Record_AbstractRecord->runCallbacks('afterSave', Array)
#14 /usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Omeka/Controller/AbstractActionController.php(144): Omeka_Record_AbstractRecord->save(false)
#15/usr/home/catalegmuseuarta.com/web/omeka/application/controllers/ItemsController.php(149): Omeka_Controller_AbstractActionController->addAction()
#16/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Zend/Controller/Action.php(516): ItemsController->addAction()
#17/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('addAction')
#18/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#19 /usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()
#20/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#21/usr/home/catalegmuseuarta.com/web/omeka/application/libraries/Omeka/Application.php(79): Zend_Application->run()
#22/usr/home/catalegmuseuarta.com/web/omeka/admin/index.php(28): Omeka_Application->run()
#23 {main}

Besides, Omeka doesn't recognize the Imagemagick Path at the Settings panel test. It should be /usr/local/home/srvcat/local/binaris/catalegmuseuarta.com/ but it doesn't work. My hosting provider assures me that Imagemagick is correctly installed on the server and I've executed some tests that seem to prove that, but Omeka just doesn't recognize the path.

Any ideas on how to solve this problem? Thank you very much

The convert binary is actually at /usr/local/home/srvcat/local/binaris/catalegmuseuarta.com/convert? That's not quite a standard place for it to be located.

At any rate, Omeka only complains about an "invalid" directory if it can't even read that the path given is a directory at all. This can happen if your host has enabled open_basedir restrictions for PHP and not included the path where ImageMagick lives. If that's the case, you'd need to get that setting relaxed or disabled.

Hi, thanks for your response. As strange as it may seem the convert binary is, actually, at the path you've mentioned. I've checked the open_basedir directive and that path isn't included, but my hosting provider tells me that this can't be the problem as the path is included at the safe_mode_exec_dir.

Actually, I've tried a php script with the following code
<?php
exec("/usr/local/home/srvcat/local/binaris/catalegmuseuarta.com/convert torre.jpg omeka/torre.png");
?>
and it works fine. If this were the problem I understand my code wouldn't work either. Would it?

I'm not sure what to try next. Any ideas?
Thanks!

We separately use a realpath and is_dir check in PHP to make sure the path you've given us is actually a directory. That requires an allowance by the open_basedir setting, even when actually running the exec wouldn't.

Hi, I've been in contact with my hosting provider and they have told me they can't include the path in the open_basedir directive as it could cause some vulnerabilities in the server.

Based on your previous response we've tried to avoid the double check you've mentioned commenting the following code lines in application\libraries\Omeka\File\Derivative\Image\Creator.php if (!realpath($dirToIm) || !is_dir($dirToIm)) {return false;}
Doing this, Omeka recognizes our path at the Settings Panel Test but it still doesn't create the thumbnails when uploading a new file. Do we've to change anything else?

Or is it any other way to use Imagemagick without including the path in the open_basedir directive?

Thanks in advance!

Hi, I'm sorry to insist but I haven't any solution to my problem yet.

If my hosting provider doesn't want to change the open_basedir directive is there any other way to use Imagemagick?

Thanks!

The hosting provider technicians have contacted me to tell me that Omeka seems to need that the Imagemagick path is /usr/bin/binario. If that's the case, I would like to know how to modify this path

Thanks!

Under Settings, there's a place to change the path to ImageMagick

I've been following the ImageMagik directory issues for a while now because I have the same problem with my installation of Omeka. My webhost (Hostpapa)emailed me: "be assured that imagemagick is already installed on the server on which your website is hosted. Also the path to the directory that contains the function 'convert' is /usr/bin/convert" I have tried many variations on the Directory Path setting but any attempt ends in an error, for instance:
'#0 /home/charl734/public_html/researchcentre/application/libraries/Omeka/File/Derivative/Image/Creator.php(26): Omeka_File_Derivative_Image_Creator->setImageMagickDirPath('/usr/bin/binari...')
#1 /home/charl734/public_html/researchcentre/application/models/File.php(362): Omeka_File_Derivative_Image_Creator->__construct('/usr/bin/binari...')
#2 /home/charl734/public_html/researchcentre/application/models/Job/FileProcessUpload.php(22): File->createDerivatives()
#3 /home/charl734/public_html/researchcentre/application/libraries/Omeka/Job/Dispatcher/Adapter/Synchronous.php(25): Job_FileProcessUpload->perform()
#4 /home/charl734/public_html/researchcentre/application/libraries/Omeka/Job/Dispatcher/Default.php(136): Omeka_Job_Dispatcher_Adapter_Synchronous->send('{"className":"J...', Array)
#5 /home/charl734/public_html/researchcentre/application/models/File.php(209): Omeka_Job_Dispatcher_Default->send('Job_FileProcess...', Array)
#6 [internal function]: File->afterSave(Array)
#7 /home/charl734/public_html/researchcentre/application/libraries/Omeka/Record/AbstractRecord.php(277): call_user_func(Array, Array)
#8 /home/charl734/public_html/researchcentre/application/libraries/Omeka/Record/AbstractRecord.php(550): Omeka_Record_AbstractRecord->runCallbacks('afterSave', Array)
#9 /home/charl734/public_html/researchcentre/application/models/Item.php(322): Omeka_Record_AbstractRecord->save()
#10 /home/charl734/public_html/researchcentre/application/models/Item.php(235): Item->saveFiles()
#11 [internal function]: Item->afterSave(Array)
#12 /home/charl734/public_html/researchcentre/application/libraries/Omeka/Record/AbstractRecord.php(277): call_user_func(Array, Array)
#13 /home/charl734/public_html/researchcentre/application/libraries/Omeka/Record/AbstractRecord.php(550): Omeka_Record_AbstractRecord->runCallbacks('afterSave', Array)
#14 /home/charl734/public_html/researchcentre/application/libraries/Omeka/Controller/AbstractActionController.php(144): Omeka_Record_AbstractRecord->save(false)
#15 /home/charl734/public_html/researchcentre/application/controllers/ItemsController.php(149): Omeka_Controller_AbstractActionController->addAction()
#16 /home/charl734/public_html/researchcentre/application/libraries/Zend/Controller/Action.php(516): ItemsController->addAction()
#17 /home/charl734/public_html/researchcentre/application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch('addAction')
#18 /home/charl734/public_html/researchcentre/application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
#19 /home/charl734/public_html/researchcentre/application/libraries/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()
#20 /home/charl734/public_html/researchcentre/application/libraries/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#21 /home/charl734/public_html/researchcentre/application/libraries/Omeka/Application.php(79): Zend_Application->run()
#22 /home/charl734/public_html/researchcentre/admin/index.php(28): Omeka_Application->run()
#23 {main}'
Is there any approach I can take with my webhost?

thanks.

Hello, thanks for your response patrickmj but what I would like to know is if Omeka looks for the Imagemagick bins in a default path and how to change that default path INSIDE the code.

I'll try to explain why: The hosting provider's technicians told me that when Imagemagick is installed it activates fastcgi that adds Imagemagick's bins path into the open_basedir to allow its use.

They think Omeka looks for the Imagemagick's bin into an especific path and they want to know where and how to change that path. I've told them that this can be done at the Settings page (as patrickmj told me) but they still want to know how to change it inside the code because they think that there could be some kind of difference between changing the path in the code or at the Settings page

As you can see, we're totally lost here. In a previous post I asked if there was any other way to create the thumbnails or to use Imagemagick without including the path in the Open_basedir directive. It may be an easier way to solve that problem that is driving me crazy.

Thanks!

There's no default in the code. When you set a path on the Settings page, that's what gets used. We initially try to "guess" and set that path, but there's no hardcoded default.

Since this issue is a show-stopper for some of us using hosting services, I don't suppose there's anything to gain by trying an old install of Omeka, say 1.5.3?

thanks

ozmac46: In your previous post, you left out the actual error message. I take it that it's "ImageMagick is not properly configured"?

MASerra: It looks like you removed the "double-check" from the part of that class that does the "test" only. A similar check happens in the setImageMagickDirPath method, and that's the one that's important for when Omeka's actually using ImageMagick, not just testing it.

thanks John, I solved my problem by changing host providers.

Hi John, thanks for answering. We tried to solve the problem commenting the double-check in the method you mentioned but it doesn't work. Right now, we've the code like this
public function setImageMagickDirPath($imDirPath)
{
// Assert that this is both a valid path and a directory (cannot be a
// script).
//if (($imDirPathClean = realpath($imDirPath)) && is_dir($imDirPath)) {
$imDirPathClean = rtrim($imDirPathClean, DIRECTORY_SEPARATOR);
$this->_convertPath = '/usr/local/home/srvcat/local/binaris/catalegmuseuarta.com/convert';
$this->_identifyPath = '/usr/local/home/srvcat/local/binaris/catalegmuseuarta.com/identify';
/* } else {
throw new Omeka_File_Derivative_Exception('ImageMagick is not properly configured: invalid directory given for the ImageMagick command!');
}*/
}
Could you tell us what should we do to make it work?

Besides, in a previous post I mentioned we executed some PHP scripts to test if Imagemagick was properly installed and they worked fine. From your answer I understand that the difference is that Omeka uses that double-check and our scripts don't, is it right? Just in case I didn't get it right, this is one of the script's code:

<?php
exec("/usr/local/home/srvcat/local/binaris/catalegmuseuarta.com/convert torre.jpg omeka/torre.png");
echo "Done";
?>

Thank you, and sorry for the inconvenience!

The other wrinkle here is that Omeka uses proc_open when it runs ImageMagick, not exec. It's possible your server has disabled proc_open, so that's something to account for in your testing.

Also, when you make that change, what kind of error or behavior do you get? You commented out the parts that would have caused the errors you've been reporting here, so something would be different.

Hi, yesterday we ran some tests based on your last response and this is our current status:

Our hosting providers told us that proc_open only executes programs that are located in the safe_mode_exec_dir directive and Imagemagick's path is located there

To prove it, we executed a Test with proc_open instead of exec and it worked fine, so this doesn't seem to be the problem.

With the Creator.php code as I put it in my last post, right now we can upload items with attached images but Omeka doesn't create thumbnails of those images.

To try to find out what could be the problem, our technicians added some echo to the executeCommand function to see which path was using. This is the executeCommand code as we've it now:

public static function executeCommand($cmd, &$status, &$output, &$errors)
{
// Using proc_open() instead of exec() solves a problem where exec('convert')
// fails with a "Permission Denied" error because the current working
// directory cannot be set properly via exec(). Note that exec() works
// fine when executing in the web environment but fails in CLI.
$descriptorSpec = array(
0 => array("pipe", "r"), //STDIN
1 => array("pipe", "w"), //STDOUT
2 => array("pipe", "w"), //STDERR
);
if ($proc = proc_open($cmd, $descriptorSpec, $pipes, getcwd())) {
$output = stream_get_contents($pipes[1]);
$errors = stream_get_contents($pipes[2]);
<srong> echo "<p> $cmd </p>"; </srong>
<srong> echo "<p> $descriptorSpec </p>"; </srong>
<srong> echo "<p> $pipes </p>"; </srong>
foreach ($pipes as $pipe) {
fclose($pipe);
}
$status = proc_close($proc);
} else {
throw new Omeka_File_Derivative_Exception("Failed to execute command: $cmd.");
}
}

When we execute the Imagemagick's Path on the Settings screen the code returns us this:
/usr/local/home/srvcat/local/binaris/catalegmuseuarta.com/convert
Array
Array
/usr/local/home/srvcat/local/binaris/catalegmuseuarta.com/identify
Array
Array


This result seems a little bit odd to us as the second and third echoes returns Array. Could this be a problem? Or is it normal?

We think that we've made some progress and that the solution isn't far, or at least, not as far as it was last week. With a little bit of help, we should solve it soon and start using Omeka at last.

I don't know if this problem is specifically ours or if you can get something out of it. Anyway, thanks a lot for your help! :-)

Hi! Sorry if I'm being annoying but I really need to solve this problem to move on and start with my project. We're stuck at the same point we were last week and we need to know what to do next.

Thanks!

Those 2nd and 3rd echoes should always be Array: those variables are arrays.

So, if I understand you correctly, you've taken out those path checks from before and now you're no longer getting an error, but you still aren't actually getting any thumbnails.

You've done most of your testing with convert, but identify is equally important for Omeka, it uses identify to decide if it can make thumbnails. Does manually running identify, or running it through a PHP script, on a test JPEG or other image file, work correctly? (It should just print some information about the image.)

Hi John, I've tested the identify function and it also works fine in a PHP script.

As you say, with the code as I shown we don't get any error but the thumbnails aren't created. Should they be created or do we have to change anything else?

And one last question. Some weeks ago I wrote that my hoster provider's told me that when Imagemagick is installed, fastcgi automatically adds Imagemagick's bins path into the open_basedir to allow its use and, therefore, it should work. Does it have any sense to you? Or they should add the path manually at php.ini?

Thanks!

There's nothing particularly unreasonable about that. You can use phpinfo() or ini_get('open_basedir') to see what the setting actually is.

I'm not totally sure where to point you at this point. What does the identify output look like when you point it at a .jpg file?

I've used phpinfo() and the path doesn't appear in the open_basedir, I understand that it should appear there even if it was automatically added, shouldn't it?

Refering to identify, I'm not sure what are you asking for. This is the test code we've been using

<?php
$commandIM = "identify torre.jpg";
exec ($commandIM, $output, $result);
print_r ($output);
?>


And this, the output we get:

Array ( [0] => torre.jpg JPEG 480x640 480x640+0+0 8-bit DirectClass 32.8KB 0.000u 0:00.000 )


Is that what you wanted to know?

Any idea on why the thumbnail creation isn't working? Should we change something else in the code?

Thanks!

Was there any resolution to these problems? I am currently trying to get Omeka to 'see' a fully-functioning ImageMagick within the chroot environment in which the httpd is running, but while the binaries all work fine, no combination of statements in the path setting leads to success.

To answer my own post, I have now got ImageMagick playing nicely with Omeka inside a chroot, and indeed the problem was not Omeka's, but my implementation of the chrooted ImageMagick, which appeared to function correctly to a shell user, but which was not actually available to the system user.
This means I now have a basic install, with functioning thumbnail creation, running on OpenBSD with its customised Apache version inside a chroot jail. I've not installed any plugins as yet, so the solution may prove less than perfect. If anyone would like to know the pitfalls I fell into, reply here and I'll do my best.