I recently was faced with a decision: which WordPress caching plugin to use on my shared hosting account. The choice was between WP Super Cache, W3 Total Cache and Hyper Cache. This article documents my admittedly limited testing of these plugins and the decision I made as a result.

The Disclaimer

I’m very aware (and you should be to) that:

• I’m not an expert on caching
• My method of testing is far from scientific
• The website used in my test isn’t well optimised in it’s own right.
• Results could be very different for other websites
• Results could be very different if I spent the time to tweak the settings of each plugin
• Future versions of the caching plugins may improve their performance. Please note their version number below and do your own testing if there are newer versions.

Nonetheless, I present this in case it’s useful for someone. At the minimum, I hope it will encourage people to do their own testing in their environment rather than just believe everything they read.

The Requirements

It was important to me to use a WordPress caching solution that worked well with my server environment: A shared hosting server with Hostgator.

Unfortunately, I’m not on a dedicated server at this point, so benefits such as a persistent object cache are not available to me. If I was on a dedicated server, the results of my testing may have been very different – but I’m not and I need a solution that fits my current circumstances.

It’s also worth pointing out that I’m not trying to protect the server from the Digg effect or from high traffic per se. My sites don’t draw that much traffic. I’m just after a caching solution that will speed up the delivery of my web pages.

The Candidates

There are many WordPress caching plugins available, but I can’t test them all. I settled on these three plugins for the following reasons:

WP Super Cache (0.9.9.3)

WP Super Cache is the current market leader, with 12,182 downloads over the last week (at the time of writing). It’s been the standard for several years now, has been widely written about and has a very good reputation. I’ve personally been using WP Super Cache for a year or so now and it’s served me well, so it was a no brainer to consider continuing with this plugin.

WP Super Cache is written by Donncha O Caoimh, an Automattic employee and a core contributor to the WordPress project. Not only is he someone who clearly knows WordPress inside out, he’s also someone I respect.

W3 Total Cache (0.9.1.1)

W3 Total Cache is a contender for the crown. Not a week goes by without me hearing someone influential extolling the virtues of this plugin. It’s worth noting that it has probably the most comprehensive list of features of any WordPress caching plugin. With 7,242 downloads over the last week, its still behind WP Super Cache in terms of usage, but it’s on the rise and clearly a worthy candidate.

W3 TC is written by Frederick Townes, the CTO at the high traffic Mashable website which runs on WordPress. Frederick clearly knows a lot about optimising WordPress for high traffic sites. I’ve also been impressed with the job he’s done as co-host of the WordPress Community Podcast with Joost de Valk.

Hyper Cache (2.7.3)

Hyper Cache is a relatively new plugin, with a smaller market share (2,517 downloads over the last week). It’s not as well known as either of the other two plugins and neither is it’s author, Stefano Lissa. All I know about Stefano is from his About page: he’s a full time developer and analyst.

Hyper Cache was first recommended to me by RT Cunningham from Living in the Philippines. RT’s never steered me wrong, so it would have been worth considering simply from that. The fact that it was written specifically for use on shared hosting was also appealing, as was it’s number one position in a recent benchmarking test.

In fact, rather than just considering Hyper Cache as a candidate, I’d decided to just give it a try (without testing the others). However, a Twitter conversation led to me comparing the plugins. A rather lengthy back story section outlines how this came about. You can skip it if you’re just interested in the test.

The Back Story

Having decided to try Hyper Cache, I tweeted the following:

Trying out Hyper Cache instead of WP Super Cache. I was happy enough with WP Super Cache, but heard a lot of good things about Hyper Cache. (source)

sonlinebiz replied with:

@StephenCronin Tried them both but they don’t compare to W3 Total Cache 0.9. Simply amazing and FAST http://strictlyonlinebiz.com/2h (source)

The short link in his tweet goes to his excellent post on speeding up your blog with W3 Total Cache. In response to him I sent a couple of tweets:

@sonlinebiz W3 I’ve heard that Total Cache is great on dedicated hosting – but I’m on shared hosting, which Hyper Cache is geared towards. (source)

and

@sonlinebiz I based my decision to try Hyper Cache on this article, which shows Hypercache beating all comers: http://bit.ly/b8v2AB  (source)

That bit.ly link goes to the benchmarking test I mentioned earlier.

Ozh had also replied and Donncha, the creator of WP Super Cache picked up on the conversation and chipped in (to Ozh, not me) with:

@ozh the benchmark results for supercache in that post look dodgy to me. Configured correctly, it’s Apache mod_rewrite serving cache files.. (source)

I wouldn’t mind knowing more of Donncha’s views on this, because measuring the effectiveness of caching plugins is something I struggled with – but more on that below. I replied with a couple of tweets to Donncha (not worth including here) explaining that I had no particular problem with Super Cache.

Then Ferederick, the maker of W3 Total Cache replied with:

@StephenCronin on the contrary, W3TC has options/benefits for all hosting scenarios (source)

It was great to get a response from Frederick, someone I really respect. Of course, I know W3 Total Cache is going to have benefits even in shared hosting situation – it’s just that I’d heard that its real power was on dedicated servers. I don’t know how accurate that is, but I responded with:

@w3edge Hi Frederick, I know it has benefits in all scenarios, I’ve just heard that you need the persistent object cache to really benefit (source)

And I thought I better point out that I do realise that if W3 Total Cache can’t take advantage of a persistent object cache, then none of the other caching plugins can either (rather obviously), which also limits their effectiveness:

@w3edge I understand that that’s the same for all caching plugins.. (source)

Frederick came back with several tweets:

@StephenCronin it doesn’t really matter what you heard. every theme/plugin/server combination varies. (source)

@StephenCronin i wouldn’t have wasted a year working on the plugin if it wasn’t going to help everyone. (source)

@StephenCronin no it’s not, there are more than 70 plugins out there, but there is no other single plugin that has a suite of tools. (source)

This is great: getting direct feedback from the maker of a very popular plugin. However, I already knew that W3 Total Cache is a very good product but I wasn’t going to change my mind, so I tweeted as much:

@w3edge No need to sell me – though I am going to try Hyper Cache dammit – I know W3 TC is great. Love the podcast by the way. (source)

Frederick came back with a final tweet:

@StephenCronin don’t care if you use it or not. just the facts. (source [now deleted])

This tweet has since been deleted. I only have a record of it because of a vanity feed in Google Reader (lesson: you can never really delete a tweet).

No matter: I have no problem with the tweet or the fact it’s deleted, but I’ve included it here because it’s important in what happened next, as was my final tweet on the topic (which was trying to lighten the mood just in case people had taken things the wrong way):

So I think I need to put WP Super Cache on one of my blogs, W3 Total Cache on another and Hyper Cache on the last one. #wp #caching (source)

Upon reflecting on some key points of the conversation, I actually did change my mind. As Frederick had said:

it doesn’t really matter what you heard. every theme/plugin/server combination varies

That’s very true. I was basing my plans on what I’d read when there was indeed likely to be significant variations depending on the environment. The "just the facts" part of his last tweet also got me thinking: what were the facts in this case?

I decided I should follow my last tweet and run all three of the candidates to compare them (although on as test rather than on separate sites).

The Testing Methodology

But first, how can we test the effectiveness of these caching plugins?

I often measure performance using the Debug Queries plugin, but that’s not going to run with a caching plugin installed (well it runs the first time and then it’s results are cached along with the rest of the page).

The benchmarking test mentioned above used Apache Bench, but that wasn’t appropriate for my test. I want to measure the speed of individual page loads, but Apache Bench is more about the effect of lots of traffic on server loads (to my admittedly limited understanding).

My thoughts therefore turned to the Lori (Life of Request info) Firefox extension, a very handy tool that measures how long a page takes to load, including:

• Time to first byte (TTFB) received from the server
• The overall time to load the page
• The size of the page
• The number of requests

The fastest overall time to load is the end result I’m after, but it’s not an effective measurement of a caching plugin because it includes the time to load images and remote scripts and widgets etc, which are outside the plugin’s control.

