Skip to main content

About the Recent WordPress Drama

About the Recent WordPress Drama

As many of you have heard, there is some drama in the WordPress space right now. If you haven’t heard anything yet, consider yourself lucky to have avoided the needless drama so far.

In this post, I’ll cover what is happening, who is impacted, why it’s important, how we are protecting you, and some thoughts for the long term.

Who is impacted:

I’ll cut right to the chase. If you are one of our customers on a Website Management Plan, you are perfectly safe, and there is nothing you need to do. If you are one of our customers who is not on WordPress, then there is also nothing you need to do. You can stop reading and file this email away as “technical babble” that can be safely ignored.

The businesses most affected by this situation are those planning or starting new projects. If you have a WordPress website that is working for you, then there is no reason to change anything. WordPress is not going away anytime soon, and the sky isn’t falling.

What is happening:

Without going into a lot of unnecessary detail, a feud broke out a few weeks ago between the co-founder of WordPress, Matt Mullenweg, and WP Engine, a large hosting platform (note: we do not use WP Engine, although we do use some products that they own and maintain). Mullenweg said he would take a “scorched earth nuclear approach” against WP Engine unless it agreed to pay “a significant percentage of its revenues for a license to the WordPress trademark.” Since then, WordPress has blocked WP Engine customers from being able to update the WordPress platform and the hundreds of thousands of plugins hosted in the repository, and they have blocked anyone affiliated with WP Engine from accessing WordPress.org.

In an engineered move, WordPress then irresponsibly disclosed a bug in the Advanced Custom Fields (ACF) plugin, one of the most widely used plugins for WordPress, which is owned and maintained by WP Engine. Since WP Engine was locked out of the repository and unable to patch the bug, WordPress changed the name of the ACF Plugin to “Secure Custom Fields,” modified code to remove some functionality, fixed the bug they found, and attributed this modified plugin to themselves. To make matters worse, WordPress did this in such a way that the 2+ million users of this plugin were automatically “updated” to this new hijacked plugin instead of the one written and maintained by the original authors.

Here is an article from TechCrunch that goes into more detail.

Why it’s important:

This act, by its very definition, can be considered a supply chain attack instigated by a single man controlling a platform that powers 40% of the internet against 2+ million websites. Needless to say, this has a lot of security professionals concerned—not just because of this incident, but because of the continued escalations and the apparent lack of governance and accountability with the WordPress platform and organization.

What we are doing to protect our customers:

The good news is that none of these actions have impacted our customers in any way. We don’t use  WP Engine hosting, and the websites we manage that run Advanced Custom Fields are using the licensed professional version, which has always received its updates directly from the plugin author. We also, as a general rule, disable WordPress’s automatic update mechanism so we can test and deploy updates in a controlled manner. Additionally, we are heavily involved in the WordPress community, monitoring the situation daily, and updating our processes as necessary.

Long-term considerations: 

Right now, it seems that every few days, Matt Mullenweg and WordPress are taking new actions that nobody ever imagined they would do, and that, in many cases, are against their own best interests. In addition to the security implications, this is also destabilizing the entire WordPress ecosystem. We are seeing plugin and theme vendors pulling their products from the WordPress repository, and several of the most prominent WordPress contributors have left the project altogether.

All of this is forcing businesses to consider whether WordPress is the right platform for them. We have already had large projects put on hold because of these actions by Mullenweg and WordPress, and we are adjusting our recommendations and offerings accordingly. For any projects that are in the planning, design, and early development phases, we’ll be reaching out to discuss these events and whether we need to adjust course.

For several years, we have considered WordPress our “go-to” solution since it was flexible enough to meet the needs of the majority of our clients. This has allowed our development and support resources to specialize in a small subset of tools and technologies. While we did occasionally deliver projects using other platforms and technologies, they were always considered the exception rather than the rule since we knew that providing exceptional service and support would often outweigh the slight technical advantages of one platform over another. Unfortunately, that equation has now changed, and it now makes sense to diversify the platforms we offer, support, and recommend.

Alternative platforms:

WordPress is unmatched when it comes to functionality, community, ease of use, familiarity, development support, and third-party integrations. It’s not even close! In 2024, a report by W3Techs shows that WordPress powers over 43.5% of the websites on the internet, with the next largest (Shopify) coming in at just 4.6%. Once you get past the top 5 platforms, each one has less than 1% of the total market share, and the vast majority power less than 0.1% of the websites they monitor. That isn’t to say that there is anything wrong with other platforms, but it does show how much of a behemoth WordPress is.

