URL rewriting is what mod_rewrite does. 

It’s an engine that helps redirect a visitor that comes for one URL to another page on the same site or another server. If you are using WordPress with some friendly-looking URLs, you are using mod_rewrite. 

Thankfully, WordPress does most of the heavy lifting with pre-built rewrite rules because the syntax is a little unfriendly to the beginner: It combines all you hate about regular expressions with all you hate about having your brain stabbed by rusted forks. 

My Problem and Need for mod_rewrite

I’ve been moving from my old domain, ChristopherSchmitt.com, to this one, Christopher.org.

I still have ChristopherSchmitt.com “live” on a server as I work on finishing some migration tasks.

Visitors might stumble onto pages on the old site and stay there. Instead of that happening, I’d like visitors that do come through the old site go to the new site and read the content there. 

That means working with mod_rewrite!¹

First mod_rewrite Workaround

If my new domain’s URL structure was an exact mirror of my original site, I could set up a simple redirect from the old domain to the new domain. 

For example, if I had a URL for my old site:

http://christopherschmitt.com/2015/07/21/i-cant-complain/

And new URL for the new domain is:

http://<strong style="background: yellow;">christopher.org</strong>/2015/07/21/i-cant-complain/

The mod_rewrite is relatively straightforward to code up.

To do that, I add the mod_rewrite rule in the .htaccess file which is in your site’s root directory — and is two lines of code:

RewriteEngine On
RewriteRule ^(.*)$ https://christopher.org/$1 [R=301,L]

The first line tells the server to turn on rewriting engine.

The second line does the heavy lifting: it gives the server information on how to process a request from the browser, i.e. the incoming URL, and what do with it, i.e. form a new URL. 

When that is added, the links will redirect — however, my problem is a bit different than that.

Little More Complex mod_rewrite Examples

While moving content to Christopher.org, I want URLs without the date. I changed WordPress Permalinks settings to remove the date in the URL:

https://christopher.org/i-cant-complain/

That result of this decision means my URL structure for my new domain does not match up perfectly with the old domain.

OLD URL: http://christopherschmitt.com/2015/07/21/i-cant-complain/
NEW URL: https://christopher.org/i-cant-complain/

So, the rewrite needs to be updated to reflect that. 

To do that, I would have to use mod_rewrite to grab only the bit of the old URL I need. Thanks to Adam Norword for helping me out with the rewrite rule and sparing me from the regular expression hell I was in: 

RewriteEngine On
RewriteRule ([^\/]+)\/$ https://christopher.org/$1/ [R=301,L]

Let’s look at the lines to see what is going on: 

1. The first line only has RewriteEngine On and it turns on the rewriting engine in the server.
2. The second line starts off with RewriteRule and says we are going to have a rule on how the server should handle incoming links.
3. ([^\/]+)\/$ tells the server to grab just the slug title of the page or post by grabbing the end portion of the URL.
4. https://christopher.org/$1/ — this tells the server to grab that title of the page or post and append it to the new domain to create the new URL
5. [R=301,L] this section tells the browser to signify the code is a 301 direct. Using 301 redirects is a method recommended by Google to let them update their listings.

Further Reading on mod_rewrite and WordPress Permalinks

At one time, I was thinking of diving into WordPress to update the Permalinks to add the redirection I needed. At a recent Austin WordPress meetup, I saw a great presentation on Advanced Permalinks in WordPress by Pete Nelson that shed some light on such an approach.

While I didn’t go that route, his presentation did let me know about some great WordPress resources: 

• Rewrite Rules Inspector WordPress Plugin
• Debug Bar WordPress plugin

And Adam showed me Regular Expression 101. It works as a regular expression decoder: taking regular expression formulas and decoding them into human-friendly language.

---

^{1. If it was one off page, I would use meta HTML element with refresh.↩}

Like the James T. Kirk character in Start Trek, I don’t believe in no-win scenarios.

That is until I come across the idea of adaptive images in responsive web design.

In Mat “Wilto” Marquis’article, he reviews the trials behind the Boston Globe redesign project to get images served in an adaptive manner — meaning that the proper, optimized image is delivered to the appropriate device based on the following factors:

• screen resolution
• bandwidth
• browser window width

The problem with trying to determine the best image to send to the browser is these kinds of factors can be independent of each other. 

And that wherein lies the problem: knowing the value of one item, like screen resolution, doesn’t mean you get the full picture of the user’s browser experience. 

Tiny Displays

First, the iPhone 4 introduced the notion of retina display (640×960 resolution at 326 pip). Before the iPhone 4, one might have gotten away with letting just the browser width. That roughly translate to the axiom: 

The smaller the screen, the slower your internet connection.

However, that’s not the case as displays are becoming great at compacting lots of image data in a small screen. 

Thought Experiment

Let’s think of this problem in another way with the following thought experiment:

The iPad 3 that is rumored to come out in the Spring of 2012 will have retina display that rivals most desktop displays and will no doubt have 3G models.

Also, since the screen of the iPad is going to be presumably the same dimensions as the iPad 2, the browser “width” is going to be the same. 

So, realizing that the browser width isn’t helpful and if a site visitor is surfing the web on an iPad 3 with 3G, which image do you deliver on your site? 

• Do you deliver the low-resolution, mobile friendly version? 
• Or do you let the iPad 3 have the larger version, but with the longer download time? 

Measure a Few Additional Times, Cut a Couple More

If you are building a complex site the size of the Boston Globe, you can follow their lead.

The best solution that’s agreed by most current solutions is to set “mobile friendly” images as the value for SRC attributes for image elements. 

Then set the URL to the high-resolution image as a value an HTML5 DATA- attribute.

<img src="images/mobile-size.jpg" data-fullsrc="images/desktop-size.jpg"/>

Then setting screen-size in a browser cookie, you can use server-side requests to deliver the appropriate image to the right browser. 

A variation of the solution called, aptly, Adaptive Images in HTML aims to keep HTML pure while utilizing PHP, JavaScript and modying .htaccess files.

If you aren’t into hacking .htaccess files to serve image files, you can look into a cloud-based service for the solution for some help.

The folks closest to this at Sencha have just a solution at src.sencha.io for scaling images, but not for replacing high-resolution images for the site visitor when it’s appropriate. 

If the service added a feature of checking and delivering the appropriate image in addition to context aware images, I think the folks at Sencha would have a great hit on their hands.

And they might have another revenue stream along the same lines as people that rent out web fonts.

Back to Old School

If you are working on a smaller scale web site, I humbly recommend a solution I’ve been working on called HiSRC.

It’s a twist on the old school LOWSRC IMG attribute, which would render a lower file size image first while a larger file size image would appears in its place later.

Back to the future, we set in the markup and leave the lower file size image. 

However, if the HiSRC plugin detects fast network or high resolution, then a high resolution image takes the image’s place.

The browser loads the low-resolution image first with an old-fashion IMG SRC attribute. 

Then the HiSRC jQuery plugin checks the resolution of the browser. 

If the browser resolution is wider than the default 640 pixels width, then the plugin overwrites the low-resolution image for the higher resolution image. 

Whereas, if mobile bandwidth is detected (like 3G), the low-resolutions stay in place thanks to the new navigator.connection first seen in Android 2.2.

The downside is that site visitors with higher resolutions get the tax or burden of having to download two images instead of one. 

For small projects or small scale projects where PHP or using .htaccess isn’t possible or too much of a burden, then I think that’s a fair price to pay until the future catches up with us.

Escape with All Alive (Except the Klingons)

Of course, there are ways to workaround the issue of delivering mobile friendly images without having a web builder be concerned about their visitor’s browser window, resolution or bandwidth. 

One way is to place images in background of HTML elements and set background-size: auto; to have them scale as the element resizes. As the container element expands, so does the image in the background.

Another way is to work with Scable Vector Graphics (SVG). SVG has made great leaps in browser support. In fact, in modern browsers support inline SVG images natively. Why we aren’t talking more about SVG these days I don’t know as it seems like manfiect desitny for responsive web design.

If you want to wait a bit longer, there might be support for a “new” image format that serves up multiple resolution. This has already been addressed in the Flashpix image format, but has yet to be adopted for web delivery.

NOTE: For more on adaptive images and responsive web design, check out my new podcast The Non-Breaking Space Show with David McFarland and Chris Enns where we interview the one-and-only Ethan Marcotte.

In his presentation at WordUp Austin inaugural event, Jason Weaver discusses responsive web design principles and web building techniques around WordPress.

Mobile First

• Make one WordPress theme to rule them all 
• Build small, then outwards adding layers 
• Progressive enhancement 

Coding

• For example, as a default style rule set fonts smaller. 
• For screens bigger than 640 pixels, set font-size to 100%
  

Flexible Helpers

• Modernizr
  • Feature detection 
  • respond.js
  • html5shiv 

• Flexible Media
  • flex slider
  • max-width 
  • height: auto
  • FitVids.js

Complex Navigation

• Content first navigation 
• Hide menu on small sizes, if Javascript is enabled (i.e, smart phone) 
• Use simple jQuery slideToggle menu 
• Might be some accessibility issues 

Hover Navigation Approach

• Drop downs 
• Multiple level 
• Using click events 
• FlexNav

Images in Responsive Design 

• Keep number of images, file sizes low 
• Delivering low-resolution images for mobile device is tough 
• Adaptive images
• jQuery plugin HiSRC 
• There are challenges. 
• With retina displays and use of mifis, screen width is not always true representation of bandwidth 
• Ultimate goal is to download only one image, rather than two
  or more