Magento2 - configuración: di: compilar

He estado trabajando en un proyecto con un código personalizado ... este es nuestro primer proyecto "mediano" de Magento 2, por lo que (como todas las personas aquí creo) todos los días aprendemos cosas nuevas, y tenemos que cambiar la forma de lidiar con esta nueva versión de Magento

La razón de esta pregunta es preguntar sobre el comando setup:di:compile

Lo he estado usando desde el primer día con Magento 2, ya que bin / magento lo solicita después de cada setup:upgrademensaje de error "Vuelva a ejecutar el comando de compilación de Magento".

Bueno ... he encontrado la ejecución de setup:di:compilepausas en la página de vista del producto en este proyecto, con un error fatal totalmente ambiguo. He pasado días hábiles enteros tratando de depurarlo y probando con cambios de código sin resultado

Hoy, he descubierto que si omito ese comando, todo funciona de maravilla, incluso en modo de producción

Entonces, la pregunta es ... ¿qué dice exactamente eso setup:di:compile? ¿Se requiere? ¿Recién recomendado? ¿O es un comando obsoleto, que no es necesario ejecutar?

ACTUALIZAR

Como algunos usuarios han requerido, este es el error fatal al que me refería

Error fatal de PHP: no se puede crear una instancia de la clase abstracta Magento \ Catalog \ Block \ Product \ View \ AbstractView en *** / vendor / magento / framework / ObjectManager / Factory / AbstractFactory.php en la línea 93

He buscado cualquier bloque personalizado usando Magento \ Catalog \ Block \ Product \ View \ AbstractView pero lo he encontrado solo en archivos de diseño, no está presente en ningún constructor de clase de bloque

Lo que no puedo entender es: por qué Magento arroja este error fatal con código compilado, pero funciona de maravilla sin código compilado

El comando setup:di:compilecomando genera el contenido de la var/dicarpeta en Magento <2.2 y generated para Magento> = 2.2

Según Magento, esto sirve para el siguiente propósito:

• Generación de código de aplicación (fábricas, proxies, etc.)
• Agregación de configuración de área (es decir, configuraciones de inyección de dependencia optimizadas por área)
• Generación de interceptores (es decir, generación optimizada de código de interceptores)
• Generación de caché de interceptación
• Generación de código de repositorios (es decir, código generado para API)
• Generación de atributos de datos de servicio (es decir, clases de extensión generadas para objetos de datos)

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

Sin embargo, cuando coloca Magento en modo de producción, sin compilación, de hecho, todavía funciona. De acuerdo con los documentos de Magento, esto es más un paso de optimización (es decir, generación optimizada de código de interceptores)

Cuando tenemos errores en el setup:di:compilecomando, esto se debe principalmente a errores en uno de los constructores de clases php personalizadas.

No es obligatorio ejecutar el setup:di:compilecomando cada vez, pero si ha realizado algún cambio de código especialmente con métodos de fábrica, proxy, agregar complementos o cualquier compilación de código, entonces debe ejecutar este comando.

Más detalles

magento setup:di:compilepara generar los archivos necesarios. Ambas opciones terminan generando clases en MAGENTO_ROOT/var/generation directory(o /generatedsi Magento 2.2+).

¿Qué clases se generan?

1. Suerte
2. Proxies
3. Complementos

Suerte

Las fábricas se utilizan para crear instancias de objetos que no se pueden inyectar automáticamente. Por ejemplo, un objeto de producto debe cargarse desde la base de datos, pero el contenedor de inyección de dependencia no tiene suficiente información para crear este objeto. Por eso usamos fábricas.

Proxies

Magento 2 utiliza inyección de constructor en la que se requieren todas las dependencias. No puede crear una instancia de un objeto sin pasar todas las dependencias. ¿Qué pasa si desea tener dependencias opcionales? Por eso existen los poderes.

Complementos (interceptores)

En pocas palabras, los complementos son los principales mecanismos de personalización para Magento 2. No más reescrituras de clases. Le permite conectarse y hacer algo antes, después o alrededor de cualquier método público de la aplicación.

cuando ejecuta setup: di: compila el comando que hace debajo de las cosas

La compilación de código consta de todo lo siguiente sin ningún orden en particular:

• Generación de código de aplicación (fábricas, proxies, etc.)

• Agregación de configuración de área (es decir, configuraciones de inyección de dependencia optimizadas por área)

• Generación de interceptores (es decir, generación optimizada de código de interceptores)

• Generación de caché de intercepción Generación de código de repositorios (es decir, código generado para API)

• Generación de atributos de datos de servicio (es decir, clases de extensión generadas para objetos de datos)

Consulte esta respuesta para saber cuándo debemos ejecutar qué comandos: /magento//a/184927/35758

Magento aún se ejecutará en producción y desarrollo sin el comando di: compile. Realmente compilará los Interceptores según sea necesario y los almacenará en la generatedcarpeta.

¡Incluso si funciona, eso no significa que debas saltarte este paso! De hecho, cuando esto se ejecuta, magento también busca inyecciones duplicadas, bucles de dependencia y otros pasos fundamentales que harán que su sitio sea más estable y tenga menos probabilidades de bloquearse y morir.

Creo firmemente que ese error se debe al uso de una clase que Magento no puede compilar debido a algún argumento de constructor incorrecto.

El error que publicó es bastante vago, pero creo que tiene una clase que extiende la AbstractViewclase, 99% es un bloque en algún lugar de sus módulos personalizados que no pasa los argumentos correctos al parent::__construct()método . Por lo tanto, cuando se instancia, falla.

Tenga en cuenta que todos los bloques extienden la clase AbstractView, por lo que tendrá que ejecutar el comando de compilación con xdebugon y establecer un registro para ver el seguimiento de la pila para ver qué clase lo llamó antes de que fallara.

El hecho de que el sitio se ejecute sin ese error significa que en realidad no está utilizando el bloque dañado en ninguna parte de su página, pero Magento aún intentará compilarlo cuando ejecute el compilecomando, por lo tanto, falla.