Які команди компіляції потрібні в режимі розробника і коли?


24

Чи може хтось дати мені вказівки, коли запускати команди компіляції в режимі розробника Magento 2? Я не впевнений, чи зрозумів це все ще правильно.

У програмі devdocs режим розробника описується так:

  • Файли статичного перегляду не кешовані; вони записуються в каталог Magento pub / static кожного разу, коли вони викликаються

Чи означає це, що кожен окремий файл у pub / static генерується, коли він запитується, і вам ніколи не потрібно дзвонити setup:static-content:deploy? Це суперечить моєму досвіду. Або я можу видалити будь-які файли, і вони будуть відновлені? Також зображення, файли CSS та JS, схоже, трактуються по-різному.

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

Іншими словами: кеш убік, які команди мені потрібно запустити, після яких змінюються?

Відповіді:


27

зверніть увагу: я відчував, що в режимі розробника видалення pub/staticволі порушить механізм, тому що ви позбудетесь .htaccessфайлу, який робить магію в цій папці.

Якщо ви тримаєте pub/static/.htaccessфайл у режимі розробника, вам не потрібно запускати жодну команду компіляції: Magento створить символьні посилання на файли, як тільки вони будуть запитані. Це означає, що зміни статичних активів будуть помітні негайно, якщо у вас також вимкнено кеш-пам'ять.

Ви можете видалити pub/static/frontendабо pub/static/adminhtmlзамість цього.

У режимі за замовчуванням активи матеріалізуються у pub/staticпідпапках, тобто вони створюються (копіюються, не посилаються на зв’язок) за першим запитом. Якщо ви їх модифікуєте, вам доведеться очистити кеш, щоб оновити їх.

У режимі виробництва активи не матеріалізуються (викликаючи помилку 404 HTTP за запитом), поки не запустите bin/magento setup:static-content:deployкоманду.

Сподіваюся, це допомагає.


А як щодо складання DI?
Ерфан

@Erfan, що ти маєш на увазі точніше?
Алессандро Рончі

2
Питання також запитує про вплив режиму розгортання на компіляцію DI. Я щойно зробив швидкий тест, і якщо ви перебуваєте в режимі розробника, вам не потрібно збирати DI для того, щоб ваші зміни di.xmlвідображалися (здається, генерація коду робиться на ходу за кожну сторінку?) Як би там не було, подумав, що це буде гарним доповненням до вашої вже хорошої відповіді!
Ерфан

Ви праві @Erfan
Алессандро Рончі

1+ Спасибі, брате. Працював як шарм. У мене був дуже поганий досвід виконувати розгортання команд неодноразово, щоб отримати зміни від меншого до css навіть у режимі розробника. Я скопіював .htaccess з іншого проекту і встав у вказане місце. Халааас!
Umar Yousaf

4

з мого досвіду, вам не потрібно запускати жодні команди для генерації коду / статичних файлів у режимі розробника.

Якщо статичні файли не були створені, може виникнути інша проблема.

Я бачу дві причини цього з першого погляду:

  • Режим розробника працює неправильно. можливо, активація чомусь не вдалася
  • перезапис для статичних файлів у pub / static.php не працює

1
Мій менший файл у pub / static не повторно генерується. Чи отримуєте ви цю проблему. Як змусити його автоматично регенеруватись
mrtuvn

Важливо, щоб режим розробника був активним, а також працювали такі переписування, оскільки будь-який запит на статичні файли переписується спочатку в pub / static.php, який потім генерує файл (у режимі розробника) під pub / static, якщо його ще немає
Девід Верхолен

4

Чи означає це, що кожен окремий файл у pub / static генерується, коли він запитується, і вам ніколи не потрібно дзвонити setup:static-content:deploy? Це суперечить моєму досвіду. Або я можу видалити будь-які файли, і вони будуть відновлені?

