Lord, you shouldn’t mistreat me, baby, because I’m young and wild,
Shouldn’t mistreat me, baby, because I’m young and wild.
You must always remember, baby, you was once a child.
- RAGGED & DIRTY

It’s been about 65 days since I started this blog, and about 50 days since I moved from hosted WordPress.com to a self-hosted version. Since gaining my freedom, I’ve learned a lot about blogging, WordPress and various tools of the trade. For some reason, I’ve struggled to find resources that list all of the nice tips and tricks out there. The sites I’ve found are generally full of crap. So I figured I might as well brain-dump what I’ve used and learned. I’m sure you all know all of this already, but if nothing else it will help me remember what I’ve done. As usual, I have to thank James as he is the brains behind the operation.

In this post, I’m only going to talk about how it is built – the on-site stuff. In Part II I’ll talk about the off-site pieces – things like Twitter, Directories, SEO and other external tools. And yes, I know I have a blog with hardly any visitors. But at least it is a compliant, SEO friendly blog so that all I can blame for the lack of visitors is my content.

The Theme

I didn’t put too much thought into this, and just looked for one that looked simple and flexible. I picked Atahualpa Theme by BytesForAll which has worked nicely. It has many options and has allowed me to change virtually everything I’ve wanted to without writing any PHP code or changing the .htaccess file. The theme handles favicons properly, which is nice. I notice many many WordPress blogs still have the good old out of the box W icon. It also lets you flip between excerpts and full posts on the listing pages, which I like. Finally, it is really easy to add custom HTML or CSS anywhere. Have done a fair bit of this.

Of course, I wouldn’t pick a theme without ensuring it produces valid XHTML. This one does, and the blog validates using the W3C validator at the time of writing. However, I didn’t validate the CSS when I chose it which was a pity as this is a bit of a disaster. Something to try to fix later.

Key Plugins

I’m not going to go into any detail here as I’ve gone with the mainstream ones. I’m also not going to mention the gimmicky plugins that appear in the sidebar. The ones that provide core functionality are:

• Akismet – saved my ass. At the time of writing, I’ve had 229 real comments and Akismet has blocked 635 spam comments. It’s let 1 spam item through, and blocked 2 that weren’t actually spam.
• All in One SEO Pack – this works well and plays nicely with my theme. See the later section on Google Webmaster Tools.
• Google Analytics for WordPress – of course. Much better than the other WordPress options
• Google XML Sitemaps – you’d be mad not to. It works very well. My sitemap is here: http://jonontech.com/sitemap.xml
• No Self Pings – great if you like cross-linking between your own posts like I do
• Sociable – to allow all the community site features beneath each post. Sadly, no-one seems to click them. And we needed to change the CSS on the theme to make it pretty.

RSS Feeds

Everyone is using FeedBurner, so I joined the party. I have two feeds – one for the postings and one for the comments. The only person who has subscribed to the comments is me. It isn’t linked to on the site yet. The FeedBurner feeds look like this:

First step was trying to decide what URLs to give the feeds. I asked James (he is, after all, on the RSS Advisory board) but I can’t remember what he said, so screwed it up going with /jonontech for the main one and /jonontech/comments for the comments one. Bit lame, really. James can’t remember what he recommended. Anyway, moving on, the feed details should look something like this:

Last step was to kill the horrible http://feeds2.feedburner.com/ FeedBurner domain and use mine. Off we go to the MyBrand page which lets you do just that. I decided to go with feed.jonontech.com as the domain, so I just need to head off to GoDaddy to enter a CNAME (feed CNAME 181d3ce.feedproxy.ghs.google.com) as instructed, and follow the simple instructions. Make sure you only promote your nice new feed URL- in my case, this is http://feed.jonontech.com/jonontech.

We’re not quite done with the feeds yet. As usual, let’s make sure everything validates. Off we go to www.feedvalidator.org. All good as you can see here and here.

OPML Feed

