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:

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!

Hey Designers, Tweak All You Like. Developers Have Sass and Compass.

Developers can all relate to a fast-approaching deadline, and though your plate is already full, your email dings at you and you’re faced with yet another request from the designer you’re working with to change the look and feel of your project.  Swap that background image, add some margin, adjust the kerning, maybe un-serif all of the fonts – but those CSS properties are used across an unfathomable number of UI elements throughout your entire website with 5 different page templates!  I say bring it, and I’m going to show you exactly why.  Keep reading to get the full picture, or skip directly to the code if you’re feeling antsy.

Sass is the next evolution of stylesheets, which allows the use of variables, functions, reusable chunks called mixins, and other cool features that CSS has been missing.  Compass is a related framework that adds functionality and makes working with Sass a little easier.

Designers and developers alike will certainly appreciate how integrating Sass and Compass into your development workflow can make these tweaks as smooth and painless as possible by allowing you to update a style in one place, and have it propagate to all of the CSS rules where that style is used.

Where Designers are Coming From

Look, it’s our job to support designers.  Not because we’re their “code monkeys” – instead, we’re both trying to achieve the same lofty goals our new project has encouraged us to set for ourselves, and that means we need to improve our flexibility to accommodate any design changes as best we can just as they must do.  Designers aren’t making changes to core interface elements because they want to rob us of our time spent catching up on last night’s Jon Stewart or playing Words With Friends.  They make changes because it’s important to the client, or because they are working diligently at achieving a pixel-perfect product for the end-user.  But whatever their reason, we can be sure they are trying to constantly improve the deliverable with each iteration.  The problem is that this can really cost some serious dev time, and potentially risk a project’s scheduled milestone at the last minute.

What a Sassy Website Does For You

Sass is an incredible progression from the powerful (but somewhat dumb) CSS language, allowing developers to set common stylesheet properties as variables in a single place, which makes cascading changes to those properties across your site into a minimal effort.  You will still write valid CSS in your .scss files, as well as the additional features that Sass provides, and those files are then processed by a Ruby script and produce valid and compact .css files.  Setting up a “watched” folder via a few simple Ruby commands enables you to simply save your file and have your stylesheets automagically processed and exported with zero effort.

The previous versions of Sass were dependent on Haml, and had a very non-CSS syntax that is more compact and preferred among many developers.  Before version 3 Sass used the .sass file extension.  Personally, I’m sticking with my normal CSS syntax which still integrates nicely with the Sass language, and uses a file extension of .scss.  As of version 3, the Sass and Haml projects have been split into separate codebases.

Get to the Code, Already!

This article does not cover the installation of Ruby or Sass/Compass because you can find that information on the Compass Docs pages (including a nicely done video from a while back), as well as many other places out on the intertubes.

Once you have Ruby up and running, and you’ve also installed the Sass and Compass gems, it’s time to get to some code!  The following outline will give you an idea of what we’re going to cover:

  1. Create your Compass project from the command line (remember, Ruby must already be installed on your system).
  2. Add a “_base.scss” file for initializing global variables across stylesheets, or even importing a common framework such as 960gs or Blueprint.
  3. Add one or more .scss files for your application’s styles.  This is where you will write your normal CSS code in addition to your Sass code to be compiled.
  4. Now back to your regularly scheduled coding!

Simple, huh?  Let’s walk through it.

Create Your Compass Project

Once Ruby and the relevant haml (Sass) and compass gems are installed, you can create your project from the command line.

[sourcecode language=”text”]
compass create ~/example-www/styles
[/sourcecode]

I chose to put all my .scss files and resulting stylesheets in a directory called “styles” within my web root, but you can choose to put it anywhere you’d like.  You’ll see that Compass has created a directory structure for me, with a directory for my Sass source files, a few example application files for targeting IE and print/screen CSS media types, a directory where our compiled CSS files will be written, and a configuration file called config.rb where we can manage some of the project output locations and such.

Your web root might look something like this:

