Wordpress and Drupal jargon compared

I made the following comparison of Wordpress and Drupal terminology for a customer and figured others might find it useful too.

Important: undoubtedly the very existence of this table will create the impression that Wordpress and Drupal are much alike. This is obviously true in some aspects – both are open source CMS-es based on a XAMPP stack for instance – but the underlying philosophies of both systems can vary wildly.

I will try and give a few examples after the jargon comparison.

* Drupal’s templates are more powerful than Wordpress’. Drupal makes almost everything themable, meaning you can make a template for almost everything. This has advantages for child-themes (you only have to define template parts, which are just called templates; Drupal will figure out which one to load) and for modules, which can define templates for their own output, which in turn can be overwritten by themes. Instead of templates you can also use theming hooks.

** ‘Hook’ is programming terminology. Wordpress sub-divides its hooks into actions and filters. Drupal lets you define hooks by prefixing function names with the name of your custom theme or module. E.g. theming hooks are called THEME_preprocess_HOOK and THEME_process_HOOK, where THEME is the machine name of your theme and HOOK is the part of the page you want to alter, e.g. ‘page’, ‘block’, ‘section’ and so on.

*** Drupal’s filters are typically only used to change text before it is being output to the browser. In Drupal 7 and earlier filters were defined using hooks, in later versions using ‘plugins’ (not the Wordpress kind, obviously).

**** Tokens require a third-party module.

Discussion

Where Wordpress is a CMS, Drupal has historically been more of a CMS construction kit – simply installing Drupal was never enough to run a website. Wordpress on the other hand has its famous 5-minute install: you can literally be up-and-running in that litle time – assuming you do not want anything complicated.

Wordpress has a rich ecosystem of large, monolithic plug-ins (often with paid expansions typically called the Pro version) which give you everything but the kitchen sink for any given functionality.

Drupal on the other hand typically has leaner modules that tend to cooperate well with other modules – meaning you can build functionality from combining modules. Since Drupal sites are typically built by professional coders, this way of glueing together small modules works well for the system.

Drupal even has modules that were specifically made to provide an API – although I am not entirely comfortable with the comparison. Wordpress provides such a large ecosystem, that the combination of Wordpress and a popular plugin can be considered a CMS in its own right.

For example if you considered the Wordpress + Elementor combination to be a CMS of its own, it would be more popular than Drupal. The result is that these popular plugins become their own API’s, even if they are very ugly API’s that can be difficult to develop against.

The existence of the table above suggests that the jargon I have compared is closely related, but the different philosophies underlying both systems permeate through each concept. As a result, finding the right terminology tends to be little more than a starting point.

This entry was posted on Wednesday, April 13th, 2022 at 4:29 pm and is filed under Web design + usability. You can follow any responses to this entry through the RSS feed. You can leave a response, or trackback from your own site.