Magento completamente rotto:Chiamata a una funzione membro getCode() booleana e non C'era nessun 404 pagina di CMS configurato o non trovato

Question

Improvvisamente (senza eventuali modifiche o aggiornamenti) la nostra installazione di magento sembra essere completamente rotto.

Ogni giorno, ora stiamo ottenendo alcuni di questi errori:

1. Non c'era 404 pagina di CMS configurato o non trovato durante l'accesso /indice.
2. Il programma di installazione di magento improvvisamente si presenta quando si accede a /indice
3. Nessun modello è in mostra (come mostrato in foto)

4. Strano reindirizza.Quando tutto sembra funzionare (no 404 cms errori, non problemi del modello) e cerco di visitare un prodotto a volte mi si verrà reindirizzati alla home page.

Beh, quello che ho fatto finora è:

1. svuotata la cartella cache, svuotato cartella sessione
2. troncato tabella core_url_rewrite

Tutto sembrava funzionare.Dopo la reindicizzazione (core_url_rewrite) tutto sembrava rotto di nuovo così ho troncato di nuovo.Con vuoto core_url_rewrite sembrava tutto ok.Ma il giorno successivo si è rotto di nuovo.

Bene e oggi è lo stesso di nuovo, ma oggi è anche la prima volta in cui vampate di cache, e le sessioni di core_url_rewrite non funziona più.

Oh, e questo sta mostrando in nostro nginx log di errore:

[errore] 11773#11773:*242799 FastCGI inviato in stderr:"PHP messaggio:PHP Fatal error:Chiamata a una funzione membro getCode() booleana in /htdocs/seg_posorder/stage/app/code/core/Mage/Customer/Model/Session.php on line 71" durante la lettura di intestazione di risposta da monte, client:217.24.X.X, il server:www.example.com, richiesta:"GET /indice.php/clienti/account/login/ HTTP/1.1", a monte:"fastcgi://unix:/var/run/php5-fpm.calzino:", host:"www.example.com" referrer:"example.com"

Ma i nostri negozi anche sembrare che vada bene:

Answer 1

Dopo chiacchierando con @alce ho deciso di postare questo come una risposta a me stesso.Grazie a Nexcess per il puntamento @alce per la mia scrittura, e alimentando in tal modo il mio insaziabile brama di stelle sul mio repository github.

C'è un core di magento configurazione della cache bug che provoca un "No 404 Pagina di CMS configurato errore" o - in altri casi - "100 router partita iterazione di errore".L'errore va via quando si svuota la cache, ma di solito appare di nuovo dopo qualche tempo.

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

(Edit:Ulteriori modifiche possono essere aggiunti per evitare config corruzione: https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-2-further-improvements)

Replica

Check out my repository di cui sopra.

Ha un file 100-router-script.php che dovrebbe aiutare a replicare l'errore, basta eseguire nella root del tuo sito web.

La Patch

Magento ha rilasciato una patch (SUPEE-4755) sulla base della mia scrittura.

PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

Questa patch è la stessa esatta come il mio fix, che dà qualche validità.

Questa patch non è quotata in borsa, ovunque, perché Magento non fare che per qualsiasi cosa, ma le patch di sicurezza per qualche motivo.So che il file di patch dice EE_1.13.1.0, ma ho testato su community edition 1.9 ed è applicata bene.

È possibile prendere una copia della patch qui:https://github.com/convenient/magento-ce-ee-config-corruption-bug/blob/master/PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

E, per ragioni storiche, o nel caso che il mio account di github viene mai eliminato

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

Se questo non risolve il tuo Magento istanza

Questo file di patch risolverà tutti ragionevolmente vaniglia magento istanze (nulla di che reinitialises la cache di configurazione utilizzando un determinato init o reinit metodi).

Se avete qualche codice che chiama la loadDb funzione - come n98-magerun - quindi hai più probabilità di avere un brutto momento e probabilmente dovrebbe considerare il refactoring del codice per chiamare reinit o init su Mage_Core_Model_Config.

Se hai ancora problemi, ti consiglio di leggere la mia scrittura e

