You will need to be able to modify your vhosts file in order to do this, but once done you will have a very flexible and powerful server.

This article is written for 3.0 alpha, as of the current build on 19th March 2010.

Multi sites mode

1. Install Wordpress 3.0 and install as a normal Wordpress.
2. Add define(’WP_ALLOW_MULTISITE’, true); near the top of wp-config.php
3. Log into the admin go to the tools/Nertwork menu.
4. If it asks you to deactivate all plug-ins do so otherwise go straight ahead and set up multi sites as sub-domains and fill in the other details as needed as needed.
5. Make a note of the changes needed to wp-config.php and .htaccess and make the changes.
6. You should now be in multi-site mode.

Adding a new domain

1. Now we’re in multisite mode login as admin go to super admin/sites
2. Add a new site – the address can be anything you like just make it unique and make it something you can remember so we can find it easier in the db.
3. Make sure your domain is pointing at the server if not do so and wait for it to propagate.
4. Add Vhost alias to the root domain. So if in the Vhost file you have ServerName mywordpres3root.com you would add ServerAlias mynewwordpress.com beneath it.  Alternatively, you can use a wildcard here, but in our implementations there are good reasons why we prefer to specify the host aliases.
5. Open up the db for editing and add a new row to wp_site table
   1. site_id, domain and path.
      1. i.      site_id, will be a new unique id, remember it
      2. ii.      domain, should be set to the new domain name added above.
      3. iii.      path should be /
6. Change the row in wp_blogs that matches your new site and make a note of the blog_id.
   1. Change site_id to the new site_id created above.
   2. Change domain to our new domain name.
7. Open up wp_[blog_id]_options table.
   1. Change siteurl to the new domain name.
   2. Change home to match the new domain name.
   3. Change the fileupload_url to match the new domain.
8. Your new site should now be ready, you’ll need to go in and set all the options for the domain now. If you wanted a clone of the root sites options you could copy all the rows in wp_sitemeta with a site_id matching the site you wanted to clone and just change the site_id to the new site.

The instructions above are obviously given without any guarantee – use at your own risk, especially if converting your site from single site to multisites.  If you have any feedback or better approaches then do let us know in the comments below.

WordPress is, frankly, very good – the focus on the user experience helps make it so, even if architecturally it has its limitations.  This has led to stellar success for the platform and is a credit to everyone involved.

A WP distro could have a different logo...

However, over the past year or so there have been a number of controversies – there was the pulling of themes from the WordPress.org repository if there was even a hint of its author profiting from non GPL themes – even if the profiting was just from an affiliate link.  Then there’s the airbrushing out of Edublogs’ and WPMU.org’s links from various official WordPress pages.

This has caused some friction in the WordPress based industry.  Folk just don’t know what’s happening.  In part that could be seen as being a problem caused by differences in business needs and approaches.  Ultimately, Matt Mullenweg is the leader of both the open source WordPress application, and the leader of Automattic.  The latter is a commercial company, funded with a significant amount of venture capital.  It has to make money.  It also funds a lot of WP development, releases a lot of code, and evangelises the product.  But what we do all have to accept is that Automattic’s business needs are not necessarily the same as every other business in the WordPress market.

Automattic are Good for Us

Yes, they are.  All of us running businesses based around WP benefit from their input.  Automattic also benefits when we contribute themes, plugins and so on.

Thing is, it’s not their job to run our business for us.  The relationship between your WordPress business and Automattic is actually pretty loose.  They’re happy for you to run whatever business you like around the product – and if they like you, they may even promote you a little.  Their choice.  If they stop promoting you, then that’s actually just tough.  I whinged about this when it happened a year ago, but after quite a long e-mail exchange with Matt himself, and then even meeting him in person, I started to realise that I had no particular right to expect favours from him or his company. If I wanted promotion from him, I had to make him happy. We changed approach, he promoted us. Simple.

Add Value to Extract Value

In developing an awesome theme or plugin, whether GPL or not, you add some value to the WordPress ecosystem.  Just a little, but it’s there.  But you’ve probably extracted at least as much already.  So don’t pat yourself on the back too hard.

What you need to do is to do things that Automattic won’t or can’t do.  And for that, I’m thinking distributions.  Bundled up, pre-configured editions of WordPress that have all the plugins and configurations that are required for specific purposes.

Some of what we’ve developed is very specific to the News & Media industry.  If we release a suite of plugins to the WordPress.org repository and people download them individually they may not work in a way that would be expected.  Instructions could help, but in effect you’re asking a user to build up their own site.  People don’t want to do that.  It’s complicated and demands a good understanding of the system, the plugins, and the dependent themes.

