Joomla And WordPress: A Matter Of Mental Models


Open-source content management systems (CMS) are a large family of Web applications, but if we’re looking for stability, performance and average technical requirements, we’ll come up with a handful of options. In the past, choosing the “right” CMS was a matter of the project’s requirements, but now this is not completely valid because the paradigm of extensibility had driven the development of major CMS’ towards a model of core features that are extensible with plug-ins that fill virtually any requirement.

Picking the right CMS is then a matter of “mental models”: choosing the one that best fits our vision of how a Web application should work and what it should provide to users and administrators. In this article, we’ll explore the main difference in the mental models: of WordPress and Joomla for theming and extending their core.

Background Thoughts

Joomla and WordPress

WordPress and Joomla are two of the most popular open-source CMS’ around. They offer large and active developer communities and excellent documentation.

WordPress is the first choice among the designer community mostly because of its well-designed back end and wide availability of excellent themes.

Joomla, meanwhile, suffers from Mambo’s legacy, which was notorious for low performance and semantically incorrect output (such as nested tables for layout). But since the release of version 1.5, Joomla has a completely rewritten core, with improved extensibility and better HTML output.

One difference between WordPress and Joomla is their theming model. A website developer migrating from Joomla to WordPress might feel that the latter requires too much theme coding, while a developer moving the other way might feel that Joomla is less flexible and customizable. The reason for this is the different models on which the themes of these CMS’ are based.

WordPress’ Theming Model

WordPress Theme

WordPress’ theming model is based on a per-view structure. This means that in each theme, you could have individual view files for the post list, the single post and the archive pages. These files are independent of each other, allowing the developer to customize each view but requiring them to duplicate many parts of the code. The only common parts in a theme are the header and footer, which can be coded directly in the individual view anyway.

The main drawback of this model is that different views will not always require a different presentation (for example, the archive, category list and tag list are just lists). To overcome this problem, a theme is organized in a hierarchical structure, in which more generic views are used as fallbacks for specific ones. The common fallback for a WordPress theme is the index.php file, which is actually the only required file (along with a style sheet) in a theme. A complete reference and visual diagram of the hierarchical structure of a WordPress theme are available here1.

The Loop and Template Tags

To better understand how a WordPress theme works, we need to look more closely at the “loop” and template tags.

All data for a post or a list of posts is extracted through a loop. A loop is basically a while construct that begins with this declaration:

<?php if (have_posts()) : while (have_posts()) : the_post(); ?> 

// post output here 

<?php endif; endwhile; ?>

The most important part of this code is the_post(), which initializes a global $post PHP object containing all of the page data. The loop construct is also required for single post view, because all functions for presentation of data rely on the presence of the $post object. These functions are called template tags, and their main purpose is to output formatted data. Usually, they do not output HTML tags so that they can be used in different scenarios.

A complete guide to theme development is available here2.

Joomla’s Content-Based Model

Joomla Template Configuration File

Joomla has a completely different theming approach. Joomla’s templates are built on a common structure defined in an index.php file.

This file contains both static content (i.e. content that is common throughout the website) and template tags, which serve as content place-holders and are replaced by HTML output during the page-rendering phase.

A common form for a template tag is:

<jdoc:include type="modules" name="right" style="xhtml" />

Template tags differ in the type of content they provide: component, message, module, head.

This structural backbone implies that each view in the CMS outputs not a complete page but just what’s needed to present content. At first glance, a developer used to the theming model of WordPress might think that there’s no way to customize this content block. In fact, Joomla relies on the MVC architectural pattern3, meaning that data extraction and presentation are separated, the latter being rendered by the view part of the application.

Template Customization

To customize the default view, Joomla has a pattern called template override, through which the system scans the template folder for a custom view file to use in place of the default one. The image below shows the folder structure and naming convention of a default view and its override.

Joomla Template override
An example of the folder and file structure of a Joomla template override (from the “ja_purity” template).

Joomla overrides are an excellent way to customize a website template without hacks. Still, they are often overlooked, and Joomla’s support of legacy extensions make this pattern unusable, even for popular packages such as Virtuemart194 (which uses its built-in template system).

A complete reference for Joomla’s template system is available here5.

Beyond Core

Modular System
(Image by jared6)

In the last few years, plug-ins have made a big difference in the software industry, one of the most notable examples being Mozilla Firefox.

As we noted, modern CMS’ are developed to be extensible, allowing us to use the core as a backbone and build specialized parts on top of it. This resulting modular design is an effective development model for many reasons:

  • Better maintainability
    Developers don’t need to modify the core in order to add or customize functionality.
  • Lightweight and safer
    Only features that are needed are included, resulting in less memory consumption, a smaller code base and fewer vulnerabilities.
  • Separate development cycles for core and features
    By offering an extensions API, third-party developers can add new features while the core team focuses on the reliability and performance of the system.

