Prior to attending my first DrupalCon, I had always wanted to learn more about Drupal, the Drupal community, and the Drupal Association. I was able to connect with Von Eaton, the Drupal Association’s Director, Programs, who was beyond amazing in diving deeper with me about the Drupal community. Through our interview engagement, I discovered more about DrupalCon and was offered the chance to attend!
DrupalCon is a four day-long conference where the Drupal community gets together, shares ideas, and collaborates on new ventures. It offers the opportunity to network within the community and also take time to break bread together. This is something I had a great interest in attending, and it was made possible through the DrupalCon Scholarship Program.
This initiative is a very comprehensive experience as a new attendee to DrupalCon. Prior to the conference, you get to connect with other new members like yourself and also have a dedicated mentor assigned to you to help navigate the events. The Welcome Breakfast for scholars on the first day is a great way to bond to Discover Drupal graduates and other scholars. Another useful tool that was resourceful to me was the guide for first-timers or scholars – this helped me to select which sessions to attend.
The Drupal Association is able to provide funding for these scholarships because of our amazing, dedicated, and mission-driven partners, donors, and members. If you would like to help support this year’s scholars, you can directly donate to the scholarship fund! Donors are invited to attend the Welcome Breakfast, where they will be honored for their contribution and have the chance to meet and network with our scholars.
Attending DrupalCon is something I look forward to every year, and it was all made possible thanks to the DrupalCon Scholarship Program!
Kwasi Afreh, DrupalCon North America Scholarship recipient
-
Help make a difference by donating now to the DrupalCon scholarship program. Each scholarship recipient receives a 1-year membership to the Drupal Association, complimentary registration, lodging, and travel, and will be paired with a mentor to create a welcoming conference experience.
-
Don’t miss this year’s DrupalCon Pittsburgh in-person conference for the opportunity to meet, collaborate, and network with the Drupal Community. We look forward to seeing you in Pittsburgh!
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.
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!
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.
One of the primary objectives of Recipes initiatives is to overcome the challenges, site maintainers and developers face with distributions and to:
Drupal recipes have certain limitations, such as:
Can't be part of a deployment. Deploying the content created by a Drupal recipe is out-of-scope.
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.
Articles
OffStill 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!
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
//--> //--> + more awesome articles by Evolving Web
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!
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.