It’s About Making it Easy

In Linux, there is still something of a perception that it’s a DIY system.  And really, that was the case in the early days – you took the Kernel, added whatever bits you needed, and you were off.  It was basic, a little clunky, but very flexible.  However, most people’s needs are generally fairly similar.  Corporates have one set of needs, people with old machines another, private users another again and so on.

What happened to address this, and where the real value in Linux came, was when other companies started to build businesses around specialist distributions.  RedHat has their distributions, which do well in the corporate and web serving sphere.  Ubuntu is doing fabulously well on the smaller user desktop.

These distributions make life easier for users and clients because they know their needs, and then it’s just a case of finding the nearest match.  Linux is not the answer to their problems – the bundled up solutions are the answer.  You can then issue packages of software designed for those distributions.

It’s About Business

Ultimately, we all need to succeed in order to invest in our businesses and feed ourselves.  We can enjoy coding for pleasure, but you can’t enjoy it if your house is unheated and your children going out in bare feet.  There’s a myth in some sectors of the GPL industry that it’s all about giving stuff away.  It’s not – a lot about the GPL is actually about helping fellow developers to run their businesses.  Coders have shared code freely for years – the GPL is just a formalisation of the developer’s mindset.

How it Could Work With WordPress

With WordPress, there isn’t much money to be made in plugins right now.  Themes have done a little bit better, but they’re a more consumer oriented product which suit certain purposes.  Sometimes the themes bundle plugins to help things along.  Sometimes they don’t.  But the business behind all of these is based purely on supporting the theme.  For everything else, the consumer is on their own.  Worse still, if they use a suite of plugins (premium or otherwise) they may have to deal with various entities in order to get support.  It’s a nightmare for a company where complexity in products is undesirable.

What many companies really just want is simplicity.  Money isn’t necessarily the problem.  They’re running businesses worth millions or even billions.  If a core component of that business (a website, an intranet, whatever) fails or leaves them stranded then they have big big problems.

Create Confidence

So what I believe will come is a marketplace where some companies will offer WordPress distributions suited to particular tasks.  Some will be for heavy marketing, others high-profile bloggers, and so on.  Each will have different minimum server specifications, come with support packages, and will provide a one-stop-shop.  Each plugin will have been tested in that combination, and they will all be supported by the distributor.

Plugin authors will benefit too – a company using a plugin as a core part of their business will gain from keeping that plugin developer happy.  Money will flow (trust me on this!) and when new requirements are identified they will pass this on to the plugin developer, along with the funds to pay for it.

Theme developers will be mixed – the best developers will simply create frameworks, with a base styling, for given purposes.  Designers will then be freed of almost all coding needs and will simply put together a nice child theme.  I anticipate that there will be three or four frameworks coming to the fore, with three or fore distributions offering different variations of framework – all carefully selected for the job.

Costs

These distributions and their support packs won’t be cheap (although for some the downloads could be free).  But they will be dependable.  You will find distributions of WordPress for high security blogs, brochure sites, news sites, membership sites and so on.  No more worrying about plugin interactions, and upgrades will be simpler because all plugins, frameworks and the distribution will upgrade all at the same time.  Your life will become easier.

Impacts

WordPress.org will continue to be the central point for the project, and it will be the reference point.  Distributions will most certainly contribute to the product to help keep their businesses going.  A fork is unlikely happen – not unless the differences in need between the source project and the distributions diverge dramatically.

Companies will be able to base their businesses on distributions which best suit their needs.  If you’re specialising in Intranets, then use the WP Intranet distro.  If you specialise in hardened sites for governments, use the WP Ultra-Secure distro.  This will help companies.

Similarly, if you’re a theme developer, you may wish to actively support distributions that are particularly suited to your style.  And you’ll know what plugins and widgets will be included by default, so you can included styling for those too.

And different distributions will have different cultures and attitudes.  Some will be more favourable to non-GPL publishers, and others much more hardline.  Some will create courses, certifications, books and support infrastructures while others will be more casual.

In the long run, WordPress has great potential as a publishing and communication tool – it does some things so right, so easily, that so long as this principle of simplicity is adhered to then there will be business opportunities surrounding it.  There’s no point getting into arguments with Automattic or Matt – just get on with it and find places to add value.  The risks may be higher, but that will mean the rewards will grow too.  Think about it.

What Do You Think?

