Joomla vs. Drupal — A Comprehensive Comparison

By Justin Kerr
March 15, 2014

Table of Contents

Drupal (www.drupal.org) and Joomla!™ (www.joomla.org) are two of the most popular and capable open-source content management systems powering dynamic websites. They share many similarities, including open licenses, strong developer communities, growing market share and a predisposition for LAMP-based (Linux, Apache, MySQL, PHP) hosting environments. Both systems are also market-proven and flexible, able to deliver content management functionality with ease and support other types of features at varying levels of expense.

These two systems’ value, efficiency and capabilities often make them top choices for organizations seeking a content management system to power a website, as well as service providers looking to standardize on a platform to deliver web solutions to clients. However, despite the similarities between Drupal and Joomla, significant differences in their implementation processes, development methods, support requirements and specific feature implementation costs may make one or the other more suited to a specific set of needs.

This article provides comprehensive information about the differences between Drupal and Joomla for common website development processes and costs. This information is meant for system implementers, IT department heads, creative agency owners, multimedia department leads and website stakeholders who are faced with a choice between Drupal and Joomla. Reading this article should result in better understanding of the differences between these two content management systems and provide the ability to make an informed decision on which to use to best meet specific project scenarios.

Methods of Comparing Content Management Systems

One of the biggest challenges in comparing two full-featured content management systems is the number of internal and outside variables which can affect project costs and implementation processes, ranging from special project requirements to the expertise of the practitioner to the business and technical environments into which the CMS is deployed. In addition, one system may be innately better suited than the other to handle a particular site requirement, even though both may be capable of supporting it.

Establishing a means of comparing two content management systems requires a deep familiarity with both platforms, experience with multiple deployments across a range of project needs and special requirements, and established expertise in the general processes of developing and deploying websites and web applications. In addition, common metrics must be employed for both systems, and innate differences between the two CMSs may result in skewed results for some projects with special requirements. Finally, understanding how a particular CMS can fit into the context of a project can go a long ways toward effectively managing integration costs, support and ongoing maintenance.

Existing Drupal-Joomla Comparisons

This article is not the first effort to compare Drupal and Joomla. A number of other resources, articles and an event have explored the differences between the two CMS platforms (as well as the WordPress blogging platform). Some of the more notable comparisons include the following:

Many other examples of Drupal/Joomla comparisons can be found online through reference and search sites.

Our Method of Comparing Drupal and Joomla

Many existing Drupal/Joomla comparisons work from a novice’s perspective and end up misrepresenting the real costs of CMS development due to a lack of experience in the best practices for a particular platform. For this article, we leverage our deep exposure to both Drupal and Joomla to mitigate inaccurate conclusions caused by a lack of understanding of platform development processes, poor choices in “plug-in” software to extend CMS capabilities, and similar novice mistakes. Throughout this text, we assume an expert level of literacy for both Drupal and Joomla, which allows for more accurate conclusions when making comparisons between the two.

Another challenge in making Drupal/Joomla comparisons is the vast variety of needs found across different types of website projects: Making apples-to-apples comparisons is very difficult in light of realistic project and deployment environments. For this article, we break down the web development process into common project processes, and conduct our comparisons within these areas, helping readers to understand the benefits and costs of each CMS platform for a particular task or project phase.

For all metrics presented in this article, we use estimated “person hours” to provide a relative scale for measuring costs between processes and tasks. An hourly metric makes more sense than a cash amount, since different organizations will use different rates for evaluating project costs. As mentioned before, all estimates assume an expert level of knowledge and experience with both content management systems, with no time dedicated to discovering platform capabilities, learning best practices or training.

Both Drupal and Joomla have developed through several major versions over the course of many years. Unless otherwise noted, references to CMS capabilities and details relate to the most recent, stable, long-term-support releases of this software: Drupal 7 and Joomla 2.5, respectively.

Comparing Common Website Development Processes and Costs

This comparison of website development processes and costs between Drupal and Joomla breaks down the site built-out process into a number of tasks or project phases. Some of these will be integral to every site buildout; some are applicable only to specific types of websites.


Every web project requires a number of essential project elements to be in place before development begins. Although all of these items are independent of the choice between Drupal and Joomla, they are intimately tied to the success or failure of a project. Note that each of the following is a topic unto itself and will not be addressed in detail here:

Understanding Project Requirements

The requirements of a given project outline exactly what the website solution must accomplish. These requirements should be as specific as possible in order to provide scope for the work to be conducted and to detail exactly what the solution must deliver. Having a written, properly scoped and developed set of requirements is essential to delivering a successful CMS project.

Understanding Web Development Processes

Experience and expertise in developing and deploying CMS (and other web application) solutions goes a long way toward delivering projects on-time and on-budget. The processes of setting up and using development, sandbox and production servers; establishing software design standards and syntax; working with version-control software; project managing web deployments; and handling software development lifecycle management all benefit greatly from previous experience.

Lining Up the Basics

Every content management system project has a number of non-platform elements which are essential parts of constructing the website: Without these elements, site buildout simply can’t happen. They include things like:

  • Content (text, images, multimedia, etc.)

  • One or more website designs and optimized HTML/CSS template frameworks to support them
     
  • Use case modeling for website interactive features
     
  • An established strategy for online media, including organizational goals, anticipated return on investment, mobile-specific strategy (and the features to support it), etc.

These basic elements are required not only for an advanced CMS project; they are essential parts of building any website.

Acquiring Platform Expertise

Fluency in either CMS platform is a necessity in order to accurately predict project costs and schedules. Any needed platform learning represents a big unknown, as the practitioner discovers and then tests various implementation and configuration options in a quest to establish best practices. This makes it very difficult to accurately estimate project costs and timetables.

The difference in learning curves between Drupal and Joomla is noteworthy. Although both continue to become easier to use and deploy, Drupal carries a much bigger up-front commitment to learning the platform’s technical details in order to effectively build Drupal sites. In contrast, Joomla provides a lot of plug-and-play, off-the-shelf functionality from the moment of installation, and it’s much easier to get basic results faster.


Hosting Environment Setup and Configuration 

Building out a web hosting environment may involve a number of tasks related to hardware selection and configuration, base OS and web server software installation and configuration, network setup, and similar data center or server configuration work. Experienced admins employ knowledge and makefiles to quickly execute these common tasks. Another common scenario is working with an established web hosting provider’s preconfigured web hosting environment, where little to no server configuration work is required. For both types of general deployments, little difference exists between Drupal and Joomla.

Drupal iconDrupal

Drupal runs well on properly configured commodity hosting services, as well as bespoke server deployments, much the same as Joomla. However, unlike Joomla, Drupal includes in-built functionality for load balancing across servers, as well as support for “multi-site” capabilities: Projects that require these features will find them more efficiently implemented in Drupal than in Joomla.

Joomla iconJoomla

Joomla runs well on contemporary, standardized hosting configurations from both hosting companies and custom builders, using recent versions of Apache and PHP. The Suhosin patch for PHP is a helpful server feature which may require implementation, if it’s not already enabled. (A “Joomla ready” host will already have addressed this.)

Dollar sign iconCost Conclusions

For many projects, hosting environment setup and configuration costs are effectively the same for Drupal and Joomla projects: a minor task that can take from one to a couple hours, or much less for experienced admins. However, for large-scale websites that require load balancing across servers, as well as projects that must support multi-site capabilities, Drupal may require less time for server planning, setup and deployment.

Development Environment Setup and Configuration

Effective build-out and deployment of a CMS-powered website benefits from established development practices, including setup of development and testing servers, version control systems, project management support, and quality assurance processes. Specific setup needs will vary by the scale and complexity of the CMS project, as well as the size of the team working on it.

All of these systems and processes are independent of the web project they’re set up to support: The same development processes and tools are equally applicable to similar Drupal and Joomla projects. (Of course, development teams will all have their own preferences and toolsets for getting things done.)

