Googlebot can’t access your site (Scary, right?)

Yesterday, many Google Webmaster Tools users received unpleasant notifications that their websites were suddenly inaccessible to Google.  After 2 hours of aggressive troubleshooting last night, and another couple hours spent this morning, it seems that this may be an issue on Google’s side.  Search Engine Roundtable just posted an article confirming more reports of problems with Google accessing robots.txt.

In my own case, the naked URL is accessible from every other browser, device, and third-party tool in my arsenal, yet Google has about a 80% error rate in accessing my robots.txt file.  While the www version is working perfectly with no crawl errors or problems fetching as Googlebot, the non-www version is having much less success.  (Please note, you may also receive duplicate “Googlebot can’t access your site” errors for both www and non-www versions.)

Attempting to use the Fetch as Google tool within Webmaster Tools was helpful in understanding the problem, but ultimately the problem seems to be with Google, and your site’s index status is likely just fine. (Whew!)  But use caution in writing off warnings from Google, you could very well be receiving these email warnings for good reason, especially if you received them before yesterday (on or before April 25, 2013).

Matt Cutts commented on the Google forum discussion earlier, acknowledging this could be an issue with Google, so I recommend you check that forum thread out.  I’ll keep an eye on this until a resolution comes around, but if you’ve already tested your site in the Fetch as Google tool and all other bots are working normally, you may actually be able to do something you almost never (ever) want to do – ignore a Google Webmaster Tools alert.


UPDATE  (2013-Apr-27)

Google’s John Mueller has indicated that this issue should now be resolved.


Using CSS to create list-items with differently colored bullets and text

The new design for a website I’m working on calls for the ability to style bullets and the following list-item text with different colors, which isn’t an easy task for your plain-Jane CSS unless you use images for your bullets.  This is not desirable because each section of the site has a different theme color, so I’d have to create and manage bullet images for every color used.  Not to mention the extra HTTP requests which slow pages down.  But there’s a better way, and it even degrades gracefully with older browsers!

This image shows what the end result should look like.  This special bullet styling should only be applied to the user-generated content (UGC), like pages and posts.  Nav items, and other cases where <ul>‘s are used for semantic purposes, should not use this styling.

To make this happen, I added a .ugc CSS class to the container element for the post and page text, and then added the appropriate stylesheet rules to any list-item elements within.

You’ll see that I first remove list-style from all <ul>‘s within a .ugc container by setting it to “none”.  Adding the “position: relative;” style to the <li>‘s allows for me to use it as an origin for some absolute positioning with other elements.  The trick to using different colors with bullets and text is to create pseudo-elements for the bullets using the “:before” pseudo-selector.  The .ugc li:before selector shown above defines a new element created right from CSS, absolutely positioned from the <li> element, with a width and height of 5px, a purple background and a border radius relative to the size so as to make the element appear circular.  Cool, huh?

(Note:  Ignore the “@purple” color and what looks like incorrect border-radius syntax, this is LESS syntax which gets compiled correctly to the correct CSS, including browser-specific prefixes.)

You’ll also see some fallback code for IE browsers before IE8, which is fairly self-explanatory.  I conditionally add CSS classes to IE browsers a la Paul Irish’s elegant solution, and so older, crappy browsers can also enjoy the separately colored bullets.

Of course, I realized that those cool styles apply to all of the targeted list-item elements within my user-generated content, and sometimes they shouldn’t.  If you drop some extra page navigation within the element having the .ugc class, or perhaps paste a code snippet to show off your own cool coding tricks, you’ll need to remove your cool bullets.  For example, if I have some Twitter Bootstrap tabs that get mixed up with my content via a WordPress shortcode or something, here’s how I’d remove the bullets that will show up (and not be easy to track down with Firebug):

Just use those same :before pseudo-selectors and set their display property to “none”.  Done and done!

When you can’t log into WordPress because your “Cookies are blocked”

But your cookies are turned on, you’ve cleared them along with the rest of your cache, and the problem exists in every browser!

A typical scenario is when you’ve copied your website from it’s test URL to production, or maybe you’re even just syncing down your prod data to your dev environment, as I do every once in a while to make sure I’m writing code against realistic data sets. After restoring the copied site files and importing your MySQL database dumb into your dev db, you innocently try to navigate to your /wp-admin page and log in. And you can’t log in because of some weird errors like “Cookies are blocked” on your system … frustrating.

But your cookies are turned on, you’ve cleared them along with the rest of your cache, and the problem exists in every browser!

