Alex King (AlexKingOrg)

WordPress has become the go-to CMS for 22% of all new websites, particularly for enterprise and agency projects. WordPress is also about to celebrate its 10th anniversary this year. With this important anniversary, I wanted to check in with one of the original contributors to the platform, Alex King, to get his perspective about the growth of WordPress over the past 10 years.

Alex has been with WordPress since it was a tiny fork off of B2, and is the founder of Crowd Favorite, one of the oldest WordPress development agencies that specializes in large WordPress development and design projects for sites like AllThingsD, AMCTV, and others.

Alex’s perspective on how WordPress has grown into a mature, enterprise platform is particularly informative because he has seen WordPress develop and evolve over the years via his own contributions to Core, as well as his work with some of the largest production installations of WordPress on the Internet.

Alex and I had a conversation to dig into how WordPress has come into its own as a CMS and App Engine in the past 2 years.

In our interview transcript, Alex shared what he thinks have been the biggest developments that have made WordPress into one of the most mature platforms on the web.

You mentioned that it was about five years ago that large publishers started getting interested in using WordPress, is that right?

Yeah, I was actually involved with the first projects, just prior to founding Crowd Favorite. The Wall Street Journal was looking to use WordPress as a platform for a new site that they were going to put together called, AllthingsD.com, and I worked alongside folks at WordPress.com to put together a Multisite system to host content for Walt Mossberg, John Paczkowski, and Kara Swisher. A lot of them published stuff continuously on the Wall-Street Journal as well as on AllthingsD.com, and also made AllthingsD a full archive of all of Walt Mossberg’s content. It was the first really large-scale site with a large-scale publisher to use WordPress as the publishing platform.

What was it about WordPress that got them interested in using it for such a huge project? That was new for the platform at the time.

They basically had an interest in wanting to use WordPress to avoid vendor l0ck-in. The technical lead for Dow Jones on the project was Raanan Bar-Cohen, who later went on to join Automattic in charge of business development.

One of the things that I’ve seen as a common thread just from anybody interested in WordPress as a platform is basically trying to avoid vendor lock-in using a platform that will be open. Nothing is future proof, but when you have a platform that has a lot of adoption and a large number of developers you rarely find yourself backed into a corner the way you can with proprietary platforms.

So with an open-source platform like WordPress, where there is a large community of developers, it’s really easy to make sure that your organization doesn’t get backed into a development corner. But what can happen with proprietary software?

Well once you do your initial investment on any platform for a website, you don’t want to lose that investment, right? The largest sites are typically six and seven-figure plus investments. And the proprietary vendors oftentimes have license fees that people have to pay annually for software that they’re using, and they’ve got upgrade fees and all sorts of stuff that comes along with the software. And the end-users don’t have much control over the direction of the platform.

Sometimes companies that produce software go away and are no longer viable entities. Sometimes companies get acquired by other, bigger companies and now all of a sudden what used to be favorable software terms go away and get replaced with unfavorable terms.

So when you build on top of an open source platform you have more control of your own destiny, and you know the worst case scenario means hiring your own developers to work on the project, possibly forking, possibly not, in the worst-case event that the main open-source project goes sideways. You’re not locked in to the types of fees and business concerns that can happen with a proprietary vendor.

So what were some of the features that were important to WordPress initially that made it a suitable blogging platform for companies, for sites like AllThingsD?

There’s been quite a bit of customization for AllThingsD. There’s been actually a lot of retrofitting over the years as more features have been added to the WordPress core like custom taxonomies, which were added just a couple of years ago. Those were things that we were leveraging before they were officially supported in Core.

The New York Times has been using WordPress as a blogging platform for a similar amount of time. I think it’s five or six years ago that they launched the NYT blogs on WordPress. I think that they’ve been pretty much sticking with the Core code with probably a minor amount of modifications, although I haven’t been involved in those projects.

