[Magento 2] - Patch

m2-why-patch.md

Utilizando patch no Magento 2.

SOBRE

Vantagens

• Não irá aplicar caso o módulo de origem for atualizado e tiver alguma diferença de quando foi criado.
• Não é necessário fazer reescrita de classe, deixando o processo de build mais complexo.
• Caso o o módulo de origem passe a ter a correção/funcionalidade que foi criado com o patch, basta apenas ignorar ele.
• Aplicamos N patch`s e conseguimos setar a ordem deles.

Desvantagens

• Não conseguimos aplicar o patch em módulos que ficam no "app/code/".
• Alterar diretamente o VENDOR dos módulos. (Caso apresente erro, não vai aparecer que é uma classe reescrita)
• Criar patch especifico por módulo.

COMO USAR

Etapas para criar um patch.

-> Deixar o projeto local sem alterações.

On branch master Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

    git pull

-> Criar uma branch apenas para gerar.

    git checkout -b patch

-> Adicionar o módulo especifico que você precisa criar o patch no git.

    git add -f vendor/<vendor-name>

-> Comitar

    git commit -m "iniciando patch"

-> Fazer as modificações necessárias no fonte.

-> Adicionar as alterações

    git add .

-> Comitar

    git commit -m "finalizado patch"

-> Gerar o arquivo de patch

    git format-patch -1 HEAD

-> Mover o patch gerado para a pasta m2-hotfixes. (caso não exista criar)

    mv 0001-finished-patch.patch ./m2-hotfixes

-> Voltar para a branch "master"

    git checkout master

-> Remover a de criação do patch.

    git branch -D patch

-> Renomear o patch conforme o padrão adotado. Obs.: Pegar a versão no composer.json do módulo.

    mv 0001-finished-patch.patch <VENDOR>_<MODULENAME>_<lowercase-description>_<ve.rs.ion>.patch

-> Adicionar o COMPOSER-PATCHES caso não exista.

    composer require cweagans/composer-patches

-> Configurar ele no "extra"

    "extra": {
        "enable-patching": true,
        "composer-exit-on-patch-failure": true,
        "patches-file": "./composer.patches.json"
    }

-> Criar o arquivo "composer.patches.json" caso não exista.

{
    "patches": {
    },
    "patches-ignore": {}
}

-> Incluir o patch no arquivo.

    {
    "patches": {
        "<vendor>/<module-name>": {
            "DESCRIÇÂO DO QUE ELE FAZ": "<VENDOR>_<MODULENAME>_<lowercase-description>_<ve.rs.ion>.patch"
        }
    }
}

Ex.:

    {
    "patches": {
        "mundipagg/mundipagg-magento2-module": {
            "Fix - website id being passed instead of store id": "./m2-hotfixes/MUNDIPAGG_MUNDIPAGGMAGENTO2MODULE_fix-website-id-being-passed-instead-of-store-id_1.8.11.patch"
        },
    }
}

-> Executar o composer

    composer install

Vai aparecer o composer removendo o módulo e instalando novamente, e em seguida o patch.

Obs.: Caso fique vermelho, aconteceu algo com o patch.

EXTRA

• Patch criado por módulo
• Não temos o composer-patches no CLOUD, porém o que exister na pasta ms-hotfixes será aplicado.
• Ordem para aplicar os patch´s no cloud é pela ordem que ele é listado na pasta.

DUVIDAS

Fala Leo, beleza?
Top o conteúdo, bem na linha daquela primeira apresentação que você fez né?

Duas coisas que vejo que podemos explorar também:

1- Falar sobre como os patch's funcionam no Magento Cloud (automáticos) e como podemos fazer para aplicarmos eles quando não usamos o setup padrão em docker com as fases de build ofertado por eles.

2- No step "Remover a de criação do patch", quando deletamos o branch que possui o módulo no vendor os arquivos são deletamos também se não me engano, depois quando tentamos executar o composer install, por conta de alguns comandos do Magento 2 que ele executa nós recebemos alguns erros de arquivo "registration.php" daquele módulo não encontrado, o que eu normalmente faço é executar o comando "git reset HEAD~2" voltando o branch para o estado inicial (igual ao master, sem os arquivos do módulo no vendor)

Abraços