A typical scenario is when you’ve copied your website from it’s test URL to production, or maybe you’re even just syncing down your prod data to your dev environment, as I do every once in a while to make sure I’m writing code against realistic data sets.  After restoring the copied site files and importing your MySQL database dump into your dev db, you innocently try to navigate to your /wp-admin page and log in.

And you can’t log in because of some weird errors like “Cookies are blocked” on your system … frustrating.


When you find yourself unable to log into WordPress, don’t panic.  Just go through the first few logical steps to make sure:

  1. Make sure you’re really at the right URL. No kidding, we all work on a million websites, just make sure your browser didn’t auto-fill your address bar with the wrong URL – it happens, admit it and let your coworkers make fun of you, then go on about your day.You might even be at the correct URL, but your hosts file is redirecting you to a server you’re not expecting.  (Touched your hosts file lately?)
  2. Reset your password.  The forgot password route is super easy, and with as many passwords as we all tend to juggle, it’s probably faster to just reset to something you’ll remember instead of spending an hour trying every combination of letters/numbers/symbols you’ve ever tried to memorize throughout your computing life.
  3. Check for error messages. But beware, error messages can be deceitful.  For example, if you’ve moved or copied your blog to another location with a different URL, you may need to do some blog triage (described further below!).  Also, you might want to try turning WP_DEBUG on in your wp-config.php file, as it may reveal more info that is helpful in troubleshooting.  Remember not to leave this on in production, though!  Read more about debugging WordPress.
  4. Disable your plugins by renaming the plugins folder.  Doing so has minimal impact, and is an attempt to remove any other non-WordPress-Core code from loading and further get to the bottom of your login issues.  Also, try renaming your active theme folder (the folder under the /wp-content/themes directory) to get WP to fall back to the default Twentyeleven theme.You’ll need to go back in and reactivate each plugin later, but is a good troubleshooting step!

This won’t solve every problem out there, but it’s a good start.  In fact, it was when my normal checklist failed and I found a more unique fix for W3 Total Cache issues that I decided to write this post.

W3 Total Cache

If you have W3 Total Cache installed, this could be causing your login problem – especially if you’ve recently moved your blog or otherwise updated it’s URL.  Admittedly, this just sucked 30 mins of life away, so this was one I wanted to share specifically.

W3TC adds and modifies some files which can be problematic, so you probably just want to triage your html_docs folder when moving your blog and using that plugin.  If you’re unable to log into your website, often seeing a “Cookies are blocked” error message as a symptom, you may need to disable and remove the plugin before you can get into the site.  (You don’t need or want a caching plugin in your dev environment, anyway!)

To disable and remove the W3 Total Cache plugin manually:

  1. Navigate to your /wp-content/plugins folder and delete the w3-total-cache folder.
  2. Also, delete the w3-total-cache-config.php file from /wp-content.
  3. Open your wp-config.php file and look for a line of code to comment out or remove:[sourcecode language=”php”]define(‘COOKIE_DOMAIN’, ‘’); // Added by W3 Total Cache[/sourcecode]This is the line that causes those confusing cookie errors!
  4. You will still have your settings in your database, and should you choose to re-install the plugin, your settings should still be there.  You could also choose to manually go in and prune the W3TC options from the wp_options table in the database, but it’s not a requirement.
  5. Additionally, I like to go to the Settings > Permalinks options page and just click save again to force WordPress to rewrite the .htaccess file.

If you have further problems, feel free to leave a comment below!  Find another special case of a plugin causing login issues?  Leave a comment and help prevent somebody else’s hair loss  🙂

Or, check out one of the following pages where more discussion on the topic has taken place:

I’m really looking forward to SXSW 2012!

Today is the last day to vote for proposals for next year’s SXSW Interactive Festival (though if history precedes itself, it could be extended), and I’ve spent a good amount of time promoting what I think should be a killer topic for attendees.  “Deploying WordPress:  From Zero to Ninja” will cover business-oriented subjects like developing in multiple environments, the have-to-have plugins, and best practices from the community’s experts for running your enterprise-class application on the WordPress platform.

But I’d like to spend the remaining voting time promoting some other topics I’m really looking forward to, and I’ll update this list over time as I find new panels that catch my eye:

Be sure to check out all of the great WordPress-related panels and give them your vote!  More than 3200 proposals are competing for about 350 slots, and only 8 relate to WordPress!  A little surprising, but that will translate to far greater expectations from the WP-related topics that are picked  🙂

Do you upload zip files to your WordPress site? Your Windows and IE users may be downloading corrupted files.

