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:compile
W 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:compile
polecenie? 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
źródło
Odpowiedzi:
Polecenie
setup:di:compile
polecenia generuje zawartośćvar/di
folderu w Magento <2.2 igenerated
dla Magento> = 2.2Według Magento służy to następującemu celowi:
Ź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:compile
poleceniu, dzieje się tak głównie z powodu błędów w jednym z konstruktorów niestandardowych klas php.źródło
Nie jest obowiązkowe uruchamianie
setup:di:compile
polecenia 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.magento setup:di:compile
w celu wygenerowania niezbędnych plików. Obie opcje kończą się generowaniem klas wMAGENTO_ROOT/var/generation directory
(lub/generated
jeśli Magento 2.2+).Jakie klasy są generowane?
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
źródło
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
generated
folderze.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 doparent::__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ą
xdebug
on 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
compile
polecenia, dlatego nie powiedzie się.źródło