[wip][RFC] LocalGov Drupal patching

[millnut]

Across the various projects which make up LocalGov Drupal we use ~16 patches which fix bugs, add additional functionality (to core or contrib modules) or ensure compatibility with PHP versions.

Project	Patches
localgov	2
localgov_campaigns	1
localgov_core	1
localgov_directories	2
localgov_events	1
localgov_microsites	2
localgov_microsites_group	4
localgov_paragraphs	2
localgov_services	1

The problem

We are now facing patch issues due to changes in Drupal core (10.1 vs 10.2) for example https://github.com/localgovdrupal/localgov_services/issues/237 which could mean maintaining a 10.1 and 10.2 version of the module due to the difference in patches.

This has the potential to become more common in future with the announcement of Drupal 10 being supported until 2026 (see https://www.drupal.org/blog/drupal-10-will-be-supported-until-the-release-of-drupal-12-in-mid-late-2026) and the release of Drupal 11 in June 2024.

Current Issues related to this and actions failing:

• Issue: https://github.com/localgovdrupal/localgov_services/issues/237
• Issue: https://github.com/localgovdrupal/localgov_paragraphs/issues/154
• Broken build: https://github.com/localgovdrupal/localgov_project/actions/runs/7457771866

With the recent release of Drupal 10.2, Drupal core now supports PHP 8.1-8.3 which means LocalGov Drupal needs to support PHP 8.3 as well as the contrib modules it uses which could mean further patches. Note PHP 8.1 is end of life in November 2024.

Possible solutions

LocalGov Drupal Patches package

Create a new composer package which manages all patches across modules. This will allow the creation of specific packages with specific requirements.

• 10.1 for Drupal 10.1 core and patches against it
• 10.2 for Drupal 10.2 core and patches against it

This will fix issues such as https://github.com/localgovdrupal/localgov_services/issues/237 as well as handle future core patch differences such as Drupal 11.

This could further expand for PHP compatibility patches such as 8.3 e.g. 10.1-php83, 10.2-php83.

Pros

• Single source for managing patches across projects
• Granular control of patches e.g. Drupal core version, PHP version specific releases
• Can use composer suggest functionality to make the user aware of which specific patch package they may require

Cons

• Responsibility on the user to use correct patch package
• Removing patches across all packages
• Will be a change that will need to be well documented and communicated to users when upgrading
• Change of working process when patching projects

Switch from cweagans/composer-patches to vaimo/composer-patches

Switching to the vaimo/composer-patches for patching functionality in composer will allow the use of version constraints for patches (see https://github.com/vaimo/composer-patches/blob/master/docs/USAGE_ADVANCED.md).

Pros

• Use version constraints for patches e.g. "php": ">=8.2.0"
• Patches maintained on a module/profile level
• Dependency patching (see https://github.com/cweagans/composer-patches/discussions/478#discussioncomment-7719049)

Cons

• Change from cweagans/composer-patches to vaimo/composer-patches across all packages
• Minor complexity increase to define versions constraints for patching specific packages e.g. drupal/core or PHP 8.1/8.2/8.3
• Pipelines with --ignore-platform-reqs might not handle platform requirements such as >= PHP 8.2