Magento EE 1.13カタログルーティング

更新
以下は元の質問であり、それが問題が最終的に何であるかに関連しているが、それは正接です。より有用な背景情報については、番号2から始まる編集を参照してください

私たちのサイトには、2つの異なるカテゴリ間の相関関係を説明するCMSページがいくつかあります。そのため、URLはそれらのカタログページのURLに似ている傾向があります。

• CMS URLの例：
  • 「brand / category.html」
• 一致するカテゴリ：
  • "カテゴリー"

Magentoには、カテゴリルートのマッチングをより厳密にする設定がありますか？

編集：私は注意する必要がありますが、明白に感じられます：これらは単なる例の名前です

編集2：役立つ場合、すべてのカタログページにはルート（website.com/subcat）を基準にしたURLがあり、subcatは別のカテゴリの子です。この動作は、他のMagentoインストールのデフォルトとは異なります。（注：これは推奨されておらず、なぜ発生しているのかは不明です）。

編集3：さらに掘り下げた後、私は1.13のURLキーに関するFabrizio Brancaによる記事からの引用を見つけました：

1.13 / 1.8より前は、カテゴリまたは製品のurl-keyとしても使用されていたurl-keyを持つCMSページが最初に評価されていました。このようにして、メインカテゴリをcmsランディングページに簡単に置き換えることができます。これは今変わりました。CMSコントローラーが最初に処理されたとしても、ルーティングプロセスが開始する前に製品とカテゴリのURLが評価されるため、代わりにクリーンな方法でcmsコンテンツを表示することがはるかに困難になります。

編集4：より多くの研究の結果：

• 「正当なカテゴリ」が存在し、デフォルトでは次の場所からアクセスできます /a
• 「正当な他のカテゴリ」も存在し、 b
• これら2つのカテゴリ間の関係に関係なく、どちらも、もう一方を親として使用してアクセスできます（a/b同様に正常に動作しますb/a）。
  • なお、a/b番組のの製品Bとb/aの積A
• ただし、b/b機能せず、機能しませんnon-existant-category/a

私が探しているのは、以前のMagentoバージョン（IE category/subcategory）と同様のURL構造であり、1.13が提供するバックグラウンドインデックスの利点を失うことはありません。

（私はAlanのような回答を投稿したと思いますが、投稿していませんでした。ここでLocalStorageに座っています。しかし、興味深い解理論で彼の答えにタグを付けることができます。）

CMSルーターは、管理ルーターと標準ルーターが追加された後にcontroller_front_init_routersイベントを 監視することで、フロントコントローラーインスタンスに自身を追加します。小さな構成XMLを使用すると、これをイベントに切り替えることができるため、最初にCMSルーターを追加できます。つまり、そのingロジックが他のロジックより先に実行されます。controller_front_init_beforematch()

この理論をテストするには、以下をapp / etc / local.xmlにドロップします。

<frontend>
    <events>
        <!-- fire observer for different event -->
        <controller_front_init_before>
            <observers>
                <cms>
                    <class>Mage_Cms_Controller_Router</class>
                    <method>initControllerRouters</method>
                </cms>
            </observers>
        </controller_front_init_before>
        <!-- disable the original observer -->
        <controller_front_init_routers>
            <observers>
                <cms>
                    <type>disabled</type>
                </cms>
            </observers>
        </controller_front_init_routers>
    </events>
</frontend>

これで問題が解決するかどうかを確認します。

ちなみに、CMSルーターはURL書き換えモデルと同じ方法でリクエストパスを調整します。

私は、長年にわたってMagentoのバックグラウンドを持っていなかったSEOスペシャリストによる多くの興味深い実装（一部は良い、一部は悪い）を見てきました。理解できないカスタムコードで問題が発生しているようです。あなたの質問に対する大まかな答えは、「SEOコードを書いた人や、わからない拡張機能をインストールした人に連絡する」かもしれません。

あなたの質問は、たとえそれが明確になったとしても、まだ混乱しすぎです。文字通り言えば、いいえ、Magentoには「カテゴリのルーティングをより厳密にする」設定はありません。カテゴリルーティングが標準のMagentoシステムでのCMSルーティングに対してどのように機能するかを、大まかに説明します。これにより、（できれば）新しい質問をするのに十分な情報が得られ、理解できるようになります。また、私は以前にMagentoのリクエストディスパッチについて広範囲に記述しました。そのため、核心的な詳細に興味がある場合は、そこから始めます。

カテゴリールーティング

厳密に言うと、Magentoには「カテゴリ」ルーティングはありません。SEO対応のURLがオフになっているサイトでは、カテゴリ一覧ページは次のようになります。

http://magento.example.com/catalog/category/view/id/8

SEO対応のURLがオンの場合、Magentoは（インデックス作成プロセスで）1つからいくつかのエントリを作成します。

core_url_rewrite

そのカテゴリの表。request_pathこちらはインポート用のコラムです。Magentoが特定のURLの処理方法を決定するとき、Magentoは最初にこのテーブルを調べます。現在のURLがと一致する場合request_path、MagentoはURLの内部表現を変更してtarget_path列のようにします。

したがって、サンプルデータには、次のような行があります。

*************************** 1. row ***************************
url_rewrite_id: 17
      store_id: 1
   category_id: 8
    product_id: NULL
       id_path: category/8
  request_path: electronics/cell-phones.html
   target_path: catalog/category/view/id/8
     is_system: 1
       options: NULL
   description: NULL
1 row in set (0.01 sec)

MagentoがURL http://magento.example.com/electronics/cell-phones.htmlを確認すると、request_path変数がであるため、この行と一致しますelectronics/cell-phones.html。次に、URLの内部表現をtarget_path（catalog/category/view/id/8）に変更します。次に、MagentoはURLを通常どおり処理します。

これに慣れていない場合は、おそらくこれで少し従うことになりますが、重要なことは、URLの処理方法を決定するシステムが、それがカテゴリURLであることを気にせず、エントリがあることだけを気にすることですでcore_url_rewriteテーブル。これと同じテーブルが製品名のURLに使用されます。多くのSEO拡張機能とカスタムコードソリューションもこのテーブルを使用します。

CMSページルーティング

Magentoがcore_url_rewriteテーブルの参照を終了した後、次に何が起こるかは

1. 管理アプリケーションページの一致をチェックします（製品の管理、カテゴリの管理など）。

2. フロントエンドアプリケーションページの一致をチェックします（製品リストページ、上記のカテゴリリストページなど）。

3. 1と2に一致するものが含まれていない場合は、CMSページの一致を探します。

Magento はcore_url_rewrite CMSページのテーブルを使用しません。代わりに、ステップ番号3に達すると、URLをURL KeyCMSページオブジェクトのセットと照合しようとします。（MagentoがCMSページの一致を探しているとき、それはcore_url_rewriteプロセスによって既に変更されたURLで動作していると言う方がより正確ですが、物事はすでに十分に混乱しています）

ここで重要なポイントは次のとおりです。CMSマッチングは、カテゴリページのマッチングが失敗した後にのみ発生します。

外部プロセスでcore_url_rewriteテーブルを変更したり、カスタムルーターオブジェクトをシステムに追加して追加のルーティングを実行したり、magento以外のシステムでURLの変更を行ったりしているようです。

申し訳ありませんが、状況に対する迅速かつ簡単な答えはありません。

私が探しているのは、以前のMagentoバージョン（IEカテゴリ/サブカテゴリ）と同様のURL構造であり、1.13が提供するバックグラウンドインデックスの利点を失うことはありません。

これは私が調べてきた問題であり、今のところ優れた解決策はないようです。たとえば、深くネストされたカテゴリがあります。

Cat A
    Cat B
        Cat C
            Cat D

1.13より前は、カテゴリURLはwww.domain.com/cat-a/cat-b/cat-c/cat-d/として生成されていましたが、現在はwww.domain.com/catdとして生成されます。「Cat D」が複数ある場合は、www.domain.com / catalog / category / view / s / cat-d / id / 132 /のように生成される可能性があります。

私はこれに対処するためのさまざまなアイデアをいじくり回してきました、今私が試みている1つのことは、デフォルトの動作を使用する前に、最初にフルパスを探すようにEnterprise_UrlRewrite_Model_Resource_Url_RewriteのloadByRequestPathメソッドを変更することです。私はこのメソッドを追加することでそれを行いました：

protected function tryLoadByFullPath($object, $paths)
{
    if (count($paths) > 1) {
        $_path = implode('/', $paths);

        $select = $this->_getReadAdapter()->select()
            ->from(array('m' => $this->getMainTable()))
            ->where('m.request_path = ?', $_path);

        $result = $this->_getReadAdapter()->fetchRow($select);

        if ($result) {
            $object->setData($result);
            $this->unserializeFields($object);
            $this->_afterLoad($object);

            return true;
        }
    }

    return false;
}

次に、このコードをloadByRequestPath（）の先頭に追加します。

if ($this->tryLoadByFullPath($object, $paths)) {
        return $this;
}

一見、うまく機能しているように見えますが、まだ十分にテストしていません。これの欠点は、url_keyをすべてのカテゴリのフルパスに手動で設定する必要があるため、Cat DのURLキーを「cat-a / cat-b / cat-c / cat-d」に設定する必要があることです。 」それは明らかに理想的ではありません。

とにかく、それはおそらくあまり役​​に立ちませんが、多分誰かがこのアプローチをよりよく理解しているでしょう。

@benmarksの回答はすでに良好です。ただし、製品のURLがCMSページのURLと一致する場合は、引き続き問題が発生します。core_url_rewriteルーターがチェックされる前に、テーブルからのURL書き換えがチェックされます-参照Mage_Core_Controller_Varien_Front::dispatch：

public function dispatch()
{
    // [...]
    $this->_getRequestRewriteController()->rewrite();

    Varien_Profiler::start('mage::dispatch::routers_match');
    $i = 0;
    while (!$request->isDispatched() && $i++ < 100) {
        foreach ($this->_routers as $router) {
            /** @var $router Mage_Core_Controller_Varien_Router_Abstract */
            if ($router->match($request)) {
                break;
            }
        }
    }
    // [...]
}

製品のURLが現在のパス情報と一致する場合、リクエストのパス情報はで変更されるMage_Core_Model_Url_Rewrite_Request::_rewriteDbため、CMSルーターは、カタログルーターの前に呼び出されても、一致しなくなります（@benmarks config.xmlを適用した場合）。 。

幸い、と呼ばれる素晴らしいフラグがありstraight、これをに設定できますMage_Core_Controller_Request_Http。フラグが設定されている場合、データベースからのURL書き換えはチェックされません。したがって、私の解決策は、十分に早いタイミングで発生するイベント（controller_front_init_before）を監視しstraight、現在のパス情報がCMSページ識別子と一致する場合に、そのリクエストにフラグを設定することです。

config.xmlで：

<global>
    <events>
        <controller_front_init_before>
            <observers>
                <namespace_module>
                    <class>namespace_module/observer</class>
                    <method>controllerFrontInitBefore</method>
                </namespace_module>
            </observers>
        </controller_front_init_before>
    </events>
<global>

あなたのオブザーバーメソッド：

class Namespace_Module_Model_Observer
{

    public function controllerFrontInitBefore(Varien_Event_Observer $observer)
    {
        /** @var Mage_Core_Controller_Request_Http $request */
        $request = $observer->getFront()->getRequest();

        $identifier = trim($request->getPathInfo(), '/');
        $pageId = Mage::getModel('cms/page')->checkIdentifier($identifier, Mage::app()->getStore()->getId());

        if ($pageId) {
            $request->isStraight(true);
        }
    }

}

データベースURLの書き換えが適用されていない場合、カタログルーターは一致しないため、このソリューションはそれ自体で機能し、@ benmarksのconfig.xmlも必要ありません。

これが誰かを助けることを願っています-デバッグするのにかなりの努力を要しました！