It’s a fairly straight-forward upgrade, just some file copies. It took me longer to verify the backups than to do the actual upgrade. I didn’t have any plugin compatibility or other problems and found this line from the announcement to be true:

2.6 is pretty much identical to 2.5 from a plugin and theme compatibility point of view, so upgrades from 2.5 should be pretty painless.

I haven’t looked specifically at the new features yet, but everything seems to be working fine. There was talk of turning remote publishing via XML-RPC and APP off by default. This is true for new installs but in my case it stayed enabled during the upgrade and I didn’t have to do anything to re-enable Windows Live Writer posting - it just worked.

Earlier in the week I made sure all my plugins were at the latest version so I wouldn’t have to worry about them during the actual upgrade. Except for the Popularity Contest plugin they all worked under WordPress 2.3.x and WordPress 2.5.

The one plugin that I had to change for WordPress 2.5. (and 2.5.1) was Popularity Contest. I used the instructions found at Blogvaria for the minor modifications. Following the link for full details but the short version is to change line 59 from require('../../wp-blog-header.php'); to require('../wp-blog-header.php');.

I use the Sandbox theme and I’d also have to upgrade it during the upgrade to WordPress 2.5. I modify a couple of the theme’s files so I had also prepared those ahead of time. This was a simple cut and paste.

Once everything was ready I did another set of backups and enabled the Maintenance Mode plugin to block traffic to the site. I then deactivated all the other plugins and started the upgrade and followed the regular WordPress upgrade instructions. Once the WordPress files were copied I copied the new theme files and the updated Popularity Contest plugin before running the WordPress upgrade script to upgrade the database. Once that was done I enabled all the plugins one at a time to make sure they started OK.

The entire upgrade took less than 30 minutes and I didn’t get burned by testing on WordPress 2.5.0 and upgrading to WordPress 2.5.1.

The update was unexpectedly smooth. I expected some plugin problems but only had one. Here’s my experience and impressions so far:

• The one plugin problem I had was with Popularity Contest. It was listed as compatible but I had a fatal error when starting it after the upgrade. A Google search showed I wasn’t alone and someone had already resolved the problem. Thomas at Blogvaria published a solution. The problem occurs with Popularity Contest 1.3b3. The core of the fix is:

Open popularity-contest.php and scroll down to line 59. Replace require(’../../wp-blog-header.php’); with require(’../wp-blog-header.php’);

• I use the Sandbox Theme and noticed that Sandbox 1.5.1 was released for WordPress 2.5 so I upgraded to that along with WordPress 2.5. This wasn’t so bad since I’d kept editing the theme files to a minimum and had commented those sections. I’d already updated all my plugins to current versions.
• Prior to WordPress 2.5 there was a bug where a post would be cut off in the feed when the "More" tag was used, even if full text feeds were enabled. Since WordPress 2.5 fixes this the the Full Text Feed plugin is no longer needed.
• My widgets were blown away by the upgrade and I had to recreate them.
• The footer on the admin pages still says "You are using a development version (2.5)." even though I downloaded the production release. I hope (and also assume) it’s just an oversight in the code and not that an older version was packaged up.
• I was able to use the built-in editor to compose and edit posts in Safari 3.1 (on a Mac). Earlier versions of WordPress would mess with the formatting, the most noticeable being the removal of line breaks making the post one long paragraph. I typically use Microsoft Live Writer so this isn’t a big issue for me but still a nice change.

The most visible change, and the one that’s most talked about, is the redesign of the admin Dashboard. I haven’t installed any of the beta versions so other than some screenshots it’s all new to me. My first impression is I like it. It’s different so it takes some getting used to, but it’s intuitive. The enhancements to photo editing (Galleries and smart Exif handling) along with the the redesigned compose screens may make browser based editing more attractive.

WordPress 2.5 has made enough of a good impression on me that I may decide to upgrade this site later this weekend rather than waiting until next weekend. So don’t be surprised if the site goes offline for an hour or two this weekend.

More Information:

WordPress.org - Download and information.

Release Announcement - Includes an overview of all the changes.

Screencast of the admin dashboard.

I didn’t do everything that was on the checklist. I did update plug-ins to their latest versions. I also went through and deactivated a couple plug-ins I no longer wanted.

One was the Articles plug-in so I also deleted the articles page. The articles page hadn’t worked right since my last upgrade and I had stopped adding new articles. The complete lack of traffic to the page contributed to my lack of desire to fix it, so it’s gone.

I also deleted the Link Harvest plug-in. It was used to build a link page based on the sites I linked to within my articles. While I liked the idea in concept, I’m not sure it was at all useful in practice. It was another page that saw no traffic so it was easier to delete than worry about in the upgrade and potential redesign.

