Drupal for Project Managers: Part 1
Flatten Drupal’s learning curve and know how to build with it
Introduction
This is the first article of the "Drupal for Project Managers" series that is divided into two parts. The goal of this series is to provide just enough information on key technical aspects of Drupal to empower project managers to make more effective decisions.
This first article will go over the strengths and weaknesses of Drupal, including the ones typically known only by developers. The second article will talk about technical concepts that will enable the project manager to better understand common trade-offs on the development side of a Drupal project.
Drupal 8 and 9 are conceptually very similar and all the lessons in this series will apply to both versions of Drupal.
Advantages
Let's start with four well-known advantages of Drupal 9.
-
Open source: Anyone can download, use, modify, and work on Drupal. There are no licensing fees, ever.
-
Secure: Drupal is carefully tested and trusted by a number of organizations that have sensitive data such as the White House, UNESCO, Tesla Motors, and others.
-
Modular: the capabilities of a Drupal site are extensible by modules.
-
Vibrant community: one of the distinguishing factors and forces behind Drupal's success is the large and active community.
In addition to these four items, there is one more important aspect of Drupal usually appreciated only by developers: flexibility. There are different facets to Drupal's flexibility, but the one we're going to focus on arises from two concepts: Entities and Fields.
"Entities are things that use fields to store information."
The definition above is paraphrasing one of the earliest attempts to define an entity in Drupal. Defining entities as "things" sound surprisingly precise but doesn't explain what they exactly are so here are some examples to clarify this idea.
-
A page can be an entity with title and content fields.
-
A user can be an entity with name, email, and password fields.
-
A photo can be an entity with title, description, and image fields.
-
A photo album can be an entity with a field referencing multiple photo entities (multi-value reference field)
Anything that can be described in terms of entity and fields can be created in Drupal. That is because fields are able to store practically any kind of information. It is not surprising to see projects that transcend the boundaries of a traditional CMS being developed in Drupal such as e-commerce, social media platform, and learning management systems. That is largely due to the flexibility of the Entity and Field systems.
Fields
The standard installation of Drupal comes with fields capable of storing common data such as number, text, date, email, link, file, and references to other entities. However, many other types of fields are available through modules developed by the Drupal community (contributed modules) that allows us to store addresses, geolocation, social media posts, currency, phone number, video streams, and more. Additionally, in the rare case where you can't find a suitable type of field for your business case, it is possible to create your own type of field (custom field).
Creating your own fields adds complexity to the project but more importantly, creates code that will need to be maintained by your internal developer team. In rare cases, creating custom fields will be inevitable. One way to mitigate the risks involved with this approach is to keep the custom code to a minimum and have more than one developer working on it, or at least familiar with this custom field.
Entities
Drupal comes with a number of entities such as user, content, comment, taxonomies, and files. Similar to fields, additional entity types can be added through contributed modules.
Entities can optionally have sub-types (known as bundles, or types) where each sub-type can have a different set of fields. This is useful when certain entity types have common functionalities that can be shared but also have specific needs that requires different fields.
An excellent example is the content entity that comes with Drupal. The content entity, also known as node, is commonly used to create pages, blog posts, news, and events. That is because the content entity comes with default fields such as title, author, and status that is certainly useful if we want to create a page for example. This way, instead of creating a specific page entity, we can create a bundle of the content entity named page.
Creating custom entity types is an advanced feature of Drupal and requires a significant amount of custom code. Therefore, it requires thoughtful consideration before adopting this solution. However, creating sub-types of an entity is much easier and safe because it doesn’t require custom code. The advantage of using node types is that it has been thoroughly tested and continually being improved by the community. However there are scenarios where a custom entity type is a better solution. In that case, the same precautionary measures apply here: aim for keeping the custom entities to a minimum and if possible have more than one developer working on it or at least familiar with the work being done.
Disadvantages
Common issues that often come up in Drupal projects include bugs in contributed modules that take too long to get fixed by the community and unintuitive user interface for web novices due to a large number of functionalities in Drupal. Beyond these general drawbacks, there is one important issue that will likely surface in a Drupal project that requires a complex user interface. Advanced design customizations requires a significant amount of effort and collaboration from designers and developers. One of the main reasons for this is because of security. As mentioned before, security is taken very seriously by Drupal and because of that, customizing any interactive piece of the website such as forms, buttons, and navigations will require a developer with deeper knowledge about how Drupal works. A modern and attractive user interface can definitely be achieved in Drupal. However, it’s important to be mindful that it can come with a certain cost not only of time and money but also in form of security breaches if not done correctly.
Conclusion
In this article we went through some of the common advantages of Drupal. We took closer look on the flexibility aspect of Drupal provided by the Entity and Field systems. We've also shown that an Entity can have bundles and discussed the pros and cons of creating entity bundles versus custom entities.
The disadvantages section explained why complex user interfaces in Drupal can be difficult to achieve and talked about potential trade-offs in trying to achieve this goal.
The next post will go over key technical concepts related to the performance side of Drupal.