言いたいことは2点。
最初のポイント。 奇妙な動作に気付きました。おそらくバグです。Magento の新しいクリーンなインスタンス (他のモジュールがないため、ゼロから) と空のデータベースを構成しました。ルート カテゴリの下に 3 つのカテゴリを作成しました。また、各カテゴリに 1 つずつ、合計 3 つの製品があります。何かのようなもの：
Cat 1
+ Prod 1
Cat 2
+ Prod 2
Cat 3
+ Prod 3
カテゴリの順序を変更して、「Cat 3」が「Cat 2」の前になるようにすると、次のようになります。
Cat 1
+ Prod 1
Cat 3
+ Prod 3
Cat 2
+ Prod 2
カテゴリ管理画面から「ねこ2」の上に「ねこ3」をドラッグ＆ドロップするだけです。したがって、cat2 と cat3 の「順序」番号は実際に交換されます。
ただし、URL インデックス プロセスでは、すべてのカテゴリのすべての製品のインデックスが再作成されます (URL REWRITE インデックス)。SQL ログを分析したところ、データベース内のすべての製品に対して実際に INSERT が実行されました。「Prod 1」、「Prod 2」、および「Prod 3」の core_url_rewrite に挿入が表示されます。
「カテゴリ 3」は同じ親カテゴリを保持するため、これはバグです。1) 「カテゴリ 3」内の製品を書き換える必要はありません (製品名は変更されませんでした、カテゴリ名は変更されませんでした!! ） 2）他のカテゴリにリンクされた製品を書き直す必要はありません
実際、select を実行すると、core_url_rewrite テーブルの行が同じであることがわかります (確かに、名前は変更されておらず、製品と製品の上のカテゴリ間の関連付けも変更されていません!)。
カテゴリを移動したときにログ ファイルから確認できる SQL クエリの 1 つを次に示します。
SQL: INSERT INTO `core_url_rewrite` (`store_id`,`category_id`,`product_id`,`id_path`,`request_path`,`target_path`,`is_system`) VALUES (?, ?, ?, ?, ?, ?, ?) ON DUPLICATE KEY UPDATE store_id = VALUES(`store_id`), category_id = VALUES(`category_id`), product_id = VALUES(`product_id`), id_path = VALUES(`id_path`), request_path = VALUES(`request_path`), target_path = VALUES(`target_path`), is_system = VALUES(`is_system`)
BIND: array (
0 => '1',
1 => NULL,
2 => '4',
3 => 'product/4',
4 => 'testun.html',
5 => 'catalog/product/view/id/4',
6 => 1,
)
AFF: 0
TIME: 0.0005
実際には、さらに悪いことに、既に存在する行を挿入するため、実際には何も挿入されません。挿入に失敗しました (何も挿入されていないことを意味する "AFF: 0" が表示されます)。
2番目のポイント 別のバグ/奇妙な動作を見つけました。同じ名前の製品が 2 つある場合 (発生する可能性があります)、url キーは同じです (デフォルト)。ところで、製品を複製して新しい製品を作成する場合、デフォルトでは URL キーも同じです。
そのため、再インデックスプロセスはおかしくなります。たとえば、「camera」という名前の 2 つの製品の URL は次のように書き換えられます。
camera-1.html
camera-2.html
私はこれで大丈夫です。しかし、今、すべてを再インデックス化すると、おかしくなります。それらの製品の URL 書き換えが変更されます (それらの製品に関連するものを何も変更していなくても)。次のように 2 つの製品を更新します。
UPDATE camera-1.html => camera-3.html
UPDATE camera-2.html => camera-4.html
設定が有効になっている場合はリダイレクトを挿入します（したがって、以前のリンクは失われません）。
INSERT camera-1.html , camera-3.html ,RP
INSERT camera-2.html , camera-4.html , RP
RP オプションは、永続的なリダイレクトに関するものです。
つまり、2 回の無駄な更新と 2 回の無駄な挿入です。もう一度インデックスを再作成すると、終了を待ってすぐに再インデックスを作成すると、Magento は 4 回の更新、4 回の挿入などを行います。再インデックス間のデータはまったく変更されません:-)
同じ名前の製品が 5,000 個ある場合 (私のように)、10,000 回の更新と 10,000 回の (本当の) 挿入が無料で行われます... core_url_rewrite のサイズは、毎日何度も増加します。Suration は非常に高いです 注: まったく同じ名前の製品が 5,000 個あるのには十分な理由があります :-) 理由が何であれ、これは奇妙に見えます。
これはもうチェックしましたか？Magento とログ ファイルの新規インストールを有効にすると、非常に簡単に確認できます。
最後に、なぜ core_url_rewrite テーブルが必要なのですか? これは、magento のパフォーマンスの問題の主な原因の 1 つです。
4 行の php コード + htaccess url 書き換えは、まったく同じジョブを実行します。これには DB テーブルは必要ありません (カスタム url 書き換えまたは CMS ページを除く)。製品の URL を (必要に応じて名前とカテゴリに基づいて) 動的に生成するメソッドと、カテゴリの URL を生成するメソッドです。次に、htaccess でリダイレクトします。商品へのリンクなのかカテゴリへのリンクなのかを知るために、URL にキーワードとその ID が必要です。何かのようなもの：
my-cat/camera-112-p.html
htacces URL 書き換えは、(-p.htm のため) 製品へのリンクであることを検出し、URL (112) から製品 ID を取得し、それに応じてユーザーをリダイレクトします。製品 ID を持つことは見栄えが悪いか、SEO の問題に見えるかもしれませんが、私はそうは思いません (読めるほど悪くはありません)。そして、大きな利点とのバランスをとる必要があります: 1) 巨大なテーブルはもうありません 2) このテーブルを再インデックス化する必要はありません (多くの magento Web サイトでは、これには 8 時間ほどかかります)。このプロセスは、多くのタイムアウトの問題、ロックなどを引き起こす可能性があります。
少なくとも、これはオプション (またはモジュール) によって可能になるはずです。リンク内のコンテンツ (テキスト) は重要ではないため、永続的なリダイレクトを気にする必要さえないことにも注意してください。IDだけが重要です。
それは存在しますか？はいの場合、この複雑で厄介なメカニズムに「さようなら」と言うために間違いなく購入します（バグあり）
どんなフィードバックでも高く評価されます。(特に、このテーブルの使用/管理に関連するパフォーマンスの低下を考慮して、magento の動作に合理的なものを見つけた場合は、その合理性を高く評価する必要があります:-))
ありがとうロッド