WordPress and Drupal terminology and concepts

Last updated on
30 January 2025

Helping new Drupal users coming from WordPress understand how Drupal works, explaining terminology and concepts, adding perspective between the two Content Management Systems (CMS'es). See the Drupal glossary for a description of terminology and acronyms used in the Drupal project and by the Drupal community.

For example, new Drupal users coming from WordPress often confuse plugins with modules. What Drupal refers to as a module is called a plugin in WordPress. While Drupal uses both terms -- module and plugin -- what a plugin means in Drupal differs: It allows extending the functionalities of a module. See also how Drupal’s admin compares to WordPress.

For local Drupal development install DDEV, it is officially recommended.

Vocabulary

There are many similarities, but also differences between concepts, and naming of features in WordPress and Drupal. This list attempts to clarify these overlaps and differences.

This list is adapted from Craft CMS for WordPress Developers.

WordPress Term Drupal Equivalent Additional Info
Post, Pages, Post Types Article, Page, Content types

Drupal comes with the content types Article and Page. You can create additional custom content types, adding new fields via the GUI, and configuring form and browser display with drag and drop.

The resulting content units are all called Nodes.

Media, Attachments, Thumbnails Media

Media files can be added as custom fields via the GUI. They are stored as individual units, and can be re-used in Nodes and Views. Thumbnail sizes are defined as Image styles, by scaling and cropping images, or adding various effects.

List, Secure Custom Fields

Views

List content from individual fields with the core module Views, in blocks or a single page.

Comments Forum

The Forum module was in Drupal core up until Drupal 11. It's now a contrib module, and can be easily installed.

Content CKEditor, custom fields Content in Drupal can be created via the default CKEditor, or split into multiple custom fields, for a much tighter control of input and display.
Taxonomies, Categories, Tags Taxonomy, Vocabulary, Tags Relate nodes to each other via Entity reference fields in a Taxonomy.
Themes Theme, Twig Install an existing theme, or override it by sub-theming. Use Twig for easy custom templates.
Appearance Appearance, Layout builder Change logo or element displays under Appearance. Arrange blocks and content fields directly on the content with Layout builder.
Plugins Modules Drupal core comes with many modules and features, but you can add Contrib modules to extend Drupal. Create your own specialized feature or customize Drupal's behavior via a custom module.
Users Users Administer users and permissions by assigning roles, highly configurable and extendable.
Draft, Revision Workflows Use Drupal core module Workflows to transition between different states, for example publication or user status.
Actions, Hooks Events, Hooks Drupal uses Symfony events and traditional Drupal hooks to allow intervention from modules.
Gutenberg, Blocks CKEditor, Gutenberg Drupal's default editor is CKEditor, Gutenberg is also supported.
Administrator (Role) User 1 Account Someone logged in as user 1 has permission to do all actions on the site, or root user, similar to the "root" user account that has full administrative permissions
Secure Custom Fields Content types, field and form layout Content types differ by the fields you define in them. Their appearance in the forms and displays can be highly configured.
Permalink URL alias Set the URL alias for each node in its form.
Ajax, JSON JSON, REST Drupal natively supports JSON and REST, for headless solutions.
WP CLI Drush

Drush is a command line tool for Drupal, and ships with lots of useful commands and generators.

wp-config.php settings.php

Use settings.php to set database connection, customize application settings through variables, or swap out default implementations with custom ones.

functions.php Custom modules

Extend Drupal with new features by creating a custom module.

What's Drupal CMS and Drupal core, and how do they work?

Drupal is two things now... Drupal Core, which is a framework to build web apps and very customised web sites, and Drupal CMS which is a pre-packaged set of very commonly used features from Drupal Core and the huge ecosystem of contributed modules, aimed at being user-friendlier.

Drupal is not like Wordpress, and it tilts more towards the engineering than Wordpress so it's good when Wordpress runs out of steam.

Drupal has a very predictable backend. Anything that is in Drupal Core is fully supported. Sometimes things are removed from Drupal Core, and then they are deprecated, with there being a full version between deprecation and removal from Core. When this happens, the features continue to be available as contributed modules. A current example is the Book module, which is for organising a bunch of pages in a treelike fashion with Previous and Next buttons. It has been in Drupal Core for at least 10 years - probably 15. But it's not used in sites nearly as much now as it used to be and has been Deprecated in Drupal 10, and is a Contributed module in Drupal 11 (D11). All the Book pages will continue to work just the same, except you have to download and install the module in D11 instead of having it packaged already when you install Drupal.

Someone who does not know coding can build good websites. In Drupal world this is usually called Site Building. Typically it involves choosing modules (Drupal modules encapsulate functionality) to achieve a set of features, configuring those modules, and configuring the content, then adding content, and altering the theme so that the site looks good. Altering the theme requires CSS knowledge.

People use Composer, because it manages dependencies and helps you keep all your modules up to date... Often one module will depend upon some others, and often particular versions are required. So, for instance, you may want module A in order to providing some feature. Module A at version 10.3, say, will need module B at version 10.4 or higher. Module B may require another module. Similarly you may want another feature, provided my Module C, and that may also require module B, but at version 10.5 or higher. Composer's job is to make sure that module B is installed at version 10.5 or higher, so that both Module A and C work properly.

You can see that you can do this all manually - by carefully checking the requirements of each module you add. Or you can use Composer because the typical Drupal site will have many, many modules installed.

What to do after install?

  • You should make two new pages. Don't worry about the URLs for now.
  • Then you should make a Block and make it appear on both pages. (Blocks are content that cut across many pages).
  • Then you should make a structured content type - say a type for Discographies by making a new content type and adding some fields.
  • Then you should add a few nodes with Discography content. Then you should investigate Views, and make a list of the Discographies. (A View is the Drupal name for any generated list of content.) (Don't be overwhelmed by the page for setting up a new View. You only need a name for the View, that you want the view delivered as a page, a url for the page, and the content type you want to show. Probably you also want to choose at least one field from that content type. The default options are fine.)
  • Lastly you should switch themes to change the look of the site.
  • Bonus task - choose a new module, download it, install it, change the settings, and use it to do the thing it advertises that it does.

Source: https://www.reddit.com/r/drupal/comments/1i4u2mc/comment/m7ztcom/

Help improve this page

Page status: No known problems

You can: