Magento völlig kaputt:Aufruf einer Mitgliedsfunktion getCode() auf boolean & Es wurde keine 404-CMS-Seite konfiguriert oder gefunden

Question

Plötzlich (ohne Änderungen oder Updates) scheint unsere Magento-Installation völlig kaputt zu sein.

Jeden Tag bekommen wir jetzt einige dieser Fehler:

1. Beim Zugriff auf /index wurde keine 404-CMS-Seite konfiguriert oder gefunden.
2. Beim Zugriff auf /index wird plötzlich das Magento-Installationsprogramm angezeigt
3. Es wird keine Vorlage angezeigt (wie im Bild gezeigt)

4. Seltsame Weiterleitungen.Wenn alles zu funktionieren scheint (kein 404-cms-Fehler, keine Vorlagenprobleme) und ich versuche, ein Produkt zu besuchen, werde ich manchmal zur Startseite weitergeleitet.

Nun, was ich bisher getan habe, ist:

1. geleerter Cache-Ordner, geleerter Sitzungsordner
2. Abgeschnittene Tabelle core_url_rewrite

Es schien zu funktionieren.Nach der Neuindizierung (core_url_rewrite) schien alles wieder kaputt zu sein, also habe ich es erneut gekürzt.Mit leerem core_url_rewrite sah alles in Ordnung aus.Aber am nächsten Tag war es wieder kaputt.

Nun, heute ist es wieder dasselbe, aber heute ist es auch das erste Mal, dass das Leeren von Cache, Sitzungen und core_url_rewrite nicht mehr funktioniert.

Oh, und das wird in unserem Nginx-Fehlerprotokoll angezeigt:

[Fehler] 11773#11773:*242799 FastCGI gesendet in stderr:„PHP-Nachricht:Schwerwiegender PHP-Fehler:Rufen Sie eine Mitgliedsfunktion getCode() auf boolean in /htdocs/seg_posorder/stage/app/code/core/Mage/Customer/Model/Session.php in Zeile 71 auf, während Sie den Antwortheader vom Upstream-Client lesen:217.24.X.X, Server:www.example.com, Anfrage:„GET /index.php/customer/account/login/ HTTP/1.1“, Upstream:„fastcgi://unix:/var/run/php5-fpm.sock:“, Host:„www.example.com“, Referrer:„example.com“

Aber auch unsere Geschäfte scheinen in Ordnung zu sein:

Answer 1

Nach chatten mit @moose Ich habe beschlossen, dies selbst als Antwort zu posten.Dank an Nexcess dafür, dass du @moose auf meinen Beitrag hingewiesen hast und so meine unstillbare Gier nach Sternen in meinem Github-Repository gestillt hast.

Es gibt einen Kernfehler im Magento-Konfigurationscache, der den Fehler „Keine 404 CMS-Seite konfiguriert“ oder – in anderen Fällen – den Fehler „100 Router-Match-Iteration“ verursacht.Der Fehler verschwindet, wenn Sie den Cache leeren, erscheint aber normalerweise nach einiger Zeit wieder.

https://github.com/convenient/magento-ce-ee-config-corruption-bug

(Bearbeiten:Weitere Änderungen können hinzugefügt werden, um eine Beschädigung der Konfiguration zu verhindern: https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-2-further-improvements)

Reproduzieren

Schauen Sie sich mein Repository oben an.

Es hat eine Datei 100-router-script.php Dies sollte dabei helfen, den Fehler für Sie zu reproduzieren, indem Sie es im Stammverzeichnis Ihrer Website ausführen.

Der Patch

Magento hat basierend auf meinem Beitrag einen Patch (SUPEE-4755) veröffentlicht.

PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

Dieser Patch ist genau derselbe wie mein Fix, was ihm eine gewisse Gültigkeit verleiht.

Dieser Patch wird nirgendwo öffentlich aufgeführt, da Magento das aus irgendeinem Grund nicht für Sicherheitspatches tut.Ich weiß, dass die Patch -Datei EE_1.13.1.0 sagt, aber ich habe sie auf der Community Edition 1.9 getestet und sie hat gut angewendet.

Eine Kopie des Patches können Sie hier herunterladen:https://github.com/convenient/magento-ce-ee-config-corruption-bug/blob/master/PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

Und aus historischen Gründen oder für den Fall, dass mein Github-Konto jemals gelöscht wird

/**
* Initialization of core configuration
*
* @return Mage_Core_Model_Config
*/
public function init($options=array())
{
    $this->setCacheChecksum(null);
    $this->_cacheLoadedSections = array();
    $this->setOptions($options);
    $this->loadBase();

    $cacheLoad = $this->loadModulesCache();
    if ($cacheLoad) {
        return $this;
    }
    //100 Router Fix Start
    $this->_useCache = false;
    //100 Router Fix End
    $this->loadModules();
    $this->loadDb();
    $this->saveCache();
    return $this;
}

Wenn dies Ihre Magento-Instanz nicht repariert

Diese Patch-Datei löst alle einigermaßen Vanilla-Magento-Instanzen (alles, was den Konfigurationscache mithilfe der definierten neu initialisiert init oder reinit Methoden).

