Blog “Reboot”

Hello – here’s the refreshed blog. I’ve decided to revert to a more typical blog format, after many months of soul searching on the issue. I previously had a layout based on a framework we used at interconnect/it for a couple of clients

But not only have I opted to switch to a blog layout, I’ve decided to use an off-the-shelf theme.  I’m now using Khoi Vinh‘s Basic Maths WordPress theme.

Why?

Well, it’s a lovely theme, for starters.  The typography is pretty good.  The archives page is brilliant (check it out) and should be the standard bearer for all themes archive pages.

But the real question for many, I suspect, is why I’m not using an interconnect/it designed theme.  Well, for starters, interconnect/it hasn’t produced an off-the-shelf theme in years.  It’s just not our business.  So rather than use a product of ours, we’d have to spend good and valuable time on creating a new theme.  And, well, why would we want to do that?

Lots of reasons, actually.  I could have a theme coded at the office that really shows off what we can do.  But the problem with that is that there’s not much need.  My blog is not an important one.  It isn’t about WordPress (most WP related content will be on our company site, not my personal one) and it just doesn’t get much traffic.

I run a business.  Its purpose is to make money, employ five people, and, with a bit of luck, turn a reasonable profit.  Its job is not to service my ego or make me look good.  A really good theme costs the equivalent of around £10k-£20k of chargeable time to design, code, test and implement.

Given that we’re turning work away, I thought “why bother?”  And decided to go shopping for something.

So What’s It Like?

It’s actually quite weird using somebody else’s theme.  I actually tried a few out and here are the things I learned that will hold us in good stead.

Themes don’t do enough to make life easy.

No really, they don’t.  One of interconnect/it’s biggest challenges is making sure that WP is as easy to use for clients as possible.  This means following standards, but it also means using some little tricks that help out – for example, registering and setting plenty of different image sizes, and setting/over-ruling whatever the media settings say.

Migrating WP content really sucks.

There’s a fundamental flaw with the default WP export/import.  If you have inline images, although the importer has the ability to download and attach the image in your new site it won’t change the links.  And if you do a search and replace, and your image sizes have changes, your lost.  Totally – the img tag will point to a file that doesn’t exist.

So what do you do?  Well, usually if I’m moving a site from one server to another, even switching domains, it’s a non-issue.  I have my tools.  But if you’re starting from fresh and working like an end-user would then you have to go through every single damn post in order to fix the images.  Every post with an image in it.  That’ll take a while.

If you’re really geeky, you’ll sort it, but it takes time.  Way too much time.  This kind of stuff needs to be sorted and it’s something we may look into as a contribution to the WP project.

Some Plugins Leave Lots of Crud

The reason for a reboot was that I felt that my site’s DB had been filled up with all sorts of crud.  Lots of plugins create tables, leave options, and so on.  Surplus tables have little impact, but they clutter the place up.  But options, lots and lots of them, do have a minor performance hit, and they add up.

Other plugins leave hooks, don’t deactivate properly and so on.  And over the years, I’d been through an awful lot of plugins.  The site hadn’t been redone since WP 2.0 had been set up on it.  I felt it was getting sluggish.

So… there are beautiful and amazing themes out there, and WP is wonderful, but there are little things that could make life just that bit better.  Better migration tools, a better system of managing images within content and their migration, and a better system for activating themes so that image sizes are better handled.

Is it a lot to ask?  Well, we’ll see what we can do about that!

New Spectacu.la Discussion Updates

My colleague James has been extending the threaded comments plugin that I use(d)* on this site.  It’s available from http://svn.wp-plugins.org/spectacula-threaded-comments/trunk for those of you with SVN clients, and for download and easy installation from WordPress.org and Spectacu.la within a few days.

If you wish to test it out, feel free to comment here…

It adds a quote button for content (try selecting some text here and see what happens!), an extending comment box, so if you like people to write long comments they’ll find it easier, and a quote button for comments.  These features all enhance the WordPress commenting engine and make it easier for your community to engage with you.

A proper release after final testing and updates is due in a few days.

* Still a good plugin that we use extensively – but on this site we designed something custom. Better that way.

WordCamp UK – Great Stuff + a Little Controversy

I went to WordCamp UK 2010 in Manchester… this is my write-up of the event, and its controversies along with my presentations…

I’m just settling in at the office having spent the weekend at WordCamp UK 2010 which was staged in Manchester and is a community event for WordPress users and developers.  I gave two presentations, one about WordPress in Big Media, and another about WordPress in the Enterprise.  These followed on from presentations given at last year’s WordCamp.

The Craic

The second WordCamp UK Logo
Yes, this isn’t the logo actually used, but I prefer this one :o)

I’m going to say now that one of the key elements of a good conference or unconference is the socialising – this is where you meet people, bond with them over beers/food/dancing and form alliances that in the future could prove to be very powerful.  You certainly get to make friends and feel like you’re a part of an actual community, and this happens in a way that you’ll never be able to reproduce with online technology.  As a consequence it’s no surprise that the awesome Thinking Digital conference has been nicknamed Drinking Digital by some wags.

As ever,Tony Scott excelled himself by getting us access to the famous Factory Manchester (FAC251) which also happens to be across the road from a magnificently geeky pub that sells good beers, has various classic 8 bit and 16 bit computers adorning the walls, and classic arcade games on free play.  Awesome.

The Presentations

There was a typically varied range of presentations running across three rooms, along with other folk busy coding up for the WordHack (the fruits of their labours are online).  One particular stream that particularly caught my attention was that of a sequence of involvement from John Adams of the Department for International Development.  He ran a free-form discussion group on testing strategies which was followed by an interesting talk on PHP unit-testing Nikolay Bachiyski of GlotPress fame.  This session showed up some of the lack of structure in general testing of WordPress core code, plugins and themes.  Although the approaches used were probably fine for a publishing platform, they would struggle to gain ISO approval.  In other words, you wouldn’t want to fly on a WordPress powered plane!

Other presentations that I particularly enjoyed were Michael Kimb Jones’s WOW plugins, and Toni Sant’s very underattended Sunday morning slot where he discused the way WP has helped with a range of Maltese websites.

The Controversy

What’s a WordCamp without at least a little controversy?  However, for the attendees of this one, this was a biggie… Jane Wells is Automattic’s Master of Suggestion (seriously, that company has some weird job titles) and she made a suggestion that we shouldn’t have a WordCamp UK, but instead locally organised WordCamps for cities.

There’s a number of issues I have with this:

  1. Everyone in the UK knows that quite quickly WordCamp London would be the big one with all the attention in both media and attendance.  It would quickly dominate – in large helped by the enormous population density of the capital.  A WordCamp UK in London would be fine and popular (also considerably more expensive) but that’s all that’s needed.
  2. Many British cities have intense rivalries whilst we all still stand together as a nation – there are folk in Glasgow who would never attend a WordCamp Edinburgh, but would definitely be more interested in a WordCamp Scotland.  End result?  Cities would have small attendances by and large, and our impressive capacity for indifference for minor events would mean that they’d end up as little more than tiny, cliquey gatherings.  Anyone who’s tried to run GeekUps will understand this problem.
  3. A lot of work, energy and our own money has been spent on building up WordCamp UK.  Is Jane seriously suggesting we should dump that?
  4. What is Jane’s authority on this?  She’s simply an Automattic employee.  We chose WordCamp UK and its structure – it’s ours.  If someone else wants to run a WordCamp UK in the country they’re perfectly entitled and there’s no real reason why we couldn’t have three or four running each year – that would be a huge success.  A highly capitalistic organisation that is just one of thousands of contributors to the project and which plays no part in actually running most WordCamps shouldn’t get so involved.
  5. The UK is also very small – 90% of the population can reach all past WordCamp UKs in less than 3hrs – there is no real problem about accessibility.
  6. None of the UK’s key WordPress community members want to give up WordCamp UK.
  7. Jane admitted only six or seven people had complained to her about the situation, two of which turned out to be in Ireland – which except for a small part isn’t in the UK at all.  She couldn’t confirm whether they were Northern Irish or not, which was actually something of a poor mistake to make in front of 150 or so Brits.
  8. Us Brits are a pretty apathetic bunch at the best of times – actually running a WordCamp in each major city would be surprisingly unlikely to happen – there were only two bids submitted for this year’s event – one in Portsmouth and one in Manchester.
  9. The whole point of the *camp suffix is that it’s all free and easy with no big organisations sticking their oar in.  They are inconsistent and joyful.  They’re fun.  Automattic should keep out.
  10. The WordCamp name is not trademarked, and we’ve been using it in the UK for some time now.  It’s ours!

Of course, there are two sides to each argument.  Here’s some reasons and benefits to splitting up WordCamps in the UK:

  1. If somebody wished to run a WordCamp for their city they may feel that the UK badge is dominating and there’d be little interest as a consequence if it was called WordCamp Bristol, or WordCamp Salford.
  2. A national event called something like WordConf could happen.
  3. Erm…

Thing is – we can’t necessarily win this battle here in Britain.  We don’t control the WordCamp.org website – Matt Mullenweg does (he has the domain registration in his name) so if we fight to keep calling it WordCamp UK there’ll be no ongoing support for the event from Matt and his team if they wish to stop the use of the UK moniker.

Which would mean standing up to them.  Do we want to?  Are we prepared for a fight on this?  What do the likes of Mike Little (co-founder of the WordPress project) and Peter Westwood (a UK based core developer) feel about this?

Interestingly we were told the same thing applies to the likes of WordCamp Ireland which will now face this problem – but I wonder if Matt understands Ireland particularly well (we know Jane doesn’t) and that in that country the dominant WordCamp would quickly become an expensive Dublin event.  You may get one doing well in Cork, but Kilkenny, with a population of just 22,000 and which staged this year’s event, probably wouldn’t be able to sustain an annual WordCamp.

So, Jane has to really allow each country to understand its own social constructs and history and let their own communities choose how they do things.  One or two may complain, but it’s not possible to please everyone.

And we showed off too…

My company Interconnect IT have released, through our Spectacu.la brand, the following plugins which you may find useful:

I couldn’t help using the Discussion plugin to run some live discussion sessions.

And The Thanks

I can’t say thank you enough to the people who make WordCamp UK a success for no personal reward.  Tony Scott leads it up, with Mike Little, Nick Garner, Chi-chi Ekweozor, Simon Dickson and many many more working hard behind the scenes.  Also to Nikolay to letting me play with the fastest 85mm lens I ever saw!  Thank you, you’re wonderful people.

WordPress in the Enterprise Presentation

WordPress in Big Media Presentation

Live Threaded Commenting on WP

At Interconnect IT / Spectacu.la my colleague James has developed a new version of the popular Spectacu.la Threaded Comments plugin.  It’s not yet in release form, but you can grab it from the WordPress.org repository via svn if you know how at http://svn.wp-plugins.org/spectacula-threaded-comments/trunk/

I’m bringing it up here because I’ve decided to trial the plugin out here on my own site.  It was designed to work in conjunction with a webinars project, allowing visitors to have an active discussion, in real time, on a WordPress site.  It can be dropped into almost any theme, and adds nicely to the standard WP comments functionality.

Threaded comments are a powerful way to turn your WordPress site into a mini discussion forum.  Adding live commenting can now turn it into a chatroom full of ajaxey goodness.

Try it out below, if you like….

WordPress Performance, Make it 3x Quicker!

I’d started to notice that my site could often be slow to load – other sites on the same server weren’t suffering the same way, so I wanted to document a simple way in which one can identify performance issues on the site. This is one of them.

A little while ago I reported that my site, since some WordPress upgrades, had started to slow down. I’d wondered whether it was WP becoming increasingly bloated, or some other problem.

Well, it took me a while to get back to the issue (babies and a booming business don’t help!) it’s continued to get worse and worse, until a recent change has improved things… but only marginally, as shown by the Pingdom chart below:

Not looking good…

This is dreadful, really – daily average of 4,000ms responses just aren’t acceptable where, two years ago, I was getting 800ms.

So, now the process starts.  The recent small improvement came after installing our Spectacu.la Advanced Search Plugin, which runs a regular database optimisation to help keep things nippy, but it was still dreadful.

Is it Pluginitis?

My first suspicion is always that of plugins (and sometimes themes, if they’re complex).  In our office we have a term called ‘pluginitis’ which refers to the problem of a site having too many plugins installed, many of which are poorly written.  I hate to say it, but when clients call to ask for a plugin to be installed that we’ve never tested we go through it and, 90% of the time, discover serious performance or security flaws that will cause long-term issues.