I had been using Google Analytics to gather site stats. It’s a lot of nice statistics but I almost never viewed them. So I decided to stop using Google Analytics and I deactivated a Google Analytics plug-in.

I had to roll back an upgrade to the HeadSpace2 plug-in I use. HeadSpace2 is a plug-in I use to manage meta-data, mainly tags, After I updated to the latest version (3.3.29) I could no longer manage tags through HeadSpace2. Rather than troubleshoot I just rolled back to my previous working version. I’ll worry about troubleshooting it when I go to WordPress 2.5.  Unless WordPress 2.5 has better tag management HeadSpace2 is critical to me. The tags themselves were unaffected in the post, but none showed up in the meta-data management screen.

I also switched anti-spam plug-ins and went back to Akismet, at least temporarily, and turned off Spam Karma. The change may be temporary. I’m curious to see how Akismet does and since it’s from the WordPress folks it should be problem free with 2.5.

So, I’m as ready as I ever will be for WordPress 2.5.

First I got the category ID numbers for the categories I wanted to exclude. In my case I want to exclude the “Quick Bits” and “Likes & Gripes” categories. The categories are listed in WordPress console on the Manage -> Categories tab. The number I want is in the first column.

The “Likes & Gripes” ID is 229, as shown in the picture to the left. The “Quick Bits” ID is 59. Now, the URL for my full feed is http://www.theosquest.com/index.php?feed=rss2. So, based on the procedures that I found I should be able to use http://www.theosquest.com/index.php?feed=rss2&cat=-59&cat=-229 But like I said, that wasn’t working for me. Only the last category would be excluded, even if I changed the order or added new category.

I was able to tweak the syntax a bit and I found the following syntax works: http://www.theosquest.com/index.php?feed=rss2&cat=-59,-229. This gave me a feed that properly excluded the “Quick Bits” and Likes & “Dislikes” categories.

I use FeedBurner for my feeds and also wanted to have this feed managed through FeedBurner. Configuring this in FeedBurner was as simple as using the working URL as the original feed address.

I’m not sure why the original syntax didn’t work. I found other articles with the same syntax. The articles were about a year old so maybe things are different with the current version. Or maybe there’s some plug-in that makes my WordPress install unique.

If you want to subscribe to this site, either through an rss feed reader or by email you can subscribe to a feed of all content, my newly created articles only feed or any of several other feeds. They’re all listed on my About page.

I didn’t want to kill off the site, I didn’t want to invest the time needed for upgrades, and I didn’t want to spend a lot of time moving the site. So, WordPress.com seemed like the logical choice. They provided a free hosting environment and since I was already using WordPress the migration should be simple.

While the hosting is free I wanted to keep the www.spamchronicles.com address. This is a $10/yr. option.

In looking at WordPress.com I saw three minor problems.

1. The permalink structure of WordPress.com is not configurable and it did not match the permalink structure of my site. I figured links to my site will be broken. I was willing to accept this as the site usually has less than six visitors a day. I ended up being wrong about this and the old URLs where redirected to the correct page and Google search results continued to work.

2. WordPress.com does not allow advertising. I probably had a few affiliate links in my articles that I’d have to hunt down and remove. I didn’t expect this to be very time consuming and in fact only took me less than 15 minutes.

3. The third problem was pictures. Since WordPress.com is a hosted blog I had no access to the file system so I couldn’t just copy the graphic files. I’d have to upload them individually. I didn’t have many files so while this would probably be the most time consuming step it wasn’t unreasonable. This took me less than an hour while I also watched TV.

Move Checklist

The is what I did to move the site:

1. I exported the site (posts, comments, custom fields, tags, categories) using the Export command in the Admin pages of the old site. Export is listed under the manage tab.

This resulted in a xml file being saved to my local drive. There’s a 3MB import limit on WordPress.com, my file was well under that.

2. I turned off the “notify blogs” option in the admin panel (Options -> Discussion) so that any edits I make won’t spam other blogs with duplicate notifications.

2. I opened the XML file in a text editor (I use Smultron). I searched for my affiliate links and either deleted or edited the post on the live site. I also deleted all posts in the SideNotes category on the live site.

3. Once all the updates were done I did a second export to get an updated xml file.

4. I set up the blog at wordpress.com with the name spamchronicles.wordpress.com. Among the configuration changes I made was to also turn off notifications for this blog (same as step 2) so that the import and subsequent edits won’t spam sites with multiple notifications. Then I ran through the options tab in the admin console and set things for my preferences.

5. Once I knew the site was ready I went to my domain manager and set the DNS server to the WordPress.com DNS server (NS1.WORDPRESS.COM, NS2.WORDPRESS.COM, NS3.WORDPRESS.COM). It’s takes awhile for this change to propagate.