This issue has been floating around for a while, but I only ran up against it a couple of weeks ago.  The short of it is that if you have Internet Explorer users complaining that they are unable to download usable zip files from your WordPress or otherwise LAMP website, this may be the fix you’re looking for.  I might also add that in my own testing of this, downloading zip files from one of my WordPress sites with gzip and deflate compression enabled were also corrupted in Firefox on a Windows 7 computer, so it’s not just constrained to IE7 and IE8 users.  However, the issue is indeed resolved on computers with IE9 installed.

Microsoft has posted the description of the bug in urlmon.dll in their “Internet Explorer May Lose the First 2,048 Bytes of Data That Are Sent Back from a Web Server That Uses HTTP Compression” article, but abhorrently they’ve also listed the fix as encouraging developers and/or users (think about your mom, now) to go in and modify the registry.  Now I love to help my parents with their email password reset or their wireless printing, but I don’t want to walk my mother through modifying the registry over the phone.  Since we care about our IE and Windows users even when their operating system or browser doesn’t, we can’t just leave them out on their own.

As WordPress developers, let’s help minimize Microsoft’s urlmon.dll problem, and fix it the right way by simply disabling gzip compression on our already-compressed files, if at least for our own sites!  You’ll need to modify your Apache configuration file, typically in either the more global httpd.conf file, or the deflate.conf mod file if you’re running an Ubuntu or Debian system by adding the following code:

This line disables compression on all files with the *.zip extension for all browsers, which is ok because the files are compressed anyway.

Microsoft also references this in another support article “An error occurs after downloading a .ZIP file with Internet Explorer“, where you can find solutions for IIS 6 and 7 servers.

Tomorrow is the last day to vote for my topic, “Deploying WordPress: From Zero to Ninja“, for the 2012 SXSW Interactive Festival.

Please check out my panel proposal and give me a thumbs up, as well as leave me any questions, or comments!

Apache HTTP Won’t Start Because Port 80 is Being Used?

Try uninstalling Web Deploy 2.0.  I’ve had IIS and Apache running smoothly for months on a new machine, and suddenly after installing SQL Server 2008 R2 and some Silverlight (yuck) tools to maintain an existing app, Apache reported that port 80 was already taken by “Microsoft HTTPAPI/2.0”.  I think it snuck in, along with an unwanted install of IIS 7.5 Express, via the Web Platform Installer.  Thanks for stealing 2 hours of my productivity from me, Microsoft.  (I don’t get why MS would install that so greedily, and I already had the full version of IIS installed, btw.  I hate that Web Platform Installer shit.)

The Web Deploy tool is not something most of us use, in fact I don’t know anybody who uses it at all.  So it’s pretty safe to get rid of.

When your app hits a snag, how do you treat your users?

Google+ site errorI really don’t mind being patient with Google+ site errors, but I really would prefer an accurate error message to being given a list of all the things it *could* be.

But let’s talk about our own websites, and how they could work better when errors pop up.  You should ensure that your users are given a direct path to fixing whatever just happened.  And for bonus points, consider providing users a simple, clickable path to recommended resolutions so that they spend as little time as possible dealing with these kinds of unfortunate interruptions when they do happen.  In my case with Google+ just a few moments ago, if I were given an error message that properly reflected the problem that I was encountering, I may have been able to resolve things myself and keep on keepin’ on.

Instead, this is what happened:

  • I was reading a good WordPress blog post and decided I’d +1 it. (Still sounds weird … but so did “like” at first.)
  • I clicked on the +1 button, and was shown a little red box with an exclamation point. No indicator of what happened, and mousing over it still did not give me an error message.
  • I clicked on it again and got a popup to their help docs with a variety of reasons for why the error could occur. Still don’t know what happened so I can take the next step to fix it.
  • I blogged about what happened.
  • I “liked” the blog post I was reading using the Facebook widget just to the right of the +1 🙂

And while this was a small, inconsequential issue that I enountered (I wasn’t submitting a resume or banking online, or anything like that), I think it’s a good reminder for designers and developers to give users a graceful experience when their websites get the hiccups. I understand that it’s often the last thing on your project’s to-do list, and might be your clients’ lowest priority, but be careful that proper error handling doesn’t fall of the radar completely.

Think about the web sites you’ve used yourself, and how your experience when that site encountered errors compares to what you expected it to be. And while you should remember that form always follows function, consider spending some extra time making your error handling a little more charming and funny! I’m a huge fan of funny 404 pages (this is a personal favorite), and you could certainly create a similar experience when your users hit a snag anywhere else on your site.

Contextual help and obvious resolutions make all the difference to a user when they encounter an error within your application, and getting those people back on track quickly will directly affect the successful adoption of your website!