फ्रंटेंड और व्यवस्थापक राउटर

Question

के लिए एक ही Magento मार्ग फ्रंटनाम का उपयोग करके मैंने Magento रूटिंग तर्क के साथ एक समस्या की खोज की और मैं यह देखना चाहता हूं कि कोई भी इसकी पुष्टि कर सकता है या नहीं।

Magento स्टैक्स राउटर व्यवस्थापक, मानक, फिर डिफ़ॉल्ट और उन्हें एक समय में प्रक्रिया करता है। Magento यूआरएल के आधार पर वर्तमान मॉड्यूल नाम प्राप्त करता है (Mage_Core_Controller_Varien_Router_Standard::match()) देखें, फिर यह जांचता है कि मैगेंटो कॉन्फ़िगरेशन में फ्रंट नाम पर एक मैच के आधार पर मॉड्यूल को इस राउटर द्वारा संभाला जाना चाहिए। यदि कोई मिलान मिलता है, तो यह रूट करता है। , यह अगले रूटर करने के लिए जारी

कॉन्फ़िग अंश:।

 
    <admin> 
     <routers> 
      <myroute> 
       <use>admin</use> 
       <args> 
        <module>MyNamespace_MyModule</module> 
        <frontName>myroute</frontName> 
       </args> 
      </myroute> 
     </routers> 
    </admin> 
    <frontend> 
     <routers> 
      <myroute> 
       <use>admin</use> 
       <args> 
        <module>MyNamespace_MyModule</module> 
        <frontName>myroute</frontName> 
       </args> 
      </myroute> 
     </routers> 
    </frontend> 

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

ध्यान दें कि यह समस्या Magento उदाहरणों में स्पष्ट नहीं है जहां व्यवस्थापक आधार URL अग्रभूमि आधार URL के समान है।

क्या कोई यह पुष्टि कर सकता है कि राउटर तर्क का मेरा आकलन सही है?

Answer 1

यह एक Magento बग नहीं है, लेकिन मॉड्यूल लिखते समय या तृतीय पक्ष कोड के साथ काम करने के बारे में कुछ पता होना चाहिए। मैंने इस मुद्दे और संकल्प को here स्पष्ट किया है। अनिवार्य रूप से, मौजूदा व्यवस्थापक HTML मार्ग हमेशा नए व्यवस्थापक मार्ग बनाने के बजाय उपयोग किया जाना चाहिए। यह व्यवस्थापक में यूआरएल को लगातार बनाता है और संघर्ष से बचाता है। Magento रूटिंग बेहतर समझने में मेरी मदद करने के लिए एलन और जेरेड धन्यवाद।

Answer 2

आप विशेष रूप से Varien/रूटर/Standard.php से अधिक देखने के लिए रूप में अच्छी तरह कर सकते हैं:

/** 
* checking if this admin if yes then we don't use this router 
* 
* @return bool 
*/ 
protected function _beforeModuleMatch() 
{ 
    if (Mage::app()->getStore()->isAdmin()) { 
     return false; 
    } 
    return true; 
} 

और इस विधि match(Zend_Controller_Request_Http $request) के साथ-साथ collectRoutes($configArea, $useRouterName)$useRouterName के रूप में के भीतर बुलाया कभी कभी admin वापस आ जाएगी और यह भी नहीं है फ्रंटेंड अनुरोधों के लिए standard वापस करें। धारणा सही लगता है क्योंकि यह सभी इस बात पर निर्भर करता है कि कैसे Magento इस श्रेणी में _routes और _modules निजी सरणी बनाता है: Mage_Core_Controller_Varien_Router_Standard।

मेरा मानना ​​है कि इस मामले में आप दृश्यपटल के लिए standard और admin व्यवस्थापक के लिए के रूप में <use> नोड निर्दिष्ट करें, या <global> नोड में नियंत्रक कार्रवाई के पुनर्लेखन के लिए चाहते हैं।

मुझे लगता है कि आपका सर्वश्रेष्ठ दांव से अधिक पढ़ने के लिए है:

• http://alanstorm.com/magento_dispatch_admin_cms_default_routers

और/या X-debug साथ तर्क से निकलते हैं।

यहां तक ​​कि उनके लेख में एलन तूफान लिखता है कि कैसे आगे के बैकएंड के लिए उपयोग किए जाने वाले समान राउटर समान नहीं होना चाहिए।

तो ऐसा लगता है कि मानक विधि राउटर ऑब्जेक्ट बेल्स सुनिश्चित करने के लिए यह तरीका यहां है, किसी कारण से, स्टोर मॉडल ऑब्जेक्ट इसे व्यवस्थापक मोड में सोचता है। मानक/एडमिन राउटर रिश्ते की तरह, स्टोर ऑब्जेक्ट उन चीजों में से एक है जो Magento विकास प्रक्रिया के कुछ हिस्सों को इंगित करता है, पहले फ्रंटेंड एप्लिकेशन पर ध्यान केंद्रित किया जा रहा है, और फिर बाद में व्यवस्थापक कंसोल पर काम करना और बैक-पोर्ट परिवर्तन करना ।

स्टोर ऑब्जेक्ट एक ऐसा मॉडल है जो वास्तव में केवल फ्रंटेंड/कार्ट एप्लिकेशन पर लागू होता है। हालांकि, क्योंकि Magento में इतना कोड स्टोर ऑब्जेक्ट मौजूद है मानता है, इसे व्यवस्थापक कंसोल एप्लिकेशन के लिए उपलब्ध होना आवश्यक है।यह बदले में, राउटर स्तर पर परेशानी पैदा करता है, जो इस तरह की जांच की ओर जाता है। अमूर्तता की कई परतें, कक्षाओं/मॉड्यूल के बीच कोई परिभाषित अनुबंध नहीं, और परीक्षणों की कमी से बनाए गए रिफैक्टरिंग का डर हमेशा इस तरह की परिस्थितियों का कारण बनता है।

Answer 3

बस इसमें 2 सेंट फेंकने के लिए; मैंने निश्चित रूप से आज रात इस मुद्दे को देखा! मैं एक कस्टम मॉड्यूल का निर्माण कर रहा हूँ और मेरे config.xml रूटर तो तरह परिभाषित कर रहे हैं:

<admin> 
    <routers> 
     <namespace_module> 
      <use>admin</use> 
      <args> 
       <module>Namespace_Module</module> 
       <frontName>namespace_module</frontName> 
      </args> 
     </namespace_module> 
    </routers> 
</admin> 
<frontend> 
    <routers> 
     <namespace_module> 
      <use>standard</use> 
      <args> 
       <module>Namespace_Module</module> 
       <frontName>namespace_module</frontName> 
      </args> 
     </namespace_module> 
    </routers> 
</frontend> 

मैं दृश्यपटल पर एक 404 त्रुटि हो रही थी, जबकि बैकएंड रूटर ठीक काम किया।

<admin> 
    <routers> 
     <namespace_module> 
      <use>admin</use> 
      <args> 
       <module>Namespace_Module</module> 
       <frontName>namespace_module</frontName> 
      </args> 
     </namespace_module> 
    </routers> 
</admin> 
<frontend> 
    <routers> 
     <namespace_module> 
      <use>standard</use> 
      <args> 
       <module>Namespace_Module</module> 
       <frontName>namespace_module_front</frontName> 
      </args> 
     </namespace_module> 
    </routers> 
</frontend> 

भावना का एक अलग नाम मुझे लगता है कि उपयोग करने के लिए बनाता है: मैं दृश्यपटल नाम और देखा बदल गया है!