With open-source projects, this last point is both a blessing and a curse. It benefits from shared development effort but leads to unverified work and a less organized workflow.

Joomla and WordPress have tried to overcome this curse by providing coding guidelines. Still, little effort is spent documenting the back-end and front-end UI design.

Aside from their different naming conventions, the extensions models of WordPress and Joomla differ in how third-party code interacts with the core by mean of the extensions API.

The key point to understand is that while Joomla is based on MVC pattern, WordPress relies on an event-like system to which extensions can be hooked. Let’s look at some details.

WordPress’ Hook Method

WordPress’ extensions model is based on the execution of a set of functions attached to the system flow by mean of “hooks.”

Hooks contain a list of functions that are triggered at various points as WordPress is running. They manipulate (in the case of filter hooks) and output (in the case of action hooks) database data and can be accessed from within the theme itself and from a specialized plug-in package.

WordPress lacks comprehensive documentation for hooks, but a list of hooks is available here7.

To understand the mental model behind WordPress’ hook system, we can compare it to the sequence of actions in baking a cake. In the beginning, we have an idea of what kind of cake we want to bake, so we get our ingredients. We cannot just throw everything together and bake it. So, we execute an ordered list of actions, such as “filtering” egg shells and mixing the eggs in with flour and sugar. As we’re doing that, we might want to customize the recipe. So, we “plug in” some chocolate and perhaps reduce the quantity of another ingredient by half. The result is a proper cake, created from discrete ingredients and a touch of creativity.

WordPress bakes its pages the same way.

While plug-ins are broadly related to hooks, a widget is a special type of plug-in. It provides a means of showing information in a theme’s sidebar. The main advantage of widgets is that they are configurable in the back-end interface, allowing quick customization even for novice users.

WordPress Widgets Page
All available widgets are listed in an administration panel.

In terms of theme development, the sidebar is similar in its mental model to Joomla’s template tags. It is a placeholder for something. The misleading bit is that a sidebar doesn’t have to be placed in the actual sidebar of a layout. It could go in the footer, navigation, header or elsewhere.

To learn more about the new API for widget development, have a look at the official documentation8.

Adding Functionality

Until now, the problem with WordPress’ extension API was that it gave you no simple way to add complex functionality, such as e-commerce carts and event listings. Most developers excused this shortcoming by pointing out that WordPress is a blog engine. This will hopefully be resolved with the release of WordPress 3.0 and its system for “post types,” which makes it possible to use the “post” and “page” interfaces for different types of content.

As for other popular CMS’ (such as Drupal9), post types function as a kind of “Content Construction Kit,” giving you the ability to smartly add, manage and present specialized content. If you’re interested in trying this new feature, here is a good tutorial10.

Other than post types (and until major plug-ins update support for this feature), the only feasible way to add complex functionality is to use already existing pages as containers, placing in the body a place-holder (called a “shortcode11“) that is replaced with HTML output by specific filter hooks.

This approach is used by plug-ins such as Buddypress12 and WP e-Commerce13, which extend the blog engine with social network and shopping-cart capabilities.

Another great example of shortcode implementation is Contact Form 714, a fully featured contact-form management plug-in.

Extending Joomla

An often overlooked aspect of Joomla is that it is built on the solid MVC framework. So, extending its core is really much like working with products such as Zend Framework and CodeIgniter, which give you an already designed back-end interface upon which to integrate your own extensions. This approach also gives designers the ability to use template overrides, even for third-party extensions.

Joomla! MVC Diagram
A diagram depicting Joomla’s Model View Controller system flow.

To better understand MVC and how it works in Joomla, here is a complete reference15.

Joomla’s Extension Types

Joomla’s extension model comes in three flavors, each with different tasks: components, modules and plug-ins.

Components extend the core by adding specific functionality, such as e-commerce carts, event listings and forums. From the user’s point of view, we can think of components as discrete sections of a website, not connected to other content. A popular example is JEvents16, an events calendar.

In the theme system, a component’s output replaces the component placeholder in the template’s index.php file:

<jdoc:include type="component" />

Modules are like widgets in WordPress: they show a component’s information, which is extracted from the database. They are “attachable” to module positions and can be put on every page of a website.

Modules are primarily intended to be teaser blocks, but they can incorporate full text and image galleries, which makes them handy for static parts of a layout, such as footer notes. They are also useful for showing related content on a page. For example, you could highlight interesting products for Web developers as they’re browsing a list of barcamp events.

The template tag, which serves as module place-holder, looks like this:

<jdoc:include type="modules" name="right" style="xhtml" />

Plug-ins work similar to WordPress’ hook system, because they bind to specific system events to format, manipulate and replace HTML output. Possible fields of action range from content for articles (such as video embedding tools—AllVideos17 is a popular one) to HTML filtering and user-profile extension. Commonly used Joomla plug-ins include URL rewriting filters, which come bundled with administrative components such as Sh404SEF18.

