Sitio en vivo en blanco en la interfaz o seguir cargando y nunca cargar

Estoy enfrentando el problema más extraño en magento. Estamos utilizando la versión 1.9.0.

Desde los últimos 2 meses, nuestro sitio en vivo está "en blanco" o "sigue cargando" para los navegadores usados. Significa que en este navegador visitamos el sitio muchas veces.

en algunos navegadores, funciona bien. en algunos mostrando en blanco.

pero el backend funciona bien en todos los navegadores.

Estamos enfrentando problemas en Chrome, Mozilla, Opera y todos los demás navegadores.

1) Si borramos el historial del navegador [caché y cookies], entonces está funcionando.

2) Si abrimos el mismo sitio en una ventana privada, está funcionando.

3) Si abrimos el sitio en navegadores recién instalados, funciona por algún tiempo. de nuevo en blanco después de usar el sitio.

4) Si borramos la carpeta var / session, comenzará a funcionar para todos los navegadores durante algún tiempo. de nuevo sitio en blanco.

5) a veces, el sitio seguirá cargándose y nunca se cargará ...

Revisé system.log y exception.log . pero parece que no hay errores relacionados con esto. Estamos usando https para páginas seguras . incluso tenemos la aplicación Andriod en vivo para este sitio. a veces obtendremos errores fatales:

**Fatal error**: Allowed memory size of 536870912 bytes exhausted (tried to allocate 85 bytes) in /lib/Zend/Db/Statement/Pdo.php or lib/Varien/Object.php or /lib/Varien/Db/Select.php or app/code/core/Mage/Core/Model/Config.php

configuramos memory_limit = 1512 Mb en php.ini

en .htaccess tenemos los siguientes archivos.

php_value memory_limit 1512M php_value max_execution_time 18000

Descomentamos esto:

ini_set('display_errors', 1);

pero no se muestra ningún error en la interfaz. Este es el registro de errores de apache :

child pid 23845 señal de salida Falla de segmentación (11), posible coredump en / etc / apache2

Realmente luchando para resolver este problema. ¿Está este problema relacionado con nuestro código o está relacionado con el lado del servidor?

¿Es la cookie del navegador el principal problema? Si es así, ¿qué debe hacer para resolver este problema de cookies para todos los navegadores? ¿Por qué comenzó a funcionar una vez que borramos la carpeta de sesión?

Nos enfrentamos a estos problemas al navegar por nuestro sitio.

Primero habilite el modo Desarrollador en su .htaccessarchivo, agregue lo siguiente al final del archivo:

SetEnv MAGE_IS_DEVELOPER_MODE "true"

A continuación, edite index.phpy descomente la línea:

#ini_set('display_errors', 1);

Línea referenciada:

• https://github.com/OpenMage/magento-mirror/blob/magento-1.9/index.php#L73

Luego, inicie sesión a través de SSH y busque un archivo de volcado de núcleo /tmpcomo se menciona en el error de falla del segmento. A veces también puede estar en la raíz /o en el directorio raíz del sitio en sí, por ejemplo: /var/www/html/videomergerapp/.

Si no puede localizar ningún archivo de volcado de núcleo, puede agregar algunas directivas adicionales a PHP / Apache.

Echa un vistazo aquí:

• /server/470407/how-to-get-a-core-dump-from-apache-when-segfaulting
• http://www.cyberciti.biz/tips/configure-apache-web-server-for-core-dump.html

Una vez que tenga los archivos de volcado de núcleo, puede usar gdb(if --enable-debug) cuando se configuró PHP. Puede hacer esta determinación emitiendo lo siguiente desde la línea de comandos:

php -i | grep debugo simplemente creando un archivo de script php en la raíz de su servidor web con: <?php phpinfo(); ?>en su contenido y vea el archivo a través del navegador web para ver los valores de configuración de PHP.

• https://bugs.php.net/bugs-generating-backtrace.php

Si no estaba habilitado, entonces no podrá obtener un rastreo completo en PHP, sino solo llamadas de sistema de nivel superior y / o rastreo de apache:

Si tiene acceso al archivo de volcado del núcleo, la emisión de algo como lo siguiente le dará un seguimiento para ayudarlo a encontrar el punto de falla:

gdb /usr/local/apache2/bin/httpd /tmp/core.2027