Так. Але, за моїм досвідом, це не працює більшість часу. Може бути помилкою. Краще рішення - видалити pub/staticвміст і знову розгорнути статичний вміст щоразу, коли ви змінили статичний файл (js, css, html тощо), навіть якщо ви вже активували режим розробника. Моє власне питання з цього приводу.


Це залежить від того, як ви це бачите. Якщо ви хочете запустити setup: static-content: розгортати щоразу, коли ви вносите зміни, вам знадобиться років, щоб закінчити проект, в основному ви створюєте кожен файл для свого магазину, коли ви лише оновлюєте один файл. Отже, моє рішення полягало в тому, щоб перезаписати файли в паб / статичний та очищаючий кеш, щоб побачити зміни. Після того, як я задоволений своїми результатами, тоді я перейду до теми моїх тем або спеціальних файлів модулів, щоб перезаписати основні файли, а потім запустя налаштування: static-content: розгорнути для оновлення моїх статичних файлів.
Вольфганг Леон

4

Просто для уточнення між трьома різними режимами (джерело: курс Magento U Fundamentals). Жирним шрифтом, конкретні моменти, пов'язані з вашим запитанням.

Режим розробника

  • Статистична матеріалізація файлів не увімкнена.
  • Невиконані винятки, що відображаються в браузері
  • Винятки, закинуті в обробник помилок, не входили в систему
  • Система входу в систему var/report, дуже детальна.

Ви повинні використовувати режим розробника під час розробки налаштувань або розширень. Основна перевага цього режиму полягає в тому, що ви бачите повідомлення про помилки. Він не повинен використовуватися у виробництві через вплив на продуктивність. У режимі розробника файли статичного перегляду генеруються щоразу, коли їх запитують. Вони записуються в pub/staticкаталог, але цей кеш не використовується. Це має великий вплив на продуктивність, але будь-які зміни, які розробник робить для перегляду файлів, видно відразу.

Невиконані винятки відображаються в браузері, а не входять у систему. Виняток видається щоразу, коли абонент події не може бути викликаний.

Системний вхід var/reportв цьому режимі дуже детальний.

Режим виробництва

  • Фаза розгортання у виробничій системі; найвища продуктивність
  • Винятки не відображаються користувачеві - записуються лише в журнали.
  • Цей режим вимикає статичну файлізацію.
  • Docroot Magento може мати дозволи лише для читання.

Вам слід запустити Magento у режимі виробництва після його розгортання на виробничому сервері.

Режим виробництва забезпечує найвищі показники в Magento 2.

Найважливішим аспектом цього режиму є те, що помилки реєструються у файловій системі та ніколи не відображаються користувачеві. У цьому режимі статичні файли перегляду не створюються під час руху при їх запиті; натомість їх потрібно розгорнути до pub/staticкаталогу за допомогою інструменту командного рядка. Створені сторінки будуть містити прямі посилання на розгорнуті ресурси ресурсів.

Будь-які зміни для перегляду файлів вимагають знову запустити інструмент розгортання.

Оскільки файли перегляду розгортаються за допомогою інструмента CLI, користувачу Інтернету потрібно мати доступ для запису. Каталог Magento pub/staticможе мати дозволи лише для читання, що є більш безпечним налаштуванням на загальнодоступному сервері.

Режим за замовчуванням

  • Використовується, коли не вказаний інший режим
  • Приховує винятки від користувача і записує їх у журнали файлів
  • Статична файлізація ввімкнена.
  • Не рекомендується / не оптимізовано для виробництва: кешування негативно впливає на продуктивність.

Як випливає з назви, типовий режим - це те, як працює програмне забезпечення Magento, якщо не вказано інший режим.

У цьому режимі помилки реєструються у файлах var/reportsі ніколи не відображаються користувачеві. Файли статичного перегляду матеріалізуються під час руху, а потім кешуються.

На відміну від режиму розробника зміни файлів перегляду не видно, доки не буде очищено створені файли статичного перегляду.

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.