I *think* Time to first byte is the best indicator of the effectiveness of a caching plugin. If the server is busy running PHP and talking to MySQL, then TTFB will be high. If a page is cached, then it should be served up almost immediately. Of course there may be other things happening on the server which could impact on the results.

I figured that given the lack of an iron clad testing methodology, I’d do the following:

• Run the test without a caching plugin to establish a baseline to compare against.
• Test each plugin twice, once with basic settings, once with more advanced settings (such as compression turned on).
• Within each test, measure results against both the home page and an individual blog post.
• Within each test, measure results both with images and scripts cached and with the browser cache clear.
• For each individual page load, measure both TTFB and the overall time to load.
• Run each page load 10 times and ignore the 2 fastest and 2 slowest results to limit anomalies.
• Monitor the server CPU usage via CPanel to ensure the server is bogged down doing something else.

I’m sure this isn’t the most scientific way to measure a caching plugin, but it’s the best I could come up with and it should at least give an indication of which plugin a particular website loads fastest with.

The Site Being Tested

I decided to use my Jobs in China website for the test. For the single post test, I used the China Is Still The Best Place To Find A Job post.

The fact that the site isn’t well optimised probably makes it a good test site, as there will be many blogs out there in a similar situation: not particularly well optimised, on shared hosting, etc.

The Results

There are too many test results to present each page load in this post. I’ve therefore included just the averages for each test run. The full results are available on Google Docs.

To fit the summary results in, I’ve separated the results into two tables: one for Time To First Byte (TTFB) and one for the page being fully loaded. First, here are the average times for the first byte to be returned by the server:

Next, here are the average times for the entire page to be loaded:

Analysis

There are a couple of very obvious trends across the board that we should get out of the way first:

• The post takes longer to load than the home page.
• Turning on compression and other advanced options (where available) improved performance across the board.

Those out of the way, here are just a few useful patterns I can see:

• W3 Total Cache actually slowed things down when it only had page caching turned on, although it was one of the better performers when the more advanced options were turned on.
• W3 Total Cache (with advanced options) had the fasted TTFB, which implies that it is the best at serving pages up efficiently and minimising server resources.
• Hyper Cache (with advanced options) resulted in pages being full loaded in the quickest time, even though it wasn’t quite as efficient at at the server end as W3TC. I’m not sure why – perhaps it makes better use of browser caching? However it managed it, Hyper Cache was the fasted across the board for full page loads.
• WP Super Cache was just a little way behind the other two plugins across the board.
• WP Super Cache (with compression turned off) significantly improved TTFB, but had mixed results with the full page load: The home page was slower than not having a caching plugin, although the single post was faster.

As I said above, I’m no caching expert. If anyone reading this can see any other patterns in the results, please let me know in the comments.

The Winner

It depends on what you want!

If you’re after the best optimisation on the server side (ie less time to server up pages, so that it can deal with more requests), then based on the test results, W3 Total Cache is the best choice for you.

If you’re after the fastest loading pages on the client side (ie pages load faster for the user), then Hyper Cache is a better alternative.

Conclusion

The test wasn’t particularly scientific, but it was good enough for me to work out which caching plugin was the right one for me. For the Jobs in China site, I ended up using Hyper Cache.

The biggest take away may be that, as Frederick pointed out, every theme/plugin/server combination varies – so what works best for my particular circumstances may not be best for yours. It’s not hard to run a quick test to compare. Do your own testing before making a choice.

Have an opinion on this test or the plugins mentioned? Please leave a comment below!

I’ve read quite a few articles on theme support for the new Menu functionality introduced in WordPress 3.0. However, these have all been theoretical rather than practical. I wanted a real life, working example, including support for users on older versions of WordPress. In the end, I wrote it myself.

Scope

I’m not going to delve into all the different options you can use when adding support for menus. There are enough articles out there that cover this in depth: I highly recommend you read Justin Tadlock’s excellent Goodbye, headaches. Hello, menus!.

Instead, I’m going to focus on the things missing from most articles, such as adding support for users on older versions and including support for static pages in the fallback menu. If you write themes that are used by other people, you need to include these.

Functions.php

First, this is the code to add to the functions.php file. I’ll explain it below.

// add menu support and fallback menu if menu doesn't exist
add_action('init', 'sjc_register_menu');
function sjc_register_menu() {
	if (function_exists('register_nav_menu')) {
		register_nav_menu('sjc-main-menu', __('Main Menu'));
	}
}
function sjc_default_menu() {
	echo '<ul>';
	if ('page' != get_option('show_on_front')) {
		echo '<li><a href="'. get_option('home') . '/">Home</a></li>';
	}
	wp_list_pages('title_li=');
	echo '</ul>';
}

Check If register_nav_menu Exists Before Calling It

On line 2, we add an action to call a function (from line 3 to 7). The purpose of this function is to register the menu via the register_nav_menu function.

Most tutorials out there focus on how to use register_nav_menu (line 5). Fair enough, it’s new and we’re all interested in how to use it. However, I want you to notice line 4:

if (function_exists('register_nav_menu'))


Surprisingly, most tutorials leave this out. No problem if your theme will only ever run on WordPress 3.0. However, if you have users on an older version of WordPress, your theme will crash and burn if you leave this out. Visitors will be greeted with the following error:

Fatal error: Call to undefined function register_nav_menu() ...

Not cool.

The Fall Back Menu Catering For Static Pages

Lines 8 to 15 contain a function that provides a fall back menu that is used if the user has not added a menu via the new interface. The code for the fall back menu is pretty standard stuff. I’m sure someone will point out that I could use wp_nav_menu, but we’ll call the fall back menu directly for older versions of WordPress (see below) and wp_nav_menu only exists in 3.0 and above.

It’s worth noting the IF statement on line 10, wrapping the Home link. This says to only create the Home link IF the site is NOT using a static home page. If it is, then the Home link will not be created. Why? Without this, the Home page option will appear twice in the menu (if users have a static home page).

There are other ways of dealing with this, but my way seems simplest to me.

Header.php

Moving on to header.php, we add the following code where we want the menu to appear:

<div id="nav">
	<?php
	if (function_exists('wp_nav_menu')) {
		wp_nav_menu(array('theme_location' => 'sjc-main-menu', 'fallback_cb' => 'sjc_default_menu'));
	}
	else {
		sjc_default_menu();
	}
	?>
</div>

Call The Fallback Menu Function Directly For Pre WordPress 3.0

The menu is called via the wp_nav_menu function (see line 4 above). This function is what the other articles all focus on. Once again, fair enough, this is a new function that can give us access to the cool new menus. But note the IF statement in line 3:

if (function_exists('wp_nav_menu'))

Leave this out and anyone using your theme on versions of WordPress older than 3.0 is going to be serving the following up to their visitors:

Fatal error: Call to undefined function wp_nav_menu()

Checking that the wp_nav_menu exists is obviously essential, unless you are certain that your theme will only ever run on WordPress 3.0 or above.

But what do we do if wp_nav_menu doesn’t exist (ie the user is on an older version of WordPress)? Should we serve up the original code that we originally used to create the menu pre WordPress 3.0?

Well, we’ve already moved our old code into the fall back menu function. There’s nothing to stop us from calling the fall back menu function directly (line 7) assuming it doesn’t use wp_nav_menu. Simple! And good reuse of code.

Final Thoughts

WordPress Theme developers, what have you done to ensure menu support for your users on older versions of WordPress? Is your approach different from mine? Can you see a better way of doing this?

I’d love to hear from you in the comments.

The other day a great comment was left on this site. When I went to answer, I realized that I wanted to be able to select part of what the commentator said and automatically turn it into a quote in my comment.

Copy and paste are too mundane for me, so I wrote a Greasemonkey script that adds the markItUp! Editor to any textarea on a page. I then extended markItUp! by adding a ‘quote’ button that wraps the currently selected text (from anywhere on the page) in blockquote tags.

Why A Greasemonkey Script?

