Using WordPress as a CMS has some major issues. How we managed to run into every single one. And how ‘pretty’ permalinks can slow down your site. And why we’ve been absent from our blog
This post is a little geeky, and doesn’t have much to do with logos per se, but a little bit of technobabble about our website in general, and WordPress as a CMS (Content Management System) in specific. If that’s not your bag, you should probably skip. If, on the other hand, you’re interested in using WordPress as a CMS platform, you might find it interesting. If you’re in the planning stages of a WordPress installation, it may even save you from making the same mistake that we did, back last summer, in the initial planning stages of our site overhaul.
Fixing content holes.
A couple of posts ago, I told you how the blog would be silent for a few days, due to some basic housecleaning chores that needed to be addressed. Some content holes in our site proper, left vacant by an overhaul back in November. The reasons for the holes are simple. While some people think that The Logo Factory is a largish design company (if you clicked on that link, the lag time you probably experienced is what this post is all about) it isn’t. There’s only Funkenhammer and me tending to the entire website (so that designers at the shop can focus on designing logos, and administration staff can concentrate on, well, administrating). Between the two of us, we only have four hands, and 48 hours a day, so we try to get to stuff as we can, client work and other tasks notwithstanding.
WordPress file naming.
Truth to tell, we didn’t even want to launch in November, but file naming conventions in WordPress had forced our hand, as half the site wouldn’t have worked when we moved to our new server (which we were doing at the same time).WordPress allows you to use what it refers to as ‘pretty’ links when naming pages. That means a page to do with stationery design can be addressed as “stationery-design/” and a page about business cards can feature the address “stationery-design/business-cards/“. All very nice and organized. Pretty too (hence the name). Trouble is, WordPress has a real hard time with these kind of links, especially if there’s any files that have similar names. Say there was an image with the file name “stationery-design.jpg” on the server as well. If you’re using WordPress pretty links, the software will freak out, not knowing which file is which, and eventually give up. Same thing for stationery-design.html. Or stationery-design.php. As we had lots of similarly named files and images (not terribly surprising considering our logo design niche), when we moved to our new server, and fired up WordPress for our new pages, the old pages blew it up. We couldn’t run the old version AND the new version simultaneously as originally planned (slowly converting over), so if we wanted to build the new site, we’d have to nuke the old. And launch before we were ready, holes and all. Which brings up to tip number one. Never move servers AND radically change your website at the same time. You’ll run into all sorts of unforeseen issues, especially when you’re changing basic HTML pages into a CMS driven site. Sometimes the files won’t play nice together.
In any case, once we had removed and 301’d the old files (a 301 redirect is server script that sends visitors to a new version of a page), everything was cool. Our new souped-up server worked blisteringly fast, WordPress was serving up pages nicely. We’d get to those empty holes as time permitted, and hoped visitors would understand. Fast forward to a few weeks ago, when we decided to fill those holes with lots of lovely stuff.
WordPress pretty permalink performance issues.
“For performance reasons, it is not a good idea to start your permalink structure with the category, tag, author, or postname fields. The reason is that these are text fields, and using them at the beginning of your permalink structure it takes more time for WordPress to distinguish your Post URLs from Page URLs (which always use the text “page slug” as the URL), and to compensate, WordPress stores a lot of extra information in its database (so much that sites with lots of Pages have experienced difficulties). So, it is best to start your permalink structure with a numeric field, such as the year or post ID.”
Turns out we’ve set up our top site in a way that’s almost guaranteed to cause site performance issues and give our server conniptions. While we originally thought the slow response time may have been a hardware issue (despite our server being ‘state-of-the-art’) turns out if our box wasn’t performing so quickly, our pages probably wouldn’t load at all. And while we were fine in the months since the launch (the number of pages is one of the determining factors) once we hit the ‘wall’ (about 150 pages if memory serves) WordPress started having issues. On a slower server, or co-hosted locations, this ‘wall’ would be dramatically lower. The quick fix? There isn’t one (at least, not that we know of). Luckily, most of our server intensive pages (our Showroom and logo design gallery for examples) are standalone pages, outside the WordPress ‘loop’ and don’t suffer much in the way of performance issues. Pages that are in the WordPress ‘loop’ (our logo design articles for example) do. And there’s not a lot we can do about it inside WordPress (even the upcoming 3.0 release probably won’t fix this issue). We can fix it outside WordPress, by changing some of our static pages to .PHP versions and carefully constructing a site hierarchy that matches the one built with ‘pretty permalinks’. In order to avoid file naming problems mentioned earlier, we’ll have to delete the WordPress generated versions from the database. As this removes most of the CMS editing function entirely, It isn’t the best solution, but it will work in a pinch. Alas, this too will take a bit of time so visitors can expect periodic site performance issues in the meantime.
Pretty permalinks for SEO?
By the way, we’re not the only site that’s experiencing these issues. According to what I read on a ton of WordPress tech blogs and forums, there’s lots an lots of others. Here’s something I found extremely interesting too. When researching the WordPress ‘pretty’ permalink issue, I ran into a lot of WordPress SEO experts and self-proclaimed Gurus who were recommending that people set up their sites exactly the way that we did. For the SEO benefits obtained with keyword laden pretty permalinks. And while it’s probably true that ‘pretty’ permalinks have some SEO benefits, due to their organized structure and keyword relevance, anyone that follows that advice will probably have the exact same performance issues that we’re having (depending on the number of pages as well as your server horsepower). Are the SEO benefits worth the risk of performance and speed hit you’ll take? I guess that all depends on your perspective (read our SEO for logo designers for my perspective on search engine optimization). I also found this great read which tackles the subject and suggests that SEO experts are giving the wrong advice regarding permalinks, going as far as calling anyone that recommends using them ‘irresponsible’. While the post was published last year, it sums up our issue perfectly, and there was a healthy debate in the comment section, as blog and site owners argued the value of permalinks in SEO, versus the performance issue they cause. I guess it could go either way, but I do know this.
I wish I had found this article before we started planning our site last August.
Here’s another issue with WordPress pretty permalinks. Due to the number of server calls required to assemble a page, if you get a spike in traffic, your server resources and processes will quickly get eaten up. That happened to us late Monday afternoon, when a sudden rush of site traffic took down our server, even though it should be robust enough to handle it. On a less robust box, a site wouldn’t last as long as ours valiantly tried to. Taking a look at the WP database, under the WP_options table, the server is throwing tons of errors and trying to write a massive file on every single page view. It’s surprising the site is serving at all.
Some of our hard-coded .PHP pages (our design help center for example) featured relative links to WordPress pages without any trailing slashes (“logo-design-articles/7-golden-rules-of-logos” for example). This was giving WordPress a little more work to do as it tried to figure out where the page is. By turning this into an absolute URL (“http://www.thelogofactory.com/logo-design-articles/7-golden-rules-of-logos/“) and added the trailing slash, it decreased server response time significantly. Still far from perfect, but a little better. Overall, we’re still treading water.
After ten days of buggering about, all fixed now. I’m too wiped to write about it at the moment.
Here’s the short & skinny of this. If you’re using a WordPress CMS setup using ‘pages’ only, DO NOT set up your permalink structure as “%category%/%post_name%” even if you’re not going to publish a blog portion. Pick anything else. You don’t need the pretty link setups (pages do that by default). That’s doubly true if you are planning a blog using ‘posts’. We took a look at some of the database errors from the WP_Options table and they’re so big, they even crashed Microsoft Word when we tried to open them. These errors are thrown on every single page call and get progressively larger the more pages you add to your site.
[Footnote: This article was originally posted on our (now) Legacy Blog and moved to its current location for consistency and database functionality. While it was accurate at the time of publication, it is currently posted as part of our historical record and details may have changed.]