CMS Battles: Drupal vs. Joomla

What is the difference between Drupal and Joomla?

If you read other blog articles about the difference, they often cite Joomla as some middle ground between WordPress and Drupal. People look to WordPress as an easy introduction to CMSs, good for small businesses; and, there seems to be agreement among blog authors that Drupal is more powerful and more flexible, but has a steep learning curve.

Most of these blog authors come to the conclusion that since Joomla offers you some of the flexibility and functionality that Drupal offers but with an easier learning curve, it has benefits for developers or companies to leverage the best of both worlds – that it is something that is out of the box pretty usable and feature-rich, that can handle large volumes of content easily with stability and scalability. As an experienced user of both Drupal and Joomla, I would have to slightly disagree with the suggestion that Joomla is a good middle ground when you want a more powerful platform for your CMS but you don’t want to try to handle the awesome weight of learning Drupal.

I would tend to lean more towards the argument that while Joomla can do lots of the things that Drupal can do when it comes to supporting a larger website and customizing the normal core functionality of the platform and various extensions, Drupal just seems to do all of this much, much better and seems to be way more thought out in its implementation. And in the end, if you are wanting an enterprise-class website, don’t you want a website that is built on a better platform all around?

User Interface

So, the first place that we will look at is the user interface and I will have to say that if we were talking 5 years ago or so, I would probably give this nod to Joomla for the simple reason that when you got logged into the admin side of things, you would be directed to a pretty control panel complete with big icons for your main functions of building articles and managing menus, etc. Overall, the User Interface (UI) was just prettier and easier to find the basic stuff than Drupal.

Now, the reason I said it was this way is because of the huge changes that Drupal made to version 7 of its platform. With an administration toolbar menu built into the top of the site when logged in as an administrator and lots more contextual menus and shortcuts to most common functions, the UI for Drupal has really come a long way. Now, Drupal doesn’t automatically take you to a clean and polished dashboard on login, but it definitely organizes things well in the admin menu and is pretty intuitive when it comes to what you are trying to do: organizing the adding of content, the building of the structure of content and the appearance, and general configuration of the site.

A couple of other aspects of the user interface that I want to point out. One is the fact that the admin side of things and the front-end presentation to the end user are completely separate areas of the site in Joomla, where Drupal is basically always showing you the front-end site with lots of ways contextually to edit and administer particular sections and functionality depending on where you are and what permission your user has.

In contrast, you can log in to the front end of the Joomla site with an administrative user but you are presented with way fewer options to do anything administratively. I will leave that up to you as to which you think is better. Another difference out of the box is how you add pieces of content to a menu. For Drupal, this seems much easier to me as you can decide if the content will be in a menu right when you are creating the content. There is a place to adjust the menu title and which menu it will appear and the sorting right on the edit page. For Joomla, this is a 2 step process of creating the article and then creating the menu item that goes with it.

I will also note that the next iteration of – Drupal: D8 – will come with the core functionality of a WYSIWYG Editor (this was always available as a contributed module before D8) and support for Inline Editing of the content so that you can edit a page’s content on the fly and see exactly how the content will look next to all the other contextual content on the page.

Flexibility

One of the big items that Drupal does very very well out of the box is how you can customize the types of content that you plan on using within your site. On a clean install, you get a basic page content type, an article content type, and the ability to build as many other types of content as you want on the site. As well, you can build all kinds of different fields that your content type will ever need to display within the site. Whether they be some “event” type that will get dates and location data or “gallery” type content that would include media type fields, basically anything is possible with how Drupal builds things.

Drupal gives you the tools to do whatever you want with your site, lets you decide how you want to build it, and gives you tons of configuration forms to really fine-tune how each aspect of it works. For example, take the aforementioned content types. You can not only decide what fields you want to collect data for each type, but you can fine-tune how each field is displayed for editing and displayed to the front-end user. On top of this, there are repeatable view modes for which you can decide which of these fields will be displayed for a content type within different contexts across the site.

Some of this content creation ability is available from contributed extensions on the Joomla side of things, but you won’t get the level of fine-tuning and flexibility that Drupal comes with out of the box. And, when you start to explore the Drupal community and the contributed modules that can extend this functionality, you really start to see some of the big differences in how advanced Drupal is compared to Joomla. To take a look even more at this field ability and view mode concept in Drupal 7, you will find that not only are the content types really configurable but users and taxonomies (tags) also have this same level of flexibility.

The Awesomeness of Views

One more huge difference between Drupal and Joomla that I want to introduce novice users to is one Drupal-contributed module that has been around since Drupal 4. The module is Views, built by a master of Drupal, code-named “merlinofchaos”. In my opinion, it forever sold me on using Drupal for every website I would ever build again. What Views is, is simply a way to build SQL queries of lists of content, and manage how to display that content all on one page of the user interface. And whether you think that is a big deal or not, I have written a thousand SQL queries over the years, and there is a level of complexity and annoying redundancy that comes with that process. The fact that there is such a beautiful piece of front-end interface to manage the building of these queries as well as the display, is just what I think Drupal excels at.

Drupal developers in general, cut to the root core of how can we build something that is slim and flexible, that gives site-builders tons of control over what they want to do. The fact that Views has been around since 2005 (and as of Drupal 8 will be in core) and the fact that I can’t find anything that comes close to this functionality for Joomla, shows just how far along the Drupal ecosystem is in comparison to Joomla development.

Components, Plugins, and Modules, Oh My!

One of the items that didn’t make a whole lot of sense to me back when I was using Joomla all the time – and even now that I have more CMS experience in general – is the way Joomla describes its categorization of extensions to its core functionality. They categorize them as components, plugins, and modules. Here is how Joomla developers themselves make sense of the difference:

• Component – Mini-application to render the main page body.
• Module – Renders small HTML blocks on any page.
• Plugin – Changes code behavior dynamically.

If this makes sense to you, then maybe Joomla is for you – I’m pretty tech-savvy, and at first glance, this makes no sense to me.

Delving a little more deeply, this still seems like some unneeded categorization that would lead to more confusion than would really help developers or site-builders. As a developer in Drupal, there are many times that I want to build an add-on piece of functionality that might span across different aspects of integration into the Drupal ecosystem, and where they might display things to the end user. In the Joomla world, this would require all 3 of these types of extensions to be grouped together – more of a suite of add-ons rather than 1 compact piece of code.

Overriding Core Code

A big thing that both systems have thought about is how to override or extend different aspects of the core functionality of the platform without modifying the actual code. In Joomla, this is supposed to be what the plugins are used for more, and they extend already available Joomla classes to offer the extended functionality. In Drupal, there is a multitude of hooks that are available to override and step into certain aspects of the page build process to alter what happens there.

Both of these systems seem fairly similar overall in what they do. However, when you get into how much you can do, I still will give the nod to Drupal for how deeply you can venture into modifying any of the underlying functionality. This is also true for contributed modules as far as Drupal hooks. For many contributed modules, developers build ways for other developers and modules to hook into their processes, allowing them to alter many many aspects of how things are done.

One other aspect that I will touch on is the overriding of the templating system. In the end, this is responsible for more of the final markup that is produced from the core code and add-ons. In Joomla, this is exclusively the work of template overrides where you basically have to hunt down the right template folders to find the perfect file to override. Then, you still won’t get what you want because you missed 3 other template files to override that are in equally mysterious locations. In Drupal, there are fewer actual locations where templates can reside – thereby reducing confusion, and there are other options for altering the theme layer without templates at all.

Add-Ons and Community Support

The community aspect of any “open-source” project like Joomla or Drupal is super important as to whether you can seriously use it in any kind of real business capacity. It needs to be stable and secure. This means that there are always lots of users and developers looking for security holes and ways of making the end platform more performant, efficient, and better. A good open-source CMS also needs to have many users and developers so it can produce better add-on options to the core functionality of the system.

Both communities of users are diverse and large, however, with 1 million users on Drupal.org, and with close to double the amount of contributed modules available in the community, it is pretty safe to say that the Drupal community is a bit more active. In my opinion, however, the real difference between these communities comes down to something a bit more intrinsic to the community.

Paid Extensions?

When you are looking at the contributed modules list at Drupal.org it is extremely boring. It’s Just lists of text and descriptions. Alternatively, when you are searching for extensions on Joomla, the list of add-ons looks exciting with their awesome polished logo thumbnails and fancy graphics. But why does it look like you are on a shopping site, wading through competing for software ads? Because many times you are.

There are tons of paid extensions available in the Joomla community and then there are free extensions that offer only part of the functionality of their brother’s paid version. There really are free extensions out there, but they aren’t as prevalent as you might think from an open-source community. They are also only available through the developers’ websites. As for Drupal add-ons, they are all free and all housed at Drupal.org for more consistency in delivery and management.

So, which is better?

You make the call. I think a case could be made for paid add-ons being better and – for Joomla in particular – paid add-ons can make a site pretty much ready to go out-of-the-box for a variety of user cases, as long as you’re happy with the default feature sets. But, if you need any modifications to your extension, this could get a little trickier. With paid add-ons, you are a lot more dependent on the extension’s developers, what they will do for you, and how well they will support the code.

With Drupal-contributed modules, there is more of a community that takes part in each module, helping to further each add-on. And as I talked about before, most of these modules have flexibility and customization in mind, so in the end, you can configure way more than most Joomla extensions let you. On top of that, the fact that the community is more focused on helping each other and being more open-source means that you can create your own module fairly easily, enhancing an extension even more than the original developer had thought about, without destroying their work and the updates that will be needed for their module. You can then contribute your new module or patch back to the community which allows the cycle of support and growth to continue.

I personally like the way the Drupal community works much better. In the Drupal community, there is more of a “work together” attitude that exemplifies what open-source is all about. We are all striving to make the product better together, contributing patches and support to each other more than a particular paid service might require.

Competition Between Add-ons

As a general rule for the Drupal community and how contributed modules are managed, there is a convergence of modules that occurs on Drupal.org that really couldn’t happen within a paid community. For example, if two modules crop up that have overlapping functionality, through collaboration and observation of how people are using them, a coalescence occurs that weeds out duplicate functionality in favor of a better module that includes parts from both. If you think about this in a paid community, this incentive would be missing as it would possibly cut out your own income from the add-on.

In the end, in my opinion, the Drupal community feels more like an ecosystem that works well together and creates code that works well with each other. In Joomla, it just feels more fractured and not as cohesive when it comes to what I would think a truly open-source project needs behind it for longevity and sustainability.

Conclusion

I hope I’ve brought up a few things that can help someone with a decision on which platform to use. Personally, I am a little biased as I have been working with Drupal pretty much exclusively for the past 5 years or so. However, I definitely gave Joomla a pretty good go-around before deciding on Drupal years back.

Frankly, Drupal is just built the way I like things to be built. I like knowing that pretty much anything is possible with the platform I am using if I just spend a little bit of time learning how I can accomplish it. I don’t necessarily like being dependent on other developers and how they want to support their paid software.