Welcome back to day 9 of the Drupal Advent Calendar. Today’s door takes us in a slightly different direction, as we join Jen Lampton (jenlampton) to tell us all about Backdrop CMS.
Backdrop CMS is the Drupal fork. Its goal is to provide a more affordable platform that’s easier to use, but without compromising on flexibility. On January 15th, it will have been 9 years since Backdrop’s initial release.
At its core, Backdrop has retained nearly all of the powerful functionalities of its predecessor, but the standard installation also includes more than 75 additional features that a modern website…
The Drupal core committers and Drupal 10 readiness initiative are seeking feedback on a proposed new working group. The group's mission is to focus on contributed modules where a maintainer has not updated to the next major Drupal version. This includes modules where the maintainer has requested assistance as well as modules where the maintainer is no longer active. This effort will benefit the entire Drupal ecosystem.
This group will have elevated privileges on Drupal.org like those that exist for the Security Team and Site Moderators.
Currently the Project Update Bot generates automated compatibility patches for contributed projects. These patches are reviewed and tested by Drupal community members and then set to the "Reviewed & tested by the community" status.
However, for some modules, these patches are not committed in a timely fashion. This creates a barrier to updating to the next Drupal major version for sites that use this module.
There are existing workarounds. One is the Composer Lenient plugin which allows affected sites to install a patched version of the module. However, this is not a substitute for having a compatible version of the module.
Establish a working group that has the ability to appoint its members as a temporary maintainer of a project. The only task of the temporary maintainer is to review, test and commit a patch or merge request that makes the module compatible with the new Drupal major version and optionally create a new release. The group will be able to take this action in the following circumstances:
The project MUST have a canonical issue for updating to the next major version of Drupal. This issue MUST have a patch or merge request. The issue MUST be marked "Reviewed & tested by the community" and MUST NOT have had feedback from a module maintainer within the past two weeks. The following proposal refers to this as the contributed project issue.
An attempt MUST have been made by members of the community to contact the module maintainers via their Drupal.org contact form. Record of this attempt MUST be recorded on the contributed project issue.
An attempt SHOULD be made by members of the community to contact the module maintainers via a messaging platform such as the Drupal community Slack. Record of this attempt MUST be recorded on the contributed project issue.
If there is no response from the module maintainer for seven (7) days, a member of the community MAY escalate the module to the Project Update Working Group. To escalate a module, create a separate issue in the Project Update Working Group issue queue. This is termed the project update group issue. An attempt SHOULD be made to notify members of the Project Update working group via a messaging platform such as the Drupal community Slack.
The Project Update Working Group MUST make a subsequent attempt to contact the module maintainers via their Drupal.org contact form. This communication MUST outline that failure to respond within seven (7) days may result in the Project update Working Group committing the contributed project issue on their behalf. Record of this contact MUST be recorded on the contributed project issue. Any communication between the Project Update Working Group and the module maintainers MUST be recorded on the project update group issue.
When the seven-day period from item 5 has elapsed, the maintainer has had two weeks overall to respond. At this point, a member of the Project Update Working Group MUST decide on the next step. The next step is to either intervene or not. If the decision is to intervene, then the group must also decide if a tagged release is to be made as well as committing the change. When making the decision the Project Update Working Group member MUST do the following.
Take into consideration recent activity from the maintainer in the project.
Take into consideration the age of the contributed project issue.
Take into account the complexity of the patch/merge request. They must work to avoid regressions. The level of automated test coverage for the project SHOULD be used to inform the likelihood of a regression.
Take into account the quality of the reviews.
Take into account the possible lifespan of the module and the needs of the community. For example, if the module duplicates functionality added to core or another module, then they may decide not to intervene.
Consider if the module is looking for new maintainers and if anyone has nominated themself for the role. The Project Update Working Group SHOULD favor supporting a new maintainer over intervention.
The Project Update Working Group SHOULD aim to achieve compatibility with the major version in a backwards-compatible way.
If a member of the Project Update Working Group decides to intervene and commit the patch, then the following occurs:
A record of the decision MUST be recorded on the contributed project issue.
The member of the Project Update Working Group MUST nominate to make the commit and/or release. Record of this nomination MUST occur on the contributed project issue.
The member of the Project Update Working Group MUST make a temporary change to the project's maintainers to add themself as a maintainer. Record of this change MUST be made on the contributed project issue.
The member of the Project Update Working Group with temporary maintainer access will then commit the patch or merge request. This MUST be recorded on the contributed project issue.
The member of the Project Update Working Group MUST acknowledge that the commit was made on the contributed project issue.
If it was decided that a release should be made, a member of the Project Update working group will create a tag and add a release node for the tag on Drupal.org. The member making this action MUST make a record of this on the contributed project issue. The release MUST follow semantic versioning rules for backwards compatibility. The member SHOULD strive to make a new minor version to allow sites to install a compatible version without updating the major version of Drupal.
If the module maintainer has not requested assistance from The Project Update group, a member of the Project Update Working Group MUST update the project node on Drupal.org to change it to 'No further development'. If the module has opted in to Security team coverage, the member of the Project Update group MAY opt the module out of this coverage.
Any member of the Project Update Working Group MUST then mark the original contributed project issue as fixed. This action SHOULD NOT prevent opening of new issues for the project for major version compatibility.
A member of the Project Update Working Group MUST revoke the temporary maintainer rights within fourteen (14 days). Record of this change MUST be recorded on the contributed project issue.
If the module was marked 'No further development' and if no such issue exists for the contributed project - a member of the Project Update Working Group MUST open a new issue in the project's queue seeking a new maintainer.
If additional compatibility issues are found between the module and the next major version of Drupal, the process above repeats.
The working group will comprise community members who self-nominate. Interested community members must receive two seconding recommendations from other community members. Nomination and seconding will occur publicly on Drupal.org in the Project Update Working Group issue queue. Community members will be able to share their thoughts or concerns on the nominees' applications. Concerns relating to conduct of members of the group MUST follow Drupal's standard Community Working Group processes.
The initial membership of the group will comprise at least five (5) individuals. Members of the group should have a record of maintaining core or contributed projects and have the git-vetted role on Drupal.org. In addition the group may contain provisional members. These members will not have the ability to change project maintainers and will require the support of a full member to carry out their duties.
The initial make up of the group will be vetted by the core committer team and security team. Subsequent appointments will be vetted by the Project Update Working Group with a fourteen day period for veto from the security team and/or core committers.
Membership of the group is for a single major update. For example, from Drupal 10 to Drupal 11. The first major update in which the group is active will be from Drupal 10 to 11. At the end of each major cycle, members can opt to renew their membership for the next major update cycle. As with the original nomination, this process will happen in public and require two seconding recommendations from the community.
To complement this process, it is proposed that a new Abandoned lifecycle status is added for project info files.
If this is successful, the following changes will be made;
The process at (6) above will be amended such that the module's info file is updated to set the lifecycle value to 'abandoned'.
A lifecycle link is added that points to the issue in the project's queue where a new maintainer is sought.
Community feedback is sought on the proposed process. Please use this issue to add your input. The feedback period will last until Friday January 12th 2024.
It’s time to open door number 8 of the Drupal Advent Calendar, and today we’re joined by Chris Wells (chrisfromredfin) to tell us about the Disclosure Menu module.
The importance of a seamless and inclusive website navigation cannot be overstated. Creating digital environments where everyone feels welcomed and capable is a central ethos in the Drupal community. And that’s why we were surprised that after spending so much time with menus over the years, there still wasn’t a truly accessible menu module available for Drupal.
The disclosure menu in action (with minimum theming)Our narrative begins with a standard website component: a hoverable menu…
Are you a Drupal enthusiast looking to take your theming game to the next level? Well, you're in for a treat! In this blog post, we're going to dive into some essential best practices for Drupal theming.
❌Don’t use the same view mode for everything
✅Do use view modes for unique content displays
View modes are an invaluable tool when it comes to theming in Drupal. They allow you to create unique presentations for your content, tailored to specific use cases. Here's why you should embrace them:
Tailored content display. View modes allow you to customize how your content appears in different contexts. You can make each one look just right, whether it's a teaser on a list page or a full content view.
Field management and formatting. Tired of displaying all the fields, even when you only need a few? View modes let you selectively show or hide specific fields, ensuring a clutter-free design. What’s more, view modes enable you to apply different formatters to each field.
Control referenced entities. View modes are also incredibly useful when displaying referenced entities as you can customize how a referenced entity appears per view mode.
Custom templates. Having different view modes also allows you to create specific templates that you can easily override and customize to your liking.
Some common examples of custom view modes:
Here you can see the recipe content type with multiple view modes configured.
❌Don’t access entity fields directly
✅Do use the content object when printing field values
Accessing and printing out entity fields directly places the burden of displaying fields on you and your code further increasing technical debt. So avoid printing entity fields like this:
{{node.field_example.value}}
Instead, use the content object:
{{content.field_example}}
Using the content object means you'll benefit from field widgets and formatters. There are tons of contrib modules that provide additional field widgets and formatters that you can use.
The content object also allows you to take advantage of field preprocess functions as well as field templates. These are out-of-the-box theming helpers that allow you to fine-tune the appearance of your fields. This approach is very close to Drupal standards.
However, there's an exception to this rule. You may access entity fields directly when checking raw values (like lists or keys) or when you need to verify the truthiness of a field. In these specific cases, it's acceptable to access the fields directly from the entity object instead of the content object. See the sections on empty fields and ternary operations below for tips on how to check raw values.
❌Don’t overfocus on fields and forget the rest of your content
✅Do pay attention to internal data and use the without Twig filter
It’s normal to find yourself printing the content fields individually, but it’s essential not to overlook the rest of your content. Here’s what to keep in mind:
Ensure processing of important internal data. Your content may contain essential internal data, such as hidden form tokens or cache tags.
Customize your view mode to hide fields. One of the strengths of view modes is their ability to hide specific fields. By leveraging view modes effectively, you can ensure that certain fields are hidden when they are not needed in a particular context.
Use the without Twig filter. To print the rest of the content effortlessly, you can make use of the without Twig filter. This filter allows you to exclude specific fields from the rendering, ensuring that only the necessary content is displayed.
// Print content fields individually.
{{content.field_foo}}
{{content.field_bar}}
// But don't forget to "flush" the rest of the content.
{{content|without('field_foo','field_bar')}}❌Don’t allow clutter and "Drupalisms" to build up
✅Do use contrib modules to tidy up your code
The Fences and No Markup modules can help you achieve more concise and readable code for cleaner, more efficient templates.
These modules allow you to control the HTML markup and structure of your content without creating unnecessary clutter. Your templates will be easier to maintain and understand as a result.
They also allow for more standardized markup that’s easier to style with CSS. Drupal generates a lot of markup by default, often containing "Drupalisms"—patterns and classes that are specific to the Drupal ecosystem. Fences and No Markup enable you to strip away these Drupal-specific elements.
Remove wrapper elements with the Fences module or completely remove all default markups with the No Markup module.
❌Don’t rely on rendering functions to tell you if a field is empty
✅Do check the entity property directly
One area that often goes overlooked is handling empty fields. It’s best practice to check the entity property directly instead of relying on rendering functions to determine if a field is empty. By accessing the raw data, you can efficiently assess whether the field contains content without triggering unnecessary rendering processes.
If you have to render a field before checking if it's empty, do so judiciously. Render the field once and store the result. Then perform your checks on the stored value. This approach minimizes the performance impact associated with repeated rendering calls.
Consider the following example:
{%ifcontent.field_name|renderisnotempty%}
{{content.field_name}}
{%endif%}This can be optimized as follows:
{%ifcontent.field_exampleisnotempty%}
{%ifnode.field_example.value%}
{%ifnotnode.field_example.isEmpty()%}Or, if rendering is necessary, do it once and test:
{%setrendered_field=content.field_example|render|trim%}
{%ifrendered_field%}
{{rendered_field}}
{%endif%}✅Do use ternary operations to make your code look concise
❌Don’t use them in situations where they might compromise code readability
Simplicity often leads to elegance. One way to achieve a cleaner and more concise codebase is by embracing Twig ternary operations. Here are some practical examples:
Example A: If foo, echo “yes” else echo “no”:
{{foo?'yes':'no'}}Example B: If foo, echo it, else echo “no”:
{{foo?:'no'}}or
{{foo?foo:'no'}}Example C: If foo, echo “yes”, else echo nothing:
{{foo?'yes'}}or
{{foo?'yes':''}}Example D: If foo is defined and not null, echo it, “no” otherwise:
{{foo??'no'}}Example E: If foo is defined (empty values also count), echo it, “no” otherwise:
{{foo|default('no')}}While Twig ternary operations are excellent for simplifying straightforward conditions, it's essential to use them judiciously. Reserve their use for situations where the conditions are concise and don't compromise code readability.
❌Don’t allow regular PHP code to become bloated and unwieldy
✅Do use Twig to create efficient and maintainable templates
Twig compiles templates down to plain optimized PHP code. Maximizing the potential of Twig goes a long way in creating efficient and maintainable templates. With single directory components (SDCs) becoming part of Drupal core, familiarizing yourself with Twig, and its built-in functions, is now more practical than ever.
The include statement allows you to insert static template content from another file into your current template. This can be especially handy when you have reusable components or snippets of code that you want to include across multiple templates.
For example:
{#Includeheadercontentfromaseparatetemplatefile#}
{%include'themes/my_theme/templates/header.html.twig'%}The extends statement is the foundation of template inheritance. It enables you to create a base template with common elements and then extend or override specific sections in child templates. This promotes consistency and reduces redundancy in your theming. Some examples are below.
Base template: base.html.twig
{%blockheader%}{%endblock%}
{%blockcontent%}{%endblock%}
Child template: child.html.twig:
{%extends'base.html.twig'%}
{%blockheader%}
Extendedblock
{%endblock%}
{%blockcontent%}
Thisblockisextended.
{%endblock%}The use statement allows you to import blocks from another template without inheriting its entire structure. This can be useful when you want to reuse specific blocks without committing to the entire template. Example:
Block library: block-library.html.twig
{%blockheader%}
Product
Features
Marketplace
Company
{%endblock%}
{%blockfooter%}
Copyright©MyWebsite2023.Allrightsreserved.
{%endblock%}
{%blocksidebar%}
Thisisasidebar
{%endblock%}The embed statement is similar to include but with a crucial difference. It allows you to create self-contained components that encapsulate their own logic and styling. This promotes modularity and makes your templates more maintainable. Some examples are below:
Person card: person-card.html.twig
{%blockperson%}
{%blockname%}Name{%endblock%}
{%blockposition%}Position{%endblock%}
{%endblock%}
People list: people.html.twig
{%embed'person-card.html.twig'%}
{%blockname%}
BubblesMcFuzzball
{%endblock%}
{%blockposition%}
ChiefBubbleologist
{%endblock%}
{%endembed%}
{%embed'person-card.html.twig'%}
{%blockname%}
SirReginaldFluffernutter
{%endblock%}
{%blockposition%}
DirectorofSnuggles
{%endblock%}
{%endembed%}
Section: section.html.twig
{%use'block-library.html.twig'%}
{{block('header')}}
The macro statement enables you to define reusable, parameterized code chunks. This is particularly useful when you need to repeat a specific operation with variations across your templates.
Button: button.html.twig
{%macrobutton(text,url,color='indigo')%}
{{text}}
{%endmacro%}Form actions: form-actions.html.twig
{%import'button.html.twig'asbuttons%}
{{buttons.button('PrimaryButton','#','indigo')}}
{{buttons.button('SecondaryButton','#','zinc')}}
From the flexibility of view modes to the power of Twig features, each technique that I’ve covered in this article will contribute to cleaner, more maintainable templates. Just remember that simplicity is key—the goal is to strike a balance between conciseness and clarity.
Happy theming!
//--> //--> //--> + more awesome articles by Evolving Web
Here's the next part of our ongoing series dedicated to assisting Drupal 7 site owners in upgrading their websites to Drupal 10. There are many great reasons to upgrade. The modern Drupal offers powerful features for content editors including: customizable editorial workflows, a layout builder for your landing pages, a media library that makes managing and reusing media easier than ever, and more. Developers can leverage the most of these advancements.
In our previous blog post, we discussed using our questionnaire to develop a plan, understanding your budget, and deciding whether to work with a certified partner from our list or take the DIY approach for your migration. As we get closer to the start of 2024 and to Drupal 7 End of Life, it's crucial to consider the next phase. Now, you need to secure your website's future but also start to map your information architecture and enhance your content strategy. In this blog post, we'll explore what that means and why these steps are crucial as you prepare to transition away from Drupal 7.
At its core, these steps are vital to ensure a smooth transition to a new version. Mapping information architecture involves creating a blueprint of your website, showcasing where every piece of content is located and how it's interconnected, along with the key content types, views, and taxonomies crucial to your site. This is crucial because when you transition away from Drupal 7 to a new version, having a clear plan ensures that your website's structure remains organized. Such clarity helps prevent issues like data loss, broken links, and confusion for your website visitors.
Drupal offers tools and features empowering site builders and developers to create and manage a structured website tailored to your specific needs.
Additionally, when you assess your content strategy, you're essentially conducting a thorough review of the quality, relevance, and overall effectiveness of the content on your website. This is crucial during migration as it ensures your content remains valuable, fits the new platform's goals, improves user experience, and maintains or boosts SEO rankings. This preparation is vital for a smooth transition and to maintain the integrity of your content in the new setting.
To learn more about information architecture, explore the information architecture guide. For insights into content strategy, refer to this content strategy guide. For a comprehensive checklist when launching a website, visit the major version upgrade documentation.
Here are some recent sessions from DrupalCon worth exploring:
In software terms, End of Life means that the version of that software no longer receives feature updates, bug fixes, or security releases. This last point is the most important. If a security vulnerability is discovered after the end of life date, it may be publicly disclosed, and you will be unable to update your site to protect against the issue. For this reason, we recommend beginning to plan your migration now.
Whether you want to take advantage of new functionalities with Drupal 10 or opt for another option, we’re here to support you.
Visit our resource center to migrate from Drupal 7 now, and stay tuned for more blogs in our Drupal 7 End of Life series!
Welcome back to the Drupal Advent Calendar, and we’re rounding out the first week with the help of Rodrigo Aguilera (rodrigoaguilera), who’s telling us about the Extra Field module.
My choice for the Drupal advent calendar is Extra field because it is a not-so-popular module that helps me in many projects. It falls into a category that I call “Developer little helpers” since it doesn’t provide any immediate interface or functionality but it makes my life a little bit easier.
I like to keep the different representations of entities in display modes and keep the configurability that Drupal offers…