The Evolutionary Process of Mobile Browsing on WordPress

Two Calls

My first rant, though certainly not my first try

A couple of months ago, I wrote about the trials and tribulations I had encountered and failed to overcome in regards to making WordPress a little more mobile-friendly. I’m not a coder or even a web developer/designer (though I sometimes pretend to be at work), so beyond using the tools and guides provided and tweaking some code, I’m at a loss for how to redo everything and make it work myself. Unfortunately, the tools that existed didn’t play well together and therefore didn’t serve my purposes for providing a fast site that also worked on mobile browsers.

When I wrote about my failed attempts, I learned that the coder, patrias familias, and maintainer of WP Super Cache, Donncha O Caoimhm, modified the plugin to allow mobile developers to add a filter to their code that would tell WP Super Cache to cache and serve data differently depending on certain variables, but no one quite picked up on it or modified their plugin to work in conjunction with WP Super Cache. And since WordPress almost isn’t worth running without WP Super Cache, it was sort of a wash.

A New Hope, Another Failure

As you may recall, I thought I had found a solution in the form of the WordPress Mobile plugin earlier this month, but it too failed. The problem is that you don’t just want a different stylesheet for mobile content; if that was all, there’d be no issue because WP Super Cache doesn’t cache styles, just content. But on mobile devices, you don’t have room or time to load everything, so you really only want to serve the content that is pertinent (blogrolls, for instance, might be nice, but you don’t want to have to scroll past that on a tiny mobile screen). Therefore, plugins that serve content to mobile devices also use a different theme for those devices, and when that theme gets cached, it then ends up being displayed to regular web browsers. WordPress Mobile, like all the other mobile plugins, weren’t using the filter in WP Super Cache to cache and serve their content appropriately.

Eureka! At last!

Donncha has just released version 0.9 of WP Super Cache, however, and this one takes into account user agent strings to identify mobile browsers by using the detection code from Alex King’s WordPress Mobile Edition. I began testing this on SilverPen yesterday using developmental versions of both WP Super Cache and WordPress Mobile Edition, and after identifying and working out a single bug (Donncha worked it out, of course, not me!) it appears to be working great! We ran into a snag where Safari on Mac was being identified as a mobile browser, but Donncha had that fixed before I could even get him the log files.

A new version of WordPress Mobile Edition has not yet been released, and I’m not entirely sure it needs to be. The caching and UA checks are being handled by WP Super Cache now to decide what to cache and serve, so not only should your choice of mobile plugin be irrelevant, it should also Just Work™.

Give it a try and let me know what you think!

Download WP Super Cache

Download WordPress Mobile Edition

Image by: lusi

Why I Should Stop Doing Web Development

MAMP does make my failure come faster, at least.
MAMP does make my failure come faster, at least.

A few weeks ago, I got home one evening all jazzed up to hack the Carrington Theme on a local web server I set up on my Macbook. I had some definite ideas for how I wanted the front page to look, so I wanted to edit the theme and achieve my vision.

Three hours later, all I had to show for the effort was having cut it down to a single sidebar and moved that sidebar over a bit.

It all makes me feel pretty stupid, because I work with computers for a living and feel like I should be able to “just get” this.  After all, I’ve built numerous web servers, personal computers, and am experienced with a variety of different operating systems, programs, and web platforms. But when it comes to coding a page, once we get beyond HTML, I’m practically a goner.

That’s the main reason I began using Content Management Systems (CMS) after all. Beyond a simple, relatively ugly page, I can’t create that good a website.  I should just stick to creating the content that the management system manages.

One of my resolutions this year is to write and publish a book, and I’ve got a few other projects that will hopefully come to fruition that I’m not ready to reveal yet. I’m not going to get all this work done if I keep screwing around with stuff I’m not good at, though. If I invest all of my time and energy into something I’m not good at, like web development/design, then there’s no time/energy left for the things I can do well, IE writing what I want to write.

It has become a guiding philosophy for me in the last couple of years that one should gauge and recognize their own strengths and weaknesses, learning to get the most out of what they can do, rather than trying to exceed their limits or waste time doing things poorly. The only metaphor I have for this is in regards to fantasy fiction and wizards: a low-level wizard who knows how to use their power well will be able to apply it creatively and to great effect. In so doing, they may outperform a significantly more powerful wizard who is not creative and doesn’t use their power wisely; instead, the more powerful individual wastes their power because they don’t know how to use it, and the comparatively weaker of the two outshines them.

I can accept not being that great at something, but it means that I need to stop focusing on those projects that I just can’t do well. I’ll produce content, and if I have to someday, I’ll hire someone else to do my web development. For now, WordPress and Alex King’s contribution is good enough for me, and with the few minor tweaks I’ve made to it, it’ll manage my content just fine.

WordPress not quite ready for mobile browsing

Instead of redacting this entire entry, I’ll let you know that mobile browsing for WordPress does work now. See my updated article on The Evolutionary Process of Mobile Browsing on WordPress for more details.


One of my design goals for revision 3 of SilverPen Publishing was to make the site more accessible. I’m not a web developer by trade and didn’t really know how to do this, but I knew that I didn’t want to exclude people from visiting my corner of the web. To me, this didn’t just mean making SilverPen more friendly to screen readers and other assistive technology devices, but also to make the site work well on mobile devices.