Dollar sign iconCost Conclusions

As development tools and processes are independent of the CMS platform, there is no significant difference in the cost of development environment setup and configuration for Drupal and Joomla sites of similar scope and complexity.

CMS Installation and Initial Configuration

Installing the base CMS in a qualified web hosting environment is a straightforward process for both Drupal and Joomla: Upload files to your hosting environment, set up a database for the CMS to use, then visit a specific URL at the install location and walk through a series of step-by-step configurations, presented through forms and control panels. Once installation is complete, a “default” version of the CMS is available at the install location, and from there, it can be further configured, customized and populated with content.

Drupal iconDrupal

Drupal installation requires some minor server-side manipulation of file permissions and file names; from there, the process is very similar to a Joomla installation. Initial Drupal configuration settings are implemented via control panels and include things like front page designation, cache settings and basic site information.

Upon completion, the default Drupal installation is very sparse, a characteristic of Drupal’s design as a framework upon which content types are built.

Joomla iconJoomla

Joomla installation is very fast and straightforward within a qualified web hosting environment, and nearly all steps take place within Joomla’s step-by-step installation process (which has become very streamlined in the latest Joomla 3 release). Successful installation yields a default version of both the front end (user-facing) and back end (administrative) sides of Joomla. In addition, Joomla provides options for publishing demo content as part of the installation process, which yields complete example sites from which implementers can work.

Dollar sign iconCost Conclusions

As the process of implementing a base installation of the CMS is so similar between Drupal and Joomla, the time required is essentially the same: perhaps one to two hours of work, much less for experienced admins.


Content Types and Structures

Proper construction of a site’s architecture and content structures yields not only a fertile base from which to launch a site, but also a stable, versatile platform for continued growth of site content. Implementation of content types and structures includes setting out the nature of the content the site is to display, as well as creating the hierarchical structures used to organize and display that content.

This process is one of the first areas where significant differences in approach, capabilities and costs appear when comparing Drupal and Joomla content management systems.

Drupal iconDrupal

In Drupal, site structures are planned and built from scratch using special sets of tools and conventions. Drupal’s site structures require significant work and expertise to implement properly, but they can support very high versatility, many different use cases, and extremely complex site architectures.

One characteristic of Drupal’s approach to structuring content is the requirement that the implementer define the different types of content that appear in the site. Building a Drupal “Content Type” requires selecting and ordering a set of Fields for that Content Type, as well as defining other parameters about how that type of content is accessed and presented. Each individual item of content in the site (which Drupal calls a “Node”) must be built within a defined Content Type.

Drupal organizes collections of Nodes through custom tagging processes called Vocabularies. A Vocabulary is a collection of terms defined by the site implementer: The terms within a Vocabulary can be organized with a flat structure, a parent-child hierarchy, or defined in an ad hoc manner as content items are entered into the system. Vocabularies are then associated with Content Types through a special Field type. A Drupal site can have multiple Vocabularies, and more than one Vocabulary can be applied to a single Content Type. Developer-defined “Taxonomy” and “Views” settings lay out the parameters by which Node content is collected and displayed; these elements can then be associated with menu items or other interface elements to help determine which content is displayed to the end user.

Drupal 7 offers a further layer of structural abstraction via Entities: a set of extensible, base classes for primary types of content (e.g. Node, user, comment), which can then be customized further via Bundles, which are extensions of a base entity class. Among other things, Drupal Entities provides the ability to implement custom fields – and field-tied capabilities – for all content and system objects, providing even more flexibility for site architects and implementers. 

Through the process of defining Content Types, Vocabularies, Taxonomy and Entities, the Drupal site implementer enjoys a tremendous amount of flexibility in structuring the site’s content items and organization: In fact, this process provides more than enough rope with which inexperienced implementers can hang themselves. Proper planning is essential for project success, and a good deal of time may be required to figure out the best way that Drupal’s organizational structures can support project goals, especially for complex websites.

Joomla iconJoomla

Out of the box, Joomla includes several “core” types of content that a site implementer can immediately use; these include Articles (Joomla’s default for a general web page), Banners, Contacts, Newsfeeds and Weblinks. Each of Joomla’s core content types contains capabilities and settings supporting that specific type of use, and they are all available as soon as Joomla is installed.

Joomla uses a nested category/sub-category hierarchy as the default method for organizing its content. A single content item can reside at any level of a Joomla category tree (or it can remain as “uncategorized”), and it can only reside in one location at a time. Joomla supports an unlimited number of category/subcategory levels, and categories can have their own extra data and features associated with them.

Third-party software extensions are used to support non-core content types for Joomla, and nearly every type of need for this is met through Joomla’s expansive software ecosystem (headquartered at the Joomla Extension Directory). For those who need completely custom content types, several third-party Content Construction Kit (or CCK) extensions are available for installation into Joomla. Likewise, for projects where content items must reside in multiple categories, third-party tagging extensions are required to add this functionality to Joomla. (Content tagging is available as a core feature in Joomla 3.)

Dollar sign iconCost Conclusions

Joomla’s default support for basic content types and a structural hierarchy makes it much faster and less expensive to implement structured site content. Most Joomla sites employ its general-purpose Article content type as the main method for containing web page content, and use the default categories/subcategories system to keep things organized. In contrast, Drupal sites require implementers to plan and create content types first before meaningful content build-out can begin. (Note that Drupal 7 does ship with a couple very basic content types.) This process takes at least a handful of hours; much longer for sites with specialized content items and complex content relationships. In general, Drupal’s site structural build-out will take at least 50 percent more time than conducting the equivalent work on Joomla sites.

That being said, certain types of complex projects and site requirements may even out the costs: For example, if a site requires multi-categorization of content, or specific, custom content types, the process of installing and configuring the required third-party Joomla extensions can escalate to the work required for content structuring and organization in Drupal.

A much higher level of experience and expertise is required to properly manage Drupal’s implementation of content characteristics and structure than using Joomla’s default methods.

Site Navigation

Website navigation elements in a content management system typically consist of menus, comprised of individual menu items. Both Drupal and Joomla follow this convention, with the ability to support multiple site menus in a variety of configurations. Both Drupal and Joomla also benefit from third-party developers who supply additional, plug-in software that can enhance the appearance and behavior of menus.

Drupal iconDrupal

Drupal controls site menus via its Menu Module, which allows for creation, editing and deletion of menus on the site (as well as providing a “Block” which can then be associated with a Drupal theme’s “Region,” or layout area). In order for a menu to contain a link pointing toward internal site content, that menu must be associated with the particular Content Type of the targeted page.

New menu items can be added from a Node’s edit screen (so that the Node becomes the menu link’s target); or directly from a menu itself, which requires input of a target path using Drupal-specific syntax. Menu items can be reordered within a menu, but not moved from one menu to another.

Joomla iconJoomla

Joomla’s Menu Manager lets implementers create, edit and delete menus, as well as control the items within a particular menu. When creating a new menu item, Joomla first requires selection of the type of content toward which the menu item points (be this Joomla Articles, Contacts, Weblinks, or a non-core content type supported through a third-party extension). Once the destination type of content is defined, additional parameters for that menu item allow for control over further display options and more specific targeting of content. Menus are placed on the page by associating a menu with a Joomla Module, then placing that module into a layout Position as determined by the relevant Joomla template. In Joomla, menu items can be rearranged and moved from one menu to another.

Dollar sign iconCost Conclusions

The processes of building menus and configuring menu items are mature and well-supported in both Drupal and Joomla, and do not require excessive labor. It may take slightly longer to implement menus in Drupal, but the time expense is still nominal for both (assuming, of course, that other project elements are also implemented with competence).


Site Design and Layout

Both Drupal and Joomla contain systems for managing the layout of site elements, as well as implementing completely custom web designs. The two systems’ support for this shares some common characteristics, including the availability of multiple default, pre-built designs; design controls built into easy-to-use control panels; multiple designs supported per website; a way to override the default HTML output; an emphasis on separating presentation from content; and a third-party design ecosystem that provides a wide variety of plug-in design options.

