Tired of waiting forever for this single-coma change on a WordPress hierarchical page to finish saving? – Relief is coming your way. In the form of a simple plugin. Just download it, enable it, and now you can rediscover how it is like managing the content of hundred-pages CMS blogs with pretty permalinks in a few seconds instead of minutes.
The problem has been long known, and a turnaround had even been designed into the core post updating function of WordPress to cover the problem of bulk page imports: a constant (aka ‘WP_IMPORTING’) could be enabled to bypass the rewrite-rules regeneration for each post. Making it technically possible to loop through the import of a few hundred pages automatically without having to wait for years if you so wanted (useful when migrating blogs for example).
But once the pages were imported in the database, you were still stuck with a very slow system whenever you wanted to change anything inside a page’s content. Or, as Patchlog puts it: “Even if we can solve the bulk import problem by calling flush_rules at the end , we end up with a blog with thousands of pages where trying to publish a new post manually might take 30 or more seconds.”
In the case of my Nogent Citoyen local community site, with 1000+ articles and 1250 pages, it usually took 1 to 3 minutes to make any kind of change to an existing page. During that time, the server load would usually leap into the two-figures digits, and the site would come to a halt, with Apache connexion slots piling up while the MySql database would perform its trick of a few thousand queries just to check up every single post’s url once again. More than once, the Apache server would simply have to be restarded, unable to recover after a few consecutive page content changes. Reaching the 1200 pages barrier, content management became altogether impossible because the server would usually reach the max execution time of either PHP or MySql before the update was completed.
Having checked the WP trac listings, I found out that the page management slowness of WordPress is a long-knowned and aknowledged problem. I even found a patch that is supposed to improve access time of the page management interface by optimizing the way the core functions loops through the page hierarchy. While this patch is effective on my 2.9.2 system, it does not bring any noticeable improvement to the page update problem.
My site becoming impossible to manage, I first checked that the problem did not come from any of the 50 plugins I use. After desabling everything, there was no noticeable improvement. I then resolved to spend part of my week-end diving inside the core PHP files of WordPress to check out where things went wrong. A few hours spent profiling the post.php functions later, I had confirmed that the problem indeed lay within the _save_post_hook core action hook.
Except in the aforementioned case of the bulk import, this piece of code will launch a full regeneration of all the sites’ rewrite rules whenever a page is created… or updated. Even if the update (involving the post content most of the time) has no chance whatsoever to have modified the url structure of the particular page being saved, nor for that same reason the url structure of the whole site altogether. Keep in mind that a pretty-permalink enabled blog will require around one rule per page, and you’ll understand the MySql hell that I described earlier.
Lucky for me, the _save_post_hook is a short function, easy to rewrite and replace with a version of my own, that first checks wether the page’s name or parent attachment has changed before deciding to launch the flushing of the rewrite rules.
This little quick trick turned out to be so effective (small page updates that took up to 3 minutes now take less than 3 seconds to complete), that I decided to throw it right away into a plugin and share it with the community. Here it is, the YD *FAST* page update plugin, coming your way. For you all big-CMS-like webmasters to enjoy.
Now for the small print: this plugin comes to you as is: deciding to bypass one of the core functions of the WordPress CMS is a bold trick to perform at your own risk. So backup first, test it thoroughly, and if anything goes wrong, just disable the plugin and restore your backed-up content. It works very well for me, but your own mileage may vary.
And oh, to be perfectly honest, I have to mention that this does not solve the problem of page addition or hierarchy changes: if you rename your page slug, move your page around in the page hierarchy, or just create a new page, you will still have to wait a very long time for the permalink structure to regenerate itself. But in my case, that usually happens far less often than small page updates. Optimizing the permalink rules management function would be a far more complicated task. For now, I prefer to leave it to our trustful WP core devs… whenever they find time for it
- Ok great, now what do we replace that silly dropdown 4000 page list with?