December 14, 2016
“I don’t care about the platform, let’s just create our website on something popular and cheap and get on with it”.
Dear IT decision maker, this is wrong. On an infinite number of levels.
This article is going to show you why. It’s not going to promote one technology or CMS platform over another,(well, at least not much, taking the author’s unavoidable personal bias under account). Instead, it’s going to address the issues that usually arise long after the CMS platform has been selected and paid for.
For the purposes of this article, we have picked interesting details about a number of popular and emerging CMS platforms like WordPress, Joomla, Drupal, Typo3, DNN and Umbraco , and we have also included references to Concrete5, Contentful and Rooftop, as well as Wix (a web site builder that is provided exclusively in SAAS form). Although WordPress is currently by far the most popular CMS out there, this post is not a “Wordpress VS the world” one.
Let’s take WordPress. It’s got over 24 million installations (an estimate from a relevant article on Quora, but we can’t know for sure what percentage of them regards installations of business websites as opposed to personal sites, blogs, or small business like hairdresser salons, neighbourhood groceries and auto repair shops (that are usually just a couple of pages set up on a free or very cheap theme and that’s about it). Don’t get me wrong – there’s nothing wrong with this type of websites, but they’re not indicative of a CMS platform’s capabilities in any way.
For comparison, Typo3 says it has over 500,000 installations, Umbraco says it has over 380,000 installations, Concrete5 is just shy of 140,000 installations and Drupal has over 1,200,000 installations.
Although other CMS platforms feature a very smaller number of installations, a Fortune 500 company website will – probably – outrank a local hairdresser’s website in complexity, features and quality.
So one number you should pay attention to is how many use cases are published out there, and for what type of clients. Do not base your choice solely on how many people are using the CMS, but introduce some quality criteria. How many companies in your business sector are using this CMS? What is their preferred choice and why?
Having been in the industry for about 20 years I’ve seen a lot, including “fake” CMS platforms. Many years ago, around 2001, I met with the owners of a small web development agency who believed in the doctrine that the client should be totally platform agnostic. They showed me the CMS they were using.
It was a glorified web file manager managing static HTML pages! This is what they knew how to do best – static HTML pages. But since clients were starting to demand “a CMS”, they gave them what they wanted.
When you choose your CMS, always make sure that it provides you with the editing functionality you really need. Chances are most of today’s CMS platforms will allow you to do several things (we’re not in 2000 any more), but how far you need them to go is up to you.
For example:
The above are just food for thought. There are actually dozens of tiny little things that you should consider in the same regard.
For some CMS platforms, the answer to almost every one of the questions above is “it depends on the developer”, which is actually a good thing since it means that the CMS can be properly customized and extended for your own needs as long as your specs are detailed and correct. Which leads us to our next point..
There are agencies out there that provide design and development services using their own proprietary CMS, claiming that it has been specifically developed to address your needs. While this may be true, you’re actually getting tied to a specific agency’s proprietary software, with little chances to find developers outside this agency willing to work on it in the future, even if the agency gives you the full source code of their CMS (which, in most cases, won’t happen anyway).
If you decide to go with a popular open source CMS, you should definitely take the “signal-to-noise” developer ratio under consideration. What I mean by that is that it’s easy to find developers for popular CMS platforms, but you should watch out for fakes or people with very limited knowledge. A rule of thumb is that the more popular the CMS platform is, the more chances you have to hire a person who just learned about it yesterday, or works solely with plugins/add-ons without having ever written a single line of code.
Although there are no known statistics for this, it is obvious that the easier a CMS is to set up and start with, the more possible a greater pool of inexperienced developers is. Open source CMS platforms suffer from this a lot – my experiences are limited to WordPress, Joomla and DNN Community – all three are very easy to set up and get going, but need a lot more when it comes to specific functionality. There are a lot of folks out there that claim to be “developers” using one of those platforms when in fact they just know how to set it up and configure it with a theme (usually a free one) and probably some plugins. Ask them to do something that isn’t covered by the core CMS functionality or the plugins they are familiar with and you’re suddenly open to a whole new world of expenses, bugs, and subsequently more expenses.
Maintenance costs, unless they are agreed upon from day one, are considered hidden costs and they often end up, in the long term, being higher than the actual cost of developing your web site with the CMS of your choice. If your CMS’ performance degrades over time or if your CMS is often vulnerable to exploits, then you *must* consider maintenance services. The alternative is far more expensive.
So what can you do? First, have in mind that the most widely used a CMS platform is the more “bad” people are going to target it and the more vulnerabilities will be discovered.
Exploit DB maintains a great database of exploits per platform. Let’s see how two of the most popular CMS platforms around today are doing there compared to other, less popular choices. WordPress had a whooping 982 total entries at the time of writing this article, Joomla (a similarly popular but notoriously insecure platform) had 1,152 entries while less popular platforms like, for example, Umbraco (the one I’m working with) had 1, Concrete5 had 16 and ModX had 15.
This does not make popular CMS platforms less valuable – it just indicates that, if left unmaintained, they will have higher chances of being exploited, hacked, defaced and lots of other terms generally meaning “more money to spend on repairs”.
The problem with updating a CMS in order to secure it often lies with third-party add-ons that may not follow your platform’s update path. It is common for popular CMS platforms to have a wide number of add-ons (called plugins or modules or packages or extensions, depending on the platform) made by third parties, and some of them break when the CMS is upgraded to a newer version, or even become the starting point for exploits in the first place.
At the time of writing this post there were 47,956 WordPress “plugins”, 859 DNN “modules”, 7288 Joomla “extensions”, over 1500 Typo3 “extensions”, 36,031 Drupal “modules”, and over 1000 Umbraco “packages, just to get a feeling of the sizes we are talking about.
If you go with a popular platform, or one that is widely known to often be the target of hackers, you should ensure that your site is developed in a safe manner, its add-ons chosen very carefully, and that it is maintained correctly (either by your agency, your web host or a person you will hire for that). Alternatively, you can switch to PAAS or SAAS solutions, like for example wordpress.org hosting for WordPress or Umbraco Cloud hosting for Umbraco and leave site maintenance to the experts (at a cost). Even Wix is considered a SAAS solution (with restrictions mentioned elsewhere in the article).
No matter how much you pay for your CMS and/or development, your content is what is most valuable to you and what you are going to be maintaining and expanding for years to come. You must be absolutely sure that you really own your content and that you can have it exported in a way that will allow you to reuse it with minimal cost if you need to.
Wix, for example, is a SAAS platform that provides a very nice (and cheap) way to have a site up and running in virtually no time – but with a price. Your content is “tied” to their platform and cannot be exported or transferred elsewhere.
Let’s say that the only thing you want done today is have your website built as soon as possible. What about tomorrow?
Often a website needs to get expanded with functionality that was not predicted or planned from day 1. This may include importing data from third-party sources, integrating feedback forms with CRM applications, adding e-commerce capabilities etc. If you have only your website in mind today, you may choose a platform that is hard (or expensive, or both) to extend in the future.
For example, WordPress has an abundance of plugins that make it integrate with third-party systems, and it’s relatively easy to have developers write some additional code to do so. But, if your long-term goal is to use the same platform for your intranet and include SSO capabilities for Windows Domains, then DNN is probably the way to go.
Let’s also not forget that a CMS today is not what a CMS was 10 years ago. A website on a desktop PC or laptop is only one way of presenting information. Your site must be ready for mobile (tablets, phones), and your data should be ready to be accessed by native applications. Well, most CMSs today solve the mobile problem by either letting you implement the responsive/grid layout of your choice or already using one for you (although how they allow you to form your content using WYSIWYG editors and how they provide decent previewing varies greatly). How you can expose data to be consumed (and updated) to native apps, though, is another issue.
If you are primarily interested in having your data consumed by third-party apps / native mobile apps, then a different set of priorities need to be introduced:
Does the CMS of your choice feature an API that is easy to use?
Although almost every CMS today is advertising an API, not all APIs are equally mature. CMS platforms with a rich add-on ecosystem usually feature the more mature APIs since those facilitate add-on development. A generic API may not be always useful for exposing your data to other apps, but it’s a first step towards that.
Does the CMS of your choice provide a REST API?
Some CMS platforms allow you to easily create your own REST APIs where others provide them out of the box (and allow you to extend them). If you need to make your data available anywhere outside the confines of the CMS, your best choice would be a platform with a mature REST API. Thankfully, all popular platforms provide that in a way or another. WordPress, for example, has multiple plugins that provide REST API functionality. Umbraco has a REST API developed internally. Joomla features a REST API in the form of an extension.
The factor that you should pay attention to, however, is how complete the REST API is. The less you need to extend it yourself the better.
For CMS platforms with an add-on ecosystem, a critical factor for your decision is how many of the add-ons you are probably going to use will work well with the existing REST API.
For example, Gravity Forms , a very popular WordPress plugin, is not implementing the WordPress API in a standard way and, instead, provides its very own API, which can lead to a lot of work if you need to seamlessly work with WordPress and Gravity Forms in a unified, RESTful way.
Should you consider an API-first CMS instead of a page-oriented one?
This is the toughest question that you may have to answer. If your primary goal is providing your data to third-party apps, then an API-first CMS like, for example, Contentful or Rooftop (which, by the way, uses WordPress as its back-end and manages to solve the WP-Gravity Forms API integration problem we talked about above), is definitely the choice to go for.
What an API-first CMS offers as an advantage is the total separation of the data and presentation layers, meaning you have an “engine” that can manage your data regardless of where they are eventually consumed. This can be a blessing or a curse, since it’s up to you to decide which technology to use for a web front-end (which is treated like any other app that consumes its data), while you may have to deal with potential limitations imposed by the number of SDKs available.
Let’s suppose your organization heavily depends on Azure, Office 365 and Active Directory. Why on earth would you select, for example, Django CMS as your platform? Although it is a fine CMS, its technologies will be far out of your organization’s scope and internal expertise and you would have to resort to third parties for every single issue introduced during the lifetime or your web site. You might do that anyway (see the next section), but you have no way to evaluate results if the technologies used are alien to you. Let alone integrate your web site with other things.
This is a highly subjective point of view and you may totally disagree, but my belief is that the CMS you will choose to power your web presence should be in harmony with other technologies already being used in your business, since this opens up a lot of options for its evolvement later. Unless, of course, you’re using an API-first, cloud-hosted CMS, around which you can build additional services.
So you’ve got a couple of IT people that are familiar with some Web technologies and you think that it would be cost effective if you selected a CMS platform that utilizes the technologies they already know so that you can maintain it and extend it internally.
I don’t even have to prove why this is fundamentally wrong, but let’s say that it is analogous to having your graphics designer paint your house.
Your decision on the CMS platform you should use for your site is not an easy one, and it should not be left in the hands of the agency you intend to hire just because “that’s what they’re working with”. It’s easy to be impressed with the design and visuals and forget there’s an “engine” that powers your website behind the scenes, but that engine is the most important aspect of the whole construct since it’s the one that will restrict you or enable you to do more when that time comes.
You should have a long-term plan about how you want your web site to evolve, what you expect it to cost you in a specific period of time and how you are going to tackle challenges like security and extensibility. There is no globally right answer, it all depends on what your own main objectives are.
Being conscious about the technology, the platform, its pros and cons and its features will only benefit you in the long term. If you feel you don’t have the technical knowledge or the time to make such a decision, you should hire an expert consultant who will take all parameters into account and suggest the best platform for your own needs. Whatever you do, though, for heaven’s sake don’t buy a website at the price you would buy a new pair of jeans just because “that’s all you need”. You’ll end up paying for a whole new wardrobe really fast.