Is this likely to be the way forward for WordPress based businesses?  Will it confuse users?  Could it make things better?  Comments, please!

This is a real-life burglar... still easier to identify than a hacker, sadly. Creative Commons Share-Alike Attribution Picture by Jofus.

There’s been a big fuss lately over the latest WordPress hacks that have targetted older versions of WordPress.

And in my view, they show the less pretty side of WordPress and some people in the community… but not all of them.  The attitude has been a straight “upgrade your blog and you’ll be secure.”

Well, I have news for you.  They’re wrong.

You’re Never Secure

Even if you have the very latest version of everything there are, out there, what are known as zero day exploits.  These are vulnerabilities which are kept secret by the hackers who have found them.  They cease to be secret if they become widely used in a large scale attack.  Like the current one against WordPress.

Now, if there are vulnerabilities out there that nobody knows about then your high profile WordPress site or blog could be targetted in a way that you, I, or the (great and lovely) WordPress developers out there don’t know about.

Not Everyone Can Upgrade Immediately

Quite frankly, I find the glib assertion that staying up to date is all you need to be secure to be… terrifying.  It’s bad advice because it leaves people with the feeling that all they need to do is to stay up to date and all is well.  Not only that, but it sidesteps the whole issue that WordPress should really consider running security updates on older versions of WordPress – not all sites can quickly change from one version to another.  When WordPress 2.8 came out it broke multi-use widgets – you could recode them, but then settings could be lost.  There are sites out there that run hundreds of widgets, and re-configuring them will be a big job.  If a new vulnerability comes out in WordPress it may not even be relevant to some sites because they may be doing everything else correctly.

In fact, in a critical environment you absolutely do not update your software without running a full suite of tests to make sure the updates won’t bring down your site.  This is a major problem for sites which, in some cases, are turning over tens of thousands of pounds a month.  Yes, they can throw money at the problem, but it still takes time – and when there’s a vulnerability the one thing you don’t have is a lot of time.  So a site needs to rely on more than just WordPress for security.

How Does That Work Then?

One of the key things about security is to think about what happens when the first line of defence is breached.  In the real physical world, we tend to take multi-part approaches – often based on the risk.  My house has locks on the doors and windows – that’s the first level of security.  But hey, everyone has that, so to make double sure I have an alarm system so that if anyone gets in, an alarm goes off – alerting me if I’m here, or letting neighbours know.

My next level of protection is that of not having much you’d want to steal.  I even used to have a car like that – I didn’t lock it, even, in the hope that somebody would take it out of my life for ever.

But, back to the subject matter… WordPress security is, frankly, just like a front door lock and nothing else.  That’s OK, but you’re not really protecting yourself properly – if someone gets past WordPress then you may have some serious problems.

I’m not going to aim this guide at experts – I’m trying to pitch this to help people who aren’t experts to understand how their WordPress blog can be hacked, and how it can be secured even if a hacker gets through the first layer of protection.

Let’s go through them:

1. Editing of Themes and Plugins Through the Admin Interface

We’re going to do a test.  I want you to log in to your installation, and go to Appearance, then Editor.  Generally, you should see the stylesheet first, with comments at the top.  At the bottom of the box you should see this:

You need to make this file writable before you can save your changes. See the Codex for more information.

If you don’t, and if you can indeed edit this file, then you have a major security flaw right from the start.  A cross site scripting error (XSS) could easily start to make changes to your theme and plugin files.  Once your theme and plugins can be modified, the hacker has complete, 100% control of your server and its database.

2. Poor Passwords

This is really before you even think about WordPress security.  Simply put, do not use a word that can be found on your blog, or in a dictionary.  Learn to use PasswordMaker and its Firefox plugin or similar.  It will make security on various sites much stronger, much more quickly.  If you or any of your users are using dictionary words, then the chances of getting in are far higher.

3. Poor mySQL Server Security

Your mySQL database should be reasonably secure.  But many times I’ve found that you can connect to a database remotely.  For this, try using something like mySQL Administrator and connect to your database using the same logonid and password that WordPress uses.  If you can easily reach your DB from any internet connection then again, you have a potential security hole.  All access of this type should either be IP limited, or over an SSH tunnel.  Setting this up is beyond the scope of this feature but your hosts could help, or we can.

4. Use of FTP Isn’t Terrible, But…

Now, I make no secret that using FTP isn’t generally that bad, but if you have a site that’s likely to be targetted then you shouldn’t have any form of FTP access.  You should be using SSH and SCP.  At the very least, use SFTP if you can sort out certificates – they don’t have to be paid for, expensive certificates, but can be generated.  Again, getting this working is beyond the scope of this, but hosts and good WordPress consultants can help you with making this happen.

