Just like those two cars, custom CMS might be similar to Drupal from the outside, but whole difference is in the inside

Drupal after making a jump from a custom CMS

Sometimes I find questions like the following one on Internet forums: “I want to build a website. Should I go with a standard CMS (such as Drupal), or develop a proprietary CMS?” I've been working with a large, custom CMS that was developed for quite a while, as well as in Drupal and I wanted to share my insights.

Reinventing the wheel

The first thing I noticed was the difference in the amount of time and effort spent on rewriting standard solutions. Every website, regardless of how big or small it is, has some recurring elements, that you usually don’t pay any attention to as the user. They are there, in the background. However, that doesn't mean they don't require much work.

Examples of this include adjusting the image on a website to a certain format, sitemap, all kinds of polls and surveys, etc. I could go on for ages. Any such functionality has to be developed, the bugs have to be caught, and unfortunately, some of the bugs are caught only in production.

Even simple changes, like adding a new data format or changing graphic elements can be a challenge in a system written from scratch. You need to remember that developing a new functionality is not only about writing the code, you also have to find all the bugs, aligning everything with the rest of the system and then push it to production, so that it can undergo a trial by fire.

There is a difference between spending a week on writing code that is similar to existing solutions, or simply installing a module, as is the case with Drupal.

I also noticed that in a custom CMS, the amount of work that goes into the administrative interface is far greater than the amount of time devoted to making solutions regarding how the customer/consumer sees the content.

What's more, when developing for Drupal, you can share the results of your work by creating a module and publishing it so that others can use it.


Secondly, I like Drupal's modularity. Our standard modus operandi is to find an existing module or to develop our own, which expands or modifies the operation of the standard module. Drupal's philosophy is to enable easy modification of all elements.

Use the user interface

Additionally, it is surprising how much can be done in Drupal without writing even a single line of code in the editor, using the Drupal menu instead.

For example, we created Droopler – a Drupal distribution at our company, allowing users to quickly create professional-looking websites. I worked on developing the interface for creating a blog. Apart from styling, almost all functionality, including the administrative interface, has been created by clicking the appropriate settings in the Drupal menu (the main page and subpages with posts, content addition interface, paragraph types and image formats, creation date, entry categories, etc...).


The problem with custom Content Management Systems is a mosaic of solutions, which can be found there. For example, it may happen that the code for a certain functionality was written by a person who has moved on to another company and nobody in the company fully understands the solution. In Drupal, this is minimised to a certain extent, because we use standard functions to modify, we have specific data structures, ways of saving configurations, and so on. This allows me to know that the other person uses the same standards and it is easier for me to understand the code. In addition, it is easier to maintain order in the code and limit the occurrences of the so-called “spaghetti code.”

In Drupal, the main data structures are well-thought-out, proven and there is no need to reinvent the wheel.

Bugs are an entirely separate issue. Almost every bug in a custom CMS means trouble. With Drupal, you can be sure that somebody already solved the problems that you’re dealing with.


Well, we’ve got to the main point – the community. Drupal is an open source project and has a vibrant community. The project is being developed not only by private individuals but also by companies using Drupal. Thanks to this, a variety of modules, a wealth of additional materials, solutions to common problems, regular meetings around the world, rich literature and online courses are available at your fingertips.

Cons of Drupal

I have focused on the advantages, but that doesn't mean that Drupal has no limitations or cons. For example... Drupal is a powerful system, each thing can be done in several ways. If you want to change an item on a page, you can use several different methods: create a block, modify the data using one of the several possible hook functions, or maybe change the skin. This can be problematic if you modify an existing codebase, because the line you are looking for, which is responsible for the appearance of a given item, can be in so many different places.

Sometimes you might encounter constraints that you would never expect to find. One such example is the fact that by default, the option to select several items in the list does not offer you the possibility of selecting them on several pages.

Drupal also has its own specific style, which is why you need to spend some time learning it. It is not possible to start a large project by knowing only PHP or by having little experience with other frameworks. You need to learn where and when to change the code, how to best modify the data, get to know the data structures, internal API.


To sum up, if I were to compare my work to a custom CMS with that in Drupal, Drupal wins. Thousands of expandable modules, well-thought-out data structures, standards, and the number of materials and documentation make it possible, after a certain period of learning, to solve tasks efficiently and productively and to create excellent software.

3. Best practices for software development teams