Magento2 - सेटअप: di: संकलन

Question

मैं कुछ कस्टम कोड के साथ एक परियोजना में काम कर रहा हूं ... यह हमारा पहला "मध्यम" मैगेंटो 2 प्रोजेक्ट है, इसलिए (जैसा कि यहां के सभी लोग सोचते हैं) हर दिन हम नई चीजें सीखते हैं, और हमें सौदा करने का तरीका बदलना होगा इस नए Magento संस्करण के साथ

इस प्रश्न का कारण कमांड के बारे में पूछ रहा है setup:di:compile

मैं Magento 2 के साथ पहले दिन से इसका उपयोग कर रहा हूं, क्योंकि बिन / मैगेंटो प्रत्येक के बाद इसके लिए कहता है setup:upgrade, संदेश के साथ "कृपया Magento संकलन कमांड को फिर से चलाएं"

अच्छी तरह से ... मुझे setup:di:compileइस परियोजना में टूटने वाले उत्पाद दृश्य पृष्ठ को पूरी तरह से अस्पष्ट घातक त्रुटि के साथ निष्पादित करना पाया गया है । मैंने इसे पूरा करने और शून्य परिणाम के साथ कोड परिवर्तन के साथ परीक्षण करने के लिए पूरे कार्य दिवस बिताए हैं

आज, मुझे पता चला है कि अगर मैं उस आदेश को छोड़ देता हूं तो सभी एक आकर्षण की तरह काम करते हैं, यहां तक ​​कि उत्पादन मोड में भी

तो, सवाल यह है ... क्या वास्तव में वह setup:di:compileआदेश करता है ? क्या यह आवश्यक है? बस सिफारिश की है? या यह कुछ पदावनत कमांड है, जिसे निष्पादित करने की आवश्यकता नहीं है?

अपडेट करें

जैसा कि कुछ उपयोगकर्ताओं के लिए आवश्यक है, यह घातक त्रुटि है जिसका मैं उल्लेख कर रहा था

PHP घातक त्रुटि: अमूर्त वर्ग Magento \ कैटलॉग \ Block \ Product \ View \ AbstractView को *** / विक्रेता / Magento / फ्रेमवर्क / ObjectManager / Factory / AbstractFactory.php में लाइन 93 पर नहीं देखा जा सकता

मैंने किसी भी कस्टम ब्लॉक की खोज मैगेंटो \ कैटलॉग \ ब्लॉक \ प्रोडक्ट \ व्यू \ एसट्रीव्यू के लिए की है, लेकिन मैंने इसे केवल लेआउट फाइलों में पाया है, यह किसी भी ब्लॉक क्लास कंस्ट्रक्टर में मौजूद नहीं है

मैं यह नहीं समझ सकता: मैगेंटो इस घातक त्रुटि को संकलित कोड के साथ क्यों फेंक रहा है, लेकिन यह संकलित कोड के बिना एक आकर्षण की तरह काम करता है

Comments

क्या आप पुष्टि कर सकते हैं कि 'सेटअप: di: संकलन' विकास मोड में भी उत्पाद दृश्य त्रुटि का कारण बनता है?

— पेज १aj

हां, दोनों मोड में घातक त्रुटि होती है

— राउल सांचेज

क्या आप "पूरी तरह से अस्पष्ट घातक त्रुटि" पोस्ट कर सकते हैं?

— पेज

मैंने प्रश्न को त्रुटि के साथ अद्यतन किया है। धन्यवाद

— राउल सांचेज़

Answer 1

कमांड setup:di:compileकमांड var/diफ़ोल्डर की सामग्री को Magento <2.2 में और generated Magento के लिए = = 2.2 उत्पन्न करता है

मैगेंटो के अनुसार, यह निम्नलिखित उद्देश्य को पूरा करता है:

• अनुप्रयोग कोड पीढ़ी (कारखाने, परदे के पीछे, और इतने पर)
• क्षेत्र विन्यास एकत्रीकरण (अर्थात, प्रति क्षेत्र पर निर्भर निर्भरता इंजेक्शन विन्यास)
• इंटरसेप्टर पीढ़ी (यानी, इंटरसेप्टर की अनुकूलित कोड पीढ़ी)
• अवरोधन कैश जनरेशन
• रिपॉजिटरी कोड जनरेशन (यानी, एपीआई के लिए जनरेट कोड)
• सेवा डेटा विशेषताएँ पीढ़ी (जो, डेटा ऑब्जेक्ट्स के लिए जेनरेट की गई एक्सटेंशन क्लासेस है)

