Jakie polecenia kompilacji są potrzebne w trybie programisty i kiedy?

Czy ktoś może mi dać instrukcje, kiedy uruchomić polecenia kompilacji w trybie deweloperskim Magento 2? Nie jestem pewien, czy dobrze to rozumiem.

W devdocs tryb programisty jest opisany następująco:

• Pliki widoku statycznego nie są buforowane; są zapisywane do katalogu pub / static Magento przy każdym wywołaniu

Czy to oznacza, że ​​każdy pojedynczy plik w pub / static jest generowany na żądanie i nigdy nie trzeba dzwonić setup:static-content:deploy? Jest to sprzeczne z moim doświadczeniem. Czy mogę usunąć jakieś pliki i zostaną one ponownie wygenerowane? Ponadto obrazy, pliki CSS i JS wydają się traktowane inaczej.

Strona dokumentacji trybu programisty nie mówi nic o kompilacji kodu, ale myślę, że była też różnica, więc nie trzeba było uruchamiać setup:di:compilepo wszystkich zmianach w di.xmlplikach. Czy to prawda, a jeśli tak, to jak działa generowanie kodu w trybie programisty?

Innymi słowy: odłóż pamięć podręczną, które polecenia muszę uruchomić po jakich zmianach?

zwróć uwagę: Doświadczyłem, że usunięcie w trybie programisty zepsuje pub/staticmechanizm, ponieważ pozbędziesz się .htaccesspliku, który tworzy magię w tym folderze.

Jeśli utrzymasz pub/static/.htaccessplik w trybie programisty, nie musisz uruchamiać żadnego polecenia kompilacji: Magento utworzy dowiązania symboliczne do plików, gdy tylko zostaną o to poproszone. Oznacza to, że zmiany w zasobach statycznych będą widoczne natychmiast, pod warunkiem, że masz również wyłączoną pamięć podręczną.

Możesz usunąć pub/static/frontendlub pub/static/adminhtml.

W trybie domyślnym zasoby są zmaterializowane w pub/staticpodfolderze, co oznacza, że ​​są tworzone (kopiowane, nie dowiązane symbolicznie) na pierwsze żądanie. Jeśli je zmodyfikujesz, musisz opróżnić pamięć podręczną, aby je zaktualizować.

W trybie produkcyjnym zasoby nie są zmaterializowane (powodując błąd 404 HTTP na żądanie) do momentu uruchomienia bin/magento setup:static-content:deploypolecenia.

Mam nadzieję, że to pomoże.

z mojego doświadczenia wynika, że ​​nie musisz uruchamiać żadnych poleceń do generowania kodu / pliku statycznego w trybie programisty.

Jeśli pliki statyczne nie zostały wygenerowane, może występować inny problem.

Widzę dwa powody tego od pierwszego wejrzenia:

• tryb programisty nie działa poprawnie. być może aktywacja nie udała się z jakiegoś powodu
• przepisywanie plików statycznych w pub / static.php nie działa

Czy to oznacza, że ​​każdy pojedynczy plik w pub / static jest generowany na żądanie i nigdy nie trzeba dzwonić setup:static-content:deploy? Jest to sprzeczne z moim doświadczeniem. Czy mogę usunąć jakieś pliki i zostaną one ponownie wygenerowane?

Tak. Ale według mojego doświadczenia to nie działa przez większość czasu. Może to być błąd. Lepszym rozwiązaniem jest usunięcie pub/staticzawartości i ponowne wdrożenie zawartości statycznej za każdym razem, gdy zmienisz plik statyczny (js, css, html itp.), Nawet jeśli już aktywowałeś tryb programisty. Moje własne pytanie na ten temat.

Aby wyjaśnić trzy różne tryby (źródło: Magento U Podstawy). Pogrubioną czcionką, konkretne punkty dotyczące twojego pytania.

tryb dewelopera

• Statyczne materializowanie pliku nie jest włączone.
• Nieprzechwycone wyjątki wyświetlane w przeglądarce
• Wyjątki zgłoszone w module obsługi błędów, niezalogowane
• Logowanie do systemu var/report, bardzo szczegółowe.

Powinieneś używać trybu programisty podczas opracowywania dostosowań lub rozszerzeń. Główną zaletą tego trybu jest to, że komunikaty o błędach są widoczne. Nie należy go stosować w produkcji ze względu na jego wpływ na wydajność. W trybie programisty pliki widoku statycznego są generowane za każdym razem, gdy są wymagane. Są zapisywane w pub/statickatalogu, ale ta pamięć podręczna nie jest używana. Ma to duży wpływ na wydajność, ale wszelkie zmiany wprowadzane przez programistę w celu wyświetlania plików są natychmiast widoczne.

Nieprzechwycone wyjątki są wyświetlane w przeglądarce, a nie rejestrowane. Zgłaszany jest wyjątek za każdym razem, gdy nie można wywołać subskrybenta zdarzenia.

Logowanie w systemie var/reportjest bardzo szczegółowe w tym trybie.

Tryb produkcji

• Faza wdrażania w systemie produkcyjnym; najwyższa wydajność
• Wyjątki nie są wyświetlane użytkownikowi - zapisywane tylko w dziennikach.
• Ten tryb wyłącza statyczną materializację pliku.
• Dokument Magento może mieć uprawnienia tylko do odczytu.

Powinieneś uruchomić Magento w trybie produkcyjnym po wdrożeniu na serwerze produkcyjnym.

Tryb produkcji zapewnia najwyższą wydajność w Magento 2.

Najważniejszym aspektem tego trybu jest to, że błędy są rejestrowane w systemie plików i nigdy nie są wyświetlane użytkownikowi. W tym trybie pliki widoku statycznego nie są tworzone w locie, gdy są wymagane; zamiast tego należy je wdrożyć do pub/statickatalogu za pomocą narzędzia wiersza polecenia. Wygenerowane strony będą zawierać bezpośrednie łącza do wdrożonych zasobów strony.

Wszelkie zmiany w celu wyświetlania plików wymagają ponownego uruchomienia narzędzia wdrażania.

Ponieważ pliki widoku są wdrażane za pomocą narzędzia CLI, użytkownik sieci musi mieć dostęp do zapisu. Katalog Magento pub/staticmoże mieć uprawnienia tylko do odczytu, co jest bezpieczniejszą konfiguracją na publicznie dostępnym serwerze.

Tryb domyślny

• Używany, gdy nie określono innego trybu
• Ukrywa wyjątki od użytkownika i zapisuje je w plikach dziennika
• Włączono statyczne materializowanie plików.
• Niezalecane / niezoptymalizowane pod kątem produkcji: buforowanie wpływa negatywnie na wydajność.

Jak sama nazwa wskazuje, tryb domyślny to sposób działania oprogramowania Magento, jeśli nie określono innego trybu.

W tym trybie błędy są rejestrowane w plikach var/reportsi nigdy nie są pokazywane użytkownikowi. Pliki widoku statycznego są materializowane w locie, a następnie buforowane.

W przeciwieństwie do trybu programisty zmiany plików widoku nie są widoczne, dopóki wygenerowane pliki widoku statycznego nie zostaną usunięte.

Tryb domyślny nie jest zoptymalizowany pod kątem środowiska produkcyjnego, przede wszystkim ze względu na niekorzystny wpływ wydajności plików statycznych na materializację w locie, a nie ich wcześniejszego generowania i wdrażania .

Innymi słowy, tworzenie plików statycznych w locie i buforowanie ich ma większy wpływ na wydajność niż generowanie ich za pomocą narzędzia wiersza polecenia tworzenia plików statycznych.