Drupal iconDrupal

Drupal uses “Themes” to customize a website’s design and layout through conventions and processes focused around discrete sets of files in a Drupal installation. By default, Drupal ships with four in-built Themes, any of which can be extended or customized by spawning off a copy, registering the copy within Drupal under a new system name, and then adjusting CSS files and template files (named with *.tpl.php file name extensions in Drupal). A top-level *.info file declares the Theme within Drupal; references css, Javascript and other files used within the Theme; and defines page layout areas, which Drupal calls “Regions.”

Drupal’s HTML page structure is built from nested collections of code from a Theme’s *.tpl.php files, each focusing on successively more specific parts of the page design. A Theme’s layout Regions are used to contain Drupal “Blocks,” which can contain Module output, custom Views, or custom content. Block configuration options allow for selective display on site pages and for specific user Roles; custom PHP code can also be used to dictate the conditions of block display and control how the output renders.

“Sub-Themes” in Drupal hook into an existing, active Theme and inherit all of its characteristics, unless more specific CSS or *.tpl.php files in the Sub-Theme override those in the parent Theme. Likewise, *.tpl.php files in any Drupal theme are automatically sensed by Drupal and used to override the system’s default HTML output. 

Drupal Themes can also be set up to override PHP functions (especially display-related functions) elsewhere in Drupal. It is an established best practice to contain all such code in the topmost PHP file for the Theme, as well as ensure that all custom PHP code is properly secured against malicious activity. Depending on the Theme and the design needs for the site, a significant amount of PHP development may be required to enable specific design options and content behavior.

Drupal Themes can be built to include control panel-based settings for adjusting Theme graphics, colors, site titles, layout and other elements. Configuring how these controls work may require significant PHP development time; advanced implementations are a common feature found in many third-party Drupal Themes.

A Drupal Module called Panels provides additional options for layout control. Panels consists of a drag-and-drop content manager that allows for visual layout design: This can be integrated to work with specific Nodes, landing pages, specific permissions settings and developer-created “Views” of content. Some limitations to using Panels include the somewhat messy HTML code it creates, and some conflicts with Javascript-heavy elements (such as third-party WYSIWYG editors) placed inside Panels. Panels can also contain their own presentation logic, adding another level of control to content presentation or user access, as well as advanced caching controls to tune site performance.

Joomla iconJoomla

Joomla uses “Templates” to control site design and layout, and includes three front-end Templates and two back-end (administrative area) Templates as part of its standard installation. A Joomla site implementer controls Template choice and parameters through Joomla’s “Template Manager” control panels, accessed through the back end of the Joomla site. A default “Template Style” is selected for the site’s front-end display, and another for the site’s back-end display. For sites that require multiple web designs for different site areas, additional Template Styles are assigned to the Joomla menu items that point to those site areas.

Joomla Templates consist of collections of files stored within the Joomla installation and registered with the Joomla system. At its most basic level, a Joomla Template consists of an index.php file that establishes the primary structure of the web page, and an XML file which contains Template meta information, including a list of the named “Positions” used by that Joomla Template to lay out various site elements on the page. Other Template files (CSS, Javascript, images, etc.) are pulled into the design via standard HTML syntax – augmented with PHP code – in the index.php file.

Joomla Templates can be constructed to contain any number of parameters – such as color, font choice, or layout options – which are then adjusted through control panels in the Template Manager. Each saved iteration of a Joomla Template becomes a Template Style, with its own specific parameter settings: One core Joomla Template may power multiple Template Styles in a site, and depending on the supported Template parameters, each Template Style can support significantly different designs and layouts.

Precise control over Joomla’s HTML output for system elements (like the “Component” output that generates main page content, or the “Module” output for things like menus and login boxes) comes through an HTML override system that exploits Joomla’s Model-View-Controller software architecture. Developers override Joomla’s default system HTML output by copying system PHP files into specifically named locations within a Template’s folder hierarchy, then adjusting the code accordingly. Joomla automatically detects the presence of the override file and employs it instead of the default system file.

Installation of a Joomla Template is a one-click process that consists of uploading a specially formatted .zip file containing all Template files and information. Once on the server, any changes made to a Template’s files are automatically detected and applied to site display. A large number of third-party Template developers provide a massive choice in pre-built Joomla templates, some of which contain very sophisticated controls for managing site presentation and layout.

The Joomla project is standardizing on the Twitter Bootstrap framework as of the Joomla 3 short-term support release. Joomla’s inclusion of Bootstrap libraries by default is primarily meant to support consistent presentation of back-end admin interfaces, however, it is also available to front-end template developers who wish to leverage the framework.

Dollar sign iconCost Conclusions

Although both Drupal and Joomla include highly capable systems for managing site design and layout, Joomla’s in-built capabilities and standards result in a templating method that makes it easier and faster to implement bespoke website designs. (Indeed, Joomla’s templating system is unmatched by any other open-source CMS with which we are familiar.) Depending on design and capability requirements, it may take up to 50 percent more development time to implement a web design and layout in Drupal than in Joomla. Part of this stems from Drupal’s requirements for specific configuration work tying together its Modules, Blocks and Regions.

Overall, the market for third-party designs is larger for Joomla than it is for Drupal, resulting in a greater number of choices for those who wish to implement a plug-and-play site design. This may be a result of Joomla’s market ecosystem, which supports both free and commercial third-party add-ons, whereas Drupal tends to focus more on community development and sharing of freely available resources.


Editorial Tools

A content management system’s editorial tools support publishing and managing content; they can include tools that directly enable content formatting, as well as workflows that support the publishing process. Both Drupal and Joomla contain tools and processes for supporting content production, however, each has significant gaps which must be filled by non-core software solutions.

Drupal iconDrupal

One of Drupal’s primary advantages in managing content is its in-built systemic capabilities to keep track of the saved versions of content as that content is edited and pushed through the publishing process. Drupal can keep track of the changes made to its Nodes (or content items), making it easier for developers to enable versioning capabilities. Drupal includes some basic workflow controls, however, sophisticated workflows require custom development and/or third-party software. Drupal does offer some basic controls for scheduling content publication, but advanced needs will require additional software or development work.

A common complaint about Drupal’s default editorial capabilities is the lack of a WYSIWYG (What-You-See-Is-What-You-Get) editor: a set of content formatting controls similar to those offered by a word processing program. By default, Drupal uses plain text areas for composing and editing content, however, third-party WYSIWYG capabilities can be enabled in Drupal through the application of extra software and configuration work. Other aspects of working with content in a Drupal installation also require installation and configuration of additional software, including server-side image editing, file management and email notifications of changes to content.

It’s worthwhile to note the growing presence of Drupal “distros” – pre-formatted Drupal installations tailored toward the needs of a specific vertical market (for example, the publishing industry). Some Drupal distros will ship with many of these editorial controls already installed and configured for use.

Joomla iconJoomla

Joomla has only recently added content versioning as of their 3.2 release, in winter 2013: The Joomla 2.5 series does not include native content versioning, so enabling this requires installation and configuration of third-party software, which provides basic content versioning. Although Joomla does contain some workflow control capabilities (through its users and permissions system), it does not natively support sophisticated workflows as may be required by publishing operations. Some basic third-party workflow software is available for installation into Joomla, but precise workflow requirements and controls will undoubtedly require custom development.

Joomla natively includes many tools for formatting and managing content. Control panels associated with content items allow for scheduling content expiry and embargoing, as well as the ability to selectively show or hide content item elements (such as titles, bylines, publication dates, intro text, etc.). Joomla also natively ships with a couple different WYSIWYG editor options, however, many developers choose to install and enable a more sophisticated third-party WYSIWYG editor instead. Joomla’s native “Media Manager” area functions as a primary way to manage file uploading and storage.