6. I imported the xml file from the original site. This added all the posts, comments, tags & categories. Because the old site was still valid in DNS (the DNS server change hadn’t propagated yet) the pictures were still shown. I went through and uploaded/re-pointed the images to the wordpress.com address. This was easy to do since I keep a site backup on my local drive and the backup directory structure was the same.

7. It took a few hours for the DNS change to propagate. Once it did I was able to go into the “Upgrades” tab of the Admin panel and select the domain upgrade. You can’t add the domain until the DNS propagates so you’ll receive an error if it’s too early. Once the DNS propagates I was presented with the steps to spend the $10 and set up the domain. Once it’s set up I have the following screen on the domains tab.

At this point the site is accessible using www.spamchronicles.com and I’m done.

Because the permalink style had changed I had expected the old links to break. But what I found is that they are being redirected. On the original site my article about blocking IntelliTxt adds was at http://www.spamchronicles.com/pop-up-ads/block-intellitxt-ads/ while at the new site it’s at http://spamchronicles.com/2007/04/01/block-intellitxt-ads/. When I click the link in the Google search results it’s properly redirected to the correct page at my new site.

I still have the old sites files and database up so if I had to go back to it all I’d have to do is change the DNS servers back to my old host. But things seem to be going OK so I’ll probably clean up all the old stuff over the weekend and be done with it.

All totaled, it was about 2 hours of actual work and I no longer have to worry about upgrading the site in order to plug vulnerabilities.

I didn’t want to kill off the site, I didn’t want to invest the time needed for upgrades, and I didn’t want to spend a lot of time moving the site. So, WordPress.com seemed like the logical choice. They provided a free hosting environment and since I was already using WordPress the migration should be simple.

While the hosting is free I wanted to keep the www.spamchronicles.com address. This is a $10/yr. option.

In looking at WordPress.com I saw three minor problems.

1. The permalink structure of WordPress.com is not configurable and it did not match the permalink structure of my site. I figured links to my site will be broken. I was willing to accept this as the site usually has less than six visitors a day. I ended up being wrong about this and the old URLs where redirected to the correct page and Google search results continued to work.

2. WordPress.com does not allow advertising. I probably had a few affiliate links in my articles that I’d have to hunt down and remove. I didn’t expect this to be very time consuming and in fact only took me less than 15 minutes.

3. The third problem was pictures. Since WordPress.com is a hosted blog I had no access to the file system so I couldn’t just copy the graphic files. I’d have to upload them individually. I didn’t have many files so while this would probably be the most time consuming step it wasn’t unreasonable. This took me less than an hour while I also watched TV.

Move Checklist

The is what I did to move the site:

1. I exported the site (posts, comments, custom fields, tags, categories) using the Export command in the Admin pages of the old site. Export is listed under the manage tab.

This resulted in a xml file being saved to my local drive. There’s a 3MB import limit on WordPress.com, my file was well under that.

2. I turned off the “notify blogs” option in the admin panel (Options -> Discussion) so that any edits I make won’t spam other blogs with duplicate notifications.

2. I opened the XML file in a text editor (I use Smultron). I searched for my affiliate links and either deleted or edited the post on the live site. I also deleted all posts in the SideNotes category on the live site.

3. Once all the updates were done I did a second export to get an updated xml file.

4. I set up the blog at wordpress.com with the name spamchronicles.wordpress.com. Among the configuration changes I made was to also turn off notifications for this blog (same as step 2) so that the import and subsequent edits won’t spam sites with multiple notifications. Then I ran through the options tab in the admin console and set things for my preferences.

5. Once I knew the site was ready I went to my domain manager and set the DNS server to the WordPress.com DNS server (NS1.WORDPRESS.COM, NS2.WORDPRESS.COM, NS3.WORDPRESS.COM). It’s takes awhile for this change to propagate.

6. I imported the xml file from the original site. This added all the posts, comments, tags & categories. Because the old site was still valid in DNS (the DNS server change hadn’t propagated yet) the pictures were still shown. I went through and uploaded/re-pointed the images to the wordpress.com address. This was easy to do since I keep a site backup on my local drive and the backup directory structure was the same.

7. It took a few hours for the DNS change to propagate. Once it did I was able to go into the “Upgrades” tab of the Admin panel and select the domain upgrade. You can’t add the domain until the DNS propagates so you’ll receive an error if it’s too early. Once the DNS propagates I was presented with the steps to spend the $10 and set up the domain. Once it’s set up I have the following screen on the domains tab.

At this point the site is accessible using www.spamchronicles.com and I’m done.

Because the permalink style had changed I had expected the old links to break. But what I found is that they are being redirected. On the original site my article about blocking IntelliTxt adds was at http://www.spamchronicles.com/pop-up-ads/block-intellitxt-ads/ while at the new site it’s at http://spamchronicles.com/2007/04/01/block-intellitxt-ads/. When I click the link in the Google search results it’s properly redirected to the correct page at my new site.

