Magento2 - thiết lập: di: biên dịch

Tôi đã làm việc trong một dự án với một số mã tùy chỉnh ... đây là dự án Magento 2 "trung bình" đầu tiên của chúng tôi, vì vậy (như tất cả mọi người ở đây tôi nghĩ) mỗi ngày chúng tôi học những điều mới và chúng tôi phải thay đổi cách đối phó với phiên bản Magento mới này

Lý do cho câu hỏi này là hỏi về lệnh setup:di:compile

Tôi đã sử dụng nó kể từ ngày đầu tiên với Magento 2, vì bin / magento yêu cầu nó sau mỗi lần setup:upgrade, với thông báo "Vui lòng chạy lại lệnh biên dịch Magento"

Chà ... tôi đã tìm thấy việc thực thi setup:di:compilephá vỡ trang xem sản phẩm trong dự án này, với một Lỗi nghiêm trọng hoàn toàn mơ hồ. Tôi đã dành cả ngày làm việc để cố gắng gỡ lỗi nó và thử nghiệm với các thay đổi mã với kết quả bằng không

Hôm nay, tôi đã phát hiện ra rằng nếu tôi bỏ qua lệnh đó thì tất cả đều hoạt động như một bùa mê, ngay cả trong chế độ sản xuất

Vì vậy, câu hỏi là ... chính xác thì setup:di:compilelệnh đó là gì? Có cần thiết không? Chỉ đề nghị? Hoặc đó là một số lệnh không dùng nữa, không cần thiết phải được thực thi?

CẬP NHẬT

Như một số người dùng đã yêu cầu, đây là Lỗi nghiêm trọng mà tôi đã đề cập

Lỗi nghiêm trọng của PHP: Không thể khởi tạo lớp trừu tượng Magento \ Catalog \ Block \ Product \ View \ AbstractView trong *** / nhà cung cấp / magento / framework / ObjectManager / Factory / AbstractFactory.php trên dòng 93

Tôi đã tìm kiếm bất kỳ khối tùy chỉnh nào bằng Magento \ Catalog \ Block \ Product \ View \ AbstractView nhưng tôi chỉ tìm thấy nó trong các tệp bố cục, nó không có trong bất kỳ trình tạo lớp khối nào

Điều tôi không thể hiểu là: tại sao Magento lại ném Lỗi nghiêm trọng này bằng mã được biên dịch, nhưng nó hoạt động như một bùa mê mà không có mã được biên dịch

Lệnh setup:di:compilelệnh tạo nội dung của var/dithư mục trong Magento <2.2 và generated cho Magento> = 2.2

Theo Magento, điều này phục vụ mục đích sau:

• Tạo mã ứng dụng (nhà máy, proxy, v.v.)
• Tổng hợp cấu hình khu vực (nghĩa là, cấu hình tiêm phụ thuộc được tối ưu hóa cho mỗi khu vực)
• Tạo chặn chặn (nghĩa là tạo mã chặn tối ưu hóa)
• Tạo bộ đệm chặn
• Tạo mã kho lưu trữ (nghĩa là mã được tạo cho API)
• Tạo thuộc tính dữ liệu dịch vụ (nghĩa là các lớp mở rộng được tạo cho các đối tượng dữ liệu)

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

Tuy nhiên, khi bạn đặt Magento ở chế độ sản xuất, không cần biên dịch thì nó thực sự vẫn hoạt động. Vì vậy, theo các tài liệu Magento, đây là một bước tối ưu hóa (nghĩa là tạo mã chặn tối ưu hóa)

Khi chúng ta có lỗi trong setup:di:compilelệnh, điều này chủ yếu là do lỗi trong một trong các hàm tạo của các lớp php tùy chỉnh.

Không bắt buộc phải chạy setup:di:compilelệnh mọi lúc nhưng nếu bạn đã thực hiện bất kỳ thay đổi mã nào đặc biệt với các phương thức xuất xưởng, proxy, thêm plugin hoặc bất kỳ trình biên dịch mã nào thì bạn phải chạy lệnh này.