I’m pretty sure that there’s a WordPress plugin somewhere that allows you to automatically add quotes to comment replies. As the comment I wanted to quote was on my site, which is powered by WordPress, I could have used this.

However, I realized that I wanted this functionality to be available on any site I was leaving a comment on, not just my own. I know there is a Firefox add-on that adds a HTML editor, but I wasn’t that impressed when I tried it and I don’t think it ‘quotes’ the selected text from anywhere on the page.

In that context, a Greasemonkey script seemed to be the answer. I just needed to find an editor to embed.

Enter markItUp!

I looked at quite a few editors, but markItUp! stood out for me because:

• It provides the main HTML markup options I need: strong, em, lists, links, images (although it doesn’t include blockquotes, by default).
• It’s easily extensible, allowing me to add the blockquote functionality.
• It’s based on jQuery, which is my preferred JavaScript framework.
• It’s open source (Dual licensed under the MIT and GPL licenses), allowing me to embed it in a Greasemonkey script.

Turning markItUp! On

The script runs on all pages you visit, but it doesn’t turn markItUp! on automatically. Instead it creates a "Toggle markItUp!" link immediately before any textarea, as follows:

Once you click this, markItUp! is turned on for that textarea and you’ll see the markItUp! editor:

markItUp! can be turned on for multiple textareas at the same time, but each one needs to be turned on individually.

Functions Included

This implementation of markItUp! includes the following functions:

• Bold: wrap the selected text in <strong> tags
• Italic: wrap the selected text in <em> tags
• Strike through: wrap the selected text in <del> tags
• Paragraph: wrap the selected text in <p> tags
• Blockquote: wrap the selected text (from anywhere on the page) in <blockquote> tags
• Unordered lists: wrap the selected text in <ul> tags
• Ordered lists: wrap the selected text in <ol> tags
• List element: wrap the selected text in <li> tags
• Picture: insert an image
• Link: insert a link
• Clean: remove HTML tags from the selected text
• Preview: show a preview of how the markup will be rendered

Example

As an example, to make something bold, first select the text you want to make bold:

Then click the B icon and the selected text will be wrapped it in <strong> tags:

To see how this will be rendered, click the Preview icon (the green check mark):

Technical Notes

For those that are interested, here are some technical notes related to creating the script.

The following scripts are embedded in the Greasemonkey script:

• jQuery by John Resig
• markItUp! by Jay Salvat
• jqModal by Brice Burgess

I used the Greasemonkey function GM_addStyle() to add the CSS for both markItUp! and jqModal. For markItUp!, I went a step further and used Daily Coding’s Online Image to Base64 Converter to convert the images for icons etc into base64 encoded images. This allowed the CSS and images to be embedded in the script itself, rather than living in external files that have to be stored somewhere (they can’t live in Greasemonkey).

I wrote a Quote function that grabs the currently selected text (from anywhere on the page), wraps it in blockquote tags and inserts it at the current cursor location in the textarea. If there’s nothing selected on the page, it grabs whatever is selected in the textarea itself and wraps that in blockquote tags.

The default Preview function in markItUp! wouldn’t work as it relies on using an IFrame to load an external file which it then manipulates. Once again, the external file can’t be stored within a Greasemonkey script. I therefore wrote my own Preview function, which uses jqModal to display the text in a modal dialog. The styles in the Preview probably won’t be exactly the same as the final comment, but it allows you to check if links, lists, etc are correct.

Where Do I Get It?

I’ll be creating a home page on this site for the markItUp! For Greasemonkey script, but it’s also available on userscripts.org.

While catching up on some old podcasts, specifically Episode 82 of WordPress Weekly, I came across a discussion about WordPress beta testing. The discussion centers around the problem of bugs not being caught during beta testing because there just aren’t enough beta testers.

To me, the solution seems straightforward – but that may be because I worked in the software industry for 10 years and have experience in software release management, so I’ll take the long path and set the scene properly.

That makes it a long post, but stick with it – you need to read it all to fully understand my reasoning. First we need to consider the following question:

Should You Upgrade WordPress Immediately After A Release?

Short answer: Sometimes, but not always.

Over the last couple of years, there have been repeated calls for WordPress users to update their blogs immediately after a new version has been released. At times, the call to upgrade has almost become a frenzy.

I’ve taken this with a grain of salt and held to my belief that upgrading immediately isn’t always the correct choice. Sure, upgrade immediately if the release fixes a critical security issue – but most of the time it’s better to wait and see whether:

• there are any major bugs in the new version
• your theme works with the new version
• all of the plugins you’re using work with the new version

I’ve developed this ‘hold back’ approach while working in the software industry over the last 15 years or so – I’d contend that it’s ‘best practice’. Upgrading to a new version without testing the new version in your environment (including server, theme and plugins) is the sign of immature processes.

Some may argue that this approach is overkill for a simple blog, but there are many sites out there running WordPress that are a little more complicated.

Even simple blogs are often not that simple, especially as so many are now monetized. Ask yourself, will I lose money if WordPress doesn’t work after an upgrade? If the answer is yes, you should probably be testing new versions before upgrading.

You’re probably asking how does this relate to beta testing? Well, in a couple of ways:

1. Bugs In New Releases Mean Less People Will Upgrade

Let’s leave aside the fact that I don’t personally subscribe to the ‘upgrade immediately’ advice and assume that it’s a good thing (which it would be in the ideal world).

Bugs in new releases undermine this advice. After the recent problem with scheduled posts, introduced in the WordPress 2.9 release, there have been people questioning whether upgrading immediately was a good thing.

If beta testing was improved and caught more of these problems, then there’d be less of the ‘hold back’ people out there and more people would follow the advice, in theory making WordPress more secure. There’d be:

• less people (such as Robert Scoble) complaining about WordPress security.
• less need for Matt to write public responses outlining why people should upgrade.
• less complaints about bugs and the loss of functionality.

There’ll always be bugs in software and there’ll always be people who complain – but more comprehensive beta testing would lead to less bugs, leading to less unhappy users, leading to more sites being updated immediately, leading to less hacking, leading to even less unhappy users.

Better beta testing begets better security.

2. Balance Between Upgrade Speed Vs Security

Alternatively, if we don’t leave aside my beliefs, if we can moderate the unthinking update immediately advice, then we’re provided with a tremendous opportunity:

On a case by case basis, we can decide if an upgrade is in the “update immediately” category or in the “can wait for critical bugs to be fixed” category.

My solution, way down the bottom of this post, is going to propose delays to upgrades that are not for critical security issues, so that user experience less critical bugs. But more on that later.

The Problem: A Lack Of Beta Testers

The problem, which has been mentioned in various places including the podcast, is that although WordPress has a beta testing phase, there aren’t enough end users testing it to catch all the critical bugs. The software appears to runs fine during beta testing, but bugs rise to the surface when the release is rolled out to everyone.

First, some facts:

• Software is always going to have bugs
• Beta testing will never find all the bugs

There will always be some bugs that are only triggered when the software is run in an obscure environment or is used in a way that’s slightly different from how most people use it.

So it’s not about eliminating bugs, just about reducing the number of critical bugs that get through beta testing. The only way to do this is to get more people, using the software in different ways, on different server environments, to test the software.

How do we get more people to test the software? The answer’s coming soon (honest).

Software Release Management Anecdotes

First, let me say that I worked in the software industry (for a library management system vendor) for 10 years. For quite a bit of that time, I was the person who authorised the release of software to clients and/or agents.

I could bore you with software release management anecdotes going back to 1994. Luckily for you, I came to my senses and edited them out! I’ll just say that making sure that major releases were properly tested and free of bugs was extremely important for the following reasons:

• Loss of reputation, harming future sales: Upset users are significant in the relatively small library software marketplace.
• Direct financial loss: yes, it cost a significant amount of money to burn 5000 CDs back in 1994 (and then post them out).
• Lots of additional work: printing letters, packaging CDs and supporting users who were upgrading, etc.

Obviously, WordPress operates in a very different environment from library software industry of old and many of these points are less of an issue:

