Extension Documentation

Front-end access
Prev Scheduled Tasks Next

Front-end access

This mechanism makes 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 a web page such as wget or curl. Such tasks typically when invoked in this way do NOT provide progress details.

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, utilising a server side executable as a means of accessing the function. Typically utilities such as wget, curl or lynx are used, which 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.

Normal web browsers tend to be "impatient". If a web page returns a bunch of redirection headers, the web browser thinks that the web server has had some sort of malfunction and stop loading the page. It will also show some kind of "destination unreachable" message. Remember, these browsers are meant to be used on web pages which are supposed to show some content to a human. This behaviour is normal. Most browsers will quit after they encounter the twentieth page redirect response, which is bound to happen. Using browsers such as Firefox, Internet Explorer, Chrome, Safari, Opera or any other browser are not intended to work with the front-end cron based features. They are not meant to work by design.

Command line utilities, by default, will also give up loading a page after it has been redirected a number of times. For example, wget gives up after 20 redirects, curl does so after 50 redirects. Depending upon the actual task being executed it may be advisable to configure the command line utility with a large number of redirects. The number will depend upon the task itself.

[Tip]Tip

There are several locations upon the web that provide a free service enabling of scripts supporting CRON. There is a free service from Webcron that provides a simple interface, that we have tested out ourselves. There is also a paid service that Webcron.org provide that fully supports a number of front-end features and is reasonably cheap - you need to spend about 1 Euro for 1000 runs. Just make sure you set up your Webcron CRON job time limit to be at least 10% more than the time it takes for the script to execute upon your site. Don't know how much is that? No problem! Just run the script from your site's front end and average out the run times and add about 10% more to the required value.

It should be noted that IF your site uses any redirection component such as sh404SEF (and possibly .htaccess) that the URL specified in the Webcron service should be the 'redirected' URL and NOT the initial URL, otherwise a 301 error is seen.

One feature that is often included is the supply of a 'Secret key' or 'Pass Phrase'. It is a character based string which will allow the CRON job to ascertain that it has the right to request to run is acceptable. It can be thought of as an additional security feature.

[Tip]Tip

Use only lower- and upper-case alphanumeric characters (0-9, a-z, A-Z) in your secret key. Other characters may need to be manually URL-encoded in the CRON job's command line. This is error prone and can cause the backup to never start even though you'll be quite sure that you have done everything correctly.

Most hosts offer a CPanel of some kind. There will be a section named something like "CRON Jobs", "scheduled tasks" or the like. The help screen they provide should describe how to set up a scheduled job. The missing part would be the command to issue. Simply putting the URL in there is unlikely to work.

[Warning]Warning

If your host only supports entering a URL in their "CRON" feature, this may not work with most cron scripts. There is no workaround. It is a hard limitation imposed by the host.

[Important]Important

Be careful with any caching that may be present upon the web site. If the specific page being accessed is present within the cache it will be delivered to the caller, BUT the underlying actions will NOT be invoked. It is better to disable cache for the specific page.

We wasted a lot of time with tracking down this specific problem, and have not found it mentioned anywhere else on the web.

UNIX System

The following examples assume that the command is referencing a Joomla component named 'com_component' and that the specific cron task to be performed is configured as 'cron.xxxx'. These will be dependant upon the specific task and component being used.

[Note]Note

We have tried to make this description generic, however in our specific implementation the component name to be used in the examples would be 'com_issuetracker'.

You can use one of the following commands depending on your server:

lynx -source "http://www.yourwebsite.com/index.php?option=com_component&task=cron.xxxx&secret=YourSecretKey" > /dev/null

Or

wget -O /dev/null -q "http://www.yourwebsite.com/index.php?option=com_component&task=cron.xxxx&secret=YourSecretKey" > /dev/null

If you access your website using an HTTPS protocol, you may want to use this command instead:

wget --no-check-certificate -O /dev/null "http://www.yourwebsite.com/index.php?option=com_component&task=cron.xxxx&secret=YourSecretKey" > /dev/null

Some hosting company block the lynx and wget command in which case you should use the curl instead:

curl --silent --compressed "http://www.yourwebsite.com/index.php?option=com_component&task=cron.xxxx&secret=YourSecretKey" > /dev/null 2>&1

or

curl -L -v "http://www.yourwebsite.com/index.php?option=com_component&task=cron.xxxx&secret=YourSecretKey" > /dev/null 2>&1

Depending upon the PATH setting in your session it may be necessary to specify the full path to the executable, and is probably a good idea to specify it as a default anyway.

i.e. /usr/bin/wget instead of wget.

Any line breaks which may be shown in the above examples are included for formatting clarity only. One should not have a line break in the command line!

[Warning]Warning

Do not forget to surround the URL in double quotes. If you don't the script will fail. The reason is that the ampersand is also used in UNIX to separate multiple commands within a single command line. If one doesn't use the double quotes at the start and end of the script URL, your host will think that an attempt has been made to run multiple commands and load your site's home page instead of the front-end page URL.

Contact your host; they usually have a handy help page for all this stuff.

[Important]Important

Using a web browser (Internet Explorer, Google Chrome, ...) or wget version 1.10 and earlier may result into an error message concerning the maximum redirections limit being exceeded. This is not a bug. Most network software will stop dealing with a web site after it has redirected the request more than 20 times. This is a safety feature to avoid consuming network resources on misconfigured web sites which have entered an infinite redirection loop. To avoid this problem (if you encounter it, there is the option --max-redirect on wget version 1.11 and above.

[Warning]Warning

Any ampersands entered in the crontab entries should be written as a single ampersand, not as an HTML entity (&). Failure to do so will result in a 403: Forbidden error message and the task will not run. This is not a bug, it's the way wget works.

Prev Up Next
Scheduled Tasks Home Command Line Alternative
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries