Posts Tagged ‘WordPress’

WordPress 3.1 Upgrade Issues

February 27th, 2011

I noticed this evening that WordPress 3.1 was available and my blog’s dasboard was coaxing me to upgrade.  Every single time I have upgraded, I have made a backup before hand.  At the end of a long week, my logic was shot and I proceeded with the upgrade without a backup.  As luck would have it, my Windows Server 2003 and IIS based blog no longer worked.  Page loads were an endless hourglass, no 404 or any other web browser errors.   However, another symptom included the w3wp.exe process (this is IIS) on my server consuming extremely heavy CPU utilization during the endless page loads.  When cancelling the page load, the CPU utilization goes back down to normal.

As I have an ongoing obligation to blog sponsors, not to mention I was mentally drained, I was feeling pretty screwed at this point, but was prepared to restore from the previous night’s Veeam file level backups.  I turned to Google looking for other WordPress upgrade experiences.  Search results quickly lead me to this thread which provided a ton of users having the same issue.  A chap by the moniker of jarnez had the solution, or at least workaround which worked for me as well as others.  Open the blog’s admin dashboard (thankfully this is still functional) and install the Permalink Fix & Disable Canonical Redirects Pack plugin and all is back to normal again. 

Thank you jarnez!!!

SexyBookmarks WordPress Plugin and RSS Feeds

November 4th, 2010

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 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.

SnagIt Capture

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.

QuickPress – VMs Per…

May 7th, 2010

I’m trying out my frist QuickPress. Let’s see how this turns out.
Right off the bat, I’m missing the autocomplete feature for Tags. As it turns out, typing more than three lines in the small content box isn’t much fun.

On with the VMware content… This all comes from the VMware vSphere Configuration Maximums document.  I’ve bolded some of what I’d call core stats which capacity planners or architects would need to be aware of on a regular basis:

15,000 VMs registered per Linked-mode vCenter Server
10,000 powered on VMs per Linked-mode vCenter Server
4,500 VMs registered per 64-bit vCenter Server
4,000 VMs concurrently scanned by VUM (64-bit)
3,000 powered on VMs per 64-bit vCenter Server
3,000 VMs registered per 32-bit vCenter Server
3,000 VMs connected per Orchestrator
2,000 powered on VMs per 32-bit vCenter Server
1,280 powered on VMs per DRS cluster
320 VMs per host (standalone)
256 VMs per VMFS volume
256 VMs per host in a DRS cluster
200 VMs concurrently scanned by VUM (32-bit)
160 VMs per host in HA cluster with 8 or fewer hosts (vSphere 4.0 Update 1)
145 powered on Linux VMs concurrently scanned per host
145 powered on Linux VMs concurrently scanned per VUM server
145 VMs per host scanned for VMware Tools
145 VMs per host scanned for VMware Tools upgrade
145 VMs per host scanned for virtual machine hardware
145 VMs per host scanned for virtual machine hardware upgrade
145 VMs per VUM server scanned for VMware Tools
145 VMs per VUM server scanned for VMware Tools upgrade
100 VMs per host in HA cluster with 8 or fewer hosts (vSphere 4.0)
72 powered on Windows VMs concurrently scanned per VUM server
40 VMs per host in HA cluster with 9 or more hosts
10 powered off Windows VMs concurrently scanned per VUM server
6 powered on Windows VMs concurrently scanned per host
6 powered off Windows VMs concurrently scanned per host
5 VMs per host concurrently remediated

Got all that?

Update 5/10/10: Added the row 160 VMs per host in HA cluster with 8 or fewer hosts (vSphere 4.0 Update 1) – Thanks for the catch Matt & Joe!

Flickr Manager Plugin Fix

April 27th, 2010

I’m a visual and hands-on kind of person and as such, I tend to make use of images in my blog posts. Flickr is an online provider that hosts images free of charge which saves me bandwidth costs and delivers content to blog readers quickly. In a sense, they are a cloud provider. Flickr Manager is a WordPress plugin that allows me to efficiently browse and insert Flickr images from the comfort of my WordPress blog editor, among other things.

Several months ago, the Flickr Manager overlay stopped working correctly.  The overlay was no longer inserting images into my blog posts as I had been instructing it to.  I filed a bug (#144) with the author as follows:

What steps will reproduce the problem?

1. Create a new blog post or page

2. Click on the “Add Flickr Photo” icon.

3. In the overlay under “My Photos” tab, click on a photo to insert.

4. In the summary overlay page, once the photo is selected in the overlay, click the “Insert into Post” button.

5. The summary overlay page for the photo returns and no photo is inserted into the blog post.

What is the expected output? What do you see instead?

I expect the photo to be inserted into the blog post and the Flickr overlay should close. Instead, the overlay stays open as if nothing has happened. The same thing happens if I check the box “Close on insert” on the overlay page.

What version of the plugin are you using? Which version of WordPress? Flickr Manager version 2.3. WordPress 2.9.2

Please provide a link to your photo gallery, or the page that has the bug: My Flickr Photostream is at

Which hosting provider are you on? What version of Apache or IIS are you using? Self hosted out of my home. Windows Server 2003, IIS 6

Please provide any additional information below.

This plugin was working fine for the first several months but after a while it stopped inserting photos. I can’t associate the breakage with any sort of upgrade such as a WordPress upgrade, plugin upgrade, or theme change. Any help would be appreciated.

Browsing my Flickr album, grabbing URLs for images, and inserting them into my blog posts manually is a painful process involving multiple browser windows.  I was really missing the functionality of Flickr Manager.  It was deterring me from writing blog posts which I knew I wanted to incorporate images.  Using Google, I was able to locate a few others who had stumbled onto this problem, but I was unable to find any solutions.

I turned to Twitter, a universe of technical expertise, among many other things I’m sure.  Kelly Culwell and Grant Bivens, Solution Architect and Web Developer resepectively of Interworks, Inc., answered the call.  I had spoken with Kelly off and on the past few months regarding VMware topics.  They quickly turned me on to this page which described fix.  All I had to do was modify three of the plugin files, removing any occurrance of the @ symbol.  Grant described the problem as a JavaScript selector the author used which has since been depreciated.


Happy days once again, the solution worked!  These guys wanted nothing in return but their kind offer to help and quick solution definitely deserves mention.  My faith in humanity has been partially restored thanks to these gentlemen.  Kudos and great job!

New Blog Theme

October 28th, 2009

Over the course of the past year, I’ve received some feedback that my dark blog theme, while nifty, was hurting readers’ eyes.  In fact, there are some readers who only read this blog through an RSS reader so that their eyes are not strained.  I’m in agreement and have been for quite some time.  The only reason I hadn’t changed it was because I didn’t want to be known as someone who changes themes often and for the heck of it.

I’ve chosen this new theme called Green Park 2. The green colored bar across the top gives it a “green feeling” which is quite appropriate for the blog’s subject of virtualization in the datacenter (and beyond).

Anyway, I hope you enjoy it.  Barring any problems, I intend to keep it around indefinitely.  Perhaps it will encourage a few of the RSS lurkers to come out of the woodwork.

Happy Birthday Blog

October 20th, 2009

This blog turned one year old on Sunday. The inaugural entry, My First Blog and How To Install WordPress, was posted on October 18th, 2008.

Happy Birthday Blog!

For some reason, it feels like I’ve been at this a lot longer than one year.

Some statistics related to this blog during the past 365 days:

  • 224 posts
    • 195 Virtualization related
    • 30 Non-virtualization related (typically other technologies and a few personal)
    • Average of one post per every 1 1/2 days
    • Using a very conservative estimate of 2 hours spent writing each post, total time spent writing:
      • 448 hours
      • 19 days
      • Almost 3 weeks
      • Doesn’t include any lab time
  • 179,389 Unique visitors
    • Generating 5,399,277 Hits
    • Consuming 71.36GB Send (upload) traffic
    • Costing $1,199.88 in bandwidth
    • Plus another $1,800 estimated in rack electrical/cooling
  • 743 legit comments (approved)
    • Average of 2 legit comments per day
  • 7,873 spam comments (blocked and IP banned)
    • Average of 22 spam comments per day
  • 90 Tags
  • 14 Active WordPress plugins
  • 7 Inactive WordPress plugins
  • 4 Sponsors
  • 1 Theme change
  • 3 VMware exams passed
    • VCDX Enterprise Administration exam
    • VCP4 exam
    • VCDX Design exam
  • 2 VMworlds attended
    • VMworld Europe 2009
    • VMworld 2009
  • 7th most popular virtualization blog as rated by the VMware community
  • 1 vCalendar idea
  • 1 vExpert award
  • 0 VMware NFR licenses received
    • Out of a dozen or so requests
    • Over the course of 2+ years
  • Established about a million virtualization industry
    • Contacts
    • Friends
    • Acquaintances
  • Through
    • Blog
    • Twitter
    • VMworld
    • LinkedIn

Thank you for reading. I look forward to another great year with more VMware virtualization information to share! A special thank you also goes out to other bloggers and VMware virtualization community members for sharing your time and knowledge and continuing to inspire me to do the same.

MobilePress caused 55,000+ files in c:\windows\temp

March 19th, 2009

A while after installing the MobilePress 1.0.3 plugin for WordPress, my IIS server locked up.  I rebooted it and all was well.  A while later, it locked up again.  Upon further investigation, I found 55,000+ files in the c:\windows\temp\ folder and new files were popping in there at a rate of a few per minute.

Each of the 55,000 files looked like:




where the prefix of sess_ is common but the rest is random.

Using Sysinternals procmon.exe, I was able to identify right away that the process responsible for creating the files was w3wp.exe which pointed me to IIS.  However, I wasn’t sure why IIS would begin doing this after being stable for a long time.

Searches on the internet said the files were being generated by PHP and indicated new user sessions as visitors hit my blog.  That helped confirm the fact that these were coming from IIS and the blog but still no tell tale reason as to why all of the sudden.

Then I opened up one of the files and it showed:

That was enough to jog my memory that I had recently installed the MobilePress plugin.

Removing the plugin immediately resolved the issues and the temp files are no longer created.