Since the first book on responsive design came out today, I thought I’d share a responsive site I completed recently.  At work we spend a good deal of time making sure our templates are designed with mobile-first techniques that respond to the size of the client’s viewport.  We are also careful to reduce http requests in general and specifically for smaller viewports to reduce load times. I thought I’d try to push out a responsive design on a simple quick-turn blog job.

Desktop rendering of site designed by Bronson

Luckily, the desktop-browser design had already completed by a very talented print and branding designer, Bronson Ma.

Mobile

I also had an early version of Jason Weaver’s responsive WordPress parent theme, Flexopotamus, at my disposal.  So, all I had to to was improvise a few smaller screens and make it work.  You can see the screencaps here, or see it live at Rethinking My Thinking.

Tablet

To learn more about responsive web design read Ethan Marcotte’s article on ALA, or see some examples of responsive design.

My group moves a lot of legacy sites into multisite WordPress.  Quite often we will also map a client’s existing domain and set up redirects so established links will resolve.  We really like using the plugin Simple 301 Redirects, but it does not work with domain mapping.  I’ve added a couple of lines of code to the plugin that allows the plugin to function when a particular site is using domain mapping.

The plugin works the same way as the original, so you can redirect requests to .php, .htm or whatever legacy paths you want to redirect.  Download my patched version at git hub. Thanks to Scott Nellé for writing a great, useful plugin.

A lot of people ask me about WordPress hosting, but this post it not about that.  I was given two t-shirts from WordPress hosting companies at SXSW this year.  I intend to compare these two freebies in a highly scientific shoot-out full of truthiness*.

Color

WP Engine uses one color, but on two sides (2 screens).  Pagely’s design is one-sided, but three colors (3 screens). More screens = more caring: Pagely +1

Distribution

Pagely sent a box of shirts to my office after bumping into Josh at an event.  WP-Engine’s shirts were in one of several piles (not as cool) on a stage (kind of cool).  Pagely +1

Tag

Pagely’s tee had a thoughtful tag printed up that instructs the user to take a photo in the tee and add it to their Flickr pool.  WP-Engine had no custom-printed tag. Pagely +1

Sizes

WP Engine had a full array of sizes available for the taking.  I’m talking, small, large, XL and even the difficult to find ‘medium’.  Pagely only sent L, and XL.  Point: WP-Engine

Blanks

WP engine used a nice Fruit of the Loom Beefy Tee (100% cotton), which is a nice blank.  Pagely went for the American Apparel 50/50 which is very soft and the cut of American Apparel fits me much better (if it were in my size). For the higher-quality blank: Pagely +1

Conclusions

So, there you have it.  The free Pagely shirt is exactly four times better than the free WP-Engine shirt.  There may be something you could read into this about how their model of distribution could reflect properties of their datacenters.  Or, perhaps the lack of smaller sizes indicates one service has more smaller clients.  Those topics will have to be covered in an entirely different post that is not about tee shirts.

* Full Disclosure

I have some sites with Pagely and have actually used their product.  Additionally, I am a Texan and WP Engine is also in Texas.

I ran my 3.1 upgrade yesterday thinking it’d be fairly uneventful coming from 3.0.5. However, I was disappointed to see all the sites on my network were serving corrupt images. Not theme images, mind you, jut the ones that were pushed up though the WP uploader. I soon found that all uploaded media had the same problem.

I got some pointers from a few threads on the wordpress.org forum. A discussion titled Media Library and pics in WPMU don’t work was particularly helpful.

This sort of thing generally means .htaccess issues, specifically the line below being goofed up somehow. (this example is for a subdirectory install and NOT for subdomain-style)

This was not the case, so then you’ll want to check httpd.conf to make sure your AllowOverride is set to All for the directory that the .htaccess file lives in.

I also went through the drill of turning off all plugins and switching to twenty ten theme just to be sure, but without any luck.

After digging a little deeper I found a bug report on TRAC.  After applying a patch to ms-files.php everything is working great again.

The patch clears out the buffer before reading the file.

I don’t know if this will make it into the core, but it certainly helped in my case.  This patch is not in 3.1.1.

I was picking through a WordPress export file today and discovered some garbage in my database.  My immediate reaction was “Oh no, I’ve been hacked!”, but after a quick search, I found this can be the symptom of a user having the Firefox Browser Highlighter add-on installed.

The above was being placed in custom field set up as a WYSIWYG input area.

Asking the offending user to disable the plugin is one fix, alternatively there’s a FCK Firefox Fix Plugin available for WordPress.

Once you’ve installed WordPress in multisite mode. You’ll soon see the screen below when you want to add plugins or themes though the admin area. You can manually enter your FTP credentials each time, or follow this tutorial and enjoy the one-click updates WordPress users are accustomed to.

Your fingers will become fatigued after a round of upgrading.

There’s two steps to this tut. First, create a new user with a it’s own rsa key. This account will only be used for updating WordPress and is named ‘wp-updater’ in this example. Secondly, we’ll add the sftp information to wp-config.

1. Create a new user
Fire up the command line:

2. Add upgrade constants to wp-config.php

You will also want to activate SFTP with the following directive:

Read more about WordPress Upgrade Constants.

Might also have to manually create your upgrade directory depending on your permission scheme:

Securing

Putting your FTP credentials into a file is generally not a great thing to do. However, the time savings may be with it to you. You can take some additional steps to obscure your wp-config file.

• Move it up a directory – Since WordPress 2.-something you’ve been able to move your wp-config.php up a directory (out of you web root) and WordPress will look for it there. I’ve heard tell of some plugins not complying with this, and if you run into that you can try:
• Puting a PHP include in your wp-config – You can move the ‘meat’ of your wp-config to another file and use a php include() to bring it in to your wp-config.

If someone gets into your wp-config, then all they’ll see is this:

 

Hopefully this will help someone.