Usar el mismo nombre de la ruta de Magento para los enrutadores frontend y admin
routing (3)
Descubrí un problema con la lógica de enrutamiento de Magento y me gustaría ver si alguien puede confirmarlo.
Magento apila los enrutadores admin, estándar, luego por defecto y los procesa uno a la vez. Magento obtiene el nombre del módulo actual basado en la URL (ver Mage_Core_Controller_Varien_Router_Standard::match()) , luego verifica si el módulo debe ser manejado por este enrutador, basado en una coincidencia con un frontName en la configuración de Magento. Si se encuentra una coincidencia, la rutea. De lo contrario, continúa al siguiente enrutador.
Extracto de configuración:
<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>
Esto significa que si usa el mismo nombre para su enrutador de frontend que su enrutador de administración, el enrutador de administración siempre coincidirá primero, incluso en las páginas frontales. Su página frontend ahora se base_url como está si fuera una página de administración, usando la base_url administración, que puede ser diferente de la URL de su tienda, causando una redirección interrumpida.
Tenga en cuenta que este problema no es evidente en las instancias de Magento donde la URL base del administrador es la misma que la URL base del frontend.
¿Alguien puede confirmar que mi evaluación de la lógica del enrutador es correcta aquí?
Es posible que desee revisar Varien / Router / Standard.php también en particular:
/**
* 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;
}
Y esto se llama dentro de la match(Zend_Controller_Request_Http $request) método match(Zend_Controller_Request_Http $request) , así como collectRoutes($configArea, $useRouterName) ya que $useRouterName a veces devolverá el admin y también devolverá el standard para las solicitudes frontend. La suposición parece correcta, ya que todo depende de cómo magento construya y _modules la matriz privada _routes y _modules en esta misma clase: Mage_Core_Controller_Varien_Router_Standard .
Creo que en este caso querrá especificar el nodo <use> como standard para frontend y admin para admin, o reescribir la acción del controlador en el nodo <global> .
Creo que tu mejor opción es leer:
y / o paso a través de la lógica con X-debug .
Incluso Alan Storm en su artículo escribe cómo los mismos enrutadores utilizados para frontend y back-end no deberían ser los mismos.
Por lo tanto, parece que este método está aquí para garantizar que el objeto de enrutador estándar se suspenda si, por alguna razón, el objeto de modelo de tienda cree que está en modo de administrador. Al igual que la relación de enrutador estándar / administrador, el objeto de tienda es otra de las cosas que apunta a ciertas partes del proceso de desarrollo de Magento enfocándose primero en la aplicación frontend, y luego apuntando a una consola administrativa más tarde y teniendo que retroceder los cambios .
El objeto de la tienda es un modelo que realmente solo se aplica a la aplicación de frontend / carrito. Sin embargo, debido a que tanto código en Magento supone que el objeto de tienda existe, debe estar disponible para la aplicación de consola de administración. Esto, a su vez, crea problemas en el nivel del enrutador, que es lo que conduce a un cheque como este. Muchas capas de abstracción, sin contratos definidos entre clases / módulos, y el temor a la refactorización creada por la falta de pruebas siempre conducirán a este tipo de situaciones.
Solo para arrojar mis 2 centavos en esto; Ciertamente noté este problema esta noche! Estoy construyendo un módulo personalizado y mis enrutadores config.xml se definen así:
<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>
Obtuve un error 404 en la interfaz mientras que los enrutadores back-end funcionaban bien. Cambié el nombre de la interfaz y voila:
<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>
¡Tiene sentido usar un nombre único, supongo!
Esto no es un error de Magento, pero es algo a tener en cuenta al escribir módulos o al trabajar con código de terceros. He aclarado el problema y la resolución aquí . Esencialmente, la ruta adminhtml existente siempre debe usarse en lugar de crear nuevas rutas de administrador. Esto hace que las URL en el administrador sean consistentes y evita conflictos. Gracias Alan y Jared por ayudarme a entender mejor el enrutamiento de Magento.