Boucles de redirection de produit

Question

Nous avons un site Web Magento (1.6.2) sur un serveur LEMP que nous exploitons depuis un peu plus de 2 ans.Récemment, nous avons apporté quelques modifications ;

• Modification de l'ensemble du site en HTTPS.
• Création de toutes les nouvelles catégories et suppression des anciennes mais conservation des mêmes produits

• Création de redirections de serveur sous le formulaire ;

  Emplacement / this / old / catégorie {réécrire ^ (this / old / catégorie) /? (. *) $ https://oursite.co.uk/new/category2 $ permanents ;}

Cela fonctionne à la fois pour les pages de catégories et pour tous les produits qu'elles contiennent et nous pensions que nous allions tous bien !

Cependant, Google WMT a commencé à afficher de nombreuses URL non suivies. Nous avons donc enquêté et constaté que de nombreux produits étaient redirigés de manière étrange et entraînaient des boucles de redirection.

Dans l'onglet Réseau de Chrome, je peux voir que lorsque vous accédez à l'ancienne URL de certains produits, la redirection du serveur démarre et vous obtenez la réponse appropriée.Cependant, il s'ensuit ensuite des redirections (apparemment infinies) qui prennent le format de ;

aléatoire/ancien/catégorie/aléatoire/ancien/catégorie/aléatoire/ancien/catégorie/aléatoire/ancien/catégorie/aléatoire/ancien/catégorie/aléatoire/ancien/catégorie/aléatoire/ancien/catégorie/aléatoire/ancien/catégorie/aléatoire/ ancien/catégorie/nom-du-produit

Fondamentalement, il ajoute "aléatoire/ancien/catégorie" à chaque demande, encore et encore.Nos hôtes de serveur sont catégoriques sur le fait que a) Magento (et donc ce n'est pas leur problème) et b) devrait avoir une barre oblique précédente.

Je ne trouve aucun paramètre qui pourrait provoquer cela.

• "utiliser les redirections du serveur Web" est défini sur oui.
• J'ai utilisé "grep" sur un vidage de texte de notre base de données pour essayer de trouver toute occurrence de l'une des URL concernées (sans joie, et je suis sûr que ce ne serait pas le cas à cause du point 1).
• J'ai également parcouru manuellement la zone d'administration avec un peigne fin et je ne vois aucune cause possible.

J'espère que ces informations sont suffisantes.Quelqu'un peut-il me dire où une redirection pourrait avoir lieu ailleurs que sur le serveur ?

MISE À JOUR:

Comme Douglas l'a souligné, il semblerait que la nouvelle URL soit également redirigée, mais j'ai vérifié le fichier .conf du site (et d'autres) et il n'y a aucune règle qui pourrait provoquer cela.

MISE À JOUR2 :

J'ai eu une légère percée.Il semble que lorsque Magento ne trouve pas le produit dans la catégorie vers laquelle il est redirigé, il tourne en boucle.Pourquoi il fait cela plutôt qu'un simple 404 est un mystère pour moi, donc aider ce serait bien aussi !

MISE À JOUR3 :

3 ans, un déménagement de serveur, beaucoup d'expérience et une mise à jour vers CE 1.9.3.8 plus tard, je pense avoir fait une percée !

Je sais maintenant avec certitude qu'il s'agit d'un problème de routage Magento, comme lors de l'ajout d'un die(); ligne dans index.php, la boucle de redirection ne se produit pas.

J'ai ajouté ce code de journalisation (qui peut être trouvé à plusieurs endroits sur Internet) au Mage_Core_Controller_Varien_Front classe:

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

Après un peu de recherche et de compréhension du code de ce cours ;Magento recherche un routeur du système (noyau ou modules) pour prendre la responsabilité du $request et une fois que l'un correspond, il enverra un signal d'envoi.

Avec le code de journalisation ci-dessus, j'ai obtenu une liste de routeurs mais aucune information dans le $requestData tableau suggérant que le routeur n'a jamais été distribué.

Dans chaque routeur répertorié, je suis allé au Contrôleur/Routeur.php fichier et j'ai trouvé le match(Zend_Controller_Request_Http $request) méthode.Dans les lignes précédant le retour de cette méthode true (signifiant une correspondance), j'ai ajouté une simple ligne d'écho, par exemple :

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

Cela m'a permis de trouver le routeur responsable et j'ai suspect cela ne distribue pas la demande après la correspondance et continue donc de tourner en boucle.Le module responsable est MageWorx_SeoSuite, je soupçonne qu'il a été modifié par un tiers dans le passé puisque je ne trouve aucune référence à cela en ligne.Une enquête plus approfondie est nécessaire, ce que je ferai dès que possible.

Answer 1

Il s'avère que le match(Zend_Controller_Request_Http $request) dans le routeur MageWorx_SeoSuite avait une instruction switch qui résolvait CMS, Rss, Category, Category_layer et d'autres itinéraires.

Le problème venait du default (lire:produit) cas de cette instruction switch.Il s’agit d’une situation assez particulière (ce qui explique qu’elle n’ait concerné qu’une poignée de produits).

Ce serait le cas ;

• Vérifiez si la fin de l'URL (c'est-à-dire :le produit urlKey) a eu une réécriture et sinon;
• Vérifiez si la catégorie de niveau le plus bas dudit produit a eu une réécriture et sinon;
• Chargez le produit par ID et récupérez l'URL canonique à partir du MageWorx_SeoSuite classe d'assistance ;
• Envoyez une redirection vers l'URL canonique et mettez à jour la réponse à l'aide d'un code de réponse HTTP défini précédemment en fonction des paramètres de configuration.
• exit();

Si l'une des deux premières instructions conditionnelles était FAUX;la méthode serait return false; (C'EST À DIRE:le routeur ne correspond pas).Cependant, si les deux premières conditions sont évaluées à true et quelques autres vérifications réussies (l'URL canonique n'était pas vide, etc.) ;la déclaration enverrait la redirection puis simplement exit();.

Je suis nouveau dans toute la méthodologie de routage, mais je pense qu'il y avait quelques problèmes avec cela ;

1. La méthode n'a pas renvoyé de booléen pour toutes les routes des conditions (par exemple si un produit et sa catégorie immédiate n'avaient pas de réécriture).
2. La méthode "correspondrait" mais n'a jamais été dispatch'd.
3. Ceci est basé sur mes connaissances limitées (de premier cycle), mais :cela semble être une très mauvaise conception logicielle.

Cela vaut la peine de le souligner à ce stade, car je ne veux pas présenter MageWorx sans les faits :Je suis sûr que ce code a été modifié au cours des 5 dernières années (ce dont plusieurs sociétés tierces auraient pu être responsables).

En résumé:J'ai commenté le default: case dans le commutateur afin que le noyau Magento en assume la responsabilité.Les URL coupables vont maintenant vers un 404, no-route page, ce qui est idéal car ce sont tous d’anciens chemins inexistants.Je ne modifierais généralement pas le code du module de cette manière aléatoire, mais je l'ai bien documenté et nous sommes dans une position chanceuse car la nouvelle version de notre site Web est en cours de développement, le « correctif » est donc temporaire.