I have a working analogy for WordPress plugins. They are like dogs at a boarding kennel. In a perfect world they all play nice together, but you really never know what you are going to get until they are in the same room. Some sniff each other and lie down. Some growl. Some are technically house-trained but still mark territory. You do not find out which is which until you have already paid and dropped them off.
This piece is about how I got to that analogy. It is a 15-year arc that starts with Drupal, runs through the WordPress premium-plugin gold rush, and lands in a 2026 reality where the trade-off that made WordPress worth recommending for a decade has quietly stopped making sense for most builds I take on.
The core argument, up front: WordPress is open source on paper. The WordPress you actually ship - ACF Pro, LearnDash, MemberPress, BuddyBoss, The Events Calendar Pro, all the pieces that make a real site possible - mostly is not. That is not a small footnote. That is the whole product.
Where I started: Drupal in the late 2000s
I came up on Drupal around 2009. I had a back-end developer on the other side of the table who handled the deep stuff, but the front of the experience - what made Drupal click for me - was that the things you actually need to build a real website were already in the box.
Content types were native. Custom fields were native. The Views module, which became core in Drupal 8, let me query and display content without writing SQL, with a UI that taught me CMS architecture as I used it. I learned what a content model was by clicking through Views. I am not sure I could have learned it any other way without a computer science background.
Themes were a different story. This was the Artisteer era. Artisteer was a desktop app that let you visually design a theme and export it for WordPress, Joomla, or Drupal. It produced bloated, awful code that no developer would willingly maintain, and it was incredible for someone like me at the time. It was the spiritual ancestor of the WordPress page builder - same vibe, same trade-off, same role in a learning curve.
What open source actually looked like in that ecosystem
Here is the part that matters for the rest of the post. In the Drupal world I worked in, even the premium modules were open in spirit. You could buy a paid extension and the code was not obfuscated. You could read it. You could fork it. You could extend it if your use case was 80% there and you needed the last 20%. The community ethos was: this is advanced code for a specific use case, we are charging for the work, but we are not locking the box.
That was not true of every single module on every single site. But it was the norm. Open source on paper matched open source in practice, even at the premium tier.
The switch to WordPress, and what I gained
When I moved to WordPress, I lost some things and gained others. The thing I missed immediately was the native content modeling. WordPress in that era was still primarily a blogging engine that had grown into a CMS. Custom post types did not land until WordPress 3.0 in 2010, and the native field UI for them was, and largely still is, rough. The thing that filled the gap was Advanced Custom Fields, released as a free plugin in 2011 by Elliot Condon. ACF Pro followed in 2014. For about a decade, ACF was the answer to the question of how to build a real content-modeled site on WordPress without writing your own admin UI.
WordPress 6.5 in 2024 introduced block bindings, which is the first time core has had a native answer to the ACF problem. It is a real step. It also took 14 years to arrive.
What I gained on WordPress was an ecosystem. Themes I could actually launch with. A plugin marketplace that solved a thousand problems out of the box. A client base that already knew the editor. That last one is not a small thing. The cost of training a non-technical client on Drupal admin in 2012 was high enough that it shaped which platform I quoted on every proposal.
The premium plugin gold rush
The early-to-mid 2010s was a wild time on the WordPress plugin marketplace. CodeCanyon launched in 2009 and for several years the market ran on a lifetime-license model. Pay once, own forever, get updates. ACF Pro was lifetime for years. The Events Calendar had a lifetime deal. LearnDash was in its first incarnation as the affordable LMS for WordPress, undercutting platforms that wanted to charge per-student. MemberPress, BuddyPress, BuddyBoss, WPMU DEV - the entire premium-feature category was a land grab, and the prices reflected it.
And the value was real. In 2014, if you wanted to build a membership site or a course platform or a community on the web, your options were: write it yourself, pay a SaaS that did not quite fit, or buy a WordPress premium plugin for $200 and have something running by the weekend. The plugin won that fight on price and time-to-launch every single time. There was no mature Kajabi yet. There was no Skool. The premium WordPress plugin was the answer, and for the kind of small operator who needed an LMS for their coaching business, it was a legitimately great answer.
The trade-off that worked for a decade
Here was the deal. You would pay $99 to $299, or a lifetime deal at $199, for a premium plugin. In exchange, you got:
- A working feature in days, not months
- An active developer maintaining it
- A support forum where someone would answer in a few hours
- An ecosystem of add-ons and integrations
What you gave up was the part that nobody talked about in 2014. The plugin code was usually obfuscated, or at minimum structured in a way that was not meant to be read or extended. You could not really patch a bug yourself. You could not really change behavior. If you needed BuddyBoss to do something it did not do, your options were file a support ticket and wait, or fork the whole thing and lose your update path forever.
For most projects, the trade-off was worth it. You were buying speed, not flexibility. The flexibility you had access to was inside the plugin own settings panel, which, in the good plugins, was extensive enough that you rarely needed to break out.
When black boxes compound
The problem is not one black box. The problem is that a real WordPress site in 2026 has six or eight or twelve of them, and they do not talk to each other.
Picture a real client site. WooCommerce for products. ACF Pro for the custom fields. LearnDash for the course platform. MemberPress for gated content. The Events Calendar for the workshop schedule. Gravity Forms for the contact and lead-gen flows. A premium SEO plugin. A backup plugin. A caching plugin. A page builder - Bricks, Elementor, Divi, whichever generation the previous developer chose. Each of these is, at best, well-documented for its own surface. None of them are designed to interoperate with the others in any deep way.
What that means in practice:
- A bug between two plugins is a finger-pointing exercise. Plugin A support says it is Plugin B problem. Plugin B support says check with Plugin A.
- A feature that crosses two plugins, like a course that grants membership access on completion, requires custom code that lives nowhere, in a third-party glue plugin, or in a child theme function that nobody documents.
- An update to any one of them can break any other one. The site is never in a known-good state for long.
- If a plugin author abandons the project, you are stuck. You cannot fork. You cannot patch. You cannot migrate without major surgery.
This is what I mean by black boxes compounding. It is not that any single plugin is bad. It is that the architecture of WordPress core plus a constellation of independently-developed proprietary plugins is fundamentally fragile in a way that the marketing copy never admits.
What changed in 2026
The trade-off held for a decade because the alternatives were worse. In 2026 the alternatives are not worse. A few things shifted at the same time.
AI changed the cost of writing custom code. The thing that used to take 12 hours of a developer time and a $299 plugin license now takes a couple of hours of a developer-with-AI time and zero plugin licenses. That is not a hype claim. That is what the actual hours look like on the project tracker. The economic argument for buying a third-party black box to handle a 200-line feature is wearing thin.
Headless and static stacks matured. Astro, Eleventy, Next, Sanity, Contentful, Decap - this stack is not experimental anymore. It is production-grade for the kinds of marketing sites and content sites most of my clients need. The content modeling story is better than WordPress, the performance story is better than WordPress, and the code you ship is your own code.
The wait-on-a-developer problem got more painful. In a world where I can get answers to a technical question in seconds, asking a client to wait two or three days for a plugin support ticket to come back feels worse than it used to. The opportunity cost has gone up. The patience has gone down.
One brief note on the Automattic situation in late 2024. I see the underlying point on more than one side and I do not want this piece to be about that. It is fair to flag, though, that the situation is downstream of the same architectural problem this piece is about. The ecosystem you depend on for a WordPress site is controlled by people whose decisions you do not get to vote on. That is the part that should make you cautious, regardless of which side of any particular drama you land on.
An aside on Gutenberg
Gutenberg is a genuinely good editor in isolation. The block model is the right model, the editing experience is fine, and the direction it points WordPress in is the right direction. Two things I would flag anyway.
First, the markup it generates is still heavier than it needs to be. Class names, wrapper divs, inline styles. It has gotten better, but a hand-built or component-rendered site will produce cleaner DOM almost every time.
Second, and more important: content editors should not be assembling pages from primitives. They should be stacking predefined sections that a designer has already shaped. Hero, then feature grid, then testimonial, then CTA. The buck stops at the section. Anything more granular - choosing between three font sizes inside a section, dragging a column wider than the design system allows - is a guardrail removed, and removing guardrails is how brand consistency dies over 18 months. Gutenberg gives editors more rope than they need. The fact that it can be locked down does not change the fact that, by default, it is not.
What I do instead
I am not anti-WordPress. There are projects where it is still the right answer. High-volume content sites with editorial teams who already know the admin. Sites that need a specific premium-plugin feature that has no equivalent yet. Sites where the client owns the existing investment and migrating is more expensive than maintaining. WordPress will still be a real platform in five years. I will still build on it when it fits.
What I will not do is pretend it is open source in the way the marketing copy implies. The version of WordPress that exists in slides at WordCamp is not the version of WordPress that exists in your /wp-content/plugins folder. The first one is open. The second one is mostly not.
For new builds where the client does not have a deep WordPress investment already, I default to headless or static now. The reasons are the ones above. Code I own. Content modeling that fits the work. No plugin roulette. Faster sites. Fewer 2 AM emergencies.
And the dogs-at-the-kennel analogy still works. It is just that I have moved to a setup where I am not boarding dogs anymore.