Compatibility Issues

One thing every developer should be aware of is that, despite efforts to provide a great extension API, Joomla 1.5 still suffers in its support of legacy extensions (built for v1.0), which do not have an MVC structure and which are sometimes hardly customizable. Furthermore, they break the API mental model.

The Joomla extensions library has a clear mark for 1.0 or 1.5 native extensions. But faking 1.5 native compatibility is easy, which would leave developers with nothing but legacy code. This method is followed even by big well-known projects like Virtuemart194.

Hopefully, once Joomla 1.6 is released and legacy support is dropped, every developer will rework their code to fit the CMS’ specifications.

What’s Next

While the best way to choose a CMS is by trying it out on a real project, understanding its underlying mental model can make developers feel less lost in code and more aware of the design patterns they need to follow.

If you want to develop themes and extensions for Joomla and WordPress, here are some resources.





  1. 1
  2. 2
  3. 3
  4. 4
  5. 5!_1.5_Template_Tutorials_Project
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26!_template
  27. 27
  28. 28
  29. 29
  30. 30

↑ Back to top Tweet itShare on Facebook

Marco Solazzi is an Italian frontend developer interested in UI design and web usability. He's an active developer and supporter of Open Source Projects like Joomla! and Wordpress. He runs a personal website about technical topics and electronic music. He also collaborates as JavaScript author with the italian website

  1. 1

    Joomla is bloatware. If you need to do something wordpress can’t do, you’re better off writing a CMS from scratch in PHP. You’ll actually finish quicker than trying to wrestle with the byzantine lines of obfuscated nonsense known as joomla. Both Joomla and Drupal are known for being too hard for computer-illiterate people to figure out. So what good are they? I’ve read stories of businesses and gov. organizations redeveloping their sites after their employees couldn’t operate Drupal.

  2. 102

    thanks ……… !!!

  3. 203

    very nice post…i am using wordperss and just started joomla..
    got helpful tips here to understand relative patterns

  4. 304

    Nice vision

    I think both need to keep growing so we keep getting the better
    as to me i prefer WP

  5. 405

    For all the hoopla over this issue, I am sure people on this thread only communicate in one language. In the future, the debate will be what CMS is the best-for the number one multilingual usage, front and backend.

    The only one that I have seen work fluently is wordpress using qtranslate. Once ANYONE can convince me otherwise, (yes I tried joomla and joomfish) (joomfish not even ready y for joom 1.6) I will go for the switch.


  6. 506

    Thanks for this post! After developing my site in WordPress, I got some work to develop a Joomla site. Just as you described here, I felt like I was “missing something”. Where was the ease of design?!? I guess it would be just as hard to go the other way. Thanks for confirming that I’m not crazy!

  7. 607

    I recently spent a month learning Joomla 1.5 & 1.6, using two online manuals and even bought a book before I gave it up. Too many bugs with the extensions. I asked myself why I should be digging through PHP trying to fix things when CMS is supposed to be the the easy way to build a website! Maybe it was because 1.6 is still new. Then I tried WordPress 3.1, as the free service from, spent about a quarter of the time on it that I spent on Joomla, and loved it! The plugins worked more often, and when they didn’t then I would write a forum complaint and the developers would get right on it and e-mail me that they had patched it. WordPress cannot do as much as Joomla, but more options made Joomla more complex, for me the developer, and also for the end user I was trying to train on how to use the website I made. I think the difference is that paid professionals at are keepting tabs on their free service at and they have a vested interest in the user experience of both translating into street cred for the paid service. It is kept simple and nearly bug free.

    • 708

      Abdessamad Idrissi

      May 11, 2012 11:06 am

      You said; …WordPress cannot do as much as Joomla..
      Do you know something that Joomla can do and WordPress can’t?

      I used WordPress for all my websites, whatever complex scenarios I had, WP never was stopping me in achieving what I wanted…

      WordPress is used by over 14.7% of Alexa Internet’s “top 1 million” websites and as of August 2011 manages 22% of all new websites. WordPress is currently the most popular CMS in use on the Internet … As of December 2011, version 3.0 had been downloaded over 65 million times.[Wikipedia]

  8. 809

    Thank you… this is what I’m searching for….

  9. 910

    Melvin Mcpherson

    March 4, 2013 8:58 pm

    Though Joomla and WordPress are the most well-known but Joomla Development is best for creating websites targeted to e-commerce and website challenging a more professional contact.

  10. 1011

    Excellent point on “choosing the right CMS”. Actually, most importantly you should base your work around the content and what you’re doing rather than the platform and technical stuff. Plus, there are tons of tools to switch between platforms, so it doesn’t really matter which one you start with. I recently moved from Joomla to WordPress quite fast and without too many issues (thanks to – no affiliation). All in all, the idea behind these CMS is the same, so why argue about them?


↑ Back to top