WordPress

Description

My first WordPress site was a blog about football that nobody read. I had it set up in February of 2012 on a shared hosting plan that cost $2.99 a month and used a free theme called flavor something — flavored something — I honestly can’t remember the name, but it had a dark background and an orange header, which I thought looked professional. I wrote eleven posts in three months. The most viewed one had fourteen visits, and seven of those were me checking if the formatting was looking right on my phone. The blog died quietly about May, but the WordPress installation lived on for another two years because I forgot to cancel the hosting. By the time I remembered, the site had been defaced by an automated bot that replaced my homepage with an advertisement for a pharmaceutical in Russian. I did not know enough to get angry at the right thing. I blamed the hosting company. I should have blamed myself for not updating WordPress, but also — and I will stand by this — I should partially blame WordPress for being the kind of software that gets exploited the moment you stop paying attention to it.

That was twelve years ago. I have built or maintained somewhere between thirty and forty WordPress sites since then — for myself, for friends, for small businesses, for clients who wanted “something simple” and did not realize that nothing about running a website is simple once you start caring about performance, security, and SEO. WordPress and I have a relationship built on mutual dependency and low grade resentment. I know it too well to love it and too well to leave it.

WordPress was developed by Matt Mullenweg and Mike Little in 2003 as a fork of an existing blogging platform known as b2/cafelog. It was a blogging tool. That is important to remember because everything that WordPress has become — a full content management system, an e-commerce platform, a membership site builder, a learning management system, an application framework — was bolted on to a foundation that was designed to let people publish paragraphs and pictures in reverse chronological order. The original architecture was simple: posts, pages, categories, tags, theme for the front end, dashboard for the back end.

That is the simplicity that made WordPress the winner. It was easier than Drupal, more flexible than Blogger, less expensive than everything else, and it allowed non-technical people to publish content on the internet without learning how to do it in HTML. As of 2011, WordPress was used to power 13 percent of the top 10 million websites. By 2025, that number passed 43 percent. Not 43 percent of blogs. 43 percent of all websites. White House website is WordPress. The New York Times blogs were running on WordPress. Your dentist’s website is almost certainly powered by WordPress. The scale is ridiculous and shows no signs of shrinking.

The plugin ecosystem is both the greatest strength of WordPress and its greatest trap. There are more than 59,000 available free plugins in the official repository. Need a contact form? There are 400 plugins for that. Need SEO tools? Yoast is installed in more than 12 million sites. Need e-commerce? WooCommerce transforms WordPress into a fully-fledged online store and handles billions of dollars in transactions every year. Need a booking system? a forum? a multilingual site? a podcast host? a job board? a real estate listing? a restaurant menu with online ordering? There is a plugin. There is always a plugin. And that is the problem.

Every plugin is code written by someone else, that runs on your server, with full access to your database. Some plugins have professional teams maintaining them with security audits and regular updates. Some plugins were written by one developer in 2017 and have not been touched since. Some plugins have conflicts with other plugins that only happen on Tuesday afternoons when a particular version of PHP processes a particular kind of request.

I once spent a whole weekend trying to debug a site that crashed every time someone submitted a form. The problem was a clash between a caching plugin and a form plugin that both attempted to change the same WordPress hook. Neither plugin was broken separately. Together, they created a white screen of death that the error log described with a stack trace as long as some of my blog posts. I fixed it by disabling the caching plugin, finding another, testing it against every other plugin on the site, and losing forty-eight hours of my life to a problem that should not have existed.

The theme ecosystem is no different. There are thousands of free themes and thousands of premium themes ranging from $30 – $200. The best themes — Astra, GeneratePress, Kadence — are lightweight and well-coded and customizable without touching CSS. The worst themes are bloated bundles of features that load fifteen JavaScript files and eight CSS stylesheets and make a simple five-page business site take six seconds to load. I audited a client’s site in 2023 that was running a popular multipurpose theme — I will not name it, but you would recognize it — and the homepage was making 127 HTTP requests and loading 4.3 megabytes of assets. The site had five pages. Five.

There was no reason for it to be more than a high-resolution photograph and yet here we were, waiting three and a half seconds for a page with a logo, three paragraphs or a contact button. I rebuilt the site on GeneratePress and did it in a weekend. Same content. Same layout. Load time dropped to 1.1 seconds. The client asked me what I changed and I said “everything under the hood”, which was true, but also allowed me to avoid a twenty minute explanation of render-blocking JavaScript.

Gutenberg — the block editor that replaced the classic editor in WordPress 5.0 in December 2018 — is the most divisive change in the history of WordPress, and I say this knowing that WordPress users argue about everything. The classic editor was a simple rich text box. You typed, you formatted using buttons that resembled what Microsoft Word looked like in 2003, you published. It was basic. It was limited. It worked. Gutenberg replaced it with a block-based editor where every piece of content — paragraph, heading, image, list, quote, embed — is a discrete block that can be moved, customized and arranged.

In theory, this allows users more control over the layouts without having to rely on a page builder plugin. In practice, Gutenberg in its first year was buggy, slow and lacked some of the features the classic editor had. The backlash was so strong that the Classic Editor plugin — which brings back the old editor — was installed more than five million times and WordPress officially vowed to support it until at least 2024. They later extended that to “as long as it is needed,” which is corporate speak for “we cannot force people to stop using the old thing if they hate the new thing enough.”