Thêm chi tiết

magento setup:di:compileđể tạo các tập tin cần thiết. Cả hai tùy chọn kết thúc với việc tạo các lớp trong MAGENTO_ROOT/var/generation directory(hoặc /generatednếu Magento 2.2+).

Những lớp nào được tạo ra?

1. Các nhà máy
2. Proxy
3. bổ sung

Các nhà máy

Các nhà máy được sử dụng để khởi tạo các đối tượng không thể được tiêm tự động. Ví dụ, một đối tượng sản phẩm phải được tải từ cơ sở dữ liệu, nhưng thùng chứa phụ thuộc tiêm không có đủ thông tin để tạo đối tượng này. Đó là lý do tại sao chúng tôi sử dụng các nhà máy.

Proxy

Magento 2 sử dụng phương thức tiêm constructor trong đó tất cả các phụ thuộc là bắt buộc. Bạn không thể khởi tạo một đối tượng mà không vượt qua tất cả các phụ thuộc. Điều gì nếu bạn muốn có phụ thuộc tùy chọn? Đó là lý do tại sao proxy tồn tại.

Plugin (đánh chặn)

Nói một cách đơn giản, plugin là cơ chế tùy biến chính cho Magento 2. Không còn viết lại lớp. Nó cho phép bạn kết nối và làm một cái gì đó trước, sau hoặc xung quanh bất kỳ phương thức công khai nào của ứng dụng.

Khi bạn chạy setup: di: compile, nó sẽ thực hiện bên dưới mọi thứ

Biên dịch mã bao gồm tất cả các thứ sau đây không theo thứ tự cụ thể:

• Tạo mã ứng dụng (nhà máy, proxy, v.v.)

• Tổng hợp cấu hình khu vực (nghĩa là, cấu hình tiêm phụ thuộc được tối ưu hóa cho mỗi khu vực)

• Tạo chặn chặn (nghĩa là tạo mã chặn tối ưu hóa)

• Tạo bộ đệm chặn Tạo bộ lưu trữ tạo mã (nghĩa là mã được tạo cho API)

• Tạo thuộc tính dữ liệu dịch vụ (nghĩa là các lớp mở rộng được tạo cho các đối tượng dữ liệu)

Tham khảo câu trả lời này khi nào chúng ta nên chạy lệnh nào: /magento//a/184927/35758

Magento vẫn sẽ chạy trong sản xuất và dev mà không có lệnh di: compile. Nó thực sự sẽ biên dịch các Thiết bị chặn khi cần và lưu trữ trong generatedthư mục.

Ngay cả khi nó hoạt động, điều đó không có nghĩa là bạn nên bỏ qua bước này! Trong thực tế, khi điều này được chạy, magento cũng kiểm tra các lần tiêm trùng lặp, vòng lặp phụ thuộc và các bước cơ bản khác sẽ làm cho trang web của bạn ổn định hơn và ít có khả năng bị sập và!

Tôi tin tưởng mạnh mẽ rằng lỗi đó là do việc sử dụng một lớp mà Magento không thể biên dịch do một số đối số hàm tạo sai.

Lỗi bạn đăng là khá mơ hồ, nhưng tôi tin rằng bạn có một lớp mở rộng AbstractViewlớp, 99% đó là một khối ở đâu đó trong các mô-đun tùy chỉnh của bạn không chuyển các đối số chính xác cho parent::__construct()phương thức . Do đó khi khởi tạo nó thất bại.

Lưu ý rằng tất cả các khối đều mở rộng lớp AbstractView, do đó bạn sẽ phải thực thi lệnh biên dịch xdebugvà bật nhật ký xem dấu vết ngăn xếp để xem lớp nào được gọi là lớp trước khi nó thất bại.

Thực tế là trang web chạy không có lỗi đó có nghĩa là bạn không thực sự sử dụng khối bị hỏng ở bất cứ đâu trên trang của mình, nhưng Magento vẫn sẽ cố gắng biên dịch nó khi chạy compilelệnh, do đó không thành công.