I think WordPress made an interesting choice to stay out of the box as a blogging platform, but still expose enough of the framework as a guide to developers and allow them to make it a very viable user- friendly CMS system.

So one of the big things that WordPress has been unfairly limited for, especially in the past, has been for just being a blogging platform, and you just mentioned that you were working on the custom post types for AllThingsD. That was about five years ago, but it was three years ago, when, the end of 2009 or the beginning of 2010,  that Custom Post Types were added and WordPress was no longer just a blogging platform, but stepped into being a full- scale CMS. What is it about Custom Post Types that gives a user more than the ability to just blog?

I think it’s actually really interesting the way WordPress has approached things as a CMS, because they haven’t gone the direction of ExpressionEngine or something like that, where they baked the additional functionality into the UI.

Jon Hamm Custom Post TypeYou still have to do work to add some Custom Post Types and write code, or do something that effectively generates that code for you. I think WordPress made an interesting choice to stay out of the box as a blogging platform, but still expose enough of the framework as a guide to developers and allow them to make it a very viable user- friendly CMS system. Specifically utilizing the custom post types and taxonomies.

The big benefit is the ability to model more complex relationships. One of the sites that we built that really leveraged this was AMCTV. We had custom post types for shows, and custom taxonomies for shows, and custom post types for actors and characters. That allowed us to say, “okay I want to be able to pull in all content regarding Don Draper the character, or I want all content regarding Jon Hamm the actor.

Some of those things have crossover and some do not. So you might have an interview with Jon Hamm that’s not really related to the Don Draper character. Then when you’re creating custom post types for the character within the show you can then pull content from all across the site using the taxonomy that’s attached to all the different custom post types there’s a News Post Type, there’s a Show Post Type, there’s a Media Post Type. There’s all this other stuff out there that will be sucked in and the content becomes much more dynamic and you can do much more powerful things to expose that content in useful ways throughout a larger and more robust site.

It seems to me that there’s a really subtle difference between a Blog Post and a Custom Post Type. Can you explain what it means to be more robust as a Custom Post Type?

I think that the best way to think about it is Custom Post Types allow for exclusion of content more easily. So if you have everything as a single type of content, and you have little bits of information that decorate those posts and give you more details about them, to say this is a New Year’s post or this is a blog post or this is a character page but they’re all in the same bucket together, then you spend all of this time trying to filter out the things that you don’t want most of the time.

One of the things you want to have is a news feed on your page, and for that you want to pull just the news stuff. So you’re trying to filter out everything else.  Having some post types allows you to silo the content in natural ways and then reach across the silos only when you explicitly want to. And that’s the 90% case when you’re working with the CMS, you’ve got these different areas of content that you only want to commingle in very intentional places.

Matt at the State of the Word in 2012 in San Francisco said he thinks we’re going to see WordPress used as an App Engine in 2013 and 2014, so it’s a natural jumping-off place from Custom Post Types t0 an app. Talk about what that actually means: to use WordPress as an App Engine rather than another development platform.

WordPress as an app platform makes sense only for specific types of apps that are already compatible with the type of data storage that WordPress does. WordPress is an archival type of system. We build custom web applications with non-WordPress platforms at Crowd Favorite as well, and when we’re choosing whether or not we’re going to use a custom platform or WordPress for a product, the thing that we’re really looking at is, what is this app trying to teach you? What’s the data search? How are we going to be querying for the info that we want?

While you can fit a ton of stuff in to WordPress’s schema because it’s so flexible, there are a lot of situations where you end up really fighting against the existing schema when you’re trying to get the data back out and WordPress is more trouble than another platform.

For example, I built an app on WordPress that I use for logging all of the HR requests that come in from my team because one of the things that happen when we hit 15-16 people was the problem of how to manage all the information, time off requests, notes about healthcare, and the rest. I just needed a place to log that information, so I used Custom Post Types and custom taxonomies to create a system where I can just throw stuff into WordPress and pull it up by each person and have a very efficient journaling system. WordPress is awesome as a platform for that type of app.

