Updating Varbase ~9.0 to Drupal 10

Paved the way for a smoother upgrade process to Drupal 10

1. Read First Before Updating

Updating Varbase should always be done in a local or development environment. Once the update process is properly done and tested you can push your code and build to your production site. DO NOT update Varbase directly when in production.

​Drupal 9 is end of life - PSA-2023-11-01​

November 1, 2023 (UTC) Drupal 9 reaches end-of-life due to its dependency on Symfony 4. Reference: Symfony 4.4 release checker.

​Drush 11 support will end in November 2023

Updating Drush to the Latest Stable Version

2. Uninstall Removed Modules and Themes

This module is no longer needed

./bin/drush pm:uninstall better_normalizers

  • Issue #3392945: Removed the Better Normalizers module from Varbase Core

Obsolete Use of this project is deprecated.

Note that there will not be a version that works on D9 and D10, that's not possible because of the return type hint change for normalizers between Symfony 4 and 6.

Update the module first from ~2.0 to ~3.0 to run the migrate update process to switch allowed formatted fields to the Drupal ~10 processor.

composer update drupal/allowed_formats

./bin/drush updb

./bin/drush pm:uninstall allowed_formats

Since Drupal 10.1.0, limiting the text formats per field instance is a feature provided by Drupal core. Read https://www.drupal.org/node/3318572 for details.

In the 3.x branch of this module this feature has been removed as obsolete, but the module provide an update path from existing sites to move the allowed formats, as they were stored by the previous versions of the module, to Drupal >=10.1.0 way, in field settings.

The module provides also a feature that allows site builders to hide the formatted text format help and guidelines. Even this feature is still preserved in the 3.x module branch, there is an issue that aims to move it in Drupal core in the future. See https://www.drupal.org/i/3323007.

Better to upgrade the Rabbit Hole module from ~1.0 to ~2.0 before the upgrade.

composer update drupal/rabbit_hole

./bin/drush updb

Seven was the default administrative theme for Drupal 7, 8, and 9. In Drupal 10, it was replaced by Claro.

Some Drupal 10 sites may still require or prefer Seven, so it's available here as a contrib theme.

Run the following to uninstall it only if it was not disabled before the upgrade

./bin/drush theme:uninstall seven

When upgrading an old Varbase ~8 site which was upgraded to Varbase ~9, but the quick edit module was not disabled yet, ( It was only deprecated, but removed from Drupal ~10 ).

Make sure to uninstall the module before upgrading to Drupal 10

Changed Varbase Admin - Removed QuickEdit from Varbase Core too

Switch From Swift Mailer to Symfony Mailer

Swiftmailer is no longer supported and it's marked as a security issue.

Bringing a security issue with the composer No longer supported in Drupal

Not supported!

Swift Mailer - Moderately critical - Access bypass - SA-CONTRIB-2024-006 Project not supported: This project is no longer supported, and is no longer available for download. Disabling everything included by this project is strongly recommended! --- Uninstall this module immediately. The swiftmailer library has been unsupported for a year, and this module is now also unsupported. Switch to Symfony Mailer in systems.

Switch From Swift Mailer to Symfony Mailer

3. Check for Drupal 10 Compatibility

Use the Upgrade Status module to check on extra used contrib or custom modules and themes in projects.

In numerous projects, contrib modules frequently contain outdated PHP code, including deprecated classes, functions, or libraries. Moreover, many of these projects make use of deprecated JavaScript components, such as JQuery UI libraries, or employ outdated Drupal 9 methods.

97% of all Modules are Drupal 10 Compatible https://www.youtube.com/live/08FaXNSVDrA?si=z-MhnnCfS9bUtnGj&t=7455 Only ~ 3% of modules are not compatible.

  • Push for maintainers ( by issues, Contact, ask them to commit and release )

  • Ask maintainers to give you a co-maintainer role so that you can commit and release

  • If the above did not work. Fork not compatible modules ( because they are not well maintained )

  • If we can drop the use of not well maintained module, do that by having the code in the project as a local custom module and remove it from the composer.json file

4. Update old Varbase ~9.0.0 to ~9.1.0 in composer.json File

Important to read and follow with all steps from the beginning of this page.

  1. Update the project to latest version of Varbase ~9.0.0

  2. Change "vardot/varbase": "~9.0.0", to "vardot/varbase": "~9.1.0", in the root composer.json file.

  3. Add "drupal/core": "~10", in the root composer.json file.

  4. Change drupal/core-composer-scaffold to ~10 in the root composer.json file.

  5. Change drupal/core-project-message to ~10 in the root composer.json file.

  6. Change "drupal/core-dev": "~10", in the root composer.json file.

  7. Have the composer as in https://github.com/Vardot/varbase-project/blob/9.1.0/composer.json​

  8. Run composer update number of times ( do that 3 times min )

  9. Run ./bin/drush updb number of times ( do that 3 times min)

✅ Released Varbase 9.0.18 ( Drupal ~9 old way ) ✅ Released Varbase 9.1.0 ( Drupal ~10 old way ) for upgrades ✅ Released Varbase 10.0.0-rc1 ( Drupal ~10 new way - it's a migration track not an update)

Dropping support for Drupal ~9

Sailing Smoothly with Drupal 10: A Blueprint for Long-Term Success

Fix Non-existent Permissions Issues

Have the system faced an issue with missing static or dynamic permissions while updating/upgrading? or after disabling/uninstalling a module?

Drush Command to Fix Non-existent Permissions in Varbase

  1. Update the Varbase Core module to 9.1.7 or later.

  2. Run the following drush command

drush varbase:remove-non-existent-permissions

Remove non-existent permissions, to be used for upgrades with missing static and dynamic permissions

Before or After Uninstalling a Module

Better to remove all permissions first for all user roles for the module before the uninstall. That can be from the Drupal UI page for permissions. Or:

Use Drush to remove specified permission(s) from a role

Have the system faced errors when uninstalling a module?

Permissions could be removed one by one and from user roles with Drush.

Use the remove specified permission(s) from a role method

Example:

If for some reason the Admin Audit Trail module wanted to be uninstalled under Drupal ~10.1.0 in a project.

In case of uninstalling without removing permissions first, the system may face issues with non-existent permissions to a role is not allowed.

Run the following drush commands to remove 'access admin audit trail' for the default user roles, or other custom user roles in the project:

./bin/drush role:perm:remove anonymous 'access admin audit trail'

./bin/drush role:perm:remove authenticated 'access admin audit trail'

./bin/drush role:perm:remove editor 'access admin audit trail'

./bin/drush role:perm:remove content_admin 'access admin audit trail'

./bin/drush role:perm:remove seo_admin 'access admin audit trail'

./bin/drush role:perm:remove site_admin 'access admin audit trail'

This method can be used before or after uninstalling a module.

List all user roles which have the permission, using the display roles and their permissions.

./bin/drush role:list --filter='access admin audit trail' --format='list'

The out put will be in a list:

editor

content_admin

seo_admin

site_admin

So that in this case the following is needed to remove:

./bin/drush role:perm:remove editor 'access admin audit trail'

./bin/drush role:perm:remove content_admin 'access admin audit trail'

./bin/drush role:perm:remove seo_admin 'access admin audit trail'

./bin/drush role:perm:remove site_admin 'access admin audit trail'

Some modules use the dynamic permissions option for custom plugins, entity types, blocks, terms. To grant extra limited permissions for user roles.

Run the following command to do the bulk remove for non existent permissions, in case not wanting to do that one by one.

Fix Mismatched Entity or Field Definitions Issues

Have the system faced issues with mismatched entity or field definitions while updating/upgrading?

Drush Command to Fix Mismatched Entities in Varbase

  1. Update the Varbase Core module to 9.1.7 or later.

  2. Run ./bin/drush varbase:entity-update

drush varbase:entity-update

Entity updates to clear up any mismatched entity and/or field definitions. Fix changes were detected in the entity type and field definitions.

Important Issues

Permissions must exist

Invalid permissions will trigger runtime exceptions in Drupal 10. Permissions should be defined in a permissions.yml file or a permission callback.

The skip_missing_permission_deprecation flag that was added in Drupal 9 to the Role entity in #2571235: [regression] Roles should depend on objects that are building the granted permissions.

Modules cannot be in a disabled state anymore, only installed and uninstalled #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed

It was removed from the 10.0.x and 10.1.x branch.

#2953111: Only migrate role permissions that exist on the destination

Not able to connect to the Database after upgrading from Drupal 9 to 10

In case of using MySQL database

Edit the $databases['default']['default'] in settings.php or local.settings.php file.

  1. Remove the old namespace

'namespace' => 'Drupal\Core\Database\Driver\mysql',

  1. Add the following in the database settings

'namespace' => 'Drupal\mysql\Driver\Database\mysql',

'autoload' => 'core/modules/mysql/src/Driver/Database/mysql/',

PreviousVersion Update GuidesNextSwitch from CKEditor 4 to CKEditor 5 in Varbase ~9.1.0

Last updated