Magento - Страница продукта 404 с правильными данными о продукте

У меня странная проблема с импортом данных Magento, и мне было интересно, сталкивался ли кто-нибудь еще с этим и, возможно, нашел решение, которое поможет диагностировать проблему.

Я использовал инструмент переноса данных Magento для переноса данных из экземпляра Magento 1 в существующий экземпляр Magento 2. В экземпляре Magento 2 уже были некоторые данные, так что это не была свежая копия всего, я делал это поэтапно, сначала только заказы, затем только клиенты и, наконец, продукты и категории. Я проигнорировал блоки и страницы CMS, поскольку те, которые необходимо было сохранить, а также тему и несколько других настроек и проблем (поэтому я запустил только migrate: data).

Мой файл конфигурации для переноса данных выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
        xs:noNamespaceSchemaLocation="urn:magento:module:Magento_DataMigrationTool:etc/config.xsd">
    <steps mode="data">
        <step title="Data Integrity Step">
            <integrity>Migration\Step\DataIntegrity\Integrity</integrity>
        </step>
        <step title="EAV Step">
            <integrity>Migration\Step\Eav\Integrity</integrity>
            <data>Migration\Step\Eav\Data</data>
            <volume>Migration\Step\Eav\Volume</volume>
        </step>
        <step title="Map Step">
            <integrity>Migration\Step\Map\Integrity</integrity>
            <data>Migration\Step\Map\Data</data>
            <volume>Migration\Step\Map\Volume</volume>
        </step>
        <step title="Url Rewrite Step">
            <integrity>Migration\Step\UrlRewrite\Version191to2000</integrity>
            <data>Migration\Step\UrlRewrite\Version191to2000</data>
            <volume>Migration\Step\UrlRewrite\Version191to2000</volume>
        </step>
        <step title="ConfigurablePrices step">
            <integrity>Migration\Step\ConfigurablePrices\Integrity</integrity>
            <data>Migration\Step\ConfigurablePrices\Data</data>
            <volume>Migration\Step\ConfigurablePrices\Volume</volume>
        </step>
        <step title="Inventory Step">
            <integrity>Migration\Step\Inventory\Integrity</integrity>
            <data>Migration\Step\Inventory\Data</data>
            <volume>Migration\Step\Inventory\Volume</volume>
        </step>
        <step title="PostProcessing Step">
            <data>Migration\Step\PostProcessing\Data</data>
        </step>
    </steps>
    <steps mode="delta">
        <step title="Map Step">
            <delta>Migration\Step\Map\Delta</delta>
            <volume>Migration\Step\Map\Volume</volume>
        </step>
        <step title="ConfigurablePrices step">
            <delta>Migration\Step\ConfigurablePrices\Delta</delta>
            <volume>Migration\Step\ConfigurablePrices\Volume</volume>
        </step>
        <step title="Url Rewrite Step">
            <delta>Migration\Step\UrlRewrite\Version191to2000Delta</delta>
            <volume>Migration\Step\UrlRewrite\Version191to2000</volume>
        </step>
        <step title="Inventory Step">
            <delta>Migration\Step\Inventory\Delta</delta>
            <volume>Migration\Step\Inventory\Volume</volume>
        </step>
    </steps>
    <source>...</source>
    <destination>...</destination>
    <options>...</options>
</config>

Данные продукта и категории безопасно скопированы, и я могу видеть их все в базе данных, а также в админке. Перезапись URL также работает правильно. Однако на некоторых (но не ВСЕХ) страницах продукта отображаются почти все данные продукта, кроме названия, но заголовок страницы - 404, и он показывает макет 404 и контент 404 под всеми данными продукта (см. Изображение) < a href = "https://i.stack.imgur.com/Ggywb.jpg" rel = "nofollow noreferrer"> проблема продукта 404 с данными продукта.

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

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

Кто-нибудь сталкивался с этой проблемой раньше и, возможно, нашел решение или хороший способ выяснить, какие плохие данные портят это?


person Erica Summers    schedule 08.01.2020    source источник


Ответы (1)


Для всех, кто может столкнуться с этой проблемой, я понял проблему. При миграции данных я использовал категории, продукты и переписанные URL-адреса. Перезаписанные URL-адреса были перенесены с правильными путями запроса, но их идентификаторы были разными, поэтому каким-то образом они нарушили путь Magento, и все страницы были 404.

Когда я вошел в продукт, изменил ключ URL-адреса на что-то другое, а затем изменил его обратно, он восстановил правильный URL-адрес, правильно связанный в Magento, и страница работала без 404ing.

Это очень неприятно, особенно потому, что в Magento 2 нет встроенного способа регенерации перезаписанных URL-адресов продуктов. Вам нужно вручную удалить все перезаписанные и обновленные URL-адреса, а также повторно сохранить продукты, чтобы восстановить их правильно. Интересно, что я сделал это в другом проекте, где URL-адрес перезаписывался правильно и работал без проблем. Во время этой миграции я убедился, что таблица url_rewrite была очищена и все значения были импортированы, поэтому, вероятно, есть проблемы с исходным содержимым url_rewrite в Magento 1 в этом конкретном проекте, которые вызвали эту проблему.

person Erica Summers    schedule 10.01.2020