I still have the old sites files and database up so if I had to go back to it all I’d have to do is change the DNS servers back to my old host. But things seem to be going OK so I’ll probably clean up all the old stuff over the weekend and be done with it.

All totaled, it was about 2 hours of actual work and I no longer have to worry about upgrading the site in order to plug vulnerabilities.

This version will also suppress some DB error messages to avoid giving out to much information. The error messages will still be displayed if debug mode is enabled. Details on all the changes can be found at Westi on WordPress.

The update was released on the 29th and I got around to installing it this past weekend, along with updating numerous plug-ins. The update wasn’t too tough but mainly because I assumed things would work OK and didn’t do too much testing. I had seven plug-ins to update, although only five were actually in use. Against common sense I updated all the plug-ins and WordPress itself on my test site without doing a backup first. I replaced all the WordPress files rather than picking out the 16 that changed. There weren’t any DB changes but I ran upgrade.php on my test site just to be sure and was told there weren’t any DB changes.

Updating the regular site was just a matter of copying the new WordPress and plug-in files up to the new site. But in this case I did do backups first.

WordPress Update Notifications

With WordPress 2.3 notification about updates began to be included in the admin panel. If WordPress itself needs to be upgraded there a message along the top of the admin panel and down on the footer too. This makes it nice to not have to go looking for updates on a regular basis even if it doesn’t alleviate the annoyance of the moment when an unexpected update notification pops up. The plug-in page also displays info on plug-ins that are out of date, although this requires the plug-in to be hosted in WordPress.org’s plug-in library.

Some plug-ins don’t provide very much information about the update so it’s hard to know if it’s worth the update. I’ve avoided updating just because it says there’s a plug-in update. Instead I tend to group them together for when I have time or when I need to install a security related update (like this time). Some plug-ins can update frequently like the one that was updated twice (at least) this month. I found that out when the update I had download two days previously was out of date when I applied it.

There’s also been other little things that make doing update easier, like a link to deactivate all plug-ins at once.

WordPress Anti-Spam

The Akismet anti-spam plug-in is included with WordPress and it’s probably what most people use. It’s free (for non-commercial use on blogs that make less than $500/mth) so that’s a plus. The actual spam detection process occurs on Akismet’s. This means your server doesn’t have to handle the processing which could be a benefit. But it does mean that it the Akismet servers are busy your comments may not be processed and spam may get through. Paid Akismet users do get priority. Another benefit, at least in theory, is that Akismet can take the knowledge learned as it processed comments for spam and help everyone. I used it at first and have to say it worked well but did let some stuff through, especially trackback spam.

I started using Spam Karma 2 back in October and it’s worked almost flawlessly. I seem to recall a comment/trackback or two getting through but can’t remember anything specific. I also can’t recall it eating any legit comments. While the ability to tweak the settings is nearly endless I pretty much stuck to the defaults. The plug-in was just updated in May and the author recently announced another update is pending. But then he says:

This will also likely be the last update to Spam Karma (which should still give us all quite a few months respite from spam). Barring any unforeseeable circumstances, there will be no more compatibility update to try and keep up with Wordpress’ habit of breaking compatibility with each of their [numerous] releases. Furthermore, there is increasingly little point in “competing” against Akismet, when it is bundled and marketed as the principal Wordpress antispam tool (even if I personally do not like its approach).

It’s probably an unfair comment, but the bundling of Akismet reminds me of the bundling of IE with Windows. (But Akismet is a plugin so easily avoided, unlike IE) Still, Spam Karma 2 will work for the foreseeable future, hopefully through the next couple of WordPress upgrade cycles.

Dozens of other spam tools are available through the WordPress codex.

EMail Address Harvesting

There are several plug-ins available to protect email addresses from being harvested from WordPress. For awhile I used the email immunizer plug-in and this seemed to work well. This allows email addresses to be specified normally and they can be read by humans but put in their HTML equivalents for spam bots. But if the plug-in breaks or stops working the addresses will also appear in plain text for the bots. I stopped using this simply to reduce the number of plug-ins I used. There are several similar plug-ins at the previous spam tools link.

Backups

As with any security measures backups of data have to be included.

The WordPress Database Backup plugin can be used to backup the WP database. I only use this occasionally as I’ve had some problems with it. If I try to back up all the tables I inevitably exceed the cpu quota with my web host and get locked out for a minute or two. I still use it to back up the basic tables before an upgrade. I also had problems when trying to schedule backups through the plugin, again my web host didn’t seem to like it. The plugin has been updated since I tried scheduling backups but I’m not entirely comfortable sending a copy of my SQL database through email.

