Magento completamente roto:Llamada a una función miembro getCode() en booleano y no se configuró ni se encontró ninguna página 404 CMS

Question

De repente (sin cambios ni actualizaciones) nuestra instalación de Magento parece estar completamente rota.

Todos los días recibimos algunos de estos errores:

1. No se configuró ni se encontró ninguna página 404 CMS al acceder a /index.
2. El instalador de magento aparece de repente al acceder a /index
3. No aparece ninguna plantilla (como se muestra en la imagen)

4. Redirecciones extrañas.Cuando todo parece funcionar (sin error de 404 cms, sin problemas de plantilla) e intento visitar un producto, a veces me redirigen a la página de inicio.

Bueno, lo que hice hasta ahora es:

1. carpeta de caché vaciada, carpeta de sesión vaciada
2. tabla truncada core_url_rewrite

Pareció funcionar.Después de reindexar (core_url_rewrite), todo parecía roto nuevamente, así que lo trunqué nuevamente.Con core_url_rewrite vacío todo parecía estar bien.Pero al día siguiente se volvió a romper.

Bueno, hoy vuelve a ser lo mismo, pero también es la primera vez que vaciar el caché, las sesiones y core_url_rewrite ya no funciona.

Ah, y esto aparece en nuestro registro de errores de nginx:

[error] 11773#11773:*242799 FastCGI enviado en stderr:"Mensaje PHP:Error grave de PHP:Llame a una función miembro getCode() en booleano en /htdocs/seg_posorder/stage/app/code/core/Mage/Customer/Model/Session.php en la línea 71" mientras lee el encabezado de respuesta del cliente ascendente:217.24.X.X, servidor:www.ejemplo.com, solicite:"GET /index.php/customer/account/login/HTTP/1.1", ascendente:"fastcgi://unix:/var/run/php5-fpm.sock:", anfitrión:"www.ejemplo.com", referente:"ejemplo.com"

Pero nuestras tiendas también parecen estar bien:

Answer 1

Después chateando con @moose He decidido publicar esto como respuesta yo mismo.Gracias a Necesario por indicarle a @moose mi artículo y así alimentar mi insaciable lujuria por las estrellas en mi repositorio de github.

Hay un error principal en la caché de configuración de Magento que provoca el error "No hay página 404 CMS configurada" o, en otros casos, un error de "100 iteraciones de coincidencia de enrutador".El error desaparece cuando vacías el caché, pero normalmente vuelve a aparecer después de un tiempo.

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

(Editar:Se pueden agregar más cambios para evitar la corrupción de la configuración: https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-2-further-improvements)

Replicación

Consulte mi repositorio arriba.

tiene un archivo 100-enrutador-script.php lo que debería ayudarle a replicar el error ejecutándolo en la raíz de su sitio web.

El parche

Magento ha lanzado un parche (SUPEE-4755) basado en mi artículo.

PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

Este parche es exactamente igual a mi solución, lo que le da cierta validez.

Este parche no se enumera públicamente en ninguna parte porque Magento no hace eso por nada más que parches de seguridad por alguna razón.Sé que el archivo de parche dice EE_1.13.1.0, pero lo probé en Community Edition 1.9 y se aplicó bien.

Puede obtener una copia del parche aquí:https://github.com/convenient/magento-ce-ee-config-corruption-bug/blob/master/PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

Y por razones históricas o en caso de que alguna vez se elimine mi cuenta de github.

