A stable version of Recipes is yet to be released in 2023, this initiative is a prominent part of Drupal 10.

Drupal 10 provides a powerful platform for building websites and applications. It offers various ways of site-building, including profiles, distributions, and now recipes. 

As part of the Drupal strategic initiative, site-builders & developers can greatly benefit from the improvements to be provided by the recipes initiative.

Drupal 10 recipes are expected to provide more flexibility and ease of use to site builders and developers, allowing them to create custom solutions that meet their specific needs. Although a stable version of recipes is yet to be released in 2023, this initiative is a prominent part of Drupal 10 features. 

This blog will help you understand how recipes are different from profiles and distributions and how they are a way forward in Drupal site-building. 

Understanding Profiles & Distributions

Profiles and distributions are often confused, but they are not the same thing. Drupal vanilla, or the basic Drupal installation, is relatively bare and lacks many of the essential features required to create a full-fledged website.

Profiles and distributions are pre-configured packages that contain a set of modules, themes, and configurations that can be used to create a specific type of website.

Profiles and distributions are pre-configured packages that contain a set of modules, themes, and configurations that can be used to create a specific type of website.

Distributions are built on top of Drupal and provide a use-case-specific package. They include a pre-selected set of modules, themes, and configurations that are designed to fulfill a particular use case.

For instance, a media and publishing distribution will include modules like feed, carousel banner, facet search, or similar features specific to media websites. 

Distributions are a great way to get started quickly and provide a solid foundation to build on top of.

Profiles, on the other hand, are subsets of distributions and are included in Drupal core. Drupal core comes with three installation profiles: Standard, Minimal, and Demo (Umami). 

Installation profiles determine the set of modules, themes, and configurations that are included in a distribution. 

For an e-commerce site, one could use the standard installation profile as a base and add additional modules and themes to customize the site.

Drupal vanilla is bare and lacks any pre-configured settings or features. Profile and Distribution are similar concepts in Drupal, but serve different purposes.

Enter recipes!

What are Drupal Recipes?

Recipes are a modular approach to site-building in Drupal. They are small use cases that can be easily combined or customized to create a unique solution. Recipes are like microservices that can be plugged in and played as needed.

Recipes are modular building blocks that allow developers to create custom site features quickly and efficiently.

A distribution is a use case that customizes Drupal to fulfill a specific need. Unlike distributions, recipes do not use installation profiles and can be tweaked at any point in the site-building process.

Installation profiles are part of Drupal core. These profiles determine which set of modules, themes, and configurations are installed during the initial setup of your Drupal site. 

The actual backend of any distribution is happening here, as installation profiles are responsible for setting up the initial site structure.

A Profile is a type of distribution that provides a more focused set of features for a specific use case. Profiles can be thought of as smaller, more specific distributions that cater to particular needs.

Unlike distributions, recipes do not use installation profiles and can be tweaked at any point in the site-building process.

To illustrate the differences between these site-building methods, let's consider an example. Suppose you want to build a news website that includes features such as a feed, carousel banner, and facet search. You could use a pre-built news distribution that includes these features out of the box. 

However, if you need to make further customizations, you would need to modify the installation profile or distribution, which could be time-consuming and complicated.

Alternatively, you could use an installation profile such as Standard and then install the necessary modules manually. This approach provides more flexibility, but it requires more effort and expertise to set up. 

Finally, you could use a recipe approach and install each required module and configure them individually. This approach provides the most flexibility but requires the most effort to set up.

Steps to install Drupal recipe

Why Recipes?

One of the primary objectives of Recipes initiatives is to overcome the challenges, site maintainers and developers face with distributions and to:

• Allow users to install multiple Drupal recipes on the same project, unlike the current scenario where selecting a distribution like OpenSocial prohibits the installation of another distribution like Commerce Kickstart or Thunder. This limitation will be eliminated, and multiple Drupal recipes can be installed on the same site.
   
• Install a recipe at any point in a project's life cycle, which is currently not feasible. For instance, if a user wants to incorporate community collaboration tools in their site after a few years of using standard Drupal, they can do so without any impediment.
   
• Simplify the process of maintaining the multisite architecture. This initiative aims to ensure that any changes made do not create additional challenges in this regard.
   
• Make updating easier, which is currently a challenging task as every existing site is in a different state, the Update Helper module developed by a few distributions will be integrated into the core.
   
• Make it easy for Drupal recipes to provide demo content, which is currently done in different ways such as importing from CSV or using custom modules, a functionality will be provided in the core to enable Drupal recipes to ship demo content.

What Drupal recipes are not

Drupal recipes have certain limitations, such as:

• The inability to provide functionality themselves, like implementing hooks and services. In cases where a Drupal recipe requires custom functionality that involves code, this must be included in a regular Drupal module.
   
• Once a Drupal recipe has been applied, the responsibility for updating configuration and content falls to modules and core, and the recipe cannot provide an upgrade path.
   

• Can't be part of a deployment. Deploying the content created by a Drupal recipe is out-of-scope.

Wrapping Up

In conclusion, Drupal provides several site-building methods that allow users to create custom solutions to their specific needs. Profiles, distributions, and recipes are all powerful ways that can help you build your Drupal site efficiently and effectively. 

Drupal 10 recipes are an exciting addition to the Drupal ecosystem and will help make building websites and applications faster and more efficient than ever before. 

As a leading open-source community leader, OpenSense Labs has helped numerous enterprises transform their digital presence with our expert Drupal services and solutions. From custom Drupal development to UX design, we have the experience and expertise to help your organization succeed in the digital landscape.

Don't miss out on the opportunity to partner with a trusted and experienced team. Contact us today at hello@opensenselabs.com to learn more about how we can help you achieve your digital goals. 

Still using an old version of Drupal? We’re confident you’ll want to update after seeing Claro, the new default admin theme in Drupal core. 

Claro replaces Seven, which has only had minor updates since being designed in 2009. The new theme is a breath of fresh air for content editors, site builders, and anyone else spending time in the Drupal admin UI. 

True to its name–Spanish word for ‘clear’–Claro is clutter-free and simple to navigate. It’s less intimidating to learn, more accessible for users with disabilities, and easier to use on mobile. 

Claro was built using feedback from an admin UX study. As part of the Drupal Admin UI & Javascript Modernisation Initiative, it aims to:

• Create a more approachable experience for site builders and content authors

• Comply with best practices and accessibility standards

• Embrace workflows, tools, and practices that are familiar to JavaScript developers 

Claro was initially introduced as an experimental version in Drupal 8.8, became stable in April 2022, and is now the default admin UI in Drupal 10. 

Below are some of the features we’re most excited about! 

Improved Readability

Claro uses a base font-size of 16px to make text easier to read. Its modular scale for typography helps to create a clear and consistent visual hierarchy. 

Claro’s modular scale for typography ensures consistent readability. Credit: Drupal. 

Claro’s style guide is designed to use system fonts. This means improved performance and support for various writing systems. It creates a better experience for admins who want to use Drupal 10 in the typography or language they’re most comfortable with.

An example of the Claro UI with text in Devanagari rendered using system fonts on macOS. Credit: Drupal. 

A Modern, Accessible Colour Palette

Claro has a light colour palette that’s easy on the eye. It includes both neutral and vivid hues, which can be paired together for high contrast. This helps important elements such as buttons to stand out. 

Claro also provides out-of-the-box support for the Windows high-contrast mode: an assistive technology designed to help users with visual impairments.

A clean colour palette is an important ingredient in Claro’s simple, accessible design. Credit: Drupal.

A high-contrast palette allows important elements to stand out in the Drupal 10 admin UI. Credit: Drupal.

Buttons and Dropdowns

Buttons and dropdowns have been redesigned to make it more obvious that users can click or interact with them. There are various size variations for use in reduced spaces such as tables.

Claro offers a range of improved button and dropdown styles. Credit: Drupal. 

Consistent Focus Styles

Claro maintains the same style for focus states across its components. This is an important improvement for usability and accessibility. 

Focus styles are consistent throughout the Claro theme. Credit: Drupal. 

Minimalist Iconography

Claro’s creators have worked hard to cut down visual clutter. The outlined icons you would have seen in Seven have been simplified in Claro for a clean, minimalist look.

Minimalist icons create a modern look in the Drupal 10 admin UI. Credit: Drupal. 

Spacious Design

Claro’s generous use of white space allows for fewer distractions and easier navigation. 

Paddings, margins, typography, and icons have been tied to the same modular scale. This helps preserve proportions and a consistent visual hierarchy. 

Claro uses a modular scale for sizes. Credit: Drupal. 

Claro uses plenty of white space to give content room to breathe. Credit: Drupal. 

Physical attributes – such as depth and shadow – have been applied to spaces and elements to make them easier to perceive. 

Depth and shadow are applied to create an environment that’s more familiar to the eye. Credit: Drupal. 

Easier Navigation

Claro has a simplified navigation to help you do your job faster. It reuses existing styles from other components for a consistent user experience. 

The default UI in Drupal 10 is quick and easy to navigate. Credit: Drupal. 

PostCSS Implementation

Claro’s creators chose to implement PostCSS instead of Sass to make life easier for web managers and front-end developers. PostCSS provides features such as cross-browser support for CSS variables.

Developers can use the Claro Distribution for theme development. It includes a dashboard with a variety of markup generator modules for theme components, along with tests.

What About End User-Facing Themes?

Olivero has replaced Bartik as the new default in Drupal 10. Just like Claro, it delivered a far more user-friendly and accessible experience. Learn more about Olivero and its namesake.

More Drupal 10 Improvements For Content Editors

It’s easier than ever for non-technical users to edit content in Drupal 10 thanks to CKEditor 5, the new default WYSIWYG editor. Learn more about the benefits of CKEditor 5.

Migrating to Drupal 10? 

Learn everything you need to know about Drupal 10 with our on-demand webinar. This free resource is perfect for web managers and content creators who want to get familiar with the new features and plan for their transition.

Create a Search Page using Views in Drupal Read More »

This blog has been re-posted and edited with permission from Dries Buytaert's blog.

Discover Drupal's future: how Automatic Updates and Project Browser will empower ambitious site builders with a no-code composable platform and modern development practices.

