Magento2 - налаштування: di: компілювати

Я працюю над проектом з якимсь спеціальним кодом ... це наш перший "середній" проект Magento 2, тому (як і всі тут люди, я думаю) щодня ми дізнаємось нові речі, і ми мусимо змінити спосіб роботи з цією новою версією Magento

Причиною цього питання є запитання про команду setup:di:compile

Я використовую його з першого дня з Magento 2, оскільки bin / magento просить його після кожного setup:upgrade, з повідомленням "Будь ласка, повторно запустіть команду компіляції Magento"

Ну ... Я виявив, що setup:di:compileв цьому проекті виконується перегляд сторінки перегляду продуктів, з абсолютно неоднозначною фатальною помилкою. Я цілі робочі дні пробував налагоджувати його та тестуючи зміни коду з нульовим результатом

Сьогодні я виявив, що якщо я пропускаю цю команду, то все працює як шарм, навіть у режимі виробництва

Отже, питання ... що саме ця setup:di:compileкоманда виконує ? Це потрібно? Просто рекомендується? Або це якась застаріла команда, яку не потрібно виконувати?

ОНОВЛЕННЯ

Як вимагають деякі користувачі, це та фатальна помилка, про яку я мав на увазі

PHP Fatal error: Неможливо створити абстрактний клас Magento \ Каталог \ Блок \ Продукт \ Перегляд \ AbstractView у *** / постачальник / magento / Framework / ObjectManager / Factory / AbstractFactory.php у рядку 93

Я шукав будь-який спеціальний блок за допомогою Magento \ Catalog \ Block \ Product \ View \ AbstractView, але я знайшов його лише у файлах компонування, його немає в жодному конструкторі класових блоків

Я не можу зрозуміти: чому Magento кидає цю фатальну помилку зі скомпільованим кодом, але вона працює як шарм без скомпільованого коду

Команда setup:di:compileкоманд генерує вміст var/diпапки в Magento <2.2, а generated для Magento> = 2.2

За словами Магенто, це служить такій меті:

• Генерація коду програми (фабрики, проксі, тощо)
• Агрегація конфігурації області (тобто оптимізовані конфігурації ін'єкцій залежностей на область)
• Генерація перехоплювачів (тобто оптимізована генерація коду перехоплювачів)
• Генерація кеш-перехоплення
• Генерація коду репозиторіїв (тобто згенерований код для API)
• Генерація атрибутів службових даних (тобто згенерованих класів розширень для об'єктів даних)

Джерело ( http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.html )

Однак, якщо ви помістите Magento у виробничий режим, без компіляції він справді працює. Отже, згідно з документами Magento, це більше крок оптимізації (тобто оптимізована генерація коду перехоплювачів)

Коли ми маємо помилки в setup:di:compileкоманді, це здебільшого через помилки в одному з конструкторів користувацьких класів php.

Не обов’язково виконувати setup:di:compileкоманду кожного разу, але якщо ви зробили будь-яку зміну коду спеціально за допомогою заводських методів, проксі, додавання плагінів або будь-якої компіляції коду, вам потрібно запустити цю команду.

Детальніше

magento setup:di:compileдля того, щоб генерувати необхідні файли. Обидва варіанти закінчуються генерацією класів у MAGENTO_ROOT/var/generation directory(або /generatedякщо Magento 2.2+).

Які класи генеруються?

1. Заводи
2. Проксі
3. Плагіни

Заводи

Заводи використовуються для створення об'єктів, які неможливо вводити автоматично. Наприклад, об’єкт продукту повинен бути завантажений з бази даних, але контейнер для введення залежностей не має достатньо інформації для створення цього об'єкта. Ось чому ми використовуємо фабрики.

Проксі

Magento 2 використовує конструкторський впорскування, в якому необхідні всі залежності. Ви не можете створити об'єкт, не пройшовши всіх залежностей. Що робити, якщо ви хочете мати додаткові залежності? Ось чому проксі є.

Плагіни (перехоплювачі)

Простіше кажучи, плагіни - це основні механізми налаштування Magento 2. Більше не переписується клас. Це дозволяє підключитись і зробити щось до, після або навколо будь-якого публічного методу програми.

коли ви запускаєте setup: di: компілювати команду, це робити нижче

Компіляція коду складається з усіх наступних, не в конкретному порядку:

• Генерація коду програми (фабрики, проксі, тощо)

• Агрегація конфігурації області (тобто оптимізовані конфігурації ін'єкцій залежностей на область)

• Генерація перехоплювачів (тобто оптимізована генерація коду перехоплювачів)

• Генерація кешу перехоплення кеш-генерації Репозиторії (тобто згенерований код для API)

• Генерація атрибутів службових даних (тобто згенерованих класів розширень для об'єктів даних)

Зверніться до цієї відповіді, коли слід виконувати, які команди: https://magento.stackexchange.com/a/184927/35758

Magento як і раніше буде працювати у виробництві та dev без команди di: compile. Він фактично буде компілювати перехоплювачі, як потрібно, і зберігати в generatedпапці.

Навіть якщо це працює, це не означає, що вам слід пропустити цей крок! Насправді, коли це виконується, magento також перевіряє наявність дублірованних ін'єкцій, циклів залежності та інших фундаментальних кроків, які зроблять ваш сайт більш стабільним і менше шансів на збій і!

Я переконаний, що ця помилка пов'язана з використанням класу, який Magento не може скласти через якийсь неправильний аргумент конструктора.

Помилка, яку ви опублікували, є досить невиразною, але я вважаю, що у вас є клас, який розширює AbstractViewклас, на 99% це блок десь у ваших користувальницьких модулях, який не передає правильних аргументів parent::__construct()методу . Отже, коли інстанціювання не вдається.

Зауважте, що всі блоки поширюють клас AbstractView, тому вам доведеться виконати команду компіляції з xdebugувімкнутим і встановити журнал при перегляді сліду стека, щоб побачити, який клас називав його останнім, перш ніж він не вдався.

Той факт, що сайт працює без цієї помилки, означає, що ви фактично не використовуєте пошкоджений блок ніде на своїй сторінці, але Magento все одно намагатиметься скомпілювати його під час виконання compileкоманди, отже, це не вдасться.