Unusual Cron (Scheduled Tasks) Change Between 3.59 and 3.62
2 posts by 2 authors in: Forums > CMS Builder
Last Post: October 25, 2023 (RSS)
By mark99 - October 24, 2023
I just wanted to highlight something I've discovered after upgrading from 3.59 to 3.62 on a dedicated server with Ionos. Before the upgrade I had no problem with cron.php, but after the upgrade I noticed they weren't running. In the past this tended to happen because I was calling cron.php with an older version of PHP via SSH/Telnet, but that was not the case this time around.
After a lot of testing, I discovered that in 3.62 I couldn't run my crons for CMS Builder in the way that usually works because the script now expects me to be logged in as a CMS Builder administrator first via the website (something you obviously can't do via a simple cron call).
So this didn't work any more:
0 * * * * /usr/bin/php8.1 /system/cron.php
Just in case anybody else runs into this, I resolved the problem by calling the command line interface version of PHP instead:
0 * * * * /usr/bin/php8.1-cli /system/cron.php
Hopefully this helps anybody else that runs into the same issue. I didn't change anything else in CMSBuilder for the upgrade, so I'm not sure what has changed between 3.59 and .62 to cause this, but I thought it worth highlighting so that others can benefit if they run into the same issue.
By Dave - October 25, 2023
Hi Mark,
Thanks for the report!
I made a patch for this for the next release. Here's the technical details if you're curious.
How it works is that cron.php can be run from the web or ssh/cron. For security, if it thinks it's being accessed from the web it requires an admin login.
We have a function in /lib/common.php called inCLI() that tries to determine if the script is being run from ssh/cron (e.g.; inCLI = in Command Line Interface).
It checks a PHP constant PHP_SAPI which is often set to 'cli' when run from the shell, but it can sometimes vary based on server configuration, likely that's why switching to php8.1-cli made it work, it likely reported a different value to cron.php for PHP_SAPI .
Web servers also usually set the script path in $_SERVER['SCRIPT_NAME'] so we're checking that as well. But previously we were checking if it had a value, and when updating the code it was switched to check if anything (even a blank value) was set. I've switched it back to the previous method.
What I suspect is that your PHP binary wasn't setting PHP_SAPI to 'cli' when being run from the shell and was setting SCRIPT_NAME but leaving it blank which is why it worked before.
If you run into this issue again and want us to have a look to confirm just let us know.
Thanks!
interactivetools.com