9.0.x

Varbase Patches

When working with Drupal, it's common to patch core or contrib modules to fix bugs or review code changes before they're officially released. While applying patches via patch files is straightforward, using GitLab's merge request (MR) feature presents a challenge due to unstable diff URLs.

As multiple commits are added to an MR, generating a stable patch file becomes complex. To create a static patch file for an MR at a specific point in time, simply set up a 'patches' folder next to your root composer.json. Download the .diff or .patch into this folder and utilize composer-patches to apply it seamlessly.

Varbase Patches has the list of needed patches for Varbase used packages with Composer Patches.

Use "vardot/varbase-patches": "~10.0.0"

with Varbase ~10.0.0 CKEditor 5 and Drupal 10

Use "vardot/varbase-patches": "~9.1.0"

with Varbase ~9.1.0 CKEditor 4 and Drupal 10

Use "vardot/varbase-patches": "~9.2.0"

with Varbase ~9.1.0 CKEditor 5 and Drupal 10

Managing Only Local Patches for Projects

When there's a need to handle local patches for a project without relying on Varbase Patches.

No patches for Varbase ~10.0.0

With CKEditor 5 and Drupal 10 : Use the "Vardot/varbase-patches": "10.0.0.0" static version to have no patches and manage local patches in the project with a copy of patches from https://github.com/Vardot/varbase-patches/blob/10.0.x/composer.json

No patches For Varbase ~9.1.0

With CKEditor 4 and Drupal 10 : Use the "Vardot/varbase-patches": "9.1.0.0" static version to have no patches and manage local patches in the project with a copy of patches from https://github.com/Vardot/varbase-patches/blob/9.1.x/composer.json

No patches For Varbase ~9.1.0

With CKEditor 5 and Drupal 10 : Use the "Vardot/varbase-patches": "9.2.0.0" static version to have no patches and manage local patches in the project with a copy of patches from https://github.com/Vardot/varbase-patches/blob/9.2.x/composer.json

Storage of Local Patches Branch

This Patches branch is a storage branch for the list of needed local patches.

Ones a patch is added, never to be deleted!

It should be considered a permanent part of the solution and should not be deleted under normal circumstances. Deleting patches can lead to unexpected behavior or loss of functionality, especially if other components of the system depend on them.

New patches should follow the following in the name of the patch file

[package name]--[Date]--[issue number]-[comment number]--[MR number/commit number].patch

Branch name for the package could be added too.

This will be a copy of Merge Request (MR), as it is important not to add .diff or .patch link to an MR as the code could change in anytime.

Examples of Names for Local Patch files:

  • drupal-core--2024-01-09--3049332-85.patch

  • drupal-core--10-2-x--3046152-49.patch

  • rabbit_hole--2024-02-04--3419073-3.patch

  • ui_patterns_settings--2023-12-17--3409221-3--mr-21--39e896da.patch

Why Direct Links for Merge Requests Aren't Preferred

To understand the process better, consult the Drupal Contributor Guide , and Creating merge requests for detailed instructions on handling issues.

When creating merge requests, it's better to use composer-patches' solution for dealing with merge request URLs from drupal.org. This solution adds support for patch checksums, preventing issues where the new patch wouldn't apply due to checksum mismatches.

Such issues can disrupt builds, compromising stability and security. Note that this solution is included in version 2, which hasn't been officially released at the time of writing.

Choosing direct merge requests over patching isn't the best option for maintaining stability, especially considering Drupal's shift from patching to merge requests.

As you implement these changes, it's recommended to convert existing patches into merge requests. Merge requests are preferred over patches in the Drupal community.

Therefore, necessary patches originating from merge requests will be stored in this designated storage branch.

Handling Varbase Patches Ignoring

Suppose you need to exclude a specific patch while utilizing Varbase Patches in your site. For instance, let's consider the scenario where you wish to either enhance an existing patch or disregard it altogether.

To achieve this, incorporate the following snippet into your root composer.json file:

Copy

"patches-ignore": {
  "vardot/varbase-patches": {
    "drupal/core": {
      "Issue #2869592: Disabled update module shouldn't produce a status report warning":
      "https://www.drupal.org/files/issues/2869592-remove-update-warning-7.patch",
    }
  }
}

By integrating this set, you effectively instruct Composer to overlook the specified patch within Varbase Patches. This empowers you to manage patches more efficiently, whether by improving them or opting out of certain patches altogether.

PreviousUpdating a Varbase SiteNextUnderstanding Varbase Updater Package

Last updated