I approve of this. Some web hosts limit the amount of cronjobs you can run, so if you have several sites (rather than an msn which I imagine would only need cronjob on the main install) then this would be handy. Especially if the sites are not high traffic and don't need regular updates.

In such a situation I'd just suggest someone chains the CRON tasks.

You could make a simple bash shell script that calls them in sequence.

Well I didn't know you could chain them so that's an interesting fact to learn. I will have to read up on that. At least one of my sites is running via EasyCron rather than my webhost as the limit on my cheap account (£19.99 for 2 years of hosting) is 3 cronjobs.

I still think this is a good idea, at least initially until you get your site ready to roll and work through the checklist. I must install Composr at least twice a week to try something different or because I've ended up with an error I have no idea how to fix (catalogues mainly, got a couple of bugs to report once I work out how I managed to create them). So I wouldn't want to set up cronjobs in those instances, for it to work (in any fashion) would be useful although I agree it's not the best solution it is a handy thing.

If something's really broken you can always ask for help, unless you really did break it yourself. Even then, you can ask on the forums.

----

1 big problem with Poor Man's CRON I realised is when creating clone test sites. If CRON is going to automatically work, then all kinds of background tasks like birthday emails are going to run from the clone site, spamming real users.
Of course, that could happen for other things like if users have notifications on, but that'd be a much smaller problem.
Ideally someone making a clone site would disable e-mails on it via the mail_queue_debug option, but it takes time to get to the admin config to do that and by then loads of emails could have gone out.

EDIT: I've edited the clone site tutorial to mention disabling email in _config.php.

I'm imagining this could work without AJAX using register_shutdown_function after a page is finished processing.

The function would only get registered / execute if Cron had not run in the last minute (and if a config option for web request based triggers is enabled).

Currently, cron_bridge itself has its own "max execution time" and query limit, so it will terminate itself without PHP's help after 8 seconds or 3,900 database queries. This would have been the crucial reason not to use register_shutdown_function in the past because it does not respect PHP's max_execution_time.

The only downside is servers which do not support register_shutdown_function. We could instead then have it execute alongside their request (but this would slow down page load) with a much more conservative 3-second execution limit.

AJAX would nix that problem but introduce other problems such as CSP, whether JavaScript is enabled, and what if a user navigates away before it's finished?

We could use a webhook method... if register_shutdown_function is not available, then use cURL to call the cron bridge asynchronously.

I'll try some of these methods.

Automated response: Poor-mans-Cron

Implement ability to use web requests as a way to run scheduled tasks.

The approach I went is different from the original issue:

- Instead of AJAX requests, this uses register shutdown function (if available) when calling a webpage (running_script('index')). And it will only call scheduled tasks via web requests if explicitly enabled in a new configuration option. The reason for this approach is to keep the burden and responsibility off of the client's JavaScript. AJAX could affect rate limiting / banning of the client when it should not (e.g. the AJAX call could result in an additional count against the client for page requests, whether in Composr or on the server end, which is unfair to the client as this is the server's responsibility to handle; it also makes it harder to determine in access logs when someone is trying to abuse cron_bridge.php).
- This *will* (opposed to the issue's desire to not) mark Cron as functioning properly. This is because the admin has to explicitly enable this feature opposed to it happening automatically by default, and the admin should know when for whatever reason this feature is not working.

Notes:

Advantage "Can be used for background caching on a fresh install, to improve perceived initial slowness (to leave a better first impression)" does NOT apply for this approach since the feature has to be explicitly enabled in configuration.

Disadvantage "bots probably wouldn't trigger AJAX, and if we did it via something like an <img> tag then onload wouldn't trigger quickly enough" does NOT apply. If a bot hits an actual webpage, that will also trigger scheduled tasks to run.

A hotfix (a TAR of files to upload) has been uploaded to this issue. Only apply this hotfix if you absolutely need it and cannot wait until the next release of Composr (releases are more reliable and strictly tested). As of Composr version 11, the recommended way to apply a hotfix is by following the same steps as an upgrade (https://baseurl/upgrader.php, use the hotfix on the step “Transfer across new/updated files”). The upgrader will automatically skip files belonging to addons you do not have installed or that are newer on disk than in the hotfix. Otherwise, you can manually extract and replace these files (do not replace if your on-disk file is newer than the one in the hotfix). Always take backups of your site or at least files you are replacing before applying a hotfix. Not sure how to extract TAR files to your Windows computer? Try 7-zip (http://www.7-zip.org/).