Third-party extensions for Joomla are required for managing special content types, such as photo galleries or document repositories, and numerous robust options accommodate nearly any content publishing scenario. Readily available third-party software is also required for server-side content manipulation, such as live editing of images within the Joomla installation.

Dollar sign iconCost Conclusions

By default, Joomla includes more in-built editorial tools and controls than Drupal, including a native WYSIWYG editor, scheduling controls and interfaces for managing the presence of content item elements. Although all of these elements can be enabled in Drupal through third-party software and custom development, Joomla’s nature is to expose more of these controls to content producers, whereas Drupal is more likely to only expose those options that have been configured by the Drupal developer to do so. For primary content formatting needs, Joomla offers more tools and options by default.

Drupal shines over Joomla in its native capabilities to handle content versioning. In addition, Drupal also offers greater potential capabilities than Joomla for enabling complex and custom editorial workflows (even though this still requires significant custom configuration and development in Drupal).

Rich Media Support

Rich media consists of video, Flash, audio, image galleries or other non-text elements within web page content. Both Drupal and Joomla support rich media display through the installation and configuration of additional third party software.

Drupal iconDrupal

Drupal requires non-native software in order to easily support rich media display. This is commonly implemented as a special Field type which is then associated with one of Drupal’s custom-configured Content Types. The Drupal developer implements rich media support by integrating rich media Fields, configuring their options and then exposing them to content producers. Some full-blown Drupal Modules also support publication and management of rich media content.

Joomla iconJoomla

Joomla can support rich media display through the installation and configuration of third-party extension software. This ranges from full-blown Joomla “Components” that provide advanced tools and configuration options for rich media management and display, to plugin-style controls that enable a rich media element to be quickly dropped into existing content.

Dollar sign iconCost Conclusions

Both Drupal and Joomla require third- party extension software to support the easy display and publication of rich media elements. Joomla tends to provide discrete tools which handle fast and/or full-featured presentation and management of rich media content: Drop in the Joomla extension, and rich media capabilities (and their configuration options) are immediately available to content producers. In contrast, Drupal tends to approach rich media through integrating new capabilities into existing content architecture, and having the developer specifically configure a more limited set of options to expose to content producers while setting across-the-board defaults for display. Because of this, enabling rich media support in Drupal tends to take more development time than in Joomla, but interface controls can be extremely streamlined and customized for specific production needs.


Social Media Features

Use and integration of social media channels such as Twitter, Facebook and LinkedIn have become critical elements of successful web site marketing initiatives. Integrating social media into a CMS-powered website ranges from simple social media page links to interactive elements that share content and features between the CMS site and the external social media account.

Both Drupal and Joomla rely upon similar methods for social media integration, primarily installation of third-party software that enables various social media features. Links to social media pages can be integrated at the web page template level, or implemented through an installed third-party software package. Sharing services/links, social media voting, and content and feature sharing are likewise implemented through third- party software packages.

Dollar sign iconCost Conclusions

Given similar implementation methods and choice of third-party software available for implementing social media features on both Drupal and Joomla sites, the costs are essentially the same.

SEO Support

Search engine optimization (or SEO)  is the process of configuring website structure and elements to best sync with the methods that search engines like Google use to evaluate, index and rank content. Although some aspects of SEO are based on conjecture surrounding engines’ secret algorithms, a number of industry-standard best practices have emerged, including use of HTML header, title and meta tags; source ordering of HTML content; file naming conventions; implementation of search-engine friendly (SEF) URLs; use of sitemaps and webmaster tools; and shunning duplicate content. (See our SEO fundamentals blog post for more information.)

Both Drupal and Joomla include significant support for SEO features, however, each implements them in very different ways.

Drupal iconDrupal

Drupal’s SEO support can be significant, and it requires planning and implementation by the Drupal developer. Web page meta tags – such as Keywords and Description – are enabled as specific custom Fields attached to a Drupal Content Type: The Drupal implementer sets up this framework, and the content producer can fill out the fields as part of the process of creating new content; similar methods can be used to customize web page Title tags.

Source ordering of content and application of HTML header tags ties into how the developer designs and structures the site’s Theme that renders and lays out web page content. For sitemaps, a Drupal developer can turn to readily available third-party Modules, or develop their own implementation.

Some level of SEF URLs are supported by Drupal’s “Clean URLs” setting, which removes nonsensical code markup from URLs by leveraging the Apache web server’s mod_rewrite component and using an .htaccess file within the Drupal installation. However, this still may result in URLs with non-ideal syntax, containing Drupal-specific semantics like “node” or identifying numbers. An additional Drupal Module can enable custom, dynamic construction of SEF URLs, however, implementing this properly requires significant planning and configuration in order to integrate with a Drupal site’s Node structure and content hierarchy.

Drupal also includes a general redirect capability to enable custom URLs which point to a different, existing Drupal site URL.

Joomla iconJoomla

Joomla’s native support for SEO is extensive, and it can be further expanded with the installation of third-party software. Joomla’s Global Configuration settings contain options for setting site-wide Keyword and Description meta tags, as well as a switch that turns on SEF URLs for the site’s front end. (Like Drupal, this employs a combination of the Apache Web server’s mod_rewrite component, and an .htaccess file for the site.)

Proper implementation of HTML header tags is closely tied to the active Joomla Template and how content settings are applied in Joomla. By default, Joomla templates will try to properly enclose page titles and content item titles in a cascading series of header tags. However, the WYSIWYG editor provides rope with which a content producer can often hang themselves (as it commonly is configured to allow placement of H1, H2, etc. tags inside content). Similarly, HTML source ordering of page content is closely tied to how the Joomla Template has been constructed.

Joomla includes an “alias” setting for most content items where a practitioner can specify the exact syntax represented by that content element within a Joomla SEF URL. If a content producer does not specify an alias, Joomla builds one automatically based on the title of that element. Joomla then constructs its URLs using these aliases, as well as the aliases of the content’s containing elements, such as Joomla Categories or menu items. A Global Configuration setting allows for default control over filename extensions in the URL (e.g. adding *.html to the URL, or hiding it entirely).

Individual content items in Joomla tend to include their own meta tag parameters, which lets a Joomla practitioner override the site-wide default meta tags with more specific meta tags for that piece of content. Likewise, Joomla content elements commonly include options for specifying the exact HTML page title; a Global Configuration setting controls the default placement of the site name within the HTML page title structure.

Joomla includes a native “Redirect” component which records every instance of a “404 - Page Not Found” error generated by site usage. The Redirect component then lets the Joomla practitioner assign a new URL to any 404 error URLs, and Joomla automatically implements a search-engine friendly “301 - Permanent Redirect” command that points toward the proper URL. Likewise, the Redirect component can be used to create custom redirects, including supporting old URLs which might have changed due to a site upgrade or migration.

Third-party Component extensions that expand Joomla’s feature set (for example, an e-commerce catalog) may or may not support SEF URLs, or they might use different methods for their construction and how they interrelate with other SEF URLs on the site. As mentioned above, some third-party Components are designed to enhance Joomla’s SEO, including more specific control over SEF URLs, automated sitemap generation, keyword weighting analysis, and other SEO tools.

Dollar sign iconCost Conclusions

By default, Joomla contains more robust and easy-to-implement SEO features than Drupal, which requires significant configuration and site-specific development to enable SEO throughout a site, especially for high-quality SEF URLs. However, Joomla practitioners may face similar challenges when working with third-party Component extensions that don’t support SEO features properly or in a way that integrates well with the rest of the Joomla site.

It is worthwhile to note that both Drupal and Joomla suffer from problems related to duplicate content: Because of the Web sites’ dynamic natures, it is often possible to view the same site content at differing URLs. Google and other search engines commonly penalize sites with duplicate content as part of their anti-spam measures.


Site Membership Features

