Breaking backward compatibility should not be about convenience

A big part of WordPress’ philosophies is embracing backward compatibility. And that commitment, for the most part, largely spills over to plugins and themes extending it. At least it should.

So when I read on the WooCommerce development blog about upcoming changes in 2.7+, I was at first encouraged that they’re embracing an abstraction layer for meta handling. Nice! Then I got to the part where they said they essentially plan to break backward compatibility in a future version for meta handling.

If you do anything with product, customer, orders, and coupons, you will be affected in some way. Even if you do a simple update meta call. This won’t break immediately, but your code will not be future proof. As soon as the schema changes in another update, your code will fail.

Yikes.

There are several good, even necessary reasons to break backward compatibility.  For instance, sometimes a product will force a backward incompatible change because something is being deliberately misused outside of the original intent. That’s not what’s going on here.

Frankly, the WooCommerce team’s decision smacks of convenience more than anything. Supporting backward compatibility is sometimes hard, but rarely impossible. And by choosing to break it, they may be unnecessarily playing with the fire that is user trust.

Won’t somebody please think of the users?

User trust isn’t something you earn and then just get to keep forever. It’s a maintenance relationship. So for WooCommerce – an extremely popular product with immense reach in the WordPress ecosystem – I would consider a backward compatibility break of this magnitude to be borderline irresponsible.

There are likely hundreds, probably even thousands of commercial and custom extensions for WooCommerce. Most, if not all of them, up until 2.7, will have probably relied on its usage of post meta for everything from products and coupons, to customer and order data.

Coming out and saying that at some point you will stop using post meta is completely fine. Coming out and saying that some point you will stop supporting post meta is not.

Use the hooks, Luke

There are more than enough hooks in the Post Meta API to facilitate backward-compatibility for previously-post-meta-now-something else data.

I know for a fact that the Easy Digital Downloads team are using those hooks since moving to a custom schema from post meta. Disclosure: I work for AffiliateWP, a sister product of Easy Digital Downloads.

There’s nothing saying that the WooCommerce team has to encourage use of post meta. Feel free to toss deprecated notices or use _doing_it_wrong()s, but don’t break what used to work before.

It’s easy enough for developers to shift to using the abstraction layers – I for one am looking forward to it – but WooCommerce wasn’t built for me. It was built for the people I (and an army of others) build things for, and it was built using post meta.

By all means, improve your code, but keep in mind: sometimes you gotta dance with the one that brung yuh.

“Chain Links” image by Danny Hope, used under Creative Commons.

Translate Me

In an effort to fully embrace internationalization in the WordPress community, I launched a campaign this morning called Translate Me.

See, I released a new plugin this week, Support Me, which aims to drastically simplify the process of creating – and later removing – temporary user accounts for support purposes.

Support Me is unique in that it is the first of my plugins to leverage the amazing and massive community of translators over at translate.wordpress.org. Language packs are served to Support Me users on-demand, meaning I don’t need to generate and ship translation files with the plugin; I simply internationalize my plugin as usual, then register the text domain in the plugin header and it just works. Amazing.

The concept behind Translate Me is simple: For every locale team that 100 percent translates Support Me, I will use WordPress in that language – where feasible – for an entire day.

Since French (France) was the first team to reach 100 percent completion, I’ve been using WordPress in French all day today. I can definitely tell you it has proven to be a worthy challenge of my familiarity with WordPress admin interfaces, mostly because I don’t speak French!

Bonus points go out to the third-party translators who’ve translated strings for AffiliateWP – the plugin I work on full-time. The French translation appears to be quite complete!

Progress So Far

As of this writing, Support Me has already been 100 percent translated for six locales:

Moar since this was originally posted:

Either way, it looks like I’ll be experiencing a lot of multilingual WordPress in the next few days once I pick up the campaign again on Monday morning. So far the schedule looks like this:

  • Monday: English (UK)
  • Tuesday: German (Formal in the afternoon)
  • Wednesday: Russian
  • Thursday: Italian
  • Friday: Hebrew
  • Monday: Japanese
  • Tuesday: Nepali
  • Wednesday: Your language? 😍

As more languages are completed, I’ll continue to add days. The goal is to promote the idea of community translation and ensure credit is given where it’s due. And to be honest, I’m kind of looking forward to the completion of an RTL language; that should be an interesting day!

Press the Words

With future days’ languages still up for grabs, it’s a great opportunity to start contributing to WordPress through translation.

If you’re a speaker of any language and have previously been hesitant to contribute to WordPress for fear that you don’t know how to code or design or whathaveyou, the Translation team can very likely use your help! With upward of 150 active locales, there’s something for just about everyone. Check it out!

Side note: As of WordPress 4.6, plugins and themes hosted and served from WordPress.org will no longer need to load their respective text domains, more on that on make/core.

Jazz up your WordPress generator tag

A couple of years ago when I was in the throws of the Filters of the Day series, I wrote an example for the get_the_generator_{$type} hook that supplemented WordPress’ default generator tag with the jazz artist that release was named after.

The concept is simple: say you’re running WordPress 4.5.2 on your site. The default generator meta tag would output “WordPress 4.5.2” in your site’s source. This plugin supplements that to instead say “WordPress 4.5.2 to the sounds of Coleman Hawkins”. It matches the jazz artist whether you’re running a major or minor release. If you’re running trunk (like on this site), you’ll get a generic “WordPress X.X to the sounds of jazz” string.

In the years since Filters of the Day, I’ve referenced this particular example several different times in WordCamp and meetup talks, and yesterday, I decided to turn it into a plugin and submit it to WordPress.org: Jazzy Generator Tag.

To see Jazzy Generator Tag in action, it’s active on this site right now, just view the source code. If you’re interested in my other plugins, check out my plugins page, or my profile page on WordPress.org.

Shout out to Dominik Schilling (ocean90) for helping me make this plugin translatable for jazz artists of different genders!

Keep your plugin(s) up to date

If you’ve ever submitted a plugin to the WordPress.org repository, you know that with the ever-growing speed at which the WordPress core team releases new versions, it’s inevitable that plugins will fall behind and out of date.

It’s a fact of life, if only because we don’t necessarily have the time to stay on top of it. We’ve all done it.

But here’s the thing: once a plugin is more than two years out of date, it’s dropped from search results on WordPress.org. To be more specific, it’s dropped from search results on WordPress.org and within the WordPress dashboard.

This last point is key.

I doubt it comes as a great surprise to most plugin developers though, especially since it was announced in Matt Mullenweg’s State of the Word speech three years ago at WCSF 2011.

I just wanted to share with you this morning, a visual representation of what it looks like when one of your plugins hits the 2-years out-of-date mark.

out_of_date_stats

This is a screenshot of the download stats for a plugin I maintain. You’ll notice that average daily downloads is cut almost in half around the December 10th mark. Up until this morning, the last-updated date was December 8, 2012. It’s pretty interesting to see what a difference it makes to have your plugin available in search results.

Do yourself a favor and keep your plugin(s) updated.

Plugin repo bookmarklet

Sometimes when I’m checking out plugins in the WordPress.org repository, I like to view the source before I download. So partly out of boredom and partly out of laziness, I decided to create a bookmarklet that jumps you from a WordPress.org-hosted plugin page to its subversion repository.

The bookmarklet: Plugin Repo

To use the bookmarklet:

  1. Drag the above ‘Plugin Repo’ link to your bookmarks bar
  2. Visit any plugin page (or plugin’s sub-page) in the WordPress.org plugin repository
  3. Click the bookmarklet and you will be sent to that plugin’s SVN repo trunk url
  4. Boom.