Table of contents of the article:
The recent WordPress vs WP Engine Conflict has captured the attention of the WordPress development community globally. At the center of the controversy is the plugin Advanced Custom Fields (ACF), a fundamental tool for customizing WordPress edit pages. This post will examine the details of the story, analyzing the context, the motivations behind WordPress's action, and the broader implications for the WordPress developer and user community.
The Birth of the WordPress vs WP Engine Conflict
The controversy arose in the context of a legal dispute between Matt Mullenweg, the founder of WordPress and CEO of Automattic, and WP Engine, a major WordPress hosting provider. The heart of the dispute appears to revolve around a series of mutual lawsuits, accusations of confusing branding, and claims of rights to the “WordPress” trademark.
Matt Mullenweg publicly criticized WP Engine in a blog post, calling the company “a cancer on WordPress.” Among the criticisms leveled were a lack of support for revision history and a management that Mullenweg said could confuse users into thinking WP Engine was officially affiliated with WordPress.
A key aspect of the dispute was Mullenweg’s threat to take legal action if WP Engine did not pay for a license to use the WordPress trademark. WP Engine, in turn, responded with cease-and-desist letters of its own, further escalating the tension between the parties.
The Advanced Custom Fields Fork and the Birth of Secure Custom Fields
At the heart of this dispute is the plugin Advanced Custom Fields (ACF), a foundational extension to the WordPress ecosystem that has had a huge impact on developers’ ability to customize the platform. ACF was developed by Elliot Condon and first launched in 2011 as a tool to extend the flexibility of WordPress by allowing developers to add custom fields to WordPress edit pages. This transformed the way users and developers manage content within WordPress, giving them a much greater level of control over the data and information displayed on their sites.
What is ACF and Why is it Important?
ACF stands out for its ease of use and its ability to significantly extend the native functionality of WordPress, allowing developers to easily create custom fields for post types, pages, and taxonomies. Before ACF, WordPress already supported “custom fields” natively, but the interface and available functions were limited and not particularly intuitive for most users. ACF filled this gap, providing a more robust and user-friendly solution, making it easy to add fields such as:
- Text
- Textarea
- Images
- Fillet
- Date selectors
- Dropdown
- Repeater fields
These custom fields can be used anywhere on the site, from the backend to the user interface. The adoption of ACF has allowed WordPress website owners, developers, and designers to build highly customized solutions without having to write complex code. This has made ACF a key tool for digital agencies, freelancers, and development companies that need flexibility and customization without having to reinvent the wheel.
ACF Success and the Role of WP Engine
Over the years, ACF has seen exponential growth and has attracted a devoted community of developers and users. The ease with which it allows to customize WordPress has made it one of the most used and loved plugins, so much so that it has led to the birth of a “Pro” version, with additional features such as repeater fields and advanced image galleries. The importance of ACF for developers cannot be understated, as it has opened up new possibilities for development and design for complex websites, including advanced e-commerce solutions, content portals and data management platforms.
In 2022, WP Engine acquired ACF along with other popular plugins, such as WP Migrate e WP OffloadMedia, bringing with it its expertise in premium WordPress hosting. The acquisition marked an important strategic move for WP Engine, which solidified its position as a leader not only in hosting, but also in managing plugins that are essential to the WordPress ecosystem. However, it also brought a new dimension to the conflict between WP Engine and WordPress, fueled by concerns about commercial competition.
WordPress Intervention: Creating Secure Custom Fields
As legal tensions between Matt Mullenweg and WP Engine worsen, WordPress has decided to take direct action on ACF, a move that has surprised many in the community. Mullenweg announced the creation of a fork of the ACF plugin, called Secure Custom Fields, justifying the action as a necessary step to remove commercial references from the plugin and fix alleged security issues. Although no precise details were provided on the security issues identified, Mullenweg referred to “Point 18” of the WordPress Plugin Repository Guidelines, which grants WordPress.org the power to remove or modify a plugin without the developer’s consent if there are security or public interest concerns.
According to Mullenweg, WP Engine was using ACF as an opportunity to promote additional sales, which was in contrast to WordPress's principles, which favor a less commercial approach. Although the security reasons were not clearly stated, it is clear that WordPress wanted to limit the commercial influence that WP Engine was exerting through the plugin. This intervention then led to the birth of Secure Custom Fields, an alternative version of the plugin, managed directly by WordPress and without commercial purposes.
Below is the translation of the Official statement from Matt Mullenweg :
On behalf of the WordPress Security Team, I am announcing that we are invoking point 18 of the Plugin Directory Guidelines and forking Advanced Custom Fields (ACF) into a new plugin, Secure Custom Fields (SCF). SCF has been updated to remove commercial promotions and fix a security issue.
On October 3, the ACF team announced that ACF plugin updates will be available directly from their website. This was also communicated via a support notice in the WordPress.org forums on October 5. Sites that have followed the ACF team’s instructions on “How to Update ACF” will continue to receive updates directly from WP Engine. On October 1, 2024, WP Engine also implemented its own solution for plugin and theme updates and installations on its customers’ sites, replacing the WordPress.org update service.
Sites that continue to use the WordPress.org update service and have not chosen to switch to ACF updates from WP Engine can click to update and switch to Secure Custom Fields. In cases where sites have enabled automatic plugin updates through WordPress.org, this update process will automatically switch them from Advanced Custom Fields to Secure Custom Fields.
This update is as minimal as possible to fix the security issue. From now on, Secure Custom Fields will be a non-commercial plugin, and if any developers would like to participate in its maintenance and improvement, they are welcome to contact us.
Similar situations have happened in the past, but not on this scale. This is a rare and unusual situation caused by WP Engine's legal attacks, and we do not expect it to happen with other plugins.
WP Engine has posted instructions on how to use their version of Advanced Custom Fields that uses their update server, so you do have that option, although the WordPress Security team doesn’t recommend it until the security issues are fixed. You can uninstall Advanced Custom Fields and enable Secure Custom Fields from the plugin directory without any issues.
There is also some separate, but not directly related, news: Jason Bahl has left WP Engine to work with Automattic and will make WPGraphQL a canonical community plugin. We expect others to follow suit.
WP Engine's Reaction
WP Engine was quick to respond to this decision. The ACF team took to social media to express their displeasure, claiming that WordPress had “forcibly and unilaterally” taken control of the plugin without their consent, something they said had never happened in WordPress’s 21-year history.
This statement has sparked mixed reactions within the WordPress community, with some developers questioning the legitimacy of WordPress’s action, while others have argued that given the open source nature of the platform, WordPress was within its rights to make this decision for the sake of public safety.
Here is also the Italian translation of the WP Engine press release and specifically from the Advanced Custom Fields team:
We are deeply saddened and shocked by the actions of Matt Mullenweg this morning, who appropriated the Advanced Custom Fields plugin, which our ACF team has been actively developing for the WordPress community since 2011.
Advanced Custom Fields is a sophisticated plugin with over 200.000 lines of code that we continue to develop, improve, support and invest in to meet the needs of our WordPress users. In the last two years, since we joined WP Engine, we have released over 15 updates and added significant features to the free plugin, while constantly improving performance and our security and testing practices to ensure an “enterprise” level that our users deserve.
The change in our published distribution, and under our “slug” that uniquely identifies the ACF plugin and the code our users rely on in the WordPress.org repository, is inconsistent with the values and principles of open source. The change made by Mullenweg is being maliciously used to update millions of existing ACF installations with unapproved and untrusted code from the Advanced Custom Fields team.
We are able to directly protect WP Engine, Flywheel hosting and ACF PRO customers: you are not impacted and do not need to take any action. You will continue to receive the latest innovations and updates from the experts at the ACF team. The ACF code on wordpress.org is no longer controlled by the ACF team.
If you have a site hosted elsewhere using the free version of ACF, to get genuine ACF updates you will need to do a one-time download of version 6.3.8 via advancedcustomfields.com to stay safe in the future. After this one-time download, you will be able to update as usual via your WordPress admin panel.
You can follow the same process if your site has already been updated to the modified “Secure Custom Fields” plugin, to revert to a genuine version of ACF.
Mullenweg’s actions are extremely concerning and pose a grave risk of disrupting and irreparably damaging the entire WordPress ecosystem. His attempt to unilaterally take control of this open platform, which we and many other plugin developers and contributors have relied upon in the spirit of sharing plugins for all, provides further evidence of his serious breach of trust, numerous conflicts of interest, and violation of his promises of openness and integrity within the community.
The Impact for ACF Users
One of the most controversial aspects of this story is how users of the ACF plugin will be impacted. With WordPress taking control of ACF and creating Secure Custom Fields, users will have to choose between two versions of the plugin: the original, maintained by WP Engine, and the new forked version maintained by WordPress.
For free ACF users, WP Engine has released a workaround that allows you to manually download the latest version of the original plugin (6.3.8) from the ACF website. However, Pro users will continue to receive updates directly from WP Engine, potentially creating a divide between free and paid users.
Implications for the WordPress Community
This event has sparked a major debate in the WordPress community on several topics, including plugin governance, the role of commercial developers, and user protection. One of the most discussed aspects is whether WordPress should have the power to make unilateral decisions regarding third-party plugins, especially when it comes to commercial developers like WP Engine.
On the one hand, WordPress’s action can be seen as a necessary move to protect users from potential security vulnerabilities and to preserve the platform’s open source philosophy. In this sense, the elimination of additional sales within a free plugin can be interpreted as an attempt to ensure a consistent and transparent user experience, free from commercial pressures that could distort the free and collaborative approach on which WordPress was built. The decision to create a fork of ACF under the name “Secure Custom Fields” could be justified, according to WordPress, by the need to provide a secure plugin, without commercial ties, that can be managed and maintained by the community.
On the other hand, many developers see this action as unmotivated and politically motivated. The perception is that it is an attempt to boycott WP Engine, especially after the conflict regarding the request for an 8% royalty of the turnover as payment for continuing to maintain the ACF plugin within the official WordPress repository. This event raises concerns not only for WP Engine, but also for the entire developer community. Many wonder if this type of intervention by WordPress could set a precedent for future cases of interference, especially when plugins or developers with commercial interests are involved.
The main concern among critics of this move is that WordPress could begin to exert excessive control over how plugins are managed, distributed, and marketed within the platform. While security protections and adherence to open source principles are key, there are concerns that developers’ freedom to innovate, monetize, and distribute their products could be compromised. The community wonders whether such interventions could turn into a form of centralized control, undermining the independence on which WordPress has built its reputation. If WordPress can intervene unilaterally in a case like ACF, it could do so again, introducing uncertainty for developers who base their work on this platform.
Conclusions
The dispute between WordPress and WP Engine over ACF represents a watershed moment for the entire WordPress ecosystem, with implications that go far beyond the management of a single plugin. WordPress’s decision to force a fork of the ACF plugin, creating Secure Custom Fields, raises a number of fundamental questions related to platform governance, security, and developer rights. However, the scope of this action must also be considered in light of the potential consequences for other commercial actors operating within the WordPress ecosystem.
WP Engine is not just a plugin developer, but a real Big Player in the WordPress hosting industry, with a prominent position that may have attracted the attention of Automattic due to its growing influence and legal controversies. This takeover of the ACF plugin by WordPress could set a precedent for similar situations in the future, and other commercial players could be left in a vulnerable position if they were to come into conflict with WordPress or Automattic.
Take, for example, commercially significant plugins like WP Rocket, a widely used cache optimization plugin, or Elementor, the popular page builder that has built an entire ecosystem of products and services around WordPress. Elementor itself offers a hosting solution called Elementor Hosting, which could be perceived as a potential competitor to Automattic’s hosting services, such as WordPress.com, WP VIP, and Pressable, a lesser-known but still strategic part of Automattic’s hosting portfolio.
If WordPress decides to apply the same treatment it has given WP Engine to other companies, it could lead to a situation where Automattic and WordPress.org use their power to take action against commercial plugins and services that are perceived as competitive threats. Elementor itself could be seen as a direct competitor to Automattic’s built-in WordPress page builders and hosting services. The same goes for WP Rocket, which could one day face a similar “forking” or other actions that limit its commercial potential.
The biggest problem is that this type of unilateral action risks discouraging innovation and creating a culture of uncertainty among plugin developers and companies that build services around the WordPress ecosystem. The perception that WordPress can take control of successful projects without developer consent calls into question the trust of those who have helped make the platform so versatile and popular to date. If these decisions were applied more broadly, they could destabilize the WordPress ecosystem, leading to conflict between the open source community and companies that build their businesses on the platform.
It is therefore essential that the WordPress community carefully reflects on these developments. This is not only about protecting the platform and its users from potential security issues, but also about preserving the principles of open source, where collaboration and innovation should be supported without the risk of commercial interference. If WordPress governance becomes too centralized, it could create an environment where only Automattic-affiliated actors are free to operate without concern, limiting the freedom of innovation for other developers and companies.
We will wait for the next few months to understand how damaging this action has been for the entire WordPress ecosystem and community, without forgetting to follow the legal case between WP Engine and Automattic, in light of what appears to all intents and purposes to be an extortion attempt by Automattic against WP Engine.