And this site here is old – I’ve been running a WP install for four and a half years with nothing more than upgrades and, like an old PC that’s been upgraded too many times, that causes issues with old drivers and code.  Same can apply to WordPress.  So let’s see what we can do to improve things.

First stage is to disable as many plugins as possible so as to isolate the issue.  I’m using a division based approach – ie, I’m going to disable half of my plugins to see what happens.  If I get full performance back, then the problem lies in that half.  I can then reactivate half the plugins and see what happens.  If the performance is still good, the problem is in the other half.  I think you can see where I’m going here.

I’m also going to go for plugins that aren’t written by us. Not because I’m biased (ok, maybe a little) but because I know all of ours are carefully tested for performance – many are run on major sites such as the Telegraphs blogs site.  Speed is of the essence.

I’m also going to skip plugins like Akismet, because anything that’s essentially ‘core’ is usually going to be reasonably performant – at least on a small site like this one.

It’s worth noting that I could easily delve into SQL statements and code efficiency – but that’s only interesting to developers – if you’re simply a WordPress user, performance is interesting but what you can do to find problems is somewhat more limiting.

Plugins being disabled:

Add to feed – a simple plugin, but sometimes simple plugins miss simple tricks.

Headspace2 – I have my suspicions about this plugin as it’s massive. Could be fine, may not be.  Only way definite way to know – measure it.

Search Meter – a nice plugin to see what people are searching for, but is it adding load somewhere?

Social Bookmarks – it shouldn’t cause issues, but you can never be sure.

wp-typography – I love what it does for the typography on the site, but it’s also running a lot of javascript.

First results:

I do use YSlow to test the site, but one of the problems is that it’s hard to get a large enough series of data to be statistically relevant.  It’s good for seeing the extra load (and why I knew the amount of javascript was an issue) but for longer term analysis it’s flawed.

So, we go back to Pingdom and look at the one day chart.  As I type this it’s now an hour since disabling the plugins above – so let’s see what’s happened:

A dramatic improvement!

As you can see, in this afternoon alone there’s been a dramatic improvement – from around 2500ms per visit to 1230ms per visit.  In one single step I’ve halved the load time of the page.

What we don’t know so far is whether that’s because the page got smaller to load or whether it’s down to a reduction in database load – but that’s really for another article.  What this is all about is trying to document how I’m improving the responsiveness of the site in a way which relatively non-technical folk can follow.

What I’ll do in the next feature is to turn off some more plugins to measure the impact they had.  I’ll also be interested to see if the spikeyness of the response times has varied much – are they caused by simple server load, or is there something else at play?

I will then start to switch plugins on again in a structured way in order to measure which was causing the heaviest loads on the site.

Keep watching!

Is WordPress Slowing My Site Down?

I noticed on my pingdom stats recently that this site has been slowing down recently. But why? Is it WordPress? Some plugins? Time for research!

I don’t really look at server response times too much, because generally it’s a bit dull, really.  If our server is really sick then the automatic alerts and text messages from Pingdom tell me to get fixing.

Anyway, tonight I just thought I’d have a look at some graphs.  And hey, there’s a bit of a shock… my own site, this one here, is getting slower.  Here’s the graph:

 

Now, what you’ll notice is that generally everything looked nice and brisk until early August 2009 when there was a marked deterioration in performance.  Then it plodded along just fine until December 2009 when it got worse again.

Is It WordPress Bloat?

I wondered what had happened to cause this – I’m especially shocked that a page load is now so slow.  I haven’t changed the theme in use for at least a year, and the plugins are generally ones I use elsewhere.  So I did a bit of thinking, and then it dawned on me when I found this list of release dates at WordPress.org:

The dates correlate exactly with the worsening performance of this site.

Now, correlation absolutely does not relate to causality.  At upgrade time I usually take a moment to review plugins, upgrade the theme, etc.  It could be that an upgrade or change to one of the many plugins in use here that has caused the slowdown.  I know it’s not traffic to my site – that’s been flat for ages, with only the occasional blip.  The server is a dedicated machine running about fourty sites that we manage, but the load is generally quite consistent and impact on different websites is fairly well managed.

But I’m a speed freak.  I like it when a website zings into view.  I love fast cars.  I love computers that don’t dither.  I love telephones that respond instantly.  So I hate that response times are now below 1s.  That’s not on!