Drupal's modularity allows developers to combine and reuse modules, themes, and libraries to create custom solutions. This modularity is one of the key ingredients that makes Drupal a composable platform. The original motivation behind Drupal's modularity was to accelerate the pace of innovation and democratize the experience of site building.

This blog post has two main goals.

First, we'll explore how Drupal's composability is evolving to empower ambitious site builders with modern, no-code development practices. Through exciting initiatives like Automatic Updates and Project Browser, Drupal will simplify the task of installing, composing, and updating Drupal sites, all within the Drupal user interface.

Second, we'll provide a retrospective on the past 10+ years of decisions that have led to significant changes in how end-users install, extend, develop, and maintain Drupal sites. By delving into Drupal's innovation process through a timeline approach, we'll showcase key contributors, significant milestones, and pivotal shifts in thinking that have influenced Drupal's approach to composability.

Let's start!

2011

Drupal 7 was released, and introduced the "Update Manager". Derek Wright (3281d Consulting), Jacob Singh (Acquia), and Joshua Rogers (Acquia) had begun developing the Update Manager feature starting in 2009.

The Update Manager can be considered Drupal's first no-code update system. This feature introduced the ability for users to easily download and upload modules from Drupal.org to a Drupal site.

Under the hood, the Update Manager uses either the File Transfer Protocol (FTP) or Secure Shell Protocol (SSH). An end user can upload a module to their Drupal site through a form, and Drupal will FTP or SSH the module to the web server's file system.

Interestingly, fifteen years after its development started, Drupal 10 still uses the same basic Update Manager. However, this is about to change.

The Update Manager has several drawbacks: modules can conflict with each other, updates are applied directly to your live site, and if something goes wrong, there is no way to recover.

Sam Boyer and me creating the Drupal 8 branch on stage at DrupalCon Chicago.

In March 2011, we started working on Drupal 8, and later that year, in August, we agreed to adopt components from the Symfony project. This decision was made to help reduce the amount of code we had to build and maintain ourselves.

2012

The Symfony project was using Composer. Composer is a PHP package management system similar to npm. With Composer, developers can define the dependencies required by their PHP application in a file called composer.json. Then, Composer will automatically download and install the required components and their dependencies.

At first, we added Symfony components directly to Drupal Core's Git repository. Core Committers would regularly run composer update and commit their updated code to Drupal Core's Git repository. This left the end user experience relatively unchanged.

Some people in the Drupal community had concerns with storing third-party dependencies in Drupal Core's Git repository. To address this, we moved the Symfony components out of Git, and required Drupal's end users to download and install third-party components themselves. To do so, end users need to run composer install on the command line.

This approach is still used today. Drupal Core Committers maintain composer.json and composer.lock in Git to specify the components that need to be installed, and end users run composer install to download and install the specified components on their system.

Looking back, it is easy to see how embracing both Symfony components and Composer was a defining moment for Drupal. It made Drupal more powerful, more flexible, and more modular. It also helped us focus. But as will become clear in the remainder of this blog post, it also changed how end users install and manage Drupal. While it brought benefits, there were also drawbacks: it increased the maintenance, integration, and testing workload for end users. For many, it made Drupal more complex and challenging to maintain.

2013

We decided that Drupal Core would adopt semantic versioning. This marked a massive shift in Drupal's innovation model, moving away from long and unpredictable release cycles that broke backward compatibility between major releases.

To understand why this decision was important for Automatic Updates and Project Browser – and Drupal's composability more broadly – it's worth discussing semantic versioning some more.

Semantic versioning is a widely-used versioning system for software that follows a standard format. The format is X.Y.Z, where X represents the major version, Y the minor version, and Z the patch version.

When a new version is released, semantic versioning requires that the version number is updated in a predictable way. Specifically, you increment Z when a release only introduces backward compatible bug fixes. If new features are added in a backward compatible manner, you increment Y. And you increment X when you introduce changes that break the existing APIs.

This versioning system makes it easy to know when an automatic update is safe. For example, if a Drupal site is running version 10.0.2 and a security update is released as version 10.0.3, it's safe to automatically update to version 10.0.3. But if a major release is made as version 11.0.0, the site owner will need to manually update, as it likely contains changes that aren't compatible with their current version. In other words, the introduction of semantic versioning laid the groundwork for safe, easy Drupal updates.

2015

Drupal 8 was released. It came with big changes on all the fronts mentioned above: a shift towards object-oriented programming, support for Composer, the introduction of Symfony components, semantic versioning, and an unwavering commitment to simplifying upgrades for users.

Unfortunately, the reaction to Composer was mixed. Many Drupal contributors greatly appreciated the introduction of Composer, as it made it easier to share and utilize code with others. On the other hand, site owners often found it difficult to use Composer. Composer necessitates using the command line, something typically used by more advanced technical users. Moreover, unexpected failures during a Composer update can be complex to resolve for both developers and non-developers alike.

2016

The Drupal Association's engineering team, together with members of the community, launched the "Composer Façade". This meant that all Drupal.org hosted projects automatically became available as packages that could be installed by Composer.

