Jumping through WordPress hoops
Hi. This is my first post here as a new employee of Substrakt so you’re entirely forgiven if you have no idea who I am. I better introduce myself I guess.
I’m Chris, I’m a web developer and although I’m trying to shake the label of ‘geek’ it pretty much sums up what I do. Not an easy thing considering the remainder of this post.
For those of you not interested in codey stuff I’ll see you in my next post. For the few still reading, I’ll be talking about WordPress clean urls.
I’ve been having a bit of a headache with WordPress this week as it kept killing a server. I think I have finally cracked it but even if this isn’t the root cause, it’s something that really needs to be addressed.
It boils down to the structure of the urls for the posts. The standard ‘clean’ url that is used is something like this: http://www.example.com/2010/08/06/some-post-name which is fine for blogs and other date based posts.
Unfortunately not all sites built with WordPress are designed to be blogs. Some are general corporate sites, some are ecommerce led. These and many more WordPress based sites would do well to have a url similar to this: http://www.example.com/some-post-name
This has some serious repercussions on speed though. I’m testing this on a site with 590 posts in the wp_posts table. Only 143 of these are published posts. The rest are drafts.
I split the serialised version of the rewrite rules by semi-colons to get a measure of how big it is in human terms. The first url version with all the dates in works out at about 144 lines of data. The second version which is simpler for a person to write but harder to check for takes up about 2270 lines.
That’s a lot more data to parse and hold in memory. I’m working on an elegant solution to this problem but right now and for the sake of the server, it’s date based urls all the way.
Apologies to our client for not spotting this sooner but hopefully this post will help someone else with a similar problem quicker than it took me to find the culprit.