How do Joomla CLI/Console jobs and Task Scheduler jobs fit together?

Question

I know that this could be considered a subjective question, but I think it's important. (I do produce Joomla documentation for extension developers and it would be useful to relay answers to them).

In Joomla 3 you would write a CLI job which was based on JApplicationCli. You would package it up in a file type install, and set up a cron job to run it automatically.

In Joomla 4 the JApplicationCli (aka Joomla\CMS\Application\CliApplication) class is deprecated with an indication "Use the ConsoleApplication instead".

How to develop a console application is described at https://docs.joomla.org/J4.x:Writing_A_CLI_Application and you can develop applications which can be run from a command line or a cron job:

php cli/joomla.php mycommand:task

So far, all is fine.

However, Joomla 4 also includes a task scheduler. You can write a task and configure when it should be run (or you can click a Run button to run it immediately). The task scheduler then acts a little like cron and runs the task automatically, albeit that the scheduler needs some sort of trigger to kick it off, eg a separate cron job or visitor traffic on this website.

I updated a Joomla 3 CLI job using both approaches. (The job queried some database records and sent an email with the results). The approaches are similar in that:

• both require a plugin, which must respond to an event to indicate that the task I've written is available
• both have a mechanism to define and obtain task configuration options
• with both you write a function which performs the task you want

However the approaches are different enough to make it a bit of a challenge to avoid duplicating code between the two.

Hence the question of how do the approaches fit together, if at all. When should one approach be used instead of the other?

I understand that one answer could be: well, Joomla gives you the choice.

But then, whose choice is this, the extension developer's or the Joomla website administrator?

If it's the developer's choice then an administrator could end up with some jobs to manage as cron jobs, and others to manage via the task scheduler.

If it's the administrator's choice then it seems to me that extension developers would be expected to develop both options.

Answer 1

Not all Cli based applications are required to be run on a schedule therefore not all Cli instances are suited to be created or converted to the Task Scheduler approach thus there is no choice for some applications.

After converting some Joomla 3 Cli applications across to the Task Scheduler initially I found it to be unreliable in a production environment, or at least my environment and eventually repackaged them as Console applications triggered by cron and have regained the stability/reliability I had previously.

Task Scheduler has two issues that I found make it less than ideal for production use. Firstly it relies on the task completing correctly to update the Task Scheduler to say it has completed, successfully or otherwise. This doesn't always occur, time outs etc. and it is difficult to debug why a task never completed which leads to the second issue. Only one task can be run at a time thus if a task if left as 'running' because it was never updated on completion then all other Tasks never start whether they are related or not.

My take is it was GSoC project that is a good idea that was developed enough to function but really needs further development and thought invested to make it a production stable component beyond very basic needs.

If it is assumed the Task Scheduler is suitable and scheduling is required and then there is a choice between the TS and Console for applications.

To be considered would be who is required to manage the schedule, the client/Administrator(client functions) or website builder(backups etc.), Task Scheduler or Cron respectively.

Where there is ambiguity or it is not the developers role to choose, then it is up to the developer to create a 'version' of each which isn't really complicated or difficult, it is still a plugin either way. The functional part of the application I think should be in neither the TS or the Console, rather they are just entry points to the real functionality that is part of an installed extension using the usual MVC approach and as much of the existing code as possible.

Update 11th July

While browsing the Task Scheduler code for something else I noticed that there is a flag/switch that can be set per Task to indicate whether it can be run concurrently so that tempers my previous comments regarding issues experienced with serialisation and unrelated failed tasks.

Another consideration when choosing between the Task Scheduler and the Console based application is which application environment do you need to run in to get the results you require. Task Scheduler I am pretty sure, but haven't be able to confirm this, runs in the SiteApplication environment while the Console appears to default to the CliApplication. Code can check this with an isClient() but the Application matters if you are expecting particular plugins or code to be available that may not be the same as the environment each uses as the default. The reverse can also apply if you want to a avoid plugin's or code that doesn't check and thus breaks in the Application you are in.