As you’ll quickly discover, not all browsers render equally. Due to differing implementations (opinions) on the (X)HTML/CSS specifications, one browser may display your content as expected, while another may not. As such, web developers are forced to test their websites in multiple browsers (and even multiple operating systems).

However, don’t rush out and start installing multiple browsers and operating system virtual machines just yet. There is a way to get a general idea of how your website looks in other browsers/operating systems. There are two web tools that allow us to get screenshots of our website rendered by a specified browser.

The first is Adobe BrowserLab. This service, by Adobe, can provide us with screenshots from Internet Explorer 6/7/8 (Windows XP), Firefox 2.0/3.0/3.5 (Windows XP), Chrome 3.0 (Windows XP), Safari 3.0/4.0 (OS X) and Firefox 2.0/3.0/3.5 (OS X). These browsers support Javascript and Flash, and even allow you to specify a delay to wait before taking the screenshot (to compensate for any animations or Javascript executing). BrowserLabs provides quick delivery of screenshots and easy comparision of screenshots with multi-views and rulers. An Adobe account required to use BrowserLabs.

Browsershots is another such service. Browsershots gives you a greater selection of browsers and more control over them. Providing almost every browser made in the last 25 years and their various versions. Browsershots allows you to specify your preferred screen size, colour depth and Javascript/Java/Flash version or disable. Browsershots’ screenshot delivery is slower than BrowserLab’s and those screenshots may not always be full-length.

Now that you can view your website in multiple browsers, across multiple operating systems, you can start the gruelling task of tweaking your code to conform to all browsers.

If you’re storing any confidential information on your server (or you’re just paranoid) you may need to securely delete it at some point. Let’s face it, you don’t want those plans for converting lead into gold to get into the wrong hands. Don’t fret though, your alchemy plans will be non-recoverable after running the shred tool.

This tool allows you to overwrite a file with random data (ones and zeros) a configurable number of times. This command line tool has the following syntax:

shred [OPTIONS] filename

The most common options you’ll use are as follows:

-n – The number of times you want to overwrite the file with random data. The United States Government defines 7 as the standard.
-u – Remove the file after overwriting (otherwise the file will still exists, just full of random data instead).
-z – Overwrite the data once more, this time just with zeros. This tries to make it less obvious that a file was overwritten.
-v – Verbose output (show progress).
-f – Forces permissions to allow writing. Likely not necessary in most scenarios.

For example, if you wanted to remove alchemy.pdf, you would use the following command (7 passes):

shred -n 7 -u -z -v alchemy.pdf

Which would output the following:

shred: alchemy.pdf: pass 1/8 (random)...
shred: alchemy.pdf: pass 2/8 (555555)...
shred: alchemy.pdf: pass 3/8 (aaaaaa)...
shred: alchemy.pdf: pass 4/8 (random)...
shred: alchemy.pdf: pass 5/8 (ffffff)...
shred: alchemy.pdf: pass 6/8 (000000)...
shred: alchemy.pdf: pass 7/8 (random)...
shred: alchemy.pdf: pass 8/8 (000000)...
shred: alchemy.pdf: removing
shred: alchemy.pdf: renamed to 00000000000
shred: 00000000000: renamed to 0000000000
shred: 0000000000: renamed to 000000000
shred: 000000000: renamed to 00000000
shred: 00000000: renamed to 0000000
shred: 0000000: renamed to 000000
shred: 000000: renamed to 00000
shred: 00000: renamed to 0000
shred: 0000: renamed to 000
shred: 000: renamed to 00
shred: 00: renamed to 0
shred: alchemy.pdf: removed

Now you can be rest assured that nobody will know why you buy so much lead.

WordPress has included the functionality to allow you to update plugins automatically since version 2.7. This works well for most setups, but what if you want a little more control over the upgrade process. Maybe you want to see the code changes between your version and the new version and merge any code changes you have made?

The answer is to install and upgrade your plugins with SVN, through the command line. Every plugin hosted in the official WordPress Plugin Repository has a Subversion repository which stores the plugin’s files. We can use these repositories to “check out” the files into our wp-content/plugins folder. Once the files have been downloaded to your plugin directory, you can then activate it in your WordPress administration panel.

