I have just gone through more time than I care to admit upgrading to version 2.2 of WordPress. I did this not only because the WP developers have signaled their intent to abandon 2.1 with a more formal upgrade and release schedule. I also did it because I was beginning — with site and user growth — to experience some noticeable performance issues. And, I also wanted to give the site its second-year anniversary tune-up.
Since I had upgraded about four previous times in the past two years (my earlier and popular Professional Blogging Guide was written for version 1.5 of WP), I pretty much assumed this next upgrade would also be generally smooth. Boy, was I wrong!
This whole experience, though not completely disillusioning, does raise some real questions and concerns. Likely some of it has to do with my own stupidity or neglect or the fact I am not a system admin. But those same factors apply to the majority of WordPress users that administer their own sites as well. If you fit in this category, Watch out! You may be sailing unawares into a perfect storm.
Just for reference, I have a virtual dedicated (private) server (VPS) with 256 MB of RAM burstable to 1 GB. I’m running Linux CentOS 4, Apache 2.0.52, MySQL 4.1.20 and PHP 4.3.9. In other words, my VPS is a fairly typical LAMP installation. My VPS plan provides no support, but I do have a Simple Control Panel (Turbopanel), though most of my management occurs through SSH. Disk space and bandwidth are not issues, though I sometimes suspect those sharing the server are resource hogs (doesn’t everyone with a VPS suspect so?; at least it is not a standard hosting arrangement!).
As with past upgrades, the instructions for upgrading WordPress have become fairly standard. You can download WordPress version 2.2 from here and the WordPress folks offer pretty clear initial installation and upgrade guides. Read these and follow them.
If upgrading, it is critical that you backup your database and backup your relevant site changes (including theme changes and plug-ins) before attempting any installation.
(Though I personally did not have to resort to a full restore when I encountered the problems noted below, it was close. And, in any event, if you are able to put up with some downtime, even if everything goes to hell in an basket, you can still get back to your original configuration. Back up!).
The actual process of upgrading went pretty smooth for me. Physically copying files and getting the site to come back up wasn’t the problem. The problems arose in how the site (mis)behaved after the upgrade.
For many reasons related to (a perhaps too-long list of plug-ins) I had no end of problems with this WordPress v. 2.2 upgrade. Here are the key ones I discovered:
More on some of these points is expanded upon below. A very helpful compilation of WordPress v. 2.2 issues and tips and resources is provided by the Blog Herald.
Now, I somewhat violated one of my personal cardinal rules for WordPress by upgrading at a single sub-version number. (I actually don’t understand or track the rationale for WordPress version upgrades; 2.2 was huge, as was 2.1, seemingly as great as the transition from 1.x to 2.x!). Somehow, however, I had the impression that 2.2 was a simple increment over 2.1, which did have a number of sub-sub releases. I did, however, wait a couple of weeks after initial release.
I suspect there will be a 2.2.1 release very soon, because the scope of issues that are emerging are pretty big. One source of new fixes will be hosting providers; I’m sure they are seeing some pretty bad stuff recently. I’d hate to own a hosting service at the moment with many WP users and have to both field their calls and wonder what the heck I have to do with my current server infrastructure to get all of my users back up to snuff!
If you don’t have to upgrade immediately, my advice would be to wait. There is quite a bit that needs to settle down, and some of the plug-in developers I believe have some big efforts ahead getting their stuff stable again.
When all hell breaks loose and panic takes hold, it is easy to loose perspective. Plugging holes in the dike, while potentially effective, can also divert and exhaust from identifying and then diagnosing real root causes.
Truthfully, I don’t understand at all with documentation, code forums, and hundreds of thousands of WordPress Google results why it is so difficult to get authoritative answers to many questions and problems. Moreover, hosted sites versus self-administered ones and dedicated v. virtual v. shared servers all have different needs and configuration options.
So, let me add to the general background noise . . . .
There is a page on the WordPress site that lists known working and non-working plug-ins for version 2.2. While useful, this list is incomplete.
I followed the general advice of individually re-activating and testing each plug-in after the upgrade. However, because of caching issues and general load problems due to using internal Feedburner scripts, some of my testing may have indicated a plug-in was not working when it was these interaction effects that are the problem. With a starting roster of about 25 plug-ins (see figure), the potential interactive and combinatorial effects are huge!
In my testing, I believe these plug-ins to not be compatible with WP v. 2.2: Advanced WYSIWYG, COinS Metadata Exposer, Customizable Post Listings, EzStatic, Kimili Flash Embed, Most Popular posts, and Smart Archives.
I strongly suspect these plug-ins are not working properly, and have de-activated in any case: ImageManager, Popularity Contest, Post Teaser, Spam Karma 2 (WP site indicates it is OK, but see below), StatTraq, and wp-cache.
This is more than half of my initial plug-ins that showed likely problems. As the figure above shows, I am now only using eight plug-ins, one of which is new that I updated myself (the Advanced TinyMCE Editor, discussed in an upcoming posting).
Of course, I could be wrong on any of these plug-ins due to the testing and combinatorial challenges noted above. I do not mean to impugn any individual plug-in. Indeed, I installed them initially because I perceived them to provide value. So, if I have erred in my assessment, I apologize in advance. But no matter how measured, compatibility is a real concern.
There has been discussion for some time regarding the impact of the number of plug-ins on WordPress performance. For example, a listing in early 2007 from Alex King’s blog seems to have the largest nucleus of discussion. The earlier consensus was that too many plug-ins may be an issue, but 30 or so were OK. (Naturally, some plug-ins are more resource-intensive than others.)
Frankly, up until now, I really had not given the question much thought. I would encounter what looked to be a useful functional addition, install and activate the plug-in, and go on my merry way.
The tip off that something might not be right arose when my chronological listing of posts broke after the upgrade. My first iteration of this page used the wp_get_archives function, often used for archive listings in sidebars of WP blogs. (I later used the Customizable Post Listings, which is a very nice one, but it is broken in 2.2.)
What I stumbled upon late in my upgrade testing was the observation that as more plug-ins were added to my system, the number of listed archive postings would decrease (also losing the footer). Under conditions of too many plug-ins, the entire page would go blank.
It was total serendipity seeing this behavior, and only occurred after much hair pulling and gnashing of teeth as to why seemingly OK plug-ins individually or in small combinations worked fine, but when all invoked worked to trash the site.
I suspect some big bug resides somewhere in the system related to resource use. My temporary fix has been to set an absolute limit in the ‘postbypost’ parameter in the function that is well below my actual total post counts. Go figure.
When everything appears to be broken no stone goes unquestioned or unturned. Because of their complexity, I spent considerable time looking at my statistics and spam plug-ins.
One possible cause for degrading site performance was a rapidly growing database. I had been getting complaints from users regarding slow load times in the past couple of months. I really did not want to bite the MySQL optimization bullet and tuning, but could avoid it no longer.
The first thing I had noticed was that my MySQL database had more than doubled in size in six months to 368 MBs! (43.5 MB zipped). I knew I was writing some long posts, but that seemed ridiculous.
So, while I had been faithfully backing up my site, I tended to avoid probing into MySQL. Faced with the unavoidable, I happened to notice, however, that 280 MB, or 75%! of my database size was due to storage of StatTraq statistics. (I know, you idiot, why didn’t I see this sooner?) I was blown away about how this silent accumulator had become the eggplant eating MySQL due to my inattentiveness.
While I had earlier looked into StatTraq speedups thinking that might be a cause of some of my performance issues, I frankly was shocked at the resource demands of this application. In fact, the only reason I had installed the application in the first place was in order to extract the minute amount of data for providing a popularity listing of prior posts in my sidebar. This was the result of an early decision when I first set up my blog and one I had not questioned or re-considered since.
That raises the broader question of why embed stats in your internal blog? You can get the same basic tracking and statistics from Google, Feedburner, Sitemeter, Stat Counter, your own internal Webalizer on most virtual servers, etc. Now, with experience and reflection, it is absolutely crazy to burden WP and MySQL further when such services can so easily and freely be obtained elsewhere.
I still liked the idea of a popular posts listing, and tried a couple of alternatives, including Alex King’s Popularity Contest. However, once I saw that these systems, too, added tables to MySQL, I decided to swear off the sweets and let go of being enamored with popularity listings.
So, with the removal of internal stats, my database reduced to a more manageable 80 MB (7.5 MB zipped).
Now on the war path for insidious MySQL sneaks, I next looked into Spam Karma 2. Actually, this plug-in has performed great for me, but again, it is complicated and writes considerable data to MySQL. In fact, even with new trimmed database, SK2 was occupying about 25% of total database space!
I presently have SK2 disabled, and am getting surprisingly good spam control with the simple use of the Comment Timeout. It seems to take some time for spammers to harvest new posting listings, so, if you are not a comment heavy site (as is the case for this AI3 blog), then timing out comments on older postings looks to be quite effective with not nearly so much overhead.
I haven’t yet removed SK2 tables, and may choose to re-activate it again in the future. But I am definitely now in the mood to question the operating profiles of statistics and spam plug-ins.
In the past week, I’ve researched and tested Apache server settings, MySQL queue caching, WP internal caching, external caching plug-ins (WP-Cache 2) and PHP opcode caches, alone and in combination.
Truth be told, despite coming across a few guides that appeared authoritative, I’m not sure that all systems work well with WP v 2.2, some definitely have issues (WP-Cache 2), combinations can produce race conditions, and, in general, nothing feels stable enough at present to use. I will likely need to await 2.2.6 with specific announcements of compatibility made by specific cache mechanisms before I try using them again.
Of course, the 256 MB of RAM item above should have caught most everyone’s attention. I know my current RAM is at the bare minimum, and perhaps most of the issues I’ve flogged in this post could be solved in a rich RAM environment.
I will look into this issue, but I’m also cheap, cheap. So, RAM and support and a host of considerations will go into any future hosting provider changes. Who knows, I might even choose to host myself?
(Actually, I need to get back to work. After the experience of the past week, I’m itching to let my blog site run as configured for quite a while before I attempt any major new changes, let alone migrating to another provider!)
A posting later this week will address this topic further.
I still (painfully) remember my transition from WordPerfect to MS Word, necessitated by market and technology shifts. But I loved WordPerfect and knew how to make it sing. I’m sure I’m not as proficient with WordPress, but I have come to understand and work around its quirks sufficient to be pretty productive. Yet, based on current trends, I’m fearful those days may be coming to an end.
There is an overarching set of issues behind the WP project that is starting to become apparent to me. Though I have used and recommended the system for two years, and have written one of the popular guides about how to roll your own professional WP blog site, here are those troubling trends and gaps I am seeing:
Granted, perhaps it is unfair to compare WP with Mozilla and its installed base of perhaps 100-fold more users. Yet, on the other hand, WP has been around for quite some time and has millions of its own users.
Without a doubt, most would observe (and I would agree) that some of the upgrade difficulties covered in this article were of my own doing. Add a plug-in here, one there, keep blogging, and only occasionally dig out those reference sheets with the hidden steps, logins and passwords to speak with such things as MySQL, phpMyAdmin, Apache, “root” Linux access and the rest. Guilty as charged.
Yet, on the other hand, writing and maintaining a blog is a means — not an end — for me. Sure, I can learn this stuff, spend the time, and even blog about it on occasion. But that is not my daily focus or passion.
It is one thing to set up a blog, try a few posts, and then move on. Literally millions of people have done so.
Yet there are also many hundreds of thousands of content-rich sites that have become more-or-less permanent and often destinations in their own right. As the space matures, so must the platforms upon which it is based. I hope that WordPress will continue to be that choice for me, but some key structural work on its foundation is well in order.
An annual birthday is time to take some stock, and to do some tuning up. This week it was my blog’s turn. A subsequent post will report on that (painful) experience. I gave a general spit polish to the ol’ site to say thanks! and Happy 2nd Birthday!
The actual birth date of this site is May 27, 2005. In the two ensuing years, I have posted 208 articles, most quite long. Over the past 12 months, I posted 100 articles, unveiled my SweetSearch Google custom search engine for the semantic Web, and unveiled and grew the Sweet Tools listing of 500+ semantic Web and related tools listing. I added multiple language translation (and then removed it when Google announced its own service!) and began testing Google ads.
My site popularity has continued to climb; AI3 is now ranked about 45,000 on Technorati (it was about 100,000 on the site’s first birthday), pretty good for a site mostly focused on technical issues of Internet content and the structured Web, and I get good commentary both on my blog and around the Web.
Thanks, everyone, for your kind words and support!
So, all in all, this blog’s toddling year was a good one. Now that we’re walking, perhaps some running and jumping in the coming year will be in order!