0

There is a specialized fix to a contrib theme that I am trying to apply. Because this theme is in the .gitignore file, it's incumbent upon me to generate a patch that composer can include. Please note that the dependency "cweagans/composer-patches" is required. Pantheon is using the composer.lock file and I cannot get composer update to find the target file. I built the patch file using diff and modified its headers like other successful Drupal patches. In composer.json

"patchLevel": {
        "drupal/core": "-p2",
        "drupal/dxpr_theme": "-p1"
    },
"enable-patching": "true",
    "patches": {
      "drupal/dxpr_theme": {
        "header patch": "./patches/header.patch"
      }

and the headers of header.patch

index fakehash..fakehash1 100644
--- a/js/dist/dxpr-theme-header.js
+++ b/js/dist/dxpr-theme-header.js
@@ -4,7 +4,7 @@

Since there is no git commit with this theme I faked a couple of hashes but left the line in, thx for the comment @Clive. Ensuring that in context of this theme folder I was able to successfully run the patch using patch -p1 < ../../../../patches/header.patch

In context of the Drupal project I ran: composer --verbose update ---lock

Applying patches for drupal/dxpr_theme ./patches/header.patch (header patch) patch '-p1' --no-backup-if-mismatch -d 'web/themes/contrib/dxpr_theme' < '/Users/sam/apps/myproject/patches/header.patch' patching file js/dist/dxpr-theme-header.js Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch.

What's curious is that the file is updated but I find no evidence in composer.lock. Perhaps it is and I don't know how it's indicated? I have removed any file with .rej, .orig and reset the target file to before any patch attempts. Same state as my successful attempt at patch by itself, apart from composer.

As mentioned, if I can get composer to update this file after patching I can then see if the composer.lock file is applying this patch.

Improve this question
7
  • 2
    Confirm that the patch command can apply your patch in the theme’s root directory. This may be closed as not pertaining directly to Drupal.
    – mona lisa
    Commented Feb 19, 2023 at 23:17
  • If you look at every patch on drupal.org (and I've also looked at a few dozens custom patches across a few projects to confirm the same), they all have 2 extra lines in the header. diff, and the index one you mentioned. Whenever I generate custom patches I leave those lines in there, regardless, and I've never had a problem. Try restoring those first two header lines and see what happens
    – Clive ♦
    Commented Feb 20, 2023 at 0:16
  • If it's not that, I think non-git patches might default to patch level 1, and your diff is for level 0. You could try adding "patchLevel": {"drupal/dxpr_theme": "-p0"} to extra in composer.json
    – Clive ♦
    Commented Feb 20, 2023 at 0:32
  • Did you show us the precise output?
    – mona lisa
    Commented Feb 20, 2023 at 10:11
  • 1
    >What's curious is that the file is updated but I find no evidence in composer.lock. Thats because it is removed in composer v2 , it was present in composer v1. There is a PR raised to reintroduce it in v2. Which is not merged yet.
    – miststudent2011
    Commented Feb 21, 2023 at 7:07

1 Answer 1

Reset to default
1

It needs to be

"header patch": "./patches/header.patch"

and then run

composer update --lock

and it will apply the patch.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.