These days I’m more likely to use the built-in WordPress export feature to save all my posts, comments and categories to a local file than use the WPBackup plugin although the next two items are my primary backup methods.

I also use my web hosts own backup facility to back up my SQL databases and download the backup to my local computer.

To back up all the files on the site I schedule a nightly backup with Transmit.

WordPress Security Resources & Links

Some additional WordPress security resources:

BlogSecurity.Net - A site with information and tools related to blog security. Most of their content is related to WordPress.

The WordPress Development Blog will bring news of the latest releases.

Help Net Security is a general network security site that contains a lot of WordPress information. Their latest WordPress article is a list of WordPress security plug-ins.

Bad Neighborhood and the Bad Neighborhood blog are primarily SEO related sites but it includes the WordPress Login Lockdown plug-in which can be used to prevent brute force attacks to guess your WordPress admin password.

This article at Quick Online Tips has 3 suggestions for securing a WordPress blog such as removing the version info from the header and preventing the display of what’s in your plug-ins directory.

Spam Counts

This weeks spam counts:

Primary Mailbox 30-day spam count: 3

This is down one from last week and none of the spam is new, the last one arriving in the 13th.

Public Mailbox 30-day spam count: 176

The total is unchanged from last week but there was plenty of new spam.

Website comment and trackback spam: 7,500

This means there were 96 new ones from last week.

Other News & Links

Some non-WordPress news & links that caught my attention this week.

ArsTechnica.com: Adobe, Omniture in hot water for snooping on CS3 users - A little more info about the snooping being done in Adobe CS3. But no info from Omniture about the curiously crafted URL that the info is sent to.

CNet.com: Problems updating the Flash player in Firefox? Here’s help - The article provides the reasons I hate Flash player. What the rather long article explains is the steps necessary to remove the old, vulnerable versions of Flash Player.

Davidairey.co.uk: WARNING: Google’s GMail security failure leaves my business sabotaged - David has his GMail account hacked due to a vulnerability (since fixed) which led to him having his domain name stolen from him.

Dynamoo.com: Js/snz.a - likely false positive in eTrust / Vet Anti-Virus - Another probable false positive which will hopefully be fixed by the time you read this.

Lifehacker.com: How to Selectively Share Google Reader Feeds - There’s been a bit of a dust up over Google automatically sharing the Google Reader shared items with all contacts. Here’s a way to selectively share feeds.

Security Fix - Brian Krebs on Computer and Internet Security - (washingtonpost.com)- The storm work is now spreading via Google’s blogspot blogs.

Techdirt.com: Will Patent Battles Make Your Computer Less Secure? - TechDirt is concerned that patents could be used to hold back progress and make PCs less secure.

UneasySilence.com: Lies, Lies and Adobe Spies - No specifics as to what’s going on here, but Adobe CS3 seems to be calling home and trying to obscure exactly what it’s doing by using a website name designed to look like a local IP address.

I upgraded my test site last weekend and did some testing during the week and didn’t find any issues. This was the first time I used a plugin called Maintenance Mode and I’ll talk about it down below. The procedure for both my test and production sites are pretty much the same. The only difference is in the timing. I update all the plugins at one time in test, but then roll them out to production one per night just in case.

1. Backup the website files (I use Transmit) and database (I use the Wordpress Database Backup plugin).

2. One by one, for each plugin being upgraded: deactivate the plugin, delete the old files and copy up the new files. Reactivate the plugin and test it. Some plugins require re-entry of an API key or reset the configuration. I make a note of these when updating my test site so I don’t have to spend a lot of time checking my production site.

I do this first to make sure the plugins work under both the old and new Wordpress versions. To reduce outage time I typically update plugins a few days before the full Wordpress Upgrade and keep the changes to one at a time to isolate problems. For the production site this will actually be done by updating one or two plugins a night after the testing is done.

3. Download the latest Wordpress release and extract the files to my local hard disk.

This update was relatively minor and it would probably have been OK to just update the changed files. Since I’m only updating one production site I decided not to go this route, but there are some people out there who have done some of the heavy lifting for this approach and packaged up the changed files. But in my case I’ll spend the extra couple of minutes and copy all the files just to be safe.

4. Configure the Maintenance Mode plugin for the expected outage (See details in the Maintenance Mode section below).

5. Deactivate all plugins except Maintenance Mode. Enable maintenance mode to block all traffic and display the splash page.

6. Carefully update the WP-Content directory with the new Wordpress Files. I do not use any of the standard themes, so my concern here is to avoid deleting what I do use and the WP-Content directory is the place where there’s a mix.

7. Copy the other Wordpress 2.3.1 files to my website, replacing what is already there. I do not modify any core Wordpress files so replacing them is not a problem. I make sure nothing in the WP-Content directory tree gets touched during this copy.

