La depuración es un poco un arte, pero algo que se puede dominar fácilmente siguiendo un régimen simple.
Sigue cada punto hasta que finalmente llegues a una solución.
Habilitar errores PHP
Esto es clave para la mayoría de los problemas. Por razones de seguridad u otras, la configuración de PHP podría deshabilitar por defecto la visualización de errores de PHP.
Puede habilitar errores con una solución más permanente, o simplemente algo más temporal.
Solución permanente
Para usuarios de Apache / mod_php
En el .htaccessarchivo raíz de su documento , simplemente colóquelo en la parte superior.
php_flag display_startup_errors on
php_flag display_errors on
php_flag html_errors on
php_flag log_errors on
php_value error_log /home/path/public_html/var/log/system.log
Para usuarios de Nginx / FastCGI
En su configuración de virtualhost de Nginx, en la location .php {directiva final o en el fastcgi_paramsarchivo (si tiene uno especificado)
fastcgi_param PHP_VALUE display_startup_errors=on;
fastcgi_param PHP_VALUE display_errors=on;
fastcgi_param PHP_VALUE html_errors=on;
fastcgi_param PHP_VALUE log_errors=on;
fastcgi_param PHP_VALUE error_log=/home/path/public_html/var/log/system.log;
Solución temporal / universal
Para cualquier plataforma
Edite el bootstrap de Magento index.phpen la raíz de su documento y descomente la siguiente línea:
#ini_set('display_errors', 1);
Habilitar modo desarrollador
Cuando ha tenido un error y de repente ha llegado a la página "Informe de errores", y se le ha dado una cadena de error aparentemente inútil como 1184257287824: tiene algunas opciones.
Solución permanente
Para usuarios de Apache / mod_php
En el .htaccessarchivo raíz del documento , simplemente colóquelo en la parte superior.
SetEnv MAGE_IS_DEVELOPER_MODE true
Para usuarios de Nginx / fastcgi
En su configuración de virtualhost de Nginx, en la location .php {directiva final o en el fastcgi_paramsarchivo (si tiene uno especificado)
fastcgi_param MAGE_IS_DEVELOPER_MODE true;
Solución temporal / universal
Edite la rutina de arranque de Magento index.phpen la raíz de su documento y haga que la ifdeclaración sea siempre verdadera o habilitada para su IP específica.
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
Mage::setIsDeveloperMode(true);
}
o
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress') {
Mage::setIsDeveloperMode(true);
}
Comprueba tus permisos
Los permisos incorrectos causarán una gran cantidad de problemas, muchos de los cuales no son tan fáciles de encontrar a primera vista.
Por ejemplo.
Si PHP no puede escribir en el ./mediadirectorio y tiene la combinación JS habilitada, Magento no puede generar el archivo combinado y el URI único asociado para los medios. En cambio, lo que encontrará en el código fuente de su navegador es una ruta completa del servidor al archivo multimedia
/home/path/public_html/media/xxx
De lo contrario, puede parecer que el sitio funciona de manera normal, sin errores críticos realmente visibles.
Tenga en cuenta que esta práctica es segura para el alojamiento dedicado, pero puede presentar problemas de seguridad con el alojamiento compartido si el proceso de Apache no se cambia por usuario.
En nuestro ejemplo, el usuario SSH / FTP es sonassi, el usuario Apache es apachey el grupo esapache
Agregue el usuario FTP / SSH al grupo Apache
Lo que es más importante, debemos asegurarnos de que el usuario FTP / SSH sea parte del grupo Apache, en nuestro ejemplo, es apache(pero también es comúnmente www-data)
usermod -a -G apache sonassi
Siga agregando tantos usuarios al grupo como tenga para FTP / SSH.
Restablecer permisos originales
Entonces, antes de comenzar, asegurémonos de que todos los permisos sean correctos.
chown -R sonassi:apache /home/path/public_html/
find /home/path/public_html/ -type d -exec chmod 775 {} \;
find /home/path/public_html/ -type f -exec chmod 664 {} \;
Hacer los cambios permanentes
ACL y bits adhesivos
Las ACL en Linux nos permiten definir reglas específicas, en nuestro caso, qué archivos de permisos deben heredar en la creación. Una parte adhesiva (mencionada más adelante) se encarga de la herencia grupal, pero no ayuda con los permisos, razón por la cual usamos ACL.
Comience por habilitar el soporte de ACL en la partición activa, asegúrese de que su núcleo se compiló con soporte de ACL .
La partición puede ser /, /home, /varo alguna otra cosa, reemplace según sea apropiado.
mount -o remount,acl /home
Ahora que las ACL están habilitadas, podemos establecer las reglas de ACL y agrupar bits fijos:
setfacl -d -m u::rwx,g::rwx,o::rx /home/path/public_html/
chmod g+s /home/path/public_html/
Pero no tengo soporte para ACL
Si su Kernel no admite ACL, también puede usar umask(que es una configuración de tiempo de ejecución para BASH, FTP y PHP) para establecer los permisos de archivo predeterminados. Magento por lo general establece umask(0)en index.php, sin embargo, sería en su interés de cambiar esta situación.
En tu index.phpcambio, la umasklínea será
umask(022);
Y en su entorno BASH para SSH, configúrelo en su .bashrco.bash_profile
umask 022
Para su servidor FTP, necesitará leer la documentación, pero el principio es el mismo.
Revertir tema a predeterminado
Es posible que su tema o paquete sea responsable de este problema. Volver a un tema Magento de vainilla es una forma rápida de averiguarlo.
** Esto viene con la advertencia de que algunos módulos pueden depender de ciertas características del tema *
En lugar de cambiar cualquier cosa a través del panel de administración, es mucho más simple cambiar el nombre de los directorios ofensivos.
Vía SSH
mv ./app/design/frontend/myBrokenTheme{,.tmp}
mv ./skin/frontend/myBrokenTheme{,.tmp}
O a través de su cliente FTP, atraviese y cambie el nombre de su paquete a otra cosa. p.ej.myBrokenTheme.tmp
Si esto resuelve tu problema
Luego debe profundizar un poco más sobre qué parte de la plantilla es problemática. Así que restaure su paquete e intente lo siguiente, probando entre cada uno.
Esencialmente, el proceso consiste en habilitar gradualmente los directorios a medida que recorre el árbol de archivos, hasta que pueda encontrar el archivo ofensivo.
- Cambie el nombre del directorio de diseño a
.tmp
- Cambie el nombre del directorio de plantilla a
.tmp
Luego, si se soluciona, cambie el nombre de todos los archivos dentro del directorio de diseño a .tmp- (para los usuarios de SSH ls | xargs -I {} mv {} {}.tmpo rename 's/^/.tmp/' *)
Luego, habilite gradualmente cada archivo 1 por 1 hasta que se resuelva.
Si esto no resuelve tu problema
Existe el potencial de que sus base/defaulto enterprise/defaultdirectorios se han contaminado - y lo mejor es reemplazado por una versión limpia conocida.
Puede hacerlo descargando una compilación limpia de Magento y reemplazando sus directorios según sea necesario. A través de SSH puedes hacer esto:
cd /home/path/public_html/
mkdir clean_mage
cd clean_mage
MAGENTO_VERSION=1.7.0.0
wget -O magento.tgz http://www.magentocommerce.com/downloads/assets/$MAGENTO_VERSION/magento-$MAGENTO_VERSION.tar.gz
tar xvfz magento.tgz
cd /home/path/public_html/app/design/frontend
mv base{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/design/frontend/base .
cd /home/path/public_html/skin/frontend
mv base{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/skin/frontend/base .
También puede aprovechar la oportunidad para difflos dos directorios si desea verificar cualquier cambio.
diff -r base base.tmp
NÓTESE BIEN. Este método causará más errores durante el proceso, ya que la dependencia del módulo dicta la existencia de archivos específicos. Desafortunadamente, es normal para el curso.
Deshabilitar módulos locales
Por defecto, Magento define la ruta de inclusión de PHP para cargar clases en el siguiente orden
Local > Community > Core
Si un archivo está en Local, cárguelo y no haga más.
Si un archivo está en la comunidad, cárguelo y no haga más.
Si no se puede encontrar un archivo en otro lugar, cárguelo desde el núcleo.
Una vez más, en lugar de deshabilitar los módulos a través del panel de administración de Magento, es más práctico hacerlo a nivel de archivo.
Por lo general, para deshabilitar un módulo de la forma "adecuada", editaría el ./app/etc/modules/MyModule.xmlarchivo y el conjunto respectivos <active>false</active>; sin embargo, esto no impide que se cargue una clase.
Si otra clase extiende una clase dada en un módulo (ignorando cualquier declaración de dependencia de Magento), todavía se cargará, independientemente de si la extensión está deshabilitada o no.
De nuevo, el mejor medio para deshabilitar una extensión es cambiar el nombre del directorio.
Comience deshabilitando local
Simplemente cambie el nombre del directorio a través de FTP o use el siguiente comando SSH
mv ./app/code/local{,.tmp}
Luego deshabilitar comunidad
mv ./app/code/community{,.tmp}
Si el problema se resuelve desde cualquiera
Entonces es un caso de entender de qué módulo en particular se originó el error. Al igual que con el ejemplo dado anteriormente para el diagnóstico del paquete, se aplica el mismo proceso.
Así que restaure el directorio X e intente lo siguiente, probando entre cada uno.
Esencialmente, el proceso consiste en habilitar gradualmente directorios (módulos) uno por uno hasta que vuelva a ocurrir el error
- Cambie el nombre de todos los módulos en el directorio a
.tmp(para los usuarios SSH ls | xargs -I {} mv {} {}.tmpo rename 's/^/.tmp/' *)
- Habilite gradualmente cada módulo uno por uno, eliminando
.tmpdel nombre del archivo
Si el problema no se resuelve
Entonces es posible que el núcleo esté contaminado. El núcleo principal de Magento PHP consiste en
./app/code/core
./lib
De nuevo, cambie el nombre de estos directorios y copie en una variante limpia. Suponiendo que ya haya descargado una versión limpia de Magento como se indicó anteriormente, a través de SSH, puede hacer esto:
cd /home/path/public_html/app/code
mv core{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/code/core .
Luego, si el problema aún no se resuelve, reemplace el libdirectorio también
cd /home/path/public_html
mv lib{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/lib .
En este punto, su tienda Magento no será más que una instalación sencilla con una base de datos modificada.
En realidad, algunos modelos todavía se almacenan en la base de datos (por ejemplo, incremento de orden), por lo que en este punto, se convierte en un caso de hacer manualmente esas ediciones. Hasta ahora, todos los pasos anteriores han sido reversibles sin daños duraderos. Pero si también importáramos una base de datos limpia de Magento, podría resultar irreversible (salvo restaurar una copia de seguridad).
La guía anterior sirve para ayudarlo a identificar un error; no para arreglar el error resultante.
Contenido obtenido voluntariamente de www.sonassi.com/knowledge-base/magento-debug-process y www.sonassi.com/knowledge-base/stop-magento-permissions-errors-permanently