Once you have found a plugin that you would like to install in the plugin repository, take note of its URL slug. We’ll need this for determining the URL of the Subversion repository. For example, the WP Super Cache plugin (http://wordpress.org/extend/plugins/wp-super-cache/) has a URL slug of wp-super-cache (the last part of the URL). The root of the plugin’s SVN repositories is located at: http://plugins.svn.wordpress.org/. You simply append a plugin’s URL slug to the end of this URL, and you will have the location of its repository.

Now that we have the Subversion repository, we need to figure out where the latest version of the plugin is stored. A Subversion repository typically has three directories in its root: branches, tags and trunk. Normally, active plugin development is done under trunk, while tags contain directories of stable releases. Branches may contain directories that encase older-than-trunk development releases. Typically, under this system, you could check out the highest number under tags to download the most recent version. However, not all developers follow this “standard”. Some may only have their plugin under trunk, and only “check in” release ready code. To find out which system the developer is using, open the readme.txt file under trunk. Under the first section in that file, look for a line that starts with “Stable tag”. If you find this line, you can get the latest stable release by “checking out” that number from the tags directory. If this line doesn’t exist, you can assume that the trunk directory contains the stable version of the plugin, and that you should “check out” trunk.

As for actually “checking out” these plugins, you’ll first need to SSH into your server and `cd` into your wp-content/plugins file. You can then run a command such as the following:

svn co http://plugins.svn.wordpress.org/wp-super-cache/tags/0.9.8/ wp-super-cache

Which would load the WP Super Cache plugin files into a directory named “wp-super-cache”. You can then head to your WordPress administration panel and activate the plugins.

When it comes time to upgrade a plugin, it’s a similar process. If you previously checked out a tag (run `svn info` if you don’t remember), just find the latest version number to determine the new Subversion URL. For example, if WP Super Cache 0.9.9 were to be released, I could upgrade to it by `cd`ing into its directory and running:

svn sw http://plugins.svn.wordpress.org/wp-super-cache/tags/0.9.9/

Which will switch the working repository to the new version of the plugin, merging the changes into your current files.

If you checked out from trunk before, you can just run the following to update:

svn up

If you plan on making custom modifications to plugins you install, managing them via Subversion is the best route to take. You’ll be able to view the differences (run `svn help diff` for details on this) and have Subversion merge them together automatically. Not to mention, you’ll also enjoy faster installs and upgrades.

Continuing our series on MySQL table joins, today we’ll be taking a look at how to join multiple tables together. You may need to join multiple tables when you have data spread across multiple tables with reference points relating them.

The syntax for joining multiple tables versus two tables is similar. You may even recognize some of the operators from previous articles. First, let’s have a look at a two table join:

[sql]SELECT * FROM table1 JOIN table2 ON table1.id = table2.id[/sql]

With a multi-table join, we will need a field in the “joining tables” that will relate to a field in the initial table. These matching fields do not need to be the same for each “joining table”. Now, let’s take a look at our feature presentation:

[sql]SELECT * FROM table1 JOIN (table2, table3, table4) ON table1.id = table2.id AND table1.name = table3.name AND table1.email = table4.email[/sql]

There is no hard limit on the number of tables you can join; however, there is a practical limit. If you’re joining more than ten tables together, you may want to look at alternate methods, such as multiple queries. If you’re joining more than ten tables constantly in one application, your data may be spread across too many tables, and you may want to look at combining some of them.

Next week we’ll be going over the different types of joins (left, right, outer, inner, natural).

Tip: If you have phpMyAdmin installed on your server, you can easily run SQL queries by selecting a database and going to the “SQL” tab at the top of the page.

Basic text editors were likely your initial choice for writing your programming in. Default operating system programs such as Notepad (on Windows) and TextEdit (on Mac OS X) work great for programming. Their minimalistic feature set and interface won’t get in your way and let’s you get straight to the point of the programs: writing. Unfortunately, their main strength, minimalism, it also their main weakness.

Notepad and TextEdit just don’t provide the features that can make programming faster and more pleasant. Features such as syntax highlighting, line numbering and code completion can all make programming just a little bit easier (and easier on the eyes). Below is a list of code editors and any outstanding features.

Notepad++ (Windows)
Tabbed documents, macros, auto-completion API. Open source (GPL). Free.

jEdit (Java based – Windows, Linux, Mac)
Macros, tabbed documents, code folding, location markers, session persistance, plugin manager. Open source (GPL). Free.

Programmers Notepad (Windows)
Code folding, project support, text clips. Free.

TextWrangler (Mac)
“Grep-format” searching, file differencing, FTP support, document sidebar. Free.

Coda (Mac)
Projects, text clips, auto-completion, file differencing, FTP support, Subversion integration, HTML/CSS preview, “drag and drop” grep searching, live collaboration. $99

Dreamweaver (Windows, Mac)
Mostly point and click web design software, however it does include a code editor. Notable features: built-in FTP, Subversion integration, live-view (for HTML/CSS), code completion. $399.

Obviously we’re just scratching the surface with this list (and the listed features). What’s your favourite code editor, and why?

When a server transmits a file to the user, additional “header” data is sent along with it. This header data contains various information about the session. One crucial part is the content-type, which contains an internet media type (commonly: “MIME type”) specification. This media type tells the browser what kind of file is being retrieved, and provides a guideline for handling the file (eg. display the file, offer to download, etc).

By default, Apache associates file name extensions to the appropriate media type. You can view these associations in the file /usr/local/apache2/conf/mime.types. However, what if you need to change how a file should be handled, or specify how an unspecified extension should be handled? It is recommended that you do not edit the mime.types file, as the file is likely to be updated during Apache upgrades, which will undo all your changes. Instead, we’ll use an .htaccess file to make our changes.

In our .htaccess file, we can add our own specifications, which will override the defaults. The syntax is as follows:

AddType media_type .extension

Where media_type is one of the defined media types and .extension is the file name extension of the files you want to modify the content-type on. For example, if we wanted MP3 files to be downloaded instead of played in the browser:

AddType application/octet-stream .mp3

This would change the content-type of MP3 files (within the directory scope* of the .htaccess file) to application/octet-stream (arbitrary binary data – browser will offer to download) instead of the default of audio/mpeg.

If you want to specify multiple extensions to be served with the same content-type, you can use a space separated list in the regular line. If we want to apply this to a single file, we can use a files section and use ForceType instead of AddType:


ForceType application/octet-stream


In future articles, we’ll be further talking about the uses of .htaccess files.

* – The directory scope of a .htaccess file refers to where its contents will be applied. The file will have an effect on the files in the same directory as well as files in (infinitely) nested directories. In these nested directories, the “root” .htaccess file can be overridden with a new .htaccess in that nested directory.

Over the last few months, development of WordPress version 2.9 has been in full swing. The major features that have been added are: basic image editing; easier video embedding; post, page and comment trash can; plugin update notification and compatibility notification in WordPress’ core upgrader and various developer and bug fixes. Along with the major changes, the smaller features and changes in 2.9 are listed here. Development is starting to come to a close, and help is needed to begin testing WordPress 2.9 beta 1.

If you’re interested in testing out beta 1 of WordPress 2.9, you can download it here (zip). You can also run the latest development version via subversion. Remember that this is pre-production software, and bugs are likely present. It is not recommended that you run this in a production environment, use a development environment instead. However, if you do decide to run the beta on your production blog, be sure to backup your blog’s files and database beforehand (as a precaution).

After testing the beta out, you can report any problems on the wp-testers mailing list. If you spot a reproducable bug, you can report it to WordPress’ ticket-management system: Trac (you can sign in using your WordPress.org account). Happy testing, the WordPress community appreciates it.

An organized and planned database will have relatable data separated into multiple tables. This data may need to be used together at some point. This is where MySQL JOINs come in. Carrying on with our previous instalment, we’ll continue talking about table joining.

Last time, we took a look at a basic table join, which selected all fields from two tables. Today, we’ll be covering how select specific fields from specific tables involved in our join. In your code, you may only need to use some of the available fields. By specifying just the fields you need, you can shave some time off your query. Let’s take a look at our previous join query, which we’ll modify:

[sql]SELECT * FROM table1 JOIN table2 ON table1.id = table2.id[/sql]

With this query, we use the wildcard character (an asterisk) to specify that we want all the fields. In a regular select query, we would use a comma-separated list of fields, in place of the wildcard, to retrieve specific fields. In a join query, it is the same, except with must specify the table that a field resides in. We do this in the format of: table_name.field_name. Adapting our previous example, we end up with this:

[sql]SELECT table1.id, table1.name, table2.mark FROM table1 JOIN table2 ON table1.id = table2.id[/sql]

Next time we’ll be covering joining multiple tables.

During our last instalment of this series, we began talking about organizational tables. This time around, we’ll be discussing some of the more advanced portions on tables in HTML.

If you’re using a table to organize data, you’ll likely have column headers that identify the type of data contained within that column. Using what we’ve previously covered, you could simply use a tr at the beginning of the table and use CSS to stylize them. However, there is a better way.

HTML contains a method to specify a table header, footer and body. We can use this method by wrapping the appropriate rows in thead, tfoot and tbody tags, respectively. In the thead section, cells must use th instead of td. The order of these “groups” is also vital. The thead and tfoot groups must be before the tbody group (the footer will be still appear below the body).

This method has a number of advantages over simply ordering your rows to create a header and footer. For starters, these three tags provide semantic meaning to your table. Having the footer above the body, in the code, allows the browser to render the footer before the (potentially long) body has loaded. Additionally, when you’re generating your body via a programming language (such as PHP), having the (likely) static header and footer before your dynamic body code will be neater.

Example:

[html]<table>
<thead>
<tr>
<th>ID</th>
<th>Surname</th>
<th>First Name</th>
<th>Email</th>
</tr>
</thead>
<tfoot>
<tr>
<td>ID</td>
<td>Surname</td>
<td>First Name</td>
<td>Email</td>
</tr>
</tfoot>
<tbody>
<tr>
<td>192<td>
<td>Smith</td>
<td>John</td>
<td>john.smith@example.com</td>
</tr>
<tr>
<td>193</td>
<td>Doe</td>
<td>Jane</td>
<td>jdoe282@example.com</td>
</tr>
</tbody>
</table>[/html]

Last week, a new version of CentOS was released. Version 5.4 includes various improvements, bug fixes and security fixes. If you’re running CentOS on your server, you may be interested in updating.

CentOS contains numerous updated packages and new packages. If you’re interested in learning more about the changes in CentOS 5.4, you can view the release notes. To update from an earlier version of CentOS, login to your server as a root user via SSH and run the following command:

yum update

You will then need to confirm that you want to update by typing y and hitting the enter key. If you want to see the package changes before updating, you can do so by running the following command:

yum list updates

As previously mentioned, you can stay up-to-date on CentOS updates by subscribing to their announcement mailing list.