top of page

Backward Compatibility: Thoughts on Advanced Custom Fields Pro


Advanced Custom Fields just released their Pro version to Developers

I received an email tonight from the developer(s) of Advanced Custom Fields Pro. If you’ve never heard of Advanced Custom Fields (and the new Pro version), it’s a powerful solution for custom fields and edit screens.

In other words, when you want to collect some extra data in WordPress – on your posts or with Custom Post Types – ACF has often been one of the go-to solutions for developers and end users alike.

In fact, outside of Gravity Forms and Yoast’s SEO plugin, I’m not sure I’ve heard of another plugin recommended to everyone as often.

Understanding Backward Compatibility

I am not one of the folks that recommend it. I stopped using it over a year ago.

But this isn’t exactly a post explaining why I don’t recommend it, or why I don’t think this new Pro version is a great idea.

It’s a post about backwards compatibility.

As you know, I don’t write a lot of negative posts – but I hope this post is actually educational for others building commercial plugins, because it’s always better to learn from the mistakes of others rather than making them on your own.

And in the case of ACF, I feel like they’ve made two common mistakes related to backward compatibility that we could all learn from.

To be clear – the entire notion of backward compatibility is one strongly held and embraced by the WordPress project. In fact, when developers used to working with other platforms first look at the code, they often complain about certain parts of the WordPress core.

But they do so from a perspective that doesn’t embrace backward compatibility and the value we have not only for making sure WordPress is easy to use, but also that older code won’t break when WordPress is updated.

Mistake One: Changing Database Schemas

A couple of years ago I was the architect on a large WordPress-based product platform that produced mobile applications. We used ACF heavily to enhance over 20 custom post types.

Every customer would get their own site spun up in a multisite environment, and we’d clone a “template” site, so that each customer got an entire solution – a custom theme, a ton of post types, lots of ACF customizations, and some Gravity Forms.

It was a powerful solution but what made it really powerful was a custom plugin we created that would pull data from the ACF tables in the database, along with pulling data from the regular WP database, and save it all, in a JSON format, to a physical file on the server.

It made our server-based solution very scalable as it removed database access completely.

But twice during the project we had to re-do our custom plugin, because the scheme (the layout and structure) of the ACF tables changed.

Every time a database changes its structure, a lot of code has to be re-written. It’s the results of breaking changes.

Code that worked on one day no longer worked the next.

Mistake Two: Changing Business Models

With version 5, ACF has fundamentally changed its business model.

They used to give the plugin away for free and charge only for extensions that offered some extra, specialized features. Now, they’ve killed that model.

Instead, the new version, ACF Pro, supports all the extensions in a single new solution. That’s great. Charge for a version that has added features – no problem.

But wait, it’s not backward compatible.

Because ACF 5.0 (non-Pro) doesn’t support the old model of added extensions. It means you need to upgrade to the Pro version. So version 4 users that had paid for an extension now need to use the ACF Pro, not the ACF 5 version.

The issue isn’t about pricing though. It’s about the fact that the ACF 4 upgrade to ACF 5 breaks things. Old features that had worked (extension-based), will no longer work. You’ll be notified that you need to install a new product (Pro) in order for your site to keep working.

Again, code that worked on one day no longer works after you upgrade.

Note: The developer is giving away a Pro version to each person who bought an extension

You might think I’m making a big deal about nothing, since the email I received is offering me a free version of Pro. That’s great. But it doesn’t solve any problems for me.

Because my problems would be related to the X number of client sites I’d have to update – including clients I don’t have a long-term relationship with – just so they don’t think that the code I wrote was bad.

See the developer solved a developer issue. But backward compatibility is a value not just for developers. It’s a value for end users.

And in this case, it’s the end user that will end up with the message saying their site no longer works.

Developers – pay attention to backward compatibility

Like I said, I don’t have this problem. I stopped using ACF a while ago because the first mistake cost me too much time and energy. But this second mistake could have cost me some brand equity.

But like I said, every developer can learn from these dynamics and think about backward compatibility much more. We can make sure that we don’t create “breaking changes” – whether it’s in the code itself or in the business model.

It also means that if you’re not great at thinking about your business model, you should get some help. Products are hard and mistakes like these can be costly.

If you want help on your product, thinking through your roadmap, pricing, go-to-market strategy or more, you know where to find me.

0 views0 comments

Recent Posts

See All

What does it take to scale WooCommerce?

Can you scale WooCommerce? One of the most common questions I hear a lot about WordPress and eCommerce revolves around the notion of WooCommerce and it’s ability to scale. “Can you scale WooCommerce?”

bottom of page