-
Notifications
You must be signed in to change notification settings - Fork 1.7k
HowDoI: Create a tutorial for patching a composer project from github #1956
Changes from 7 commits
9a2e929
54c4a03
ed1f664
b10c253
e358e87
47bd878
43fcab6
f353f52
c52502b
a775db1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
--- | ||
group: howdoi | ||
title: Create a GitHub patch for a Composer installation | ||
version: 2.2 | ||
github_link: howdoi/patch_from_github.md | ||
functional_areas: | ||
- Install | ||
- System | ||
- Setup | ||
--- | ||
|
||
Sometimes it takes a while for us to include a bug fix made on GitHub in a Magento 2 Composer release. In the meantime, you can create a patch from GitHub and use the `composer-patches` plugin to apply it to your Composer-based Magento 2 installation. | ||
|
||
<div class="bs-callout bs-callout-warning" markdown="1"> | ||
Always perform comprehensive testing before deploying any unreleased patch. | ||
</div> | ||
|
||
## Create a patch | ||
|
||
To create a patch file from a GitHub commit or pull request, append `.patch` to the url, [https://github.com/magento/magento2/commit/2d31571f1bacd11aa2ec795180abf682e0e9aede.patch](https://github.com/magento/magento2/commit/2d31571f1bacd11aa2ec795180abf682e0e9aede.patch). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This URL shows you the patch file, but doesn't actually create it for your purposes. I think you copy the contents, and paste it into the file described in line 31. When take the link, I see this at the top:
Does any of this need to be deleted? It's certainly not essential, but maybe the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dmanners, deferring to you on this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Alternatively, you can also add And yes, it's best if you then download that file and put it in the directory mentioned below: Some other additions here:
So maybe we'll need to add some section about how you find the correct commit (or even multiple commits) for a certain fix. Which will probably be pretty complex to write down...
Feel free to ignore these things above if this would make the documentation more complex then it needs to. It might scare users or confuse them ... |
||
|
||
<div class="bs-callout bs-callout-info" markdown="1"> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Give an example of what needs to be changed. Would you change every instance of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dmanners, deferring to you on this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Indeed, example would be very useful here. BTW: the So in this specific case, you would replace all instances (5 times) of (But if it would be considered easier to understand, then just replace Btw, maybe good to mention as a warning: you shouldn't make these changes with an actual code editor, since they sometimes strip out trailing whitespace or adding new lines depending on how they are configured, which can sometimes mess up the patch file. I prefer a very old school editor which doesn't do any fancy stuff like that. On macOS I'm using the built-in TextEdit application for this. For Windows, I'm assuming you can use the built-in Notepad? And for Linux, just vim or nano probably? |
||
You must change the paths in the patch file to correspond to the `vendor/***` directories. | ||
</div> | ||
|
||
## Apply a patch | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd like to see more of an intro paragraph. The following example applies the X patch to .... |
||
1. Create a `patches/composer` directory. | ||
1. Prepare your patch file so that the paths are relative to the `vendor/<VENDOR>/<PACKAGE>` directory. For example `vendor/magento/module-payment`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See comment above about original intent of the |
||
1. Name the patch file appropriately and move it to the `patches/composer` directory. | ||
2. Add the `cweagans/composer-patches` plugin to the `composer.json` file. | ||
|
||
```bash | ||
composer require cweagans/composer-patches | ||
``` | ||
|
||
1. Edit the `composer.json` file and add the following section, specifying the Composer package to apply the patch to, as well as a description of the patch and a reference to the file location: | ||
|
||
```json | ||
"extra": { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dmanners, deferring to you on this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You should merge the lines unless it doesn't already exist, then you have to create one. |
||
"magento-force": "override", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would remove this |
||
"composer-exit-on-patch-failure": true, | ||
"patches": { | ||
"magento/module-payment": { | ||
"MAGETWO-56934: Checkout page freezes when ordering with Authorize.net with invalid credit card": "patches/composer/github-issue-6474.patch" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, it looks like there are 3 key elements that need to be called out: Affected module: "magento/module-payment" Line 31 should give an indication of what an appropriately named patch would be. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dmanners, deferring to you on this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correct! The title is also arbitrary here, you can put in it what makes sense to you. Also, if multiple modules are involved with a patch file, you need multiple patch files targeting multiple modules. |
||
} | ||
} | ||
} | ||
``` | ||
|
||
2. Apply the patch. | ||
|
||
```bash | ||
composer install | ||
``` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If a patch can't be applied, composer will complain with an error message: This is not very helpful, so sometimes it helps if you could get some more debugging output about why a patch doesn't want to apply. This can maybe be added to some troubleshooting section? |
||
|
||
1. Update the `composer.lock` file. The lock file tracks which patches have been applied to each Composer package in an `extra > patches_applied` object. | ||
|
||
```bash | ||
composer update <PACKAGE NAME> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I prefer |
||
``` |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
../../v2.1/howdoi/patch_from_github.md |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
../../v2.2/howdoi/patch_from_github.md |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You sometimes see devs complaining about not wanting to install a patch but prefer to build a custom M2 module which fixes the bug by rewriting the original code.
This is a very personal opinion, but I think that using a patch is better in most cases, because if you upgrade Magento to a new version and it contains a fix for what you patched, composer will start complaining that it can no longer apply the patch. So you'll automatically go looking for a reason why it doesn't apply and you'll find that it was fixed in this particular new version and you can then remove the patch.
You wouldn't get notified about that if you use a custom build module. So you would have to keep that in mind to check all your custom modules with fixes after every Magento update.
Not sure if this makes a good addition to this page though, since it's a very personal opinion.
I would also add a link to the
cweagans/composer-patches
module, since its readme file contains useful information which explains all the options you can use: https://github.com/cweagans/composer-patches/There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's great context. I'm not sure if it's necessary yet, but I may add it later. I'll definitely add a link to the package.