8. Run /WP-Admin/Upgrade.php. In this case there wasn’t anything to update and it told me so. I didn’t bother to try this during the production upgrade since there was nothing to do in test.

9. Enable plugins one by one. Reconfigure those identified as needing additional configuration when re-activated.

10. Once all plugins are activated do some final testing, concentrating on pages which use plugins to generate their content.

11. Disable maintenance mode once testing is done and let people back in.

12. Test the site again, this time when not logged on as any sort of Wordpress user.

Wordpress Plugin: Maintenance Mode

Maintenance Mode is a plugin by Michael Woerher. When activated it puts up a landing page that says the site is down for maintenance. It also has the optional ability to return a “503 Service Unavailable” error in the HTTP header. The message displayed is also fully configurable as is the outage duration to be displayed on the page and returned in the http header for the “Retry-After <backtime>”.

The current release is version 3.2 which was released August 28, 2007.

Setup is straightforward. It installs like any other plugin. Activating the plugin does NOT block traffic. When the plugin is first activated maintenance mode is disabled. Once the plugin is activated you can find it’s configuration screen under the options menu in the Wordpress admin console.

The configuration screen allow you to set the “backtime” which is used in the message and returned with the 503 status (if it’s enabled). It’s not a countdown, so someone who sees it 29 minutes into a 30 minute outage will still be told to return in 30 minutes. If this is a problem you can always edit the message to include the specific times.

You can also configure what appears in the landing page (a.k.a. splash page) title and text. HTML is supported, php is not. You can use [blogurl], [blogtitle] and [backtime] as tags that will be replaced with their appropriate values. Click the thumbnail at the beginning of this section to see what I used for my most recent update.

You can also specify specific URLs that you still want to be available. This isn’t a feature I used. All of my pages are in the Wordpress DB so there wasn’t much point in keeping some available.

Finally, there’s an option to enable returning a “503 Service Unavailable” error in the http header and specify the time to return. This would prove useful to let any search engine spiders know the URLs they’re trying to reach are valid and will be back shortly.

There’s also a template tag you can use as a reminder when maintenance mode is active. The admin panels will also display a message near the top when maintenance mode is active.

This is useful since you’ll have full access to your site as an Administrator and may forget it’s active.

The Maintenance Mode plugin can be left activated all the time since the actual maintenance mode can be disabled. But I dislike leaving plugins active when they aren’t needed so I end up deactivating this one once I’ve completed maintenance.

The problem was resolved relatively painlessly. See the bottom of this post for the update.

Sometime between July 30th and August 1st the sidebar modules on this website stopped working and the default settings kicked in. Not the worst problem in the world since everything looked OK and visitors didn’t have a problem. The modules aren’t showing on the site and the module config screen is missing from the admin panel.

I figured it should be easy to resolve. Just find out what changed and undo it. Nah, foolish me. I added 4 posts during that time but nothing about the site itself changed. I didn’t do anything bizarre in those posts to make them different than what came before so I’m not about to delete them (although I did change them to draft to take them off the blog).

So I went into research mode. I spent several hours trying solutions for similar problems. I have another blog with the same plugins and theme so I didn’t think it was a plugin conflict but I eventually disabled all plugins (except the one that disabled widgets) and the problem remained. Some web searches show some sidebar module problems with the version of K2 that Redoable is based on. I also found a thread on the Redoable support forum about the problem being a ampersand in a sidebar module name. None of the solutions mentioned worked for me.

So the next step would be a complete removal and re-install of the theme. I could get the files from a backup done before the problem so this shouldn’t be a problem. But I’ll have to remove all the settings from the DB which means reconfiguring everything manually.

So, i figure my options are:

1. Wait until the problem magically resolves itself. (not likely - but I like the lack of effort needed)
2. Bite the bullet and do a complete re-install (after making sure all settings are gone).The real risk here is I will smash my iMac if it doesn’t work after all that time and effort or of things really go bad. It’ll probably be a week or two before I get time to do this.
3. Do nothing with the site for now. Use this as a reason to start learning about Wordpress themes and PHP. The plan here (I think) would be to go to the Sandbox theme and concentrate on learning CSS, at least at first. Seeing the site and the problem would motivate me to learn.
4. Use Widgets instead of the sidebar modules.

I’m beginning to wonder if a theme like redoable, which is based on the code from another theme is too risky these days. Everytime Wordpress is updated there’s a risk the theme will break and I’d be dependent on two theme designers for updates. Or I’d have to figure it out myself. Even if I fix this problem will a future Wordpress upgrade break things.

Any ideas or solutions?

Update: Resolution