If WordPress lose one user, or even ten thousand users, because of loss of reputation, they don’t actually lose any money in sales (actually there is no they!). If they have to release an upgrade, there are no costs for CDs and postage, people just download it. There’s no surge in the amount of support they need to provide, as support is crowd sourced.

Does that mean WordPress can afford to ignore this issue?

I say No – they should care about their reputation (and their users), even if there isn’t the same financial emphasis that there is in the closed source software industry. In fact, they should look to the closed source software industry and learn from it. Solutions to this very problem have been worked on and refined for decades.

In my particular case, we had several major incidents that led to us refining our testing and release processes. We ended up moving to a process that involved three phases of testing – I’ll outline these and relate them to WordPress in the next section.

The Three Phases Of Testing

1. Developer Testing

I’m sure this is done comprehensively by the WordPress developers. Ultimately, we employed a couple of full time testers, which Automattic could possibly consider funding. They may already have some testers (besides the Chief BBQ Taste Tester), although it’s not obvious from their About page.

But the problem isn’t here and full time testers would only have limited impact, so let’s keep moving.

2. Beta Testing

This is being done, but the problem is that not enough end users are involved. WordPress could look at ways to entice more users to join the beta testing program, but many of the methods that the closed source software industry use, such as offering discounts to beta testers, won’t work in the open source world.

One idea could be to build in a "do you want to upgrade to the beta version (for the greater good)" message into the automatic update function. When a beta version is released, everyone gets this message.

It would have to be very clear that it was a beta version and that there may be some problems and it would need Yes, No and Never Ask Me Again options, but it could work. Not many would choose to upgrade, but 1% of 3 million is 30,000, which is a lot more than the number of current beta testers.

Once again, though, I don’t think the answer is here. It would be a significant improvement, but could cause a lot of negative publicity: there’d be too many people who’d choose it accidentally, then blame WordPress for upgrading them to beta software.

3. Live User Testing / Staged Release

So we come to the solution at last (I told you we would) and it’s not in the beta testing phase.

Instead, the answer lies in a staged roll-out to users: limiting new releases to a relatively small number of people until it’s proven that there are no major problems.

If any major problems are found, a decision can be made on whether they are serious enough to fix immediately, before making the software available to the rest of the users. Even if it’s decided not to fix the problems, users can be made aware of issues that may affect them before they upgrade. Even that small improvement would make a real difference to users.

The staged release approach been used for decades. I was using it 15 years ago. Google uses it today: they roll-out new features in Google Analytics or Google Adsense slowly.

How Would A Staged Release Work?

A staged roll-out of WordPress would work something like this:

1. Once the beta testing phase is complete, the automatic upgrade notice would be sent out to say 100,000 people.
2. There would then be a period of say one week, where the feedback would be monitored and any critical bugs identified and investigated.
3. At the end of the period:
   • if no critical bugs have been identified, then the automatic upgrade would appear to everyone else.
   • If critical issues have been identified, a decision would be made on whether to proceed with the release or delay it until the problem is fixed.

It goes without saying that urgent security releases would bypass this.

Now I’m not talking about physically denying the software to anyone, just manipulating who gets it through the automatic upgrade process. Anyone would still be able to visit wordpress.org and download the lastest version.

How Would A Staged Release Be Achieved Technically?

I’m not the best person to answer that, but I’d imagine it wouldn’t be too hard to do. It would require the automatic upgrade function to be modified: instead of WordPress installations asking "is there a new version", they’d ask "is there a new version and can I have it".

On the server side, it would check the download count and, when it reached the threshold, start saying no. You could make it complicated (checking whether it’s been downloaded from this IP address before), but it would be best to keep it simple.

There exists the potential that some users may be unhappy about either getting the new version before it’s been through live testing, or having to wait until after. The key here is that users are not getting the beta version, they’re getting the real version that’s been through beta testing, just as they would now. It’s just that it’s being rolled out slowly to further protect users.

This would need to be well communicated.

Of course, it could be made it opt-in. The first 100,000 users could be shown the message: "WordPress 3.1 is available! Update or Wait". If they choose Wait, it won’t ask them again until the live release testing is complete. The rest of the users would be shown: "WordPress 3.1 is available, but we recommend you wait for moment. Wait or Upgrade anyway".

Final Thoughts

So the solution to the beta testing problem isn’t actually within the actual beta testing phase. It’s just to roll out the upgrades slowly, giving time for critical bugs to be caught before they affect too many people. This would protect the majority of users from any serious bugs.

Personally, I have doubts that this would ever be adopted: I think it would be seen as too complicated. But really, it wouldn’t be that hard to do and would make life better for the vast majority.

What do you think? Am I crazy? Do you disagree with me? Do closed source practices have no place in the open source world? Do you have a better idea? Let me know!

Go to Posts -> Edit in the WordPress Admin area and you’ll see a list of all the posts you have. There is a dropdown list called View all categories, which allows you to select a single category to view posts from. But…

What if you want to view posts from more than one category, or better yet, want to exclude posts from certain categories? Can’t do it right? Well not through the WordPress interface, but you can do it through URL parameters.

Finding Out Your Category Numbers

To make this work, you’ll need to know the category numbers for your categories. You can find these through either of the following two methods:

1. Go to Posts -> Category screen and hold your mouse over the category in question. In your browser’s status bar you will see a URL which ends in ID=xx (xx is the number of the category).

OR

2. While still in Posts -> Edit, select the category you want in the dropdown list and click Filter. You’ll be taken to a page showing only posts from that category. In the browser’s address bar you’ll see that the URL contains cat=xx (xx is the number of the category).

The first method is quicker if you want to look up multiple category numbers (you may want to write them down). The second method is better if you’re just after one or two category numbers – you’ll need to do this step anyway.

First Step

By default, the Posts -> Edit screen has a URL that ends in wp-admin/edit.php with no parameters, eg:

http://www.scratch99.com/wp-admin/edit.php

Rather than typing all the parameters, it makes sense to start with a URL that includes them.

If you haven’t already, select one of the categories you want to include / exclude in the dropdown list and click Filter. You’ll be taken to a page showing only posts from that category, but you will now have a URL that looks like this:

http://www.scratch99.com/wp-admin/edit.php?s&mode=list&action=-1&m=0&cat=92&action2=-1

We’re going to be changing the cat=xx part of the URL.

Displaying Posts From More Than One Category

Perhaps I want to display posts from more than one category – in my case, I may want to see all the posts from my WordPress and Web Development categories, but not from the rest of my categories (too much noise).

Easy. Simply edit the URL and change the cat=xx to cat=xx,xx (where xx is the category numbers that you want). In my case, I change the URL to the following (note the cat=4,65):

http://www.scratch99.com/wp-admin/edit.php?s&mode=list&action=-1&m=0&cat=4,65&action2=-1

Want posts from three categories? That’s right:

cat=xx,xx,xx

You’ve got it now!

Excluding Posts From Certain Categories

It’s also possible to exclude posts from certain categories from appearing in the Posts -> Edit screen.

Why would I want to exclude posts from certain categories? Actually, that’s how I started looking into this issue. I haven’t been posting much recently and, as a result, my weekly automatic lifestream digest posts pretty much filled up the screen:

I was having trouble seeing my real posts!

Thankfully it’s easy to exclude the category that these posts are in. Simply edit the URL and change the cat=xx to cat=-xx (where xx is the category number you want). In my case, I change the URL to the following (note the minus sign, eg: cat=-92):

http://www.scratch99.com/wp-admin/edit.php?s&mode=list&action=-1&m=0&cat=-92&action2=-1

The result:

Want to exclude posts from more than one category? That’s right:

cat=-xx,-xx,-xx

Final Thoughts

That’s all – it’s a fairly long post for a fairly simple tip. It’s probably not something that will be needed often, but in some circumstances it’s very useful to have greater control over which posts appear on the Edit Posts screen.

Happy New Year to all! A year ago, after looking at my Google Analytics stats for the year, I wrote a post reviewing 2008. I figure I may as well do it again for 2009 and also take the opportunity to explain the direction of this site.