So I’m going to try to find the cause of this slowdown – I’ll be running some experiments on this site, profiling queries, checking the database over and so on.  And I’ll document it all as a way of showing you how we at Interconnect IT do our performance tuning.  Whether I document it here or there I haven’t decided yet – I think it would make a good case study for the site.  We’ll see!  Watch both sites…

note 1 – deactivated Twitme on 03/02/2010

mySQL Database Search & Replace With Serialized PHP [Updated]

Ever needed to migrate a database to a new server or website (especially with WordPress and other PHP applications) and been stuck because when you do a search and replace some of the data seems to get corrupted?

Please note that a newer version of this code is now available from my Interconnect’s site over at https://interconnectit.com/search-and-replace-for-wordpress-databases/ 

Ever needed to migrate a database to a new server or website (especially with WordPress and other PHP applications) and been stuck because when you do a search and replace some of the data seems to get corrupted?

Serialized PHP Arrays Cause Problems

In PHP one of the easiest ways of storing an array in a database is to use the serialize function.  Works a treat, but the downside is that you’re not storing data with a cross platform method.  In many product development environments this would get you a stern talking to, but in the world of web development where deadlines are tight and betas are the norm, this seems to be overlooked somewhat.

So what we have are tables full of data that can’t be easily edited by hand.  For example:

;a:3:{s:5:"title";s:17:"This Week\'s Poll";s:18:"poll_multiplepolls";s:0:"";s:14:"multiple_polls";N;}

Say you had thousands of records like the one above, and the word ‘multiple’ needs to be changed to ‘happy’.  Two bits would change – poll_multiplepolls would now read poll_happypolls and multiple_polls would read happy_polls.  In both cases you would have three characters fewer to deal with.

Fine, you may think, but you can only do the change by hand because where it says s:18:"poll_multiplepolls" it now has to say s:15:"poll_happypolls" – see the difference?  S18 spells out the length of the following string, and it has to be changed to s:15

I’ll say right now, that that was a pain.  For simple arrays I wrote the straightforward PHP Serialization fixer code, which got me out of many a pickle – do the search and replace without worrying, and then run the script.  Fixed about 90% of problems.

Multidimensional Array Problem

Sadly those 10% of problems left were a real pain.  I needed something more robust.  Something more powerful.  And finally today it was a Bank Holiday in the UK – that means no phone calls… I could have a quiet day of coding and concentrate on the best solution to this problem.

What I’ve done is to write a database search and replace utility in PHP that scans through an entire database (so use with care!) which is designed for developers to use on database migrations.  It’s definitely not what you’d call an end-user tool, though I may sanitize it at some point and turn it into an easy to use WordPress plugin.  Thing is – this is dangerous code – sometimes I think it’s better to make it deliberately a bit tricky, don’t you?

It’s not that bad though – if you can manually install WordPress, you can easily configure the database connection settings.

What the code does is to look at the database, analyse the tables, columns and keys, and then starts reading through it.  It will attempt to unserialize any data it finds, and if it succeeds it will modify that data then reserialize it and pop it back in the database where it found it.  If it finds unserialized data it will still carry out the search and replace.

Use in WordPress

In most WordPress migrations you tend to have the primary problem of changing the domain name entries in content, settings and widgets – you simply need to put in the $search_for string the old domain address (including the http if it’s there) as seen on the database, and the new one into $replace_with.  Then put this script onto your server, and run it by visiting it in your browser or inputting the appropriate command line – depending on your server configuration.

Other things you may want to check are for plugins or themes that have made the mistake of storing the full server path to the installation – cFormsII does this, for example.  You will need to find out your old and new server paths and use those, in full, for another iteration of this script.

After less than a second of running, you should have a freshly edited database.  It may take a little longer on slow or share hosting, or if you have a very large database, but on my laptop I can manage around 60,000 items of data per second.

I’ve just used the script to migrate, in its entirety, with content, settings, 87 widgets (yes, really!) and hundreds of images to my localhost server.  It took moments, and the site is perfectly preserved.

Search and Replace Database download.
download file

Search and Replace Database download

BIG WARNING: I take no responsibility for what this code does to your data. Use it at your own risk. Test it. Be careful. OK? Here in the North we might describe the code as being as “Rough as a badger’s arse.” Never felt a badger’s arse, but I’ll take their word for it.