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
fuente
Respuestas:
El comando
setup:di:compilecomando genera el contenido de lavar/dicarpeta en Magento <2.2 ygeneratedpara Magento> = 2.2Según Magento, esto sirve para el siguiente propósito:
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.fuente
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.magento setup:di:compilepara generar los archivos necesarios. Ambas opciones terminan generando clases enMAGENTO_ROOT/var/generation directory(o/generatedsi Magento 2.2+).¿Qué clases se generan?
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
fuente
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 alparent::__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.fuente