Magento2 - configuration: di: compile

J'ai travaillé sur un projet avec du code personnalisé ... c'est notre premier projet Magento 2 "moyen", donc (comme tout le monde ici je pense) chaque jour nous apprenons de nouvelles choses, et nous devons changer la façon de traiter avec cette nouvelle version de Magento

La raison de cette question concerne la commande setup:di:compile

Je l'utilise depuis le premier jour avec Magento 2, comme bin / magento le demande après chaque setup:upgrade, avec le message "Veuillez réexécuter la commande de compilation Magento"

Eh bien ... J'ai trouvé l'exécution de setup:di:compilela page de visualisation du produit des pauses dans ce projet, avec une erreur fatale totalement ambiguë. J'ai passé des journées entières à essayer de le déboguer et à tester avec des modifications de code avec un résultat nul

Aujourd'hui, j'ai découvert que si j'omet cette commande, alors tout fonctionne comme un charme, même en mode production

Alors, la question est ... qu'est-ce que cette setup:di:compilecommande exactement ? Est-ce obligatoire? Juste recommandé? Ou c'est une commande obsolète, qui n'est pas nécessaire pour être exécutée?

MISE À JOUR

Comme certains utilisateurs l'ont demandé, il s'agit de l'erreur fatale à laquelle je faisais référence

Erreur fatale PHP: Impossible d'instancier la classe abstraite Magento \ Catalog \ Block \ Product \ View \ AbstractView dans *** / vendor / magento / framework / ObjectManager / Factory / AbstractFactory.php sur la ligne 93

J'ai recherché un bloc personnalisé à l'aide de Magento \ Catalog \ Block \ Product \ View \ AbstractView, mais je ne l'ai trouvé que dans les fichiers de disposition, il n'est présent dans aucun constructeur de classe de bloc

Ce que je ne peux pas comprendre, c'est: pourquoi Magento lance cette erreur fatale avec du code compilé, mais cela fonctionne comme un charme sans code compilé

La commande setup:di:compilecommande génère le contenu du var/didossier dans Magento <2.2 et generated pour Magento> = 2.2

Selon Magento, cela sert le but suivant:

• Génération de code d'application (usines, procurations, etc.)
• Agrégation de configuration de zone (c'est-à-dire, configurations d'injection de dépendance optimisées par zone)
• Génération d'intercepteurs (c'est-à-dire génération de code optimisée d'intercepteurs)
• Génération de cache d'interception
• Génération de code de référentiels (c'est-à-dire, code généré pour les API)
• Génération d'attributs de données de service (c'est-à-dire, génération de classes d'extension pour les objets de données)

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

Cependant, lorsque vous placez Magento en mode production, sans compilation, il fonctionne en effet toujours. Donc, selon les documents de Magento, il s'agit plus d'une étape d'optimisation (c'est-à-dire d'une génération de code optimisée d'intercepteurs)

Lorsque nous avons des erreurs dans la setup:di:compilecommande, c'est principalement à cause d'erreurs dans l'un des constructeurs de classes php personnalisées.

Il n'est pas obligatoire d'exécuter la setup:di:compilecommande à chaque fois, mais si vous avez effectué un changement de code spécialement avec les méthodes d'usine, le proxy, l'ajout de plugins ou toute compilation de code, vous devez alors exécuter cette commande.

Plus de détails

magento setup:di:compileafin de générer les fichiers nécessaires. Les deux options finissent par générer des classes dans MAGENTO_ROOT/var/generation directory(ou /generatedsi Magento 2.2+).

Quelles classes sont générées?

1. Des usines
2. Procurations
3. Plugins

Des usines

Les usines sont utilisées pour instancier des objets qui ne peuvent pas être injectés automatiquement. Par exemple, un objet produit doit être chargé à partir de la base de données, mais le conteneur d'injection de dépendance n'a pas suffisamment d'informations pour créer cet objet. C'est pourquoi nous utilisons des usines.

Procurations

Magento 2 utilise l'injection de constructeur dans laquelle toutes les dépendances sont requises. Vous ne pouvez pas instancier un objet sans passer toutes les dépendances. Et si vous souhaitez avoir des dépendances optionnelles? C'est pourquoi les procurations existent.

Plugins (Intercepteurs)

Autrement dit, les plugins sont les principaux mécanismes de personnalisation pour Magento 2. Plus de réécritures de classe. Il vous permet de vous connecter et de faire quelque chose avant, après ou autour de toute méthode publique de l'application.

lorsque vous exécutez la commande setup: di: compile, faites-le ci-dessous

La compilation du code comprend tous les éléments suivants sans ordre particulier:

• Génération de code d'application (usines, procurations, etc.)

• Agrégation de configuration de zone (c'est-à-dire, configurations d'injection de dépendance optimisées par zone)

• Génération d'intercepteurs (c'est-à-dire génération de code optimisée d'intercepteurs)

• Génération de cache d'interception Génération de code de référentiels (c'est-à-dire, code généré pour les API)

• Génération d'attributs de données de service (c'est-à-dire, génération de classes d'extension pour les objets de données)

Reportez-vous à cette réponse pour savoir quand exécuter les commandes: /magento//a/184927/35758

Magento fonctionnera toujours en production et en développement sans la commande di: compile. Il compilera en fait les intercepteurs selon les besoins et les stockera dans le generateddossier.

Même si cela fonctionne, cela ne signifie pas que vous devez sauter cette étape! En fait, lors de son exécution, magento vérifie également les injections dupliquées, les boucles de dépendance et d'autres étapes fondamentales qui rendront votre site plus stable et moins susceptible de se bloquer et de mourir.

Je crois fermement que cette erreur est due à l'utilisation d'une classe que Magento ne peut pas compiler en raison d'un mauvais argument constructeur.

L'erreur que vous avez publiée est assez vague, mais je pense que vous avez une classe qui étend la AbstractViewclasse, 99% c'est un bloc quelque part dans vos modules personnalisés qui ne transmet pas les arguments corrects à la parent::__construct()méthode . Par conséquent, une fois instancié, il échoue.

Notez que tous les blocs étendent la classe AbstractView, vous devrez donc exécuter la commande de compilation avec xdebugon et définir un journal pour regarder la trace de la pile pour voir quelle classe l'a appelée en dernier avant qu'elle n'échoue.

Le fait que le site s'exécute sans cette erreur signifie que vous n'utilisez pas réellement le bloc corrompu n'importe où sur votre page, mais Magento essaiera toujours de le compiler lors de l'exécution de la compilecommande, donc il échoue.