Wenn Sie einen Code haben, der das aufruft loadDb Funktion - wie n98-magerun - Dann werden Sie wahrscheinlich eine schlechte Zeit haben und sollten wahrscheinlich darüber nachdenken, Ihren Aufrufcode umzugestalten reinit oder init An Mage_Core_Model_Config.

Wenn Sie immer noch Probleme haben, empfehle ich Ihnen, meinen Artikel zu lesen und

1. Implementieren Sie die in der erwähnte Logik Debuggen des Problems Abschnitt.
2. Warten Sie, bis einige Protokolldaten angezeigt werden.
3. Kontaktiere mich!

Eine Theorie, warum supee 6788 den Fehler verschlimmert

Ich habe das gerade im Chatroom gepostet und dachte, ich würde es hier für die Nachwelt veröffentlichen.

Etwas zu erinnern ist, dass Magento diesen Fehler immer im Hintergrund hatte.und dass Supee 6788 es gerade zu etwas gemacht hat, das eher passieren wird

Ich habe mir gerade den supee 6788 Patch für EE1.14 angesehen. Das ist meine Arbeitstheorie.

Mage_Core_Controller_Varien_Router_Admin wurde gepatcht, um das zu überschreiben addModule Funktion

Nun kann ich mich nicht mehr genau an die Reihenfolge erinnern, in der die Dinge während der Initialisierung der Mage-Anfrage geschehen. Diese Änderung fügt nun jedoch zwei Aufrufe von Mage::getConfig()->getNode() bei jeder einzelnen Anfrage hinzu, und zwar ziemlich früh im Ablauf.Wenn während eines dieser beiden Aufrufe ein Objekt-Cache-Parameterfehler mit useCache auftritt, kann dies möglicherweise dazu führen, dass eine unvollständige Konfiguration in den Cache geschrieben wird (getNode kann eine Neuinitialisierung auslösen, wenn versucht wird, Werte aus dem Cache zu laden, und auf einem Wenn das Laden fehlschlägt, wird der gesamte Konfigurationscache neu initialisiert und über die Funktion reinit() erneut gespeichert.)

Vielleicht nur diese beiden zusätzlichen GetNodes zu einem sehr frühen Teil der Anfrage hinzufügen, hätte ich, wenn die vollständige Konfiguration möglicherweise nicht geladen wurde, dazu führen, dass dieser Fehler in beiden Fällen nicht ein vollständiges Verständnis des Problems schwitzen würde.Es wäre eine Menge Arbeit für nicht viel Gewinn, und ein Blick auf mage_core_model_config :: loadDB (mit dem Fokus darauf, welche Auswirkungen das Usecache -Flag auf sich haben könnte) könnte einen Mann wahnsinnig machen.

Answer 2

Von den Problemen, die Sie beschreiben, ist nur Punkt 2 besonders vertraut, aber für das, was es wert ist, ist es, wie wir es in unserem Fall gelöst haben:

Es gibt einen Fehler in der LibxML-Bibliothek von PHP - ich denke, es ist dieses -Das bedeutet, dass Magento manchmal einige eigene Konfigurationsdateien lädt.Sie können feststellen, dass es ein gewisses Update mit niedrigem Niveau (PHP oder einer der von ihm angewiesenen Bibliotheken) war, die das Problem in der Öffnung hervorbrachte.

Versuchen Sie, diese Zeile zu index.php hinzuzufügen, direkt in der Nähe des Starts (ich lege es kurz nach der PHP-Versionsprüfung):

generasacodicetagpre.

Answer 3

nexcess (Magento Platinum Hosting-Partner) zeigte auf die Lösung auf GitHub (großes Kudos zu Luke Rodgers , der Autor des Patches)

magento bug - beschädigt cache .

patch_supee-4755_ee_1.13.1.0_v1.sh

Dieser Patch ist genau wie mein Fix, der ihm etwas Gültigkeit gibt.

Dieser Patch ist nicht öffentlich aufgelistet, weil Magento nicht tut Das für alles andere als Sicherheitspflege aus irgendeinem Grund. Ich kenne das Patch-Datei sagt EE_1.13.1.0, aber ich habe es auf Community Edition 1.9 getestet und es hat sich gut angelegt.

Diese Seite gibt Ihnen einen Vollständige Erläuterung Und die Fähigkeit, den Fehler zu reproduzieren, indem Sie den 100-router-script.php aus Ihrem Root-Verzeichnis (das Problem für mich repliziert, erster Versuch).

das fix:

generasacodicetagpre.

es geht weiter, um zu sagen:

Es wäre naiv von mir, zu glauben, dass dies das vollständig lösen wird Problem für jedes Magento-Setup. Wenn es nicht für Sie funktioniert, dann bin ich Empfehlen Sie

• Implementieren Sie die in der Debugging des Problems erwähnte Logik.
• warten, bis einige Protokolldaten angezeigt werden sollen.
• Kontaktieren Sie mich!

Answer 4

Da ich lange Zeit keine Antwort habe (und unser Geschäft ist in der Produktion für einen Kunden), musste ich mit meiner eigenen Lösung auftreten.Ich teile es, vielleicht kann es helfen, das Problem zu finden:

In meinem Index.php habe ich geändert:

generasacodicetagpre.

an:

generasacodicetagpre.

Dies ist destocodiert und funktioniert nur, da wir nur einen Laden haben.Aber trotzdem scheint es jetzt zu arbeiten.