I think if you’re looking at creating a time management system, a billing and tracking system, or a project management system where you’re going to have complex reporting requirements, and you need to have the data stored in certain formats that make that type of reporting efficient. The WordPress schema out of the box is not going to be the right solution for that. You can make it work, and people have built contact managers and project managers with WordPress, but you’re swimming upstream more than you’d like, or than you arguably should be.

What are WordPress’s limitations for a project management system? It’s helpful to understand how useful WordPress actually is by also acknowledging where its limitations may lie.

There just aren’t columns for the information you want in the WordPress schema, so if you create a Custom Post Type for a task or project, there’s no column in the post field for the status of that project or the priority of that project, or who it’s assigned to. You can repurpose different fields in different ways, maybe use the publish column with some custom values, maybe use the author, but you’re not going to have the type of efficient queries to run real reporting on that stuff, especially at scale, than you would if you had a custom schema that was designed specifically for that application.

When you look around, 22% of new websites created are WordPress, some of the highest traffic blogs as well as websites on the internet right now are WordPress. Can you talk specifically about how production usage of WordPress by large sites?

You’ve mentioned AllthingsD, the New York times, and theWall Street Journal, Tech Crunch, VentureBeat, are all sites with millions and millions of visitors using WordPress. They’ve got scale. They have robust features. They have hundreds of contributors. How has that contributed to making WordPress what it is today?

Interesting question. I think in a lot of ways WordPress.com has been one of the biggest reasons why WordPress has become more scalable. Because one of the areas of contention when I was contributing to core back in the early days of WordPress was efficiency. I was trying to make WordPress more efficient, but I was having trouble getting traction with that. People were saying they didn’t feel they were important at the time because people weren’t complaining about that enough, so it wasn’t a problem.

That’s a legitimate way to approach prioritizing issues, but it was frustrating to me personally and one of the reasons I stopped contributing to core, and started moving more into plugins and themes, and other projects where I felt like I had a little bit more direct control.

Then a couple of years later as WordPress.com came along and larger publishers were signing up with WordPress, some of those performance concerns started to come to the forefront because people were trying to serve larger and larger sites. Now the topic is so popular, you can’t do a Google search without finding “18 ways of improving performance on a WordPress site.”

There’s a lot of really good tools that people have built, a lot of really good platforms, a lot of really great information about how to tune different configurations, how to use things together to make WordPress scale not just at enterprise scale, but other applications as well.

Scalability on the web is kind of the art of knocking down the next big bottleneck, right?

Most recently, WordPress 3.5 had the ability to run a Multisite instance from a subdirectory, as well as a single site instance. That allows shops and large publishers that are doing this at large scale to be able to create better automation tools, and create clusters and environments that support really large traffic that super high-end WordPress sites need to be able to deliver.

So you’re saying that without those high scale applications of WordPress, the Community might not have responded to the need to make Core more scalable? And so WordPress.com has been a driver of adoption because  that and VIP have made it easy for those large organizations to use WordPress in the first place?

I think the experience that Barry Abrahamson and the operations team at .com had early on profiling WordPress as an application and seeing where bottlenecks were, and then working with the Core teams to try to optimize it was key. Scalability on the web is kind of the art of knocking down the next big bottleneck, right?

You say, “ok this is the thing that is causing the most amount of grief,” and then you figure out what the next thing is, and solve that. You just kind of keep working your way through and I think we saw a lot of that happening in Core, especially in the late 2.0 releases where there was a lot of optimization happening, retrofitting things that had been poorly optimized to begin with.

But how were the production use cases of WordPress by these large sites essential to actually pointing out where those bottlenecks were located? For example, code that might run fine at low traffic levels, but suddenly those little details add up and crashes your site at scale. Like if you’re writing transients that don’t expire, for example, that will build up in the options table and then never get deleted.

