I spent a lot of time trying to figure out how to make phpJobScheduler work to trigger jobs using an HTTP url address. More about that in the posting after this one. I learned a number of things about PHP, CRON, PHP-CLI, Security, Hosting limitations and Job Scheduling:
Most of the job schedulers are in Java or Perl. phpJobScheduler is the only one I could find in PHP. phpJobScheduler does not do any job sequencing (other than by timing when the jobs start) so there is still a gap if you want to do anything fancy.
The web hosting services (in this case mine) turn off a number of options in php.ini as security precautions. One of those options is allow_url_include and this was the source of my problem with phpJobScheduler. With this option off, you can only include another module within your own site (i.e. using a relative address).
With some / all web hosting services, you can use a local php.ini file to override the normal settings. This is on a directory-by-directory basis so you need a php.ini file with an allow_url_include = on command in every directory where you will do an include using a full URL. This can also be a security exposure so if you just add the php.ini to overcome the problem, you are re-introducing the exposure that the Web Host was originally trying to block (but limited to the directories where you add the php.ini).
I wanted to use CRON to trigger phpJobScheduler as a background job so I could run it at a consistent time (in the middle of the night) when it wouldn't impact any users of the site. CRON seems to impose some limitations that my Hosting Service didn't seem to be aware of (and aren't identified in the CRON manual). It uses PHP-CLI to parse the PHP code and it seems to limit using Header and Meta commands that would cause it to lose control (which probably makes some sense since php-cli is a command line tool). Even though my code (using a Meta refresh) worked fine locally and on the server when called from the browser, it would not work when called from CRON.
I experimented with Exec, System and other such PHP commands and tried running a task in the background (which I eventually figured out how to do). This was similar to Header and Meta in that it wouldn't work when initiated through CRON.
I had intended to enable the php.ini file(s) by changing the name, changing the content or changing the permissions (from a php program). None of that would work when the initial program included firepjs.php (even when they were in different directories. It wouldn`t recognize the change to php.ini until the job ended. Using the Meta Refresh approach worked but couldn`t be used with CRON.
I also tried the PHP command ini_set but I found that it also seemed to be disabled (and will apparently be disabled in PHP itself in upcoming releases).
In the end, with all of the limitations, the only feasible approach was to use separate CRON jobs as described in the next post. If I have a need to use Meta Refresh or Exec or any of the other things that I experimented with on another project, this experimentation may provide some payback.
