Magento2 - configuração: di: compile

Eu tenho trabalhado em um projeto com algum código personalizado ... este é o nosso primeiro projeto "médio" do Magento 2, então (como todas as pessoas daqui eu acho) todos os dias aprendemos coisas novas e precisamos mudar a maneira de lidar com esta nova versão do Magento

O motivo desta pergunta é perguntar sobre o comando setup:di:compile

Uso-o desde o primeiro dia com o Magento 2, como o bin / magento pede depois de todos os dias setup:upgrade, com a mensagem "Por favor, execute novamente o comando de compilação do Magento"

Bem ... Eu encontrei a execução de setup:di:compileinterrupções na página de visualização do produto neste projeto, com um erro fatal totalmente ambíguo. Passei dias úteis tentando depurá-lo e testando com alterações de código com resultado zero

Hoje, descobri que, se eu omitir esse comando, tudo funciona como um encanto, mesmo no modo de produção

Então, a pergunta é ... o que exatamente isso setup:di:compileordena? É necessário? Apenas recomendado? Ou é algum comando obsoleto, que não precisa ser executado?

ATUALIZAR

Como alguns usuários exigiram, esse é o erro fatal que eu estava me referindo

Erro fatal do PHP: Não é possível instanciar a classe abstrata Magento \ Catalog \ Block \ Product \ View \ AbstractView em *** / vendor / magento / framework / ObjectManager / Factory / AbstractFactory.php na linha 93

Procurei por qualquer bloco personalizado usando Magento \ Catálogo \ Bloco \ Produto \ Visualização \ ResumoView, mas o encontrei apenas em arquivos de layout, não está presente em nenhum construtor de classe de bloco

O que não consigo entender é: por que o Magento está lançando esse erro fatal com código compilado, mas funciona como um encanto sem código compilado

O comando setup:di:compilecommand gera o conteúdo da var/dipasta no Magento <2.2 e generated para Magento> = 2.2

Segundo Magento, isso serve ao seguinte objetivo:

• Geração de código do aplicativo (fábricas, proxies etc.)
• Agregação de configuração de área (ou seja, configurações otimizadas de injeção de dependência por área)
• Geração de interceptores (ou seja, geração de código otimizada de interceptores)
• Geração de cache de interceptação
• Geração de código de repositórios (ou seja, código gerado para APIs)
• Geração de atributos de dados de serviço (ou seja, classes de extensão geradas para objetos de dados)

Fonte ( http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.html )

No entanto, quando você coloca o Magento no modo de produção, sem compilação, ele ainda funciona. Portanto, de acordo com os documentos do Magento, essa é mais uma etapa de otimização (ou seja, geração otimizada de código de interceptores)

Quando temos erros no setup:di:compilecomando, isso ocorre principalmente por causa de erros em um dos construtores de classes php personalizadas.

Não é obrigatório executar o setup:di:compilecomando toda vez, mas se você tiver alterado algum código especialmente com métodos de fábrica, proxy, adicionar plug-ins ou qualquer compilação de código, será necessário executar este comando.

Mais detalhes

magento setup:di:compilepara gerar os arquivos necessários. Ambas as opções acabam gerando classes em MAGENTO_ROOT/var/generation directory(ou /generatedse Magento 2.2+).

Quais classes são geradas?

1. Fábricas
2. Proxies
3. Plugins

Fábricas

Fábricas são usadas para instanciar objetos que não podem ser injetados automaticamente. Por exemplo, um objeto do produto deve ser carregado no banco de dados, mas o contêiner de injeção de dependência não possui informações suficientes para criar esse objeto. É por isso que usamos fábricas.

Proxies

O Magento 2 usa injeção de construtor na qual todas as dependências são necessárias. Você não pode instanciar um objeto sem passar todas as dependências. E se você gostaria de ter dependências opcionais? É por isso que existem proxies.

Plugins (interceptores)

Simplificando, os plugins são os principais mecanismos de personalização do Magento 2. Chega de reescrever classes. Ele permite que você conecte e faça algo antes, depois ou ao redor de qualquer método público do aplicativo.

quando você executa o comando setup: di: compile, ele faz abaixo das coisas

A compilação de código consiste em todos os itens a seguir em nenhuma ordem específica:

• Geração de código do aplicativo (fábricas, proxies etc.)

• Agregação de configuração de área (ou seja, configurações otimizadas de injeção de dependência por área)

• Geração de interceptores (ou seja, geração de código otimizada de interceptores)

• Geração de cache de interceptação Geração de código de repositórios (ou seja, código gerado para APIs)

• Geração de atributos de dados de serviço (ou seja, classes de extensão geradas para objetos de dados)

Consulte esta resposta para quando devemos executar quais comandos: /magento//a/184927/35758

O Magento ainda será executado em produção e dev sem o comando di: compile. Na verdade, ele irá compilar os interceptores conforme necessário e armazená-los na generatedpasta.

Mesmo que funcione, isso não significa que você deve pular esta etapa! De fato, quando isso é executado, o magento também verifica injeções duplicadas, loops de dependência e outras etapas fundamentais que tornarão seu site mais estável e menos propenso a travar e morrer!

Eu acredito firmemente que esse erro se deve ao uso de uma classe que o Magento não pode compilar devido a algum argumento errado do construtor.

O erro que você postou é bastante vago, mas acredito que você tenha uma classe que estende a AbstractViewclasse, 99%, é um bloco em algum lugar nos seus módulos personalizados que não passa os argumentos corretos para o parent::__construct()método . Portanto, quando instanciado, ele falha.

Observe que todos os blocos estendem a classe AbstractView, portanto você terá que executar o comando compile com xdebugon e definir um log para examinar o rastreamento da pilha para ver qual classe a chamou por último antes de falhar.

O fato de o site ser executado sem esse erro significa que você não está realmente usando o bloco corrompido em nenhum lugar da sua página, mas o Magento ainda tentará compilá-lo ao executar o compilecomando; portanto, ele falha.