I really like RSS. I read my feeds on the tube (i.e. subway) on the way home as I don’t have internet access there. It’s pretty tedious to add RSS feeds to my shitty iPhone RSS client, but it does do OPML. I decided I’d like to add my entire blogroll in one go. Enter OPML. I found a plugin called Get_OPML which sort of does this. Once you install it, there are two steps. Step 1 works well. You click a button, and it runs off to your blogroll and technorati (you need a technorati API key) to update the RSS field in your blogroll links. Admittedly, if your blogroll is short your could skip this and just enter the RSS feed URLs yourself when you add a blogroll link.

Step 2 sucked a bit. It generates the OPML file from the blogroll. Two problems. Firstly, the query gets ALL links, not just the ones in the blogroll. So all the “About Me” rubbish and more. To avoid this, I hacked the SQL query in the module to only get Blogroll entries. In case anyone wants to do the same, the new query looks like:

SELECT link_id,link_url,link_name,link_rss
FROM wp_links AS l
JOIN wp_term_relationships AS r ON l.link_id = r.object_id
JOIN wp_terms AS t ON t.term_id = r.term_taxonomy_id
WHERE t.name = ‘Blogroll’ ORDER BY link_id ASC

Second problem – the dude that wrote the plugin hard-coded his own feed into the plugin. Lame. Comment it out. And Have a look at my OPML file if you want to add everyone to your RSS readers.

As usual, let’s validate it. At present, the only OPML validator I am aware of is dead, but maybe it’ll come back. I don’t know if my OPML file validates.

Mobile Version

A colleague of mine told me I need to get myself a mobile version, and pointed me at Mofuse. The setup was really painless. Go to their site, create an account and add a mobile site. You’ll need to pick a SiteID so your site becomes available on <SiteID>.mofuse.mobi initially. Enter the link to your RSS feed, and you’re done. You can upload upload a header image, pick some colours and even add pages to your mobile site if you want to. I just did the header and colours and left the rest as it is. That’s it – you’ve got a mobile version which looks something like this:

There are a few other things worth doing. I like everything under one domain, so using their Custom Domain option on the dashboard, I added m.jonontech.com. Then it is back to the Daddy to add a CNAME mapping m -> jonontech.mofuse.mobi. After all this, my GoDaddy Total DNS looks like this (also see the feedburner entry):

But wait, there is more. Fancy a dedicated iPhone version? Mofuse support this too. Just go to the iPhone Settings option on the dashboard and follow the simple instructions. You can see my iPhone version at m.jonontech.com/iphone. They’ll use your HTTP User Agent to make sure you see the right version. But how does WordPress know to send a visitor to the main site to the mobile site. That’s easy too! Mofuse supply a WordPress plugin that does exactly that. Download it, install if (version 0.9o is the one I’m on), and configure it. Screenshot of the configuration is shown:

All done. Cheap and cheerful mobile version.

Google WebMaster Tools

I’m presuming all you bloggers out there are using the Google WebMaster Tools. If not, you’re insane. Add your site, verify, and away you go. Make sure you register your Google sitemap that you created earlier. You can add the Gadgets to your Google Home Page if you use that. Look at all the errors and warnings you get, and try to fix them. I’ve managed to get rid of all of mine now, which the exception of some old Page Not Founds which a new crawl should fix.

One thing I did discover – WordPress out of the box is configured so that it will cause duplicate content errors, which Google doesn’t like at all. This is due to pagination of comments. In order to correct this, siply don’t paginate them. So go to Settings > Discussions, and uncheck this checkbox:

Final Thoughts

That’s all for now, I think. In closing, a couple of questions for those that know what they’re doing. Firstly, I hate links that open in new windows. So all my links use the same window. However, I’ve had a few people complain about this as they say they keep leaving and having to come back to the site. What’s best practice these days? Secondly, I’ve gone with jonontech.com as the canonical URL instead of www.jonontech.com. Is there a good reason to pick one over the other? Finally, I’m not going to put any badges (e.g. This site is valid XYZ) on the site. They’re not as bad as ads, but who needs ‘em. Right?

