The MySQL people have hired a few old DEC and IBM hands who are writing a new engine called Falcon. It’ll be interesting to see how that goes, but it doesn’t do much for me right now.

InnoDB isn’t written by the MySQL people. It’s written by a third party who were subsequently bought by Oracle.

InnoDB doesn’t support TEXT fields, so cannot be used to back Wordpress installations. Which brings me back to bitching about MyISAM :)

I haven’t ever used Wordpress for any serious purpose, so I can’t really comment on your buggy experience, but it seems a bit unfair to group MySQL with WordPress.

According to various posts, the InnoDB engine works just fine and has all the features you say you’re missing.

But it does sound like Wordpress doesn’t quite understand what ‘dot point’ releases are all about.

By tradition, 2.5 -> 2.5.1 should be just bug fixes, not major new features like a “new interface”.

Cloning tool? IANA MySQL Admin, but this works for me rather well.

mysqldump databasename -u username -h hostname -ppassword –add-drop-table –compatible=mysql323 > database.backup
mysql backupdatabasename -u username -h backuphostname -ppassword < database.backup

Wordpress relies on another dogpile piece of software, MySQL, using MySQL’s preposterously poor MyISAM engine. Which doesn’t have transactions. Or referential integrity. Or indeed anything that separates databases from flatfiles.

So I’m nervous about running two copies off a single database. I might see if there’s a cloning tool though, that could be a way forward.

I tried looking around for their source repository to see if it was even plausible for others to generate patches themselves, but couldn’t find one. Is it not publicly available?

I imagine the test would have to involve ‘replaying’ a bunch of traffic. There are tools around for capturing traffic so it can be replayed. Then you’d need to write tests to compare the befores and afters, and so on.

Ooooooon the other hand, perhaps the Wordpress.org crew could try unit testing their own code. Which they don’t, at the moment. Or fixing old bugs. Which they don’t, at the moment. Or backporting security fixes so I don’t need to stress about this kind of rubbish. Which they don’t, at the moment.

But it’s a giant pain in the arse to do. I gave up on doing it because I find it easier to just deploy and fix things if they crop up; like Microsoft does :- )

I’m not keen to do a standalone installation as TinyMCE is fairly closely wired into the standard Wordpress install. Wordpress is hassle enough already.

That’s why, for a few weeks, everyone was getting a dozen copies of Missing Link. So now instead the code is wired into the ‘private_to_public’ hook. The new interface makes it harder to do this. It used to be that pressing ‘publish’ turned off private status; now you have to click a tickbox as well.

Ken is, quite naturally, ropable.

Plus, for bonus fun, a migration test wouldn’t have revealed this behaviour in advance.

I made sure to say that going in so I don’t come across as a complete arsehole. But really, you’ve not got a second copy of CT running somewhere to do migration tests on?