Yeah, with transients, let’s say you‘re making the assumption that the transients will always be on the options table and you find yourself in a high-scale environment, then all of a sudden it’s probably in some sort of key/value store cache back end, as opposed to hitting the database rows and you’ve got assumptions that are eventually going to cause problems for the site.

So what about WordPress security fixes in Core? What are some of the highlights in your mind, of how WordPress has gotten as secure as it has in the last two years? There were concerns about WordPress being insecure 2 years ago, but frankly, those have all been production-tested by this point, particularly with sites like the one’s you’ve already mentioned.

There was a big push to standardize the way that security was handled in core throughout the codebase where they introduced a set of escaping functions, and things like that to be used consistently. The Core team went through the process of trying to input those throughout the entire core code base over the next series of releases.

Once that happened, there were a number of security issues that came up where not all of the changes had been implemented completely. So it was a process of finding the stragglers here and there that needed to be included in those best practices. And then there was the addition to the Community of people who have a real passion for trying to find much more obscure platform-level security issues. Looking at WordPress not just from a code perspective, but from the entire application vulnerability perspective and looking at ways that vulnerabilities in plugins and themes can be changed into the WordPress stack. And how Core can be hardened to try to reduce those types of vulnerabilities.

I would even expand that to say that one of the things that has shown the maturity of the WordPress platform is the explosion of not just the third party hosting, but significant pieces of functionality available as plugins, themes that enable specific verticals and use cases.

The things that are getting patched right now, security patches, over the last two years have been really obscure, interesting security issues, they haven’t been the kind of bonehead,  “somebody forgot to escape something,” issues that were around as people were trying to formalize how WordPress security was going to be approached four or five years ago.

I think it has been the natural progression of the platform itself as the people that have been involved in the platform for a long time have been exposed to the types of large scale internet security issues that happen that are important for really big scale applications on the web and then also the majority of the Community, more people that are security minded contributing in positive ways.

So let’s also talk about the UI on WordPress because it’s become more user friendly, and it’s really easy to insert your content and hit that publish button and get things out there. What are some of the ways that that really makes WordPress a mature platform that’s not just accessible for the developer but for the enduser as well?

I don’t know if I really agree with that. I think the WordPress UI is very functional for people who are willing to put in a little bit of effort to understand how it works. I think it’s a little daunting for new users, there’s a lot of stuff there. It doesn’t allow the flexibility that I’d like to see when we’re using WordPress as a CMS, you’re using it as a CMS or as an application as we talked about previously.

There are a lot of situations where tailoring the administrative interface to a specific use case makes a lot of sense and that’s one area of WordPress that is not very flexible.

That is something that I spent a lot of time talking to people about at WordCamp SF last year, and my big takeaways from those situations were that this is a choice. The perceived benefits of consistency in the interface trumped the benefit of custom interface for specific use cases. So if somebody logs in to a WordPress site they generally know how that site is going to work regardless of what that site is for, versus a real custom interface for my own HR application or a large CMS site that has lots of different customizations.

WordPress started as a tool for tinkerers. Initially, you had to download the code and install it. It was still really easy to download and install, but that was a huge hurdle to get started that only tinkerers would find their way past.

I think that those WP-Admin interface right now is a bit of a compromise. I think it handles the 80% case pretty well. As you start to push the edges of what you’re doing with WordPress, the interface becomes less and less elegant.

We recently built a site that had probably a dozen or so different Custom Post Types. That explodes the side menu in a really awkward way, and you almost have to come up with a new solution for that type of navigation at that point. But there’s no easy way to do that. The admin interface doesn’t allow for easy customization, so you have to go and do things in a little bit hackier fashion then you’d really like to.

I think that it’s definitely clear, like the stat that you used earlier, WordPress’s adoption is testament to the fact that the interface is clear enough and easy enough for most people to understand and use. It’s certainly not hindering adoption or hindering the growth of the platform so far, but I think the experiment they’re doing on WordPress.com with the dashboard and the first run experience are designed to make it easier for people to go ahead and start writing content.

