allrite

I’ve just got back from a weekend at WordCamp Sydney 2024, an official event dedicated to WordPress and its users. Overshadowing the event was the recent actions by WordPress co-founder and trademark owner Matt Mullenweg. At another recent WordCamp in the United States Mullenweg laid into WPEngine, a popular WordPress hosting service and owner of the popular Advanced Custom Forms (ACF) plugin. The dispute escalated, WPEngine and its users were blocked from accessing the wordpress.org update servers and the ACF plugin was taken over by Automattic, owners of WordPress.com and renamed Secure Custom Forms. Mullenweg also revealed that wordpress.org, the site of the free version of WordPress, and the WordPress trademark were both personally owned by him, not the WordPress Foundation.

Mullenweg’s actions alarmed the WordPress community. Personally, it has come at a bad time when our cybersecurity group are looking into supply chain risks and, make no mistake, this is a business risk. We only have to look at the behaviour of Elon Musk and what has happened to Twitter (now X), to see what damage owners going “rogue” can do to a service.

WordPress is open source and can be forked, as it has been before. What is lost is the central repository of free plugins and themes and the security that comes from that. All plugins and themes are reviewed before they are added to the repository and can be removed if they have security or ownership issues.

That infrastructure and the community around it is difficult to replicate.

Naturally, this has lead to many WordPress users looking for alternatives. But for many it’s not a simple option.

What I gained most from WordCamp was an appreciation of the diversity of uses for WordPress. There is more than one reason that WordPress is the most popular content management system (CMS) on the Internet. These include:

• It’s free. Whilst individual plugins and themes may cost money, there are many free and low cost versions and you can get a free instance of WordPress on the WordPress.com service.
• Easy to setup. Most web hosting services offer a one-click WordPress setup and even the manual installation is easy.
• Multiple sites. Native support for running and managing multiple sites from a single installation.
• The editor. The editor doesn’t require learning markdown, HTML or require filling in endless fields. It’s pretty WYSIWYG. Support for images and other media is included in the system.
• The dashboard. The administration interface is built in and relatively simple to use.
• Updating. Update notifications are pushed to the platform and most updating can be done with a single click in the web interface. So many other tools require command line migrations between versions and break between major versions (I’m looking at you Drupal).
• Plugins. There are plugins for most things you’d want to do and probably a free version out there somewhere. Writing your own plugin is not difficult either (although the new block system has made this harder).
• WooCommerce. Run your online shop with WordPress and WooCommerce.
• Popularity. There is a lot of documentation and many knowledgeable users out there.

There are also features like versioning, integration with other platforms, such as ActivityPub and RSS. I also like that the data structure of WordPress is fairly simple, making migration of content in and out of the platform relatively easy and this is a stated goal of WordPress. You generally don’t have your main content scattered across multiple tables and fields. Unless you use some page builders, which I will get to later.

It’s not all good. Aside from the ownership and control issues discussed at the beginning of this post, WordPress isn’t the fastest or most efficient platform, suffering from the bloat and legacy issues of its long existence. WordPress is also first and foremost a blogging platform. That means that simple blog posts are the core content type of the system, with pages coming second. Custom posts and fields require additional plugins and or custom coding.

In my opinion, one of the biggest problems with WordPress is that site owners try to make the system do too many things that it was not designed for. Many sites would be better off with a custom built platform that supports their unique data and document type needs rather than trying to retrofit them into WordPress with fudges like ACF and page builders.

There are many reasons for this. Firstly, a custom platform requires substantial development and locks you into a supplier for updates and changes, which is a real issue when many of them have a lifespan of only a few years. There is also a lack of expertise. A surprising number of agencies offering WordPress services only have limited coding and development expertise and instead rely on the ACF and page builder plugins to offer customisations that are primarily front-end design in nature.

I use WordPress for personal blogging and at work as a content management system. My blogs have migrated through various incarnations, from a self-built system 25 years ago, through to Drupal, Blogger, a custom Django system and now to WordPress (mainly because I was already using it for work). I expect that one day I will migrate them to another platform, especially as my host isn’t the fastest.

At work I have tried a variety of systems, from handwritten HTML to Zope/Plone and expensive enterprise systems, including Sitecore which we use for our main corporate website. I have written custom a few PHP CMS, and while very fast and flexible, lacked maintainability and support.

I manage around 50 WordPress sites for my employer, including multiple WordPress networks, one of which has over 500 subsites. They were designed to be replacements for static HTML sites, so WordPress’ ability to have a page hierarchy was important, with blog posts substituting for news items. Networks, with the ability to have a separate site for each group to look after the content while centrally managing the plugins and themes is another crucial factor. Most of the sites themselves are not particularly big or complicated.

Our strategy is to use the default WordPress capabilities as much as possible and minimise the number of third-party plugins and themes. Instead, we develop most of the plugins and themes in house to deliver visual elements that are specifically required by branding and accessibility requirements.

This means that our risk from the repository issues fallout is low and, if necessary, we could build a simple system to output the database and filesystem (images, documents) content if we were forced to move away from WordPress. In the long term, the loss of the dashboard and admin interface would present difficulties, along with a reliance on WordPress’ functions.

I have seen several suggestions for static systems to replace WordPress output for both security and speed reasons. I can definitely see use cases for this, but we rely on dynamically generated content for the React components that list posts, pages and data elements. Many users also rely on the WordPress dashboard interface and media library. Hand writing markdown is not always an option.

For my personal blogs, the ability to easily upload and refer to images is a major factor as I am often on a mobile device when I write my travel blog posts. Being able to write these offline in an app is also frequently a necessity.

So far WordPress has worked best out of all the different systems we have tried. It has allowed our researchers to easily communicate with their peers outside the strictures of the enterprise system and for us to quickly and cheaply deploy new websites for special requirements. It works well for my blogs while minimising the time I need to spend managing them.

I won’t claim that WordPress is the best possible system and I think many people misuse it. But it does do a lot of things well enough that it does not deserve the amount of scorn it so often receives. I hope that good sense will prevail at the top. Should they not, it’s always prudent to look for exit strategies and alternatives regardless. I’ll certainly be trialing a few.