5. Allowing User Registration

Sometimes you need or want this – in which case, make damn sure you can keep bang up to date on your WP installs.  But if there isn’t a strong business case for having user registration (and I personally don’t believe there is in 95% of cases) then don’t bother.  If you do have it switched on you’ll notice lots of registrations from around the world.

6. XMLRCP Support

A high proportion of attacks on WordPress have come through or made use of the XMLRPC protocol – this is used by many exploits as it helps to automate the process of posting content to a website.  Mostly the protocol is used for pingbacks and remote publishing to a site.  If you don’t need or want those two features then you can safely remove the file xmlrpc.php from your WordPress’s root folder.  Pingbacks are less useful than they used to be, so it’s not an eccentric thing to get rid of.

7. Firewalls

Putting your server behind an appropriate firewall can help with certain types of attack.  This is something to talk about with your hosts.  And they do cost money.  A lot of things I’m talking about can be done more cheaply, but for a high profile site a firewall is an absolute must.

8. Server Permissions

Apache and the user used to upload files to the server should be kept in separate groups.  This really helps to protect against attacks that get through various layers of protection.  Something could attack your Apache web server and still fail to make updates because it doesn’t have rights.

9. All the Other Code

One thing many folk forget about with WP installations is that it depends on a huge range of code and modules.  Are you running an up to date release of PHP?  How about mySQL?  GDLib?  Apache?  There’s a lot of components to a website – although WP makes it look simple you’re actually dealing with a very sophisticated machine.  If you’re running outdated versions of server software there may be significant non-WP vulnerabilities.  Check with your hosts if possible.

10. Shared Hosting

Some shared hosting plans are, I can confirm without hesitation, absolutely dreadfully configured.  You may have 800 websites on one cheap old server – none particularly active and none set up or configured by experts.  If one gets hacked, the whole machine becomes vulnerable, and every other site can be hacked.  Often when this happens the host will blame you in various ways.  Sometimes the host may simply find it’s all too much trouble and disappear, along with your website.

Don’t let that happen to you.

11. Always Log Out When Finished

If you log out when you finish your work in the back end of your site, you’ll be much less likely to fall victim to a cross site scripting vulnerability.  So make a habit of it.  Alternatively, have a browser that you only use for WordPress.  Some people may choose to use Firefox for general browsing, and Google Chrome for WordPress work.

12. Consider Using Real Hosting

I mean, don’t go for the cheap, commodity hosting that costs £7.95 a month.  Is your online business really that weak that spending on something more serious and carefully managed is a problem?  You have a number of choices.  You could go for a Virtual Private Server or even Dedicated Server from someone like Namesco in the UK, or if your business is really serious talk to the excellent chaps (and our partners when we build big sites) at Kumina in the Netherlands.  There are US equivalents, but I don’t know them, sorry.  By spending more you will generally enjoy a more proactive approach to your site’s security at a server level.  Same goes for spending money on WordPress consultants like, erm, us, to take the worry out of it.  Worth thinking about.

13. Use Google Alerts as a Final Alarm

Google Alerts are incredibly useful for many reasons.  One of the uses I make of it is to have searches set up for my primary sites for words such as ’sex’, ‘phentermine’, ‘viagra’, ‘casino’ and so on.  Then, if anyone gets in and leaves dodgy links on the site then there’s a bigger chance of finding out about it.  If it happens, you’re kind of late, but at least you’re aware of it quickly and have a chance to fix the problem before there’s ranking damage to your site.

Read on for some links to practical tips for securing your WordPress install…

There’s several handy resources out there for you if you want to understand more practical information on improving your site’s security:

Hardening WordPress in the codex – a useful guide, from the people who brought you WordPress.

Hardening WordPress with mod rewrite and htaccess – an alternative and useful approach that’s not for everybody, but works for many.

Noupe’s guide to WordPress security – always useful site has some good ideas.

Richard Scoble on why he doesn’t feel safe with WordPress now.

Discussion about this post over at WPTavern.

A post by Matt Mullenweg about this hack on the WordPress Development Blog – I think the advice could be a little more rounded and pragmatic, personally.  Not everyone can be 100% up to date.  Upgrades need testing, and folk go offline for weeks at a time…