The Top Ten Visited Posts In 2009

According to Google Analytics, the top ten visited posts in 2009 (with the home page and plugin pages stripped out) were:

1. Creating A JavaScript Array Dynamically Via PHP (2008)
2. Blogger – How To Add Adsense Inside Single Posts Only (2009)
3. How To Display Ads Only To Search Visitors (2008)
4. Poll – Which WordPress Theme Framework To Use? (2009)
5. WordPress – Simple CSS Text Boxes In Posts (2007)
6. WordPress – Most Viewed – Sidebar Widget (2007)
7. WordPress – Rounded Text Boxes in Posts (2007)
8. Custom Page Templates – Calling An External CSS File (2009)
9. Setting Cookies In WordPress – Trap For Beginners (2008)
10. How To Avoid Adsense Smart Pricing On Blogs (2008)

While I feel some of those posts deserve to be there, there are some that I don’t feel are particularly deserving.

Also, as you can see, there’s only 3 posts written in 2009 in that list. The others were written in 2008 (4 posts) or 2007 (3 posts). I guess that’s not too surprising as a lot of my traffic comes from search engines and old posts are just as likely to rank well as new ones.

It also doesn’t help that I only wrote 20 posts in 2009 (not counting automatic lifestream posts), but more on that later.

My Top 5 Posts From 2009

Last year, I included a list of the 10 posts that I thought were my best in 2008. If I were to do this again for 2009, I’d only go with 5 articles that I was particularly happy with. There are others which are okay, but don’t particularly stand out for me.

So, here are my top 5 posts written in 2009:

1. Subscribe To Comments & Protected Wp-admin Folder
2. Blogger – How To Add Adsense Inside Single Posts Only
3. Show Adsense To Search Visitors Only – On Blogger
4. XAMMPLite Virtual Directory And WordPress Permalinks
5. Sharepoint As A CMS – Microsoft Tech.Ed Australia 2009

Other Interesting Stats From Google Analytics

Google Analytics also provided some interesting statistics for 2009 on this site.

Traffic

The site had significantly more traffic in 2009 than in did in 2008. There were 75,343 Visits and 113,016 Pageviews in 2009, up from 46,488 Visits and 74,916 Pageviews in 2008.

That said, the first half of 2009 was the best: traffic tailed off slightly in the second half of 2009 (since I disabled my DoFollow plugin).

It will be interesting to see what will happen in 2010. Unlike last year, I’m not particularly concerned about whether traffic will increase in 2010.

I now consider this site as an area for me to write about my WordPress plugins and my Greasemonkey scripts – I no longer have any grand ambitions about creating a thriving blog.

Browser Breakdown

The vast majority of visitors were using Firefox. That isn’t surprising given the nature of this blog, as it appeals to web developers and bloggers, groups given to using FireFox. The full breakdown is as follows:

1. Firefox – 67.62%
2. Internet Explorer – 17.65%
3. Chrome – 6.24%
4. Safari – 4.75%
5. Opera – 2.30%

Of the Internet Explorer users, 20.66% were using IE6 (about 3.6% of all visitors). Too many! The numbers are roughly the same as last year, but with a slight drop for IE and a 5% increase for Chrome.

Operating systems

The major operating systems used by visitors was virtually the same as last year, being dominated by Windows. The full breakdown is as follows:

1. Windows – 82.92%
2. Macintosh – 12.28%
3. Linux – 4.25%

Top 10 Screen Resolutions

The screen resolution of visitors is always important to web developers. I’ve included the top 10 resolutions below.

1. 1024×768 – 21.23%
2. 1280×800 – 19.57%
3. 1280×1024 – 15.07%
4. 1440×900 – 11.88%
5. 1680×1050 – 11.06%
6. 1920×1200 – 5.21%
7. 1152×864 – 2.36%
8. 800×600 – 1.76%
9. 1366×768 – 1.50%
10. 1280×768 – 1.46%

Interesting things to note are:

• 800×600 has actually moved up one place, despite me proclaiming last year that it had almost dropped off the list at last. It’s hanging in there grimly.
• 1024×768 is still the most popular, but it’s 5% lead in to 2009 has been reduced to just 2% in 2009. Will it hang on in 2010?

Top 10 Countries

1. US (by far)
2. India
3. UK (London was the top city)
4. Canada
5. Australia
6. Philippines (Hi RT)
7. Germany
8. Indonesia
9. France
10. Netherlands

Not much change here.

Report Card For 2009

I didn’t meet many of my goals for 2009, as I changed my objectives during the course of the year. Here’s a brief rundown on how I did for each of my 2009 goals.

Post More Often

I published 52 posts in 2007, followed by 41 posts in 2008. One of my 2009 goals was to post more often. I failed big time, only publishing 20 posts in 2009. As I said last year:

It’s not for lack of ideas – I have lots of half written posts that I just need some time to finish off. I tend to spend more time working on my projects than writing about what I’m learning.

That’s still true, but I’m more comfortable with it now. I’ll probably post more this year, but won’t sweat it if I don’t.

Post On Topic

Last year I wrote:

It’s noticeable in my top 10 posts above that many are my Make Money Online posts. I’d like to keep posting on that topic as I learn more about it, but I want to post more often on my Web Development efforts (and WordPress of course).

I didn’t post often in 2009, but I was probably more aligned with my core topics than in 2008.

Update My Current WordPress Plugins

I had planned to overhaul my my existing WordPress plugins and move them into the official WordPress plugin directory. Didn’t happen. The new ones are going into the official directory, but the old ones haven’t been touched. Still on my list for 2010.

Release Some New WordPress Plugins

Last year I wrote:

I started off by writing that I’d like to release another 4 WordPress plugins this year (I already have 4 half finished plugins that I want to finish off). However, thinking of my workload, I changed it first to 3 plugins, then to 2 plugins! So we’ll have to see how many I can actually get out.

Spot on! I released 2 new plugins in 2009. I’m sure more will follow in 2010.

Release A WordPress Theme

I had been thinking that I’d release a WordPress theme in 2009. Didn’t happen. This is now far down on my priority list. I may release one in future if I create my own theme framework for my sites, but it’s not likely anytime soon.

Release Some Greasemonkey Scripts

I released a couple of Greasemonkey scripts in 2009 and plan to release more in future. Greasemonkey rocks! I write little scripts for it all the time, although I haven’t released many of them (yet).

Changing Goals For 2010

I don’t really have many goals for this site in 2010. As I mentioned above, I’d like to update my old WordPress plugins and move them into the official directory, release some new WordPress plugins and release some new Greasemonkey scripts, but that’s about it.

I have other projects, which I won’t mention here, that are more of a focus for me in 2010. This is just going to become the ‘portal’ to the software I release, with the occasional post thrown in.

Final Thoughts

Well that’s a quick look at the year that was and the year that will be here at More Than Scratch The Surface. I hope all your endeavours for 2010 are successful! If you have any big plans for your blog, feel free to share in the comments.

It’s been over a month since I published my notes on the Thursday session of Microsoft Tech.Ed Australia 2009. In that post, I promised to write up the SharePoint discussion session separately. Finally, here it is.

Session Details

Session: BOF007 SharePoint, .Net and SQL blended applications
Presenter: Elaine van Bergen
When: Thu 9/10 | 12:45-13:45 | Meeting Room 5

Official Description

Join Elaine van Bergen in this discussion as to why SharePoint is a powerful platform which is increasingly used to build applications. This session will include discussion on methods for addressing the many challenges faced in scenarios such as:

• A complete custom user interface build on top of SharePoint, such as a public facing internet site
• SharePoint application with complex relational components provided by SQL Server integration
• An ASP.Net application running beside SharePoint using components such as search
• A generic application that is written in a way to be able to switch in and out SharePoint.

The knowledge discussed will be based on recently completed SharePoint projects and will include debate on pros and cons of various approaches, approaches for .net developers moving to SharePoint, ways to avoid or workaround common problem including when to just use a pure custom build instead of SharePoint.

My Comments