Additionally, run the compass watch command on the same folder to have your stylesheets automatically processed and exported each time you save your .scss file to disk.  This is a huge time-saver!

[sourcecode language=”text”]
compass watch ~/example-www/styles
[/sourcecode]

Create a Base Sass File

In the “src” folder, create a new file called “_base.scss” which we will use to set some global variables for all of our stylesheets.  Style properties used throughout the site, like branded colors, common border widths, and other values that multiple elements will use should be declared here.

[sourcecode language=”css”]
/*
_base.scss

Put your global variables, and/or any imported CSS frameworks,
in this file.
*/

$default-text-color: #333;
$default-bg-color: #fff;
$heading-text-color: #7eb5e3;
$fat-border-width: 4px;
$skinny-border-width: 1px;
[/sourcecode]

Add Your Application’s Styles

Your source code belongs in the “src” folder, and you may choose to use the default .scss files created for you when your Compass project was created, or you may delete those files and add your own.  For simplicity, we are going to stick with the existing files.  So let’s add some CSS rules to our “screen.scss” file, which will be the primary stylesheet for styles rendered to the screen media type.

[sourcecode language=”css”]
/*
screen.scss

Your application’s style rules go here, and will be compiled to
a new file within your "stylesheets" folder with the same file
name, except that the file extension will now be ".css".
*/

@import "base";

#content {
color: $default-text-color;
background-color: $default-bg-color;
}
#content-invert-colors{
color: $default-bg-color;
background-color: $default-text-color;
}
#header img.logo {
border: $fat-border-width solid darkblue;
}
#content .tagcloud {
border: $skinny-border-width solid lightblue;
}
[/sourcecode]

Check Out Your Compiled Stylesheets

If you used the compass watch command, then your CSS files have already been compiled automatically when the .scss file(s) were saved!  Just look in the “stylesheets” folder and check out the files – they should be ready to link to directly from your HTML.  Otherwise, you’ll need to run the following command to compile the Sass ad hoc:

[sourcecode language=”text”]
compass compile ~/example-www/styles
[/sourcecode]

Using my Sass example above, the CSS result should look like this:

[sourcecode language=”css”]
/*
screen.css

This is the compiled CSS from our Sass code.
*/

/* line 11, ../src/screen.scss */
#content {
color: #333333;
background-color: white;
}

/* line 15, ../src/screen.scss */
#content-invert-colors {
color: white;
background-color: #333333;
}

/* line 19, ../src/screen.scss */
#header img.logo {
border: 4px solid darkblue;
}

/* line 22, ../src/screen.scss */
#content .tagcloud {
border: 1px solid lightblue;
}
[/sourcecode]

And that’s that!  I’ve described how the Sass/Compass frameworks can improve the workflow for managing stylesheets, and demonstrated a simple example of writing some “Sassy CSS” to create manageable styles that can be updated across multiple files and elements in a snap.  Have fun making your website a little Sass-ier, and let your design buddies know that you’re open for requests!

Further Reading

All My Children and CSS3

I know, I’m just lobbing titles over the fence these days, but it’ll make more sense in a moment.  The SXSW Interactive Festival 2011 is beginning, and I’ll be there with badge on!  Some of the other Springbox crew members will also be there, including several talented individuals who are speaking.  Check out our SXSW 2011 page to catch up on the fun stuff, and grab yourself a request to our super rad party on the balcony of the W Hotel.  Springbox has some of the brightest minds in interactive, and we’ve got an open bar, so … yeah!

While I was HTML-ifying our SXSW page a little while back, I came across the requirement for a nice semi-transparent background for a floating div.  It was to have sharp, fully opaque text, play well with our chosen TypeKit fonts, and partially reveal the cool photo behind it exactly how the designer mocked it up.  This is such a common request, and a cool effect.  But until recently, web developers have always had to work pretty hard to achieve such a simple treatment in the browser.

