-
-
Updated 21-01-2023 with code corrections by WPMU Dev. Multisite cron script code are now compliant with PHP 8.x.x.
Why You Are Running WP Cron The Wrong Way in WPMU
So you have installed your new shiny WordPress website and then converted it to an awesome WordPress Multisite network with all the bells and whistles; you have configured the WordPress cron job either though C-Panel with wp.cron.php or through a plugin. All happy days right?
Nope!
Why?
Well while this is perfectly fine and good when it comes to single stand-alone WordPress installation it is just not good enough to WordPress Multisite and it doesn’t apply if you run a WordPress Multisite installation. Actually all the generic common advice you can find on the internet about configuring WordPress cron is absolutely incorrect!This is because there is a little dirty WordPress secret that you cannot find even on WordPress.org’s own website. And “what is that secret” you might ask?
Well the secret is that thew wp-cron.php file only fire and run on your main site in Multisite and not on all your sub-sites in WordPress Multisite so all the scheduled tasks that you might setup for any sub-site in the WordPress Multisite network will never ever run correctly.. Crazy isn’t it?
So we thought too and therefore created a fix for it.
In WordPress you have a small file called wp-cron.php, which simulates normal cron-jobs. except this file isn’t executed every x amount of minutes. Instead WP-Cron will execute when someone visit the website. This will in normal single site fire when either user visits the website which then in turn will run the scheduled tasks. Now there is problem with this method in two ways of course. The first reason is that if you have low traffic site, then wp-cron will almost never fire and the task will not run all the time and two; on high traffic site it be very problematic due to it can generate too many cron tasks that it quickly uses all the server memory and crash the server. So for that reason most WP cron tutorials suggest that you disable wp-cron in your WordPress installation:
and then you set up a manual cron job. This is all good so far. The issue starts when you using WordPress Multisite and the cron job only run by default for the primary website aka. site ID 1. We have coded a this a fix for this issue and our script called “wp-cron-multisite.php” which will enable cron to run on all websites in the WordPress Multisite network with a short delay of 10000000 microseconds between each site in the system.What you need to do to fix this:
Download our wp-cron-multisite.php and wp-croncustom.php script to your computer and save it as wp-cron-multisite.php and then upload it to your root folder of your WordPress installation:
wp-cron-mulitiste.php
wp-cron-custom.php
After that you will need to disable wp-cron in your wp-config.php file if you haven’t already done that:
and enable alternative cron for our custom WordPress Multisite cron job script.Once you have completed this step then head over to your hosting control panel and create the cron job manually:
or you could alternative use a online cron service to call the script for you if you prefer that. I suggest this website http://www.cron-job.org which is totally free to use and just works flawlessly.What happens when you fire the wp-cron-multisite.php is that it run alongside with the other file and that will call ‘wp-cron-custom.php’ which is a modification of ‘wp-cron.php’ file.
You should now have smoothly working WordPress Multisite network that just works with its scheduled task.
You can also if you want to test run the script your browsers to confirm that it is working properly:
https://yourwebsite.com/wp-cron-multisite.php
Hit enter and wait a little while and you should see the response that it is starting to fire up the cron jobs individually for each website which you have in the WordPress Multisite network.All right; that’s it good folks for now and I’m out of here!
Comment here in this SEO forum thread if you want and share this with your with anyone you think might have good use of this.
-
Thanks for the article. I’m wondering what types of things you folks use custom cron-jobs for. Sharing your code above is helpful. Perhaps a bit of dissecting the components for us budding developers would be helpful.
Cheers from Canada!
1 user thanked author for this post.
-
Hi Studio 6Am
Well there could be many reasons why cron jobs needs to run on the sub-sites in a WordPress Multisite network. The most common and simple reason is this:
In WPMU installations you will have many different flavors of plugins installed and not every plugin will by default run on the primary site or be network enabled. Thus there will be plugin on individual sub-sites that will run plugins that needs to be scheduled to do certain task such as they need to send out emails at a certain time due to various events or lets say a front-end meeting booking for example where the calendar needs to be refreshed and the attendances need to be notified when a meeting is about to start as an example.
The same applies for example to other types of plugins like lets say a security plugin where a malware scanner needs to be scheduled to run at a certain time and date. The same applies. The cron jobs needs to be running.
Now if you the cron jobs does not run on the sub-sites too then the functions of these plugins will simply not work as the crons are never fired up . So that is why it is not sufficient with just having the cron run on only the primary site.
Also you should think about that WordPress itself has a lot of natively scheduled background task and those need to run on the sub sites too in order for WordPress to function properly and if they to do not run there also then the WordPress background tasks will fail to complete their job on the whole network, (except for the main primary website).
I hope this explains it better for you?
Kind regards
-
Whoa!😮
This is a really useful information. I didn’t know that WordPress cron didn’t do this by itself on WordPress Multisite..
An angel in wolves clothing..
-
You must be logged in to reply to this topic.