6 Essential Drupal Interview Questions*

Need more accurate results? Got a big list to verify?

Click the banner below to go to our recommended premium email verification service, Email Checker.


Advertise on Leopathu

The five layers, starting from the bottom layer, are as follows:
  1. Data (nodes, etc.). Before anything can be displayed on the site, it must be input as data.
  2. Modules. Modules are functional plugins that are either part of the Drupal core or are contributed modules that build on Drupal’s core functionality.
  3. Blocks and menus. Blocks can be used to present anything, so just about any piece of content on a Drupal site (other than main content, breadcrumbs, and primary/secondary menus) is usually a block. Blocks are an extensible core feature of Drupal with a simple API provided by the block module. Blocks are similar to “widgets” in content management systems, but are highly generalized. Menus are a collection of links (menu items) used to navigate a website. The Menu module provides an interface to control and customize the menu system that comes with Drupal. By default, new menu items are placed inside a built-in menu labeled Navigation, but administrators can also create custom menus.
  4. User permissions. User permissions are defined for various roles and users are assigned to these roles in order to grant them the defined permissions.
  5. Themes and templates. The top conceptual layer of the drupal architecture is the theme. This consists primarily of XHTML and CSS, with some PHP variables intermixed, so Drupal-generated content can go in the appropriate spots. Also included with each theme is a set of functions that can be used to override standard functions in the modules in order to provide complete control over how the modules generate their markup at output time. A theme may contain one or more templates, depending on the complexity of the site and the way it has been designed.

Drupal comes with a built in taxonomy system that allows for categorization of the nodes on a site.

The taxonomy system allows for arbitrary definition of terms, as well as arbitrary organization of those terms into vocabularies. There is no limit to the number of vocabularies that can be created, nor is there any limit to the number of terms that can be included in a vocabulary.

A vocabulary can also have free tagging which means that, instead of entering specific terms ahead of time, users may enter tags freely at the time the content is created and those tags automatically become terms in that vocabulary.


Drupal’s taxonomy system is one if its most powerful and flexible features.

The Field API allows custom data fields to be attached to Drupal entities and takes care of storing, loading, editing, and rendering field data. Any entity type (node, user, etc.) can use the Field API to make itself “fieldable” and thus allow fields to be attached to it. Other modules can provide a user interface for managing custom fields via a web browser as well as a wide and flexible variety of data type, form element, and display format capabilities.

The Field API defines two primary data structures, Field and Instance, and the concept of a Bundle. A Field defines a particular type of data that can be attached to entities. A Field Instance is a Field attached to a single Bundle. A Bundle is a set of fields that are treated as a group by the Field Attach API and is related to a single fieldable entity type.

For example, suppose a site administrator wants Article nodes to have a subtitle and photo. Using the Field API or Field UI module, the administrator creates a field named ‘subtitle’ of type ‘text’ and a field named ‘photo’ of type ‘image’. The administrator (again, via a UI) creates two Field Instances, one attaching the field ‘subtitle’ to the ‘node’ bundle ‘article’ and one attaching the field ‘photo’ to the ‘node’ bundle ‘article’. When the node system uses the Field Attach API to load all fields for an Article node, it passes the node’s entity type (which is ‘node’) and content type (which is ‘article’) as the node’s bundle. field_attach_load() then loads the ‘subtitle’ and ‘photo’ fields because they are both attached to the ‘node’ bundle ‘article’.

Field definitions are represented as an array of key/value pairs.

Note that the above answer has been excerpted from the Drupal API Documentation, where more information can be found.

All content on a Drupal website is stored and treated as “nodes”. A node is any piece of individual content (e.g., a page, article, forum topic, blog entry, etc.). Note, though, that omments are not stored as nodes but are always connected to a node.

The ability to create different “content types” is a way Drupal allows you to have different kinds of nodes for different purposes. For example, an “article” is one content type, a “book page” is another, and a “blog entry” yet another. You can also create new content types of your own.

Treating all content as nodes provides a great deal of flexibility that facilitates and simplifies creating new types of content. It also makes it easy to apply new features or changes to all content of a particular type.

Using the Views module, you can fetch content from the database of your site and present it to the user as lists, posts, galleries, tables, maps, graphs, menu items, blocks, reports, forum posts etc. Different content types including nodes, users, and other bundles can be displayed.

Views UI, a submodule within Views, provides a graphical interface underneath which lies a powerful SQL query builder that can access virtually any information in your database and display it in any format.

Different displays can present the query results as pages with fixed URLs on your site (or URLs accepting arguments), blocks, feeds, or panel panes.

You can also use Views to present related content or implement contextual filters. For example, you can display a list of users along with links to the content they have created and/or you can display customized content to a user according to their user ID.

More information is available in the Views documentation on the Drupal site.

Rails is a general purpose web application framework for Ruby. It’s designed to help programmers be more productive in building web sites of all types, not just CMSs. And note that it’s for “programmers”. Unless you intend to write server-side code, you can’t hope to get much done with just Rails alone (but if you do intend to write code, both Ruby and Rails are known to be very productive).

Drupal is a Content Management System, of which there are hundreds. It happens to be written in PHP, but it’s modular design and large collection of available modules and themes make it possible to design and implement a large variety of web sites without writing a line of code. Most importantly, though, it is fundamntally a CMS. The further your site’s needs are from the CMS sweet-spot, the less likely it is that Drupal will be your best choice.

This article is from https://www.toptal.com/drupal/interview-questions