Opacity has been tough because the default behavior of the CSS opacity property is to not only affect the transparency of the element it is set on, but also all of it’s children.  (See?  Full circle.  Bam.)  But this isn’t the effect we want in this case, and in the past I would resort to some positioning tricks using relative positioning or negative margins to simulate that effect.

Enter CSS3 and the rgba() syntax, which allows as to set opacity using a fourth parameter after the RGB values.  This will only change the opacity of the element it is set on, and it’s children will remain fully opaque!

Only WebKit, Gecko, and Opera browsers currently support this feature, basically all but IE (as usual).  But IE does have a workaround (aka hack) that somewhat works in IE7/8.  Before I give you the code, here are the issues you should be aware of when using this hack:
  1. Requires the infamous hasLayout property in IE to be set to true.  Use “zoom:1;” to cause IE to set this value.
  2. Using the Microsoft filters disables ClearType, and so you may notice blurry text with certain fonts, weights and sizes.
  3. Uses hex code for the alpha level instead of the standard 0 to 255 value.  It’s annoying, but you can do a quick calculation to get the converted hex code.

    Thanks to Kilian Valkhof for this rgba/#ARGB converter code snippet!

Ok, and here’s the CSS code.  I keep it in my screen-ie.css file which is conditionally loaded for IE 8 and below only.

Basically, we have to use Microsoft’s gradient filter to set the same start and end colors (so effectively there is no gradient at all) along with their option for setting the opacity hex code via the first 2 characters of the color string.  IE9 will support rgba(), however.

So that’s how it was done!  Find me at SXSW in Austin this weekend, or follow me on twitter (@grantnorwood).  The weather is beautiful and I know this town is going to pull off another super rad show for developers, designers, and the other brainy and creative types swarming in.  Welcome to my hometown everybody, and be sure to catch plenty of Texas blues with your Texas booze!

Making QR Codes Mainstream

You are fascinated by a painting you’ve discovered, and want to see more of the artist’s work.  You’ve been pricing a new toy at Best Buy, but need to see which stores carry it in hot pink.  You are walking past a billboard for the hippest band in town and want to add it to your digital calendar without skipping a beat.  Maybe you’re even reading an article about QR codes on your laptop, and want to quickly take it with you and share with a friend.  Manufacturers and marketers have been steadily dropping more of these blocky barcodes all around us, but do you know how to use them yet?

Scanning this QR code will take you to https://grantnorwood.com/.
Scanning this QR code will take you to https://grantnorwood.com/.

A QR code (quick response code) is a simple 2D barcode that holds 4 to 10 times the information compared to that of the standard barcode format.  And while QR codes were first used for tracking inventories in Japan, the uses of this openly standardized barcode format have become almost limitless, especially in the marketing world.  QR code readers are available for most every smartphone platform (for free), and with a simple point and snap with your phone’s camera, you can be transported to a URL to find out more about a new product or automatically add a colleague to your contacts list.

So if QR codes are so easy to use, and extremely useful to most anybody with a smartphone, why doesn’t everybody use them in their daily life?  Simple, we haven’t crossed that chasm yet.  In “Crossing the Chasm”, a marketing book by Geoffrey A. Moore, he describes 5 primary segments of technology adopters, each having their own traits, and each called to action by something different.  Technology Adoption LifecycleThey adopt changes to the technology in their life at different rates, each segment building on top of the momentum created by previous segments.  And while there is already huge value to using QR codes across the web, print, mobile and social mediums, we’re still very much in the early adopter phase.  This is no different than the advent of CDs or the daily usage of Facebook.  How long does it take you to switch over to what’s new, and how does that compare with others around you?

As a developer for interactive marketing agency Springbox, we most recently used them to announce our free holiday-themed wallpapers for mobile devices, and often pitch QR codes to clients who are looking for the coolest new way to connect with both new and existing customers, and quickly direct public interest to their campaign.