स्रोत ( http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-compiler.html )

हालांकि, जब आप मैगनेटो को उत्पादन मोड में रखते हैं, तो संकलन के बिना यह वास्तव में अभी भी काम करता है। तो Magento डॉक्स के अनुसार यह एक ऑप्टिमाइज़ेशन स्टेप है (यानी, इंटरसेप्टर का ऑप्टिमाइज़्ड कोड जनरेशन)

जब हमारे पास setup:di:compileकमांड में त्रुटियां होती हैं , तो यह ज्यादातर कस्टम php वर्गों के निर्माणकर्ताओं में से एक में त्रुटियों के कारण होता है।

Comments

धन्यवाद! तो, यह पूरी तरह से वैकल्पिक है ... बस एक बिंदु, इसलिए यह मेरे लिए अधिक स्पष्ट है। हमारे मामले में, सेटअप: डीआई: संकलन कोई त्रुटि नहीं करता है, कमांड ठीक है। यह तब होता है जब कमांड को पूरा करने के बाद, साइट को ब्राउज़ करते समय, जब प्रोडक्ट व्यू पेजों में फैटल एरर को निकाल दिया जाता है

— राउल सांचेज

शायद आप त्रुटि पोस्ट कर सकते हैं? इससे बात और स्पष्ट होगी।

— तजीस

मैंने प्रश्न को त्रुटि के साथ अद्यतन किया है। धन्यवाद

— राउल सांचेज़

Answer 2

यह setup:di:compileहर बार कमांड चलाने के लिए अनिवार्य नहीं है, लेकिन यदि आपने विशेष रूप से कारखाने के तरीकों, प्रॉक्सी, प्लगइन्स या किसी भी कोड संकलन के साथ कोई कोड परिवर्तन किया है, तो आपको इस कमांड को चलाने की आवश्यकता होगी।

अधिक जानकारी

magento setup:di:compileआवश्यक फ़ाइलों को उत्पन्न करने के लिए। दोनों विकल्प MAGENTO_ROOT/var/generation directory(या /generatedयदि मैगेंटो 2.2+) उत्पन्न करने वाली कक्षाओं के साथ समाप्त होता है ।

क्या वर्ग उत्पन्न होते हैं?

1. कारखाना
2. प्रॉक्सी
3. प्लगइन्स

कारखाना

फैक्टरियों का उपयोग उन वस्तुओं को तुरंत करने के लिए किया जाता है जिन्हें स्वचालित रूप से इंजेक्ट नहीं किया जा सकता है। उदाहरण के लिए, किसी उत्पाद ऑब्जेक्ट को डेटाबेस से लोड किया जाना है, लेकिन निर्भरता इंजेक्शन कंटेनर में इस ऑब्जेक्ट को बनाने के लिए पर्याप्त जानकारी नहीं है। इसलिए हम कारखानों का उपयोग करते हैं।

प्रॉक्सी

Magento 2 कंस्ट्रक्टर इंजेक्शन का उपयोग करता है जिसमें सभी निर्भरताएं आवश्यक हैं। आप सभी आश्रितों को पास किए बिना किसी वस्तु को त्वरित नहीं कर सकते। यदि आप वैकल्पिक निर्भरता रखना चाहते हैं तो क्या होगा? यही कारण है कि परदे के पीछे मौजूद हैं।

प्लगइन्स (इंटरसेप्टर)

सीधे शब्दों में कहें, प्लगइन्स Magento 2 के लिए प्राथमिक अनुकूलन तंत्र हैं। कोई और वर्ग फिर से नहीं लिखता है। यह आपको आवेदन के किसी भी सार्वजनिक विधि के पहले या बाद में हुक करने और कुछ करने की अनुमति देता है।

जब आप सेटअप चलाते हैं: di: compile कमांड यह चीजों के नीचे करता है

कोड संकलन में किसी विशेष क्रम में निम्नलिखित सभी शामिल हैं:

• अनुप्रयोग कोड पीढ़ी (कारखाने, परदे के पीछे, और इतने पर)

• क्षेत्र विन्यास एकत्रीकरण (अर्थात, प्रति क्षेत्र पर निर्भर निर्भरता इंजेक्शन विन्यास)