If anyone knows of some sweet plugins or tips out there, please let me know. You can read about the second 50 days in My Second 50 Days of WordPress – Part II.

Half of the people can be part right all of the time,
Some of the people can be all right part of the time.
But all of the people can’t be right all of the time.
I think Abraham Lincoln said that.
“I’ll let you be in my dreams if I can be in yours,”
I said that.
- TALKIN’ WORLD WAR III BLUES

Is the tail wagging the dog?

A recent posting caused a rather lively conversation. One question I didn’t get around to answering came from Adriaan Bloem, an analyst at CMS Watch:

But just ask yourself this: 1. Do you design the visitor UX, then use a CMS as a tool to build it? Or 2. Do you consider the process of building and maintaining the lifecycle of a site (the actual *managing of the content*) to be as important as the visitor-facing facia of it? If 1., and not 2., the CMS is going to be thrown out together with the site it produces like a pair of badly hurting shoes as soon as the opportunity arises. And it’ll have caused plenty of hurt by then.

Badly hurting shoes?!? Hey buddy, this is my baby you’re talking about. So, in order to answer this, I’m going to first talk a little about what I want from a content management system.

I want it to manage content, and give me a sensible way to get at that content. And I want this to be easy and logical. That’s all. Done. [UPDATE: My attempt to be sarcastic may have failed. I know it isn't that simple and there are a hundred Content Management Features that influence the decision. But those aren't what this post is about. See this comment]

But content management systems these days do more than this. I’m still an old-school fan of decoupled delivery, although most products now also provide delivery capability and a whole boatload of extras. And the infamous RFP matrices I see focus far too much on delivery side issues that are nothing to do with the CMS. So what do I want from the delivery framework? Not much either, really. In some vague order of importance, these are the biggies.

Every <Tag> is sacred

I want full control over the markup generated by the product. Our interface developers (the front end guys) take their HTML/CSS/JavaScript very seriously, and I want to be able to emit their code byte for byte. I’ll accept some things. A <FORM> tag around a .NET page is expected, with a hidden VIEWSTATE input. Adding extra styles to the front end when doing inline editing is okay too. But when viewing the site as a normal user, I don’t want any of those either. I certainly don’t want their JavaScript and CSS stomping all over my JavaScript and CSS.

The “Egg Analogy” presentation below is a Microsoft one, which I first saw when our friends from Redmond popped into our office to demo their Expressions product suite. The first 9 slides really touch a nerve for me. Don’t bother with the propaganda from slide 1o onwards. The slides mirror our development process pretty well, as does the end result if the delivery framework places constraints on the markup. We don’t like breaking the egg.

If it ain’t broke, don’t break it

So, we’ve got our perfect HTML. Let’s make sure the editors can’t break the egg either. This is more a Content Management than Content Delivery issue but, I beg you, don’t let the editorial team play with the HTML directly without ensuring the markup is valid. It isn’t that hard to do. Don’t publish something that isn’t valid, at the very least. Applying some accessibility guidelines doesn’t hurt either. I also need the editors to have full control over the URLs, including multiple “campaign URLs” for the same entry point. Don’t allow illegal characters in these URLs, please. Oh yeah. Tell your Rich Text Editor not to convert relative URLs into absolute ones that point to my staging environment.

Play properly with the interwebs

HTTP status codes exist for a reason. Please can your “Page Not Found” page actually also return a 404, not a 200. Please use 301 and 302 redirects in the right places. Please use proper caching headers when serving static files. And dynamic files too. Did you know that SharePoint serves an “Exires” header (without the ‘p’)? WTF! Form builders need a good excuse not to use XForms.

Developers should dig it

