WordPress fast page updates. At last.
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?
le 27 April 2010 à 18:11 h
If your problem is regenerating the rewrite rules then maybe you should change your permalink structure so it includes the id before the name . This way wordpress would not have to generate a rewrite rule for each page/post
le 28 April 2010 à 9:33 h
@Mihai:
The problem is not about regular posts, where you can have the post id somewhere in the URL. The problem is uniquely with hierarchical pages, as I stressed. In the case of a hierarchical page url structure based on the page names, there is no practical way you can include the page id in the URL. In this case, the plugin is a huge time saver. I couldn’t do without it on a 1200 page blog. Changing the permalink structure of an existing big site is impractical anyway because of SEO issues.
le 2 April 2011 à 16:21 h
Hi, I discovered this plugin while searching for an answer to the verbose page rules problem. Since then I’ve found that when working with pages, WP 3.1 will maintain “pretty” permalinks in the form of parentname/childname/etc. even when the permalinks are set to a mode which does not invoke verbose page rules ( such as /%post_id%/%postname%/ ).
This appears to have the interesting effect of letting a site with mainly or all pages run with the most minimal and efficient set of page rules. While I only have 250 pages on my prototype site at the moment, I noticed a significant speed increase once I switched to the permalink rule above. Best of all, the page permalinks are exactly the same as they were before the switch (don’t ask me why, but I’ll gladly take it :).
le 5 April 2011 à 0:42 h
@Dains: I’m not sure I understood it all. Do you mean WP3.1 is more efficient in dealing with numerous pages? In my experience, there has alas been almost no difference when switching over, and I can still easily hang my server by just adding or moving a page. I still have this crazy behaviour of regenerating rules for all pages all the time, with one rule per page. So my plugin is still necessary to be able to change the content of a page without hanging the server… If you have any hint on preventing verbose rules regeneration, I’ll gladly take it.
le 5 April 2011 à 5:52 h
I don’t know if it’s specific to WP 3.1, but my development installation is keeping the page permalinks “pretty” while using /%post_id%/%postname%/ as the custom permalink setting. (example 4th-level page – http://cdmnplan.theopscompany.com/buddypress-default-theme-site-map/4-groups-directory/4-3-group/4-3-1-home/). So it’s actually using the page slugs as permalinks, and not what I enter in the permalink settings.
The verbose page rules setting shows as OFF using the AskApache RewriteRules Viewer plugin, and it was most definitely ON before I made the change to /%post_id%/%postname%/. Also, the almost 3000 page rules for both page_rewrite and wp_rewrite all disappeared – I now have a dozen page rewrite rules and around 35 wp_rewrite rules for 250 pages.
So I thought I’d drop you a note and see if the information helped you any. I’m sure that changing the permalink structure will give you different post permalinks, so I don’t know what the impact would be on posts for you. I am planning very limited post use, and that delivered by custom page templates, so I am fortunate to have no concern for their permalinks
le 15 April 2011 à 0:50 h
Actually the permalinks settings are only for the posts. The pages always use the url/parent/child name and structure, whatever you put in the permalinks options.
The problem only exists when you have:
1) A lot of pages AND
2) Your permalinks for the posts (even if you have only one post) starts with a fixed name (“blog” or “news”) or with %category or with %posttitle.
if you use any of the precooked permalinks versions (%date etc),then no extra rules will be created as WP knows how to get to your page.
So the problem is the permalinks setting for posts combined with a large number of pages.
There is some TRAC activity about this, search for ‘Verbose rewrite rules’ etc.
Thanks for the plugin, cheers, Harry
le 15 April 2011 à 9:42 h
@Harry:
Yes you are perfectly right, and that has been the situation for a while: nothing has changed with later versions of WP. My plugin is still useful because it prevents re-generation of all the verbose rules when you are merely changing the content of a page (so no need to re-generate all the URLs). As for preventing verbose rules at all, I confirm that permalinks starting with date or post ID avoid the problem. But some sites just don’t want that kind of permalinks, or don’t want to change. There is still space for improvements in the way WP generates rewrite rules: I don’t see a reason why permalinks starting with a fixed word should imply verbose rewrites, for example.
le 17 May 2011 à 9:11 h
Quick question I’d like clarification on… Will this plugin only speed up PAGE modification – or POST modifications as well?
My site only has a few PAGES (maybe 20), but over 10,000 POSTS.
Also – when you say “backup your files,” can you be a bit clearer about WHICH ONES to backup?
I’d love to speed up the time it takes to save, update posts on my site.
Thanks for your help!
le 17 May 2011 à 9:38 h
It only speeds up page modification on sites with lots of pages and specific permalink that generate “verbose rules”. Increase in speed for posts is usually only marginal, and again only applies if you have the verbose rules problem. As for backup, it is the database that you should backup.
le 17 May 2011 à 10:25 h
Thank you for your clarification!