Pseudo-Cron

[ryan]

Add a Pseudo-Cron implementation to WP core. Useful for handling future posts, scheduling backups, etc.

​http://comox.textdrive.com/pipermail/wp-hackers/2006-February/004764.html

Pseudo-Cron Implementation from Owen and Ryan

wp-cron.php

First pass.

[3512]

And along comes a second pass. A list of improvements:

• Spawns off with fsockopen like execute-pings.php (and works on CGI in testing as well!)
• Filters for adding schedules to schedule events by (And the ability for an action to continue on without problems when its schedule providing plugin has disappeared)
• Future-posting actually works in this cut
• A volunteer by me to write documentation and fix this up more in the future.

Feedback is appreciated.

Oh, forgot to mention, this needs a few other bugfixes applied to work that I've submitted patches for while writing this.

#2542 and #2537

[3634]

I prefer wp_schedule_event() to wp_schedule_new_event(). I think the new is implied. Any preferences?

+1 for name change.

[3635]

Ryan's DB_PASS + salt check didn't make it in.

wp-cron.php doesn't need ?time= time(), unless we want to be able to run cron against future times.

Also, typo in function name.

Patch attached for all the above.

md5 check, don't need time (do we?), typo

Ah yes - sorry. And that patch gets rid of an extraneous fwrite().

Actually, the md5 and dbcheck was left out intentionally, I don't understand why it would be there in the first place. An external script loading wp-cron.php has no negative side effects, it just fetches an option and not much more, crons aren't run unless their scheduled time has come. This way, I had planned with MarkJaquith to include a constant to disable auto-spawning of wp-cron.php and allow a real cron to fetch it.

Thanks for catching the fwrite though, old debugging stuff. And the typo as well, that was from me moving the functions under wp_ to keep consistant.

Marty Malicious: "Bwah haha. I'll... run his... cros jobs for him...."

Good call.

With the NST about, this may show up as a vulnerability, I can see it now:

========== WordPress 2.1 Remote Cron Exectuion ==========
Severity: CRITICAL!!!!1

WordPress 2.1 allow any users to run wp-cron.php which may run scheduled cron jobs on remote server.
this vuln has a few problems though
[1] The cron jobs have to be scheduled by an admin user

If you are an admin user, you can enable cron jobs that could potentially damage your install or users!!

Solution

wordpress/ $ rm wp-cron.php

Anyways, now that that bit of halarity is over, here's a fix for just that typo mdawaffe pointed out.

[3636]

I committed the entire patch. The salt doesn't hurt.

Oops, we crossed in the mail. We can remove the salting if we don't want it.

WARNING: (MOSTLY TO KEEP PODZ HAPPY)

masquerade's above post was a ​joke. Don't take it seriously.

Oh, and masq, you forgot all the "l0lz!!11" and "h3h" and "gr33ts".

Could someone please document how this works in general, either here or in the codex (and also point out since it's named wp-cron that it has absolutely in common with the plugin by the same name).

So far all I have observed/learned is that in 2.1 wp-cron is periodically calling wordpress back through the web at regular intervals (and therefore messing up my stats, quite annoying).

I'd definitely like to keep it's functionality for other plugins to hook into, but admin with enough experience should be able to setup a real cron to call it internally via php instead of an external web call.

remove_action('init', 'wp_cron');

will apparently disable it's web based self-call

Now how about some example code and suggested periodic time frame for a real cron to call it?

I'll get us started with what little I know, on most cpanel servers, this will call a php file every 20 minutes (offset by 5 to avoid load from automated newsreaders set to the hour)

5,25,45 * * * * /usr/local/bin/php /home/accountname/public_html/wordpress/example.php

So what should I be calling instead of "example.php" ??

ps. why is this ticket labeled as defect when it's clearly an enhancement?

Closing this as fixed by the above and more. New cron issues should go into new tickets.

Masquerade, I agree about the salt. If it's still an issue, let's start a new ticket.