I don’t necessarily recommend all of the linked tips in securing a site, and some are really for experts to deal with, but this is a starting point to understanding.  However, in almost all guides I think they assume that you can’t do much about the security of your web server.  That’s really down to your hosts having a genuine understanding of web security.  Good hosts do, and you can tweak things on bad hosts, but if the host isn’t great you have to look after yourself as much you can – and that, really, means that if you’re managing your own site you have to become a security expert.

Ultimately, if you’re not comfortable in dealing with security issues, let someone else who is skilled and knowledgeable do it for you.  If you’re running a basic blog and don’t really need a custom or distinctive visual design, get an account at WordPress.com.  If you need something more but without the fine control given by custom shops you can have a WordPress VIP account, and if you want real control you can use a company like us who deal with WordPress on a daily basis and who will do the worrying for you.

If you need to view the slide notes (primarily for me, to be honest, but you may see some points that got cut during the presentation) you’ll have to visit the Slideshare site.

Be there to get the latest news and network with the leading lights of WordPress in the UK

Last year we decided to keep quiet at WordCamp UK, on the whole, beyond a spot of sponsorship – simply because we didn’t have that much to talk about that we felt could be exciting.  But a year has changed a lot – WordPress is becoming popular for large scale blogging platforms such as The Telegraph Blogs, and for use as a news platform such as at Telecoms.com.

Large companies are, inherently, going to be a little more conservative in their approach to new technology – but once they see others making a move a cascade effect tends to kick in.  This, we believe, is what is starting to happen with WordPress.

So, because of what is happening, we’re giving two presentations at WordCamp UK this year…

WordPress in the Enterprise

This presentation will cover how WordPress is starting to be seen in the enterprise space, its potential, the pitfalls, and the opportunities available to WordPress developers and designers.  The presentation itself should last around 30-40 minutes, with a further 15 minutes of open discussion and Q&A before clearing the stage in preparation of the next talk.

WordPress in News & Media

WordPress is starting to show signs of adoption within the news industry not just as a blogging platform, but as a full featured news platform.  We will cover the strengths and weaknesses, problems found, what WP lacks out of the box, and demonstrate some of the ways in which a comprehensive news site can be built using our Caribou Theme that we built for Spectacu.la.  We will also be demonstrating the back-end we built for Telecoms.com which allow them to run a far more flexible WP news site than ever anticipated.

Other Reasons to Go to WordCamp UK 2009

1. It’s in Cardiff, capital of Wales.
2. Matt Mullenweg is attending – he’s effectively the lead of the WordPress project and is highly influential in the community.
3. Other notables such as Tony Scott, Peter Westwood, Simon Wheatley, Simon Dickson and Mike Little (who sometimes does some work for us) are presenting – and they always have something interesting to say.
4. You’ll be mixing with some of the coolest and nicest people in the software community.
5. The afterparty is always good fun!

We really look forward to seeing everyone at the WordCamp.  Myself and James Whitehead (our technical lead) will be attending.  If you have anything you’d like to see covered at the event, just comment here.

And, proudly, we’d like to say we had a little bit to do with the project.  Not a lot, mind – we provided some consultancy, some code snippets, advice and developer support now and then.  It’s the kind of project we’d have loved to have taken on in full, but the in-house team at the Telegraph were perfectly capable of doing the work and we always say that if you have the in-house skills then you shouldn’t spend a small fortune on external consultants and developers.

The Telegraph's blogs, running on WordPress MU

The site is a fairly typical MU implementation, but with a few interesting tweaks in the way they’ve configured.  Instead of giving each journalist their own blog, they’ve understood that some simply won’t be that active.  Instead, authors tend towards having a category of their own to work with.  So if you go to Shane Richmond’s blog, for instance, you’re actually seeing the Author Archive view that WordPress provides, within the general Technology Blog.

In fact, the flexibility of WordPress, the way you can output content differently according to category or author, all helped to contribute towards creating a platform that Telegraph Media feel they can grow with.

Challenges

One of the key things to think about with media blogs like this is that traffic can be astonishing.  A lot of questions were asked early on about scalability and performance in WordPress.  Because it’s a purely dynamic system, running more like an application than a group of static files, different approaches have to be taken with caching and performance.  The database server is one key area that always needs consideration – especially when you have to consider 200 concurrent users.

One interesting lesson learned is that with WordPress you have to be exceptionally careful about go-live processes.  Our standard process is to run two installs – one for pre-production and one for live.  There is never a beta running that suddenly finds itself running on a different domain name.