The product should feel natural to them. No proprietary languages. No stupid development tools. No complex installations. Less quirks than average. It needs a logical API and useful templated controls. It should feel like it is an extension of the dev tools they know and love. The in-memory caching and decaching should be invisible to them. And it should be fast.

I want my configuration in configuration files and template code on the file system so it plays with our release management and continuous integration software. I only want content in the content database, so I can back up and restore databases without screwing up code. I want language files in standard places.

I love the products that do less rather than more. Using .NET as an example, your API should do less with each .NET release. Chuck out propriety authentication methods for .NET Membership. Chuck out your clever workflow engine for Windows Workflow. Stand on the shoulders of giants, and let my developers do the things they know already. Focus on the core use cases of a Content Management System.

Don’t try to sell me snake oil

I don’t want a non-techie sales guy telling me things like “Oh yes, our product does SEO really well”, “It also works as a Portal” or “It does an iPhone version” without knowing what it means. I don’t want the system to bloat itself with tightly coupled modules that need to be uninstalled with a scalpel and a bottle of gin. You can keep your Module X that has clearly been hacked together on a client project, produces crap markup, isn’t cross browser, doesn’t have an accessible fallback, and clearly isn’t ready for production. I don’t really want sub-standard features that have been implemented simply to tick a box on an ill-thought-out RFP. On most of my projects, the CMS isn’t the only third party application in the solution. It needs to talk to the others too. I already have products for my Analytics and MVT, thank you very much. If you also do e-Commerce, SoCo or something else, I might consider those as a loosely coupled optional extra. And I really really really don’t want fancy drag-and-drop site building demoware that is completely useless and downright dangerous on a real project.

Rant over. So, to answer Adriaan’s question at last

I believe that any delivery framework that meets the above requirements can be used to create any user experience. In fact, I like the idea that our UX, Creative and even Interface Developers can do their thing without knowing which CMS we’re going to use. So, I’m going to say we do both 1. and 2. at the same time. The front end is designed entirely with the users in mind, without caring about the CMS details. The CMS implementation is completely the opposite. It’s all about modelling the content and making the editors’ day job easier.

In a year or three, the customer may need a complete site refresh and the content and processes shouldn’t need to change unnecessarily. Or, alternatively, the Best CMS Product Ever might be released, and the customer might want to use it instead of the CMS we’ve implemented. They should be able to do this without losing the design, UX and HTML, which is a substantial investment. Or, to paraphrase Adriaan. I want to be able to throw out our CMS like a pair of badly fitting shoes, or throw out our website like a hat that is too tight. But I don’t need to throw them out together.

Finally, I reserve the right to violently disagree with any of the ill-thought-out things I’ve said in the above. Get out those hunting rifles – it is open season on Jon.

You’ve been avoiding the main streets for a long, long while
The truth that I’m seeking is in your missing file
What’s your position, baby, what’s going on?
Why is the light in your eyes nearly gone?
- SOMETHING’S BURNING, BABY

Following on from the wonderfully entertaining “CMS Vendor Meme” (a.k.a. the “CMS Celebrity Deathmatch“), I’d like to drill slightly deeper into Item #9 – Dog Food. For the uninitiated, “Eating your own dogfood” means that the vendor uses their own software to run their own site. All of them do, according to the responses to the Vendor Meme so far, although not always on the very latest version.

So, do the vendors’ sites, written on technology which is sold as fully accessible and built by experts (at least, one hopes the vendor has experts), actually produce markup that validates? I guess the first question one has to ask is does it matter if a site is accessible. And the answer: Oh yes. For many many reasons which I’m not going to go into here. I understand that W3C validation ≠ Accessibility, but that is another discussion for another time too. Validation is still an important part.

XXXHTML by Rob Cottingham

I know that it isn’t always easy to make complex site that validate. Where I work, sites should always validate when they’re launched – it is part of the User Acceptance Criteria. However, we are guilty of back-sliding when sites are in support /maintenance mode, and editors break things when abusing Rich Text Editors. Shock, horror – there are still a lot of CMS products that allow editors to enter broken markup.

