I discovered an issue with Magento routing logic and I would like to see if anyone can confirm this.
Magento stacks routers admin, standard, then default and processes them one at a time. Magento gets the current module name based on the URL (see Mage_Core_Controller_Varien_Router_Standard::match())
, then checks if the module should be handled by this router, based on a match to a frontName in the Magento config. If a match is found, it routes it. If not, it continues to the next router.
Config excerpt:
<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>
This means that if you use the same name for your frontend router as your admin router, the admin router will always be matched first, even on frontend pages. Your frontend page will now route as is if were an admin page, using the admin base_url
, which may be different from your store's URL causing a broken redirect.
Note that this issue is not apparent in Magento instances where the admin base URL is the same as the frontend base URL.
Can anyone confirm that my assesment of the router logic is correct here?
Magento 2 routing defines a URL of the module. The entire Magento 2 application flow is based on processing URL request and router classes which are responsible for matching and processing that requests. Here, the router_name is used to find the module. When a request is made in Magento 2, controller/action: index.
The FrontController class class searches through a list of routers, provided by the RouterList class, until it matches one that can process a request. When the FrontController finds a matching router, it dispatches the request to an action class returned by the router.
To create a router first you need to add it to the \Magento\Framework\App\RouterList, which is transferred to the Front Controller and contains all the available routers in the right order. To do this, we use the di. xml file in our module.
You may want to look over Varien/Router/Standard.php as well in 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;
}
And this is called within the method match(Zend_Controller_Request_Http $request)
as well as collectRoutes($configArea, $useRouterName)
as $useRouterName
will sometimes return admin
and will also return standard
for frontend requests. The assumption sounds correct as it all depends on how magento builds and stacks the _routes
and _modules
private array in this same class: Mage_Core_Controller_Varien_Router_Standard
.
I believe in this case you would want to specify the <use>
node as standard
for frontend and admin
for admin, or rewrite the controller action in the <global>
node.
I think your best bet is to read over:
and/or step through the logic with X-debug.
Even Alan Storm in his article writes how the same routers used for frontend and backend shouldn't be the same.
So it looks like this method is here to ensure the Standard router object bails if, for some reason, the store model object thinks its in admin mode. Like the Standard/Admin router relationship, the store object is another one of those things that points to certain parts of the Magento development process being focused on the frontend application first, and then tacking on an admin console later and having to back-port changes.
The store object is a model that really only applies to the frontend/cart application. However, because so much code in Magento assumes the store object exists, it needs to be available to the admin console application. This, in turn, creates trouble at the router level, which is what leads to a check like this. Many layers of abstraction, no defined contracts between classes/modules, and the fear of refactoring created by the lack of tests will always lead to these sorts of situations.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With