x + 3 = frozen pipes

When I develop WordPress sites, I find that I end up repeating many identical tasks for each site. The phrase “repeating identical tasks” should (and does) set off alarms: This should be automated! To that end, I’m trying to learn some more command line tools for doing tasks that I currently use a GUI for.

One such task is migrating my development database to the staging/production server. Basically a mysqldump from my local database that I can then import on another server. A key thing to watch out for with WordPress, though, is the base URL for your site. If you’re serving a site from localhost while you develop it, you’ll need to change every occurrence of localhost in your database to the base URL for the new server.

sed is a command line tool for doing just that job. It runs a regular expression search on the input and outputs the replacement. Example:

$ echo "localhost" | sed "s/localhost/www.example.com/g"
www.example.org

Pipe your mysqldump through sed to have an SQL file ready for your new server.

$ mysqldump -uusername -ppassword database_name | sed "s/localhost/www.example.com/g" > database.sql

This way I avoid having to open the SQL file in a text editor, doing a global search and replace, and re-saving.

My general rule for browser compatibility when I develop a site is to follow a simple formula: if a browser has a 5% or larger share, make sure the site works on that browser, with or without JavaScript. If it’s under 5%, make sure it works so long as JavaScript is enabled (since JavaScript can be used to work around a lot of bugs). If it’s under 1%, just ignore it.

I’m in the preliminary stages of thinking about a re-design for this site, so I thought it would be interesting to look at the browser statistics for my readers before I get going.

Here’s the breakdown for the last month, by browser (including those 1% and above):

The order changes a bit when you break it down by browser version (again, only those 1% and above):

Notice a browser not on that list? That’s right, fewer than 1% of my visitors use IE 6. As far as I’m concerned, that browser version is no longer supported for this site. It can hang out in the corner with Camino, Konquerer, and Firefox 1.5.

I’m also surprised by both the high position of Safari on the list and the low position of IE 7. It seems that a lot more people with Macs read this site than I expected (24% of my visitors) and that the IE users are actually upgrading (and if you haven’t yet, please do so now; it would be nice to get IE 7 under that 1% mark, too).

I’m still not to the point where I can rely on visitor’s browsers supporting much of CSS3, in large part due to the still-high position of Firefox 3.0.x. I anticipate that number dropping significantly in the coming months, though, so I may revisit this before I get around to actually doing a re-design. Overall, I would say things are trending in an agreeable direction, though (thank you!).

Note: I should make it clear that the above conclusions only apply to this site, and have little bearing on other websites I develop. Unfortunately, IE 6 still has a strong impact elsewhere on the Internet.

Drupal has the ability to connect to multiple databases, allowing you to use Drupal’s built in database abstraction layer on more than just Drupal’s primary database.

The “proper” way to do it (according to Pro Drupal Development and the Module Developer’s Guide) is to change $db_url in your settings.php file from a string to an array, e.g.:

$db_url['default'] = 'mysqli://user:password@localhost/drupal';
$db_url['alternate'] = 'mysqli://user:password@localhost/alternate_db';

Then you can switch from one database to another quite easily:

db_set_active('alternate');
// do stuff...
db_set_active('default');

What if you want your alternate database to be configurable through a settings page, though? You can’t set that in the settings.php file. The solution is pretty simple, actually: just edit $db_url to add in your new database.

global $db_url;
if ( !is_array($db_url) ) {
  $db_url = array( 'default' => $db_url );
}
$protocol = 'mysqli'; // or use variable_get() to get the variable you set on your settings page
$user = 'user';
$pass = 'password';
$host = 'localhost';
$db = 'alternate_db';
$db_url['alternate'] = "$protocol://$user:$pass@$host/$db";
$previous = db_set_active('alternate'); // returns the previous db name
// do stuff...
db_set_active($previous); // return to whatever database was active before

Drupal will check $db_url every time db_set_active is called, so you can edit it whenever you need.

As a web developer, I swear by jQuery. The library has done wonders to make JavaScript both fun and usable, two words that I never thought I’d use to describe it when I was first learning to use JS. My approach to learning jQuery has always been somewhat haphazard, though, learning the little bits I need here and there to do what I need to do at the time.

That’s no way to live as a professional web developer, though, so when Packt Publishing asked me to review their new jQuery book, it seemed like the right time to receive a more thorough education in the library.

Learning jQuery 1.3: Better Interaction Design and Web Development with Simple JavaScript Techniques, by Jonathan Chaffer and Karl Swedberg, aims to provide a thorough introduction to jQuery. It walks the reader through techniques for DOM traversal and manipulation, event-handling, animations, and Ajax. After several chapters of detailed examples, the book concludes with an introduction to using and writing jQuery plugins.
More…