WordPress do a pretty good job. This blog validates at the time of writing, no thanks to me. Admittedly, I did have to fix the FeedBurner RSS link which left the closing slash from the img tag, but that wasn’t WordPress’s fault.

I digress. I thought I’d test the home pages of a few major commercial Web CMS vendors – those listed as Enterprise or Upper Tier in the latest CMS Watch Web CMS Report. I tested the vendor home page, which may not be CMS related at all, especially for the big boys. The results are tabulated below. The numbers below were generated on 18 March between 21:00 and 23:00 GMT using the W3C HTML Validator. I didn’t check the CSS or Feeds, just the markup. Both encoding and doctype were left on “Detect Automatically”. I didn’t look into the details of the errors. The ones with a large number of errors might actually only be a few errors that are repeated, or have knock-on effects.

The nice surprise mentioned in the title is IBM. Big Blue really does care about standards, and maybe Java is going to safe place should the SUN deal materialise. Hats off to Fatwire, Day and Percussion who get really close and clearly try to ensure the markup is good. The other 9 out of 13, however, don’t look so promising.

So, what am I saying? I am not for a second implying that the products that do badly in the above are “not accessible”. I just think the question we always see in an CMS Selection RFP is incorrect. Asking about an accessible editing interface (which comes out of the box) makes sense. Asking about an accessible front end (which is different for every implementation) makes no sense at all.

So, instead, the question on the RFP should be “Does your CMS allow the developer full control over the markup. If not, please specify where?” Now, it is highly unlikely that any product can answer an unequivocal “yes” to this. For example, every .NET based product mandates that a FORM tag containing the VIEWSTATE exists. However, this does not cause a problem.

But as we add products into the solution, we hit more restrictions. Portals are notoriosuly bad at giving control. I promised myself I wouldn’t rant about Portals for Public Facing Sites here, so I won’t. Many AJAX libraries (e.g. some JavaServer Faces implementations and ASP.NET AJAX nee ATLAS) give you very little control at all. JavaScript libraries are normally pretty good.

I believe the problem in most of the examples in the table above could be rooted in one of:

• The technology makes valid markup impossible – I think this could probably be worked around in many cases. But sometimes you simply can’t get around the bad markup you’re given.
• Nobody knew it mattered – Ignorance isn’t an excuse any more.
• Someone decided it wasn’t important – this doesn’t need further comment. Give them some concrete shoes and send them for a swim.
• There isn’t time and/or budget to ensure it validates – in some cases it is more expensive to create a validating, progressively enhanced site. However, in many cases I believe it is cheaper to do it properly.
• The front end team lacked the skill - This I can believe. Hopefully this improves with time. Many server side developers aren’t any good at client side work. I know I fall into this camp. When I was coding, CSS didn’t exist, HTML still had TABLES in it and the BLINK tag was cool. I’m not allowed anywhere near the front end code where I work. We have professionals for that.
• Showing off with fancy client side technologies - There are far too many sites that use Flash/AIR/Silverlight for no good reason, without providing an accessible fallback. Now this won’t affect the W3C validation, but it annoys the hell out of me. Use these technologies where they are needed, not for the sake of it.

I’m sure there are other reasons I’ve missed out, and I’d love to hear about them. I believe the responsibility for convincing management of the importance of doing things properly lies with us, the technologists. And if they seem not to care too much about accessibility, play the Increased Revenue cards (SEO, multi-device target market, maintainable code, integration with as yet unknown services, working on IE8 and other future browsers, etc) instead.

And once again, nice one IBM for winning the Home Page test. I apologise for my behaviour in some meetings in the past about the markup from WebSphere Portal. But let’s not get complacent – it would be nice if you could make the deeper pages in the site validate too.

UPDATE: Does anyone have the energy to publish a similar test for the mid-range and Open Source vendors? I might do it in a week or three if no-one else does it first.