In order to keep the site running smoothly and keep it up to date, there are a variety of chores that need to be performed on a regular basis. For example, we saw earlier in the book that the aggregator module needed to be run on a regular basis so that it could update all its feeds and so forth. The Drupal developers are well aware of all the tasks that need to be handled; so they bundled everything up into one handy script—cron.php.
You need to set the crontab or scheduled task to execute the cron.php
script, which is housed in the main folder of your Drupal installation, so that it can perform all the necessary tasks. The cron script basically searches through the site and executes any tasks that apply to modules or other things (like log handling) so that they all stay updated.
Let's take a look at how to control the crontab, followed by setting up a scheduled task for the Windows users among us.
If you are not particularly keen to learn how to make use of the crontab on your hosted site, then feel free to skip to the section entitled Poormanscron a little later on in this chapter. It is recommended that you do learn how to make use of the crontab regardless, because it will no doubt come in handy someday when your Drupal site is not immediately available.
All the variables set in the crontab are numerical constants, with the exception of the asterisk character, which is a wildcard that allows any value. The ranges permitted for each field are as follows:
You can include multiple values for each entry, simply by separating each value with a comma. The command you wish to issue can be any shell command, and can be used to execute web pages, like the cronfeed.php
file. Many hosting companies will have an interface such as the following one, which allows you to work with the crontab easily:
In the final entry you can see (hopefully) that the cron.php
script is set to run at midnight every day using the command:
/usr/bin/lynx source http://www.cwc.com/cron.php
whereas, for example, the first task is set to run every hour (remember to substitute your own site's URL in place of the highlighted code in the previous snippet). Notice too that the php
command was not used to execute the cron script as it was for the other two scripts—this is because the cron.php
file needs to be accessed as a web page so that certain environment variables are properly set.
On the off chance you are using a Windows-based server, or simply wish to enable scheduled tasks on your Windows PC while you are developing, you can make use of the Scheduled Task wizard. The following instructions, taken from the Drupal site, explain exactly how this is done:
cron.php
page in double quotation marks (for example, C:PROGRA~1MOZILL~1firefox.exe "http://localhost/drupal/cron.php")If you find that you are unable to set a cron job to run on your host site once it is live, then you can use a neat trick and set your Windows scheduled task to access the cron.php
script directly from your home PC instead using the instructions just listed. This means that the cron script is executed, depending on your settings, as often as your PC is online and able to access web pages.
This last point highlights how easy Drupal has made things when it comes to performing necessary tasks on a regular basis. All that's required is a browser application of some sort to access the cron.php
script, and any tasks that need to be run by the Drupal site will be run. You could access this script from your own browser, or set your own PC to do it whenever you start it up, or any other number of things.
It should come as no surprise that there is a contribution that can make life even easier. Poormanscron is a contributed module that does away with the need to set the crontab or a scheduled task entirely.
It works by checking whether the cron script has been run in the last unit of time (whatever you have set this to be; by default it is every hour) each time a web page is browsed. If it finds that there is a cron run due, it will cause this to happen after the page has been served (so that the user does not have to wait for the tasks to complete before viewing the page).
Basically, Poormanscron means that you are freed from having to learn anything about cron jobs. This is convenient, but is also a double edged sword! It is quite likely that you will need to make use of cron jobs for other tasks, and if you use Poormanscron for Drupal, then all you are doing is postponing the time when you have to sit down and learn how to use the crontab or scheduled tasks. At any rate, you have seen examples of how to use all the options; so all that remains is for us to take a look at how to work with Poormanscron:
modules
folder.That's all there is to it—provided your site has regular use, your cron tasks will run smoothly and you need not worry about accessing the cron.php
script manually or setting the crontab.
After some time, however, you might get a bit sick of seeing logged cron messages all the time. If you want to administer the Poormanscron module, then head on over to poormanscron under settings in the administration area, to bring up the following page:
As you can see from this, there are a number of options available to control how often cron jobs should be run, how long to wait before retrying after an error, and what your logging policy should be. In this instance logging is disabled because there is nothing that urgently requires manual verification on the demo site (for the moment). If you added new software and had to confirm that it was being properly executed by the cron.php
script, then you might consider switching logging back on.
3.145.64.132