Patches and Updates

A -p release is security fixes only; isolated patches go through the Quality Patches Tool and are tested against the latest -p.

Syntaxcomposer require magento/product-community-edition 2.4.9-p1 --no-update

Fixes arrive in two shapes. A patch release is a new version of the whole application: 2.4.9-p1 is 2.4.9 plus security fixes and nothing else, installed by changing a Composer constraint. An isolated patch is a single file Adobe publishes for one problem, applied on top of a patch release.

Cadence and support dates

The 2.4 line gets one full release a year, in May, plus security patches at least annually for every supported line. 2.4.9 reached general availability on 12 May 2026 and its regular support ends 31 May 2029. 2.4.8 (8 April 2025) runs to 31 May 2028. 2.4.7 (9 April 2024) runs to 31 May 2027, with extended support to 31 May 2028. Those dates are what decide an upgrade, because an unsupported line stops receiving security patches altogether.

Applying them

A patch release is a version change on the metapackage followed by the ordinary upgrade commands: setup:upgrade, setup:di:compile, setup:static-content:deploy, cache:flush.

Isolated and quality patches go through the Quality Patches Tool, the Composer package magento/quality-patches. ./vendor/bin/magento-patches status lists what applies to the installed version, apply and revert take patch ids, and every operation is written to var/log/patch.log. Patches you wrote or received as files belong in composer.json under cweagans/composer-patches, so they are reapplied on each install rather than living in someone's shell history.

Example

Example · bash
# Run from the Magento root. Moves a 2.4.9 install to the latest
# security-only patch release, then rebuilds everything it touched.

composer require magento/product-community-edition 2.4.9-p1 --no-update
composer update --with-all-dependencies

php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f
php bin/magento cache:flush

# Shorthand for the first two lines, which does the same thing:
#   composer require magento/product-community-edition 2.4.9-p1 \
#       --update-with-all-dependencies

php bin/magento --version
# Magento CLI 2.4.9-p1

./vendor/bin/magento-patches status
# Magento 2.4.9-p1 (Open Source)
#
# Patch ID    | Title | Type | Status | Details
# ------------+-------+------+--------+--------
# (one row for every patch that applies to this version, with Status
#  reading Applied, Not applied or N/A)

When to use it

  • Decide whether to move to the next -p release or to the next full release in May.
  • Apply an isolated security patch Adobe published between releases.
  • Keep a one-off vendor fix in the repository so a clean build reproduces it.
  • Work out whether a site's Magento version still receives security patches at all.

More examples

A patch file tracked in composer.json

This is the root composer.json of the project. The patch file lives in the repository under patches/composer/ and is applied whenever the patched package is installed, so a fresh composer install on a build server produces the same code as your laptop. composer-exit-on-patch-failure turns a patch that no longer applies into a failed build instead of a silently unpatched deploy. Reach for this for an isolated patch Adobe sent you and for any change you cannot wait for upstream to take.

Example · json
{
    "require": {
        "magento/product-community-edition": "2.4.9-p1",
        "cweagans/composer-patches": "^1.7"
    },
    "extra": {
        "composer-exit-on-patch-failure": true,
        "patches": {
            "magento/module-catalog": {
                "APSB26-xx: escape attribute label in layered navigation":
                    "patches/composer/APSB26-xx-catalog-layered-nav.patch"
            }
        }
    }
}

Checking where you actually are before upgrading

Run this before every upgrade and keep the output. The composer show version is authoritative: a partially completed upgrade can leave bin/magento --version and the installed packages disagreeing. The saved patch status is what you compare against afterwards to see which patches the new release absorbed.

Example · bash
# What the application reports
php bin/magento --version
# Magento CLI 2.4.9

# What Composer resolved, which is the version that matters
composer show magento/product-community-edition | head -n 3
# name     : magento/product-community-edition
# descrip. : eCommerce Platform for Growth (Community Edition)
# versions : * 2.4.9

# Which patches the tool thinks apply to that version
./vendor/bin/magento-patches status > var/log/patch-status-before.txt

# PHP in use must match what the release supports.
# Magento 2.4.9 supports PHP 8.3, 8.4 and 8.5.
php -v | head -n 1
# PHP 8.4.13 (cli) (built: ...)

Reverting a patch that broke something

revert takes the same ids as apply and --all undoes the lot. Reach for it the moment a patch is the only change between a working and a broken environment. var/log/patch.log is the record of what was applied to an installation, which matters when you inherit a site and no one can tell you what has been patched.

Example · bash
# Revert one patch by id
./vendor/bin/magento-patches revert ACSD-00000

# Or revert every patch the tool applied
./vendor/bin/magento-patches revert --all

# The tool writes every apply and revert here
tail -n 20 var/log/patch.log

# Patches change PHP under vendor/, so rebuild and clear afterwards
php bin/magento setup:di:compile
php bin/magento cache:clean

Related

m2 upgrade pathm2 patchesm2 upgrade runm2 deploy checklistm2 requirements

Discussion

  • Be the first to comment on this lesson.