Jaka jest przyczyna błędu „Front kontrolera osiągnął 100 iteracji dopasowania routera”?

14

Jako programista Magento napotkałem ten problem mnóstwo razy, wiem, że jest to problem z błędną konfiguracją, gdy pojawia się, że niektóre moduły nie są załadowane, ani ich routery, powodując błąd. W większości przypadków rozwiązuje się go bez akcji, innym razem możesz opróżnić pamięć podręczną

Przeczytałem wiele postów na ten temat, próbując debugować umieszczenie dodatkowego kodu w kontrolerze z rdzeniem Magento app/code/core/Mage/Core/Controller/Varien/Front.php, ale na końcu pokazuje tylko, które routery modułów brakuje, a nie dlaczego nie są ładowane. Za każdym razem, gdy się pojawia, próbuję sprawdzić, które adresy URL powodują błąd, ale są to bezużyteczne informacje, podobnie jak śledzenie kodu. To jest zawsze takie samo

Być może jest to spowodowane konfliktami modułów? Może to jakieś zadanie crona robi coś złego? Może jakiś zły kod w starszych wersjach Magento? Chodzi o to, że ten problem nie występuje od wersji 1.7 (lub jeśli wystąpi, to jest całkowicie sporadyczny). Znalazłem pewne różnice w kodzie w głównym przepływie, takie jak

Mage::register('application_params', $params);

Metoda run () app/code/core/Mage/Core/Model/App.phplub

$this->_shouldSkipProcessModulesUpdates()

sprawdź metodę _initModules () ...

Chcę wierzyć, że powinien być ktoś, kto definitywnie znalazł przyczynę. Jakieś wskazówki?

magento-1.9 error configuration bug router Raul Sanchez
źródło
1
Czy odwoływałeś się do tego? github.com/convenient/…
Tim Hallman
1
Plakat tego artykułu był w stanie rozwiązać problem, zastępując Mage_Core_Model_Configi zmuszając$_useCache = false
Tim Hallman
1
Po przeczytaniu całego artykułu uważam, że powinieneś opublikować to jako właściwą odpowiedź na moje pytanie, aby inni użytkownicy mogli go przeczytać. Dzięki
Raul Sanchez

Odpowiedzi:

12

Wygląda na to, że wystąpił błąd konfiguracji Magento.

Jest doskonały write-up roztworem tutaj .

W tym artykule autor był w stanie naprawić błąd, zastępując Mage_Core_Model_Configi wymuszając $_useCache = falsepodczas ponownego generowania konfiguracji.

Tim Hallman
źródło
4
Cholera! Nigdy nie mogę zebrać przedstawiciela tego artykułu, inni zawsze najpierw go łączą;)
Luke Rodgers
3
Bardzo fajny napis @LukeRodgers!
Tim Hallman
5
Chciałbym tylko skomentować i powiedzieć, że Magento zaakceptowało to jako rozwiązanie problemu z SUPEE-4755 github.com/convenient/…
Luke Rodgers
2
Dodałem także kolejną łatkę. Nie tak miło, ale omówione tutaj. github.com/convenient/…
Luke Rodgers
Mam do czynienia z tym problemem w Magento 2 CE wersja 2.1.0. Należy to naprawić, ponieważ to stary problem?
Ankit Shah,
6

Sprawdź ustawienia konfiguracji Magento Domyślny adres URL bez trasy pod adresem

System> Konfiguracje> Internet> Strony domyślne
. Należy ustawić wartość domyślną cms / index / noRoute . Sprawdź także konkretną wartość sklepu, czy wartość domyślna została tutaj nadpisana. Magento może wejść w nieskończoną pętlę, dopóki nie osiągnie limitu 100 iteracji, jeśli nie zostanie poprawnie ustawiony.

Jeśli używasz Magerun , uruchom to polecenie.

magerun config:set cms/index/noRoute no-route

Znalazłem tutaj rozwiązanie, to był problem w moim przypadku. Możesz sprawdzić adres URL dla innych opcji.

https://merchantprotocol.com/506/solved-front-controller-reached-100-router-match-iterations/

Sandipan S.
źródło
Jeśli wykonam ./n98-magerun.phar config: get no-route, wtedy otrzymuję Nie mogłem znaleźć wartości config dla „no-route”, a pozycja config nawet nie istnieje, czy jesteś pewien swojej odpowiedzi?
Czarny
1
@Czarno robisz to źle. metoda get konsoli wymaga ścieżki - więc twoje polecenie powinno być - \ n "n98-magerun.phar config: get cms / index / noRoute" \ n Sprawdź opcję pomocy, uruchamiając "n98-magerun.phar config: get - help ”
Sandipan S