I remember when I first started using WordPress, I had two options: Drupal or WordPress. It was a really clear choice for me because I didn’t like the Drupal interface, I didn’t like how the plug-ins worked. WordPress was dramatically easier, but I still got help from friends who were already building sites with WordPress.

There are lots of people who have heard WordPress is the right platform for you to build a site. And these people are motivated to go figure out how to use it. And if you have a mental model of how a CMS in general works, then mapping any interface to perform that task becomes pretty easy. But if you’re starting from zero, then everything is brand new. At that point, WordPress isn’t just competing with Drupal anymore, it’s competing with Facebook and Twitter and Tumblr. These are platforms that I would say offer an easier way to publish for a lot of people.

The last thing I want to cover is the role of Managed WordPress Providers in the maturity of WordPress. There’s a little bit of bias in this topic because I’m with WP Engine. In spite of that, I think it’s fair to discuss how managed WordPress hosting has been a critical element to the maturity of WordPress as a whole because of how it creates opportunities for companies to use WordPress in production without having to know the server, scalability, and security aspects. All they need to know is how versatile WordPress is, and how to use it. What’s your perspective on how managed solutions for WordPress are impacting the maturity of the platform?

I would even expand that to say that one of the things that has shown the maturity of the WordPress platform is the explosion of not just the third party hosting, but significant pieces of functionality available as plugins, themes that enable specific verticals and use cases.

WordPress started as a tool for tinkerers. Initially, you had to download the code and install it. It was still really easy to download and install, but that was a huge hurdle to get started that only tinkerers would find their way past.

The first time I set up a server on AWS to install WordPress on, it took me 20 hours to get it all figured out and it was because I didn’t have a ton of Linux experience at the time. But 20 hours! I was pulling my hair out.

That experience is invaluable. In those 20 hours you probably learned a ton of stuff,… but a lot of people don’t have the time or the interest to invest in that type of exploration. They’ve got a specific problem and they want a solution for it.

One of the things that I’ve written a little about is “Is WordPress a platform or a product?” Really I think it comes down to the eye of the beholder.

There are many people who make their living, like my team does, using WordPress as a platform, we build on top of it. There are many people like a number of your customers that view WordPress as a product that is going to solve a specific problem for them. They want to get in and solve that problem, and they don’t want to deal with questions like, “is my hosting version up to date?” “Has my security patch been applied?”  That’s where Managed Hosting Providers just eliminate that entire set of issues from the equation.

That’s a good way to understand WordPress in terms of how people are using it- there are several different levels. There’s the blogger that’s using it, there’s the small business, there’s the guy that’s hiring Crowd Favorite because you’re going to take WordPress and build something else on top of it.

There’s even different levels of custom WordPress where you can easily spend six figures on custom app development, and end up with something that is so robust that it doesn’t even resemble the same thing that the blogger who installed the 2013 theme on their site. That individual may be blogging regularly and be really happy and feel like they have a great site but that’s a far cry from using WordPress for development of a custom app to be used in production.

Yeah it’s one of the things that creates a little bit of confusion in our community and is making WordCamps increasingly more challenging as our platform grows. But it’s also one of the things makes the platform and the Community so robust and so powerful.

All right, Alex, I really appreciate you taking the time this afternoon to talk to me. It’s been an amazing conversation, and there has been a ton of really good insight about where WordPress has come from, and where it’s going.

Thanks Austin. It’s been fun. I enjoy getting to answer deep questions about this. It’s been a fun interview.

If you are curious to learn more about Alex, visit his website, AlexKing.org. And then check out his company, CrowdFavorite, which is an excellent agency to build production WordPress sites for your organization.

As well, if you’d like to learn more about how WordPress is being adopted in the Enterprise, stay tuned in our blog.  We’ll be publishing a lot more content on this topic in the next few months.