Of code and (wo)mens
Drupal is based on a core (opens in a new tab) that provides the kernel and its own modules and themes. The core is maintained by a dedicated crew. It provides a starting point that can be extended by other projects maintained by the community, contributed projects: modules, themes, or distributions.
Full documentation is available on the Drupal User Guide (opens in a new tab).
Here is a summary of the concepts for site builders.
Storage (persistence) is the responsibility of entities that can be
- Content entity : stored on the database, used by any Drupal user.
- Configuration entity : stored on configuration files, mostly used by the developer and the site builder.
[/admin/structure/types] and [/admin/content]
- A node is the basic piece of content
- Nodes can be from several types (known as “content types”), describing the business model: Article, Basic Page are coming out of the box, Event, Session, Training, Organization, … are customized.
- Nodes can be created, edited and translated with the contributor role.
- Taxonomy vocabularies are used for content (node, user, ...) categorization
- Each vocabulary is composed of terms
- Terms can have an hierarchy and multiple parents
[/admin/people] and [/admin/people/roles]
- Users are can access the Drupal backend, if they have the permission to do so
- Users are grouped by roles
- Roles can be cumulated
- Each role has a set of permissions
- Blocks are used to handle page display exceptions
- They can appear on regions, defined by themes
- Their display can be based on conditions (by path inclusion or exclusion, by role, …)
- Fields can specialize content types, taxonomy vocabularies, users and blocks.
- Fields can be shared among the same entity type (you can share the field Image with Basic Page and Article), allows one single instance on the same content type (you cannot create two image fields with the same machine name on the same content type, but you can create a field_image and a field_logo).
- Fields are not shared among different entity types, so they can adopt the same machine name: you can create a field_image for vocabularies, even if it already exists for content types.
- Some are simple / scalar (text, long text, float) while other can be composite (address)
- Fields have cardinality (one to many values)
- Fields can be used to reference any another entity (the Article content type can reference a Article Type vocabulary).
- Fields can be defined as sub structure with some modules (e.g. Field Collection or Paragraphs) that can also have cardinality. Note that Field Collection is probably on its way to be deprecated.
- Fields can be synced among content translation or be defined as translatable
Views are SQL query builders that are primarily focusing on one entity type.
They can use filters that are implicit or exposed to the user, relationships and much more...
Menus are being used for frontend or backend navigation (e.g. About in the footer, Main navigation, User account menu, ...).
Translation occurs at several levels
- Content entity translation
- Configuration entity translation
- User interface translation : system global, like button labels or pagination
Historically, depending on the context (user interface, code, ...) we can find several synonyms for Drupal data structures.
Content type can have several "bundles" (example: Page, Article) that are producing nodes.
We should talk about Entity type of Node for a Content type and Node type for a bundle.
This is the case in the code.
Taxonomy can have several vocabularies that are producing Taxonomy terms.
We should talk about Entity type of Term and Term type.
Entities can have several Display modes (Teaser, ...). In some situations they are called View modes.
Do not get confused with the Views that are SQL query builders.
Node entities have title while Taxonomy Term have name. In the code, you usually can refer to it as label.