Cluster Fudge: Recipes for WordPress in the Cloud (WordCamp Austin 2014)

About a month ago, I gave a talk at WordCamp Austin 2014 about running enterprise-class WordPress in clustered, cloud-hosted environments. Thanks to all who attended, and for your great questions! While it was standing room only for “Cluster Fudge: Recipes for WordPress in the Cloud”, I hope that everyone who wanted to get in was able to see my presentation.

I’d love to keep the discussion going, so feel free to offer your own best practices and tips for success in running WordPress in the cloud at scale! You can leave comments at the bottom of the page.

About a month ago, I gave a talk at WordCamp Austin 2014 about running enterprise-class WordPress in clustered, cloud-hosted environments.  Thanks to all who attended, and for your great questions! While it was standing room only for “Cluster Fudge: Recipes for WordPress in the Cloud“, I hope that everyone who wanted to get in was able to see my presentation.

I’d love to keep the discussion going, so feel free to offer your own best practices and tips for success in running WordPress in the cloud at scale!  You can leave comments at the bottom of the page.

Overview

Your self-hosted WordPress site is quickly growing in popularity and page views. Or maybe you want to get away from that costly enterprise CMS currently on your plate and adopt a delectable, open-source platform. There are many reasons you might need the performance and redundancy of a clustered server solution, and I’ll show you how to mix up the ingredients needed to throw together a successful cloud-hosted WordPress environment that’s right for you.

We’ll talk about common multi-server configurations, from cheap and quick for the cost-conscious business, to robust and complex for the high level of control an enterprise demands. You will leave with a better knowledge of which web server makes sense for your requirements, and learn some tips and tricks to better caching without sacrificing the dynamic nature of WordPress.

Downloadable code snippets and example config files will help get you started in your own cloud environment.

Example Code and Configuration Files

Visit my GitHub repo for examples of server configuration files optimized for WordPress, and PDF versions of my slides with speaker notes.

Slides

If you missed it, you can view my slides embedded from SlideShare below.

 

Adjusted Bounce Rate WordPress Plugin released!

I’ve just released a new WordPress plugin for better tracking of adjusted bounce rate, time on page, and time on site metrics in Google Analytics!

The problem is that Google Analytics does not properly track some important engagement metrics like Avg Time on Site, Avg Session Duration, and Bounce Rate. This plugin enhances a commonly-accepted JavaScript method of improving the accuracy of these stats, but with some extra features and options.

Adjusted Bounce Rate WordPress Plugin

I’ve just released a new WordPress plugin for better tracking of adjusted bounce rate, time on page, and time on site metrics in Google Analytics!

The problem is that Google Analytics does not properly track some important engagement metrics like Avg Time on Site, Avg Session Duration, and Bounce Rate. This plugin enhances a commonly-accepted JavaScript method of improving the accuracy of these stats, but with some extra features and options.

This plugin addresses the issues as identified by the Google Analytics team at http://analytics.blogspot.com/2012/07/tracking-adjusted-bounce-rate-in-google.html.

Features

  • Set the engagement tracking event interval. (Defaults to 10 secs.)
  • Set the max engagement time, which allows you to customize when the session should be considered abandoned. (Defaults to 20 mins.)
  • Set the minimum engagement time, which can be used to set an initial amount of time required to count the user has having engaged. (Defaults to 10 secs.)
  • Customize the event Category, Action and Label names to be displayed in Google Analytics.
  • Uses either the old pageTracker code, the newer asynchronous code, or the newest Universal Analytics code.
  • Choose header or footer placement for the code.
  • Compatible with Yoast’s Google Analytics for WordPress. For example, detects if analytics were loaded, or if they are disabled because of the currently logged in user’s role.

Download

This plugin is available from the WordPress Plugin Repository at http://wordpress.org/plugins/adjusted-bounce-rate/, and from GitHub at https://github.com/grantnorwood/adjusted-bounce-rate. Please submit issues to the GitHub repo for the fastest response!

Screen Shot

Adjusted Bounce Rate WordPress Plugin

A fix for outbound & download links not working in Yoast’s Google Analytics for WordPress

The Problem

I just noticed on one of my sites that some download links to PDF, zip, and other assets had an almost total drop in download events in Google Analytics after a recent Yoast Google Analytics for WordPress plugin update.  So I began to troubleshoot …

Track outbound clicks and downloads is enabled in the Yoast plugin settings
Track outbound clicks and downloads is enabled in the Yoast plugin settings.

The firing of trackEvent() is handled by the popular Yoast Google Analytics plugin, which automatically adds onClick() javascript handlers to fire the correct event for <a /> tags, and uses the GA Event Category of “download”, and the domain or full URL to the file (determined by your plugin settings) as the Event Action.  It had worked for over a year, and is working normally on our other web properties, all of which use the same latest version of the plugin Google Analytics for WordPress plugin.

I enabled Debug Mode with the Yoast Google Analytics plugin and set the option to log all users. I typically prefer not to skew my reporting with administrator traffic, but in order to see the Debug Mode output in your browser’s javascript console, you must select the “Ignore no-one” option on the settings page.

Set ignore users option to "Ignore no-one".
Set ignore users option to “Ignore no-one”.
Enable debug mode for browsers with Javascript consoles, or alternatively, you can use the Firebug Lite feature.
Enable debug mode for browsers with Javascript consoles, or alternatively, you can use the Firebug Lite feature.

I was then able to monitor the console and see the Google Analytics pageview event fire, however, I did not see the “download” event fire.  I was stuck.

The Solution

It was a partner of mine, Colin Alsheimer from Weber Shandwick (@colinize on Twitter) that figured out the root cause:  relative URLs in the download links.

The tracking beacon finally fires successfully when using fully qualified URLs, not relative URLs.
The tracking beacon finally fires successfully when using fully qualified URLs, not relative URLs.

When I viewed the source code of my site, I could see that only the download & outbound links with fully-qualified URLs had onclick handlers attached in order to properly fire _trackEvent() attached, and not the links with relative URLs. After updating my page to use the full URLs, those download links immediately began working again, and I was able to see the event fire in the debug console as well as show up in my GA real-time event tracking.

Success!  The root cause of this seems to be a bug in the Yoast plugin as GA should allow any text string – relative URL or not – as an event action, and I’ve reported the issue to them in the WordPress forums.  It seems that the “link sanitization” feature that rewrites relative URLs with full URLs was added to the plugin in v4.0.2, however since then it has stopped adding the click event handlers to links with relative URLs.

The moral of the story is that relative links rarely come back and bite you, and they are so convenient when moving content and code between environments.  But the cost of that convenience is a very small chance that not using a full URL will break something, and it may or may not fit your individual tolerance for risk.

Have a comment about using relative links in Google Analytics event tracking?  Help others out by posting below!

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 msdf.org/robots.txt 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.  https://productforums.google.com/d/msg/webmasters/mY75bBb3c3c/ARQqAWOf_6YJ

 

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!

Official Facebook for WordPress plugin released!

You can find the new Facebook for WordPress plugin in the WordPress Plugin Directory, or read more about Facebook and WordPress on the developers page.

You can find the new Facebook for WordPress plugin in the WordPress Plugin Directory, or read more about Facebook and WordPress on the developers page.

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.

Checklist

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’, ‘www.your-website.com’); // 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: