Produktumleitungsschleifen

Question

Wir haben eine Magento-Website (1.6.2) auf einem LEMP-Server, den wir seit etwas mehr als 2 Jahren betreiben.Kürzlich haben wir ein paar Änderungen vorgenommen;

• Die gesamte Site wurde auf HTTPS geändert.
• Alle neuen Kategorien erstellt und die alten entfernt, aber die gleichen Produkte beibehalten

• Erstellte Serverumleitungen im Formular;

  standort / diese / alte / Kategorie { ^(diese / alte / Kategorie) / umschreiben?(.*)$ https://oursite.co.uk/new/category$2 dauerhaft;}

Dies funktioniert sowohl für Kategorieseiten als auch für alle darin enthaltenen Produkte und wir dachten, wir wären alle gut!

Google WMT zeigte jedoch viele nicht verfolgte URLs an, sodass wir nachforschten und feststellten, dass viele Produkte auf seltsame Weise umgeleitet werden und zu Umleitungsschleifen führen.

Auf der Registerkarte Netzwerk von Chrome kann ich sehen, dass beim Aufrufen der alten URL bestimmter Produkte die Serverumleitung aktiviert wird und Sie die richtige Antwort erhalten.Es folgen jedoch (scheinbar unendliche) Weiterleitungen, die das Format von annehmen;

random/old/category/random/old/category/random/old/category/random/old/category/random/old/category/random/old/category/random/old/category/random/old/category/random/old/category/product-name

Grundsätzlich wird bei jeder Anfrage immer wieder "zufällig / alt / Kategorie" hinzugefügt.Unsere Server-Hosts sind fest davon überzeugt, dass a) Magento (und damit nicht ihr Problem) und b) ein vorangestellter Schrägstrich sein sollte.

Ich kann keine Einstellungen finden, die dies verursachen würden.

• "Webserver-Weiterleitungen verwenden" ist auf Ja gesetzt.
• Ich habe "grep" für einen Textauszug unserer Datenbank verwendet, um zu versuchen, das Vorkommen einer der betroffenen URLs zu finden (ohne Freude, und ich bin mir sicher, dass dies aufgrund von Punkt 1 nicht der Fall wäre).
• Ich bin auch manuell mit einem feinen Zahnkamm durch den Admin-Bereich gegangen und kann keine möglichen Ursachen erkennen.

Ich hoffe, das sind genug Informationen.Kann mir jemand sagen, wo eine Umleitung anders als auf dem Server stattfinden könnte?

UPDATE:

Wie Douglas betonte, scheint es, dass die neue URL auch umgeleitet wird, aber ich habe die überprüft.konfigurationsdatei für die Site (und andere) und es gibt keine Regel, die dies verursachen würde.

AKTUALISIERUNG2:

Ich hatte einen kleinen Durchbruch.Es scheint, dass, wenn Magento das Produkt in der Kategorie, zu der es umgeleitet wird, nicht finden kann, es in einer Schleife herumläuft.Warum es das tut und nicht nur eine 404, ist mir ein Rätsel, also wäre Hilfe auch gut!

AKTUALISIERUNG3:

3 jahre, ein Serverumzug, eine ganze Menge Erfahrung und ein Upgrade auf CE 1.9.3.8 später denke ich, ich habe einen Durchbruch geschafft!

Ich weiß jetzt mit Sicherheit, dass dies ein Magento-Routing-Problem ist, wie beim Hinzufügen eines die(); zeile im Index.php die Umleitungsschleife tritt nicht auf.

Ich habe diesen Protokollierungscode (der an mehreren Stellen im Internet zu finden ist) dem hinzugefügt Mage_Core_Controller_Varien_Front Klasse:

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;
        }
    }
}

Nach ein wenig Recherche und Verständnis des Codes in dieser Klasse;Magento sucht nach einem Router aus dem System (entweder Kern oder Module), der die Verantwortung für die $request und sobald einer übereinstimmt, wird ein Versandsignal gesendet.

Mit dem obigen Protokollierungscode habe ich eine Liste von Routern erhalten, aber keine Informationen in der $requestData array, das darauf hinweist, dass der Router nie gesendet hat.

In jedem aufgelisteten Router ging ich zum Steuerung / Router.PHP datei und fand die match(Zend_Controller_Request_Http $request) Methode.In den Zeilen, bevor diese Methode true zurückgegeben hat (was eine Übereinstimmung bedeutet), habe ich eine einfache Echozeile hinzugefügt, zB:

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

Dies führte dazu, dass ich den Router verantwortlich fand und ich vermuten das löst die Anfrage nach dem Abgleich nicht aus und führt daher nur eine Schleife durch.Das verantwortliche Modul ist MageWorx_SeoSuite, Ich vermute, dass es in der Vergangenheit von einem Dritten geändert wurde, da ich online keine Hinweise darauf finden kann.Weitere Untersuchungen sind erforderlich, die ich so schnell wie möglich durchführen werde.

Answer 1

Es stellt sich heraus, dass die match(Zend_Controller_Request_Http $request) in der MageWorx_SeoSuite hatte der Router eine switch-Anweisung, die aufgelöst wurde CMS, Rss, Category, Category_layer und andere Routen.

Das Problem war mit dem default (lesen:Produkt) fall dieser switch-Anweisung.Es war eine ziemlich einzigartige Situation (was erklärt, warum nur eine Handvoll Produkte betroffen waren).

Es würde;

• Überprüfen Sie, ob das Ende der URL (dh:Produkt urlKey) hatte eine Neufassung und wenn nicht;
• Überprüfen Sie, ob die niedrigste Kategorie des Produkts neu geschrieben wurde und wenn nicht;
• Laden Sie das Produkt nach ID und holen Sie sich die kanonische URL von der MageWorx_SeoSuite Hilfsklasse;
• Senden Sie eine Weiterleitung an die kanonische URL und aktualisieren Sie die Antwort mit einem früher definierten HTTP-Antwortcode, abhängig von den Konfigurationseinstellungen.
• exit();

Wenn eine der ersten beiden Bedingungsanweisungen war falsch;die Methode würde return false; (Dh:router stimmte nicht überein).Wenn jedoch beide der ersten beiden Bedingungen zu ausgewertet werden true und einige andere Prüfungen bestanden (kanonische URL war nicht leer usw.);die Anweisung würde die Weiterleitung senden und dann einfach exit();.

Ich bin neu in der gesamten Routing-Methodik, aber ich glaube, dass damit ein paar Dinge nicht stimmten;

1. Die Methode hat nicht für alle Routen der Bedingungen einen booleschen Wert zurückgegeben (z. B. wenn ein Produkt und seine unmittelbare Kategorie nicht neu geschrieben wurden).
2. Die Methode würde "übereinstimmen", war es aber nie dispatch'd.
3. Dies basiert auf meinem begrenzten (Bachelor-) Wissen, aber:das scheint ein wirklich schlechtes Software-Design zu sein.

Es lohnt sich, zu diesem Zeitpunkt darauf hinzuweisen, weil ich MageWorx nicht ohne die Fakten auf den Tisch legen möchte:Ich bin mir ziemlich sicher, dass dieser Kodex in den letzten 5 Jahren geändert wurde (wobei mehrere Drittunternehmen dafür verantwortlich sein könnten).

Zusammenfassend:Ich habe das auskommentiert default: case-Anweisung im Switch, damit der Magento Core die Verantwortung übernimmt.Die Täter-URLs gehen jetzt zu einem 404, no-route seite, die ideal ist, da es sich bei allen um alte, nicht existierende Pfade handelt.Normalerweise würde ich den Modulcode nicht auf diese Weise ändern, aber ich habe dies gut dokumentiert und wir sind in der glücklichen Lage, dass die neue Version unserer Website in der Entwicklung ist, sodass der "Fix" vorübergehend ist.