Both Drupal and Joomla include extensive default access and permissions controls to allow site administrators, content producers, and other authorized personnel to log into the website and manipulate content, change configuration settings, add features and conduct other site editing or administrative work. Public-facing site memberships require different approaches for both Drupal and Joomla, at varying cost levels.

Drupal iconDrupal

Custom configuration and development work is a requisite for Drupal sites with public-facing membership features. By default, Drupal installs with two types of user “Roles” available to the system: an anonymous (or public) user role, and an authenticated user role, used to enable Drupal administrative login. A single super administrator account is initially available for site configuration and build-out. A core Users Module enables account signup and login features, and a core Profile Module supports basic user profile pages, as well as a “My Page” feature that lets users edit their own profile information.

Drupal manages site access levels through a system of custom Roles defined by Permissions that tie to allowed behaviour within Modules and other site elements; Roles also tie into display options for Blocks. This system can support completely custom access schema, as well as extremely granular control over user access to content and interactive features. Each Drupal system Module includes its own set of allowed behaviors; changes to a site’s Modules list or Permissions schema often require adjustment of configuration settings for the other set of elements.

Implementation of Drupal membership features is a complicated, custom process that typically requires installation and integration of numerous contributed Modules, each of which enables a specific subset of user or membership capabilities. Drupal offers no standardized process for this: Enabling these features comes down to which collections of Modules and configurations are preferred by the developer, and how that is designed to interact with the site’s architecture. For example, one site’s access control architecture may be designed around user-defined Node access, whereas another site’s access control might be developed to relate to that site’s Taxonomy.

Some recommended approaches include using a specific family of Modules designed to work together to enable membership and community features, as well as numerous developer “recipes” for enabling specific site membership features. In addition, some Drupal distros are designed to support community and/or membership features and come preconfigured with the necessary Modules and configuration settings to support this upon site installation.

Joomla iconJoomla

Joomla includes several in-built features to support site administration and membership options. Upon installation, a single super user account enables login to both Joomla’s publicly facing front end and its administrative back end (in which the bulk of site configuration and build-out occurs). A front-end Joomla Module and native membership capabilities allow for user account signup, confirmation and login; a very basic default profile page lets front-end users manage their account information. On the back end, a user management control panel provides administrative-level account controls, as well as access to settings to enable selective access to content and features.

Joomla employs a system of user Groups and Access Control Levels (ACL) to define who gets access to what on both the front and back end of a Joomla site. Joomla’s user Groups operates as a hierarchical list with deeper nested groups inheriting the capabilities of their parents. By default, Joomla ships with some pre-built user Groups designed to support common site production and membership uses: a hierarchy of Public > Registered > Author > Editor > Publisher focused on front-end usage, and a back-end hierarchy of Manager > Administrator > Superadministrator. Authorized admins can create custom Groups and Group hierarchies from Joomla’s back end control panels.

Groups’ access and capabilities are defined via Joomla Permissions, which are associated with various Joomla Components, Categories and content items, all defined through the back-end administration interface. A common set of Permissions (View, Edit, Delete, Edit Own, etc.) are available throughout core Joomla Components, with varying levels of Permissions supported by third-party software. Permissions can inherit both through the Groups hierarchy and Joomla’s standard Categories hierarchy, down to the individual content item, and Permissions apply to elements on both the front end and back end of the site. There is no granular Permissions integration for elements inside a Joomla content item, however, some basic differentiation is built into Joomla’s front-end content editing process.

Joomla’s ACL relates to the front end of the site, determining which collections of users can view and access front-end content and interface elements. It consists of different, named access levels to which multiple user Groups can be assigned. By default, Joomla ships with four initial Access Control Levels: Public, Registered, Special and Guest, with each level associated with one or more user Groups. User accounts assigned to a Group then receive the ability to view front-end elements assigned with a related ACL setting. Authorized administrators can set up and assign new ACL levels, and and Joomla’s user registration settings can be set to target a specific Group by default upon new user signup.

Joomla’s native membership capabilities do not include many elements required for online communities or paid access services. For these needs, third-party plug-in software extends Joomla to enable things like paid access to content, enhanced user profiles, communication and messaging channels, and community-specific user groups. Available software ranges from small, discrete enhancements for Joomla’s existing membership infrastructure to entire drop-in software suites that automatically enable a wide variety of membership features and include integration with other types of third-party community software.

Dollar sign iconCost Conclusions

Both Drupal and Joomla install by default with extensive capabilities for site administrators to log in and conduct site buildout. However, after this point, the costs for enabling site membership features can vary enormously. 

Drupal requires development time to implement even basic site membership capabilities: Although Drupal includes many of the discrete elements needed to support site memberships, it is up to the developer to knit them together and properly associate them with the particular access and permissions schema for that site. Drupal’s approach supports massively complex and expansive setups for user access, content management capabilities and workflows, with costs for engineering and implementation directly related to the complexity of the membership system. Because Drupal does not offer a standardized method for setting this all up, it may be more difficult for new developers to pick up and work with an existing membership-centric site. Mitigation of some development costs can come through families of third-party Modules designed to work together to enable membership features, as well as entire Drupal distros pre-loaded with a set of ready-to-go membership and community capabilities.

By default, Joomla offers more site membership features than Drupal, including account signup/confirmation/login, basic user profile and account management pages, and Joomla’s Groups/ACL/Permissions schema (with a default configuration to support initial access and content management). This makes it easy to quickly get started with basic membership capabilities. However, special requirements for community, communications or payment features will require third-party extension software, including commercial open source software (although the licensing costs for this are still nominal). Membership-focused Joomla sites may face limitations through imperfect support of Permissions by third-party software, few practical options for implementing custom workflows, and an inability to enable granular Permissions inside of content items.

Site membership cost comparisons between Drupal and Joomla are very closely related to the membership feature requirements for that site. Joomla is a better option for sites with basic membership requirements, or those that fit within Joomla’s native capabilities and/or those of available third-party membership and community packages. Drupal’s membership capabilities can take much longer than Joomla’s to set up, but they offer more customization and workflow options, as well as much more granular permissions. Drupal’s membership schema can also take more time to engineer and plan, due to the many available options and lack of a single standard for implementing membership features.


Support for Mobile Platforms

With mobile Internet usage soon to eclipse that of traditional desktops and laptops, a mobile-friendly version of a website has become a necessity for effective communication and marketing. A leading tactic for enabling mobile capabilities comes via “responsive web design,” whereby a single web template leverages CSS, HTML and Javascript to selectively adjust page layout, sizing and interface elements according to the pixel size and orientation of the viewing device. Both Drupal and Joomla employ similar tactics to support mobile web display, and both suffer from similar problems.

Drupal iconDrupal

The bulk of a Drupal site’s capabilities for mobile support will probably be enabled through a Theme that is optimized for responsive website display: This can be hand-built or acquired from a third-party Theme developer. A couple contributed Drupal Modules also support aspects of mobile website display, including device detection and alternative, mobile-specific Themes, and may be an effective option for a mobile-friendly Drupal site.

Drupal suffers from the problem of non-optimal HTML source code generated from specific Modules: At this point, very little has been optimized for mobile display, so extensive overrides (and possibly some PHP hacking) are needed to mobile-optimize the HTML content that Drupal feeds into the web page output.

Joomla iconJoomla

Similar to Drupal, Joomla tends to enable most of a site’s mobile capabilities through the Template used to render the site design. Many off-the-shelf options and custom design approaches are available, including responsive design capabilities through hand-built or third-party Templates.

Just like Drupal, Joomla also suffers from HTML content that does not necessarily support friendly mobile display options. Joomla’s HTML override system allows for precisely adjusting the output, but this can be a long and tedious process, especially for complex Joomla sites that leverage many third-party software extensions.

Dollar sign iconCost Conclusions