To this end, I found yet another great plugin by Alex King that queries the user agent of the browser trying to access the site. If it’s a mobile web browser, the plugin serves up a custom template that’s very lightweight and fast to load on mobile devices. It worked very well, but unfortunately it only worked in a vaccuum, and even then had some serious repercussions.

WP Super Cache

First off, it simply does not work with WP Super Cache, and in fact, no mobile browsing solution does. For those who haven’t heard of Super Cache, I’ll explain what it does and why it’s necessary very briefly. Every blog post and page that WordPress serves up is dynamically generated on the fly when you access the site. Putting all the pieces together to make a web page puts a lot of load on the server, and it makes the page load a lot slower for you. Caching allows the server to create static pages, rather than dynamic ones, of the same content and therefore serve it up faster. This reduces load on the server and makes the page load a whole lot fast for you.

Because of how WordPress works, this caching is pretty much vital to running a site on WordPress. My traffic’s not that high yet, but it has more than doubled in the last few months, and I expect it to continue increasing at a similar rate. The last thing I need is Bluehost freezing my site temporarily due to a sudden spike of traffic, so like all good WordPress bloggers, I use WP Super Cache.

To make a long story short, WP Super Cache creates a copy of a page the first time someone visits it. Each subsequent visitor is shown that copy, and this is what breaks WordPress Mobile Edition. Since you’re viewing a static copy of the page that has already been generated, you don’t see the mobile theme, rendering the mobile plugin useless.

If it’s a choice between having the page load more quickly for most everyone and reducing the load on my server vs. having the site more accessible on mobile devices, I’m going to have to go with the former. Especially as data plans move towards 3g and faster mobile browsing.

Search Engine de-Optimization

The second reason that mobile browsing fails for WordPress is because it kills SEO, which harms your ranking in search engines. By its very nature of essentially serving a different set of pages to mobile devices, plugins such at WordPress Mobile Edition fool search engine robots into thinking there’s a second website with duplicate content on it. Such duplicate content is ranked down by search engines, which means your pages are less likely to turn up in searches and you’ll get less traffic.

The mobile plugins and solutions for WordPress all admit that it’ll kill your SEO and recommend you “do something” about it, but don’t offer many solutions. I thought I had found an elegant work-around yesterday in the form of themed multiple domains in WordPress, which would allow me to have multiple domains pointing at a single instance of WordPress, wich each domain triggering its own theme. In this instance, you can easily redirect robots that hit those other domains to a separate robots.txt file, which would tell them “don’t index this site.” For example, if I had silverpenpub.net and m.silverpenpub.net (for mobile browsers), I could have the main site indexed and tell the robots not to index the mobile site.

But I don’t want to register a separate domain for mobile browsers, and I couldn’t get it to work with a subdomain for some reason. Maybe I was doing something wrong there and will figure it out eventually, but it’s not going to happen today.

Not worth my time

In the end, trying to twist WordPress into working on mobile devices doesn’t give a  lot of return for the investment, and I’m beginning to think it will be a non-issue before too long. Even I am beginning to dream nightly of acquiring an iPhone, and browsing with a 3g connection means that, even over a cellular data plan, you can load a site quickly. And newer phones have a lot larger screens, which means that my theme displays fine all on its own.

I know that WordPress now has a iPhone-friendly administrative interface, and I hope that they include more features in the future to help their platform run better on mobile devices. Accessibility is still important to me, but I can’t justify 5-10+ hours of work to make the site more accessible to 0.5% of readers by introducing “features” that degrade or break the site for the other 99.5%.

Carrington 1.3 has been released

If you pay attention to your WordPress Dashboard (I notice mine every 2-3 days), you might have seen that version 1.3 of Carrington has been released. Carrington is the theme I use for SilverPen Publishing, but it’s more than a theme: Carrington is a unique shift in theme framework development and finds itself in a significantly more advanced category than your standard WordPress theme.

Simply put, it’s all kinds of wonderful, and I’ve really enjoyed having its style represent SilverPen Publishing. However, I have had to make a few tweaks to the theme, and when faced with an upgrade, I was hesitant to recommit myself to that task. All of those changes would have to be made once again, and I didn’t take notes on what I had edited because I didn’t think I’d have to do it again any time soon, let alone with this theme.

Most theme publishers write a theme, put it out for public consumption, and leave it. I never expect upgrades of a theme unless a major change in WordPress outright breaks the theme, and even then it doesn’t get upgraded most of the time. Alex King‘s a champ, though, and stands by his work. If I could laud him any more highly I would, but for now my praise and recommendation will have to be sufficient. Such dedication caught me by surprise though, hence the lack of notes.

Because there were some important security upgrades in this version, I went ahead and upgraded after backing up my current theme, and then spent some time going through and changing what I needed to. In addition, I actually took notes this time as I went, and I’m going to go ahead and post them here. As I read in someone else’s blog recently, notes for me, notes for you.

Reasons to upgrade:

From Alex King’s blog:

Version 1.3 of Carrington Blog is now available for download.

Upgrading is strongly recommended due to a security patch in this release.

This version has a couple of changes – both bug fixes and new features:

  • Added an image.php file for displaying media. This is not yet abstracted into the framework, but will be in the future.
  • Added a field to the settings page for adding in analytics code.
  • Fixed a problem with IE7 and the dropdown menus.
  • Explicitly send headers with AJAX responses, hopefully fixes some issues reported by Safari users.
  • Added a Log In link to the header.
  • Added code to load in translations.
  • Updated documentation.

Continue reading