Utilizzo dello stesso nome di instradamento di Magento per i router frontend e admin

Question

Ho scoperto un problema con la logica di routing Magento e vorrei vedere se qualcuno può confermarlo.

Magento impila i router admin, standard, quindi predefinito e li elabora uno alla volta. Magento ottiene il nome del modulo corrente in base all'URL (vedi Mage_Core_Controller_Varien_Router_Standard::match()), quindi controlla se il modulo deve essere gestito da questo router, in base a una corrispondenza con un nome nella configurazione Magento. Se viene trovata una corrispondenza, la instrada. , continua al router successivo

Config estratto:.

 
    <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> 

Questo significa che se si utilizza lo stesso nome per il router frontend come router admin, il router di amministrazione sarà sempre abbinato prima, anche su frontend page. La tua pagina di frontend ora verrà instradata come se fosse una pagina di amministrazione, utilizzando l'amministratore base_url, che potrebbe essere diverso dall'URL del tuo negozio causando un reindirizzamento danneggiato

Si noti che questo problema non è evidente nelle istanze di Magento in cui l'URL della base di amministrazione è uguale all'URL di base del frontend.

Qualcuno può confermare che la mia valutazione della logica del router è corretta qui?

Answer 1

Questo non è un bug Magento, ma è qualcosa di cui essere a conoscenza quando si scrivono moduli o si lavora con codice di terze parti. Ho chiarito il problema e la risoluzione here. In sostanza, la rotta adminhtml esistente dovrebbe sempre essere utilizzata piuttosto che creare nuovi percorsi di amministrazione. Ciò rende coerenti gli URL nell'amministratore ed evita i conflitti. Grazie Alan e Jared per avermi aiutato a capire meglio il routing Magento.

Answer 2

Si consiglia di guardare oltre Varien/Router/Standard.php e in particolare:

/** 
* 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; 
} 

E questo è chiamato all'interno del metodo match(Zend_Controller_Request_Http $request) così come collectRoutes($configArea, $useRouterName) come $useRouterName a volte tornare admin e sarà anche restituire standard per le richieste di frontend. L'ipotesi sembra corretta in quanto tutto dipende da come Magento crea e impila l'array privato _routes e _modules in questa stessa classe: Mage_Core_Controller_Varien_Router_Standard.

credo in questo caso si vorrebbe specificare il nodo <use> come standard per frontend e admin per admin, o riscrivere l'azione di controllo nel nodo <global>.

penso che la cosa migliore è leggere su:

• http://alanstorm.com/magento_dispatch_admin_cms_default_routers

e/o passo attraverso la logica con X-debug.

Anche Alan Storm nel suo articolo scrive come gli stessi router utilizzati per frontend e backend non dovrebbero essere gli stessi.

Quindi sembra che questo metodo sia qui per assicurare che l'oggetto del router standard salti le sbarre se, per qualche motivo, l'oggetto del modello di negozio la pensa in modalità di amministrazione. Come la relazione Router Standard/Admin, l'oggetto store è un'altra di quelle cose che puntano a determinate parti del processo di sviluppo di Magento focalizzate prima sull'applicazione frontend, e poi a virate su una console di amministrazione in un secondo momento e dovute alle modifiche di back-port .

L'oggetto negozio è un modello che si applica solo all'applicazione frontend/carrello. Tuttavia, poiché così tanto codice in Magento assume che l'oggetto negozio esiste, deve essere disponibile per l'applicazione della console di amministrazione.Questo, a sua volta, crea problemi a livello di router, che è ciò che porta a un controllo come questo. Molti strati di astrazione, nessun contratto definito tra classi/moduli e la paura del refactoring creato dalla mancanza di test porteranno sempre a questo tipo di situazioni.

Answer 3

Giusto per lanciare i miei 2 centesimi in questo; Ho sicuramente notato questo problema stasera! Sto costruendo un modulo personalizzato e le mie config.xml router sono definiti in questo modo:

<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> 

stavo ottenendo un errore 404 sul frontend, mentre i router di back-end lavorato bene. Ho cambiato il nome del frontend e voilà:

<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> 

Ha senso usare un nome unico, immagino!