Cron Storage Abstraction

[ryan]

Abstract cron storage to allow pluggable storage schemes.

WP_Cron_Store

Moved to WP_Cron_Store class that can be inherited by a custom class or overridden. It is loaded in the same fashion as wpdb. I started by using a custom class filter as is done with the xmlrpc server class and other classes, but core WP (and thus probably many plugins) was calling cron functions prior to init. I moved the core places that were doing this into a function hooked onto init. If we are willing to suffer a back compat hit, we could move to the class filter approach which has the advantage of not requiring files living directly in wp-content that aren't part of auto updates.

Updated WP_Cron_Store

I've attached an updated version of Ryan's patch. I've tested it locally and fixed a few minor bugs, but haven't tested it in production yet.

I'm also attaching a cron.php drop-in that would use a separate cron job table. This drop-in won't handle concurrent wp cron processes any better than the current wp cron, but it will handle prevention of duplicate jobs and prevent race conditions that cause jobs to get lost. Concurrent instances of wp cron could be minimized by updating executing jobs to the "processing" state and checking the job state prior to executing. They could be completely eliminated by spawning 1 cron process to handle each queued task, but I didn't want to get too ambitious without feedback.

Some of the modifications include:

• Private methods are handled entirely within the cron store class, cron API no longer uses private methods but instead passes arguments to the cron store class

• Changed WP API to pass functions directly to the cron store class. The cron store can figure out how it wants to handle those params.

• Ryan's previous patch removed the procedural versions of _get_cron_array, _set_cron_array and _upgrade_cron_array, this patch takes the next step and actually labels them as protected methods. Not having a publically-accessible version of these methods may break some plugins that used them in spite of being labelled with @access private. If that's the case, may need to make the methods public and create a public procedural function that also invokes doing_it_wrong and _deprecated.

• I wonder if it's cheaper for *_Cron_Store->get_event() to first check if the event exists, if not then immediately query the event from the database rather than looping through the current cron array?

• Can't bail out of *_Cron_Store->get_event() early if _cron_array is empty, because there may be events stored in the database. Don't want to query all pending events because of large job queues, e.g. Disqus on sites with a lot of comments.

• If using the PMC_Cron_Store class, wp-cron.php could be improved by updating in-progress jobs to "processing" status. Then it would be possible to go back and see what jobs failed/never completed, and potentially have an automated process that would retry them and/or alert the admin that the jobs never completed. It also paves the way for having wp cron spawn 1 process to handle each pending job it tries to process, rather than trying to procedurally complete jobs. This would theoretically negate the need for the "doing cron" transient.

Proposed improved cron store (as a drop-in)

Oops, the cron.php drop-in I originally attached depended on a function only available in upgrade.php. Fixed that.