Anantomy of Drupal
This chapter introduces the basic components of Drupal.
Table of contents
Introduction
This chapter introduces some of the major features of Drupal and the nomenclature used to describe it.
The Drupal site building GUI
Drupal let you build complex websites without programming. It does so by providing a site building GUI where you build the site by clicking on links, filling in forms, and dragging & dropping. A typical panel in the administrative user interface (the field manager) is shown below.
The blue texts are links. For instance, to view or change the field settings for “Long text and summary”, you click on the link.
You enter data by filling in forms. To configure a new field in the form shown above, you input text into the the Label and Field name fields, and select a field type and widget type from a menu.
In this, and many other panels, you rearrange the order of items by
dragging & dropping by putting the cursor over the
-symbol. Press the mouse button
to drag, release to drop.
Always, after making changes, you need to click the button at the bottom of the panel to save your changes. Do not forget to do this, or all your changes will be forgotten when you move away from the panel.
Paths
The main method for accessing content in Drupal is through a path leading to the content.
In Drupal, a path is a series short string separated by slashes,
for example node/42 or user/69. A Drupal path may
appear as a query strings when used in an URL –
for example
http://example.com/?q=node/42http://example.com/?q=user/69
However, if possible, Drupal will rewrite URLs containing paths into Clean URLs. In that case, these two URLs will instead appear as:
http://example.com/node/42http://example.com/user/69
To navigate a Drupal website, you navigate from path to path using hyperlinks. A path should not be changed after it has created, unless the content it makes available is deleted.
By default, a path is constructed from at least the entity type (see next section) and the entity instance numeric identifier. Additional functionality related to the entity instance may be qualified by additional elements being present in the path. Here are some examples of paths, with explanations:
user/42– Load and display the user with uid 42.user/42/contact– Load and display the contact form belonging to the user with uid 42.taxonomy/term/42– Load and display the taxonomy term with tid 42.node/42– Load and display the node with nid 42.node/42/edit– Load and display editing form for the node with nid 42.node/42/revisions– Show the revision history for the node with nid 42.
There is a provision in Drupal to create an alias for a path.
If about-us is set up as an alias for node/42, then:
about-us– Load and display node with nid 42.
For a path to be usable, it need to be registred with
Drupal menu router. Registration is done by the core or by the module
implementing the path. The paths shown above are all registred by the
Drupal core. However, any module can register a path, so there is
no standard list of paths available. Registered paths can be
found in the {menu_router} table of a Drupal
installation.
Entities
Drupal is a system to manage “content”. In Drupal the main unit used to store, process and display content is known as an “entity”. Entities in Drupal are characterised by have a common programmatic interface through which (most) of their behaviour are defined. The six entity types that comes with Drupal 7 are:
- Users
- Content (Drupal's main content container, stored in the
{node}base table) - Comments
- Taxonomy terms
- Taxonomy vocabularies
- Files
Source - Drupal.org: An Introduction to Entities.
It is possible to create custom entities, but this requires programming.
An entity is an abstract pattern of a data type. For instance you may have an entity “shop” of type “content” with attributes “name”, “address”, “postal code“, “hours of operation“, etc. When you create instances of this entity, the attributes are assigned values. For example there may be a shop named “Willy's widgets”, with the address “3222 E. Ocean Ave”, postal code “85040”, and hours of operation from “10-18 weekdays”.
In Drupal, attributes are knows as “fields”, and the administrative GUI lets an administrator add or remove fields from any entity. The collection of fields that make up a particular entity is sometimes referred to as a “bundle”.
Entities are assigned a numeric primary key identifier, which are
used in all sorts of constructs to refer to the entity. Each entity
type has its own number space, so the paths user/42
and node/42 refer to two different entity instances.
Users
Information about a user is used by Drupal for purposes such as authentication, keeping track of preferences and permissions, and logging.
Instances of user entities are stored in the database. The basic information about a user and user permissions are kept in the following four tables:
{users}– basic information about a user.{role}– names of roles{role_permission}– permissions assigned to the roles{users_roles}– connecting users to roles
There exists an User API that lets programmers interact with user entities. The API gives access to functions to perform permissions checks, get contact information, and discover user preferences.
For more about Drupal users, see the chapter about administration.
Content
Drupal's main content container is also called a "node". Most Drupal-based websites can be viewed as an interlinked collection of nodes, with other entities (in particular comments, taxonomy terms and files) existing as appendages to nodes).
Like other entities, nodes can be extended. However, unlike the other default entities, nodes are divided into subclasses called content types. You never extend the node entity, you always extend some subclass of it. The subclass a node belongs to defines the bundle (i.e. the collection of fields that determines the types contents a node instance may hold, and how this content is displayed) for the content type.
Nodes are stored in the database and retrieved as needed. Among other things, all nodes have:
- A primary key identifier (Node ID nid).
- At least one version identifier (Version ID vid) used to track revisions.
- A content type subclass identifier (type).
- A title (title). This is always treated as non-markup plain text.
- Ownership (uid). Initially this is the user that created the node.
- Dates (created and changed). Unix timestamps indicating when the node was first created, and last saved.
- Other metadata such as publishing status (status), language (language), and so on.
It is possible for site builders to create new node subclasses with additional fields. This is usually how Drupal is extended to accommodate custom content and functions.
Nodes
are still Drupal 7's most versatile entity. Some of Drupal's built-in
magic, such as the Book module for manipulating
content hierarchies, will only operate on nodes. This makes it
tempting to use nodes to represent other entities, such as users and
taxonomy terms. This is discouraged. All the workarounds I've seen
where site builders have tried to do this, has resulted in some very
awkward design decisions.
Comments
Drupal provides a general user-level feedback mechanism that is known as a comment. A comment is not a node, but is always linked to one.
Taxonomy terms
Taxonomies plays is an important part of the Drupal framework. Drupal is set up to let you relate, organise, and display content based upon taxonomy terms (tags) associated with entities. The terms are organised into vocabularies which may be regarded as term containers.
Whenever a new taxonomy term is created, Drupal assigns it a
primary key identifier, known as the taxonomy term ID (tid).
To see the tid associated with a term, click on
the term, you'll see a path ending with a number (e.g. the
path taxonomy/term/42 ending with the number
42). The number is the tid.
Files
Unlike other Drupal entities, files (including uploaded images) are not stored in the database. Instead, they are stored in the file system on the server. Public files are saved below the site-root, and can by accessed by anyone that knows their path or URL, even if they are associated with protected or unpublished content. Private files are stored outside the site-root, and can be made subject to access control.
Drupal file entities are managed, which means they are
tracked in Drupal's {files} base table. If you store
files in the server's file system bypassing Drupal's file management
mechanisms, they're not entities.
Menus
Drupal has a sophisticated menu system whose main purpose is to help the site builder manage navigation. Menus is dynamically generated by the menu system.
To see the list of menus that exists on a Drupal 7 website, log in as the site administrator and navigate to . On a freshly installed Drupal sitem there are four menus:
Each menu has a corresponding block that will show up if you navigate to (the blocks administration page). However, if you do so, you will discover that by default, most of the menus are not assigned to a block region, but are placed in the pseudo-region named “Disabled”. However, if you look at a newly installed Drupal 7 website, all four menus show up on the front page (along with two additional menu-like structures that are not in the manu list) as indicated in the screenshot below:
The reason for this is that the layout of a Drupal website is controlled by a a set of templates, and while templates may define regions where blocks can be placed by means of the GUI (the blocks administration page mentioned above), the templates may also bypass the GUI and place block directly in a region. For blocks placed ths way, you cannot use the GUI to manage tem – you have to edit the PHP template.
On the screenshot above, there is also two menu-like items that
are not menus. There are shortcuts (provided by
the Shortcut module, and the two links in the upper
right corner that comes directly from the
template page.tpl.php. As you learn more about Drupal, you
will discover that there are many different ways to source the elements
that make up the web page facing the user.
Programmers
should know that the Drupal menu system also functions as the
primary tool for mapping URLs to specific handling routines. Using the
Menu API, programmers can correlate paths with specially defined functions.
Themes
The “look” of a Drupal website is defined by its theme. Drupal themes are designed and developed using the hyper-text markup language (HTML), cascading style sheets (CSS), the server-side PHP hypertext pre-processor (PHP) and the client-side JavaScript scripting language. A Drupal “theme“ can be as simple as black text on a plain, white background, and as rich and complex as anything you see on the web. The theme defines both the graphical presentation of the site, and its layout. The key component defining layout is a set of regions where content is displayed. The theme determines where the regions are physically placed within the web page, and how (and if) they are presented.
Drupal is designed to keep presentation and content separate. This means that you can change the way a Drupal site presents itself to the world by replacing the site's theme, without having to do anything with its content.
Drupal ships with a few themes, including a default theme
(Bartik). There exists more than one thousand contributed
themes which can be downloaded and installed to replace Bartik.
It is also possible for developers to create their own custom
Displays
Drupal provides two main displays (views) for showing content: Page and Block. The difference between them is that a Page is characterised by having a path, while a Block do not.
A Page is typically used to present articles and larger
pieces of content, such as an featured article. The default for the
main page content is to go into the Content region of the
page (but you can override this with the blocks administration page). The
other regions on a page may have other content, typically
A Block is a container for smaller chunks of content. A generated list, a daily quote, or a a poll result, are often displayed as a Block on a Drupal website.
Note that while Drupal comes with many pre-defined blocks, only a few blocks of them are assigned to a region by default. Most are listed in the “Disabled” pseudo-region of the blocks administration page. To make them visible, assign them to a real region.
Administrators can use the blocks administration page (), which provides a drop-down menu interface for assigning a block to a region, and drag-and-drop for controlling the order of blocks within regions.
The regions are coded into a theme by the theme designer. The default Bartik theme comes with 15 regions, but only regions with visible blocks in them appears. If you navigate to , you will see the default home page, with an overlay that shows the names of all the theme's regions inside a yellow box. It will look something like the screen shot below.
Since not all themes implement the same regions, or display regions in the same way, blocks are positioned on a per-theme basis. Note that the blocks editor interface shows tabs with active themes. Block placement and visibility depends on the theme.
In addition to that, block visibility depends on the following:
- Whether the block is assigned to the page being viewed.
- Whether the block is assigned to a region that is available on the page being viewed.
- Whether the user's role has sufficient permissions to view the block.
The main tool for creating specific Page and Block displays is the Views UI module. It will be discussed in detail in the chapter about Views.
Text filters
Drupal's text filters play an important role in sanitizing text output to keep the site secure (see text formats). But they are also used to enhance and alter text output.
Drupal comes packaged with the five filters shown in the screen shot below.
It is quite feasible to install custom filters. Some extension define additional filters that you may use.
Filters are part of the long text widgets, which uses a HTML form text area to accept user input.
Final word
To understand how Drupal works, you need to “speak” Drupal. Like most complex tools, Drupal comes loaded with some jargon. Mastering this jargon is part of learning to design websites with Drupal.
All these technical terms may seem a little intimidating when you first are exposed to them, but after you've designed a few websites using Drupal as your WCMS, you'll recognise them as your friends.
Last update: 2020-10-25 [gh].