WordPress 2.9: From a Developer's Point of View

Yup, WordPress 2.9 is finally out and I’ve seen a lot of people upgrade immediately – sweet thing to do, I did so too and hadn’t had any problems here (I’m not using too much plugins), then I switched over to the 3.0 branch, all good! The semi-square buttons in the admin interface are fixed by the way ;) Anyways, this post is not about my blog, but about something I’m working on locally in the intranet of a company. And here’s a quick reminder: do not upgrade the running instance before you checked everything on a duplicate testing one, especially if a bunch of plugins there are handwritten ;)

A Handwritten WordPress Plugin is a huge set of files, with hundreds of duplicate lines of code and tonnes of commented code. The MVC/MVP models are usually transformed into the AIO (All-In-One) model. The only version control systems used are the “Copy & Paste” and “Undo & Redo”. The Core Upgrade process does not involve reading the changelog, backing up, etc.

Okay this is not a very smart thing to do, but sometimes you just need to, especially when you’re in a hurry (duh!). I’m not going to go in detail about the plugins, because you wouldn’t understand it anyway (no offence, I don’t understand most of it either), but let’s just say that I was using the Post Tags interface that you see in your “Edit Posts” admin interface. The sweet little box where you can type some tags or choose from the most used ones. All I did was copy the HTML contents of that little box onto my page, and it used to work (in 2.7 and 2.8), but as soon as I upgraded to 2.9, bang! It suddenly stopped. The javascript bindings were gone!

I figured out that the bindings were all made in the post.js so I took a look at the diff between 2.8 and 2.9 – completely different. The major change was the jQuery selector from span#ajaxtag to div.ajaxtag (line 99 in post.dev.js) which prevented all the other bindings. A few more ids have changed to include the tax name, and some other minor changes which I didn’t figure out yet. Although what’s the point in figuring it out? Wait until 3.0 is released and rewrite the plugin again, meh!

I did a lot of thinking here. This was not the only interface that broke, and rewriting everything on every core upgrade would be pretty difficult. People talk a lot about WordPress upgrades, plugins compatibility, etc. But most of the time they refer to plugins developed by other people, which sooner or later will get an upgrade. So waiting for a few weeks before launching the core upgrade generally does the job. But what if it’s a completely different page with a completely customized admin interface?

I worked a lot with WordPress metaboxes a few weeks before the upgrade and today I figured out that the best and easiest way of building WordPress admin interfaces would be, that’s right, metaboxing. The standard components used in the edit posts/pages interface (tags, publishing, categories, custom fields, etc) are simple metaboxes. So why copy HTML if you could simply use the predefined ones? And when a change is on its way, you’d sleep tight. Unless of course you’re interacting with the standard components from your customized ones, which involves using certain selectors for ids and classes. In that case you’ll just have to read the changelog, tickets (over 500 for WordPress 2.9) and of course code diffs.

Creating your own custom metaboxes is not as difficult as it is at first sight (yet I still haven’t figured out how to save their positions via AJAX, but I will). You will get the hang of it after your third or fourth metabox ;)

P.S. Have you noticed the new post thumbnails here? They used to be wide images, now they’re h2 text and small thumbnail. I love WordPress shortcodes ;)