This session was the highlight of the day for me. It was held in one of the meeting rooms and had about 70 or 80 people, with 4 or 5 facilitators leading the discussion and running around to get people’s input.

The lead ‘presenter’ was Elaine van Bergen, State Manager of .Net at OBS. The other facilitators were all leading .NET / Sharepoint consultants from around the country. There was discussion around Documents Records Management and various other disciplines, but I’m only going to focus on using Sharepoint as a Web Content Management System.

The thing that shone through for me was a consistent message that:

1. Sharepoint won’t do everything you want out of the box
2. It can be made to do anything but you’ll have to customise it
3. Sharepoint development is complicated

I’ve heard a lot of anti Sharepoint rhetoric in web development circles, but this is far more valuable for me.

This isn’t coming from people with an anti Sharepoint agenda. This is from the people on the ground who make their living by implementing Sharepoint. These people are some of the top Sharepoint professionals out there, those that Microsoft selected to run a session at Microsoft’s biggest annual developer event.

Now, they’re not criticising Sharepoint. They’re just giving us a realistic view of implementing Sharepoint.

Why is this so important? Because I’ve heard the Microsoft sales pitch for Sharepoint and they are super smooth. There is no hint of weakness, no acknowledgement that implementing Sharepoint may involve a lot of effort or that it may be complicated.

Personally, I think that’s why Sharepoint has a bad name in some circles: Microsoft don’t give clients a realistic view of what they’re getting into.

Onto some of the quotes (well paraphrases actually, I can’t type that fast!):

One of the facilitators was actually anti Sharepoint which surprised me given the setting. I didn’t catch his name, but he said that for public websites, Sharepoint is the very last resort, because of the problems he’s seen in implementing it. He said his preference was to build the site in ASP .NET. He seemed to be talking about a site with minimal content pages and a lot of products in a database.

I personally think that while creating that site with ASP might be feasible, it’s not practical for a site with a large number of content pages of varying types. A Content Management System would be essential in that scenario.

Anyway, he moved on to talk about forms. For one client he had to use InfoPath for forms because the client’s forms were too complex for Sharepoint. They used Sharepoint to store the forms, but they kept the application layer separate, because the analysis logic and Silverlight were too hard to build into Sharepoint.

One of the audience members backed him up and said they use ASP .NET for forms because it’s too hard to make forms look the way the user wants in Sharepoint. However Elaine responded to both by saying that Sharepoint was good, as long as you employ staff to fix the UI layer.

The anti-Sharepoint facilitator went on to say that the decision to use Sharepoint should be made by technical people deciding it’s the best solution for the problem, but that it seemed to him that the decision is often made by business people. They decide to buy Sharepoint without having properly considered how it will used, then they look at what they can use it for, which is the wrong way around.

An audience member related their experience with the Starlight Foundation: they consolidated 70 different sites across various open source systems onto a  common platform of Sharepoint. For one of those sites, they had to create a .NET website because Sharepoint "couldn’t deal with it". For the other 69 sites, Sharepoint was fine. That seems like good odds to me.

Elaine said that Sharepoint won’t cater for all your needs out of the box. You need to do some analysis and you’ll probably have to write some customisations yourself. She also said that it’s very difficult to do unit testing.

Another audience member said that he has to do development on the server – he can’t do it on his workstation because his computer isn’t powerful enough to run Sharepoint.

Someone else said there were issues between the Silverlight and Sharepoint web parts. Elaine said that while she can’t comment on that problem specifically, there are a lot of Silverlight related improvements in Sharepoint 2010, which is coming soon.

Another person said that they didn’t have any problems with implementing Sharepoint, but that was because he’d created a custom library to tweak the default web parts.

Elaine said "Sharepoint is its own enemy, you can throw all sorts of things in and it won’t all work together. Have a look at DevWiki. Sharepoint development is complicated – there’s a lot to know if you want to build a simple to use and scalable site."

That’s the end of the ‘quotes’. If they sound negative, I need to point out that the discussion wasn’t negative – it was well grounded and based on a realistic viewpoint. The facilitators openly discussed the issues involved with implementing Sharepoint, warts and all. They were positive in places, but acknowledged the problems in other places.

For me, it was a real eye opener, and extremely valuable in understanding just what we’d be getting into if we went down the path of using Sharepoint as a CMS. It could do what we need it to do, but not out of the box and a reasonable amount of work would be required to get it set up correctly.

There are a bucketload of blog posts out there about web hosting. The vast majority of these are either praising their current hosts (along with a nice little affiliate link for you to click) or berating them for poor service.

Today, I’m going to do something different: I’m going to praise a web host that I no longer use and for which I don’t have an affiliate link.

Why would I take the time to do this? I truly believe that the company in question, kwikhosting, offers exceptional customer service.

First some background: I first used kwikhosting back in 2006 to host a single short term website (related to the 2006 FIFA World Cup in Germany). I can’t tell you exactly what the uptime was like. I didn’t notice it, which means it must have been pretty good. The site was fast, despite the server being on the other side of the world from me (it was in Houston, I was in China).

There were a couple of issues in the initial setup of the site (my fault), but they were resolved like lightening. Answers came back within minutes (at best) or a couple of hours (at worst).

So why did I leave kwikhosting? Well, I’m ambitious and I had my eyes on creating several different sites. Kwikhosting didn’t offer unlimited domains. Hostgator did (yes that is an affiliate link).

I swapped and, as they say, the rest was history.

I’m very happy with HostGator. I’ve been with them for several years and have had very few problems. On the couple of occasions when I have needed to contact Hostgator support, the issue has been resolved pretty quickly. But as great as they are, the service can’t compare with kwikhosting.

I guess the analogy is that HostGator is like the large national chain of supermarkets that’s cheaper and has more products, but which has large impersonal service points, while kiwkhosting is like the corner store that’s slightly more expensive and doesn’t have the range, but the guy behind the counter knows all the customers and treats them like old friends.

Would I move back to kwikhosting? No, I need the extras offered by HostGator.

Would I recommend kwikhosting? Definitely, especially to people who only have a single site.

Why am I writing about this now? I recently moved to consolidate my domain names onto one domain reseller. I had a domain name being looked after by kwikhosting and wanted to transfer it away from them.

Halfway through the process, I realised that it would take up to 5 days to transfer the domain – which put the transfer day as the same day the domain expired. I was worried there’d be complications as a result.

I contacted kwikhosting for assistance in fast tracking the transfer. Even though I was transferring away from them, the service was just like it was back when I was a new customer. They were very fast to respond, they found out what I needed to know and they fast tracked things for me.

They even offered to renew the domain at the price of the new domain registrar (lower than their normal fee). Pure class.

Anyway, this post is just a shout out to kwikhosting, a web host with great customer service. Thanks guys!

I was fortunate to attend Microsoft Tech.Ed Australia 2009 last week. I made copious notes during the day, so I thought I’d share them.

Tech.Ed At Last

This was my first time at Microsoft Tech.Ed. I almost went to Tech.Ed 2000 in Cairns: I was working for an integrated library system software house that was a Microsoft Certified Solutions Provider and Tech.Ed was the highlight of the year. Everyone wanted to go, including me, but in the end I missed out.

Fast forward to Tech.Ed 2009 on the Gold Coast: I’ve long moved on from the MCSP company I used to work for. I’m now a web developer and when the opportunity to attend TechEd arose, I was a little skeptical of the benifits:

Sure, Tech.Ed had a web track, but it’s based heavily around .NET development, which my team doesn’t do much of- we focus mostly on the client side (HTML, CSS, JavaScript), usability and accessibility, etc. We have a strong emphasis on being standards compliant and lets face it, Microsoft haven’t got the best reputation when it comes to standards. To top it off, although we don’t use it at work, I consider myself a PHP developer.

So, when I wanted to go to Tech.Ed, I didn’t get the chance and when I got the chance, I didn’t want to go!

Given the choice, I would have rather gone to a conference relating to Search Engine Optimisation, Usability, Accessibility, etc. However, there was a position available and we identified a genuine business need for me to go, so along I went. As it turned out, I did get some real value from it.

