Как выявить товар, вызывающий проблему при переиндексировании catalog_url

У нас выявилась проблема, связанная с незавершением переиндексирования catalog_url
Кажется, существует уже пару месяцев - не сразу заметили. Увидели, когда добавляли товары через csv и не завершилось переиндексирование.


Текст ошибок при индексировании - во вложенном файле.
 Ошибка переиндексирования.docx (13.07К)
Количество загрузок:: 774
Коротко:
Catalog URL Rewrites index process unknown error:
exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'скрапбукинг/альбомы-бумага-кардст▒' for key 'UNQ_CORE_URL_REWRITE_REQUEST_PATH_STORE_ID''

Один из предыдущих похожих опытов описан в дискуссии по ссылке: http://magento-forum.ru/topic/1463/

После описанного там случая несколько раз проблема всплывала, но по свежим следам достаточно быстро решалась и «токсичный» товар выявлялся и удалялся.
Обычно причиной возникновения такой проблемы были неправильные действия при создании новых карточек товара методом дублирования старых товаров.
Как правило, выстреливали и давали ошибку при дублировании товары с длинными названиями. Если после дублирования с такой ошибкой товар сохранялся, а не удалялся, то могла возникнуть проблема с индексированием.


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

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

Есть ли какой-то способ выявить id товара, который вызывает ошибку, чтобы, удалив его, устранить проблемы с переиндексированием?

Спасибо.

Так происходит из-за превышение адресом товарной страницы максимальной длины, отведённой для его хранения в базе данных.
Надо делать адреса короче, а лучше всего вообще отключить опцию «Система» → «Настройки» → «Каталог» → «Каталог» → «Оптимизация в поисковых системах (SEO)» → «Добавлять ли в адреса товарных страниц названия товарных разделов иерархической цепочки товара?»

Благодарю за ответ! В моей версии перевода админки данная опция названа, как "Использовать путь категории для адресов (URLs) товара". Вы о ней вели речь?
После отключения данной опции произойдет изменение всех ссылок и выпадение сайта из поисковиков?

Спасибо.

Надо делать адреса короче.


Ищете графу «Название в веб-адресе»:

и там пишете конкретный короткий адрес.

Это нужно делать при создании новых товаров?
Или нужно укоротить все существующие длинные ссылки? Выпадение из индекса поисковиков не произойдет?

Это поможет устранить проблему с индексацией catalog_url? Или для этого нужно найти и удалить те товары, которые вызвали данные проблемы?

Спасибо.

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

А есть способ вычислить данные проблемные товары, работая с выгрузкой CSV, экспортированной из magento, или же работая с выгрузкой из базы данных таблицы core_url_rewrite?

Потому как на будущее как поступать стало понятно - резать длину адресов. А вот для того, чтобы устранить проблему с индексацией catalog_url, существующую в данный момент, нужно вычислить те несколько или один товар, которые приводят к данной ошибке индексации.

Спасибо.

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

Спасибо за оперативные ответы! Кроме длины адреса, полагаю, что проблемным фактором может являться длинное совпадающее начало адреса, которое после автоматической обрезки становится полностью идентичным адресу другого товара.

1. Вариант резки длинных адресов можно провести через импорт CSV таблицы с двумя колонками: sku и url_key (в котором содержатся урезанные вручную адреса)? Или этого недостаточно?

2. Есть ли способы провести переиндексацию catalog_url через SSH в визуальном режиме, то есть, наблюдая за процессом, и, видя, на каком конкретно товаре запнулась индексация? Сам я использовал php -f indexer.php — -reindex catalog_url:, что дало лишь возможность увидеть сообщение об ошибке.

1. В результате резки длинных адресов существующие ссылки в индексе поисковых систем не приведут на страницу данного товара? То есть ссылка меняется коренным образом и просто заново проходит индексацию в поисковиках?

2. На странице товара в админке есть галочка "Создать постоянную переадресацию для старых URL". Будет ли как-то влиять данная опция при обрезке длинных ссылок? И представлена ли данная опция в CSV-таблице для импорта?

3. В CSV-таблице для импорта есть столбцы url_key и url_path. Содержимое обоих из столбцов необходимо резать в случае длинных ссылок или только одного из них?

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

Спасибо.

5 вопросов в одной теме задавать нельзя.