Alternatives to WordPress fall into a few different categories but can largely be grouped into two distinct buckets: SaaS platforms, such as Shopify, Wix, Squarespace, and Webflow, or “self-hosted” platforms such as Drupal, Joomla, Craft CMS, Statamic, and others.

SaaS platforms, generally speaking, offer features and conveniences that are simple to implement and use as long as you stay within their parameters. The minute you need to customize something in a way that isn’t offered by that platform, you run into major roadblocks, requiring you to either abandon those requirements or switch platforms. They also often “lock you in” to their proprietary platforms, making it difficult and costly to switch. With the average lifespan of a website being 3-5 years, selecting a SaaS website platform is a big decision. That said, there are many cases where these SaaS platforms are the best choice for a particular project or business.

Because SaaS platforms are sometimes the best choice for certain projects, I’ve long considered adding them to our service offerings, and now I have a good reason to start doing so. I still need to get developers and support teams trained, and nothing is official yet, but we will likely be offering solutions based on Shopify, Wix (Studio), and Webflow.

On the self-hosted front, we have a lot more options, each with its own set of benefits and limitations. The great thing about self-hosted solutions, especially when they are open source, is that they offer a level of customization and flexibility that a SaaS platform just can’t match. Getting your data into and out of these platforms is typically much easier than with a SaaS platform, and you also have the added benefit of knowing that your website is safely under your control and not at the mercy of a third-party service or being mined for data to power the latest AI algorithm.

Unfortunately, that customization and flexibility of a self-hosted system also come with a level of complexity that a commercial SaaS product would never be able to sell to the public. These systems are generally more developer-oriented, and it’s much harder to find off-the-shelf solutions and integrations without having to build them yourself. Because of this, they have the potential to be more costly upfront and take longer to build on than SaaS platforms.

In addition to offering static HTML/CSS/JS sites, which we have done for the last few years on a case-by-case basis, we are exploring several “self-hosted” CMS platforms and website frameworks at the moment. We’ll definitely be reintroducing Drupal back into the product mix since we already have history with it and it’s the most mature and widely used platform of the ones we are considering. Statamic is also very much in consideration for its ease of use, flexibility, friendly pricing, and community support.

In addition to the ones mentioned above, we are also looking to add options for a lightweight, editor-friendly CMS such as Craft CMS or Kirby CMS and a more robust headless platform such as Strapi or Directus.

Conclusion:

As you can imagine, evaluating these platforms and training our team is a monumental effort, and it’s one we don’t take lightly since anything we build will need to be supported for years to come. Because of this, we’ll be spending a lot more time than usual identifying the specific requirements for each project and going through a much more rigorous product selection process than we would otherwise. And, in the end, we may still decide that WordPress is the right answer.

This is a difficult and uncertain time for the web industry, and I appreciate your flexibility and patience as we regroup and work together to find the right path forward for your business.

Recent Posts

  • About the Recent WordPress Drama

    As many of you have heard, there is some drama in the WordPress space right now. If you haven’t heard anything yet, consider yourself lucky to have avoided the needless drama so far. In this post, I’ll cover what is happening, who is impacted, why it’s important, how we are protecting you, and some thoughts […]

  • Using Sass with Pinegrow

    I recently had someone ask whether Pinegrow supports Sass, so I thought I’d do a quick video demonstration. In this demo, I show you how we activate our Sass stylesheet and how we can use a simple Sass variable to change the color of a heading.

  • Pinegrow Countdown: Day 1 – Pinegrow Plays Nice with Others

    A lot of products in the WordPress space have grown in popularity, primarily because of their open and flexible ecosystem that allows 3rd party developers to create add-ons, extensions, and libraries. Pinegrow also has a great plugin API. But I’m going to show you in this video, that in most cases, you don’t even need it.

  • Pinegrow Countdown: Day 2 – Pinegrow is STILL not a Page Builder

    In this video, I’m going to show you why Pinegrow is different from Page Builders so you don’t fall into the trap of trying to use it like something it’s not, only to get frustrated and give up.

  • Pinegrow Countdown: Day 3 – Frameworks in Pinegrow

    Pinegrow has built some fantastic helpers for popular frameworks. In fact, when you start a new project in either Pinegrow Desktop or the Pinegrow WordPress plugin, you’ll be asked which framework you want to choose. If you are already used to using one of the built-in frameworks, the choice will be easy. If not, this little video will hopefully help you understand what the frameworks do and how you should answer those important initial questions.