If yours is one of the 42% of Drupal sites that are still using Drupal 7, we’re writing this post specifically with you in mind. 

After all, you’ve probably heard the news by now; as of January 5th, 2025, everyone’s beloved, trusted Drupal version 7 will reach its end-of-life. If you haven’t done so already, this means it’s time to start thinking about the ‘m’ word — yup, migration — to a newer version.

Modern Drupal’s versions 8, 9, 10, and the newly released 11 are similar in many ways, yet very different in others. The Drupal 7 migration process is kind of similar to finally trading in your trusty old well-worn VW camper van for a brand new Porsche. As you can imagine, a transition of such magnitude could be a tad jarring for some — not to mention a wee bit confusing.

That’s why we’ve created this handy infographic, to give you an overview of the key differences between each modern Drupal version, their respective functionalities, and how they solve specific business needs. 

What about Drupal 8 & 9?

Since these versions have both reached their end-of-life, there’s no long term support for them. We’ve still included them in our comparison, since their features are integral to understanding the path of version 10 and beyond; however, we don’t recommend them for new builds or upgrades.

An overview of Drupal 7 to Drupal 12

This chart is best viewed when downloaded.

The one thing to keep in mind is that anything higher than Drupal 8 is part of Drupal’s composable future — i.e., not only can Drupal integrate with virtually any business or marcom software or service, but it in itself is composable. Taking the best open source tools — CKEditor, Symfony, and Twig, for example —  allows modern Drupal to keep innovating and improving while keeping your website’s appearance and functionality intact.

Drupal remains an excellent platform, and its newest releases demonstrate its commitment to staying current and providing the best possible experience to its users. It’s also incredibly complex, which is why any successful migration from Drupal 7 will involve a great deal of planning and resources — not to mention expertise. That’s why it’s highly recommended to work with a web developer, whether as part of your organization or a third-party web development firm.

When searching for the right Drupal partner, it’s helpful to find an organization with experienced developers who contribute to the project on an ongoing basis. At Kanopi Studios, we provide Drupal development services for all types of organizations, including nonprofits, corporations, healthcare organizations, and higher education institutions. 

We’ve also written several blog posts about the various Drupal versions and their upgrade paths: 

• All about Drupal 11
• What you need to know about the Drupal 9 to 10 migration
• The ultimate Drupal 7 to Drupal 10 migration guide for marketers
• Drupal 7 end of life: a guide to next steps

Ready to launch the migration process? Contact our team today!

References:

• Onwards to Drupal 11 – ways to get involved
• Drupal 10 will be supported until the release of Drupal 12 in mid-late 2026
• Drupal core release schedule
• Release process overview

The next major Drupal version was just released — laying the foundation for its future.

Drupal 11 was recently released on Drupal’s timeline. Unlike previous major versions, where releases needed to accommodate underlying technologies’ end of life like Symfony, Drupal 11 was released because it was the right time to solidify new features and free us from deprecated code so development can continue to improve functionality and performance.

The initial Drupal 11 release has the same functionality as Drupal 10.3, to which most Drupal sites should have been upgraded in the spring — although Drupal 11 does have a few differences. For example: 

1. Instead of having deprecated code and modules identified, they are now removed. 
2. Dependencies and dependency requirements were upgraded. The minimum PHP version for Drupal 11 is 8.3, which brings impressive performance and a better developer experience. jQuery, Symfony, and PHPUnit were also upgraded to allow for code and testing modernization and performance.

As Drupal works to become more performant and valuable as a framework, overly specialized or underutilized modules are continually being removed from core. This includes the Actions UI, Book, Tracker, Forum, Statistics, and Tour modules. 

However, they aren’t gone! Instead, they’ve been moved to the Drupal contrib space. If your website relies on any of these modules, a simple command can switch versions. The great news is that with new contrib maintainers, development will continue to improve these modules. 

The Tour module, which I presented about at DrupalCon Europe 2021, has already seen several improvements and bug fixes. It has combined my Tour Enhancements module and the Tour UI module in its 2.x release.

New Features in Drupal 11

Drupal 10.3 and 11 include several significant new features and improvements, including:

• The Drupal core Workspace module moved from being experimental to stable. You can create multiple workspaces for development, testing, and staging with Workspaces. Each workspace can have its own set of configurations and content, allowing you to test changes without affecting the live site. Developers have had multidev environments for a while. This is now the content editor’s version!
• Drupal now supports Single-Directory Components in core. SDCs provide a simplified front-end development workflow based on components, where all the files needed for the component are in the same directory. This increases developer productivity and makes components more shareable.
• The new Navigation module, which rewrites the admin toolbar using modern tools. This Navigation toolbar adds a collapsible left-aligned sidebar that organizes the administration menu and allows customization by including other blocks or menus.
• One of the most significant additions is the experimental Recipes API, for which I am a core subsystem maintainer. Recipes allow for the easy sharing of module configuration changes and additions, allowing you to add functionality without rebuilding it every time. An example recipe would add an Event system—and it includes everything you need, including a content type, taxonomies, a calendar view, meta tags, etc.
  
  Recipes are the backbone of the Drupal Starshot initiative which aims to create Drupal CMS, a new preconfigured install of Drupal.
  
  For an in-depth look at Recipes and how Starshot and we are using them, check out our on-demand webinar, Recipes, Starshot, and the Future of Drupal.
  
• The new Access policy API allows developers to create access verification and granting that extend well beyond Drupal’s already robust roles and permissions systems. Imagine you want to limit how many pages a person can make or restrict access to a site to only certain hours. You can now build custom policies to suit an ever-increasing number of options.

These are our favorite new features in Drupal 11. To learn more, visit Drupal.org’s Drupal 11 page.

Upgrading to Drupal 11

If you’re starting a new project today, there isn’t much holding you back from starting on Drupal 11. You may need to patch a couple of contrib module’s core_version_requirements, but more and more updates are happening daily.

Update to the latest version of Drupal 10.3. All sites upgrading from 10 to 11 must be on the latest version, so be sure to update to 10.3 first.

1. Update to PHP 8.3. Verify that your host, local development environment, and custom code all work with PHP 8.3, which is required for Drupal 11.
2. Run Upgrade Status and Drupal Rector.

This will find and fix any modules that need updating and deprecated code. 

If you’re a Kanopi client, we run rector on every pull request to ensure we catch and fix deprecations early, as most of the deprecations for Drupal 11 were documented on Drupal 10.2. If you want to learn more about our continuous website improvement services, please contact us.

You have time to upgrade!

Drupal 10 will continue to be supported until Drupal 12 is released in June 2026. This still gives you plenty of time to prepare your site if you have custom code or have contributed modules that need to be upgraded to PHP 8.3.

However, if your site can run on Drupal 10.3 and PHP 8.3, upgrading to 11 should be part of your short-term development plan — in order to stay current and take advantage of the additional performance enhancements and new tools available.

And if you need assistance, we’re here to help, as always.

At the keynote speech at DrupalCon 2022, Dries Buytaert, the founder of Drupal, presented the idea of “Starter templates” to help ambitious site builders quickly and easily create solutions. From that, the Distributions and Recipes initiative was born.

Drupal recipes are the foundation for the new Starshot Initiative, which aims to make Drupal easier to use and out of the box for all users. It took a couple of years, but Recipes have been added to Drupal core in 10.3 as Experimental APIs.

(If you prefer webinars, I gave a webinar on Recipes, Starshot, and the future of Drupal. Check it out.)

The Problem

For decades, developers have been packaging functionality together for Drupal to create different solutions, such as eCommerce stores, blogs, LMS, social media, and publishing sites. Many approaches were taken, each with its own pain points.

Installation Profiles

• You can only start with them.
• Once you start with them, you are stuck with them forever!
• You can’t change to a different install profile.

Distributions

• Complex dependencies that need to be maintained
• Updates could break customizations
• Would be hard to get solutions into Drupal core.

Features and Custom modules

• As with the above, these often become complex and hard to manage.
• Need update hooks or manual steps to alter core and other contrib module’s configuration.

The Solution

An issue has been created to add four new APIs to Drupal that will allow Recipes to be applied to Drupal. These recipes allow Drupal module automation, theme installation, and configuration at any time during the lifecycle of a Drupal site. They can install modules, import configuration, alter existing configuration, and even provide content to a Drupal site. Recipes are ephemeral; once applied, the results become the site’s responsibility.

What makes up a Drupal Recipe?

A recipe needs only a folder with the recipe’s name, which contains a recipe.yml file.  Beyond that, optional items are a /config folder, a /content folder, and a composer.json file. You can also include README.md and LICENSE.md files like a module or theme.

Recipe structure

• recipe_name folder
  • recipe.yml
  • /config folder
    • node.type.event.yml
  • /content folder
  • composer.json

recipe.yml structure

name: 'Event'
  type: 'Content type'
recipes:
  event_manager
install:
  datetime_range
  node
config:
  actions:
    user.role.event_manager:
      grantPermissions:
        'delete any event content'
        'edit any event content'

What can’t a Recipe do?

To keep things functional and sustainable, recipes can’t do certain things.  For instance, recipes can’t…

• Have their own code. If you need code, have your recipe install a module with that code.
• Make dynamic changes.
• Provide their own upgrade path (functionality is now part of the site).

Applying a recipe to an existing site

Recipes are applied to Drupal, not installed. Until the code is merged into Drupal core, you need to patch Drupal.  Patches can be found here on the project page.

Once you’ ha’ve patched your Drupal core version, you can use the internal script to apply a recipe to an existing site. On your command line, run the following command from your webroot:

php core/scripts/drupal recipe core/recipes/standard -v

This command uses PHP to find the “recipe” script in core/scripts/drupal. Then list the full path to the recipe. The -v flag has the recipe runner output the application steps as they happen on the command line. 

Once you apply the patch, you will get Drupal recipes from core! Core’s recipes currently include the Standard installation profile recreated as recipes. You can apply Standard and get all the functionality or apply them individually as needed. They were created to be very atomic — so that you can choose your own adventure.

Applying a recipe using Quick Start

Another Drupal script allows you to install Drupal from a recipe. When you do this, you do not start from an install profile! This is a new change. Previously, you at least had to start with a minimal profile; now, that is no longer needed.

If you’re starting a new Drupal install, you can use the following script:

php core/scripts/drupal quick-start core/recipes/article_content_type

The new Recipe APIs

The core of the recipe’s code are four new APIs.

• Drupal\Core\Config\Action
• Drupal\Core\Config\Checkpoint
• Drupal\Core\Recipe
• Drupal\Core\DefaultContent

The Recipe API depends on DefaultContent, Action, and Checkpoint. The other three APIs have no interdependencies.

Drupal\Core\Config\Checkpoint

A checkpoint is made for the site’s configuration when a recipe is applied. The recipe runner uses this to revert if the application fails, but there may be other uses for this in the future, like unapplying a recipe.

Drupal\Core\DefaultContent

This API’s code came from the contributed Default Content module. It allows recipes to provide content to Drupal using YAML files.

Drupal\Core\Config\Action

The Config Action API is the magic of the recipe system. It allows you to alter configurations already in a site, including core’s configs!

Drupal\Core\Recipe

Finally, the Recipe API puts it all together and applies the recipe. The recipe runner takes a recipe, and follows the following steps:

1. Applies dependent recipes
2. Install modules and themes
3. Imports configuration from the /config folder
4. Alters configuration based on actions
5. Imports content from the /content folder

Deep Dive into an Actual Recipe

This recipe creates two fully configured content types. It includes meta tags, paths, configured admin forms:

name: 'Saplings - Content types'
description: 'Configuration for the Saplings Content types.'
type: 'Site'
# Here we require other dependent recipes.
recipes:
  - saplings-content-base
  - saplings-component-types
# Now we install modules.
install:
  # Core.
  - menu_ui
  - tour
  # Contrib.
  - access_unpublished
  - field_group
  - metatag_open_graph
  - metatag_twitter_cards
  - pathauto
  - publication_date
  - scheduler
  - scheduler_content_moderation_integration
  - schema_article
  - simple_sitemap
  - token_or
  - ui_patterns_layouts
config:
  # Now can import configuration
  import:
    # Core.
    menu_ui: "*"
    # Contrib.
    access_unpublished: "*"
    pathauto: "*"
    # If we only want to import certain configs, we can identify them like this.
    scheduler:
      - scheduler.settings
      - views.view.scheduler_scheduled_content
  # Config actions are where we can change configuration in Drupal 
  actions:
    # Set Metatag Home page:
    metatag.metatag_defaults.front:
      simple_config_update:
        tags.canonical_url: '[site:url]'
        tags.description: '[node:sa_description|node:sa_seo_description]'
        tags.image_src: '[node:sa_seo_image:entity:field_media_image:sa_social_media_facebook|node:sa_featured_image:entity:field_media_image:sa_social_media_facebook]'
     tags.og_description: '[node:sa_description|node:sa_seo_description]'
    # Set permissions for anonymous role.
    user.role.anonymous:
      ensure_exists:
        id: anonymous
      grantPermissions:
        - 'access content'
        - 'access sitemap'
        - 'access_unpublished node sa_page'
        - 'access_unpublished node sa_post'
    # Set permissions for content editor role.
    user.role.content_editor:
      ensure_exists:
        id: content_editor
      grantPermissions:
        - 'access administration pages'
        - 'access block library'
        - 'access content overview'
        - 'access environment indicator'
        - 'access environment indicator ribbon'
        - 'access help pages'
        - 'access media overview'
        - 'access media_entity_browser entity browser pages'
        - 'access media_entity_browser_modal entity browser pages'

What are Config Actions?

As you can see in the recipe example above, you can import config from modules and themes, and take action against config that already exists. Config actions are written to make specific changes to config files — including Drupal core configuration files, which previously could only be done through update hooks.

Look for this list to update as the initiative digs into phase 2 and creates more recipes and possibilities.

Available to all config entities

simple_config_update

This is a config action that can be used to make foo: bar type updates to any configuration file.

setThirdPartySetting(s)

The setThirdPartySetting(s) config actions allows recipe authors to set third-party

settings values.  Add the ‘s’ to apply multiple third part settings.

ensure_exists

This action can be used to ensure as a user role exists before applying other actions.  It helps a recipe not fail if the role does not exist.

create

The create config action can be used to create a config entity, but it is much easier to just put the config file in the /config folder.

Applicable to specific config entity types

addItemToToolbar

Used to add a button to the toolbar of a CKEditor 5 editor.

addToAllBundles

Used to add a field to all bundles of an entity type. Should be used in combination with setComponent(s) below to make sure the field displays on forms and displays.

addNodeTypes, addTaxonomyVocabularies

Used to add editorial workflows to node and taxonomy bundles.

grantPermission(s)

Used to grant permissions to any user.role.* config files.  Add the ‘s’ to add multiple permissions.

setComponent(s)

Used to to add fields to an entity’s view or form display configs.

What’s next for Drupal Recipes?

Now that recipes are in Drupal core, the phase 2 of the roadmap will soon be updated. Integration with Project Browser, and recipe creation in Starshot are definitely on the top of the list, but there are lots more things to do.  Stay tuned and check out the issue queue to learn more!

Want to learn more via an on-demand webinar?

View Jim’s on-demand webinar on Drupal Recipes and Starshot.