WordPress and Drupal terminology and concepts
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 |
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
You can:
- Log in, click Edit, and edit this page
- Log in, click Discuss, update the Page status value, and suggest an improvement
- Log in and create a Documentation issue with your suggestion
Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our Drupal 7 End of Life resources page to review all of your options.