Arriving At Tech.Ed

Tech.Ed 2009 was held at the Gold Coast Convention and Exhibition Centre at Broadbeach, just across the road from Jupiter’s Casino.

I drove down from Brisbane in the morning, arriving a little after 9am. I parked at the Casino and walked across. The Exhibition Centre was bustling with people as I collected my ticket and the HP Mini that every attendee is given, then headed off to find the session I’d earmarked for 9:45am.

One of the things I noticed was that about 99% of the people in centre were male! There were more women in the web sessions (perhaps 10%), but the low number of women was was really noticeable, especially in out in the corridors.

The HP Mini

Whilst waiting for my first session to begin, I fired up the HP Mini and had a go with it. I have to say I was very impressed with it. It was running Windows 7 Ultimate, which seems nice (better than Vista) at first glance. It carries an Intel Atom N270 1.6GHz processor, 2 GB RAM and a 149GB HDD.

I have an Acer Aspire 1 netbook that I use each day on the train and I have to say that that the HP Mini tops it. Although the maximum resolution is similar (1024 x 600 for the Acer, 1024 x 576 for the HP), the HP Mini’s 10 inch screen was bigger than my Acer’s 9 inch screen. The overall physical size of the HP Mini wasn’t noticeably larger, although the keyboard did seem bigger and more comfortable to use. Battery life and overall quality both seemed better .

Logistics wise, there were plenty of recharging points around the exhibition centre where you could recharge your HP Mini. These were mostly full, most of the time, but there were always some spaces available.

The wireless network connection was decent throughout the day, although it did drop out once for about 10 minutes and there were some slow moments (mostly during lunch time).

Having the HP Mini was very useful, as it allowed me to make notes on the fly. When I’m back at work, it’ll be much easier to action these notes. If I’d used pen and paper, the notes would probably sit on my desk for a month before I typed everything up. Now it’s mostly done, I just need to tidy them up a little.

It also made me think about live blogging. I’ve read posts by live bloggers such as Lisa Barone and have been impressed by what they’ve been able to do. Now, all of a sudden, I was sitting in a conference with a laptop and an internet connection. It wouldn’t have been a big step to turn my note taking into live blogging – but in the end, I was on my employer’s time and they need me to spend that little bit extra time concentrating on how we could apply what I learnt, rather than trying to capture everything and blog about it.

Lunch And Goodies

You can’t talk about a conference without talking about:

1. the food
2. the giveaways

On the food and beverage side of things, free coffee was in plentiful supply – both from ‘make your own’ service points and from proper coffee stands (but there were big queues at time).

Lunch was great, although they did run out of food as I got to the head of the queue and we had to wait 5 minutes till they got some more food out. The food itself was great for a conference and there was everything you’d expect.

The items put out for afternoon tea were interesting. They looked more like a kids party than a conference: bright coloured jellies, sherbet cones, chocolates coated in hundreds and thousands. Geek food perhaps? An interesting choice anyway. There was free ice cream somewhere, but I missed it.

As for giveaways, they were in very short supply, especially compared to the library software shows I’ve been to in the past. There was virtually nothing, even in the Expo room. Of course, all attendees were given a HP Mini, so I can’t complain about the lack of pens, hats and other such things!

Sessions

It’s time I started talking about the sessions! I attended 5 sessions in all and I’ve outlined my thoughts (and the official description from the Tech Ed website) below.

WEB304 Building Silverlight applications for Microsoft Dynamics CRM

Presenter: Jian Sun

When: Thu 9/10 | 9:45-11:00 | Meeting Room 8

Official Description:

We start with demonstrating some real world examples of Silverlight applications built on Microsoft Dynamics xRM implementations. We then will look at how Microsoft Silverlight can be used to deliver richer experiences within Dynamics CRM applications. We’ll explain the fundamentals of XAML and Silverlight before discussing hosting and connectivity approaches to integrate Silverlight applications into both the Out of Box CRM UI as well as Customer Self Service we portals. This session will provide a practical how-2 demonstration of a Silverlight based Dashboard for Dynamics CRM

My Comments:

The Citrix session next door was was packed, with several hundred people fighting to get in the doors. In contrast, there was no trouble getting into Building Silverlight applications for Microsoft Dynamics CRM and there was total of only about 50 people in the session.

The presenter, Sun Jian, was quite likeable. He started off by saying that we needed some knowledge on

1. Microsoft CRM
2. Silverlight
3. C#.

Three strikes for me before he even got on to the topic!

The topic was of very little use to me, either personally or professionally. This was the only web session on at the time and there was nothing else on of interest to me, so there I was.

We got to see a Silverlight application being developed. He used Visual Studio to create the app, along with Expression Blend to style the user interface. It made me wonder whether Silverlight applications can be developed with alternative (ie non Microsoft) software.

I’ll have to look into it as I don’t have either – not that I’m expecting to develop any Silverlight apps in the near future. Actually, I’m still wondering why anyone would choose Silverlight over Flash, which would be present on a much greater number of computers. If anyone has views on this, please let me know via the comments below.

One useful tidbit I did pick up was that Silverlight doesn’t need the full .NET framework to run. That makes sense if they’re trying to compete with Flash – they’d need to keep the size of the player as low as possible.

Sun Jian embedded the Silverlight app in an iFrame within Microsoft CRM, passing parameters to Silverlight via the code calling the iFrame (I think). Quite interesting.

He did have a problem with the Silverlight app working, which turned out to be a spelling mistake. Haven’t we all been there! Anyway, Sun recovered well using humour to turn the problem to his advantage.

WEB305 Modular User Interfaces: Easier than Ever

Presenter: Omar Besiso

When: Thu 9/10 | 11:30-12:45 | Arena 1B

Official Description:

WPF & Silverlight, the new cool neighbours you always wanted to have. Yet you’re still scared to introduce yourself. Well in this session Omar Besiso will not only introduce to the beautiful world of simple WPF, but will also show you using the WPF composite framework & the Model-View-ViewModel pattern how you can build highly scalable user interfaces with very appealing user experiences. After the session you will think twice before using any other technology for your windows or web apps.

My Comments:

Once again, this session didn’t promise much of interest me: I don’t develop Silverlight applications and I don’t use WPF. In fact, I’ve never even heard of WPF, which as it turns out, stands for Windows Presentation Foundation.

Although in the Web stream, this session only had a tenuous connection to web development. Web applications development perhaps (quote description: "for your windows or web apps"), but not straight up web development.

The session was held in a much larger room, with tiers of chairs flowing from the upper level of the building, down to the stage on the ground level. There were a couple hundred people. It was quite dark (ie too dark) compared to the first room.

Omar started off saying he was going to build an RSS reader using WPF. That peaked my interest as I’ve written various PHP scripts that work with RSS feeds. However, it didn’t turn out as interesting as it sounded and I consulted my schedule.

There was a "discussion" over lunch that I wanted to attend. As the Modular User Interfaces session didn’t really have anything applicable to me, I left early (after 40 minutes) and headed off to try to get an early lunch.

BOF007 SharePoint, .Net and SQL blended applications

Presenter: Elaine van Bergen

When: Thu 9/10 | 12:45-13:45 | Meeting Room 5

Official Description:

Join Elaine van Bergen in this discussion as to why SharePoint is a powerful platform which is increasingly used to build applications. This session will include discussion on methods for addressing the many challenges faced in scenarios such as:

• A complete custom user interface build on top of SharePoint, such as a public facing internet site
• SharePoint application with complex relational components provided by SQL Server integration
• An ASP.Net application running beside SharePoint using components such as search
• A generic application that is written in a way to be able to switch in and out SharePoint

The knowledge discussed will be based on recently completed SharePoint projects and will include debate on pros and cons of various approaches, approaches for .net developers moving to SharePoint, ways to avoid or workaround common problem including when to just use a pure custom build instead of SharePoint.

My Comments:

This session was the highlight of the day for me and I have extensive notes on it – so many that I’ve decided to put them into a separate Sharepoint post (coming soon).

WEB208 Your Windows Live Messenger Web Toolkit

Presenter: Vaughan Knight

When: Thu 9/10 | 13:45-15:00 | Meeting Room 9

Official Description:

Hook your website instantly into a social graph of over 400 million users with Windows Live Messenger Web Toolkit. In this session Vaughan Knight will discuss how to get started with the Live Messenger UI controls, and then dive in deep with the Windows Live Messenger API. Come away from this session knowing how to connect sites and build applications that to reach out into the Live Messenger social network. Learn how to use the Live Messenger API to allow your site and users to interact with the social graph, send messages, integrate and build applications with Silverlight, and create site features that are social graph aware.

My Comments:

There were only 5 people at this session (20% female which must be a record for the day). The session was showing how to integrate the Live Messenger Web Toolkit into your website, adding social media abilities to your site.

The most obvious feature seems to be ability to add chat to your website, allow users to give you instant feedback via an Instant Messenger embedded in your site. There are quite a few other solutions for live chat, but if you’re a fan of the Microsoft Instant Messenger client, this may be the solution for you.

The web toolkit also includes other features that utilise the network of Live Messenger users. For example a Live Messenger bar can be added to the bottom of your web pages and visitors who are logged into Live Messenger have access to additional functionality.

Apparently it is easy to set up out of the box, but you can also create your own interface using either:

• HTML UI controls (XHTML), along with server side components for .NET, PHP etc.
• Live Messenger UI controls (Flash, Silverlight, Java applet), along with the same server side components.

This session was sort of interesting, but didn’t really catch me, for several reasons:

• To be honest, I was still writing up my notes on the Sharepoint session, which has far more importance for me.
• The web toolkit is probably not appropriate for my organisation’s websites (at least for the moment).
• I’m not likely to use it on any of my personal sites, and following on:
• Lets face it, Microsoft just aren’t cool when it comes to Social Media. Integrate Twitter? COOL!! Integrate Live Messenger? zzzz…

Still an interesting attempt by Microsoft to get more involved in social media.

WEB306 Building Fast, Standards Compliant ASP.NET sites

Presenters: Damian Edwards, Tatham Oddie

When: Thu 9/10 | 15:30-16:45 | Arena 2

Official Description:

In this demo-packed session, Damian Edwards (MVP) and Tatham Oddie (MVP) will share their experiences from building Australia’s largest e-commerce site with ASP.NET Web Forms. They’ll show you how to be a good web citizen by covering standards compliance (properly!), cross browser and accessibility considerations, non-JavaScript support, coding techniques like the Model-View-Presenter pattern to improve maintainability and testing, as well as both client and server side performance. Along the way, there’ll be plenty of discussion of the differences between Web Forms and ASP.NET MVC in each area, as well as an early peek at some of the new features coming in ASP.NET 4 and VS 2010.

My Comments:

This was a great session, looking at how to run and optimise a high traffic website, based on the presenters’ experience with graysonline.com.

It was the only session, in the whole day, that had a lot of value for non ASP .NET web developers, covering issues such as doctypes, CSS, accessibility, jQuery, Firefox extensions, improving performance, etc.

For me, the session fell neatly into two halves:

• The first half which, although interesting, wasn’t anything I hadn’t heard of before (via my RSS reader); and
• The second half which truly pushed the boundaries of my knowledge.

I’ll briefly list some of the things they covered:

They focused on markup. They are proponents of using XHTML 1.1 Strict, which I found interesting. I’m still using XHTML 1.0 Transitional for most things. I find Strict too … strict. So I respect them for making the effort to use Strict. They did mention that moving forward they are going to try to use HTML5 more, now that the XHTML project has officially been discontinued.

They used CSS friendly code adaptors, to change what the server delivers at run time. This one is an ASP .NET only one, although there are probably similar utilities out there for other languages.

Visual Studio 2010 was their IDE of choice. I have to say that the code completion / sanitization functionality looks pretty good, up there with anything I’ve seen. Of course I won’t be using it any time soon, what with the price and so many good cheap alternatives out there.

Accessibility! The Sydney Olympic case was raised (it’s the poster child for accessibility related legal cases). They said to make sure that the site complies with WAI, WCAG, WAI-ARIA, WebAIM and WAVE. This is important not just for people, but also for search engines such as Google and Bing (they’re the ones they named).

Regarding optimisation, they used Firefox, "as all web developers should", along with Firebug and Y-Slow to measure performance. Their main tip was to reduce http requests, through the use of CSS sprites, combining JavaScript files, combining CSS files etc. Their combined JavaScript file was 250KB and the HTML was 120KB, before being compressed using GZip.

For ASP .NET developers out there, you can’t use the built in automatic method to add scripts, as it will include the files individually. You need to combine the files manually, then call the combined file. They also said to set Load scripts before UI to false, so the JavaScript loads lower down the page.

They used Fiddler to slow the download speed to emulate dial up. They added version numbers to the CSS and JavaScript file URLs, so that new files can be forced to be used (ie instead of the old ones in the cache).

They talked about using different subdomains to serve up images etc, to get around the limitation on concurrent downloads from the same server. They mentioned that Bing maps use 4 subdomains for tiles, so more can be served up at the same time. However, if you’re doing this, you can’t use etag for caching because it doesn’t handle multiple servers for delivery.

High traffic websites should have a full time front end web engineer for UX (User Experience) and Accessibility.

A very clever tip for scaling: When server load is light, they use heavy GZip compression. As server load increases, the amount of compression decreases, meaning less work for the server (for each page served up), but larger files for the end user. Clever.

Final Thoughts

Well that wraps it up. I had a good time and learnt a fair bit at Tech.Ed 2009. It still would be my conference of choice, but I’m glad I went.

I’d like to announce the release of my second Greasemonkey script: Google Numbered Search Results; which numbers the SERP entries delivered by the Google search engine.

Other Scripts To Number Google Search Results

If you’re someone who’s likely to use this (ie an SEO practitioner or website administrator checking their rankings), you’re probably saying "Wait! Aren’t there already Greasemonkey scripts for this?"

Yes there are.

For years, I’ve relied on the Numbered Google Results script, but it seems it’s not being updated. When Google introduced the SearchWiki functionality, it stopped working, prompting me to write a simple hack to fix the problem. I left a comment on the script’s home page, but the fix wasn’t added to the script. I’m not complaining, because I didn’t email the author (Dave Child) directly – I had my fix and, as a user, I was happy.

Now, Google has introduced AJAX powered search results, which has broken Numbered Google Results again (along with many other Greasemonkey scripts). AJAX powered search results have been being phased in for a while now, but recently it’s become a lot more common.

There’s also another script, Google Search Results – Numbered, but it starts at 1 on every page. For example, items on the first page of results will be numbered 1 to 10 and items on the second page will also be numbered 1 to 10 (instead of 11 to 20). I didn’t even bother seeing if it worked with the AJAX powered search.

What This Script Offers

Instead, I wrote my own script, which works with the AJAX powered search results, SearchWiki and can number entries appropriately for pages other than the first one.

I didn’t mean to write my own. I started off hacking Numbered Google Results, but I ran into a serious problem I couldn’t resolve, so I started again from scratch. As it happens, I encountered the same problem and my eventual solution could have worked with Numbered Google Results.

My eventual solution will also help many other Greasemonkey scripts for Google Search, so I’ll write up what I did in case it’s useful for others – although I should point out I didn’t actually make it work with the AJAX powered search results, I just worked out how to bypass them and force the use of the traditional search.

This may not work forever, as Google may eventually turn off the traditional search, but such is the life of a Greasemonkey script: when the site changes, the script breaks.

Acknowledgements

As with my first Greasemonkey script, Bing Numbered Search Results, I’ve embedded jQuery. Thanks to John Resig and his team!

I started by hacking the Numbered Google Results script, which obviously helped me write my own. Thanks to Dave Child for a great plugin to start with.

Where Can I Get It

You can find out more about it at the Google Numbered Search Results home page or you can skip straight to Userscripts.org if you want to download it.