There was some behind-the-scenes magic going on to help the Drupal community transition to Composer. For example, Drupal.org extensions were available to Composer even though they were not using semantic versioning.

Over the coming months and years, additional features would be added to Composer Façade, including solutions to help manage compatibility issues, sub-modules, and namespace collisions.

2017

Because Drupal has users with different levels of technical sophistication and different technical environments, we supported multiple distribution methods: zip files, tarballs, and Composer.

In the end, we were living in an increasingly Composer-centric world and updates via zip files or tarballs became less and less viable. So we agreed that we had to take a difficult path by fully embracing Composer. We began a long-running effort to make Composer easier for Drupal end users.

For example, the Drupal Association engineering team started building zip files and tarballs with Composer support: you could start with a zip/tar file, and then continue updating your site using Composer.

Separately, we also introduced new ways to install Drupal Core via Composer, such as using a new drupal/core-recommended project template. This template specifies the exact dependencies used to test a particular version of Drupal Core. Drupal Core is only released when all tests pass, so using drupal/core-recommended helps to prevent any problems caused by using different versions of the dependencies.

A slide from my keynote at DrupalCon Vienna 2017 where I introduced the Automatic Updates initiative. My speaker notes read: "Maybe Composer can be used under the hood to develop an automatic updates feature?".

Lastly, in my DrupalCon Vienna keynote, I declared the need for automatic updates, and made it a top priority for the Drupal community based on community surveys and interviews. This led to the formation of the Automatic Updates Initiative. The basic idea was to make updating Drupal sites easier by making Composer invisible to most users, thus empowering more people, regardless of their technical expertise.

2018

From 2017 into 2018, David Strauss (Pantheon) and Peter Wolanin (SciShield) took the lead on planning out the Automatic Updates Initiative, and presented possible architectural approaches at DrupalCon Nashville.

Their approaches drew inspiration from a multitude of Open Source projects like CoreOS, Fedora Atomic/Silverblue, and systemd. Some of the ideas outlined in their presentation have since been implemented. This is the beauty of Open Source; you can stand on the shoulders of other Open Source projects.

In 2018, the Drupal Security Team and Drupal Core release managers also extended the security coverage of Drupal minor releases from six to twelve months. This enabled site owners to update Drupal on their own schedule, but also introduced "security updates only" branches which will make automatic updates safer. This work was implemented with help from Ted Bowman, Emilie Nouveau, xjm, and Neil Drumm, with sponsorship from Acquia and the Drupal Association.

Later that year, at the Midwest Developer Summit organized by Michael Hess (University of Michigan), the new initiative team (composed of members of the Drupal Security Team, Drupal Association staff, and other interested contributors) defined a full initiative roadmap and began development. Key contributors were Angela Byron, David Strauss, Michael Hess, Mike Baynton, Neil Drumm, Peter Wolanin, Ryan Aslett, Tim Lehnen and xjm (sponsored by Acquia, Pantheon, the Drupal Association, SciShield, and the Universities of Michigan and Minnesota).

This work continued at Drupal Europe in Darmstadt, when the Automatic Updates Initiative team met with contributors from the Composer Initiative to compare needs and goals.

2019

In 2019, with sponsorship from the European Commission (EC), the Drupal Association contracted additional developers to build the first iteration of the Automatic Updates concept.

On the server-side, the funding from the EC resulted in all packages hosted on Drupal.org being signed with PHP Signify. PHP Signify is a PHP implementation of OpenBSD's Signify. PHP Signify assists in verifying the authenticity of Drupal modules, safeguarding against malicious forgeries. Additionally, Drupal extended OpenBSD's Signify to support chained signatures (CSIG) for better key rotation and maintenance.

On the client-side, the funding resulted in a contributed module for Drupal 7. Due to the European Commission's exclusive use of Drupal 7 at the time, a Drupal 8 module was out of scope. The Drupal 7 module updates tar-based installations of Drupal, as Composer wasn't introduced until Drupal 8.

In my DrupalCon Amsterdam keynote in late 2019, I provided an update on the Automatic Updates initiative with the assistance of Tim Lehnen from the Drupal Association:

2020

Up until 2020, contributed modules used version numbers like 8.x-2.1. This example meant the module was compatible with Drupal 8, and that it was major version 2 with patch level 1. In other words, we supported major and patch level releases, but no minor releases.

We finally updated Drupal.org to enable semantic versioning for contributed modules, which brought them up to date with best practices, including the ability to have minor releases, which was consistent with Drupal Core.

Composer Façade continued to support modules that had not adopted semantic versioning.

A slide from my keynote at DrupalCon Global 2020 where I gave an update on the Automatic Updates initiative. The slide shows the four major architectural building blocks of the Automatic Updates initiative.

Meanwhile, work on Automatic Updates continued. Because we had already embraced Composer, it seemed obvious that we would use Composer under the hood to power Automatic Updates. However, there was one feature we identified as missing from the existing Composer/Packagist ecosystem: package signing.

Composer's main security measure is at the transport layer: communication between the client (Drupal) and the package repository (drupal.org, packagist.org, github.com) is protected by https (TLS). However, we didn't believe that to be sufficient for an automatic update system.

