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.1.0"

---

Managing Only Local Patches for Projects

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

Remove Varbase Patches in Varbase ~10.1.0

With CKEditor 5 and Drupal ~11 : Use the "Vardot/varbase-patches": "10.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/10.0.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.

• Patches from drupal.org merge request URLs are dangerous?

• Add support for patch checksums.

• composer-patches 2.0.0 hasn't been released yet

---

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.

All keys live under extra in your project's root composer.json.

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

composer-patches.allowed-dependency-patches

List of package-name patterns. Only packages matching this list contribute patches via the dependency resolver.

• Type: array of strings

• Pattern: fnmatch (so drupal/*, vardot/*, *-patches all work)

• Default: ["vardot/varbase-patches"]

{
  "extra": {
    "composer-patches": {
      "allowed-dependency-patches": ["vardot/varbase-patches"]
    }
  }
}

If you want to also accept patches from another vendor:

{
  "extra": {
    "composer-patches": {
      "allowed-dependency-patches": [
        "vardot/varbase-patches",
        "myorg/myorg-patches"
      ]
    }
  }
}

composer-patches.ignore-dependency-patches

List of package-name patterns to exclude after the allowlist is applied. Useful when you widen the allowlist with a wildcard and need to carve out exceptions.

• Type: array of strings

• Pattern: fnmatch

• Default: []

{
  "extra": {
    "composer-patches": {
      "allowed-dependency-patches": ["drupal/*", "vardot/*"],
      "ignore-dependency-patches": ["drupal/ai_context"]
    }
  }
}

When allowed-dependency-patches is set to the default ["vardot/varbase-patches"], ignore-dependency-patches is redundant — nothing else passes the allowlist.

patches-ignore

Drop specific patch URLs declared by a given dependency against a given target package. Restored from cweagans/composer-patches v1.

• Type: nested object

• Default: {}

Two equivalent schemas are accepted. The v1-style description-keyed map (matches the format used in the upstream Varbase docs):

{
  "extra": {
    "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"
        }
      }
    }
  }
}

Or a flat array of URLs:

{
  "extra": {
    "patches-ignore": {
      "vardot/varbase-patches": {
        "drupal/some_module": [
          "https://www.drupal.org/files/issues/.../some.patch"
        ]
      }
    }
  }
}

Matching is done by URL string. The description (if you use the dict form) is informational only — vardot/varbase-patches and the consumer can disagree on the description and the URL still matches.

Composer Command to Clean up Any Merge Request Patches

Clean up the Root `composer.json` File

Name: varbase-patches:composer:cleanup:patches Aliases: var-ccup Description: This command detects any merge request patches, downloads them to the local patches folder with a timestamp, and updates the root `composer.json` file to use the timestamped local patch file.

Example:

composer varbase-patches:composer:cleanup:patches

or

composer var-ccup

Clean up the External `patches-file` JSON File

Name: varbase-patches:composer:cleanup:patches-file Aliases: var-ccupf Description: This command detects any merge request patches, downloads them to the local patches folder with a timestamp, and updates the `patches-file JSON` file to use the timestamped local patch file.

Example:

composer varbase-patches:composer:cleanup:patches-file

or

composer var-ccupf