Magento complètement brisé:Appel à une fonction membre getCode() sur boolean & Il n'y a pas de 404 page CMS configuré ou trouvé

magento.stackexchange https://magento.stackexchange.com//questions/87164

Question

Tout d'un coup (sans aucune modification ou mise à jour) notre installation de magento semble être complètement brisé.

Chaque jour, nous sommes maintenant certains de ces erreurs:

  1. Il n'y a pas de 404 page CMS configuré ou trouvé lors de l'accès /index.
  2. Le programme d'installation de magento soudain s'affiche lors de l'accès /index
  3. Pas de modèle s'affiche (comme indiqué dans l'image)

enter image description here

  1. D'étranges redirection.Quand tout semble fonctionner (pas de 404 cms d'erreur, pas de problèmes de modèle) et j'essaie de visiter un produit parfois, j'ai redirigé vers la page d'accueil.

Eh bien, ce que j'ai fait jusqu'à présent est:

  1. vidé le cache de dossier, une rougeur de la session de dossier
  2. table tronquée core_url_rewrite

Il semblait fonctionner.Après de réindexation (core_url_rewrite) tout semblait brisé à nouveau j'ai donc tronquée de nouveau.Avec vide core_url_rewrite il a regardé tout va bien.Mais le lendemain, il a été brisé à nouveau.

Bien et aujourd'hui c'est la même chose, mais aujourd'hui c'est aussi la première fois où rinçage cache, sessions et core_url_rewrite ne fonctionne plus.

Oh, et c'est dans nos nginx journal des erreurs:

[erreur] 11773#11773:*242799 FastCGI envoyé dans stderr:"PHP message:PHP Fatal error:Appel à une fonction membre getCode() sur boolean dans /htdocs/seg_posorder/stage/app/code/core/Mage/Customer/Model/Session.php sur la ligne 71" tout en lisant l'en-tête de réponse à partir de l'amont, du client:217.24.X.X, serveur:www.example.com, demande:"GET /index.php/client/compte/login/ HTTP/1.1", en amont:"fastcgi://unix:/var/run/php5-fpm.chaussette:", de l'hôte:"www.example.com", parrain:"example.com"

Mais nos magasins semblent aussi bien:

enter image description here

Était-ce utile?

La solution

Après bavarder avec @moose j'ai décidé de poster cela comme une réponse moi-même.Grâce à Nexcess pour le pointage @orignal à mon écriture, et donc de l'alimentation de mon convoitise insatiable pour les étoiles sur mon dépôt github.

Il y a un core de magento cache de configuration d'un bug qui provoque un "404 Page CMS configuré" erreur ou - dans d'autres cas - "100 routeur match itération d'erreur".L'erreur disparaît lorsque vous videz le cache, mais généralement s'affiche de nouveau après un certain temps.

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

(Edit:D'autres changements peuvent être ajoutés pour prévenir la config de la corruption: https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-2-further-improvements)

La réplication

Découvrez mon référentiel ci-dessus.

Il dispose d'un fichier 100-router-script.php ce qui devrait aider à reproduire l'erreur pour vous en cours d'exécution dans la racine de votre site web.

Le Patch

Magento ont sorti un patch (SUPEE-4755) basé sur mon écriture.

PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

Ce patch est exactement le même que celui de mon fix ce qui lui donne une certaine validité.

Ce patch n'est pas cotée en bourse partout parce que Magento ne pas le faire que pour n'importe quoi, mais des correctifs de sécurité pour une raison quelconque.Je sais que le fichier de correctif dit EE_1.13.1.0, mais je l'ai testé sur community edition 1.9 et il s'applique très bien.

Vous pouvez récupérer une copie du patch ici:https://github.com/convenient/magento-ce-ee-config-corruption-bug/blob/master/PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

Et pour des raisons historiques, ou dans le cas de mon github compte est supprimé

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

Si cela ne résout pas votre instance Magento

Ce fichier correctif va résoudre tous raisonnablement vanille magento instances (rien que reinitialises le cache de configuration à l'aide de la définition de init ou reinit les méthodes).

Si vous avez un code qui appelle à la loadDb fonction - comme n98-magerun - alors vous êtes susceptibles d'avoir un mauvais moment et devrait probablement envisager la refactorisation de votre code d'appel de reinit ou init sur Mage_Core_Model_Config.

Si vous avez encore des problèmes, je vous recommande de lire mon article et

  1. Mettre en œuvre la logique mentionné dans la Débogage de la Question de la section.
  2. Attendre quelques données du journal à paraître.
  3. Contactez-moi!

Une théorie sur pourquoi supee 6788 fait la pire erreur

J'ai juste posté ça dans la salle de chat et j'ai pensé pop ici pour la postérité.

Quelque chose à retenir est que magento a TOUJOURS eu ce bug dans un fond.et que supee 6788 a juste fait quelque chose qui est plus susceptible de se produire

J'ai juste eu un coup d'oeil à la supee 6788 patch pour EE1.14 C'est mon hypothèse de travail.

Mage_Core_Controller_Varien_Router_admin a été patché pour remplacer la addModule la fonction

Maintenant, je ne peux pas tout à fait rappeler à l'ordre dans lequel les choses se produisent pendant le mage demande d'initialisation Mais cette modification ajoute désormais deux appels à Mage::getConfig()->getNode() pour chaque requête unique, assez tôt dans le flux.Si il y a un cache d'objets param échec avec useCache au cours de l'une de ces deux appels, il pourrait éventuellement déclencher une configuration incomplète d'être écrites dans le cache (getNode peut déclencher une reinit, comme il essaie de charger des valeurs de la cache, et sur l'échec d'une charge, il va réinitialiser l'ensemble de la config de cache et de ré-enregistrer via le reinit (), fonction)

Alors peut-être juste l'ajout de ces deux getNodes sur un début de partie de la demande, lorsque la configuration complète peut ne pas être chargé pourrait ont causé cette erreur arrive de toute façon je n'aurais pas la sueur plein la compréhension de la question.Ce serait beaucoup de travail pour pas beaucoup de gain, et en le regardant dans Mage_Core_Model_Config::loadDb (avec un accent sur quel est l'effet du useCache drapeau peut avoir sur elle) pourrait conduire un homme fou.

Autres conseils

des problèmes que vous décrivez, seul point 2 est particulièrement familier, mais pour ce que cela vaut la peine, c'est ainsi que nous avons résolu dans notre cas:

Il y a un bug dans la bibliothèque libxml de PHP - je pense que c'est Celui-ci -Ce qui signifie que parfois Magento ne parvient pas à charger certains de ses propres fichiers de configuration.Vous trouverez peut-être que c'était une mise à jour de bas niveau (PHP ou une des bibliothèques qui s'appuie sur) qui a apporté le problème à l'extérieur.

Essayez d'ajouter cette ligne à index.php, juste à côté du début (je l'ai dit juste après la vérification de la version PHP): 

libxml_disable_entity_loader(false);

NEXCESS (partenaire d'hébergement de Magento Platinum) m'a pointé vers la solution sur Github (Big Kudos à Luke Rodgers , l'auteur du patch)

Magento Bug - Cache de configuration corrompue

patch_supee-4755_ee_1.13.1.0_v1.sh

Ce correctif est exactement le même que mon correctif qui lui donne une certaine validité.

Ce patch n'est pas répertorié publiquement nulle part parce que Magento ne fait pas que pour quoi que ce soit, mais des correctifs de sécurité pour une raison quelconque. Je connais le fichier de correctif dit EE_1.13.1.0, mais je l'ai testé sur la communauté Edition 1.9 et il a appliqué fin.

Cette page vous donne un Explication complète Et la possibilité de reproduire l'erreur en exécutant le 100-routeur-script.php de votre répertoire racine (ceci a répliqué le problème pour moi, premier essai).

le correctif: 

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

Ça continue à dire:

Il serait naïf de moi de croire que cela résoudra complètement la Problème de la configuration de tout le monde Magento. Si cela ne fonctionne pas pour vous, alors je vous recommande

  • Mettre en œuvre la logique mentionnée dans le débogage de la section émission.
  • Attendez que certaines données de journal apparaissent.
  • contactez-moi!

Puisque je n'ai aucune réponse pendant une longue période (et notre magasin est en production pour un client) Je devais proposer ma propre solution.Je vais le partager, peut-être que cela peut aider à trouver le problème:

dans mon index.php j'ai changé: 

/* Store or website code */
$mageRunCode = isset($_SERVER['MAGE_RUN_CODE']) ? $_SERVER['MAGE_RUN_CODE'] : '';

/* Run store or run website */
$mageRunType = isset($_SERVER['MAGE_RUN_TYPE']) ? $_SERVER['MAGE_RUN_TYPE'] : 'store';

Mage::run($mageRunCode, $mageRunType);

à: 

$mageRunCode = 'default';
$mageRunType = 'store';

Mage::app()->setCurrentStore(1);
Mage::run($mageRunCode, $mageRunType, array('is_installed' => true));

Ceci est codé en dur et ne fonctionne que parce que nous avons juste un magasin.Mais toujours, il semble travailler maintenant.

Licencié sous: CC-BY-SA avec attribution
Non affilié à magento.stackexchange
scroll top