Category Archives: Wordpress

So long MT, G’Day DH

Well, it wasn’t easy, but I’ve done it: I have migrated my sites away from MediaTemple (MT) to DreamHost (DH).

Why the change? Performance mainly.

MediaTemple has given me decent stability and good support over the last few years. And most of all I’ll miss that gorgeous, minimal admin control panel.

But the performance has been poor at best. Even with WordPress caching plugins installed, page renders averaged 3 seconds, not including the fairly frequent spikes (of up to 30 seconds) which would occur every 5 attempts or so.

And while they seem to have more constant outages (two of which have affected me already), the overall page render performance at DreamHost has been at least twice as good (< 1 second for page render on average) as MediaTemple and far more consistent (i.e: no spikes). For those who are interested, without caching plugins installed, the difference was far more pronounced (averages of 13 seconds for MT and 2 seconds for DH). The DreamHost control panel isn't quite as minimal or as gorgeous, but it is much better organised than others I tried, and has all the functionality I require.

I should note here that these performance results (especially the DreamHost results) are based on a limited period of testing. So I’ll keep you posted as to the service and performance longer term. But it is safe to say that the performance of my previous provider has been less-than-ideal for a long time, hence the move.

For those interested in WordPress performance, I’ll post a follow up about the plugins I’m using.

Posted in

First contact

I finally have a contact form! Thanks to the close-to-perfect WordPress plugin Contact Form 7.

I say “close-to-perfect” because of two fairly minor flaws (these observations are based on WordPress v2.7.1 and Contact Form 7 v1.9.3)…

Flaw the first: Accessible form markup

The plugin seems to output a bunch of non-semantic markup (<span>s, etc…). I’m just going to ignore them because I figure they aren’t doing too much harm.

The bigger issue is that using the default form template, form control labels aren’t marked-up using the <label> tag! This issue has an easy fix, because the plugin’s author iDeasilo has thoughtfully allowed for customising the output markup.

Here’s the template markup I settled on:

<div id="contact-form">
<p class="instructions">Required fields are marked with
<abbr title="(required)" class="req">*</abbr></p>
<ul>
	<li class="input required"><label for="your-name">Your Name
		<abbr title="(required)" class="req">*</abbr></label>
		[text* your-name id:your-name]</li>
	
	<li class="input required"><label for="your-email">Your Email
		<abbr title="(required)" class="req">*</abbr></label>
		[email* your-email id:your-email]</li>
	
	<li class="input"><label for="your-subject">Subject</label>
		[text your-subject id:your-subject]</li>
	
	<li class="input"><label for="your-message">Your Message</label>
		[textarea your-message id:your-message]</li>
	
	<li class="submit"><strong>[submit "Send"]</strong></li>
</ul>
</div>

I also added the following CSS to my stylesheet to make the form prettier:

#contact-form ul,
#contact-form li {
	margin: 0;
	padding: 0;
	list-style-type: none;
	overflow: hidden;
	zoom: 1; /* For IE6&7 */
	margin-bottom: 1em;
}
#contact-form li {
	position: relative;
	padding-left: 1em;
}
#contact-form label {
	float: left;
	clear: left;
	width: 10em;
	margin-bottom: .2em
}
#contact-form input,
#contact-form select,
#contact-form textarea {
	float: left;
}
#contact-form .submit {
	padding-left: 11em;
}
#contact-form abbr.req {
	color: #f00;
	font-weight: bold;
}
#contact-form .required abbr.req {
	position: absolute;
	left: 0;
	top: .2em;
}

The markup and style above are based on forms code ideas Ben and I have been refining for the last few years (which in turn are based on ideas from other web developers far and wide, I’m sure Ben will post about it in more detail later).

This version works well for a simple form like this. The form controls wrap under the labels at smaller resolutions, and the required field indicators always sit in their own column.

If you are a purist, you can separate the zoom: 1; line into a separate stylesheet and serve it to IE6 and 7 only using conditional comments.

Flaw the second: Automatic addition of <br /> to output

This issue is a little prickly, because there’s no way to turn this “feature” off in the plugin configuration.

A workaround has been suggested, thanks Aiden!

Unfortunately, implementing this workaround means I would need to remember to edit this file every time I update the plugin.

I have a slightly different solution, based on Aiden’s idea that means the plugin can be updated and this preference should remain intact.

Because the plugin checks to see if the constant is defined before setting it, if we set the contstant first, our value will not be overwritten by the plugin.

Add the following code to the top of your wp-config.php file:

// Contact Form 7 plugin: Don't add <br /> tags!
	define('WPCF7_AUTOP', false);

Remember to keep this part of the wp-config.php file when you next upgrade WordPress.

Posted in