At the Telegraph we know that the way they did it was to run a beta on a subdomain prior to running a search and replace script (not sure if it was one of our own developer’s PHP database search and replace scripts that we use for migrations) and then point the domains right over to it.  That resulted in poor performance initially, even though load testing had confirmed everything to be OK.  Consequently the go-live was held back for a few days, but once WordPress had settled down performance picked up markedly.  The issue appears to be to do with cached variables not resetting on the move.  We’ll document our low-hassle approach to migrating WordPress installs shortly on this site.

The Future

Well, we can’t talk for what will happen at Telegraph Media in the future, but what we do see is increased interest in WordPress as a blogging tool for newspapers.  But beyond that it’s even more interesting – some groups like Informa Telecoms & Media are starting to use WordPress as complete news platforms.  For Informa we built the Telecoms.com site almost entirely from WordPress – this not only led to increased journalistic productivity, but increased traffic and reader engagement.  Seeing the comments section slowly spring to life as readers started to understand its potential has been a real joy to see.

We imagine that it will be magazines and local newspapers that make the first moves to WordPress as a news platform, but when will the first national do it?  We’d like to be there for them if they make the leap!  WordPress is fully capable thanks, in no part, to some of the excellent work in turning WP into what is essentially framework by Donncha O’Caoimh, a WordPress core developer, and others on the WordPress.org team.

If the interest in The Telegraph’s move by such important figures as Kevin Anderson at the Guardian, Simon Dickson (a WordPress friendly rival who specialises in e-Government sites), and others is anything to go by then WordPress is booming in the news sector.  Good!

Because of a small budget, we decided to use a lightly customised version of iThemes iCar theme which fit the purpose just right.  A few plugins and modifications later, and the site was quickly up and running.  We created some suitable graphics, selected some photographs, and with just a day or so’s work turned around the site from basic blog, to professional online presence.

Quickly produced, yet effective.

You know that over-clocking experiment?

We had an interesting failure recently. The server for one of our larger clients, who have their own high-spec dedicated server arranged, went down. We got the alert by text, and swung into action.

Well, more accurately we had called the hosting providers and told them to fix it.

They gave no solid reason or explanation as to why the server had died, but within in an hour things were normal enough.

Or so we thought…

In fact, things in the background weren’t looking so great. The hosting provision is rather off-hand. Off the “here’s a box, now off you go lads!” variety. It came with just an OS and an SSH connection. Nothing, and I mean nothing was installed. No fancy control panels here. No web server even. Or ftp. You were expected to do it yourself. Right down to compiling code.

So really, when they brought the database back up I should have known better. They ran no checks. They simply loaded the service and closed the ticket.

Unfortunately a few days later we started getting support calls from the users:

We can’t see our categories or tags.

Publishing in advance never works.

And then more alarmingly:

One of the blogs has disappeared!

The latter was a worry. It was one of the most important blogs on this MU install. It needed to be restored.

What I found was alarming – any attempt to look at wp_x_options for that blog in the admin panel caused an error. PHP was throwing up errors everywhere. But when I queried the table it looked fine.

In the end it was connecting with mySQL Administrator, a wonderful tool, and trying to do a backup before starting anything technical that revealed the true extent of the troubles. And there it was – it couldn’t backup one table because it was completely corrupt. Do a repair on it and ‘Hey presto!’ fixed.

But that wasn’t the end of it. The other problems still existed. I thought that this rebuild would have been fine, but no. The Administrator app didn’t find anything obvious, and when I looked in the taxonomy tables to see what was wrong all seemed fine – if you did a select on just one table.

But if you ran a join, things fell apart and you received zero rows. This time I decided to run an extended check on the whole database and found that of the 116 tables, five had indexes with link problems. Now, if you don’t know, an index in a database is essentially a linked list – this is a fast way of allowing data to be added without having to shuffle things around too much. Break a link and that index falls apart – especially on joins that need to find everything on a table.

So a repair against all affected tables and we were done.

If you get this kind of weird behaviour, especially after a crash, it can be well worth looking through the tables for problems like this. Do make sure you know what you’re doing, however – mySQL Administrator is a powerful, quick and dangerous tool!

What is it, exactly?

Well, just at this moment, we’re not saying. There’s been hints out there, and it’s not a huge secret, but we’re not ready to make any big announcements just yet. Look out for clues in our forum posts around the place, and in some of our work.

Really I had to post simply to explain why we’ve posted nothing on the blog for over a month. There’s been that internal project, but also some very interesting projects for clients. All of which has conspired to keep us with our noses on the grindstone. Soon we’ll look up and return to normal. Maybe.