Wordpress And Concrete CMS A Philosophical Difference In Adding Features

I still remember the sinking feeling as I realized; I have absolutely no idea, and it would take my engineers spending at least several days with this codebase for me to feel comfortable putting a fixed bid on that request. This client thought they had bought something specific when they approved ‘Drupal’ as a product, but the reality was there were dozens of competing 3rd party modules for essential functionality that their old developer had used, and as a new shop we had no idea what we were going to find in the code base. 

That’s what we were doing in the industry, and as a business person it disappointed me. 

I’ve kept that experience close to my heart as our internal toolkit became Concrete CMS. Our philosophy is that a good content management system should give 90% of customers 90% of what they need to run 90% of websites. Yes, we have a marketplace full of add-ons and themes, but ideally we see those packages as the last 10%. Maybe it’s a great looking theme that will make your site stand out from your competitors. Maybe it’s a bunch of functionality that uniquely serves the needs of a particular market. Maybe it’s even a more powerful version of some basic functionality. That said, when we look at a marketplace extension and think “well every site needs one of those” - our immediate gut reaction is to think of ways to include it in the core. 

Obviously, this does not always delight the developers making these extensions. They’ve identified a hole in our product offering, built a solution, are selling it with success, and we come along and fold similar functionality into the core. That’s not a great way to treat your partners. We try to do our best to communicate around it, but yeah, fundamentally that’s just going to suck from time to time. The reason we’ll do that is the memory of that poor business owner who wasn’t particularly interested in if Drupal was open source or not, but just wanted to have a website that worked and could be extended by someone who wasn’t the person who originally built it. 

Can you imagine if Ford sold you a car, but to drive it out of the dealer’s lot you had to engage with a dozen different vendors to get it driving? 

No, frankly that customer just wanted to get from point A to B in a safe way that makes a lifestyle statement. If they wanted to build a car, they wouldn’t be at a dealership. 

WordPress has become the Kleenex of the web with a double digit market share. In the early days much of WordPress’s success was tied to the easy install they pulled off. Most other solutions in the aughts were complicated to even install, and once you got it running you were presented with a blank slate. WordPress captured a lot of love early on because you didn’t have to be an engineer to set up a new site, just a couple of clicks and anyone could be blogging about their cat. They were right to focus on that onboarding early on, but now there are plenty of SaaS platforms that deliver a business owner friendly experience. 

WordPress has started to feel more like Drupal to me back in the day. Talk to a great WordPress developer and they’ll tell you the first thing they do is install a dozen extensions for features as basic as SEO or a contact form. There are extensions out there for keeping your extensions up to date. From the outside it feels like that hilarious SnL Taco Town bit where someone who just wanted a taco is strung along through a ridiculous journey of choices they never wanted to make. 

I know WordPress talks about offering “decisions not options” to their users in an effort to avoid the checkbox trap of a lot of open source software. I also know the more customers you have using a piece of software, the harder it is to change it. People depend on something working the way it does. Even if that way has clear issues in retrospect, changing it later can cause more pain than you’d imagine. 

The recent back and forth over adding WebP support to the WordPress core was pretty telling. This new improved image format will make websites faster and is generally considered a good thing (we’ll be folding more support for it into the core in the future.) The downside of that double digit market share is when WordPress decided to include it in the core and turn it on by default (decisions, not options) someone pointed out they were going to break a huge chunk of the web because so many budget hosting WordPress sites were out there running at near disk storage capacity, that automatically generating all of these new images was a real problem. Debate ensued, and they ended up pulling the feature back out. 

That’s a pretty frustrating position to be in as a technology leader. It sucks to have a compelling feature ready but be unable to deliver on that because of the competing needs of a community that tries to be everything to everyone. I understand why Ma.tt has started talking more about pushing functionality out into “canonical plugins” that are not part of the core, but still recommended by the core. It feels like a compromise that might make the loudest developer voices somewhat happier, but it really doesn’t feel like it’s going to make things easier for the end site owner. 

I can’t say if I’d make different decisions in his shoes or not, but what I can tell you is that Concrete CMS does an awful lot in the core that other open source content management systems depend on 3rd party tools for. 

With Concrete you get:

• Permissions
• Workflow
• Comments
• Calendar/events
• Forms
• Caching
• SEO tool (including bulk tools)
• Layout/WYSIWYG modes (since day 1)
• and so on… 

In WordPress, each and every one of these things is a separate tool from a separate development shop that may or may not keep it updated over time. With Concrete, you can count on all of that stuff working consistently from one site to another. Two developers can make two different add-ons that show calendars in different ways, and they should both be able to work on the same site, showing the same events. 

We’re certainly not always perfect about it, and upgrading a CMS is never going to be painless. Even with our approach, I know we’ve got themes that are still not version 9 ready ourselves - so I get the pain. That said, you can count on us to continually ask “shouldn’t a CMS actually ship with everything a site owner needs to manage content safely?” You can count on us to make hard decisions in an effort to build a web where a webshop can make some assumptions about taking over an existing site and actually provide a free estimate that’s fair to everyone, just like my plumber can today.