Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.
Categories
Tags
Archives
Calendar
Categories:   All Categories
Suggested keywords
x
Font size: + –
  Print

Running scheduled (cron) tasks with Joomla

7102 Hits

joomlaWe have recently developed a feature with one of our components to make use of a scheduled task to perform a repetitive action, which avoids the need for us to enter the site and manually click upon various icon(s) which in turn cause the required action(s) to occur. Such a requirement is reasonably common and includes things such as sending scheduled emails etc. We were expecting it to be difficult to implement but as it turned out was pleasantly easy to achieve.

Upon UNIX based systems ‘Cron’ is a daemon that provides a time-based job scheduler that runs in the  background on UNIX systems that executes commands at specified intervals. These commands are called "cron jobs."  Windows servers use a Scheduled Task to  execute commands. Typically a task requiring repetitive actions  to be carried out on a regular (pre-determined) basis would be ideal candidates for using ‘cron’.

There are basically a few methods that can be used to provide a  scheduled task within Joomla. The preferred method will depend upon the specific web hosting supplier and the facilities they supply. [For our implementation it was necessary to supply both mechanisms, since some of our users’ systems may not have one or the other.]

 

1) It is possible to make use of a ‘bespoke’ plugin which can we invoked when someone accesses one or more pages upon a site and performs some predefined tasks.  This is really a ‘pseudo-cron’ since there is no real way in which one can guarantee that there would be a site visitor at any predetermine time, and has an unavoidable side effect of slowing the site access for the specific visitor that happen to visit the site at or immediately after the desired time.  For this reason we do not suggest implementing such a mechanism, however for some ‘short’ running tasks it might be suitable.

The following mechanisms are real ‘time based’ schedules, and generally run at the ‘pre-determined’ time.  These make use of the UNIX' ‘cron’ daemon or Windows task scheduler.

2) If a Command Line Interpreter version of PHP is available then a PHP script can be written to be called by the PHP CLI executable.  However not all web hosting suppliers provide such an executable so in these situations one is usually forced to turn to the second option.

Note: Most hosting suppliers supply a CGI  (Common Gateway Interface) version of PHP and one may have to specifically ask if a CLI version is available. One way to determine the version in use is to invoke PHP from the command line with the ‘-v’ or ‘—version’ option. The output will contain the string ‘cli’ or ‘cgi’ immediately after the version number. 

3) The next option is to make use of the front end of the site and provides  a task that may be invoked by a web browser, but more commonly by a utility accessing the web page such as wget or curl. The front-end access URL's for ‘cron’ tasks are not usually designed to be run from a normal web browser, but from an unattended cron script,  utilizing wget or curl as a means of accessing the function. These are server side binaries that can be thought of as applications which simulates the  behaviour of the browser. They typically try to access the cron supplied  site URL so that the accessed page actions occur. Such tasks typically when invoked in this way do NOT provide progress details.

Note: If your site does not provide a scheduling ability there are several third party sites, that for a modest cost, will enable one to run scheduled task accessing your site.

The front end of the site requires an access point so a controller method is created on the site, which is then supplied as the URL to the wget (or curl/lnyx) executable.  Additional options can be supplied upon the URL, typically to provide some additional security, which are checked in the controller to ensure  correct ‘calling’.   The main reason this is required is because the front end can be accessed by ‘anyone’ and one usually wants to protect such publicly accessible URLs!  Since the ‘task’ is not intended to be visible to the front end of the site, any output is usually directed to an output file or log, which may be within a database, or on the file system.

We found it relatively simple to set up the task on the front end and the setting up of the UNIX crontab entry was trivial. [There are many excellent tutorials on the web about setting up crontab entries.] The main problem was writing the code within the controller, and even that was fairly simple.

When we turned to creating the PHP CLI script however we found a few problems. First the sample examples on GitHub just wouldn’t work, complaining about missing ‘include’ files!  Not surprising since they didn’t exist on our installation.  Then we found difficulty in getting database access from the script, which kept raising a database connection exception.  We eventually gave up with the examples, and instead took one of the existing CLI scripts (located in the cli directory hanging off of the Joomla root directory) named ‘update_cron.php’ and used this as the base for our implementation.  It is fairly basic in what it has to do, but conveniently accesses the Joomla database and file system, so was ideal for our requirements, and as an added bonus is unchanged between Joomla 2.5 and Joomla 3.2!  Some customisation was required to get it to use our ‘pre-defined’ language text strings and our ‘helper’ files, but the end result very closely follows the structure of our front end ‘controller cron task’, making the code maintenance much easier.

We were surprised to find that there was no existing mechanism to include/invoke within the component xml which would place the cli script in the ‘cli’ directory of the Joomla installation, so we wrote our own code in our install/uninstall script. Not difficult just something else to do and be aware of.  We can only imagine that not many third party components make use of ‘scheduled’ tasks.

Putting it all together was much simpler than we had expected and we have decided to implement it in some of our other components.

We can already see ways in which scheduled tasks can be further used to improve component functionality.  The processing of ‘received’ emails from an email server is one that we want to investigate further.

Tags:
components joomla Cron security PHP
Problems installing a Joomla component
reCAPTCHA updated by Google

About the author

Geoffrey Chapman

Geoffrey Chapman

Subscribe to updates from author Unsubscribe to updates from author Geoffrey Chapman

An IT professional with a wide experience of IT systems, specialising in Database Management and Security.

Author's recent posts
More posts from author
 
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries