magento - 对前端和管理路由器使用相同的 Magento 路由名称

Question

我发现 Magento 路由逻辑存在问题，我想看看是否有人可以确认这一点。

Magento 将路由器 admin、standard 和 default 堆叠起来，一次处理一个。 Magento 根据 URL 获取当前模块名称(参见 Mage_Core_Controller_Varien_Router_Standard::match()) ，然后根据 Magento 配置中与 frontName 的匹配来检查模块是否应由此路由器处理。如果找到匹配项，则路由它。如果没有，它会继续到下一个路由器。

配置摘录:
<管理员>
<路由器>
<我的路线>
<使用>管理员
<参数>
MyNamespace_MyModule
我的路线




<前端>
<路由器>
<我的路线>
<使用>管理员
<参数>
MyNamespace_MyModule
我的路线






这意味着，如果您为前端路由器使用与管理路由器相同的名称，则管理路由器将始终首先匹配，即使在前端页面上也是如此。您的前端页面现在将像管理页面一样路由，使用管理员 base_url ，这可能与您商店的 URL 不同，从而导致重定向中断。

请注意，在管理基本 URL 与前端基本 URL 相同的 Magento 实例中，此问题并不明显。

谁能在这里确认我对路由器逻辑的评估是正确的？

Answer 1

您可能还想查看 Varien/Router/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同一类中的私有(private)数组: Mage_Core_Controller_Varien_Router_Standard .
我相信在这种情况下你会想要指定 <use>节点为 standard用于前端和 admin对于管理员，或重写 <global> 中的 Controller 操作节点。
我认为你最好的选择是阅读:

http://alanstorm.com/magento_dispatch_admin_cms_default_routers

和/或使用 X-debug 逐步执行逻辑.
甚至 Alan Storm 在他的文章中写道，用于前端和后端的相同路由器不应相同。

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.