Common Drupal Terminology

There is a lot of terminology specific to Drupal and it is easier when your clients get used to the odd language you are using. This is made overly complicated by the Drupal community sometimes messing up these terms by making them ambiguous or contradictory.

While working for one of my government clients, I put this short list together. For now, it mostly covers terms related to data structures.

Entity Type

• This is the mother of all content in Drupal.
• An instance of an Entity Type is called an Entity
• There are many Entity Types, some common examples include:
  • Node (commonly, and poorly, referred to as Content Type). Page, News, Blog post (not Blog), and an infinite number of others are commonly created as Nodes.
    • The primary difference between a Node entity and most (but not all) others is that it has a URL.
  • User (as in a “user account”).
    • This has certain “properties” which make it stand out. It has an email address and username (which on most sites is never used or seen)
    • Also has an associated URL
  • Vocabulary (collection of Taxonomy Terms)
    • Also has an associated URL. Honestly though, most entities don’t.
  • Others include Feeds, Messages, Paragraphs, Watchdog (log) entries.

Fields

• These are typically (but not always) what you think of on a Form. Such as text field, select list, text area, radio buttons, etc
• Technically few of those I just listed are fields and they are more correctly referred to as Widgets.
• A field refers to DB storage and how it appears on a form (if it even does) is it’s widget. A field may support different widgets. For example, a Date Field defines a certain storage type in the DB but may have as a widget a simple text field, a month/day combo of select lists, a date popup, etc. But all these widgets store the same format of data in the DB.
• There are hundreds of different Field types provided by their own Module (more on those later). A Module may, however provide more than one field type and may include other functionality with it as well.
• Some common Fields (field modules) include: Date, Number, Text, Address, Phone Number, Email, Entity Reference, Paragraph (both a Field and an Entity Type, you guessed it, more on this later), and literally hundreds more.

Properties

• Like Fields; but not. Properties are not “added” to an Entity Type; they are inherent in its definition; whereas Fields can be added as required (more on that later)
• They are usually what distinguish different Entity Types.
• Examples, mentioned above:
  • User: username, email address
  • Node: author, created date, updated date
  • Vocabulary: label, description
• ALL Entity Types have an Entity ID property. And all entities therefore have an ID number (as this is how DBs work)

Bundle (sometimes incorrectly referred to as a Content Type)

• This is a collection of Fields of a certain Entity Type.. and yes, this is a bit confusing.
• A Node Type (often called, somewhat incorrectly, a Content Type) is basically a Bundle of Fields of Entity Type: Node. Simple, right?
• So News, Blog post, Event would all be different collections of Fields; but all Bundles of Entity Type: Node. Therefore each has a common set of Properties (author, created date, etc); but a different set of Fields: Title, Body, News Type, Starting Date, Topic, etc, etc)
  • Almost any time you here of a Thingy Type, this is a Bundle of Type Thingy (yes, fine, that doesn’t refer to the term Entity Type – but good to see you are paying attention). Examples of this include: Block Type, Message Type, Paragraph Type, Node Type, Vocabulary Type.. uhh..nope, just call it a Taxonomy, Feed Type, so many others.
  • User is a different one (wouldn’t call it unique though) as it doesn’t have different Types/Bundles. In code, you will often see the Bundle and Type both referred to as User.

Paragraph

• This is a useful and interesting Entity Type. It is a collection of Fields, uhh.. Bundle, which is then embedded as a Field onto other Bundles. This really isn’t any different than an EntityReference Field (which simply refers to a reference to some other entity, hmm, I guess that’s obvious); but you wouldn’t want that to be a reference to a node, user or taxonomy for example as those all have URLs, which this doesn’t/shouldn’t have.
• It then embeds its Field structure into the parent’s form (although you could do that with any EntityReference, but again, we don’t want this entity to have a URL).
• Then like any field, you can have it set to add another, and another, and…
• One note of interest is that Paragraph (Fields) can’t be translated. Not a big deal once you understand translation – and yes, more on that later.

Field Group

• Just because this came up today and it is interesting
• FG is a contrib module (i.e. not part of Drupal core) which adds display groupings to both Entity forms and display. It is not a DB structure, so much different than everything discussed so far.
• It provides HTML wrappers for both form elements and fields being presented on the entity view.
• These include things such as tabs, accordions, divs, details/fieldsets, etc.

Translation

• There is a ton to discuss here but just a few basics.
• As Drupal community messed up the terminology of these translation methodologies; I have given them my own names: “the Drupal 6 Way” and “the Drupal 8 Way”.
• D7 supports both.
• D6 uses the concept of creating a translated entity. So basically 2 different entities (think of this as a Node if it’s easier for you, or easier yet, a Page). So 2 different entity IDs (or Node IDs) and then linking those entities/nodes together.
• D8 uses the much smarter system of translating Fields (and Properties). So there is only a single Entity/Node/Page and possibly numerous Fields which are in various languages. The Entity is built out of the correct pieces (Fields) as required for the given language.
• To give an easy example of why this makes much more sense than the D6 approach, consider voting on a Blog post. Would you typically be voting on the post, or would you want those vote’s split between languages? Typically it is the first of these. So the votes are all assigned to the 1 ID for that post.
• To understand my comment above about not being able to translate Paragraphs (fields); and why that is rarely a big deal. Think of this in the context of how I described translation. You can certainly translate the content within the fields of the Paragraph; just not the entire Paragraph itself. A little tricky to wrap your head around this; but think of Taxonomy terms in a similar manner. If you tag a post as Red (i.e. set the Colour field on the Entity to the Red term) it is rare that you want to translate the post and set the French version to Bleu. More likely what is wanted is that the Taxonomy or Paragraph (or any other EntityRef field) is not set different for different languages (i.e. translated); just the fields/content within that thing itself is translated (i.e. the Red term is translated to Rouge).