Proper implementation of mobile capabilities in a website is a significant project cost, not only in the practical implementation of responsive web design, but also in the planning required for a successful mobile strategy. That being said, both Drupal and Joomla offer similar capabilities and approaches to mobile support, as well as the same overhead related to overriding default HTML content output with mobile-friendly code. For similar sites with similar requirements, the costs are effectively the same.

E-commerce

A website’s e-commerce features can range from simple integrations with outside payment systems to complex and custom implementations of massive product catalogs, subscription systems and reseller networks. Both Drupal and Joomla rely upon third-party, plug-in solutions for many e-commerce needs, and integration with outside web applications for complex e-commerce deployments.

Drupal iconDrupal

Drupal’s Ubercart system is third-party plug-in software that many sites use to support e-commerce features. Ubercart requires not-inconsiderable development time to configure and implement, however, it offers a fairly full set of features and many options for integration with other parts of the Drupal system, content or data. Ubercart has become the de-facto way that many Drupal developers look to implement e-commerce.

Joomla iconJoomla

Joomla also relies on third-party software to enable e-commerce features, however, the Joomla ecosystem offers a wider variety of plug-in e-commerce software than Drupal, from simple donation buttons that link to a PayPal account to full-blown catalog and shopping cart systems. Although some of Joomla’s e-commerce options may require paid licensing for access to the software, the costs are usually nominal.

Dollar sign iconCost Conclusions

Both Drupal and Joomla tend to solve e-commerce needs by integrating third-party plug-in software. Due to Joomla’s structure and the wide variety of its third-party software options, Joomla tends to require much less time for implementing simple e-commerce features. Third-party software can also enable full shopping cart and online catalog functionality in both Drupal and Joomla, however, Drupal’s Ubercart tends to be more full-featured and capable than any Joomla option for accommodating specific shopping cart and catalog requirements.

Many Joomla and Drupal sites with advanced or complex e-commerce needs will instead integrate an entirely separate e-commerce web application, such as CSCart or Magento, to accommodate the features which are impossible or too expensive to effectively implement within the CMS.


Custom Software Engineering

Software engineering is a discovery, planning and implementation process that includes defining specific project requirements; establishing a plan for software architecture and coding methodologies; and actively managing and assessing the project as the development team builds the solution. Although the relative complexity of a project may tie into the chosen approach, both Drupal and Joomla projects can leverage any popular software development process, from the the waterfall method’s step-by-step progressions, to iterative development styles like the spiral model, to contemporary agile development and rapid prototyping processes. Development strategy may also be determined by things like scheduling demands, the anticipated longevity of the software, and developer preferences. For both Drupal and Joomla, strategies related to software engineering often grow out of the frameworks and standards established by the CMS platform.

Drupal iconDrupal

Drupal’s approach to software engineering ties into its nature as a lattice upon which content types and system capabilities can be built according to specific project requirements. Drupal has a very modular structure, with separate system elements easily able to talk to each other via “hooks” – PHP functions with standardized naming patterns and hook-specific parameters that can tie into user-selected values or those passed from other Modules. Drupal also offers an extensive, documented Application Programming Interface (or API) for all of its major versions, exposing commonly needed and powerful system constants, functions, classes and other resources.

It is noteworthy that Drupal does not formally follow object-oriented software design, or mandate other coding paradigms, although it does establish some standards for code structure and syntax. Indeed, each third-party Module’s developer is free to build their Module-specific code according to the design and syntax patterns they see fit, as long as the Module respects Drupal’s naming and access conventions for hooks, plus some basic guidelines. Even though this sometimes results in non-optimal code, Drupal’s primary Modules – and popular contributed Modules – tend to be well-engineered, having been built and validated by veteran developers.

Drupal provides a full database abstraction layer which enables the same Drupal code to be relevant for any database connected to Drupal, as well as do things like connect to multiple databases at the same time. Drupal provides support for MySQL (Drupal’s most common database), PostgreSQL, SQLite and, through contributed Modules, Microsoft SQL Server and Oracle.

Drupal’s overall structure allows for a great deal of freedom for developers, as well as many potential pitfalls and false paths (which are especially perilous for those new to Drupal development). Knowing the bigger picture behind the software’s purpose – like organizational goals and anticipations about the software’s lifecycle – can help Drupal developers make the right decisions about site architecture and which development paths to pursue.

Joomla iconJoomla

Joomla is unique in the world of open-source content management systems in that it has formally separated all of its CMS-specific code from an underlying base of abstract classes, software libraries and other resources called the Joomla Framework. This future-forward stance can have implications for developers who may wish to implement web application functionality not specifically tied to content management. It is also a hallmark of maturing web software systems, and generally adds a great deal of potential versatility to Joomla.

Object-oriented development is de rigueur for code within the Joomla project and for third-party software extensions. A well-documented schema for universal Model-View-Controller (MVC) development patterns provides both code structure and integration with Joomla system capabilities such as HTML overrides. The Joomla project has also formally adopted specific coding style based on the PEAR Coding Standards, as well as integrated many open-source software libraries into the CMS and Joomla Platform.

Much Joomla development follows well-established and documented processes for creating installable software extensions that can be added to Joomla’s core installation. These extensions take the form of Components, which are akin to discrete Web apps inside Joomla; Modules, which for Joomla means an in-page widget; and Plugins, which are custom actions tied to Joomla system events.

As a practical matter when planning a site’s development, developers may first look to Joomla’s expansive directory of third-party extensions which enable non-core Joomla features and functionality. Much of the time, a third-party extension will accommodate a project need not satisfied by Joomla’s core software. However, most Joomla implementers then live with the conventions, features and configuration options enabled by the third-party developer, even if they don’t meet ideal criteria. PHP developers can certainly customize an extension’s code, but this raises issues for maintenance of the third-party software and working around any original limitations. To accommodate unique project requirements, most Joomla developers write their own extensions for installation into the CMS.

Because of Joomla’s structure and these default development patterns, Joomla’s Components tend to exist within their own silos, only hooking into the CMS as necessary to implement menu items, display extension content, support Permissions/ACL and perhaps integrate with related third-party Modules and Plugins. (Indeed, Joomla Components tend to have their own database tables.) An interesting development in the Joomla software ecosystem is the emergence of extensions middleware that knits together two different third-party extensions for a specific result. Also, many popular Joomla Components now offer their own software development toolkits so that developers can write integration software or plug-ins specifically for that third-party extension.

Joomla can now run on Microsoft SQL Server, in addition to its default, MySQL. Support for PostgreSQL and other databases, as well as a database abstraction features, are planned for future Joomla releases. Joomla does offer robust in-built capabilities for working with database queries and data manipulation.

Dollar sign iconCost Conclusions

Software engineering costs will be directly related to the complexity and scope of the required solution, the rigidity of project requirements, and the platform choice of the developer. There is no doubt that Drupal requires significantly more time for planning and constructing a site that has straightforward content management needs: Joomla’s in-built capabilities, established (and required) structures, and third-party plugins can quickly accommodate a very wide variety of CMS project scenarios.

Where Drupal shines is in its capabilities for specific customization to meet rigid project requirements, support for extremely complex site architectures and functionality, and the capacity to engineer new solutions based on the software that’s already running on the site. Drupal’s system of hooks and other development capabilities require work and experience to leverage effectively, and improper software engineering or 11th-hour project changes can carry very heavy costs. In addition, some developers gripe that the lack of standards and Drupal’s wide-open nature can lead to messy code and other problems.

It’s worthwhile to note the commercial differences between Drupal’s contributed Modules and Joomla’s extensions ecosystem. Whereas Drupal eschews any required monetary payment for its Modules, Joomla is open to the concept of commercial open source, with some third-party extensions carrying subscription, support or other costs (even though these tend to be negligible compared to overall project cost, and the best third-party extensions deliver incredible value versus hand-coding an equivalent solution). Indeed, the Joomla project is changing the licensing terms for the Joomla Framework from GPL to LGPL to allow for broader framework adoption and integration with commercial products and services. The Joomla CMS will remain GPL.


