Omeka Import API


I am having problems with Import API. It is stating:

The background.php.path in config.ini is not valid. The correct path must be set for the import to work

I have checked and changed the config.ini file to both the following

/usr/lib/php.ini AND usr/local/lib/php.ini

I have shelled to the server and found it as usr/lib/php.ini

The same error message comes up in either case. Is there something I am missing here.

It won’t be something ending with .ini. Generally it’ll just be something/something/php. My guess is that usr/lib/php might work. If you shell in and do which php, that might also point you to the right location.

I found it eventually with some prompting from my host co. It was usr/bin/php
Again thanks to the information. The process is now underway.

OK so I have waited 2 hours and it is still saying:

Status: starting Click here to update status.

I do and it stays the same. it’s not transferring. Any ideas?

I have API enabled on the Original site.

Something must be going wrong very early in the process, and isn’t being caught or detected. Could you try turning on the error logging as described here, try the import again, and look to see what appears in the log file?

If you give the url of the site you are trying to import from, I can also look to see if there’s something surprising there.

Thanks for the reply.

The error I get is:

Warning: escapeshellarg() has been disabled for security reasons in /home/harpmand/public_html/*********.com/omeka/application/libraries/Omeka/Job/Process/Dispatcher.php on line 49

Warning: escapeshellarg() has been disabled for security reasons in /home/harpmand/public_html/**********.com/omeka/application/libraries/Omeka/Job/Process/Dispatcher.php on line 50

********* is my domain edit for security reasons.

I presume it is to do with this:

    $command = escapeshellcmd($cliPath) . ' '
             . escapeshellarg(self::_getBootstrapFilePath())
             . " -p " . escapeshellarg($process->id);

I have asked the host if they disable this in php.ini and await their reply.

Here is the Origin site:

Yep, that definitely looks like the issue. Not 100% sure, but it might be fixed in newer versions of Omeka. So, what versions of Omeka, and the API Import plugin are you using?

My test at least pulled some data in, and eventually got to a status message of ‘Error’, but that’s at least some progress from ‘Starting’. I got to importing “Modern Reprint of an ancient photograph of Sedgewick’s American Jungle Wagon”, which sounds totally fascinating.

I’ll work on what might be the error on my import attempt, but that version data and info from the host will also be helpful.

Hi, thanks,yes that’s the stuff I’m transferring. Host has placed a nw php.ini in the root to my domain. I’ll look in there and see if I can unban.

Took the escapeshellarg out of the disable list and the import started! Watch this space for an update and thanks again for your input.

Everything has transferred, but the thumbnails are blank/default.

If I click on one it shows the path to a third party site. Amazon!


I guess I have to change these and save them all over again on my server, unless you know any other way?

The image files have imported anyway, sorry forgot to say.

Traced te code as follows to the ExternalImageMagick.php which states

        throw new Omeka_File_Derivative_Exception('ImageMagick is not properly configured: invalid directory given for the ImageMagick command!');

OK so I haven’t entered it correctly. However, the host says this:

‘The path is /usr/bin/convert, which does require the
leading ‘/’ for the path to be syntactically correct in most use cases’

I try usr/bin and it seems to work, but I get an error:

Failed to execute command: /usr/bin/convert -version

Line 212:
Failed to execute command: /usr/bin/convert -version

I tried adding an image again from scratch and it errored here:

Line 212

Failed to execute command: /usr/bin/convert -background white +repage -flatten -thumbnail

That’s where Omeka usually expects to find imagemagick, so it’s a little curious. If you go to Omeka’s general settings, there’s a place to test it and change it if needed.

A couple possibilities to check if that still doesn’t get things going:

It might be that convert is also blocked in the php.ini file, so you could look there to see if it is banned and unban it.

Try one of the other derivative strategies in config.ini.

I’m not sure how the import plugin will handle these kinds of file problems when you re-run it. Generally it tries to update data and files, but in this case it might see the file as already existing so no update needed. You should be able to undo the import completely and start again if that’s the case.

Hi, I tried the different variants on the settings page. No luck.

convert is not blocked in the php.ini file

Derivatives is way beyond my comprehension.

What I see in config.ini is:

; Derivative Images ;

; fileDerivatives.strategy
; Controls what method Omeka uses to create derivative images.
; default: Omeka_File_Derivative_Strategy_ExternalImageMagick
; The built-in strategies are ExternalImageMagick (the old default), Imagick
; (requires PECL ext/imagick), and GD (generally installed by default with PHP,
; but handles fewer formats). Others can be added by plugins.
;fileDerivatives.strategy = “Omeka_File_Derivative_Strategy_ExternalImageMagick”

; fileDerivatives.strategyOptions
; Specific settings for the configured derivative strategy.
; Subkeys to this entry specify each option.
; = “0”
; fileDerivatives.strategyOptions.gravity = “center”
; fileDerivatives.strategyOptions.autoOrient = false

; fileDerivatives.typeWhitelist[]
; If set, Omeka will only attempt to create derivatives for files with the
; given MIME types.
; This entry can be specified multiple times, once for each type in the list.
;fileDerivatives.typeWhitelist[] = “image/jpeg”

; fileDerivatives.typeBlacklist[]
; If set, Omeka will not attempt to create derivatives for files with the
; given MIME types.
; Both this blacklist and the whitelist can be set at the same time, but the
; whitelist will control.
; This entry can be specified multiple times, once for each type in the list.
;fileDerivatives.typeBlacklist[] = “image/jpeg”

Hi, host co. says proc_open(0) is disabled and errors are being seen. Don’t look at it yet I’ll enable that one first.

It’s just a game of changing the name of the strategy on the line below and deleting the semi-colon.

The options for the strategy are Omeka_File_Derivative_Strategy_IMagick and Omeka_File_Derivative_Strategy_GD.

Those depend on what’s on the server, so there’s no guarantee, but it’s an option to try.

OK I enabled close AND open in the php.ini file and the imagemagick settings path worked!!! Tried editing the first item record and it saves the original size image ok. It does not produce a thumbnail though.

Also are you saying to run the whole Import again?