The good news is that QR code technology is simple to use, and it’s free!  With free apps like ZXing’s Barcode Scanner for Android, Ricoh’s iCandyMobile for iPhone and iPod Touch, or BeeTagg for BlackBerry, there are few obstacles to being able to scan codes easily from a mobile device.

All of us can be consumers of QR codes, but there is a chasm between early adoption and the beginning of mainstream.  This is where exponentially rapid adoption becomes a requirement to cross over to the Early Majority phase, or risk fizzling out.  Barcodes are not human-readable, so they may appear difficult to use.  But the action of snapping a QR code can save precious moments many, many times over.  It’s the difference between the grocery clerk manually ringing up every item’s price on paper, or scanning your cart’s items using a sophisticated barcode and reader.  And in the marketing world, fast engagement is key to staying relevant to the customer and improving conversion rates.

When users discover how they can create their own QR codes from major websites like Google’s ZXing project and Kaywa, or send them as coupons in their email newsletters using MailChimp, they will not only better understand what is available to them, but innovators will keep pushing the envelope with what the technology is capable.  This is demonstrated simply by the evolution that has already occurred, where barcodes for scanning automobile parts have been repurposed for other industries and consumed by the general public on advertisements, hockey game programs, t-shirts, and not surprisingly, food.

So if you want to help take QR codes from “that’s cool” to “I gotta have it”, just start scanning!

Show your friends and your family what you’ve learned, and help them get a reader on their device so they can enjoy showing up early to the party this time.

Be a champion amongst your co-workers by suggesting some of the many business applications of 2D barcodes, and proving how much value QR codes create for your company and your customers.

SXSWi 2011: My Topics of Interest

Springbox is sending a dozen employees to this year’s SXSW Interactive festival. So we asked them: “What topics are you interested in learning more about at SXSW Interactive?” Here are Senior Developer Grant Norwood’s topics of interest.

I’m going to take the non-profit route at this year’s SXSWi. I volunteer my time and talents to several non-profit organizations because I share a belief in their causes and I support the ways in which each execute upon their respective missions. But more than that, during SXSWi, I want to narrow my focus within the almost overwhelming choices of panels offered.

I’ve spent much of my career in the enterprise and product development worlds and I’m programmed to keep an eye on increasing revenue and reducing costs within any business environment.  By eliminating the distractions of my natural interests with my non-profit strategy at SXSWi, I’ll have a comfortable and comprehensive list of panels I can attend without feeling spread too thin. Here are my overall areas of interest:

Non-Profit Branding

It’s no surprise that every non-profit needs to market itself in order to be successful. I’m looking for answers to these questions:

  • How does one take their charitable organization from a moderately successful size with loyal users to one with exceptionally rapid growth and a fully mainstream presence?
  • How does a non-profit organization build and leverage public partnerships with other successful brands and personalities to better achieve its mission?
  • How does partnering with other for-profit organizations benefit the partner, and how does one best approach those partners for their support?

Attracting Talent and Growing a Team

Whether you’re building the next great product or saving the whales, a talented team of individuals can make or break your organization and its endeavors, and how are teams of volunteers are managed differently than those made up of paid employees.

Measuring Success

How does one know when their efforts are paying off, when their message has been received and where they can improve? I’m not just talking donations and ROI here; I want to know more.

Article originally published by Springbox at http://www.springbox.com/insight/post/SXSWi-2011-Grant-Norwoods-Topics-of-Interest.aspx.

HTML5 video brings cool new features, same old fragmentation

I was excited to spend some time digging into the new video features of HTML5 recently.  My mindset has been that once HTML5 becomes the standard, browsers are finally going to behave better and conform to the web standards more closely than ever.  The reality is that the same old problems that have long plagued web developers still exist, and may become more prominent than ever with HTML5.

After the launch of a new website the other week, we had reports of the embedded video not playing correctly on some iPhones, even when using the latest iOS4.  I hadn’t done the research or development on the video feature for this project, so I ramped up on the implementation details quickly with the help of one of the original developers, and then set off to diagnose the problem.

