Have tried all possibilities our service provider gave
/usr/local/php74/bin/php74
/usr/local/php80/bin/php80
/usr/local/php81/bin/php81
And none of them works.
So, what’s next?
P.S. And now I have copy-pasted those paths, not to create additional mess by my own typos 
This kind of path: /usr/local/php74/bin/php is more common than the ones you listed (note that the “74” part is not repeated at the end), and that might be worth a try.
Tried now ton of different versions, no luck. Kind of funny, as isn’t Omeka based on PHP?.. Well, any other suggestions I can try?
The right path varies from server to server but since you talked to your host they should know the right one.
One other simple thing to check, the line where you’re setting this in the config.ini file, there’s no semicolon at the front of the line, right? Having that semicolon there makes the line a comment that has no effect.
Yes, I have quadruple checked semicolon and typos, I have learned
And just double-checked from service provider that paths are ok.
OK.
So, my thinking is maybe your host doesn’t allow the PHP function we use to run background jobs? The function is exec and you could ask them if they disable it.
Forwarded that info to service provider but haven’t gotten any from them yet. But just a wild guess: if they have disabled that function, wouldn’t that affect more widely to the operation of Omeka, like preview creation etc.?
Just checked, from this problematic installation to our site at omeka.net API import works fine and dandy.
If I recall correctly, the derivative strategy that worked for you from your last thread was the “Imagick” one (and not “ExternalImageMagick,” which is the default one).
The “Imagick” one specifically doesn’t require this kind of “running a command on the server” access, the exec function. The fact that you had to switch to it to get thumbnails working is probably another point in favor of thinking this is where your problem lies.
So I think it’s fairly likely that your host has indeed disabled the exec function (and probably others like shell_exec also).
Yep, service provider has indeed disabled exec function and seems that it is common practise on shared hosting environments (you might want to update your docs about this possibility).
As they are installing just another new server, they proposed that they’ll move our installation into that one and temporarily (as there’s no other clients nor services than ours) enable exec so we can use API to updated the data. Lets see how that goes then in coming days…
Thanks for your help so far!
Hmm…
Today everything was transferred to new server, us being only customer so they were able to enable exec function for us. Omeka with existing data, as well as Wordpress, wrongs fine and dandy.
And still Omeka tells that path is not ok. Tried all PHP versions (above) as well tried to shorten all paths etc. No help.
So, the I think that initial problem with path has not been related to exec function as without Omeka having correct path that cannot be even (tried) to execute…
So, if we tell Omeka where’s PHP, why it don’t want to use that info but thinks that it is not ok?
Just double checked that shell_exec has been also enabled and - just in case - service provider increased PHP time limits. No help.
Just also verified (in terminal) php path by “which php” and it is the same as written in config.ini.
How about this kind of approach: can we start this import process via terminal (if approved by service provider) and if so, how to do that (what is command format etc.)?
The function that’s running that actually does the checking here is this.
So one possibility that jumps out is, maybe they have also disabled escapeshellarg and not enabled that for you.
Yep, that was it, seems that all those three (exec, shell_exec and escapeshellarg) functions needs to be enabled before the API import can be run.
So, it is now running and hopefully we’ll finish it withou any hiccups.
Thanks for your help!