Si solo está experimentando problemas aleatorios en el frontend y nunca en el backend, entonces la mayoría de los signos apuntan a un posible problema con la codificación de su plantilla. Una vez que experimente las páginas en blanco (y / o aparece un error si ha habilitado el modo de desarrollador y la visualización de error). Inicie sesión en su administrador y desactive todas las memorias caché y vacíe todas las memorias caché y los almacenes de memoria caché.

Luego, ingrese app/etc/local.xmly configure los módulos locales de desactivación en verdadero.

<disable_local_modules>true</disable_local_modules>

Esto impedirá que el cargador automático cargue los módulos app/code/local.

Para deshabilitar los módulos de la comunidad, es más fácil pasar por cada uno de los archivos de definición de módulos que se encuentran app/etc/modulesy deshabilitar configurando el nodo activo en falso de la siguiente manera:

<active>false</active>

De esta manera, puede ayudar a descartar si un módulo de terceros está causando el origen del problema por el proceso de eliminación. NOTA: No puede disable_local_modulesy simplemente debe pasar por todos sus módulos NO CORE (¡cualquier cosa que Mage_ * ignore!).

Si todavía hay problemas, intentaré un paquete de plantilla predeterminado temporalmente yendo a Sistema> Diseño y definiendo un nuevo diseño de algo como predeterminado o base. Si los paquetes de plantillas de stock funcionan, entonces sabrá que la causa del error reside en sus archivos de diseño de plantilla (.phtml).

Muchas de las plantillas con las que me he encontrado son malas para usar Mage::getModel()->load()dentro de los bucles foreach, ya que esta es una mala práctica y, en última instancia, puede consumir grandes cantidades de memoria y recursos del servidor.

Magento tiene una herramienta de análisis de código que puede ayudar a escanear sus archivos de plantilla para determinar si hay alguno de estos fragmentos de código incorrectos:

• https://github.com/magento-ecg/magniffer

Otras lecturas:

• Fundamentos para depurar una tienda Magento

Además, puede ser útil para todos qué almacenamiento en caché y sesión está utilizando que se define en app/etc/local.xml.

¡Espero que esto ayude!

Supongo que hay una recurrencia en su código. Edite el archivo lib/Varien/Db/Adapter/Pdo/Mysql.phpy configúrelo $_debugcomo $_logCallStackverdadero. Esto debería registrar la pila de llamadas en el var/debug/pdo_mysql.logarchivo, lo que debería darle una idea si hay una recurrencia en su código cuando se tarda una eternidad en cargar. Tenga en cuenta que este archivo seguirá creciendo muy rápidamente, así que idealmente habilítelo cuando piense que el problema ha comenzado en el sitio.

Otra forma es deshabilitar los módulos / extensiones con errores que cree que podrían causar esto. Esta podría ser también su extensión de precios configurable simple, intente deshabilitarla temporalmente y vea si ayuda a prevenir el problema.

Tuve el mismo problema en el sitio web de un cliente. Verifique su Magento en busca de malware.

Este es un escenario bien conocido, usualmente es un walware que redirige el contenido de la publicación del usuario a un sitio web externo.

Comience a verificar index.php, generalmente lo piratean. Desplace el código hasta el final, también marque a la derecha y entre las líneas comentadas en el encabezado de la licencia. Los hackers se utilizan para ocultar código de esta manera.

Usted tiene la "carga para siempre" porque intenta contactar sitios web que su ISP bloqueó.

Debería ser bastante fácil encontrar el malware, buscar cadenas "base64", "eval", "mcrypt".

He experimentado un comportamiento similar en un Magento que tenía dos sitios web. El sitio se cargaba bien durante unas pocas páginas y luego se cargaba para siempre.

La configuración de las URL base era incorrecta. La configuración de URL base segura se estableció en el sitio web incorrecto mientras que la URL base no segura se configuró correctamente.

Entonces, para solucionar esto si el administrador ni siquiera funciona correctamente, los valores deben cambiarse en la tabla core_config_data para el sitio web correcto, es decir, establecer la URL correcta con "http: //" y una barra diagonal en el campo de valor correspondiente a la ruta "web / unsecure / base_url" y "web / secure / base_url" para el scope_id correcto que representa el ID del sitio web.

Tenga en cuenta que la URL segura es http solo porque era un sitio web de demostración.