【问题标题】:Magento URL indexing and core_url_rewrite tableMagento URL 索引和 core_url_rewrite 表
【发布时间】:2012-11-12 13:12:02
【问题描述】:

谁能解释一下 Magento 如何确定是否为产品创建新的 URL 重写?每次我运行 Catalog URL Rewrite reindex 过程时,core_url_rewrite 中的行数都会增加大约 10,000 行。由于同时没有修改产品数据,为什么会生成一个新的 URL?

【问题讨论】:

  • 我遇到了同样的问题,到目前为止我怀疑有一些不一致的数据。我会关注这个话题……也许我们会在这里找到答案。您是否使用一些脚本来自动同步价格、数量等?
  • 是的,我们使用 urapidflow 导入从远程服务器生成的信息。但是,这不应该太相关,因为即使我禁用了所有脚本并只运行 reindex,也会发生额外的行。我截断了表格并在本地计算机上单击了 3 次重新索引,每次都发生。
  • 你有几家店?
  • 只有一个。我对代码进行了一些查看,似乎在我们从 1.5.1 升级到 1.7 时引入了一些差异,这意味着它总是生成一个新值而不是使用新值。

标签: magento indexing magento-1.7


【解决方案1】:

这个问题在 Magento 1.7 中仍然存在,但我不知道 1.8 还是 1.9。 Magento 似乎不会删除旧条目。这会严重降低您的数据库速度。解决这个问题的最简单方法是截断表并重新索引它。

  • 登录 mysql 并选择(使用)合适的数据库
  • 执行以下查询:truncate table core_url_rewrite;
  • 转到您的 magento 根目录(命令行)中的 shell 文件夹并执行以下命令:php -f indexer.php -- -reindex catalog_url
  • 或者,您可以在管理员中执行此操作:系统 > 索引管理;重新索引目录 URL 重写

然后检查管理员:目录> URL重写管理,并查看是否已创建新条目。如果这显示没有项目,则 URL 重写将不起作用!

【讨论】:

    【解决方案2】:

    您可以运行以下 SQL 来找出哪些 URL 属于不存在的产品:

    SELECT `cur`.`product_id`
    FROM `core_url_rewrite` AS `cur`
    LEFT OUTER JOIN `catalog_product_entity` AS `cpe`
    ON `cur`.`product_id` = `cpe`.`entity_id`
    WHERE `cpe`.`entity_id` IS NULL
    AND `cur`.`product_id` IS NOT NULL
    

    ...您应该看到一个不存在于中的 entity_id 列表

    `catalog_product_entity`
    

    EcomDev 有一个免费的 URL 重写模块 (http://shop.ecomdev.org/url-rewrite-indexer.html),我发现它很有用。

    编辑

    为了回答这个问题,会生成新的 URL,因为当 URL 重新索引由以下人员触发时:

    Mage_Catalog_Model_Indexer_Url::reindexAll()
    

    ...这是一个包装器:

    Mage_Catalog_Model_Url::refreshRewrites
    

    ... 不检查数据是否已更改。如果这是您需要的,您可以覆盖该类并重新编写功能以比较差异。

    【讨论】:

    • 嗨詹姆斯,感谢您的回复。我不认为问题与不存在的产品有任何关系,我相信每次运行索引时都会为确实存在的产品生成新的 URL,这会导致问题。由于我在运行测试之前在我的开发环境中截断了 core_url_rewrites 表,因此不应该存在任何不存在的产品。我之前遇到过 EcomDev 扩展,将来可能会尝试,但现在我想深入了解为什么核心扩展会创建一个新 URL。
    • 嗨 Cags,我已经编辑了我的答案,希望它更有用。有任何问题,请随时提问。
    • 嗨,james,我明白,调用的是那些代码。但是从我的粗略测试来看,在 Magento 1.5 版中似乎没有生成相同数量的 URL。让我们假设,正如您所说,堆栈中没有任何地方检查值是否已更改(粗略一瞥似乎就是这种情况)。您能想出一个很好的理由来为您网站上的每个产品在每次运行索引过程时都提供一个新的 URL 吗?这对我来说听起来很疯狂,特别是如果它是一个新的“功能”(我需要运行更多的测试)。
    • Re-index all 按照它的暗示进行,并且在运行之前不检查:它与其他每个核心索引器相同(CatalogSearchCatalogInventory 等)。自从我使用 1.5 以来已经有一段时间了,所以我不知道这个功能有多老了。也许您可以向 Magento 提交错误或功能请求,以包括“检查重新索引所有”(或编写补丁?)
    • 我快速搜索了 bug-tracker 并想出了这个 magentocommerce.com/bug-tracking/issue/?issue=13662 ,看来我不是唯一一个受此困扰的人。似乎只有当您拥有同名的产品时才会发生这种情况(由于它们的导入方式,我们有很多产品,简单的产品不单独可见,但都具有相同的名称)。
    【解决方案3】:

    我使用的是 Magento 1.8,我的 core_url_rewrite 表有大约 5 百万!!!!记录。 最后,我覆盖了 Mage_Catalog_Model_Product_Attribute_Backend_Urlkey 中的 beforeSave 函数,并从产品名称的前五个单词中生成了我自己的 url 键。如果前 5 个单词不是唯一的,我会附加一些数字。如果有人对我的代码感兴趣,我可以发布一些 sn-ps。

    在覆盖 Mage_Catalog_Model_Product_Attribute_Backend_Urlkey 后,我截断了 core_url_rewrite 并重建了索引。最后我得到了大约 60.000 个 URL...并且重新索引过程不会添加新的。

    但您必须记住,在截断和重新构建 core_url_rewrite 表时,自定义 url 重写会丢失。也许您的 seo 主管遇到了一些意想不到的问题。导致所有 302er 重定向都丢失了

    干杯

    【讨论】:

      【解决方案4】:

      此问题是由于 Magento 企业版和社区版的早期版本中产品和类别索引系统中的一个已知错误造成的。

      可以在Magento core_url_rewrite table excessively large找到为类别和产品 URL 提供的根本原因分析的完整说明以及对研究和解决方案的额外确认。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-07-21
        • 1970-01-01
        • 2014-07-19
        • 2012-02-14
        • 1970-01-01
        相关资源
        最近更新 更多