WordPress 2.6: The issue of “wp-cron.php”
I love WordPress. When I needed something simple, robust, and easy to use for a company project, I found out really quick how easy it is to use WordPress for almost anything. If you are willing to spend the time and find the right plugins for what you need, the sky is the limit. But sometimes I just have to kind of scratch my head at how WordPress does things.
So I’ve been working on this project for a few months now and I’m only just now starting to understand the inner workings of how the nuts and bolts of WordPress fit together. I’m also new to PHP, but have a background in Perl. Things were great until my server admin informed me that the install of word press was hitting a file called “wp-cron.php: over 381 times a day, and we haven’t even opened it up to the public yet. That seemed really weird to me so I did some poking around and found that this is a known issue with WordPress.
What is “wp-cron.php”?
-
Simply put, is the part of WordPress that takes care of all the scheduled tasks that WordPress has to preform in order to work correctly. For instance, changed a post from Unpublished to Published when it has been set to publish at a future date. Now WordPress is designed to be easy to install, easy to set up, and easy to use. So if you are a new user to the WordPress platform, the wp-cron.php file is something that takes care of a lot of the stuff you never even thought about. Until, that is, your system administrator for you web host turns you site off because you are “bogging” down the server.
Is this Bad?
-
There is a lot of discussion out there about what to do if your hosting service does that. The answer range from, “switch to a host who has a real sever set up” or “work with your host to see if there is a compromise you can make with them”. There are ways to edit the “wp-cron.php” file so that it can be run by the system cron every night with all of the normal sever jobs that clean things up when no one is looking. But still, this does not take away from the root of the issue, which is why I’m writing this rant.
- Gripe 1: Process Intensive
-
The “wp-cron.php” file is just another script that pulls data values that have been stored in the system memory of the sever, while a user load a page from WordPress. In normal speak, every time a person view a page on a WordPress blog, there are a lot of processes that get run in that moment that allow the user to see the pages they were intended to be seen, and “wp-cron.php” is one of those processes. So on every page load, this process get run. EVERY PAGE LOAD!! So there is my first gripe: Why Every Page Load? There has to be some way of accomplishing this task without running the script every time a new page is loaded by a person viewing the site.
The answer I have found to the why is that this is all done as a bundle of PHP scripts, which means all of these tasks are stored in system memory. This means every page load the information can change, so it has to execute ever page load. My response to that is…isn’t WordPress already connected to an database that could be used for that sort of thing? The updated processes could be run by perl scirpts or other such things that run on severs these days, and not having to hit the CPU of the server every time a new page load is run, but when it needs to be run.
- Gripe 2: Security
-
“wp-cron.php” is run by the web sever, not by a system process initiated by the actual server it’s self. This may seem confusing to some people, because most people think that a web server is the actual computer they are connecting to when the view a web page. That’s only partially correct. A Web Server is an actual process on a computer that gives you information based on how the server is set up to display it. This means the web server, just like any other person trying to preform a task on a server, is a user of that computer. A user that his triggered to do something when someone else is view the any page/post/image in the Word Press Blog
I personally don’t like the idea of the web server being told to do something by a user who may not even be authenticated as a user of my blog, let alone have access to my host server.
Does anyone out there resonate with this? Don’t get me wrong. I love the WordPress team and all the amazing stuff they do for the WordPress community. But it just seems a little odd that such a basic thing as hitting the web server CPU multiple times from one page view, seems to have become a common practice.
Trinity's World 
Hi,
Thanks for the informative post! I just got the dreadful notice that my hosting account was suspended as well due to this wp-cron thingy 😦
Would you know if the earlier versions of wordpress is less resource hungry? e.g. 2.3.3 or even the 2.2.x branch?
Thanks,
Adrian
You are very welcome!
You really don’t want to go back to older versions of WordPress, because there are a lot of security updates that are not included in the older branches that may leave you vulnerable to attack.
A while back I e-mail Otto (you may recognize his name from the support forums) and he was a gold mine of information, and really nice too. If your web admin insists on taking wp-cron.php offline, here is a solution. First step, remove the following lines from your wp-cron.php file (after you back up the original):
if ( $_GET[‘check’] != wp_hash(‘187425’) )
exit;
What this code does is keeps the cron alive (basically) so it can keep running. Once this is removed, if wp-cron.php is called directly by a web browser, it will only run the cron once instead of trying to stay alive with each page view of the blog.
Once this is done, you have to options.
1. Have your sys admin set up a system cron that runs frequently enough to suite your needs. If you are only posting a couple of posts a day, you may not need to run wp-cron.php more than once or twice a day. If you are doing a lot of posts, and if you have a large number of people subscribing RSS feeds and such, remember that all the automated stuff in WordPress (like future posts and RSS feeds) only get done if wp-cron.php runs. So when you ask your sys admin to set up a real cron, make sure you tell them that you need it to run X number of times a day. What ever that number is, I’m sure your sys admin will like it better than how many times wp-cron.php is currently running.
If your sys admin for your server is anything like mine, you may run into a tiny snag. If you are on a virtual host (many server hosted on the same machine) this may not be an issue. Some systems will deny the server the ability to use commands like CURL, WGET, or other commands that allow the server to see a webpage from the standard linux/unix/windows command line. This is important because in order to set up a “real” system cron job, the server needs to be able to run that process as a command script. My sys admin had disabled the ability to do that. For his own piece of mind (he’s a little paranoid, and rightfully so in my opinion), he was able to set it up so only the cron procedure could run that command and all was well. I tell you this to warn you that some Sys Admins will say something like “Your funny php script is not a real cron, and you should never set up a cron to run based on an outside influence on your server.” And they would have a valid point. But usually a comment like, “But how else would you do it though PHP” shuts them up.
2. If in the pursuit of option one you end up in conversation that degrades into a playground style name calling contest, here is an alternative: Use your computer to hit the wp-cron.php file if your sys admin will not set it up as a system cron. All that needs to happen, once you edit the two lines as I described above, is for any web client to hit that file and it will kick over. So, for instance, if you put the URL of the file (http://mydomain.com/wordpress/wp-cron.php) you will most likely get a white screen. But all the processes pending for WordPress would still be run by wp-cron.php. All you have to do then, is make sure you are hitting that file a couple times a day and you are all set.
I hope that helps you out.
Are you sure that removing those two lines will stop wp-cron running for each page.
I think it does not disable the cron. It only allows you to access it via web without an hash because normally, wordpress calls the wp-cron like:
http://yourdomain.com/wp-cron.php?check=8e75b76828161e47d6165ac6b650f990
By Removing these lines, as I understand it, wp-cron should only run when you actually hit the wp-cron.php file with a web browser event. Now, I have not been able to keep up with things like I used to, and the latest release may have changed, but that is how it used to work.
Holy crap! This is FABULOUS information. Thank you so much. I was able to adapt this information to get rid of the dreaded “Missed Schedule” problem that plagues scheduled posts.
You are my new hero.
Wow, I’ve never been a hero before! I’m glad this was useful to you, I know it frustrated the hell out of me for a while.
Removing the following lines:
if ( $_GET[‘check’] != wp_hash(’187425′) )
exit;
does not disable the cron. It only allows you to access it via web without an hash because normally, wordpress calls the wp-cron like:
http://yourdomain.com/wp-cron.php?check=8e75b76828161e47d6165ac6b650f990
That is correct, but removing the check line also removed the code that checks to see if the wp-cron job as been run and then runs the process. By removing this line, and the hash that should accompany it, you remove the ability for WordPress to run the cron automatically, which is what most web admins complain about. You still need to manually hit the wp-cron to make sure that things like future posts are managed correctly, but you can set it up as regular cron process that a sys admin can set up in a way they are comfortable.
Just to be clear, I wrote this post as a work around to make your hosting sys. admin happy, not as a solution. I still think a lot of thought needs to be done by the WordPress team to come up with a better solution. The server I was running into issues with was being hit about 1000+ times a day by the WP cron, when we don’t even utilize the future post feature. We now control how often, not the WordPress engine.
Fix missed schedules: http://blog.5ubliminal.com/48 .
Cool Plug in Subliminal, that should help out a lot for people who just want to kill the wp-cron, and take care of things on their own. But I’d still caution against this for one very specific reason: WP-CRON is part of the WordPress Core. Disabling a section of the core, and implementing a plugin to pick up loss of functionality, may be a great solution for some people who have admins complaining about the overhead of the wp-cron, but it can create the potential for even great issues latter.
I’m glad that this works for you. I just hope that the WordPress team realizes that the gowning number of work around that exist to fight the WP-CRON overhead issue proves that something needs to be altered in the way WordPress handles scheduling in general. I mean, storing values in the memory of the server as PHP variables is good for instances of code that only run for short periods of time. There has to be a better way of storing that data, in the MySQL table for instance, that does not sacrifice the speed gained by storing the values in PHP elements. Automatically running a check for what needs to be done on every page view is not a good implementation, especially when there are was to run automated process via the normal system cron.
I think this is a place where the decision to make the install of WordPress easy to install, has created a very large obstacle to over come. Not all people who install WordPress will have the Admin access required to add a system cron. At least, those who do no have the access may not be able to fully communicate to the sys admin the what and why of what needs to be done. While I applaud WordPress for picking the side that makes it easy for users, I still think there has to be a better way to implement it. But I’m not a programmer so….
Thanks for your solution. I’m using this with 2.7.1 and it seems to have prevented the CPU runaway that I was struggling with. I set it up to run a cron job every 4 hours. I used the curl command and have an email sent to me each time it runs.
However I am unsure if the trackbacks/pings are working correctly. Future scheduled posts do appear correctly but I still receive a message saying “Nothing found for Wp-cron Php.” Is that to be expected?
[…] at our hosting service. A solution was found which had been freely offered by another blogger. The wp-cron solution was from trinity777 at his blog, trinity’s world. We appreciate his knowledge and helpfulness […]
Thanks from Preacher’s Study | Preacher's Study said this on May 31, 2009 at 2:44 pm
Seeing that the pingback is listed from my site to yours I guess it is working.
jbevans, that is great! I like the touch of having your server e-mail you so you know exactly when wp-cron is hit without searching a log. Technology put to good use!
[…] https://trinity777.wordpress.com/2008/10/28/wordpress-26-the-issue-of-wp-cronphp/ Tēmas:Beztēma Birkas: Komentāri (0) Atsaišu sūtīšana (0) Komentēt Atsaite […]
cron job | Mārtiņa Štāla blogs said this on August 4, 2009 at 10:03 pm
Just to pipe in on the host side, my guys had one hell of time tracking this wp-cron.php issue down. what we mistook for several different types of attempted attacks was this little guy bloating up our Apache server (that makes the websites work) and our MySQL server as well. I too had to send that horrid suspended notice out. We had no choice to to do so because it stole the entire server and took it over. not really but none of our customers on that server could access it. its sad that they have not fixed it yet because we love to support the software but not at the cost of my techs sanity and the customers pocket book. After finding the link above and one from cPanel we were able to find a solution to what “our” issue was as the provider and be able to un-suspend our happy customers. now if Word press can find it in their hearts to add this fix to the next version maybe the hosters out there can stop having to suspend peoples service for using software that everyone wants to use. GRRR.
cheers!!
you really don’t want to be hitting the database for every page hit either… storing data in memory cache is much much faster than going to the db every time (executing sql is more cpu intensive then fetching data from memory)… you want a dynamic site, you have to pay the price somewhere.
This line is not included in WP 2.8.3. How do I apply this same solution to 2.8.3? Or how do I make wp-cron run only when I hit the wp-cron.php file with a web browser event. Thanks!
trinity777:
Can you contact me at the email address I’ve provided? I’ve run into the problem you describe but I’ve run into it with WordPress 2.8.5 and your prescription above doesn’t seem to apply.
I hate to bug you but I’ve left requests on the WP forums and received no responses. You seem to have thought about this a bit so, if possible, I’d like to bat it around with you.
Also running 2.8.5. Interested in what is discussed with Dave, above.
I struggled with this for a long time. I received next to no support from my hosting company (inmotion) and about as little from the WordPress forums. In the end, after trying the above mention solution, I still had similar problems. I dumped inmotion and took my blog to Bluehost. In the several weeks since I have been there I have had no problems at all and am not forced to use some kind of workaround. I am more convinced than ever that the hosting configuration makes all the difference.
That said, WordPress ought to deal with this as it is a long running, unnecessary problem.
Hi,
Can anyone suggest that how can I stop the execution of a cron through page load for a particular plugin not for whole wordpress.
Actually, I want to run cron script through cron job.
I would appreciate your suggestion
I’m having the CPU overload problem as well. Could we just rename wp-cron.php to wp-cron0.php and then set up a cron job in cPanel to run it how ever often we want things updated?
hello I’m new in using woprdpress and I have a problem with my server, they said that my cron job are to much so that CPU work overload, it may be I’m using WP-Robot plug in to scheduled my update post, Could you help m to solve my problem in the simple way such as using plug in? because I don’t understand in coding and some script, thanks in advance..
I used WordPress for a number of years without difficulty. In recent months I’ve started getting daily CPU overload reports from the hosting company I’ve been with all these years. Although I have 30+ blogs on two servers, it’s usually only one blog on each server that’s reported. I thought it was the autoblogging from WPInsider (free WPRobot clone), but I’m getting some reports from blogs that don’t have that.
My impression is the WP developers, due to their silence, don’t care about this problem. I haven’t tried my wp-cron0.php “solution” yet.
My impression is that the WP developers don’t care much about ANY problems they cause by bloating the software. Someone just needs to write something better. (Unfortunately, I lack the skills.) I’d be willing to PAY for something, if it would get me decent support.
Mr Lester. I’m sorry that I can not be of more help. I actually wrote this post a few years ago, when I used word press to build a blog as an internal knowledge base for the company I was working for. We liked it so much they still use it as an external tool for their customers now. Alas, I am no longer with at company as I have moved to North Carolina to be with my wife’s family. I have not touched the back end PHP of a WordPress blog since I left that company almost 2 years ago. These days I spend most of my time crawling around in SQL data bases, fixing user errors.
A wise program I knew from my days back in California made the following observation about WordPress, that I think is very important to always keep in mind. There are only so many things you can track with PHP variables. If you pass an option as a variable, and then base a whole function of a system on that variable, it has better be committed to a database or file if you want to no run into issues latter on. Because WPCron is the way that a lot of the future posts and other functions are controlled, and the values it references are stored PHP variables, WordPress is FORCED to work this way. But it makes for much faster data execution to have thins stored in RAM as variables, rather then hitting the hard disk to read from a file or database.
All in all, I think the WordPress team (who I still love and admire) have made it pretty clear where they stand on this issue: it is working as designed. The only thing that is going to change their mind is to have enough WordPress admins complain and offer SOLUTIONS, not just requests, as to alternative methods. This, I do not have so I will continue to work with what exists and be happy that it is free.
Thanks for the response. My “solution” turned out to be an upgrade of the level of reseller account I had with the company. Since upgrading from “Basic” to “Advanced” there have been no complaints about resource usage.
What if i chmod wp-cron.php to 000? What will this effect be and will it reduce the many requests?
This is blog post saved me hours of time and worry. My site was suspended because of the pesky wp_cron default setting and it’s CPU hog tendencies. Thanks so much for putting so much information together with great references.
[…] https://trinity777.wordpress.com/2008/10/28/wordpress-26-the-issue-of-wp-cronphp/ […]
WordPress Excessive Overloading of Your Server Solving The wp_cron.php Resource Issue said this on November 28, 2010 at 12:44 pm
Very informative post, I appreciate it, i have a wordpress miniclip game site galagamer.com It happens to me ones when my website was down due too resource issue as well. I was in a USA server but my hosting transfer me to other server. This was related to wp_cron.php
[…] is a nice Article written by Trinity which explains wp-cron.php issues! Please check it […]
WordPress 2.6: The issue of “wp-cron.php” said this on April 25, 2011 at 7:22 am
[…] is a nice Article written by Trinity which explains wp-cron.php issues! Please check it […]
WordPress 2.6: The issue of wp-cron.php said this on April 25, 2011 at 7:23 am
Question, is it a good idea to hide /wp-cron.php?doing_wp_cron
in robots.txt; hence a disallow?
I have a problem with wp-cron that I also raised here http://wordpress.stackexchange.com/questions/24211/404-on-running-scheduled-events
Can someone help me?
Very useful thanks Trinity.
I’ve had this problem too this week…very frustrating.
I’ve tried a service from a company called CloudFare which reduces the direct calls on your server by sitting between your server and the readers of your site. Too early to say if it works yet.
Another solution I am planning on trying is the WP Super Cache Plug in for WordPress which turns your pages into static html as often as you tell it to.
Thank you once again…
[…] A very well written article regarding the High CPU usage of wp-cron.php can be found here for your reference: CPU Usage by WP Cron Jobs […]
Blogger Tweaks » Lifesaving Tips to Reduce Website CPU Usage said this on September 27, 2012 at 8:50 am
There are no such lines in wp-cron.php any longer. Perhaps there used to be.
if ( $_GET[‘check’] != wp_hash(’187425′) )
exit;
… or am i el-stupido?
However, the following statement is in wp-cron.php in my current wp version 3.7.1 and is a totally false statement as I have cron disabled by adding this to wp-config.php – define(‘DISABLE_WP_CRON’, true); – because all 200+ sites I admin are screaming fast when cron is disabled and not so much when it is.
* The HTTP request to this file will not slow down the visitor who happens to visit when the cron job is needed to run.
To call wp-cron.php to run 3 times a day I use this actual cron job config for every domain:
10 2,9,16 * * * /usr/bin/wget -q http://www.thedomain.com/wp-cron.php > /dev/null 2>&1
The cron job triggers all schedules except for those associated with wp-supercache. So to overcome the issues with wp-supercache I use this cron job to delete all supercache directory files each night: 8 4 * * * find /home/USERNAME/public_html/wp-content/cache/supercache/ -maxdepth 8 -type f -exec rm -f {} \; > /dev/null 2>&1
and then use the warm-cache plugin along with the required google-sitemap plugin in order to have the deleted cache files all replaced and preloaded each night with this cron job: 30 4 * * * /usr/bin/wget -q http://www.domain.com/?warm_cache=therandomcode > /dev/null 2>&1
The result is screaming Click-BANG sites and cpu and memory usage next to nothing all day long because I schedule out all my preload crons so only a couple of sites are preloading at the same time in the wee hours of the morning.
I only wish the lines mentioned were actually still there as it would be less confusing but I hold hope that WP will deal with the cron issue for real one day as no matter what they say… it crashes monster servers when site’s are being spidered hard by even legitimate multiple spiders at once and that’s a problem that must be avoided.
[…] https://trinity777.wordpress.com/2008/10/28/wordpress-26-the-issue-of-wp-cronphp/ […]
Reducing CPU usage for WordPress users! | Technogeeks said this on February 11, 2015 at 11:03 pm