Magento2 - setup: di: compile

Ho lavorato a un progetto con un codice personalizzato ... questo è il nostro primo progetto "medio" di Magento 2, quindi (come tutte le persone qui penso) ogni giorno impariamo cose nuove e dobbiamo cambiare il modo di trattare con questa nuova versione di Magento

Il motivo di questa domanda è chiedere il comando setup:di:compile

Lo uso dal primo giorno con Magento 2, come bin / magento lo richiede dopo ogni volta setup:upgrade, con il messaggio "Esegui nuovamente il comando di compilazione Magento"

Bene ... Ho trovato l'esecuzione della setup:di:compilepagina di visualizzazione del prodotto per le pause in questo progetto, con un errore irreversibile totalmente ambiguo. Ho trascorso interi giorni lavorativi cercando di eseguire il debug e test con modifiche al codice con risultato zero

Oggi ho scoperto che se ometto quel comando tutto funziona come un incantesimo, anche in modalità di produzione

Quindi, la domanda è ... che cosa fa esattamente quel setup:di:compilecomando? È richiesto? Appena consigliato? O è un comando deprecato, che non è necessario per essere eseguito?

AGGIORNARE

Come alcuni utenti hanno richiesto, questo è l'errore fatale a cui mi riferivo

Errore irreversibile PHP: impossibile istanziare la classe astratta Magento \ Catalog \ Block \ Product \ View \ AbstractView in *** / vendor / magento / framework / ObjectManager / Factory / AbstractFactory.php on line 93

Ho cercato qualsiasi blocco personalizzato usando Magento \ Catalog \ Block \ Product \ View \ AbstractView ma l'ho trovato solo nei file di layout, non è presente in alcun costruttore di classi di blocchi

Quello che non riesco a capire è: perché Magento sta lanciando questo errore fatale con il codice compilato, ma funziona come un incantesimo senza codice compilato

Il comando setup:di:compilecomando genera il contenuto della var/dicartella in Magento <2.2 e generated per Magento> = 2.2

Secondo Magento, questo serve al seguente scopo:

• Generazione del codice dell'applicazione (fabbriche, proxy e così via)
• Aggregazione della configurazione dell'area (ovvero configurazioni di iniezione della dipendenza ottimizzate per area)
• Generazione di intercettori (ovvero generazione di codice ottimizzata di intercettori)
• Generazione di cache di intercettazione
• Generazione del codice dei repository (ovvero codice generato per le API)
• Generazione di attributi di dati di servizio (ovvero, classi di estensione generate per oggetti dati)

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

Tuttavia, quando metti Magento in modalità di produzione, senza compilazione, funziona davvero. Quindi, secondo i documenti di Magento, si tratta più di una fase di ottimizzazione (ovvero generazione di codice ottimizzata di intercettori)

Quando abbiamo errori nel setup:di:compilecomando, questo è principalmente a causa di errori in uno dei costruttori di classi php personalizzate.

Non è obbligatorio eseguire il setup:di:compilecomando ogni volta, ma se hai apportato modifiche al codice appositamente con metodi di fabbrica, proxy, aggiungi plug-in o compilazioni di codice, devi eseguire questo comando.

Più dettagli

magento setup:di:compileper generare i file necessari. Entrambe le opzioni finiscono con la generazione di classi in MAGENTO_ROOT/var/generation directory(o /generatedse Magento 2.2+).

Quali classi vengono generate?

1. fabbriche
2. Proxy
3. plugin

fabbriche

Le fabbriche vengono utilizzate per istanziare oggetti che non possono essere iniettati automaticamente. Ad esempio, un oggetto prodotto deve essere caricato dal database, ma il contenitore di iniezione di dipendenza non dispone di informazioni sufficienti per creare questo oggetto. Ecco perché usiamo le fabbriche.

Proxy

Magento 2 utilizza l'iniezione del costruttore in cui sono richieste tutte le dipendenze. Non è possibile creare un'istanza di un oggetto senza passare tutte le dipendenze. E se desideri avere dipendenze opzionali? Ecco perché esistono i proxy.

Plugin (intercettori)

In poche parole, i plug-in sono i principali meccanismi di personalizzazione di Magento 2. Niente più riscritture di classe. Ti consente di collegarti e fare qualcosa prima, dopo o intorno a qualsiasi metodo pubblico dell'applicazione.

quando si esegue setup: di: compile il comando fa sotto le cose

La compilazione del codice consiste in tutto ciò che segue in nessun ordine particolare:

• Generazione del codice dell'applicazione (fabbriche, proxy e così via)

• Aggregazione della configurazione dell'area (ovvero configurazioni di iniezione della dipendenza ottimizzate per area)

• Generazione di intercettori (ovvero generazione di codice ottimizzata di intercettori)

• Generazione di cache di intercettazione Generazione di codici di repository (ovvero codice generato per API)

• Generazione di attributi di dati di servizio (ovvero, classi di estensione generate per oggetti dati)

Invia questa risposta per quando dovremmo eseguire quali comandi: /magento//a/184927/35758

Magento funzionerà ancora in produzione e svilupperà senza il comando di: compile. In realtà compilerà gli intercettori di cui ha bisogno e li memorizzerà nella generatedcartella.

Anche se funziona, ciò non significa che dovresti saltare questo passaggio! Infatti, quando questo viene eseguito, magento verifica anche iniezioni duplicate, cicli di dipendenza e altri passaggi fondamentali che renderanno il tuo sito più stabile e con meno probabilità di crash e! Die.

Sono fermamente convinto che questo errore sia dovuto all'uso di una classe che Magento non può compilare a causa di un argomento del costruttore errato.

L'errore che hai pubblicato è piuttosto vago, ma credo che tu abbia una classe che estende la AbstractViewclasse, il 99% è un blocco da qualche parte nei tuoi moduli personalizzati che non passa gli argomenti corretti al parent::__construct()metodo . Quindi quando viene istanziato fallisce.

Si noti che tutti i blocchi estendono la classe AbstractView, quindi è necessario eseguire il comando di compilazione con xdebugon e impostare un registro in cerca della traccia dello stack per vedere quale classe l'ha chiamata l'ultima volta prima che fallisse.

Il fatto che il sito viene eseguito senza che i mezzi di errore che si sta non in realtà usando il danneggiato blocco qualsiasi punto della pagina, ma Magento sarà comunque provare a compilarla durante l'esecuzione del compilecomando, e quindi non riesce.