Chiefly, I needed to define the bug (aka an “unexpected feature”) a little better.  The HTML5 video element (using .m4v and .ogv sources) is displayed in a modal window when the thumbnail is clicked, and while the desktop browsers all pass beautifully, the various mobile devices (iOS devices specifically) were hit or miss.

I tested on the devices that were used by the reporters of the bug, as well as with some of the other mobile devices laying around the office for better context.  All of the desktop browsers worked fine, as multiple codecs were used along with the HTML5 video tag to properly support Chrome, FireFox, and Safari, and an elegant Adobe Flash fallback was done for IE (IE7 and IE8 do not support HTML5 at all).  Only iOS was correctly displaying the modal window, but failing to play the video on some devices.

The devices I tested with include:

  • iPad (iOS 3.2.2)
  • iPhone 3G  (iOS 4.0)
  • iPhone 3GS  (iOS 4.1)
  • iPhone 4  (iOS 4.1)
  • iPod Touch  (iOS 3.2)

Here’s how I worked through it.

The Problem

  • iPhone 4  (iOS 4.1) works fine.
  • All other iOS versions and devices showed the poster thumbnail for the video, but the play button was crossed out, indicating the video was not playable.

The Analysis

  • The page was using textbook HTML5 code to declare a video element along with 2 separate source elements, an MPEG4 and an OGG, each with mime types and codecs declared.
  • The HTML5-compatible desktop browsers were running the video, so the code was at least syntactically correct.
  • The web server was sending the correct mime-type for both the .mp4 file and the .ogv file.
  • The root cause is likely a codec or player issue, not a code or mime-type issue.
  • Either the file was not encoded in an acceptable format, or the set of failing iOS devices were not able to correctly detect the (correct) format of the video file.

The Solution

Re-encode the file!  I know from some basic video production experience that file formats, video players and transcoders can be finicky.  Since a few code changes weren’t doing the trick, and the mime-type HTTP header was already being sent, the video file itself just seemed to be the next likely culprit.

Here’s a great article on mobile file formats.  I was most interested in the MP4 knowledge, and since I didn’t know which profile was used when the video was encoded, I decided to re-encode the video using the “baseline” profile.  The H.264 Baseline Profile is compatible with a broader range of devices, while the High Profile has better quality.  It made perfect sense that iPhone 4’s would play the newer, better quality video format, and that my 3GS (though running iOS 4.1) would be more likely to support only the Baseline Profile.

I used HandBrake to go back to my original .mp4 source file, and it quickly churned out my new video file in no time at all (they give us some pretty rad hardware at Springbox!).  With my new .m4v file (notice the different file extension) in hand, I updated our staging server and got the QA team started on approving the fix for production.  I had also removed the “type” attribute from the .m4v file’s source tag for better Android support, even though we weren’t officially supporting Android.

The fix was confirmed by QA, the new video file was pushed to production, and the client was happy.  All in a good day’s work.  However, in troubleshooting this issue, I’ve found that the HTML5 spec is really not locked down very well at all, and the fragmented support of current browsers (desktop or mobile) make development arduous and troublesome, especially across the ever-growing array of mobile devices.  This is nothing new for web developers, who’ve fought some hard battles with their software tools and technologies, even as some have matured into standards.  For now, those of us who publish video to the masses should get used to encoding videos in 2 or 3 formats (at least) and hacking code to make it work on everybody’s device.

Vendors, developers and clients alike aren’t waiting for HTML5 to be finalized.  In fact, they’re chomping at the bit because it’s new and cool (and they are right!).  An official with the W3C has been quoted as saying that they “want to be feature-complete by mid-2011”, which seems like a long way off.  But while HTML5 and it’s features were originally sold as a solution to the compatibility nightmare that is cross-browser web development, I’m finding that developers will need to wait a little bit longer for our jobs to get easier.  In the meantime, all of us code ninjas will need to continue doing redundant development to make things work for everybody – as usual.  But the results will be rewarding, and the client will be happy!