Overriding Varbase

First Rule in Overriding

Do not change the original code of Drupal Core, Varbase, Vartheme or any other Varbase components. In another words "Do not hack the original code without a trace for the change"

Use the standard Drupal overriding methods.

Custom Tweak Modules

Create custom modules and have your override in them.

Patching Bugs

In case of capturing a bug. Search if it was filed in an issue. Look if the a patch fix for the issue was uploaded.

Apply the patch using the Composer patching method using:

cweagans/composer-patches

Do not use the manual patching method in projects.

This action will guarantee the direction of keeping track of changes over the code.

Example: In the composer.json file for the project:

{
  "name": "vardot/varbase-project",
  "description": "Project template for Varbase distribution.",
  "type": "project",
  "license": "GPL-2.0-or-later",
  
  ...
  ...
  ...
  
  "require": {
    "composer/installers": "~1.0 || ~2.0",
    "oomphinc/composer-installers-extender": "~1.0 || ~2.0",
    "cweagans/composer-patches": "~1.0",
    "drupal/core-composer-scaffold": "^9",
    "drupal/core-project-message": "^9",
    "webflo/drupal-finder": "~1.0",
    "webmozart/path-util": "~2.0",
    "vardot/varbase": "~9.0",
    "vardot/varbase-updater": "~2.0"
  },
  "extra": {
    "enable-patching": true,
    "composer-exit-on-patch-failure": true,
    "patchLevel": {
      "drupal/core": "-p2"
    },
    "patches": {
      "drupal/core": {
        "Issue 1543858: Add startup configuration for PHP server":
        "https://www.drupal.org/files/issues/add_a_startup-1543858-30.patch"
      }
    }
  }
}

Please add the "Issue Number" and the URL for the used patch

Patch for a New Enhancements

An introductory patch for an enhancement over a Varbase component or any Drupal project is welcomed.

A patch may not be committed on the spot. It will need review, and testing for what affect it may do for websites.

A patch will work. But although a custom module is the better logic.

Ignoring Patches

Using the cweagans/composer-patches composer plugin with patches-ignore

There may be situations in which you want to ignore a patch supplied by a dependency. For example:

  • You use a different more recent version of a dependency, and now a patch isn't applying.

  • You have a more up to date patch than the dependency, and want to use yours instead of theirs.

  • A dependency's patch adds a feature to a project that you don't need.

  • Your patches conflict with a dependency's patches.

Example:

The Varbase Core module is requiring Drupal Core with "drupal/core": "~9.0", . Having number of patches to fix issues or overriding Drupal core.

Varbase Core's composer.json file for the 9.0.7 version

https://github.com/Vardot/varbase_core/blob/9.0.7/composer.json#L138

Let imagine that the Drupal core release team had a new release, But they had committed the following issue:

The patch fix for the core issue was added when a fix was needed for the following issue:

At the point of a new release for Drupal core and in case the patch was committed.

The cweagans/compsoer-patches composer plugin will not allow to apply it if it was committed.

Ignore the patch being used as in the following example method:

{
  "name": "vardot/varbase-project",
  "description": "Project template for Varbase distribution.",
  "type": "project",
  "license": "GPL-2.0-or-later",
  
  ...
  ...
  ...
  
  "require": {
    "composer/installers": "~1.0 || ~2.0",
    "oomphinc/composer-installers-extender": "~1.0 || ~2.0",
    "cweagans/composer-patches": "~1.0",
    "drupal/core-composer-scaffold": "^9",
    "drupal/core-project-message": "^9",
    "webflo/drupal-finder": "~1.0",
    "webmozart/path-util": "~2.0",
    "vardot/varbase": "~9.0",
    "vardot/varbase-updater": "~2.0"
  },
  "extra": {
    "enable-patching": true,
    "composer-exit-on-patch-failure": true,
    "patchLevel": {
      "drupal/core": "-p2"
    },
    "patches": {
      "drupal/core": {
        "Issue 1543858: Add startup configuration for PHP server":
        "https://www.drupal.org/files/issues/add_a_startup-1543858-30.patch"
      }
    },
    "patches-ignore": {
      "drupal/varbase_core": {
        "drupal/core": {
          "Issue #3165435: Fix tour <front> route as route name when a selected node had been set as the front page for the site":
          "https://www.drupal.org/files/issues/2020-08-16/3165435-2.patch"
        }
      }
    }
  }
}

If you use the URL to the Gitlab MR directly, your code base will change without warning, as people work on the merge request.

https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupal/creating-issue-forks-and-merge-requests#s-patch-files-f[…]se-with-composer

  • Download the .diff or .patch file in a patches folder in the project.

  • Add the module name, issue number, and date for the MR changes to the name of the file.

  • Add the patch local patch to patches.

Example ( NOT Recommended ):

    "patches": {
      "drupal/gin_login": {
        "Issue #3342318: Fix Gin Login Wallpaper images with the Origin URL (scheme and HTTP host) of the site":
        "https://git.drupalcode.org/project/gin_login/-/merge_requests/19.diff"
      }
    }

Example ( Recommended remote patch file ):

    "patches": {
      "drupal/gin_login": {
        "Issue #3342318: Fix Gin Login Wallpaper images with the Origin URL (scheme and HTTP host) of the site":
        "https://www.drupal.org/files/issues/2023-02-16/3342318-3.patch"
      }
    }

Example ( Recommended local patch/diff file ):

    "patches": {
      "drupal/gin_login": {
        "Issue #3342318: Fix Gin Login Wallpaper images with the Origin URL (scheme and HTTP host) of the site":
        "patches/gin_login-2023-02-16--3342318-19.diff"
      }
    }

Last updated