I converted to Gutenberg in 2020, after fighting for a year, and I will admit it has improved substantially. The current version is faster, more stable and truly useful for creating layouts that would have required Elementor or Divi in the past. I’ve built a landing page last month using only Gutenberg blocks — columns, cover images, buttons, spacers — and it looked professional without using any page builder plugin. That is real progress. But Gutenberg’s ambition has become something more than the editor.

The Full Site Editing initiative wants Gutenberg to rule the world — headers, footers, sidebars, template parts, archive layouts — with the whole site turned into a collection of blocks. Some theme developers have taken to this. Others are waiting to see if it stabilizes. I am in the second group. Every time WordPress attempts to do too much too fast, the people maintaining sites pay the price in broken layouts and unexpected behavior after updates.

Security is the conversation that every WordPress site owner has to have eventually, usually after something has gone wrong. WordPress core is not terribly insecure. The team is able to quickly patch vulnerabilities and the automatic update system is able to handle minor releases without interference. The security problems almost always come from plugins and themes — abandoned plugins with known vulnerabilities, premium themes with nulled licenses that contain backdoors, admin accounts with “password123” as the password. Sucuri’s annual reports consistently find that outdated plugins are number one for WordPress site attack vectors.

I have cleaned hacked WordPress installations four times in my career. Each time, the reason was the same: a plugin that had not been updated in more than a year with a known vulnerability that was publicly documented. Each time, the site owner said something like “I did not know I had to update plugins.” And every time, I thought: they shouldn’t have to know. A content management system that needs constant vigilance against its own ecosystem is a content management system with a design problem, not a user problem.

WooCommerce deserves specific mention because it transforms WordPress into something it was never architecturally designed to be — an e-commerce platform dealing with inventory, payments, shipping, taxes, and customer accounts. And, somehow, against all reasonable expectations, it works. WooCommerce is used by around 36 percent of all online stores. I have built 3 WooCommerce shops. The smallest sold handmade jewelry and processed about twenty orders a month. The largest sold industrial supplies and processed three hundred. For the small shop, WooCommerce was perfect — free, flexible and simple enough that the owner could manage it herself after a two-hour training session. For the bigger shop, WooCommerce began to show strain.

Order processing was slow with thousands of products. The checkout page needed seven plugins to manage the specific tax, shipping and payment requirements. Every WooCommerce update had to be tested against every single plugin because one incompatibility could break the checkout flow and cost real money. I eventually migrated that shop to Shopify – not because Shopify was better at any one thing, but because Shopify didn’t require me to babysit a stack of plugins and pray they’d all get along.

The hosting situation is more important with WordPress than with really any other software I have used, and most people learn this too late. WordPress on a $3.99 Shared Hosting Plan will work. It will also be slow, have limitations on PHP memory, be sharing a server with hundreds of other sites, and one traffic spike away from going down. WordPress on a managed host such as Kinsta, WP Engine, or Cloudways will be faster, more secure, automatically backed up, and much more expensive — $30 to $100 a month depending on the plan.

The difference in experience is not marginal. It is transformative. I migrated a client’s site from a $7 shared host to Kinsta and the Time to First Byte went from 1.8 seconds to 0.3 seconds. The client did not understand what Time to First Byte meant but she understood that her website was suddenly fast, and she was willing to pay $35 a month for that feeling. The WordPress community does a terrible job of communicating this. Every “start a WordPress site for $2.99!” advertisement sets people up for a slow frustrating experience that they blame on WordPress and not the underpowered server running it.

I have a complicated relationship with Matt Mullenweg and Automattic, the company behind WordPress.com, Jetpack, WooCommerce and much of the WordPress ecosystem. Mullenweg has been the co-founder of the project and its public face for more than two decades and his leadership has kept WordPress open source, free and dominant. But Automattic’s commercial interests sometimes lead to uncomfortable dynamics — Jetpack, for instance, is an Automattic product that bundles security, performance, and marketing tools into a single plugin that is heavily promoted within the WordPress dashboard. It is useful.

It is also enormous, adds a lot of overhead and creates a dependency on Automattic’s cloud services for features that independent plugins handle just as well with less bloat. And recent disputes in the WordPress community over governance and commercial contributions have made some long-time contributors nervous about the direction of the project. These are inside-baseball concerns that will never be noticed by the vast majority of site owners, but for anyone who has invested years into the WordPress ecosystem, the health of the project’s leadership is important.

Despite all of this — the plugin conflicts, the security maintenance, the debates over Gutenberg, the hosting complexity, the update anxiety — I am still building with WordPress in 2026. Not because it is the best tool for every job. It is not. For a simple blog, Ghost is cleaner. For e-commerce, Shopify is less stressful. For a static portfolio, a simple web site with html or a site such as Squarespace is easier. But for the particular combination of flexibility, cost, community support, extensibility and ownership that WordPress provides, nothing else is competing at the same scale.

I can do almost anything with WordPress. I can hand it over to a client and they can do it themselves. I can move it between hosts. I can customize it to some degree that no closed platform allows. And when something breaks — because something always breaks — there are fourteen years of Stack Overflow answers, YouTube tutorials, blog posts and forum threads waiting to help me fix it.

WordPress is not elegant software. It is a twenty-three-year-old PHP application held together by backward compatibility, community goodwill and an ecosystem of plugins that ranges from brilliant to dangerous. It powers 43 percent of the web not because it’s the best at anything, but because it’s good enough at everything, and because it allows ordinary people to own their corner of the internet, without having to ask permission from a platform that could change its terms tomorrow. That is more important than elegance. It always has.