magento url重寫沒用？

Question

我要提兩點。

第一點。 我注意到一種奇怪的行為，很可能是一個bug。 我配置了一個新的Magento干凈實例（沒有其他模塊，所以從頭開始）和一個空數據庫。 我在根目錄下創建了3個類別。 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

我只需要在類別管理屏幕上將“Cat 3”拖放到“cat 2”上方。 所以cat2和cat3的“訂單”號實際上是交換的。

但url索引進程重新索引所有類別的所有產品（URL REWRITE索引）！ 我分析了SQL日志，它實際上對數據庫中的每個產品進行了INSERT。 我看到在core_url_rewrite中插入“Prod 1”，“Prod 2”和“Prod 3”。

這是一個錯誤，因為“Cat 3”保持相同的父類別，因此：1）不需要在“Cat 3”中重寫產品（產品名稱沒有改變，類別名稱沒有改變!! ）2）無需重寫與其他類別相關的產品

實際上，通過選擇，我可以看到core_url_rewrite表的行是相同的（確實沒有更改名稱！產品和產品之上的任何類別之間沒有關聯更改！）

這是我從日志文件中看到的一個SQL查詢我移動類別：

        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個具有相同名稱的產品（可能會發生），那么url鍵是相同的（默認情況下）。 復制產品以創建新產品時，BTW網址密鑰默認也相同。

所以reindex過程變得瘋狂。 例如，2個名為“camera”的產品將重新打包，如下所示：

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性能問題的主要原因之一！

4行php代碼+ htaccess url重寫將完成相同的工作，不需要數據庫表（除了自定義URL重寫或CMS頁面）。 一種動態生成產品網址的方法（根據需要根據名稱和類別）和一種生成類別網址的方法。 然后htaccess重定向。 您只需要在網址中使用關鍵字即可知道它是指向產品或類別的鏈接及其ID。 就像是：

my-cat/camera-112-p.html

htacces URL重寫檢測到它是產品的鏈接（因為-p.htm），它從url（112）獲取產品ID並相應地重定向用戶。 擁有產品ID可能看起來很難看或SEO的問題，但我不這么認為（沒有你能讀到的那么糟糕）。 它必須與最大的好處相平衡：1）不再有大表2​​）無需重新索引這個表（這需要幾個小時，比如8小時，有很多magento網站）。 此過程可能會導致很多超時問題，鎖定等。

至少這應該可以通過選項（或模塊）。 另請注意，您甚至不需要關心永久重定向，因為鏈接中的內容（文本）無關緊要！ 只是身份證很重要。

它存在嗎？ 如果是的話，我會定義購買它來對這個復雜的混亂機制說“再見”（帶有錯誤）

任何反饋意見都會受到高度贊賞。 （特別是如果你發現magento的行為有任何理性，考慮到與使用/管理這個表相關的不良表現，所以必須高度贊賞理性:-)）

謝謝羅德

Answer 1

第一點和第二點似乎已得到解決，請參閱EE 1.13.0.2的注釋（今天發布，CE 1.7即將推出）： http ： //www.magentocommerce.com/knowledge-base/entry/ee113-later-release-notes ＃PROD-URL唯一

但是，值得解決一些問題。

• 為什么URL重寫以這種方式工作？ 因為這就是他們的工作方式 - 這就是他們創建/演變的方式，包括當兩個產品具有相同的url_key時你注意到的賽車重寫錯誤。
• 根據大量的基准測試和經驗，我可以說core_url_rewrite表不是 “Magento性能不佳的主要原因”。 毫無疑問，重新索引過程可能很糟糕。
• 該URL改寫表是必要的，一般的自定義重寫。 建議操縱服務器配置文件（例如Apache .htaccess ）以添加重寫不能認為Magento是一個可以在沒有直接開發人員知識的情況下進行修改和擴展的應用程序（例如，由店主）。
• 使用pretty-urls mod_rewrite模式的建議對任何與SEO有關的商店都不合適，我向你保證，URL路徑對於排名/相關性非常重要。