Early in 2020, at a CMS security conference sponsored by Google, David Strauss proposed that Drupal implement The Update Framework (TUF), which would resolve several architectural issues with PHP Signify and also provide a specification to mitigate numerous kinds of supply chain attacks that we had not considered previously.

To start off this project, developers from the Drupal community met with leaders of TYPO3 (Benni Mack, Oliver Hader) and Joomla! (David Jardin, Tobias Zuluaf) to ensure this implementation of TUF would be beneficial not only to Drupal, but to the broader PHP ecosystem, especially to other Composer-driven projects.

With guidance from Trishank Karthik Kuppusamy (Datadog) and Joshua Lock (Python TUF), Ted Bowman, Adam Globus-Hoenich, xjm, David Strauss, David Stoline, and others developed PHP-TUF, with sponsorship from Acquia, Pantheon, and DDEV. PHP-TUF handles the client-side part of TUF that will run as part of every Drupal site.

At this time, the Drupal Association also began working on the server-side of the TUF implementation so that Drupal.org would be able to sign packages.

In addition to securing the update process with TUF, we also needed to figure out how to apply updates to a live site with minimal interruption. David Strauss, Mike Baynton, and Lucas Hedding (sponsored by Pantheon, Tag1, and MTech, respectively) had previously prototyped a blue-green deployment approach similar to the one used by CoreOS.

We decided that the required changes to support this would be too disruptive to Drupal, so we pivoted to a new approach proposed by David Strauss: to perform updates in a temporary copy of the site's codebase and then copy the changes to the live codebase as the final step.

While not perfectly atomic in the way that a blue-green deployment would have been, the key advantage to this approach is that it didn't require any changes to Drupal Core's file structure, which meant that it could also be easily adopted by other PHP projects. Travis Carden (Acquia) began implementing this approach as the Composer Stager library.

2021

A design proposal for Automatic Updates. There are updates available for different modules. You can upgrade them immediately using the user interface, or you can let the scheduler run to do it for you.

The second iteration of the Automatic Updates module was released as a beta. Unlike the first iteration sponsored by the European Commission, this version worked for Composer-based projects by leveraging the newly created Composer Stager library.

I had also gone on a virtual listening tour around the same time, and when I asked people why they fell in love with Drupal, the most common response had to do with the empowerment they felt from Drupal's no-code/low-code approach.

With that in mind, I proposed the Project Browser Initiative. The idea was that anyone should be able to install modules, including their third party dependencies, all without having to resort to using Composer on the command line.

This dovetailed nicely with the Automatic Updates initiative. The combination of Automatic Updates and Project Browser would give Drupal the equivalent of an 'app store', making it easy for anyone to discover, install, and update a module and its components.

2022

A design proposal for the Project Browser. Users can filter modules by category, development status, security policy and more. Users can also page through results or sort the results by the number of active installs.

In 2022, we began work on making Automatic Updates' Composer functionality available for Project Browser, so that module installs and updates are handled in the same seamless, robust way. The new Package Manager (a sub-module of Automatic Updates) provides this functionality for both Automatic Updates and Project Browser, and will be the cornerstone of Drupal's install and update functionality.

Ben Mullins (Acquia), Narendra Singh Rathore (Acquia) and Fran Garcia-Linares (Drupal Association) from the Project Browser team collaborated with Ted Bowman (Acquia), Adam Globus-Hoenich (Acquia), Kunal Sachdev (Acquia), Omkar Podey (Acquia), and Yash Rode (Acquia) from the Automatic Updates team in order to enhance the Package Manager's capabilities in order to cater to both use cases.

While work was ongoing on the client side of both Automatic Updates and the Project Browser, the Drupal Association remained focused on the server side. The Drupal Association put out an RFP to implement the TUF signing specification in a way that would integrate with Drupal.org's packaging pipeline. Together with Christopher Gervais and his team at Consensus Enterprises, they developed and released the Open Source Rugged server. A server-side TUF implementation that is the companion to the PHP TUF client implementation.

Drupal Association team member Fran Garcia-Linares also started work on new Drupal.org endpoints that will feed the necessary data for the Project Browser. These endpoints were built on modern Drupal, with JSON:API, and will be deployed to production in the first half of 2023.

2023

That brings us to today. Project Browser and Automatic Updates are still two of the biggest initiatives for Drupal. Chris Wells (Redfin Solutions) and Leslie Glynn (Redfin Solutions) are leading the Project Browser initiative, and Ted Bowman (Acquia) and Tim Lehnen (Drupal Association) are leading the Automatic Updates initiatives.

Both are built on top of Drupal's new Package Manager. Package Manager provides these initiatives with the ability to programmatically utilize Composer under the hood. Acquia and the Drupal Association are funding several people to work on these initiatives full-time, while other organizations like Redfin Solutions, Agileana, PreviousNext, Third & Grove, and more have provided extensive part-time contributions.

At the time of writing this, Narayan Newton (Tag1 Consulting), as part of the Drupal.org infrastructure team, is working on deploying the Rugged TUF server on the Drupal.org infrastructure. xjm (Agileana) and catch (Third & Grove), two of Drupal Core's release managers, are also collaborating on both the client and server sides of the initiative to help smooth the path to inclusion into Drupal Core.

We have built key parts of our solution in such a way that they can easily be adopted by any PHP project: from PHP-TUF to Rugged and Composer Stager. In the spirit of Open Source, our implementation was based on other Open Source projects, and now our work can be leveraged by others in turn. We encourage any PHP project that seeks to implement automated updates and a UI-based package manager to do so.

Automatic Updates is currently available as contributed module, which facilitates updates for Drupal Core. The Automatic Updates Extensions module (a sub-module that ships with Automatic Updates) provides automatic updates for contributed modules and themes. The Project Browser is also currently available as a contributed module.

Our goal is to have both Automatic Updates and Project Browser included in Drupal Core, making them out-of-the-box features for all end users. I'm hopeful we can take the final steps to flush out the remaining bugs, finalize the Drupal.org services and APIs, and move these modules to Drupal Core in the second half of 2023.

Conclusion

Getting Automatic Updates and Project Browser into Drupal Core will be the result of 10+ years of hard work.

After all these years, we believe Drupal's Automatic Updates and Project Browser to be both the most user-friendly and most security-conscious tools of their kind among all PHP applications.

We were also able to overcome most of the drawbacks of the original Drupal 7 Update Manager: Composer helps us manage module conflicts, and updates are first applied to a staged copy of the site's codebase to ensure they do not cause any unintended side effects.

In the end, Drupal will offer an 'app-store'-like experience. Drupal contributors can register, promote, update, version, and certify modules through Drupal.org. And Drupal end users can securely install and update modules from within their Drupal site without having to use the command line.

I'm excited about achieving this milestone because it will make Drupal a lot easier to use. In fact, Drupal will be easier to install and update than Drupal 7 ever was. Think about that. Furthermore, Drupal will help showcase how one can democratize composability and advanced dependency management. I'm optimistic that in a few years, we'll realize that adopting Composer for dependency management was the correct decision, even if it was difficult initially.

Hundreds of people have been involved in climbing to reach this summit, and hundreds more outside of the Drupal project have influenced and guided our thinking. I'm grateful to everyone involved in helping to make Drupal more composable and easier to use for people worldwide. Thank you!

Special thanks to Alex Bronstein, Christopher Wells, David Strauss, Derek Wright, Gábor Hojtsy, Lee Rowlands, Nathaniel Catchpole, Neil Drumm, Ted Bowman, Tim Lehnen, Tim Plunkett, Peter Wolanin, Wim Leers, and xjm for their contributions to this blog post. Taking a stroll down memory lane with you was a blast!

With the help of the above reviewers, I made an effort to acknowledge and give credit to those who deserve it. However, there is always a possibility that we missed significant contributors. If you have any corrections or additions, feel free to email me at dries@buytaert.net, and I'll update the blog post accordingly.

DrupalCon is a community event, where people from around the world can come together and share in the mission to make Drupal the most impactful DXP in the world. Even beyond that, DrupalCon is for many people the one time a year to connect in person with the people they work with every day. We are so excited to share all the places where the community can connect in June! 

Community Summit 

Join us on Thursday, 8 June at DrupalCon Pittsburgh for a full-day unconference dedicated to exploring the issues that matter most to the Drupal community. What’s an unconference, you ask? It is a loosely structured conference that emphasizes sharing information instead of following a conventionally structured schedule. Together we will select topics that matter most to attendees and have collaborative discussions throughout the day. 

RSVP

There is a lot more information about unconferences online - Here are some great tips on how to prepare to attend an unconference. Please feel free to contact the organizers if you have questions: 

• Kathryn Carruthers 
• Jordana Fung
• Joi Garrett 
• Em Nouveau

Who should attend?

You! Are you part of a Drupal community or want to start one in your city? This summit is meant to be a meeting place for all Drupalistas interested in the community. Whether you need help maintaining a long-standing camp or User Group, you’re new to the community and want to know where you can get involved, or you want to share a success story from your community, everyone is welcome.

What gets discussed?

In the morning: 

Presentations on the latest work being done from some of the Community Initiative Leads. Check out the detailed schedule page for session descriptions! 

In the afternoon: 

You decide! Topics at past events have included:

• Contributing to the community
• Organizing events
• Improving diversity
• Growing local communities
• How to prevent burnout
• How do we foster and grow mentorship programs

But it all gets decided on the day, by whoever is in the room.

The community summit isn’t all about talk, it’s about action as well. Networking is a powerful force for collaboration.

Check out the detailed schedule

Community summit success stories

Several initiatives have started as a conversation at past community summits:

• The Event Organizer Working Group
• Speaker Diversity workshops
• Internship programs

Please RSVP and let us know what you’d like to discuss!

Community Initiatives 

Come by the community booth in the expo hall to learn more about Drupal Community Initiatives and how you can get involved! 

• Event Organizers Working Group 
• Community Working Group 
• Promote Drupal Initiative 
• Drupal Diversity & Inclusion 

Social Events 

Social events are often where the magic happens at DrupalCon. Whether it’s a small group hike, coffee hang-outs, or organized parties by our amazing partners, social events help foster lifelong connections. Check out the social events page to stay up to date on what’s happening around the city during DrupalCon, and even submit one yourself! 

Social events at DrupalCon

Decompress 

The festivities at DrupalCon can be overwhelming at times, and it can be hard to find a space to be in community quietly. For a respite from the hustle and bustle, visit our Quiet Space, Non-Denominational Prayer Space, or rooftop terrace. 

Quiet Space - Room 313

This room is reserved for those who need space free from interaction with other participants in an environment where they feel free and safe to do so. The quiet rooms are free of conversation and interaction of any kind. They can be used for meditation, journaling, reading, or just silence away from the buzz of the Con. Soft seating, stimming tools, and relaxing art supplies are provided. 

Non-Denominational Prayer Space - Room 314

This room is reserved for those who wish to practice their faith in a quiet and respectful environment. Spiritual texts and prayer rugs are provided. We ask that participants use hushed voices when necessary, but practice silence as much as possible to respect other attendees who may be using the space.

Rooftop Terrace 

Relax in green space without having to leave the DLCC. The rooftop terrace overlooks the Duquesne River, and you’ll have a view of many of Pittsburgh’s bridges. Enjoy the sounds of the water below, or take a stroll along the Rooftop Boulevard, where gentle tones play from the speakers above. If you take a look at the swooping art fixture, you can also find inspiration quotes scrolling digitally. 

No matter how you like to be in community, there’s a place for you at DrupalCon. We can’t wait to share space with you! 

Drupal is great for its content (data) modeling capabilities with its entity and field system. Not only is this system robust, but it is also completely manageable from a user interface! When fields are created through the user interface, they are managed through configuration. Drupal automates all schema changes required in the database based on this configuration when it is first created or when it might be removed. I have always had one issue with managing fields through configuration – your business logic relies on trusting that no one modifies this configuration. I prefer to define my fields programmatically, ensuring they exist and that fields tied to business logic are always present. Of course, this means I must also manage their installation and deletion for schema changes. But I prefer that level of control.

The primary function of a CMS is to create and manage content, as well as to allow users to search, customize, and publish content. The way your content is presented can decide how easy or difficult it is to use your website. In Drupal, display modes are different ways of presenting your content on your website. For example, you can show all the information about an article on a website, like a title, author, date, and full text, or you can show just a summary of it. Display modes let you choose what information you want to show and how it's arranged.

Display modes are built into Drupal core and they provide an easy way for developers to control how their content appears on the page. Content types in Drupal provide different types of display modes, each with its own features. For example, nodes (content pieces) can have multiple displays, such as teaser, full, list, and even a custom view. While some content types are limited to one display type (e.g. single page), other content types can have multiple display modes.

This article will help you get a deeper understanding of display modes, their uses, applications and extensions. So let’s get started!

What are Display Modes

Display modes are one of the core features of Drupal that help us manage the display of content and form entities differently for different situations. Content entities include taxonomy, nodes, paragraphs, and forms to add/edit content entities.

Similar to other configuration entities, like content types, display modes can be exported and imported as configuration files(.yml). Display modes have two parts, view mode, and form mode.

Why use them?

Display modes are just one of the many features that make Drupal great, and they provide users with a way to customize their websites by allowing them to control how different types of content are displayed on their sites. It also helps: 

1. Render content on the page only when required. The fields we don't need can be skipped.
2. Increase site performance.
3. Reduce the necessity to create multiple or duplicate content.

Working with Display Modes

Display modes can be accessed from structures.

As discussed previously, there are two types of display modes:

1. View Mode
2. Form Mode

Using the View Mode

View modes help to manage the display of the content item.
Different modes can be used to display different types of entities. Like view mode for taxonomy content can be used for taxonomies contents only. 

You can create new view modes or modify existing view modes.

To create a new view mode, click on “Add view mode” and choose the type for which you want to create the view mode. For example, select “content”. This will create a view mode for contents of a content type.

For configuring a view mode, go to the content type settings for which you want to use the view mode. Next, go to “Manage display”. At the bottom within “Custom display settings”, you can select any of the available view modes that you want to use.

Here we have selected three view modes. Next, save this configuration. You will then see that these view modes are visible in the “Manage display” tab.

You can make different configurations for displaying the content on the front end for each mode. For example, if you need to disable a field content or render it differently.

Few common use cases:

1. Entity reference field
2. View items
3. Paragraphs

Form Mode

Form modes can be used to simplify forms for certain use cases, such as creating a simpler form for user registration, or to add additional fields and functionality to a form for more complex use cases. Most commonly, you want to display forms according to user roles.

Like view mode, you can create or configure your own form mode. If you want to use a form mode for a node add/edit form, you can do it in the “Manage form display”.

Form mode features will not work directly from the UI for all forms. If you need to implement for node forms, you have to do it programmatically.

If you want some easy UI options for using form mode we can use the Form mode manager and form mode control contributed modules.

Form mode Manager

After installing the module, you will see the form mode listed on the module configuration page.

Here you can manage which form mode to use for a user by providing permissions.

Form Mode Control

The module also simplifies the process of using form modes.

After enabling the module, you can see form modes on the configuration page. You can choose which form to use.

If you want to use the form mode for other user roles, you have to provide relevant permissions.

You can set up the user roles on the configuration page.

Final Thoughts

Features like display modes make Drupal a great CMS to work with as they provide a high degree of flexibility and customization for how content is displayed on your website. Display modes allow you to create different layouts and designs for your content, giving you the ability to showcase your content in unique and engaging ways. We hope this brief tutorial will help you understand and work with Display modes more effectively. If you like what you read here, consider subscribing to our weekly newsletter so you don’t miss out on any of our latest articles.

Author: Pratik

Meet Pratik, a Drupal developer by profession. He enjoys reading and is always eager to learn new languages. Someday, he would love to visit Italy, his dream travel destination. He enjoys diverse cuisines and has a passion for food.

Leave us a Comment

Recent Blogs

Customizing Content Display in Drupal: A Guide to Display Modes

How to Create Dynamic Layouts with Layout Builder, CTools, and View Modes

A Journey of Persistence - Shreeganesh’s Career Story

Featured Case Studies

Upgrading the web presence of IEEE Information Theory Society, the most trusted voice for advanced technology

Explore

A Drupal powered multi-site, multi-lingual platform to enable a unified user experience at SEMI

Explore

Great Southern Homes, one of the fastest growing home builders in the US, sees greater results with Drupal

Explore

Today we are talking about Drupal & JavaScript with Andy Blum.

For show notes visit: www.talkingDrupal.com/393

• Talk at FLDC
• Important Drupal JS features
• Drupal behaviors
• Why use JS
• Users with no JS
• jQuery
• Front end framework
• Bigpipe
• JS components single folder components
• Future of JS in Drupal

• DrupalCon Pittsburgh training
• Top-10 libraries slides
• Drupal JavaScript Modernization Initiative
• Drupal issue to replace jQuery with vanilla JS
• What is bigpipe?
• Bigpipe in Drupal
• State of JS 2022
• Talking Drupal 386 - Drupal Vs Wordpress
• Devel accessibility tool devel_a11y
• Bigpipe when it was first added showing the contrast between bigpipe and no bigpipe John’s Talk at FLDC
• Nic’s Talk at NERD Summit

Andy Blum - @andy_blum

Nic Laflin - www.nLighteneddevelopment.com @nicxvan John Picozzi - www.epam.com @johnpicozzi Kat Shaw - drupal.org/u/katannshaw @katannshaw

Martin Anderson-Clutz - @mandclu Real-time SEO for Drupal Provides content authors immediate feedback about how optimized their content is against specific keywords.

It would be a slight change of scenery for you readers—an inexperienced writer in the works. I have always preferred people who knew what they were doing. Of course, from my stance, that preference would be because I want to learn. But when TDT’s editorial meeting puts confidence in a newcomer, and she is tasked to write a personal note to our avid readers, that sounds like an opportunity. And here I am grabbing that moment. 

Writing as a profession was revealed to me quite early on, but the art of writing is what I struggle with everyday. I don’t want to speak for everyone, but, to be honest, almost every writer could feel this way.

Now, I do have a simple plan. To observe is to learn. And my first target is to learn from my mentors. Taking my own advice and looking into what our Editor-in-Chief mentioned in a previous newsletter:

It is the baby steps that matter. And once you are thorough, it comes naturally to you. To reach that level need patience and practice. ~ VOL. 1 ISSUE. 7

The words, tone, structure of the sentences, references, and how the stories are told—Storytelling is a wonder. Has the media mastered the art of storytelling? A liar could have that skill as well. Apparently, it is all in the details, not too much or too little.

I think it is all perception and the power of discernment. It is in your hand, dear readers, all in yours. So, if you believe my writing is good and faithful, it could be. But if you don’t, it is all in your hands again. Until you decide, I’ll take you through what we have covered on TDT this past week.

I want to point out that writing a news story is a bit different. As you know, it is all about accuracy and facts. There aren’t many areas for storytelling, or are there? 

Now straight to the week’s stories. 

The DrupalCamp Poland proposals deadline is approaching soon, and the Drupal User Group Hamburg & Schleswig Holstein hosted an in-person meetup on March 30.

As the EoL of Drupal 7 nears, Chromatic released a Podcast that discusses the implications of Drupal 7 End of Life. Another exciting release was Droptica’s E-Book on SEO Strategies for Drupal Websites.

NERD Summit ended last month; here are the summit’s statistics: 2023 vs. before, excluding the covid years. DrupalSouth calls for a broad panel of judges for the splash awards. Fox Valley Drupal will host the midCamp preview and ramp-up. Acquia stands out as a leader in the 2023 Gartner Magic Quadrant for DXPs and SystemSeed Shortlisted for the 2023 Global Business Tech Awards.

There will be a Drupal4Gov’s in-person half-day seminar on April 18, so keep an eye out for that and also make sure to read an article shared on opensource.com, titled “How to encourage positive online communication in your open source community,”

There is more to ramble on about, but these were a few favorites picked in all truth. That’s it for this week.

Sincerely,
Alethia Rose Braganza
Sub-Editor.