Well, I resolved it and it was fairly quick an painless. The “Uninstall” button in the Redoable admin panel didn’t properly remove the Redoable options. The code was still set to remove K2 options. There was a post on the Redoable support forum for what line to change in the PHP code. Open options\app\tools.php, locate the line ” $cleanup = $wpdb->query(”DELETE FROM $wpdb->options WHERE option_name LIKE ‘k2%’”);” (it’s near the top) and change “k2″ to “redo”. Then I uninstalled the Redoable theme and immediately repicked it again. Naturally I had to reset all my options and recreate the modules but then all was well.

Graphic from coolclips.com.

Wordpress Stats Version 1.1.1 was released soon after. It plugs a critical SQL injection security vulnerability.

I upgraded this blog and everything seems fine - the old stats remained and they’ve been updated. The instructions say the updated plugin can be copied over the old one, no mention of deactivating the plugin first. I followed my typical procedure and shut down the plugin first, then replaced it. When I restarted the plugin I had to re-enter the Wordpress API key.

But there were problems before the upgrade which went unnoticed since I was offline so much. Some URLs just returned a 301 permanent redirect error and redirected back to itself. All-in-all not a good thing. This was caused by the Permalink Redirect plugin being turned on (accidentally) before I finished testing. For some reason it affected many URLs but not others. Well, the plugin is off and things are working again. There’s a new item on my todo list - delete unused plugins.

Wordpress.com Stats

Wordpress.com Stats requires you to have an account at Wordpress.com, although you do not need an actual blog there. The Stats are hosted on their servers. Also, you’ll need an API key from Automattic. If you have one for Akismet you can use the same key, and if it sees the key in the DB it will offer to use it.

Assuming you don’t already have an API key you can go here for instructions on how to get one. This process will also give you an account on Wordpress.com.

One you have the API key you simply upload stats.php to your plugins directory and activate it in the plugins admin panel in your Wordpress blog. You’ll be prompted to enter the API key, or use one it finds. They say it takes about 20 minutes for stats to start showing up which I found to be fairly accurate. My busier blog showed activity in about 15 minutes while my less active blog showed activity in about 30 minutes.

Stats are viewed by selecting “Blog Stats” on the Dashboard menu in your Wordpress blog admin panel. This redirects you to your Wordpress.com admin panel and you’ll be prompted for an ID and password unless you told it to remember you.

There’s a graph showing views over the last 30 days (but only from when you started collecting stats). The top 10 posts for the current and previous days are shows along with the number of views. All times are GMT so “today” and “yesterday” are calculated based GMT. You can also drill into the top posts and get daily reports for the past seven days. These list more than the top 10 posts but still eventually truncate the least viewed posts if you have a long list. You can also get summary reports for pages viewed in the last seven or last thirty days. On any of these post views there’s a graph icon next to each post listing, clicking it displays a 30 day graph of views for the post.

The main page also displays a list of referrers for the current and previous days. This also has the ability to drill into the detail but it ends up being one of the bugs in the plugin. Drilling in shows a heading “Referrers for 7 Days…” but only the current day’s referrers are shown. Even the previous day’s referrers that were shown on the previous page have been dropped from this report.

Search engine terms used to find the blog are also shown. Again, on the main page they’re shown for the current day and yesterday. But again, drilling into them results in a header that says “Search Terms for 7 Days…” but the result is only the current day’s terms. In my case I had sixteen referrals for one search term yesterday but it didn’t make the seven day drill down even though the top search term for those seven days had only two uses and only contained what appeared to be the current days referrers. It clearly should have been there.

Finally rounding out the major stats, the clicks on the blog are also tracked. This seems to only track outbound clicks. And again, the drill down has the same issues as search and referrers.

The plugin also keeps track of total views and the “best day ever”. It also lists a couple of recent incoming links while clicking “more” brings you out to a Google Blog “links” search.

If you have multiple blogs which use the same API key you can jump between them by picking the blog from a drop down and clicking “go”.

I also found some problems that appear shortly after midnight GMT. The “Today” and “Yesterday” stats for search, referrers and clicks are identical for a period of time although eventually they become distinct. It appears the daily rollover isn’t clean until some time passes or enough news stats are collected. Although the amount of time I’ve waited seems rather random. But since I need to be at my computer at a specific time it’s been hard to track, especially since it’s not a minor issue.

Summary: The graph of views and the simple metrics for post views makes Wordpress.com Stats worth using for me. It provides a quick view of what’s recently active along with quick insight into the 30-day trend overall or for a specific page. The bugs in the referrers, search and clicks does leave gaps in it’s ability.

Google Analytics by Denis de Bernardy

In a bit of irony, prior to the redesign I used a theme by Denis de Bernardy but not his Google Analytics plugin. My main reason for switching to this plugin was it’s ability to ignore my own site visits. The plugin actually excludes visits from all authors, editors and site admins if you have a blog that uses these various roles.