1. Implementare la logica menzionati nel Il debug il Problema sezione.
2. Attendere alcuni dati del registro di apparire.
3. In contatto con me!

Una teoria sul perché supee 6788 fa l'errore di peggio

Ho appena postato questo nella chat room e ho pensato di inserirlo qui per i posteri.

Qualcosa da ricordare è che magento ha SEMPRE avuto questo bug in sottofondo.e che supee 6788 ha appena fatto qualcosa di che è più probabile che accada

Ho appena dato uno sguardo al supee 6788 patch per EE1.14 Questa è la mia teoria di lavoro.

Mage_Core_Controller_Varien_Router_admin è stato corretto per eseguire l'override del addModule funzione

Ora, non riesco a ricordare l'ordine in cui le cose si verificano durante il mago richiesta di inizializzazione, Ma questa modifica aggiunge due chiamate a Mage::getConfig()->getNode() su ogni singola richiesta, molto presto nel flusso.Se c'è un oggetto cache param fallimento con useCache durante uno di questi due chiamate, quindi potenzialmente potrebbe innescare una configurazione incompleta essere scritta la cache (getNode può innescare una reinit, come si cerca di caricare i valori dalla cache, e non è riuscito carico, sarà reinit l'intera configurazione della cache e ri-salvare tramite il reinit funzione ())

Quindi, forse, solo l'aggiunta di questi due extra getNodes su una parte molto presto della richiesta, quando la configurazione completa potrebbe non essere caricato potrebbe hanno causato questo errore accadere in ogni modo non vorrei sudare un pieno la comprensione del problema.Sarebbe un sacco di lavoro per un sacco di guadagno, e cercando in Mage_Core_Model_Config::loadDb (con un focus sulla che effetto le useCache bandiera su di esso) potrebbe guidare un uomo insane.

Answer 2

dei problemi che descrivi, solo il punto 2 è particolarmente familiare, ma per quello che vale questo è il modo in cui lo abbiamo risolto nel nostro caso:

C'è un bug nella libreria libxml di PHP - Penso che sia questo -Il che significa che a volte Magento non riesce a caricare alcuni dei propri file di configurazione.Potresti scoprire che è stato un aggiornamento di basso livello (PHP o una delle librerie che si basa su) che ha portato il problema nell'aperto.

Prova ad aggiungere questa linea a index.php, proprio vicino all'inizio (lo metto subito dopo il controllo della versione PHP):

libxml_disable_entity_loader(false);

.

Answer 3

Nexcess (Magento Platinum Hosting Partner) mi ha indicato alla soluzione su GitHub (Big Kudos a Luke Rodgers , l'autore della patch)

Bug magento - cache di configurazione danneggiata .

patch_supee-4755_ee_1.13.1.0_v1.sh

Questa patch è esatta come la mia correzione che gli conferisce una validità.

Questa patch non è elencata pubblicamente da nessuna parte perché Magento non lo fa quello per tutto tranne che le patch di sicurezza per qualche motivo. Conosco il Il file di patch dice EE_1.13.1.0, ma l'ho testato sull'edizione della Comunità 1.9 e ha applicato bene.

Questa pagina ti dà un spiegazione completa E la possibilità di riprodurre l'errore eseguendo il 100-router-script.php dalla directory principale (questo ha replicato il problema per me, prima prova).

La correzione:

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

.

continua a dire:

.

Sarebbe ingenuo di me credere che questo risolverà completamente il Problema per l'installazione di tutti i genitori. Se non funziona per te, allora io Ti consiglio

.
• Attuare la logica menzionata nel debug della sezione del rilascio.
• Attendi che alcuni dati di registro appaiano.
• Contattami!

Answer 4

Dal momento che non ho alcuna risposta per molto tempo (e il nostro negozio è in produzione per un cliente) Avevo bisogno di inventare la mia soluzione.Lo condividerò, forse può aiutare a trovare il problema:

nel mio index.php ho cambiato:

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

.

A:

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

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

.

Questo è hardcoded e funziona solo perché abbiamo solo un negozio.Ma ancora, sembra funzionare ora.