Loop reindirizzamento del prodotto.
-
13-12-2019 - |
Domanda
Abbiamo un sito web Magento (1.6.2) su un server LEONE che abbiamo avuto in esecuzione per poco più di 2 anni. Recentemente abbiamo fatto alcuni cambiamenti;
- .
- ha cambiato l'intero sito su https.
- ha creato tutte le nuove categorie e si è liberato dei vecchi, ma ha mantenuto gli stessi prodotti
-
Reindirizza il server creato nel modulo;
Posizione / questa / vecchia / categoria { Riscrivi ^ (questa / vecchia / categoria) /? (. *) $ https://oursite.co. Regno Unito / Nuova / Categoria $ 2 permanente; }
funziona sia per le pagine di categoria che per qualsiasi prodotto all'interno di loro e abbiamo pensato che eravamo tutti buoni!
Tuttavia Google WMT ha iniziato a mostrare molti URL non selezionati, così abbiamo studiato e ha scoperto che molti prodotti vengono reindirizzati stranamente e con conseguente loop reindirizzamento.
Nella scheda Rete di Chrome posso vedere che quando vai al vecchio URL di determinati prodotti, il reindirizzamento del server entra e si ottiene la risposta corretta. Tuttavia, segue quindi i reindirizzamenti (apparentemente infiniti) che prendono il formato di;
casuale / vecchio / categoria / casuale / vecchio / categoria / casuale / anziano / categoria / casuale / anziano / categoria / casuale / anziano / categoria / casuale / vecchio / categoria / casuale / anziano / categoria / Categoria / Categoria / Categoria / casuale / vecchio / categoria / nome-nome
Fondamentalmente aggiunge "casuale / vecchio / categoria" con ogni richiesta, accesa e attiva. I nostri host del server sono adamant che è A) Magento (e quindi non il loro problema) e B) dovrebbe avere una barra precedente.
Non riesco a trovare nessuna impostazione che potrebbe causare questo.
- .
- "Usa reindirizzamento del server Web" è impostato su Sì.
- Ho usato "grep" su una discarica di testo del nostro database per cercare di trovare eventuali eventuali degli URL interessati (senza gioia, e sono sicuro che questo non sarebbe il caso a causa del punto 1). < / Li >.
- Ho anche manualmente attraverso l'area di amministrazione con un drinkbb fine e non riesco a vedere le possibili cause.
Spero che questa sia abbastanza informazioni. Qualcuno può dirmi dove si potrebbe accadere un reindirizzamento diverso dal server?
Aggiornamento:
Come sottolineato Douglas, sembrerebbe che il nuovo URL venga reindirizzato, ma ho controllato il file .conf per il sito (e altri) e non c'è nessuna regola che lo causerebbe.
update2:
Ho avuto una leggera svolta. Sembra che quando Magento non riesca a trovare il prodotto nella categoria è reindirizzato, andrà intorno e round in un ciclo. Perché lo fa piuttosto che un solo 404 è un mistero per me quindi aiuti su quello sarebbe stato buono anche!
update3:
3 anni, un server spostata, un sacco di esperienza e un aggiornamento a CE 1.9.3.8 dopo Penso di aver fatto una svolta!
Ora so per certo che questo è un problema di routing magento, come quando si aggiunge una linea die();
in index.php il ciclo di reindirizzamento non è necessario.
Ho aggiunto questo codice di registrazione (che può essere trovato in più posizioni su Internet) al 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;
}
}
}
.
da un po 'di ricerca e comprensione del codice in questa classe; Magento cerca un router dal sistema (core o moduli) di assumersi la responsabilità per il $request
e una volta che una corrispondenza invierà un segnale di spedizione.
Con il codice di registrazione sopra ho ricevuto un elenco di router ma nessuna informazione nell'array $requestData
che suggerisce che il router non è mai stato inviata.
In ogni router elencato sono andato al file controller / router.php e ha trovato il metodo match(Zend_Controller_Request_Http $request)
. Nelle linee prima di questo metodo restituito true (significatificare una corrispondenza) ho aggiunto una semplice linea Echo, ad esempio:
echo "matched in the xxx module"; die();
.
Ciò ha comportato me trovare il router responsabile e i sospetto che non invia la richiesta dopo la corrispondenza e quindi mantiene looping. Il modulo responsabile è madeworx_seosuite , sospetto che sia stato modificato da una terza parte in passato da quando non riesco a trovare riferimenti a questo online. È necessaria più indagine che farò il prima possibile.
Soluzione
Si scopre che il match(Zend_Controller_Request_Http $request)
nel router di Mageworx_seosuite ha avuto un'istruzione Switch che ha risolto CMS
, Rss
, Category
, Category_layer
e altri percorsi.
Il problema era con il caso default
( Leggi: Prodotto ) Dichiarazione di questa istruzione. Era una situazione unica (che spiega perché ha solo influenzato una manciata di prodotti).
Sarebbe;
- .
- Verifica se la fine dell'URL (I.e: il prodotto
urlKey
) ha avuto una riscrittura ese non ; - Verifica se la categoria di livello più bassa di detto prodotto ha avuto una riscrittura e se non ;
- Carica il prodotto tramite ID e prendi l'URL canonico dalla classe Helper
MageWorx_SeoSuite
; - Invia un reindirizzamento all'URL canonico e aggiorna la risposta utilizzando un codice di risposta HTTP definito in precedenza in base alle impostazioni di configurazione.
-
exit();
Se una delle prime due dichiarazioni condizionate erano false ; Il metodo verrebbe generatoDicetagcode (I.e: il router non corrispondeva). Tuttavia, se entrambi i primi due condizionati valutati a return false;
e alcuni altri controlli passati (URL canonico non era vuoto ecc.); L'affermazione invierebbe il reindirizzamento e quindi semplicemente true
.
Sono nuovo a tutta la metologia di routing, ma credo che c'erano alcune cose sbagliate in questo;
- .
- Il metodo non ha restituito un booleano per tutti i percorsi dei condizionali (ad esempio se un prodotto e la sua categoria IMEDIATE non ha riscrittura).
- Il metodo "corrisponderebbe" ma non è mai stato
exit();
'd. - Questo è basato sulla mia conoscenza limitata (universana) ma: sembra un design davvero cattivo software.
Vale la pena indicare in questo momento, perché non voglio ardere a magaworx senza i fatti: sono abbastanza sicuro che questo codice sia stato modificato negli ultimi 5 anni (per cui le diverse società di terzi potrebbero essere state responsabili) .
In sintesi : Ho commentato l'istruzione Case dispatch
nell'interruttore in modo che il core magento assume la responsabilità. Gli URL Culprit ora vanno in una pagina default:
, 404
Page, che è ideale in quanto sono tutti vecchi percorsi inesistenti. Di solito non avrei modificato il codice del modulo in questo modo di pericolo di HAP, ma ho documentato bene questo e siamo in una posizione fortunata che la nuova versione del nostro sito web sia in fase di sviluppo, quindi la "correzione" è temporanea.