Il debug è un po 'un'arte, ma qualcosa che può essere facilmente padroneggiato seguendo un semplice regime.
Segui ogni punto fino a raggiungere finalmente una soluzione.
Abilita errori PHP
Questa è la chiave per la maggior parte dei problemi. Per motivi di sicurezza o altri motivi, la visualizzazione dell'errore PHP potrebbe essere disabilitata per impostazione predefinita dalla configurazione di PHP.
È possibile abilitare gli errori con una soluzione più permanente o semplicemente qualcosa di più temporaneo.
Soluzione permanente
Per utenti Apache / mod_php
Nel .htaccessfile radice del documento: rilascialo in alto.
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
Per utenti Nginx / FastCGI
Nella configurazione del tuo host virtuale Nginx, nella location .php {direttiva finale o nel fastcgi_paramsfile (se ne hai specificato uno)
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;
Soluzione temporanea / universale
Per qualsiasi piattaforma
Modifica il bootstrap Magento index.phpnella radice del documento e decommenta la seguente riga:
#ini_set('display_errors', 1);
Abilita modalità sviluppatore
Quando hai avuto un errore e hai colpito improvvisamente la pagina "Rapporto errori" e ti è stata data una stringa di errore apparentemente inutile come 1184257287824- hai alcune opzioni.
Soluzione permanente
Per utenti Apache / mod_php
Nel .htaccessfile radice del documento: rilascialo in alto.
SetEnv MAGE_IS_DEVELOPER_MODE true
Per utenti Nginx / fastcgi
Nella configurazione del tuo host virtuale Nginx, nella location .php {direttiva finale o nel fastcgi_paramsfile (se ne hai specificato uno)
fastcgi_param MAGE_IS_DEVELOPER_MODE true;
Soluzione temporanea / universale
Modifica il bootstrap Magento index.phpnella radice del documento e rendi l' ifistruzione sempre vera o abilitata per il tuo IP specifico.
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);
}
Controlla le tue autorizzazioni
Autorizzazioni errate causeranno numerosi problemi, molti dei quali non sono così facili da trovare a prima vista.
Per esempio.
Se PHP non è in grado di scrivere nella ./mediadirectory e hai attivato la combinazione JS, Magento non è in grado di generare il file combinato e l'URI univoco associato per il supporto. Quindi, invece, quello che troverai nel codice sorgente del tuo browser è un percorso completo del server per il file multimediale
/home/path/public_html/media/xxx
Altrimenti, il sito può sembrare funzionare normalmente, senza errori critici effettivamente visibili.
Tieni presente che questa pratica è sicura per l'hosting dedicato, ma può presentare problemi di sicurezza con l'hosting condiviso se il processo Apache non è sottoposto a chroot per utente.
Nel nostro esempio, l'utente SSH / FTP è sonassi, l'utente Apache è apachee il gruppo lo èapache
Aggiungi l'utente FTP / SSH al gruppo Apache
Ancora più importante, dobbiamo assicurarci che l'utente FTP / SSH faccia parte del gruppo Apache, nel nostro esempio, è apache(ma è anche comunemente www-data)
usermod -a -G apache sonassi
Continua ad aggiungere al gruppo tutti gli utenti che hai per FTP / SSH.
Ripristina permessi originali
Quindi, prima di iniziare, assicuriamoci che tutte le autorizzazioni siano corrette.
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 {} \;
Rendere permanenti le modifiche
ACL e bit appiccicosi
Gli ACL in Linux ci consentono di definire regole specifiche, nel nostro caso, quali file di autorizzazioni dovrebbero ereditare al momento della creazione. Un po 'appiccicoso (menzionato più avanti) si occupa dell'ereditarietà di gruppo, ma non aiuta con le autorizzazioni, motivo per cui utilizziamo gli ACL.
Inizia abilitando il supporto ACL sulla partizione attiva, assicurati che il tuo kernel sia stato compilato con il supporto ACL .
La partizione può essere /, /home, /varo qualcosa d'altro, sostituire a seconda dei casi.
mount -o remount,acl /home
Ora gli ACL sono abilitati, possiamo impostare le regole ACL e raggruppare i bit sticky:
setfacl -d -m u::rwx,g::rwx,o::rx /home/path/public_html/
chmod g+s /home/path/public_html/
Ma non ho il supporto ACL
Se il tuo kernel non supporta gli ACL puoi anche usare umask(che è un'impostazione di runtime per BASH, FTP e PHP) per impostare le autorizzazioni di file predefinite. Magento di solito mette umask(0)in index.php, tuttavia, sarebbe nel vostro interesse a cambiare questo.
Nel tuo index.phpcambio la umasklinea sarà
umask(022);
E nel tuo ambiente BASH per SSH, imposta questo in tuo .bashrco.bash_profile
umask 022
Per il tuo server FTP, dovrai leggere la documentazione, ma il principio è lo stesso.
Ripristina tema predefinito
È possibile che il tema o il pacchetto siano responsabili di questo problema. Tornare a un tema Magento alla vaniglia è un modo rapido per scoprirlo.
** Questo viene fornito con l'avvertenza che alcuni moduli potrebbero dipendere da alcune funzionalità del tema *
Invece di modificare qualsiasi cosa tramite il pannello di amministrazione, è molto più semplice rinominare semplicemente le directory offensive.
Tramite SSH
mv ./app/design/frontend/myBrokenTheme{,.tmp}
mv ./skin/frontend/myBrokenTheme{,.tmp}
O tramite il tuo client FTP, attraversa e rinomina il tuo pacchetto con qualcos'altro. per esempio.myBrokenTheme.tmp
Se questo risolve il problema
Quindi è necessario scavare un po 'più a fondo su quale parte del modello è problematica. Quindi ripristinare il pacchetto e provare quanto segue, testando tra ciascuno.
In sostanza, il processo consiste nell'abilitare gradualmente le directory mentre attraversi l'albero dei file, fino a quando non trovi il file offensivo.
- Rinominare la directory di layout in
.tmp
- Rinominare la directory del modello in
.tmp
Quindi, se si ottiene una correzione, rinominare tutti i file nella directory di layout in .tmp- (per gli utenti SSH ls | xargs -I {} mv {} {}.tmpo rename 's/^/.tmp/' *)
Quindi abilitare gradualmente ogni file 1 per 1 fino alla risoluzione.
Se ciò non risolve il problema
Esiste la possibilità che i vostri base/defaulto enterprise/defaultle directory sono diventati contaminati - e sono meglio sostituito con una versione pulita noto.
Puoi farlo scaricando una build pulita di Magento e sostituendo le tue directory se necessario. Tramite SSH puoi fare questo:
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 .
È inoltre possibile cogliere l'opportunità per diffle due directory se si desidera verificare eventuali modifiche.
diff -r base base.tmp
NB. Questo metodo causerà più errori durante il processo, poiché la dipendenza del modulo determina l'esistenza di file specifici. Sfortunatamente, è la norma per il corso.
Disabilita i moduli locali
Per impostazione predefinita, Magento definisce il percorso di inclusione PHP per caricare le classi nel seguente ordine
Local > Community > Core
Se un file è in Local, caricalo e non fare altro.
Se un file è nella comunità, caricalo e non fare altro.
Se un file non può essere trovato da nessun'altra parte, caricalo dal core.
Ancora una volta, piuttosto che disabilitare i moduli tramite il pannello di amministrazione di Magento, è più pratico farlo a livello di file.
In genere, per disabilitare un modulo nel modo "corretto", è necessario modificare il rispettivo ./app/etc/modules/MyModule.xmlfile e impostarlo <active>false</active>, tuttavia ciò non impedisce il caricamento di una classe.
Se un'altra classe estende una determinata classe in un modulo (ignorando qualsiasi dichiarazione di dipendenza Magento), verrà comunque caricata, indipendentemente dal fatto che l'estensione sia disabilitata o meno.
Quindi, il modo migliore per disabilitare un'estensione è rinominare la directory.
Inizia disabilitando locale
Rinomina la directory tramite FTP o usa il seguente comando SSH
mv ./app/code/local{,.tmp}
Quindi disabilitare la community
mv ./app/code/community{,.tmp}
Se il problema è risolto da entrambi
Quindi si tratta di capire da quale modulo, in particolare, deriva l'errore. Come nell'esempio sopra riportato per la diagnosi del pacchetto, si applica lo stesso processo.
Quindi ripristina la directory X e prova quanto segue, testando tra di loro.
In sostanza, il processo consiste nell'abilitare gradualmente le directory (moduli) una alla volta fino a quando non si ripresenta l'errore
- Rinominare tutti i moduli nella directory in
.tmp(per gli utenti SSH ls | xargs -I {} mv {} {}.tmpo rename 's/^/.tmp/' *)
- Abilitare gradualmente ogni modulo uno per uno, rimuovendolo
.tmpdal nome del file
Se il problema non viene risolto
Quindi è possibile che il nucleo stesso sia contaminato. Il nucleo principale di Magento PHP è costituito da
./app/code/core
./lib
Quindi, rinominare queste directory e copiarle in una variante pulita. Supponendo che tu abbia già scaricato una versione pulita di Magento come sopra, tramite SSH, puoi farlo:
cd /home/path/public_html/app/code
mv core{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/code/core .
Quindi se il problema persiste, sostituire anche la libdirectory
cd /home/path/public_html
mv lib{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/lib .
A questo punto, il tuo negozio Magento non sarà altro che un'installazione vanilla con un database modificato.
Alcuni modelli sono effettivamente ancora archiviati nel database (ad es. Incremento dell'ordine), quindi a questo punto diventa un caso di apportare manualmente tali modifiche. Finora, tutti i passaggi precedenti sono stati reversibili senza danni permanenti. Ma se importassimo anche un database Magento pulito, potrebbe rivelarsi irreversibile (a meno di ripristinare un backup).
La guida sopra ti aiuta a identificare un errore; non correggere l'errore risultante.
Contenuti generosamente forniti da www.sonassi.com/knowledge-base/magento-debug-process e www.sonassi.com/knowledge-base/stop-magento-permissions-errors-permanently
