Wednesday night I wrote up a blog post on Veeam Backup and Recovery 5.0 and scheduled its release for this morning at 9am.  I’ve been swamped at work but I did get a chance to validate mid-morning that the post was up.  Shortly after I realized the blog’s RSS Feed had stopped working as of last night’s Veeam post.

Once home from work, I started the troubleshooting.  Due to the self-hosting aspect, IIS, MySQL, the number of plugins in use (I do try to keep to an absolute minimum), the theme mods, the monetizing, Feedburner, etc., my blog has several moving parts and is a bit of a pain sometimes.  WordPress itself is solid but with the add-ons and hacks, it can become a house of cards (it’s a lot like running a game server).  The more time that is invested in a blog, the less of an option it is to firebomb and start over.  I crossed that point of no return a long time ago.  Themes, monetization, and all that stuff aside, the content (and to some degree the comments) is by far the most valuable piece to NOT be lost.  In retrospect, solving the technical issues as they arise is satisfying and a slight boost to the ego, but often times there just aren’t enough hours in the day for these types of problems.

Troubleshooting a WordPress blog is best approached from a chronological standpoint.  Think of the blog as one long timeline of sequentially serial events.  You’ve got post history, comment history, WordPress code history, theme history, plugin history, integration history, hack history, platform infrastructure history (Windows/Linux, MySQL, IIS or Apache), etc.  Blog problems are usually going to be tied back to changes to any one of these components.  If the blog sees a lot of action, malfunctions will usually surface quickly.  “It was working yesterday, but something broke today”.  Such was the case when my blog’s RSS Feeds stopped updating this morning.  As I stated earlier, the best approach is to think about the timeline and go backwards from the point of broken identifying each change that was made to the blog.  Historically for me, it’s usually a plugin or a recent post which has some sort of nasty formatting embedded in it somewhere.

So.. the problem: RSS Feeds broken; no longer updating at Feedburner.  Impact: 3009 RSS subscribers are unaware I’ve written new content – bad for me, bad for sponsors.

Solving this problem was a treat because I had made multiple changes to the blog last night:

1. Upgraded the theme to a new rev. (finally!)
2. Applied existing hack functionality to new theme files
3. Installed two new plugins
4. Made changes to sidebar widgets
5. Wrote a Veeam blog post which had some special characters copied/pasted in it

I started by testing my blog’s RSS feed with a syntax/format checker at Feedburner.  It failed.  There’s bad code embedded somewhere which can stem from any of the above changes.

Next I shut down Feedburner integration to help isolate the problem.  With the Feedburner plugin disabled, my blog now supplies its native RSS feed capability which is built into WordPress.  Hitting the URL for the feed showed failure.  Long hourglass followed by a blank browser page with a bit of information, again, about bad code in the feed which cannot be handled.  So now I know Feedburner is indeed not updating because of bad content in the feed (that behavior is by design which is why the internet makes feed checkers to aid in troubleshooting).

Good progress, however I’m still left with identifying which change above caused the RSS feed to stop working.  The next step is to start backing out the above changes.

1. I started by unpublishing the Veeam post.  No dice.
2. I then rolled back to the old version of the theme.  Problem still exists.
3. Then I disabled the SexyBookmarks 3.2.4.2 plugin.  B-I-N-G-O

Shortly after, I found specifically what in the plugin was causing the RSS feed issue.  There’s an option in the plugin settings called Show in RSS feed? (displayed in the image below)  This feature is designed to show the little social media information sharing buttons in RSS feeds when set to Yes.  Whether or not I had configured this option, it was configured as Yes.  When set to Yes, it embeds code in the RSS feed which RSS readers don’t understand, which then leads to RSS feed failure.  With this find, I could disable the feature but at the same time,  keep the plugin enabled.

I can’t say I learned a great deal here.  It was more reinforcement of what I’ve learned in the past.  I’ve been through blog troubleshooting exercises like this before and they were solved using the same or similar techniques.  Blog plugins and modifications ship with the implied warranty of “buyer beware”.  When something goes wrong with your blog, you should be able to tie the problem back to recent changes or events.  In an environment such as mine where I’m the only one making changes and writing content, I’m accountable for what broke and I can isolate the problem to something that I did to cause impact fairly quickly.  Larger blogs hosted somewhere else with multiple owners and authors introduces troubleshooting complexity, particularly if changes aren’t documented.  I guess that’s why change management was invented.  My lab is the last environment I’m aware of where changes can be made without a CR.  That’s one of the reasons why the lab remains so sexy and is such a great escape.

• Previous Entry: Veeam Backup & Replication 5.0
• Next Entry: Hyper9 Pulse Check