What made WordPress incredible (and helped it grow)
If you were around in the old days, like 2005, there were a lot of different blogging platforms. You could find them using a variety of different programming languages (in case you wanted to make modifications), but each one came with some core features that made it easy to create blogs (and later websites).
I remember my brother and I comparing notes. He was looking at Community Server (later Telligent Community) and he even went to work for them. I had been using a different .NET product, called DotNetNuke. But then I found WordPress. One thing felt like it helped WordPress stand out – and that was how many themes and plugins were available.
I'm not saying those other ecosystems didn't have a community of folks building things, but it wasn't anything like the quantity of code being produced for WordPress.
And the beauty of the platform was the ecosystem flexibility. That's a made-up term that I coined just a few seconds ago. But hear me out.
What made WordPress so incredible, even back then, was that I could pick a theme, create content, then a month later, change the theme and my content still worked. It still showed up.
What made it so incredible was that I could use one plugin for related posts, and then later change my mind and use a different one, and I didn't have to re-code my entire site.
Quantity of available options (in both plugins and themes) was one part of the success, for sure. But the other part was the ability to swap one available option out and drop in another, and everything still worked. That's what I'm calling the ecosystem flexibility. Someone smarter than me can surely find the right term or name it something else, but that flexibility was and has been incredible.
It's what has fostered the ability for the community to have GravityForms, WPForms, NinjaForms, Formidable, ContactForm7, WSForm and more all co-exist and all grow. People use one, then swap to another, and it won't kill you (though you'll have to create your forms again).
Theme Frameworks & Pagebuilders
If we continue down the road of navigating my version of the history of WordPress, we get to the early frameworks. Do people even remember that WooThemes existed and had a theme framework? The most famous of these theme frameworks wasn't the work of iThemes, WooThemes or even Crowd Favorite. It was / is the Genesis Framework (which is still around today, purchased by WP Engine).
And what we saw, as Genesis took off, was that developers started specializing in Genesis – from building child themes to plugins that extended just Genesis, to building agencies dedicated to building sites using the framework.
The good news was that you could build something really fast with Genesis, but you could also build something without it. The bad news was that if you changed from Genesis to something else, it wasn't just the theme that you'd have to work on after the swap, it was all those extra Genesis-specific features (social icons, etc) that you'd have to replace.
That was a bit of a challenge to the ecosystem flexibility, but what we saw was people were either Genesis folks, or they weren't. Not the end of the world.
Pagebuilders didn't bring the end of the world either, but they added another layer to the ecosystem flexibility challenge. If you built sites using Elementor or BeaverBuilder, you likely weren't jumping to the other. And if you built a site with either Pagebuilder, you likely bought a pack of extended mini-features (add-ons) that enhanced what you could do with it. It was basically the same thing as Genesis-specific plugins, but for Beaver Builder or Elementor.
And if you decided to re-build your site and switch from one solution to another, you were likely going to have to spend a decent time re-creating things.
Will Gutenberg bring back Ecosystem Flexibility?
The introduction of Gutenberg to WordPress didn't kill the pagebuilder ecosystem any more than pagebuilders killed Genesis. There will continue to be evolutions to how WordPress sites get built. But I did wonder if Gutenberg would re-introduce the flexibility that existed in the early years – simply because a lightweight theme and some blocks could make a site look pretty great without locking you into anything. And if you wanted to drop in a new block from a new player, it would be additive.
That's really the key, in my opinion. Can you add more blocks from different block vendors to your site, and not have to re-create your whole site? And the answer from the folks working on the core of Gutenberg, along with several companies building free (and premium) block libraries – was “yes!”
So what's the issue? What are you going on about?
This weekend I started playing with four themes:
All four are lightweight and fast WordPress themes that work well with Gutenberg. I wanted to dig into and write about the notion of content blocks.
My idea was to create a content block (like the Clarity CTA you see at the bottom of my pages / posts) and then “hook” it into the theme at the bottom of all the pages.
After a couple of hours, I was frustrated, but not with building and configuring the Gutenberg block. Instead I was frustrated with a lack of flexibility that I didn't expect.
Take a look at this screenshot and tell me what you notice?
- Astra's theme has a Pro plugin. And it has a set of Gutenberg blocks.
- The Blocksy theme has a Companion plugin.
- Kadence isn't just a theme. It has a Pro plugin and a set of Gutenberg blocks.
- And GeneratePress is a free theme. But also has a GP Premium add-on, plus the new GenerateBlocks (/Pro) blocks.
You may say, how is this any different than Genesis and it's Genesis plugins, or the pagebuilders and their pagebuilder add-ons? It's not, really.
Except the idea of Gutenberg wasn't that I would have to pick a theme, a pro plugin to add more extensibility to the theme, and the custom pack of Gutenberg blocks.
This isn't a Gutenberg problem. This is the way the market is implementing the move into Gutenberg. With micro-ecosystems that limit flexibility.
- In Astra, it's called a Custom Layout. If I change my theme, it's gone. But even if I don't, and I simply change the blocks I'm using it doesn't display well.
- If you use Blocksy, it's called Content Blocks. Same feature as Custom Layout. Just a different name. With slightly different hooks. But use different blocks and it doesn't hook right.
- If I wanted to create something that looks great in Kadence, I really need to use Kadence's Elements (same as Custom Layout & Content Blocks), and Kadence blocks.
- My GenerateBlocks look and work great when I use GeneratePress.
You get the idea.
What's the answer? How do we get back to the flexibility we want and need?
The other day I wrote about our recent tests to find the fastest WooCommerce theme. Somehow, in my focus on speed and performance, I missed this dynamic. And it worries me.
My encouragement to every theme vendor, and every block library vendor, is that we try to:
- Name things the same. Imagine if every form plugin called “exports” and “entries” something different. That would get annoying very quickly.
- Make sure we test as much for other block libraries as we do with our own. Blocks should be additive.
- It would be over-the-top amazing if our content blocks were available regardless of theme (which is a core issue more than a theme vendor issue).
- And it would be amazing if we could start a conversation about the hook architecture of themes to find a single model.
I don't know if any of this makes sense and/or worries you at all. But hey, it's Saturday, and I'm going to walk away from creating re-usable Gutenberg content blocks and go watch some football. Have a great weekend!