I sometimes like to tell people I’ve been using WordPress since it was called b2, which is not a well-understood reference anymore, even within the WordPress community. A fair number of members weren’t even born yet, so that makes me feel just a little long in the tooth. In internet years, that’s almost primeval but it’s true. I remember when “Internet” was always capitalized and we hand-coded everything in text editors. (Some of us still do.)
WP & Me
Back around the turn of the millennium, there were these things called “weblogs,” and we nerds regularly read the musings of Dave Winer, Doc Searls, and anything on Slashdot, before Seth Godin, and even before Kathy Sierra. It was a kind of golden age, when platforms like Movable Type, LiveJournal, and Blogger were born. Even back then, I knew you should own your own content and control your platform — I was a firm believer in Open Source Software. People of this bent had a few options, like PHP-Nuke or for the more adventurous, Mambo, Slashcode, or roll-your-own. Other options came later, but around that time I ran a Linux advocacy blog on custom code (Perl & MySQL), where I posted daily for about three years and even got slashdotted once. I had to write my own open content license for it, since Creative Commons licenses hadn’t been written yet.
Needing to launch another blog site around that time, I did a search and came up with a few options, which I immediately narrowed to self-hosted GPL-licensed ones, which brought me to CafeLog b2 as the leading contender. (Note camelCase was big in those days.) This is the software which was later forked as b2/evolution and WordPress, and b2++ which later changed its name to WP-MU, commonly called “multisite”, which was a separate code base that for the most part maintained compatibility with WordPress so they could use the same themes and plugins, though not all of them were compatible with MU. This is a point which a number of community members get wrong — multisite was not a new feature for WordPress in version 3.0, nor was it a 2010 fork of WordPress — it was a 2010 (version 3.0) merger of the two code bases. It’s worth noting as well that WordPress.com has always run WP-MU, so obviously this made it easier for Automattic to maintain. (Having run MultiSite both before and after the merge, I can tell you MU has gotten a lot easier to install and there are far fewer plugin incompatibilities now.) There’s more of this history in a 2013 interview with Donncha O’Caoimh, who maintained the WP-MU fork until the code merge.
When setting up additional blog sites during that same period, I noticed there were forks of b2 available. Reviewing b2/evolution, WP-MU, and WordPress, I selected the latter as my fork of choice for what I needed, and hundreds of websites later, I’m still using it. Other CMSs and blogging platforms came along around the same time as WordPress, like TextPattern and others, but WordPress was gaining traction. (On one of the sites from that era, I posted daily for about four years, and without really intending to, it became one of Technorati‘s top 10 in two niche categories.)
6 Favourite Features
Of course, since 2003 there have been a number of new features within WordPress core. Some of the ones I remember being most excited about or thankful for have been
- Plugins
WordPress 1.2 introduced a new plugin architecture. Until then, you had to use a “hacks” file to accomplish any functional changes. - Pages
I remember when WordPress only had posts, and I still had some hand-coded html pages on my site as a workaround. This resolved the biggest issue that I’d had with b2 and WordPress up to this point. - Tags
It seems like a small thing and you just can’t get clients to use them now, but back in the day, tags were a big deal in blogging and many of us were using plugins to add them. Bringing them into core and converting your old system to native tags was a big plus for WordPress. Later on, the fact that WordPress now had two types of taxonomy would mean it could also have custom taxonomies. - Custom Post Types
Many people cite this as the release that made WordPress a CMS, which was somewhat offensive to those of us who had been using it as a CMS all along. Still, this was the feature that made WordPress so extensible and made it viable to use as an application framework. Remember tags? Enter custom taxonomies to go with your custom post types, and you were no longer limited to posts and pages — you could have any content type you could dream up. - REST API
For most users, this is a hidden feature they know nothing about, but it solidifies the ability to use WordPress as an application framework and becomes the linchpin for the development of its interfaces and integrations from then on. - Gutenberg
Perhaps it’s controversial, but Gutenberg is a forward leap for the WordPress editing experience. It frustrates me at times and it does things I think it shouldn’t at times, but it is most definitely the way forward. Page Builders were becoming so popular and numerous that a block-based system was necessary in core, and with Gutenberg we have one that is faster and more flexible than any of the others available. We aren’t done with the growing pain, but it’s something we need to embrace.
6 Least Favourite Features
It’s only fair — I haven’t been a fan of everything that’s happened.
- Kubrik
I’m sorry, I just never liked it. Sadly, it was also the default theme for several years until 2010, so I also associated it with splogs, since they all used it. - The File Editor
I know people use and like it, and it even got a facelift with syntax highlighting, but philosophically I do not believe it should be in core, as it’s a security risk to be able to edit executable PHP files in the filesystem from within the application. It could be limited to editing CSS files only, but should really just be removed from core and made into a separate plugin. Yes, I know you can disable it, and always do; there’s a reason every security plugin will do this as well. - PHP Snippets Plugins
For much the same reason as above, it’s a security risk to allow people to paste code into a text box and run it. These snippets should have as a minimum barrier to entry the requirement to put them into a plugin file and upload it. - “Pro” This & “Pro” That
Paid plugins are good for the WordPress ecosystem, and this is more a community/ecosystem thing than a purely WordPress thing, but I have a real dislike for calling something “pro” just because you pay for it. I’m okay with “Plus” because you’re usually paying for extra features, but it’d be a false dichotomy to imply something free is amateur or in any other way less. Plus, if someone referred to a “WordPress Pro,” I’d assume they were talking about a person. - Page Builders
Not that I’ve never used a page builder, I have… but the ones that leave behind a veritable shortcode hell when disabled with all the content hidden safely away in the database where you’ll never find it should all die a slow and painful death at the hands of Gutenberg. Just saying. - Advanced Custom Fields (ACF)
I may get flack for this, but I think ACF has done more harm than good. Many people have benefited from using it in saving development time, and may argue their own use case for it, but having seen it used by various developers on no small number of sites, I see it misused more often than not. It’s strength is its greatest problem: you can do all kinds of things with it, but if you don’t think about the site’s architecture, you will likely do the wrong things with it. I’ve seen it used just to put some text in a header, and I’ve seen it used to build every piece of content on every page, each of which had its own custom template to display the ACF fields. The functions that ACF replaces aren’t that complex, and can be created with free online code generators. Sometimes a barrier to entry is a good thing. We might infer from Peter’s Uncle Ben that if you can’t handle the responsibility, you shouldn’t have the power.
Market Share: the Holy Grail
A change in the license of Movable Type to begin charging users in 2004 saw a mass exodus from the platform. Once bitten, twice shy: users mostly moved to Open Source solutions, where WordPress was ready and waiting. Some users, seeing what happened at Movable Type, left other platforms like Blogger and LiveJournal to avoid the same fate. This little twist of serendipity was one of WordPress’ greatest moments, and at least in terms of market share, it’s never looked back.
You almost can’t read a WordPress article from any time in the past 10-15 years without seeing a reference to its then-current market share. Isn’t it up around 43% now? I kept watch on it from around the 25-40% range. I know that in a given year it can grow by the market share of one of its competitors, and that the next-biggest share goes to “other.” Perhaps controversially, I’m going to say that this is enough. WordPress doesn’t need more market share, and if it goes above 50%, I think it will be unhealthy for the industry as a whole. There need to be others out there; competition is a good thing. Too much market share for Bell, Windows, Amazon, or iTunes or anyone else getting too close to monopoly status has historically been bad for the consumer and served to reduce their choices.
True, it’s a major point of differentiation that WordPress is Open Source, and other Open Source projects have worked well with large market shares (Apache, BIND, Linux) but I still approach it with caution, since within the WordPress ecosystem, Automattic holds all the sway. This is not a problem yet, but if Automattic ever went public and had shareholders demanding larger profits, it would have a serious negative impact on the ecosystem.
The reasoning is a much bigger topic, but the closer WordPress gets to 50% market share and beyond, the less inclined I am to celebrate.
The Future?
Difficult to see, the future is. But as WordPress has matured and added the features I’ve noted above along with many others, it has become a website platform of its own. In other words, it has become almost its own layer on top of your LAMP stack (helpfully, MariaDB also starts with “M”). Having worked with numerous developers, I’ve found a difference between PHP developers and WordPress developers. While a number of the former may tend to look down on the latter, knowing the available WP functions saves a ton of development time in not reinventing the wheel. It can also save you from having to debug poorly-written SQL queries.
I’m going to wrap this up by suggesting that WordPress will continue to grow in its impact on the internet, whether or not it continues to grow its market share. More WordPress projects are resulting in large, custom, scalable sites including complex applications, building on an increasing array of options within WordPress core. We’re doing this here at Modern Earth, and I know there are others are doing so as well.
As websites themselves move beyond placeholders and brochureware to content management and ecommerce applications into becoming customer portals that may interact with any number of other systems, WordPress has been maturing into a platform ready to have these custom functions integrated into it. In short, the future of the internet is also the future of WordPress.
