disrex / magento-patch-installer
Applies Magento 2 / Adobe Commerce security patches, verifies they stay applied, and fails loudly when they do not
Package info
github.com/disrex-group/magento-patch-installer
Type:composer-plugin
pkg:composer/disrex/magento-patch-installer
Requires
- php: >=7.4
- composer-plugin-api: ^2.0
Requires (Dev)
- composer/composer: ^2.2
- phpstan/phpstan: ^2.2
- phpunit/phpunit: ^9.6 || ^10.5 || ^11.5
Suggests
None
Provides
None
Conflicts
None
Replaces
None
This package is auto-updated.
Last update: 2026-10-15 17:15:26 UTC
README
A Composer plugin that applies patches to Magento 2 and Adobe Commerce, checks on every Composer run that they are still on disk, and fails the run when one is missing. It was built for Adobe's monthly isolated security patches, which a store only receives by applying the files itself.
Full documentation: https://disrex-group.github.io/magento-patch-installer/
Install
composer config --no-plugins allow-plugins.disrex/magento-patch-installer true composer config --json extra.magento-patches.trust '["disrex/*"]' composer require disrex/magento-security-patches
You only require the patch package; this installer comes with it as a dependency. The allow-plugins line names the installer because it is the plugin Composer has to trust. Without that line a CI run skips the plugin without a word and exits 0 on an unpatched store. Without trust the run fails and names the package.
Use
composer magento-patches:status # the store and every patch meant for it composer magento-patches:verify # exit 0 only when everything is in place; writes nothing composer magento-patches:apply # apply what is missing; --dry-run to only report composer magento-patches:list # what the trusted packages declare composer magento-patches:lock # write magento-patches.lock; --check for CI
A patch package can mark a patch optional. It stays off until the project enables it under extra.magento-patches.sources with a reason; see Declaring patches.
Exit codes: 0 all in place, 1 missing, 2 conflict, 3 configuration error. Run verify as its own pipeline step after composer install.
What it guarantees
- Every verdict comes from asking
git applyabout the file on disk, so a reinstalled package that lost its patch is found and patched again. - A patch Adobe re-issues with other content replaces the old one on stores that already have it.
- A patch goes on whole or not at all, and a file that matches neither side is never overwritten.
- Root files that Magento copies from
magento/magento2-baseare patched in both places.
Requirements
Magento 2.4.4 or later or Mage-OS 1.0 or later, PHP 7.4 to 8.5, Composer 2.2 or later, and git on the PATH. CI runs the end-to-end check on Magento 2.4.6-p15 to 2.4.9 and Mage-OS 1.3.1, 2.3.0 and 3.6.0.
Development
composer install composer lint && composer analyse && composer test tests/e2e-local.sh ~/path/to/a/magento/project # against a copy of a real store
Releases use git-cliff with conventional commits:
git cliff --bump -o CHANGELOG.md git commit -am "chore(release): X.Y.Z" && git tag X.Y.Z && git push origin master X.Y.Z
The tag triggers the GitHub release, and Packagist picks it up through its webhook.
License
MIT, see LICENSE. Security issues: see SECURITY.md.