Magento2 - setup: di: compile


12

Saya telah bekerja dalam sebuah proyek dengan beberapa kode khusus ... ini adalah proyek "medium" Magento 2 pertama kami, jadi (karena semua orang di sini saya pikir) setiap hari kami mempelajari hal-hal baru, dan kami harus mengubah cara untuk menangani dengan versi Magento baru ini

Alasan untuk pertanyaan ini adalah menanyakan tentang perintah setup:di:compile

Saya telah menggunakannya sejak hari pertama dengan Magento 2, karena bin / magento memintanya setelah setiap setup:upgrade, dengan pesan "Silakan jalankan kembali perintah kompilasi Magento"

Yah ... Saya telah menemukan mengeksekusi setup:di:compilehalaman istirahat tampilan produk dalam proyek ini, dengan Kesalahan Fatal yang sepenuhnya ambigu. Saya telah menghabiskan seluruh hari kerja untuk mencoba debug dan menguji dengan perubahan kode tanpa hasil

Hari ini, saya telah menemukan bahwa jika saya menghilangkan perintah itu maka semua berfungsi seperti pesona, bahkan dalam mode produksi

Jadi, pertanyaannya adalah ... apa tepatnya setup:di:compileperintah itu? Apakah itu wajib? Baru saja direkomendasikan? Atau itu adalah perintah yang sudah usang, yang tidak perlu dieksekusi?

MEMPERBARUI

Seperti yang diperlukan beberapa pengguna, ini adalah Kesalahan Fatal yang saya maksudkan

Kesalahan fatal PHP: Tidak dapat membuat instance kelas abstrak Magento \ Catalog \ Block \ Product \ View \ AbstractView in *** / vendor / magento / framework / ObjectManager / Factory / AbstractFactory.php on line 93

Saya telah mencari setiap blok khusus menggunakan Magento \ Catalog \ Block \ Product \ View \ AbstractView tetapi saya menemukannya hanya di file tata letak, tidak ada di konstruktor kelas blok mana pun

Yang tidak bisa saya pahami adalah: mengapa Magento melempar Kesalahan Fatal ini dengan kode terkompilasi, tetapi ia berfungsi seperti pesona tanpa kode terkompilasi


dapatkah Anda mengonfirmasi bahwa 'setup: di: compile' juga menyebabkan kesalahan tampilan produk dalam mode pengembangan?
paj

ya, Kesalahan Fatal terjadi di kedua mode
Raul Sanchez

Bisakah Anda memposting "Kesalahan Fatal yang sepenuhnya ambigu"?
paj

Saya telah memperbarui pertanyaan dengan kesalahan. Terima kasih
Raul Sanchez

Jawaban:


21

Perintah setup:di:compileperintah menghasilkan konten var/difolder di Magento <2.2 dan generated untuk Magento> = 2.2

Menurut Magento, ini melayani tujuan berikut:

  • Pembuatan kode aplikasi (pabrik, proksi, dan sebagainya)
  • Agregasi konfigurasi area (yaitu, konfigurasi injeksi dependensi yang dioptimalkan per area)
  • Generasi interseptor (yaitu, generasi kode interseptor yang dioptimalkan)
  • Pembuatan cache intersepsi
  • Pembuatan kode repositori (yaitu, kode yang dihasilkan untuk API)
  • Pembuatan atribut data layanan (yaitu, kelas ekstensi yang dihasilkan untuk objek data)

Sumber ( http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.html )

Namun, ketika Anda menempatkan Magento dalam mode produksi, tanpa kompilasi itu memang masih berfungsi. Jadi menurut dokumen Magento, ini lebih merupakan langkah pengoptimalan (yaitu, pembuatan kode interseptor yang dioptimalkan)

Ketika kami memiliki kesalahan dalam setup:di:compileperintah, ini sebagian besar karena kesalahan di salah satu konstruktor dari kelas php kustom.


1
Terima kasih! Jadi, ini benar-benar opsional ... Hanya satu poin, jadi lebih jelas bagi saya. Dalam kasus kami, setup: di: compile tidak menimbulkan kesalahan, perintah berakhir ok. Itu adalah ketika menjelajahi situs, setelah perintah selesai, ketika Kesalahan Fatal dipecat, di halaman tampilan produk
Raul Sanchez

Mungkin Anda bisa memposting kesalahan? Itu akan membuat segalanya lebih jelas.
Tjitse

Saya telah memperbarui pertanyaan dengan kesalahan. Terima kasih
Raul Sanchez

12

Ini tidak wajib untuk menjalankan setup:di:compileperintah setiap kali tetapi jika Anda telah melakukan perubahan kode khusus dengan metode pabrik, proksi, tambahkan plugin atau kompilasi kode apa pun maka Anda harus menjalankan perintah ini.

Keterangan lebih lanjut

