Magento2 - setup: di: compile


12

Pracowałem nad projektem z jakimś niestandardowym kodem ... to nasz pierwszy „średni” projekt Magento 2, więc (jak sądzę tutaj wszyscy ludzie) każdego dnia uczymy się nowych rzeczy i musimy zmienić sposób postępowania dzięki nowej wersji Magento

Powodem tego pytania jest pytanie o polecenie setup:di:compile

Używam go od pierwszego dnia z Magento 2, ponieważ bin / magento prosi o to po każdym setup:upgrade, z komunikatem „Proszę ponownie uruchomić polecenie kompilacji Magento”

Cóż ... setup:di:compileW tym projekcie znalazłem wykonywanie strony podglądu przerw w pracy z całkowicie niejednoznacznym błędem krytycznym. Spędziłem całe dni robocze próbując go debugować i testując zmiany kodu z zerowym wynikiem

Dziś odkryłem, że jeśli pominę to polecenie, wszystko działa jak urok, nawet w trybie produkcyjnym

Pytanie brzmi: co dokładnie to setup:di:compilepolecenie? Czy to jest wymagane Właśnie poleciłem? A może jest to przestarzałe polecenie, którego nie trzeba wykonywać?

AKTUALIZACJA

Jak niektórzy użytkownicy tego wymagali, to właśnie ten błąd krytyczny miał na myśli

Błąd krytyczny PHP: Nie można utworzyć instancji klasy abstrakcyjnej Magento \ Catalog \ Block \ Product \ View \ AbstractView w *** / vendor / magento / framework / ObjectManager / Factory / AbstractFactory.php w linii 93

Szukałem dowolnego niestandardowego bloku za pomocą Magento \ Catalog \ Block \ Product \ View \ AbstractView, ale znalazłem go tylko w plikach układu, nie ma go w żadnym konstruktorze klasy bloku

Nie mogę zrozumieć: dlaczego Magento zgłasza ten krytyczny błąd ze skompilowanym kodem, ale działa jak urok bez skompilowanego kodu


czy możesz potwierdzić, że „setup: di: compile” powoduje również błąd widoku produktu w trybie programowania?
paj

tak, błąd krytyczny występuje w obu trybach
Raul Sanchez

Czy możesz opublikować „całkowicie niejednoznaczny błąd krytyczny”?
paj

Zaktualizowałem pytanie z błędem. Dzięki
Raul Sanchez,

Odpowiedzi:


21

Polecenie setup:di:compilepolecenia generuje zawartość var/difolderu w Magento <2.2 i generated dla Magento> = 2.2

Według Magento służy to następującemu celowi:

  • Generowanie kodu aplikacji (fabryki, proxy itp.)
  • Agregacja konfiguracji obszaru (to znaczy zoptymalizowane konfiguracje wstrzykiwania zależności dla obszaru)
  • Generowanie przechwytywaczy (czyli zoptymalizowane generowanie kodu przechwytywaczy)
  • Generowanie pamięci podręcznej przechwytywania
  • Generowanie kodu repozytoriów (tj. Generowany kod dla interfejsów API)
  • Generowanie atrybutów danych usługi (tj. Generowanych klas rozszerzeń dla obiektów danych)

Źródło ( http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.html )

Jednak po umieszczeniu Magento w trybie produkcyjnym bez kompilacji rzeczywiście nadal działa. Tak więc, zgodnie z dokumentami Magento, jest to bardziej etap optymalizacji (tzn. Zoptymalizowane generowanie kodu przechwytywaczy)

Kiedy mamy błędy w setup:di:compilepoleceniu, dzieje się tak głównie z powodu błędów w jednym z konstruktorów niestandardowych klas php.


1
Dzięki! Jest więc całkowicie opcjonalny ... Tylko jeden punkt, więc jest dla mnie bardziej zrozumiały. W naszym przypadku setup: di: compile nie zgłasza żadnego błędu, polecenie kończy się dobrze. To jest podczas przeglądania strony, po zakończeniu polecenia, gdy wystrzeliwany jest Błąd krytyczny, na stronach widoku produktu
Raul Sanchez

Może możesz opublikować błąd? To by wyjaśniło.
Tjitse,

Zaktualizowałem pytanie z błędem. Dzięki
Raul Sanchez,

12

Nie jest obowiązkowe uruchamianie setup:di:compilepolecenia za każdym razem, ale jeśli dokonałeś jakiejkolwiek zmiany kodu specjalnie metodami fabrycznymi, proxy, dodaj wtyczki lub jakąkolwiek kompilację kodu, musisz uruchomić to polecenie.

Więcej szczegółów

magento setup:di:compilew celu wygenerowania niezbędnych plików. Obie opcje kończą się generowaniem klas w MAGENTO_ROOT/var/generation directory(lub /generatedjeśli Magento 2.2+).

