Job without PHP-CLI

Omeka S
1

Hi !

I have an Omeka S instance on a server which don’t have PHP-CLI package. When I dispatch a Job, I systematically get these errors in the log:
ERR (3): Command "command -v 'php'" failed with status code 1.
ERR (3): exception 'Omeka\Job\Exception\RuntimeException' with message 'PHP-CLI error: cannot determine path to PHP.' in /path/to/omeka-s/application/src/Job/Strategy/PhpCliStrategy.php:62

I would like to know if Omeka S integrated a way to perform a job using current PHP instance instead of trying to exec() a PHP-CLI instance.

2

The problem is, executing a job in the current PHP instance leads to all sorts of issues with things like execution time limits and browser-side timeouts, the user navigating away, etc.

The jobs are intended for executing things that would take a long time. Strategies that do something other than exec-ing are certainly possible, but usually a separate PHP process has to be involved at some level to get the separate long-running process that’s desired.

3

Yeah, I understand why CLI is used.

However, I think other CMS do not require CLI to execute batch tasks, but I don’t know how they work. Maybe I’m wrong…

4

Another approach would be to use a work queue either in the database or a message queue. Similar projects like MDID off-load work to RabbitMQ where another process (possibly on a different server for scalability) listens for, and performs the work asynchronously.

Some universities with shared PHP hosting also disable the exec function for security reasons, so other, less system level options would be appreciated.

5

Message queues are a fine approach, one that we’ve had support for in Classic by way of Beanstalk support. S currently only has support for directly using exec, as you know, but the same system is in place to have a pluggable, configurable set of job dispatchers, so support for a message queue is possible either in the core or (possibly better as there’s a fair variety of them) from a module.

They don’t really do much for people on restricted setups though, since you still need to be running a PHP worker(s) somewhere to process the jobs. They’re also just generally a lot more setup-heavy. It would work around exec being blocked though, I suppose.