magento setup:di:compileuntuk menghasilkan file yang diperlukan. Kedua opsi berakhir dengan menghasilkan kelas di MAGENTO_ROOT/var/generation directory(atau /generatedjika Magento 2.2+).

Kelas apa yang dihasilkan?

  1. Pabrik
  2. Proksi
  3. Plugin

Pabrik

Pabrik digunakan untuk instantiate objek yang tidak dapat disuntikkan secara otomatis. Misalnya, objek produk harus dimuat dari database, tetapi wadah injeksi ketergantungan tidak memiliki informasi yang cukup untuk membuat objek ini. Itu sebabnya kami menggunakan pabrik.

Proksi

Magento 2 menggunakan injeksi konstruktor di mana semua dependensi diperlukan. Anda tidak dapat membuat instance objek tanpa melewati semua dependensi. Bagaimana jika Anda ingin memiliki dependensi opsional? Itu sebabnya proxy ada.

Plugin (Interceptor)

Sederhananya, plugin adalah mekanisme penyesuaian utama untuk Magento 2. Tidak ada lagi penulisan ulang kelas. Ini memungkinkan Anda untuk terhubung dan melakukan sesuatu sebelum, setelah atau di sekitar metode publik aplikasi apa pun.

ketika Anda menjalankan setup: di: compile perintah yang dilakukannya di bawah ini

Kompilasi kode terdiri dari semua hal berikut tanpa urutan tertentu:

  • Pembuatan kode aplikasi (pabrik, proksi, dan sebagainya)

  • Agregasi konfigurasi area (yaitu, konfigurasi injeksi dependensi yang dioptimalkan per area)

  • Generasi interseptor (yaitu, generasi kode interseptor yang dioptimalkan)

  • Pembuatan cache intersepsi Pembuatan kode repositori (yaitu, kode yang dihasilkan untuk API)

  • Pembuatan atribut data layanan (yaitu, kelas ekstensi yang dihasilkan untuk objek data)

Lihat jawaban ini untuk kapan kita harus menjalankan perintah mana: /magento//a/184927/35758


Terima kasih! Jadi, ini benar-benar opsional ... Hanya satu poin, jadi lebih jelas bagi saya. Dalam kasus kami, setup: di: compile tidak menimbulkan kesalahan, perintah berakhir ok. Itu adalah ketika menjelajahi situs, setelah perintah selesai, ketika Fatal Error dipecat, di halaman tampilan produk ... jadi saya tidak benar-benar mengerti mengapa tidak mengkompilasi kode berfungsi dengan baik tetapi ketika kompilasi maka Fatal Error terjadi
Raul Sanchez

Ini dapat terjadi jika sub-kelas Anda menambahkan dependensi baru setelah dependensi opsional yang ada dari kelas induk. Anda dapat memperbaikinya dengan memindahkan parameter yang diperlukan baru di atas yang opsional.
Pangeran Patel

2

Magento masih akan berjalan di produksi dan dev tanpa perintah di: compile. Ini sebenarnya akan mengkompilasi Interceptor karena perlu dan menyimpannya di generatedfolder.

Bahkan jika itu berhasil, itu tidak berarti Anda harus melewati langkah ini! Bahkan, ketika ini dijalankan, Magento juga memeriksa injeksi digandakan, loop ketergantungan dan langkah-langkah mendasar lainnya yang akan membuat situs Anda lebih stabil dan kecil kemungkinannya untuk crash dan! Mati.

Saya sangat percaya bahwa kesalahan itu disebabkan oleh penggunaan kelas yang tidak bisa dikompilasi Magento karena beberapa argumen konstruktor yang salah.

Kesalahan yang Anda posting cukup kabur, tetapi saya yakin Anda memiliki kelas yang memperluas AbstractViewkelas, 99% itu adalah blok di suatu tempat di modul khusus Anda yang tidak memberikan argumen yang benar ke parent::__construct()metode . Karena itu ketika instantiated gagal.

Perhatikan bahwa semua blok memperpanjang kelas AbstractView sehingga Anda harus menjalankan perintah kompilasi dengan xdebugon dan mengatur log saat melihat jejak stack untuk melihat kelas apa yang disebut terakhir sebelum gagal.

Fakta bahwa situs berjalan tanpa kesalahan itu berarti bahwa Anda tidak benar-benar menggunakan blok rusak di mana pun di halaman Anda, tetapi Magento masih akan mencoba untuk mengkompilasinya ketika menjalankan compileperintah, maka itu gagal.


Terima kasih telah meluangkan waktu untuk menjawab pertanyaan yang lebih tua seperti ini, dengan jawaban yang divalidasi lainnya ... Sebenarnya, saya menyelesaikan ini dengan memperbaiki blok yang salah dalam tata letak khusus, seperti yang Anda tunjukkan
Raul Sanchez
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.