Drupal is a powerful platform that offers us the flexibility to create solutions using various approaches. However, it's essential to exercise caution when planning our architecture and making code decisions during the development process.
It is always important to answer the following question:
Does our solution provide scalability for the application?
Technical decisions have a direct impact on the future scalability of our systems
In this article, we will share some advice and reflections on decisions that you might encounter during the development process.
1- Logic on templates
Prior to Drupal 8, Drupal used the PHPTemplate template engine, which led to entire websites being constructed around PHP logic. Consequently, it was common in the past to find complex logic added on templates rather than being processed in the back-end, which is considered a bad practice nowadays.
When we opt to implement our logic on a Twig template, we are limiting our development to a template engine itself, bypassing PHP - a powerful tool that offers a huge number of functions to develop our logic.
If you need to address some complex logic before data output, write it first in a Drupal preprocess function and rely on Twig to just apply conditional logic for display or hiding this processed data.
If you choose to use Drupal preprocess function, you will have another benefit: it allows you to add your code in a custom module instead of a custom theme.
Alright, but what makes this a benefit?
When we encapsulate our client’s business logic in code, we aim for that logic to remain unaffected by the theme in use. Adding logic into custom modules ensures the continuity of the business logic, even if the theme changes.
2- Use Drupal Interface
Twig is brilliant, allowing us to customize with logic in our templates output, however, Drupal delivers a strong interface to manage the display of our entities such as content, users, and taxonomies. Sometimes we just need to add or change one small field in these displays, by default, the best solution would be a preprocess or override the default template and apply these changes.
Nevertheless, certain Drupal-contributed modules enhance the admin dashboard, granting us the ability to make changes directly within the interface.
2.1 Fences module
Fences module is “an easy-to-use tool to specify an HTML element for each field”, This feature empowers us to unlock our development process to interface adjustments, rather than only relying on code to make these minor changes. This flexibility enables us to customize data output effectively.
When we integrate this solution with a front-end CSS framework like Zurb Foundation Prototyping Utilities classes, which delivers utility classes such as "margin-bottom", "text-align-center", "text-uppercase" or "font-bold", it enables non-developers to handle visual changes and provides us alternatives to avoid the dependency on Twig templates for implementing these modifications.
2.2 Field Group
I need additional capabilities to group or wrap fields together
In this scenario, the Field Group module offers a variety of options, we can group fields and add custom wrappers directly in the Drupal interface, eliminating the need to work with Twig templates.
Field Group allows us to add extra attributes or classes, show labels, and adding visual effects, giving more flexibility to customize the data output.
3- Twig Template naming conventions
Name conventions on Twig provide a great interface to customize default templates and implement our own changes. However, choosing the best template option can be a challenging task sometimes.
What is the correct template I should choose?
The most common example, Node template, shows a lot of options to override the default template.
The answer is “it depends on your specific solution”. If you are aiming to create a teaser for all website content types, using node--teaser.twig might be the best choice. But if you require custom behaviors or styling for the article teaser, opting for node–article–teaser.twig could be a better option.
If you need assistance and a more in-depth evaluation of your Drupal architecture decisions, send us your questions.
References:
- https://www.drupal.org/project/fences
- https://www.drupal.org/docs/theming-drupal/twig-in-drupal/twig-template-naming-conventions
- https://www.drupal.org/project/layout_paragraphs
- https://www.drupal.org/project/field_group
- https://get.foundation/sites/docs/prototyping-utilities.html