• इंटरसेप्टर पीढ़ी (यानी, इंटरसेप्टर की अनुकूलित कोड पीढ़ी)

• इंटरसेप्शन कैश जनरेशन रिपॉजिटरी कोड जनरेशन (यानी एपीआई के लिए जनरेट कोड)

• सेवा डेटा विशेषताएँ पीढ़ी (जो, डेटा ऑब्जेक्ट्स के लिए जेनरेट की गई एक्सटेंशन क्लासेस है)

इस उत्तर को देखें कि हमें कब कौन सी आज्ञाओं को चलाना चाहिए: https://magento.stackexchange.com/a/184927/35758

Comments

धन्यवाद! तो, यह पूरी तरह से वैकल्पिक है ... बस एक बिंदु, इसलिए यह मेरे लिए अधिक स्पष्ट है। हमारे मामले में, सेटअप: डीआई: संकलन कोई त्रुटि नहीं करता है, कमांड ठीक है। यह तब होता है जब साइट ब्राउज़ करना, कमांड के समाप्त होने के बाद, जब प्रोडक्ट व्यू पेजों में फैटल एरर को निकाल दिया जाता है ... तो मुझे वास्तव में समझ में नहीं आता है कि क्यों संकलित कोड अच्छा काम नहीं करता है लेकिन जब कंपाइलिंग होती है तो फालल एरर होता है

— राउल सांचेज

यह तब हो सकता है जब आपके उप-वर्ग ने मूल वर्ग की मौजूदा वैकल्पिक निर्भरता के बाद नई निर्भरता जोड़ दी। आप वैकल्पिक के ऊपर किसी भी नए आवश्यक पैरामीटर को ले जाकर इसे ठीक कर सकते हैं।

— प्रिंस पटेल

Answer 3

Magento अभी भी डि के बिना उत्पादन और देव में चलेगा: संकलन करें। यह वास्तव में इंटरसेप्टर्स को संकलित करेगा क्योंकि इसे generatedफ़ोल्डर में संग्रहीत करने और इसे संग्रहीत करने की आवश्यकता है ।

यहां तक ​​कि अगर यह काम करता है, इसका मतलब यह नहीं है कि आपको इस कदम को छोड़ देना चाहिए! वास्तव में, जब इसे चलाया जाता है, तो Magento डुप्लिकेट किए गए इंजेक्शन, निर्भरता लूप और अन्य मौलिक कदमों के लिए भी जांच करता है जो आपकी साइट को अधिक स्थिर और दुर्घटनाग्रस्त होने और मरने की संभावना कम कर देगा।

मेरा दृढ़ता से मानना ​​है कि त्रुटि एक वर्ग के उपयोग के कारण है जो मैगेंटो कुछ गलत निर्माण तर्क के कारण संकलित नहीं कर सकता है।

आपके द्वारा पोस्ट की गई त्रुटि बहुत अस्पष्ट है, लेकिन मेरा मानना ​​है कि आपके पास एक वर्ग है जो वर्ग का विस्तार करता है AbstractView, 99% यह आपके कस्टम मॉड्यूल में कहीं न कहीं एक ब्लॉक है जो parent::__construct()विधि के लिए सही तर्क पास नहीं करता है । इसलिए जब तत्काल किया जाता है तो यह विफल हो जाता है।

ध्यान दें कि सभी ब्लॉक AbstractView क्लास का विस्तार करते हैं, इसलिए आपको कंपाइल कमांड को xdebugऑन करना होगा और स्टैक ट्रेस पर एक लॉग सेट करके यह देखना होगा कि यह असफल होने से पहले किस क्लास ने इसे कॉल किया था।

तथ्य यह है कि साइट उस त्रुटि के बिना चलती है इसका मतलब है कि आप वास्तव में अपने पृष्ठ पर कहीं भी भ्रष्ट ब्लॉक का उपयोग नहीं कर रहे हैं , लेकिन मैगेंटो अभी भी कमांड चलाने के दौरान इसे संकलित करने की कोशिश करेगा , इसलिए यह विफल हो जाता है।compile

Comments

इस तरह के एक पुराने सवाल का जवाब देने के लिए समय निकालने के लिए धन्यवाद, अन्य मान्य उत्तर के साथ ... वास्तव में, मैंने कस्टम लेआउट में उस गलत ब्लॉक को ठीक करके इसे हल किया, जैसा कि आपने बताया है

— राउल सांचेज़