Performance Tuning and Testing

All websites benefit from good performance, which encompasses fast generation of dynamic web pages, efficient HTML, CSS and media assets, and quick delivery to the Web browser. Although performance tuning is essential for large, customer-facing sites, it can be a major boon to any size of website.

Both Drupal and Joomla contain a number of built-in features to aid website performance. However, for general web page efficiency, much depends on outside factors such as the HTML/CSS design of the respective Joomla Template or Drupal Theme. Likewise, the web server and database setup can have a big effect on site performance, especially for large or busy sites with high performance requirements and specialized deployment schema. Proper CMS system architecture can also be important: If too many system elements (e.g. Drupal Modules, Joomla Plugins) are used to build a page, all of the database connections can bog down the server. Finally, integrating a site’s resources with a Content Delivery Network (or CDN) will dramatically improve site performance for any platform.

Drupal iconDrupal

Drupal contains some core, system-wide caching settings and controls, including the ability to enable site-wide caching, dump the site-wide cache, and aggregate CSS and Javascript files to result in fewer server calls. Additional site-wide caching capabilities come through the implementation of contributed Modules designed to aid site caching and expand caching features.

Drupal also contains caching controls that permeate throughout the Drupal system. By adjusting cache settings on Drupal Blocks, Modules, Panels and other areas, a Drupal developer can implement extremely granular caching mechanisms that operate under specific rules and conditions (for example, caching based on user activity, in addition to traditional time-based caching schema). Some specialized Modules can also hand off Drupal’s caching capabilities to other, server-based caching solutions, like APC and Varnish.

Although Drupal’s top-level caching controls are pretty easy to use, implementing granular caching features raises a lot of complex issues that require proper planning and approach in order to engineer a working solution. Drupal can support some extremely sophisticated caching behaviors, but this requires an expert level of knowledge to implement effectively.

Drupal sites can easily integrate with a CDN through a contributed Module and other tools.

Joomla iconJoomla

Joomla provides some easy-to-use, site-wide caching controls accessible through its back-end control panel. Global Configuration settings allow administrators to turn caching on or off, set the general caching profile (“Conservative” or “Progressive”), and the amount of time until cached files are refreshed. Admins can also use control panels to selectively clear cached content and delete older cached files from the server. Many core and third-party Joomla Modules enable time-based caching for that Module’s content.

Third-party Joomla extensions provide additional site performance enhancements, from CSS and Javascript aggregators (and minifiers) to finer-grained caching controls to selective loading of media elements. CDN integration is straightforward and quick through third-party Joomla extensions.

Dollar sign iconCost Conclusions

Joomla’s site-wide caching controls are well-balanced, easy to implement and effective: In general, it takes less time to configure site-wide caching for Joomla than it does for Drupal, although these costs are still nominal. Also, due to how third-party extensions install into Joomla as control panels, it’s generally easier to implement additional capabilities for page-specific caching, code aggregation and CDN integration by using Joomla extensions as compared to configuring similar Drupal Modules.

Drupal is able to offer a much more precise level of control over caching behavior than Joomla. While all of Joomla’s available caching options are time-based, Drupal provides a framework for activity-based caching, in addition to granular caching controls spread throughout Drupal’s functional areas. However, sophisticated caching setups in Drupal come at a high cost in time and expertise.

Website Deployment

Launching a new website is fairly easy: Just move files and the database from the development server to the live, production web server location. However, once a website is up and running, implementing updates can get quite a bit more complex. Both Drupal and Joomla (and indeed many other platforms) face the same challenge of updating data between production and development databases, as discrepancies between the two can sow chaos throughout the CMS deployment.

Generally, sites are taken offline in the middle of the night while admins furiously conduct site updates and transfers, then turn on the live site and conduct testing to make sure everything’s working correctly. (Naturally, incremental backups are essential throughout this process.) More experienced administrators may selectively update data between the development and the live production server, but this is a nerve-wracking process fraught with danger, even for veteran admins. For large and complex sites that can’t suffer through downtime, updating site software is going to be one of the most difficult tasks facing both Drupal and Joomla sites.

Drupal iconDrupal

Drupal provides a “Maintenance Mode” setting that allows administrators to temporarily take a site offline and display a custom message to site visitors. When in Maintenance Mode, only the top-level superadministrator account has login access to the Drupal site in order to conduct updates and make other changes.

Note that the pending Drupal 8 release plans to include site staging functionality.

Joomla iconJoomla

Joomla offers control panel settings to let administrators take a site offline, display a custom or default site offline message, and set an image for the site offline page that appears to users. While a site is offline, any user Group with appropriate permissions can log in to view and interact with site content.

Some third-party extensions provide help with site deployment, in particular those that bundle an entire Joomla site and database into a single archive file that can be easily transferred between locations and unpacked/reinstalled via a related PHP script file.

Dollar sign iconCost Conclusions

Both Drupal and Joomla sites follow the same process and have the same general costs for launching a website. Both also offer similar features for taking a site offline while updates are implemented, although Joomla lets multiple authorized users log in while a site is in offline mode, whereas Drupal limits this to the superadministrator. Finally, both face the same extreme challenges of updating live sites that can’t have downtime. Website deployment costs are essentially the same between the two, although Joomla may be more approachable for less experienced administrators.


Ongoing Support

Dynamic, CMS-powered websites need care and feeding, and both Drupal and Joomla require ongoing support and maintenance to update software, add features, hunt down bugs and assist site managers. Due to the nature of the CMS software and resulting websites, ongoing support can vary tremendously between Drupal and Joomla sites.

Drupal iconDrupal

By its nature, Drupal sites are custom-built to implement specific interfaces: The Drupal developer decides which Content Types, Fields and related controls to make accessible to users and content managers, and then develops the specific ways in which content is to be entered, stored and displayed. So, content managers typically only see the interfaces and options relevant to their specific usage, and this is ideally simplified and streamlined as much as possible to aid production. This custom approach mitigates problems related to producing content, but it requires Drupal developer involvement for even minor interface changes and site layout adjustments, much less site structural overhaul or enhancements to interactive features.

According to both convention and necessity, a Drupal site must commonly drag along the original developer to provide support and enable ongoing maintenance. Because of the complexity of Drupal sites, the range of implementation options and developer styles, and Drupal’s many Modules and distros, only the original developer may truly understand what’s going on. Coordinated hand-off of a well-documented Drupal site is certainly possible, but poor code commenting and sparse documentation tend to be the norm. Much of the time, a new Drupal developer will find it takes less time to build anew than trying to decipher the previous developer’s work.

Joomla iconJoomla

Joomla offers a good deal of flexibility for support options because of its setup, its structure and the consistency between different Joomla installations. Content producers have the ability to enter and edit content through both simplified front end interfaces, and the control panel-laden back end of the site. Inside the back end administrator, Joomla exposes many control panel-based settings that allow for things like reordering content, adjusting navigation and controlling front-end display options (in addition to the common task of producing content within a WYSIWYG editor).

Some knowledge is required to employ these controls, but they are generally very accessible to any back end user who wants to use them, and whose account has the permissions to do so. Depending on what the website’s content producers and managers want to take on, support may surround only producing content, or it may include helping with use of the back-end Joomla interface to adjust display options.

Because of Joomla’s standardized approach to management interfaces, coding conventions and structures, and site architecture, it’s relatively easy to hand off a Joomla site from one developer to another. The new developer may discover areas where cleanup is needed, but this is commonly accomplished through adjusting settings in Joomla’s back-end administrator interface.

Dollar sign iconCost Conclusions

For general content production and site usage, Drupal sites may take less effort to support, given that only the necessary controls and options are exposed to the end user, and the Drupal site is built to accommodate its specific use cases. However, any changes to the Drupal site’s structure, features, interfaces and functionality can require significant development work, in addition to an intimate knowledge of how the site was built, something only the original developer may know.

In contrast, Joomla sites are easy to hand off between developers due to its standardized approach and interfaces. Also, Joomla’s exposure of accessible controls makes it possible to train site managers to gradually take on more command over site construction, layout and content appearance. Supporting usage of these options may come at a higher initial cost, but this delivers more potential control to site managers, which could reduce longer term support costs in some scenarios.

Generally, supporting a Drupal site costs more (and engenders a higher billable hourly rate) than supporting Joomla sites because of the greater technical knowledge required, vendor lock-in with the original developer, and Drupal’s market position as a solution that focuses on larger, more expensive web development projects.


Software Development Lifecycle Management

Software Development Lifecycle Management (or SDLM) is the process whereby the overall scope of a software project is considered in light of the organizational requirements for that software, its specific outcomes and goals, the software development process, and how all these elements change over time. Although SDLM is traditionally associated with discrete software engineering projects, its principals can also be applied to platform-based solutions like Drupal and Joomla.

SDLM is valuable for adding longer-term perspective to running a CMS-powered site: It anticipates future work and costs and how these might best be managed. In the case of open-source projects like Drupal and Joomla, many SDLM concerns tie into the activities and advancement of the open source project itself, including updates to both core platform and third-party software, anticipated features under development, release of new major versions of the software, and abandonment of core code or third-party plug-in solutions. For the purposes of Drupal and Joomla, SDLM can also consider marketplace-based perspectives, as the popularity of a platform affects its longevity and the availability of third-party resources.

Drupal iconDrupal

Drupal’s build-out process and its resulting sites are complex by default and require expert knowledge in the Drupal platform and related technologies. A qualified support resource – probably the original developer of the site – will need to be available for any changes to site structure or capabilities, which will possibly require significant development time and come at a high cost.

Keeping Drupal’s core software and third-party contributed Modules up to date is an important ongoing task that requires specialized technical knowledge and understanding of the existing Drupal installation; again, something probably best accommodated by the original developer. Drupal and third-party Module contributors regularly release incremental updates to their software; the Drupal project maintains a loose schedule for major releases, with Drupal 8 anticipated to arrive at an undefined date.

Upgrading a site between major versions of Drupal – for example, upgrading to Drupal 7 from Drupal 6 – is a very complicated task that requires high Drupal expertise and intimate knowledge of the site being upgraded. In many cases, upgrading a Drupal site to its next major version is not possible, because a required Module has not been updated to support the new version of Drupal, a Module’s development has been abandoned, or the original site was built with Drupal-specific structures that are no longer supported in the new version of Drupal.

Another consideration in Drupal SDLM is the open-ended nature of its development style and looser standards for contributed Module development: This may require more discovery time for projects and updates, as well as cleaning up non-ideal code.

Drupal maintains a very strong position in the CMS market, supported to a great extent by the venture capital-backed Acquia corporation. Many existing Drupal installations at major institutions and for-profit businesses, as well as a thriving network of developers and vendors, ensure that Drupal will remain a popular CMS option for some time. Drupal’s development culture eschews ever charging money for software, with all third-party contributed Modules available at no cost.

Given Drupal’s heavy requirements for technical expertise and intimacy with any given Drupal installation, the original developer is a valuable asset for SDLM. Developers may know this and charge accordingly. As a practical matter, Drupal sites of any size or consequence do not get upgraded between major versions: The work required to conduct the upgrade, resolve any issues with Modules, and re-build site structures and code would take more time than rebuilding from scratch on the new version of Drupal. Because of this, Drupal sites tend to have a lifespan of a couple to several years before they need to be completely rebuilt. It’s still possible for a site to limp along on an older version of Drupal, but eventually, the underlying PHP and database technologies will need to be upgraded, quite possibly dropping support for a function required by the older Drupal version.

Joomla iconJoomla

The Joomla project has established a standard release schedule with new major versions appearing about every two years: Initially, a “dot zero” version (e.g. Joomla 3.0) for early adopters and testers, and later a “dot five” version (e.g. Joomla 3.5) that is fully validated for production use and that receives long-term support. On a regular basis, the Joomla project releases incremental updates to major versions, as well as offers overlapping support for older versions of the software.

Joomla makes site software updates easy to implement through a series of tools built into its control panels. Incremental updates are accommodated with a one-click process in the back-end administrator; third-party extensions can often be updated with a single click as well, or, failing that, through upload and installation of the new extension through Joomla’s Extensions Manager. The Joomla project has committed to providing an easy upgrade path between major software versions, which will ideally be a single-click process for core Joomla software. (Third-party software will still need to be updated independently, but these packages tend to follow the pattern of one-click upgrades.)

Joomla’s standardization of coding practices, its common structures, and platform maturity harbingers like the Joomla Framework all make it much easier for Joomla developers to work with each others’ code. Joomla sites are pretty easy to hand off between developers and site maintainers, and doing so should entail no extraordinary additional cost. Of course, adding site capabilities or features will inspire additional work and expense.

Joomla occupies a very strong CMS market position and is quickly expanding its base of installations from small business and organization sites into the enterprise and larger corporations. All Joomla project work is done on a volunteer basis, supported by the non-profit foundation Open Source Matters. A number of larger corporate players, in particular Ebay, have invested heavily in Joomla technology and talent. Many Joomla practitioners and service vendors are available worldwide, providing a huge choice of solution providers and driving down market costs. Joomla is also being adopted as a website solution for many marketing and communications agencies, because of its accessibility and value. Like Drupal, the Joomla project is going to be around for quite some time.

Looking at the longevity of a Joomla site yields the potential for ongoing site maturation through upcoming versions of Joomla, given the project’s emphasis on ease of upgrades and its planned release cycle. This means a Joomla site should be able to live on indefinitely as the Joomla software matures, without the need for complete site rebuilds.

Dollar sign iconCost Conclusions

Joomla sites are much easier to update and maintain than Drupal sites, given Joomla’s single-click update interfaces and the adoption of this standard by third- party extension developers. Joomla’s standardized code base and established structures in software and content make it easy to hand off a Joomla site to another developer or site manager; Drupal sites usually need to drag the original developer along in tow. Drupal’s higher requirements for site-specific knowledge and technical expertise also means more expense for ongoing maintenance and making structural or functional changes to the site.

In terms of upgrading between major versions of software, Joomla offers simple methods (or at minimum a documented process), whereas a Drupal site’s upgrade potential is tied to many different elements that can’t be directly accommodated by the Drupal project. For the most part, Drupal sites will eventually need to be completely rebuilt on a newer version of Drupal, whereas Joomla offers ongoing upgrades as the software matures. This represents one of the biggest differences between Drupal and Joomla SDLM, and Drupal website stakeholders should plan accordingly for these probable major expenses.


Making the Right Choice for Your CMS

This article has hopefully helped you understand some of the key differences between Drupal and Joomla. Although traditional rubric will say to use Drupal for large and/or complicated sites, and Joomla for simpler, smaller sites, one or the other could still be the best choice for a large or small project scenario, depending on what the website needs to accomplish and a host of other factors as outlined in this article.

Deciding between Drupal and Joomla may come down to the native capabilities of the CMS, anticipated support requirements, or future customization needs; it may even tie into marketplace concerns, such as the availability of professional expertise and services at a level which will result in a successful CMS project. Perhaps neither Drupal nor Joomla is appropriate, so you’ll need to look to one of the hundreds of other options in CMS platforms. No matter what, careful consideration and planning (and a properly scoped requirements document) will help ensure you make the best choice for your content management system.

Getting More Info and Help

Prototaph Interactive provides expert web development, design and consulting services, primarily concentrated on Joomla solutions for small- to medium-sized businesses and organizations. We intimately understand platform differences and can assist with deciding on a CMS platform direction and site implementation. Contact us with questions or to set up an appointment to discuss your website project needs.