You’ll need to set up a Google Analytics account before you can use the plugin. Once you do that you simply copy the contents of the plugin download to your wordpress plugins directory and activate it. Since there are two files I copied the directory contained within the zip to my plugins directory. Then, in the admin panel, locate “Google Analytics” on the “Options” menu. Paste the tracking code provided by Google Analytics into the box provided. You can also simply type your tracking number in the space provided since the code template is already there. In my case I simply replaced all the code with cut/paste from Google Analytics.

I’ve tested the ability to exclude my visits by viewing some obscure pages and Google Analytics did not report the views. Also, prior to activating the plugin my admin panel usage was tracked. This dropped to zero when I activated the plugin.

Most of my usage was with version 2.2 of the plugin. Version 2.4 is now available. The latest version uses roles rather than levels so isn’t compatible with Wordpress pre-version 2.

Summary: The plugin has no purpose unless you use Google Analytics but if you do the plugin does a good job of limiting the stats to visitors. For those of you who are anti-Google Analytics (because it gives Google too much info) Denis also has a similar plugin for HitsLink which is a paid tracking service.

Additonal Information

You can find additional information about Plugins and Wordpress on my Wordpress page.

The plugin puts some intelligence into determining the popularity of a post by allowing weights to be assigned based on how the post is viewed or used. The screenshot below shows the possibilities along with their default values.

As you can see, views from the feed carry the least weight since there’s no way to know if someone actually read the article. The same with Homepage and Archive views, they carry a bit mnore weight but not too much since there are multiple posts of the page. Trackbacks really bump things up because someone else referenced the post. Permalink Views are when someone views the article on it’s own page. Either because they came via a search engine or clicked the article URL on the Archive or Home page. These values are fully configurable so that they can be customized to the structure of the site.

You can see the current rankings for my site in the bottom of the right sitebar. The most popular posts of all time along with the most popular for the month so far are shown. Unless there’s a lot of trackbacks or comments there’s a bias to new posts in the beginning since they collect points with homepage views. The plugin also includes the ability to recalculate trackback/pingback/comment values which is useful if you have to delete spam. This calculation can also be scheduled using cron so the values can be automatically re-calculated every night.

The plugin also includes several template tags. The widget in the sidebar uses the tag for the most popular of all time along with the tag for most popular in a month. A tag for most popular in a category is also available. The plugin creates a “Most Popular” page in the Wordpress Dashboard which shows the most popular posts in categories and views and serves as an example of what can be done.

The plugin also displays the popularity of each post, in relation to the most popular, within each post (at the bottom). I have that feature turned off for now. I want to see what it does to feeds (if the popularity changesm does the feed change?) and collect more data before displaying it.

You can follow future updates and information about the Popularity Contest plugin on my Wordpress page.

While I hadn’t intended to use it to handle redirection for the /blog directory change, I decided to give it a try once I saw the errors from the Google web crawler since it was easier than figuring out the .htaccess commands. Plus, at the time I had access to my blog but not ftp access to the server. The plugin supports regex redirects and the website gave an example of exactly what I needed. Google hasn’t crawled my site again so it remains to be seen if it’s a true fix to the problem. (In the past, typing old /blog URLs manually were properly redirected so the fact they still work doesn’t actually prove the problem is fixed, but all signs are positive.)

But I did find another problem caused by the way I imported the postings/comments/categories from the old site rather than doing a database backup/restore. On the old site I had changed some category, posting and page names without changing their slugs. When I imported them into the new site it looks like new slugs for the permalinks were generated based on the current info (the slugs used for permalinks are based on title and are generated when the first save is done, even if it’s a draft). They began showing up in the 404 error log files for the Redirection plugin. It was simple enough to create the redirects based on these logs. In the case of category changes I could create regex redirects. The plugin logs the bad URL as a link so it was easy enough to verify it was bad and then verify the redirect worked.

The plugin has some other nice little features:

• For each configured redirection it keeps track of the number of redirections performed and the last date one was done.
• I’ve only used simple redirection but it will also redirect in other ways - to random URL, based on referrer, based on login status and to one of several URLs
• I’ve only used 301 and 302 redirects but it also does 307, 404 and pass-through redirects

An updated was released yesterday (which I haven’t had a chance to download) which has some nice usability enhancements (a search and a minor tweak to jump down to the new redirect fields when clicking the button to create a new redirect from a logged error. I haven’t had enough redirects to notice the need for these yet but they’ll certainly be appreciated if the list grows.

I had actually avoided this plugin (actually any redirect plugin at first) because I figured it would be better to manage through .htaccess. But further research shows that Wordpress creates a default redirect that puts all URLs through Wordpress so there doesn’t seem to be any benefit to using .htaccess for the redirects. It just seems easier to use the plugin, with no down-side, so I’ll probably be using it even more, especially if I do any major redesigns.