Циклы перенаправления продукта

magento.stackexchange https://magento.stackexchange.com//questions/69204

Вопрос

У нас есть веб-сайт Magento (1.6.2) на сервере LEMP, который работает чуть более 2 лет.Недавно мы внесли несколько изменений;

  • Весь сайт переведён на HTTPS.
  • Создали все новые категории и избавились от старых, но сохранили те же продукты.

  • Создал редиректы сервера в форме;

    местоположение/this/old/category {rewrite ^(this/old/category)/? (.*) $ https://oursite.co.uk/new/category2 доллара на постоянной основе;}

Это работает как для страниц категорий, так и для любых продуктов в них, и мы подумали, что у нас все хорошо!

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

На вкладке «Сеть» Chrome я вижу, что когда вы переходите на старый URL-адрес определенных продуктов, срабатывает перенаправление сервера, и вы получаете правильный ответ.Однако затем следуют (казалось бы, бесконечные) перенаправления, которые принимают формат;

случайный/старый/категория/случайный/старый/категория/случайный/старый/категория/случайный/старый/категория/случайный/старый/категория/случайный/старый/категория/случайный/старый/категория/случайный/старый/категория/случайный/ старый/категория/название продукта

По сути, он добавляет «случайную/старую/категорию» с каждым запросом, снова и снова.Хозяева наших серверов непреклонны в том, что а) Magento (и это не их проблема) и б) должен иметь предшествующую косую черту.

Я не могу найти никаких настроек, которые могли бы вызвать это.

  • Для параметра «использовать перенаправление веб-сервера» установлено значение «да».
  • Я использовал «grep» для текстового дампа нашей базы данных, чтобы попытаться найти любое появление одного из затронутых URL-адресов (без радости, и я уверен, что это не так из-за пункта 1).
  • Я также вручную просмотрел административную область с помощью тонкой зубной щетки и не увидел никаких возможных причин.

Надеюсь, этой информации достаточно.Может ли кто-нибудь сказать мне, где может происходить перенаправление, кроме как на сервере?

ОБНОВЛЯТЬ:

Как отметил Дуглас, похоже, что новый URL-адрес также перенаправляется, но я проверил файл .conf для сайта (и других), и не существует правила, которое могло бы вызвать это.

ОБНОВЛЕНИЕ2:

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

ОБНОВЛЕНИЕ3:

3 года, переезд сервера, огромный опыт и позже обновление до CE 1.9.3.8. Думаю, я совершил прорыв!

Теперь я точно знаю, что это проблема маршрутизации Magento, например, при добавлении die(); строке в index.php цикл перенаправления не происходит.

Я добавил этот код регистрации (который можно найти во многих местах в Интернете) в файл Mage_Core_Controller_Varien_Front сорт:

Mage::log('----Matching routers------------------------------');
Mage::log('Total ' . count($this->_routers) . ': ' . implode(', ', 
array_keys($this->_routers)));
while (!$request->isDispatched() && $i++<100) {
    Mage::log('- Iteration ' . $i);
    $requestData = array(
        'path_info' => $request->getPathInfo(),
        'module' => $request->getModuleName(),
        'action' => $request->getActionName(),
        'controller' => $request->getControllerName(),
        'controller_module' => $request->getControllerModule(),
        'route' => $request->getRouteName()
    );

    $st = '';
    foreach ($requestData as $key => $val) {
        $st .= "[{$key}={$val}]";
    }
    Mage::log('Request: ' . $st);
    foreach ($this->_routers as $name => $router) {
        if ($router->match($this->getRequest())) {
            Mage::log('Matched by "' . $name . '" router, class ' . 
    get_class($router));
            break;
        }
    }
}

Из небольшого исследования и понимания кода этого класса;Magento ищет маршрутизатор в системе (ядро или модули), чтобы взять на себя ответственность за $request и как только один из них совпадет, он отправит сигнал отправки.

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

В каждом указанном маршрутизаторе я зашел в Контроллер/Маршрутизатор.php файл и нашел match(Zend_Controller_Request_Http $request) метод.В строках перед тем, как этот метод вернул значение true (означающее совпадение), я добавил простую строку эха, например:

echo "matched in the xxx module"; die();

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

Это было полезно?

Решение

Оказывается, match(Zend_Controller_Request_Http $request) в маршрутизаторе MageWorx_SeoSuite был оператор переключения, который разрешал CMS, Rss, Category, Category_layer и другие маршруты.

Проблема была с default (читать:продукт) случай этого оператора переключения.Это была совершенно уникальная ситуация (что объясняет, почему она затронула лишь несколько продуктов).

Было бы;

  • Проверьте, находится ли конец URL-адреса (т. е.:продукт urlKey) пришлось переписать и если не;
  • Проверьте, не была ли переписана и изменена категория самого нижнего уровня указанного продукта. если не;
  • Загрузите продукт по идентификатору и получите канонический URL-адрес из MageWorx_SeoSuite вспомогательный класс;
  • Отправьте перенаправление на канонический URL-адрес и обновите ответ, используя ранее определенный код ответа HTTP в зависимости от настроек конфигурации.
  • exit();

Если бы любое из первых двух условных операторов было ЛОЖЬ;метод будет return false; (Т.е.:роутер не подошёл).Однако, если оба первых двух условия оцениваются как true и некоторые другие проверки пройдены (канонический URL не был пустым и т. д.);оператор отправит перенаправление, а затем просто exit();.

Я новичок во всей методологии маршрутизации, но считаю, что здесь есть некоторые недостатки;

  1. Метод не возвращал логическое значение для всех маршрутов условий (например, если продукт и его ближайшая категория не были переписаны).
  2. Метод «совпадал», но никогда не был dispatch'д.
  3. Это основано на моих ограниченных (бакалаврских) знаниях, но:это похоже на действительно плохой дизайн программного обеспечения.

Сейчас стоит отметить это, потому что я не хочу писать о MageWorx без фактов:Я совершенно уверен, что этот код был изменен за последние 5 лет (за что могли нести ответственность несколько сторонних компаний).

В итоге:я закомментировал default: оператор случая в коммутаторе, чтобы ядро ​​Magento взяло на себя ответственность.Виновные URL-адреса теперь переходят на 404, no-route страница, которая идеальна, поскольку все они представляют собой старые несуществующие пути.Обычно я бы не стал изменять код модуля таким рискованным образом, но я хорошо это задокументировал, и нам повезло, что новая версия нашего веб-сайта находится в стадии разработки, поэтому «исправление» является временным.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с magento.stackexchange
scroll top