/**
* 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 esto no soluciona tu instancia de Magento

Este archivo de parche resolverá todas las instancias razonablemente básicas de Magento (cualquier cosa que reinicie el caché de configuración usando el archivo definido). init o reinit métodos).

Si tiene algún código que llame al loadDb función - como n98-magerun - entonces es probable que lo pases mal y probablemente deberías considerar refactorizar tu código para llamar reinit o init en Mage_Core_Model_Config.

Si todavía tienes problemas, te recomiendo que leas mi artículo y

1. Implementar la lógica mencionada en el Depurando el problema sección.
2. Espere a que aparezcan algunos datos de registro.
3. ¡Contáctame!

Una teoría sobre por qué supee 6788 empeora el error

Acabo de publicar esto en la sala de chat y pensé en dejarlo aquí para la posteridad.

Algo para recordar es que Magento siempre ha tenido este error en su fondo.y ese su sobre 6788 acaba de convertirlo en algo que es más probable que suceda

Acabo de echar un vistazo al parche supee 6788 para EE1.14. Esta es mi teoría de trabajo.

Mage_Core_Controller_Varien_Router_Admin fue parcheado para anular el addModule función

Ahora, no puedo recordar el orden en el que ocurren las cosas durante la inicialización de la solicitud de mage. Pero esta modificación ahora agrega dos llamadas a Mage::getConfig()->getNode() en cada solicitud, bastante temprano en el flujo.Si hay una falla en el parámetro de caché de objetos con useCache durante cualquiera de estas dos llamadas, entonces podría provocar que se escriba una configuración incompleta en el caché (getNode puede desencadenar un reinicio, ya que intenta cargar valores desde el caché, y en un carga fallida, reiniciará todo el caché de configuración y lo volverá a guardar mediante la función reinit())

Entonces, tal vez solo agregar estos dos GetNodes adicionales a una parte muy temprana de la solicitud, cuando la configuración completa puede no cargarse podría haber causado que este error ocurra de cualquier manera, no sudaría una comprensión completa del problema.Sería mucho trabajo para no mucha ganancia, y mirar a Mage_Core_Model_Config :: LoadDB (con un enfoque en qué efecto puede tener el indicador de USECACHE en él) podría volver a un hombre loco.

Answer 2

De los problemas que describe, solo el punto 2 es particularmente familiar, pero por lo que vale la pena, así es como lo resolvimos en nuestro caso:

Hay un error en la Biblioteca Libxml de PHP: creo que es este -Lo que significa que a veces Magento no carga algunos de sus propios archivos de configuración.Puede encontrar que era una actualización de bajo nivel (PHP o una de las bibliotecas en la que confía) que sacó el problema al principio.

Intente agregar esta línea a index.php, cerca del inicio (lo puse justo después de la verificación de la versión PHP):

libxml_disable_entity_loader(false);

Answer 3

nexcess (Magento Platinum Hosting Partner) Me señaló a la solución en GitHub (Big Kudos a Luke Rodgers , el autor del parche)

Magento Bug - Cache de configuración dañada

patch_supee-4755_ee_1.13.1.0_v1.sh

Este parche es exactamente igual que mi solución que le da alguna validez.

Este parche no está enumerado públicamente en cualquier lugar porque Magento no lo hagas Eso para cualquier cosa menos parches de seguridad por alguna razón. Sé que el El archivo de parche dice EE_1.13.1.0, pero lo probé en la edición de la comunidad 1.9 y se aplicó bien.

Esta página le da una explicación completa Y la capacidad de reproducir el error al ejecutar el 100-router-script.php de su directorio raíz (esto replicó el problema para mí, primero intento).

la solución:

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

continúa diciendo:

Sería ingenuo de mí creer que esto resolverá completamente el Problema para Everyones Magento Configuración. Si no funciona para ti, entonces yo te recomiendo

• Implementar la lógica mencionada en la depuración de la sección de emisión.
• Espere a que aparezcan algunos datos de registro.
• contactame!

Answer 4

Dado que no tengo ninguna respuesta durante mucho tiempo (y nuestra tienda está en producción para un cliente), necesitaba encontrar mi propia solución.Lo compartiré, tal vez pueda ayudar a encontrar el problema:

en mi índice.php he cambiado:

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

Esto es codificado y solo funciona porque solo tenemos una tienda.Pero aún así, parece funcionar ahora.