Chapter in this post:
Today I had the case again that I had a customer's WordPress site that ran agonizingly slow despite being hosted on a "managed server". When calling the WP-Admin you could see that he repeatedly accessed the wp-cron.php file and the admin pages sometimes took between 30 seconds and 2 minutes to open. The memory requirement was also quite high with over 200 MB RAM. All indications that something was not going quite well.
WP Cron is a kind of internal cron job that WordPress uses to carry out regular cleaning tasks and to run administrative scripts. In the case of WordPress sites that have few visitors, it can happen that WordPress cannot run the cron jobs often enough due to the few tasks. In most cases, however, this is rarely the case, as there are only a few regular tasks in the WP cron list. These are then already done when you call up the WP admin area.
My suspicion was that WordPress has to process a lot of cron jobs in the background, which are then always done when the admin is called normally. Now WordPress itself does not offer the possibility to view this list of the cron events, but with the plugin "WP-Crontrol"You get a list in the admin area that gives you information about the individual tasks that are currently still in the WP-Cron's queue. This looks like this, for example:
In the case of the extremely slow WordPress installation, there were over 40.000 entries in the list that were generated by the "Huge-IT-Gallery" plugin and that were also steadily more instead of less. The WP-Crontrol plug-in offers a list of all the cron events and you can also delete them individually using a button, but with over 40.000 entries a "more comprehensive" solution had to be found.
Fortunately, the Internet offers a wide range of information options and so I came across the command »delete_option ('cron');«, which deletes all entries in the wp_options table that match the "cron" area.
This will delete all existing cron events that WordPress currently has in the queue in one fell swoop. In order for the command to be executed, you have to include it in the "functions.php" file in the theme. Then call up any WordPress page in the frontend and then delete the line again. If the theme does not have a "functions.php" file, you can copy it into the headerphp, footer.php or other files that are executed when the WordPress site is called up.
Now that all cron events had been deleted, WordPress ran really fast again. To check I looked again at the list of cron events with WP-Crontrol and saw that new entries from the Huge-IT-Gallery plugin are constantly being added. It would be just a matter of time before everything slows down again.
Since the plugin was still needed, I just looked for the string "cron" in the plugin's source code and commented out the corresponding lines that ensured that new cron events were created for WP-Cron. So the WordPress installation is now permanently cleaned up and nice, fast.
[sc name = "WordPress Help"]
Jens has been running the blog since 2012. He appears as Sir Apfelot for his readers and helps them with problems of a technical nature. In his free time he drives electric unicycles, takes photos (preferably with his iPhone, of course), climbs around in the Hessian mountains or hikes with the family. His articles deal with Apple products, news from the world of drones or solutions for current bugs.