Summary
Matt Mullenweg has taken the next step in his fight with WP Engine and Silver Lake by forking Advanced Custom Fields into Secure Custom Fields (SCF) to protect its security after WP Engine/Silver Lake’s ban from WordPress.org infrastructure. While emotions are high, this move highlights the importance of maintaining the security and integrity of WordPress’s ecosystem. Forking under the GPL is not unprecedented, and this action reinforces the need for WP Engine/Silver Lake to negotiate in good faith.
Up front, I just want to be clear that I work at Automattic and had previous knowledge that this work was being undertaken and began writing this post before the official launch. If you haven’t yet read the official post, I suggest you do.
My goal with this post is to provide a little bit of insight from my perspective on why this has been done and answer some questions that folks in the community might have. These views are my own and don’t necessarily represent the views of Automattic. I’m not saying that to distance myself from Automattic but just to be clear that these aren’t official positions by them and just my personal musings and thoughts.
A Ban Is In Place
Regardless of whether you agree with the ban on WP Engine / Silver Lake or not, it exists. The result of that ban is that folks affiliated with WPE/SL (employees and contractors, IMO) no longer have access to the infrastructure of WordPress.org. They cannot log in, update, or remove their existing plugins and themes. The ACF team have also provided an alternate way for people and teams using ACF to access ongoing updates.
While this is not the first time a ban has occurred, this is the first time it has happened where the scale of the plugin in question requires a more nuanced approach. For example, as a stop-gap, the WordPress security team recently rolled out an update to patch a vulnerability on behalf of the WPE/SL team. This worked to solve an immediate problem but it does not resolve the issue in the long term.
It goes without saying that yes, this could be fixed if WordPress.org lifted the ban on WPE/SL. However, as I have previously stated, the volume is going to continue to rise and WPE/SL is going to continue to feel the pressure to negotiate in good faith as the levers available to the Project Lead are exercised. WPE/SL has sued Automattic, WordPress.org and Matt Mullenweg, not the other way around.
Introducing Secure Custom Fields
Given that there are currently over 2 million active installs of Advanced Custom Fields and the developers of the plugin do not have access to dotorg to maintain its security, the decision was made to fork ACF.
There are rules on dotorg that govern forking in the Plugin Handbook: “We also don’t accept 100% copies of other people’s work or plugins that duplicate functionality found in WordPress Core. Basically, your plugin should do something new, or in a new way, or solve a specific issue.”
The WordPress security team is also within its rights as described in Point 18 of the Plugin Directory guidelines to assume maintenance going forward.
With Secure Custom Fields, its first launch is implementing a stronger patch on the security vulnerability patched in 6.3.6.1 of the original plugin and creating a divergent, non-commercial pathway for development and distribution. If you are extending ACF and have plugins in the dotorg repo, I highly recommend you test compatibility with SCF.
The new plugin Secure Custom Fields is also now open for contributions as well.
This will be a change for users but hopefully there will be minimal impact to most as at this stage there are no major changes to the core functionality of the plugin, just a lot fewer upsells and links to the ACF website.
Are Other Plugins Going To Have A Similar Experience?
The short answer is yes, but not for the reasons you may be thinking. If your code is in the dotorg repo, it’s under the GPL license and could be forked at any time. A modern recent example is when GiveWP forked Easy Digital Downloads.
Since then both have diverged from each other significantly and solved different and distinct challenges. That is always possible in the world of WordPress. Perhaps the real question being asked is, if I get banned or I end up on the wrong side of the Project Lead, could this happen to me too?
Honestly, I can’t answer that but I doubt what we’re seeing with WPE/SL is something anyone wants to see repeated. In Matt’s post he also calls this out as a “rare and unusual event.” My opinion is that WPE/SL has created the conditions that have put us in this spot, I’m aware others don’t share my position (that’s okay too). I would love it if both sides would get together to negotiate in good faith.
This is a really big deal, right?
Yeah, this is a big deal. If you’re feeling emotions, you are not alone. Fear, anger, frustration, and uncertainty are all reasonable. We’ve not dealt with anything like this in our community. If you’re leading a team or engaged meaningfully in the WordPress ecosystem it’s a lot. Especially if you are personally connected to individuals that are significantly impacted by what’s going on.
Dee and I recorded a special episode of our podcast where we talked about this. It got emotional and was raw for both of us. You’re welcome to have a listen to it and feel free to reach out (here or on social media) if you want to talk more.



Leave a Reply