Jakie klasy są generowane?

  1. Fabryki
  2. Proxy
  3. Wtyczki

Fabryki

Fabryki są używane do tworzenia obiektów, których nie można wstrzyknąć automatycznie. Na przykład obiekt produktu musi zostać załadowany z bazy danych, ale kontener wstrzykiwania zależności nie ma wystarczających informacji, aby utworzyć ten obiekt. Dlatego korzystamy z fabryk.

Proxy

Magento 2 wykorzystuje wstrzykiwanie konstruktora, w którym wymagane są wszystkie zależności. Nie można utworzyć instancji obiektu bez przekazania wszystkich zależności. Co jeśli chcesz mieć opcjonalne zależności? Dlatego istnieją proxy.

Wtyczki (przechwytywacze)

Mówiąc najprościej, wtyczki są podstawowymi mechanizmami dostosowywania Magento 2. Nigdy więcej przepisywania klas. Pozwala ci podłączyć się i zrobić coś przed, po lub wokół dowolnej publicznej metody aplikacji.

po uruchomieniu polecenia setup: di: compile robi to poniżej

Kompilacja kodu składa się z wszystkich poniższych elementów, w żadnej określonej kolejności:

  • Generowanie kodu aplikacji (fabryki, proxy itp.)

  • Agregacja konfiguracji obszaru (to znaczy zoptymalizowane konfiguracje wstrzykiwania zależności dla obszaru)

  • Generowanie przechwytywaczy (czyli zoptymalizowane generowanie kodu przechwytywaczy)

  • Generowanie pamięci podręcznej przechwytywania Generowanie kodu repozytoriów (tj. Generowany kod dla interfejsów API)

  • Generowanie atrybutów danych usługi (tj. Generowanych klas rozszerzeń dla obiektów danych)

Zapoznaj się z tą odpowiedzią, kiedy powinniśmy uruchomić, które polecenia: /magento//a/184927/35758


Dzięki! Jest więc całkowicie opcjonalny ... Tylko jeden punkt, więc jest dla mnie bardziej zrozumiały. W naszym przypadku setup: di: compile nie zgłasza żadnego błędu, polecenie kończy się dobrze. To jest podczas przeglądania strony, po zakończeniu polecenia, gdy występuje błąd krytyczny, na stronach widoku produktu ... więc tak naprawdę nie rozumiem, dlaczego nieskompilowany kod działa dobrze, ale podczas kompilacji występuje błąd krytyczny
Raul Sanchez

Może się to zdarzyć, jeśli podklasa dodała nowe zależności po istniejących opcjonalnych zależnościach klasy nadrzędnej. Możesz to naprawić, przesuwając dowolny nowy wymagany parametr powyżej opcjonalnych.
Prince Patel,

2

Magento będzie nadal działało w produkcji i dev bez polecenia di: compile. W rzeczywistości skompiluje przechwytywacze zgodnie z potrzebami i zapisze je w generatedfolderze.

Nawet jeśli działa, nie oznacza to, że powinieneś pominąć ten krok! W rzeczywistości, kiedy to zostanie uruchomione, magento sprawdza również pod kątem powielonych zastrzyków, pętli zależności i innych podstawowych kroków, które sprawią, że twoja strona będzie bardziej stabilna i rzadziej ulegnie awarii i! Umrze.

Mocno wierzę, że ten błąd jest spowodowany użyciem klasy, której Magento nie może skompilować z powodu jakiegoś niewłaściwego argumentu konstruktora.

Błąd, który opublikowałeś, jest dość niejasny, ale uważam, że masz klasę, która ją rozszerza AbstractView, 99% to blok w niestandardowych modułach, który nie przekazuje poprawnych argumentów do parent::__construct()metody . Dlatego po utworzeniu instancji nie działa.

Zauważ, że wszystkie bloki rozszerzają klasę AbstractView, więc będziesz musiał wykonać komendę kompilacji za pomocą xdebugon i ustawić dziennik, aby spojrzał na ślad stosu, aby zobaczyć, która klasa nazywała ją ostatnio, zanim zakończyła się niepowodzeniem.

Fakt, że strona działa bez tego błędu oznacza, że ​​tak naprawdę nie używasz uszkodzonego bloku nigdzie na twojej stronie, ale Magento nadal spróbuje go skompilować podczas uruchamiania compilepolecenia, dlatego nie powiedzie się.


Dzięki za poświęcenie czasu na udzielenie odpowiedzi na starsze pytanie, takie jak to, z innymi potwierdzonymi odpowiedziami ... W rzeczywistości rozwiązałem ten problem, naprawiając błędne bloki w niestandardowych układach, jak już wskazałeś
Raul Sanchez
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.