Bug do core do Magento 2? Aplique o patch oficial da Adobe

Instala e vê o que serve para a sua versão

É um pacote Composer normal:

composer require magento/quality-patches

Ele vem do repo.magento.com, o mesmo repositório que sua loja já usa para baixar o Magento — então as credenciais que estão no auth.json bastam. Junto vem o magento/magento-cloud-patches, que é quem entrega o executável.

./vendor/bin/magento-patches status

A saída é uma tabela com Id, Title, Category, Origin, Status e Details. O Status diz Applied, Not applied ou N/A quando o próprio comando não consegue decidir por causa de conflito.

Se a sua versão tiver mais de 50 patches disponíveis — e vai ter — o comando fica interativo: pergunta o provedor e depois a categoria antes de imprimir. Categorias reais são coisas como Order/Checkout, Catalog/Product, Performance, Inventory, Emails. Se você quer só o despejo cru para grep ou script:

./vendor/bin/magento-patches status --format json

Só para dar tamanho ao que tem lá dentro: AC-14985 conserta o envio de e-mail por SMTP com TLS na 2.4.8; ACSD-51819 resolve dois pedidos serem criados com o mesmo quote id. É esse tipo de coisa — bug de operação do dia a dia.

Aplicar, conferir e voltar atrás

Aplicar é passar o id. Aceita mais de um:

./vendor/bin/magento-patches apply ACSD-51819

Depois disso, o de sempre para código que mudou dentro de vendor/:

php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento cache:flush

Voltar atrás é o mesmo verbo ao contrário:

./vendor/bin/magento-patches revert ACSD-51819
./vendor/bin/magento-patches revert --all

Esse revert --all é o botão de pânico e funciona. É por isso que eu prefiro esse caminho a um patch caseiro colado com cweagans/composer-patches: aqui a reversão é prevista.

Tem também o verify, que confere se os patches que você espera estão mesmo aplicados. Bom para pôr no fim do pipeline e descobrir o problema na hora do deploy, não na sexta à noite.

Testa em homologação. Sério. O README do repositório é explícito: Make sure to test all patches in a pre-production environment. Patch de qualidade não passa pelo mesmo ciclo de teste de uma release.

O que isso muda no seu deploy

Duas coisas importantes, e as duas mordem quem esquece.

O patch mora dentro de vendor/. Ou seja, todo composer install apaga o que você aplicou. O apply tem que entrar no script de deploy, depois do composer install e antes do setup:di:compile. Se o seu deploy é build separado, o lugar é a máquina de build.

Cada patch é construído para uma faixa de versão. No catálogo isso aparece como >=2.4.7 <2.4.8, por exemplo. Quando você finalmente for subir de versão, reverta tudo antes: patch feito para a 2.4.7 aplicado sobre a 2.4.8 ou não entra, ou entra torto. E na versão nova ele provavelmente nem é mais necessário, porque a correção virou parte do core.

Por fim, não confunda os dois mundos. Quality patch é correção funcional e é opcional. Patch de segurança da Adobe, aquele que vem com boletim APSB, é outro assunto e outro pacote — esse não é opcional, e eu trato dele à parte no guia de segurança.