I’ve written a few times about challenges with plugins on WordPress.org. Eleven years ago, as a comparative newcomer to WordPress, I wrote “Draining the swamp,” about a difficulty with an abandoned plugin. Later, I wrote “The Changelog Is A Lie” after a user usurped a plugin, hollowed it out, and replaced it with something else. I never thought we’d be in the situation that we are today, where WordPress.org has undermined the trust in the WordPress.org plugin repository. As they first said in Black Christmas, the call is coming from inside the house.
It’s beyond the scope of this post to fully review the dispute between Matt Mullenweg and WP Engine (see this article in The Verge for a good summary as of October 4). The latest development is that Mullenweg has usurped the free version of Advanced Custom Fields on the WordPress.org repository. The official announcement implies that the ACF team abandoned the plugin. This is inaccurate at best: Mullenweg banned the WP Engine developers from the WordPress.org repository, and blocked WP Engine-hosted sites from accessing it. Under the circumstances, switching the updating mechanism away from WordPress.org was the only responsible course of action available.
It’s a neat trick. You ban a developer from the repository, then announce that you’ve found a security issue, don’t let them release a patch for that issue, and then usurp the plugin because they haven’t fixed the issue. A tweet from WordPress claims justification under Guideline 18 of the plugin guidelines. It’s difficult to see how that guideline justifies this action. The developer hasn’t abandoned the plugin. The security issue wasn’t serious, and it’s been fixed. Put another way, if this is justifiable under Guideline 18, then there is no limiting principle.
If you look at the free version of Advanced Custom Fields on WordPress.org now, you’ll see that it’s called “Secure Custom Fields.” The description when you search for it says that “Secure Custom Fields is a free fork of the Advanced Custom Fields plugin created originally for security updates, but now includes functionality improvements…” The plugin description page itself gives no indication that this has been a WordPress.org plugin for approximately five hours. The changelog for version 6.3.6.2 blandly says the following:
Security – Harden fix in 6.3.6.1 to cover $_REQUEST as well.
Fork – Change name of plugin to Secure Custom Fields.
This is also misleading. The actual change is quite significant. Once you install this update, which will be automatically offered to you from the WordPress admin, your contact with WP Engine/Delicious Brains is broken. You’re now using WordPress.org’s fork, and you don’t have a choice. This is because WordPress.org retained the advanced-custom-fields slug, which allows them to retain all the users and reviews of the original plugin for their “fork.”
This is a profoundly destabilizing action for the WordPress plugin ecosystem. In effect, WordPress.org has seized the plugin of a competitor over that competitor’s objections. This isn’t forking–forking would be releasing a copy of the plugin using the secure-custom-fields slug and inviting uses to switch. There are now two WordPress plugins with the same slug and same purpose: the “genuine” Advanced Custom Fields, available from its own website, and Secure Custom Fields, available on WordPress.org. This situation is ripe for trademark confusion, which is ostensibly why Mullenweg went after WP Engine in the first place. This is a terrible outcome for the average WordPess user.
Now what?
I’ve been critical before of the WordPress.org plugin repository, because it forced developers into an arcane SVN workflow for plugin releases. For my own deployments I use Composer (see Overlaying dependency management); packages from WordPress.org are filtered through the Wpackagist.org platform. We’ve done this for the better part of a decade. Now, for the first time, I’m worried. The ACF usurpation doesn’t immediately affect me because we use the pro version, which isn’t hosted on WordPress.org. However, I don’t get a warm fuzzy feeling when the most important plugin we use is at the center of a very public fight between the owner (?) of WordPress and the owner of the plugin. Do I need to worry about updates to core WordPress that interfere with Advanced Custom Fields Pro? A week ago I would have said that was outlandish. Now? Do I need to go over core updates with a fine-toothed comb?
We run our WordPress environments in such a way that WordPress can’t auto-update. That’s by choice, as a security measure: Apache shouldn’t write to its own document root. If we weren’t doing that, I’d be worried about what kind of updates might be pushed automatically. WordPress has done forced security updates before for critical vulnerabilities. This practice was controversial even before the current dispute. Now, there’s the real possibility that if you’re connected to WordPress.org you don’t really have control over what gets installed. That’s fine for managed hosting, but this isn’t managed hosting. This isn’t WordPress.com. If I’m a business in the WordPress hosting/development space I’m deeply concerned about the viability of my business model.
For those of us on the sidelines, there are medium- and long-term issues to consider. The medium-term issue is how do we obtain our plugins if we have trust issues with WordPress.org? Do we have a fallback plan if our favorite plugin is yanked from the repository or our hosting partner is blocked from it? Is our review process thorough enough to catch these issues?
The long-term issue is whether it’s a good idea to stay on WordPress at all.