The developer release of Advanced Custom Fields PRO two weeks ago caused quite a stir in the WordPress community. It sparked a debate about backward compatibility, business models, and developer entitlement with free plugins. However, for me this debate actually highlighted wider issues around WordPress site development and perhaps more importantly the community.
So in case you didn’t know, Advanced Custom Fields (ACF) is a free plugin that has over 2 million downloads on the WordPress plugin repository. It is one of those tool plugins that almost every site can benefit from, saving a developer coding time and giving a user much larger control of custom data of their WordPress site. It is currently at version 4.3.8 for the free version, which interacts with a number of premium add-on plugins for richer functionality.
Elliot Condon, the Melbourne based developer of ACF, announced the arrival of ACF PRO, which effectively is an improved version of the free version plus the inclusion of the three previous premium add-on plugins. Version 5 of the free version has yet to be released, although it has been available for beta testing on Github since March. This announcement triggered many people to panic over a perceived lack of backward compatibility with version 4 and potential site breakages. This panic had actually already happened on Twitter back in April, and Elliot had taken the feedback criticism on board:
@jaredatch @pat_ramsey @tnorthcutt @BillErickson lets get some suggestions going for best outcome. Prevent update if add-ons detected?
— elliot condon (@elliotcondon) April 22, 2014
So if an install had been upgraded to v5 and there were the premium add-ons present, the plugin would rollback to v4, allowing developers to migrate fully to ACF PRO if they so wished or leave the plugin at v4 – fully functional.
Then came a post from Chris Lema about backward compatibility in plugins, directly aimed at ACF and the move to the new model, that frankly fuelled the ACF panic fire again needlessly. Now Chris is a well respected figure in the WordPress community and of course is entitled to his opinion on these things but certain aspects of the post were unnecessary. The majority of his criticism of ACF came from his bad historical experiences with the plugin, and not directly related to the v5 and PRO. He makes a bold statement that the issue is about how the upgrade breaks things, citing this post from the ACF website. I’m not sure I understand the fuss on that one. Elliott recommends you back up your database. Good advice, WordPress does the same for manual core updates. He then lists changes to registering fields via code but goes on to mention v5 handles compatibility. Ok, great. Some other small amendments but no big breaking changes. Hmmm. The update route from v4 was clearly documented as well.
The biggest issue is the need to purchase PRO, install it and deactivate the free and premium add-ons, if you choose to do so. I appreciate that on a large scale that is time consuming. But it isn’t a necessary step to keep the plugin running or stop it from breaking. One of the most worrying things I have heard repeatedly in the comments and on Twitter is the fear about clients updating the plugin and breaking it. To me the worry should actually be about letting clients update plugins, especially essential tool plugins for a site. As developers we should be in a position to mitigate these risks by doing a number of things:
- Preventing end clients from updating plugins. Would you really feel comfortable letting a client update WooCommerce for example?
- Having support contracts in place with clients to handle the testing and deployment of WordPress core and plugin updates, so the worst case scenario is covered by an invoice.
- Simply, if a client is serious about their website then you should be too. Have staging environments, test things locally, don’t suck it and see.
Unfortunately Lema’s post, the subsequent comments and related posts, displayed a side of the WordPress community I had hoped didn’t exist. The clique. Too quick to take up the pitchforks.
For me, Andrey Savchenko (Rarst) hit the nail on the head in his comment on the Post Status followup piece regarding this furore over backward compatibility:
But the pestering of developer for it is unseemly, mean, and entitled.
I can’t help thinking that the reaction from the community would not be quite the same if it was a different plugin, a different developer.
Of course this is only my perspective on the debate and I generally respect and value the opinions of the authors quoted here. But I believe that, as developers, we need to take more responsibility for our work when using free (or even premium) plugins, and as a community not instantly turn on a developer, who has spent countless hours on a widely used free plugin, when things change.
