Странные несистемные строки добавляются в core_url_rewrite

core_url_rewriteКажется, что наша таблица чрезмерно растет (в настоящее время 21 млн строк) - я знаю, что были другие вопросы по этому поводу, но ни один из них, кажется, не упоминает эту специфическую странность: у многих добавляемых новых строк есть is_system = 0что- id_pathто вроде " 97704000_1422557940" . Число после подчеркивания выглядит как метка времени, в которую была добавлена ​​строка, но я не уверен, что это за первое число.

Совет для решения core_url_rewriteпроблем, кажется, всегда состоит в том, чтобы урезать таблицу и переиндексировать, и это может прийти к этому, но у нас есть много пользовательских переписываний в таблице, поэтому необходимость их постоянного повторного добавления будет настоящей болью и я бы предпочел разобраться с корнем проблемы.

Мы только что обновились до 1.9.1.0, но в таблице есть строки, возвращающиеся почти два года (!).

Любые идеи?

Это классический выпуск с переписывает. Основная причина не в уникальных URL-ключах. Обычно это вызвано тем, что простые продукты могут быть настроены с тем же именем.

По понятным причинам один путь запроса (URL) должен соответствовать одному действию в Magento. Поэтому все пути запроса должны быть уникальными. URL-пути к продуктам и категориям создаются из их URL-ключей, и, как правило, когда у вас есть настраиваемые продукты, владельцы магазинов / работники бэкэнда не тратят время на то, чтобы простые продукты ниже настраиваемых имели разные URL-ключи. Это заставляет Magento вставлять тире и порядковый номер. Учитывая конфигурируемый продукт с 4 простыми значениями, это означает, что по крайней мере 4 URL-адреса с последовательностью добавляются к каждой итерации (поскольку Magento не различает / не может отличить прогоны, в которых последовательность уже создана). Это быстро складывается в большой каталог.

Рабочий процесс для восстановления выглядит следующим образом:

1. Убедитесь, что все URL-ключи уникальны для исправления вашего ввода, и сделайте еще один переиндекс переписывания.
2. Удалите все переписывает, которые соответствуют WHERE id_path LIKE "%_%" AND options="RP" AND (catalog_id IS NOT NULL OR product_id IS NOT NULL) AND target_path NOT IN (temp_table).
3. Для соответствия оставшихся перезаписей WHERE id_path LIKE "%_%" AND options="RP" AND (catalog_id IS NOT NULL OR product_id IS NOT NULL)установите request_path в target_path, а target_path - в request_path, который соответствует комбинации category_id-product_id и где опции IS NULL.
4. Установите это расширение и включите все оптимизации
5. Reindex переписывает по крайней мере дважды, проверяя количество строк в соответствии (без изменений в продуктах или категориях).
6. Мониторинг Инструментов для веб-мастеров и 404 для получения дополнительных устаревших URL-адресов, которые все еще находятся в пауках и должны быть перенаправлены. Желательно использовать 301 в вашем веб-сервере, чтобы поддерживать его в core_url_rewriteчистоте.

Примечания. Этот сценарий помогает создавать уникальные ключи URL-адресов, перебирая значения атрибутов и добавляя их до тех пор, пока не будет создан уникальный ключ. Обратите внимание, что этот скрипт не проверяет конфликты между категорией и продуктом. Как правило, это не проблема, так как категории естественно называются во множественном числе, но если вы продаете, например, овец или рыбу, это все равно может быть проблемой. Еще один важный случай - столкновение URL-адресов каталога и страниц CMS. Этот скрипт не проверяет его, но он также не влияет на перезапись, поскольку там нет идентификаторов страницы CMS. Это просто приведет к тому, что страница CMS или страница категории / продукта будут отображаться там, где один будет ожидать другого.

Упомянутая временная таблица должна быть заполнена URL-адресами, которые есть во всех файлах сайта. Это смягчает некоторые последствия SEO, сохраняя текущий вариант тире и порядкового номера, и на шаге 3 это затем переписывается в правильный URL. Расширение на шаге 4 не позволяет нескольким URL-адресам входить в таблицу core_url_rewrite, особенно это касается продуктов, для которых не задана видимость «каталог / поиск». Если у вас есть простые продукты, которые являются частью настраиваемых и не перечислены отдельно, они должны быть помечены как «невидимые по отдельности», и это расширение затем не позволяет им вводить изменения. Это ценная оптимизация для магазинов с настраиваемыми продуктами, независимо от того, есть ли у них проблема перезаписи URL. Что касается шага 5, если не внесены изменения в URL-адреса продуктов и категорий, тогда каждая индексация должна генерировать одинаковое количество перезаписей. Если это не так, у вас все еще есть конфликт где-то, и вы должны выследить его.

Надеюсь, это немного прояснит ситуацию.

Я считаю, что это обычно программно сгенерированные перенаправления при изменении продуктов и категорий в каталоге. Они предназначены для поддержания старых ссылок для отправки клиентов в новые местоположения, но вы, вероятно, сможете через некоторое время их очистить, поскольку они имеют тенденцию расти со временем, особенно если у вас есть несколько веб-сайтов / магазинов / просмотров и множество продуктов.