A depuração é um pouco de arte, mas algo que pode ser facilmente dominado seguindo um regime simples.
Siga cada ponto até chegar finalmente a uma solução.
Habilitar erros de PHP
Essa é a chave para a maioria dos problemas. Por segurança ou outros motivos, a exibição de erros do PHP provavelmente pode ser desativada por padrão na sua configuração do PHP.
Você pode ativar erros com uma solução mais permanente ou apenas algo mais temporário.
Solução permanente
Para usuários do Apache / mod_php
No .htaccessarquivo raiz do documento - basta soltá-lo no topo.
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 usuários do Nginx / FastCGI
Na configuração do seu host virtual Nginx, na location .php {diretiva final ou no fastcgi_paramsarquivo (se você tiver um 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;
Solução temporária / universal
Para qualquer plataforma
Edite a inicialização do Magento index.phpna raiz do documento e remova o comentário da seguinte linha:
#ini_set('display_errors', 1);
Ativar modo de desenvolvedor
Quando você teve um erro e, de repente, acessou a página "Relatório de erros" e recebeu uma sequência de erros aparentemente inútil como 1184257287824- você tem algumas opções.
Solução permanente
Para usuários do Apache / mod_php
No .htaccessarquivo raiz do documento - basta soltá-lo no topo.
SetEnv MAGE_IS_DEVELOPER_MODE true
Para usuários do Nginx / fastcgi
Na configuração do seu host virtual Nginx, na location .php {diretiva final ou no fastcgi_paramsarquivo (se você tiver um especificado)
fastcgi_param MAGE_IS_DEVELOPER_MODE true;
Solução temporária / universal
Edite a inicialização do Magento index.phpna raiz do documento e torne a ifdeclaração sempre verdadeira ou ativada para o seu IP específico.
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
Mage::setIsDeveloperMode(true);
}
ou
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress') {
Mage::setIsDeveloperMode(true);
}
Verifique suas permissões
Permissões incorretas causarão muitos problemas, muitos dos quais não são fáceis de encontrar à primeira vista.
Por exemplo.
Se o PHP não puder gravar no ./mediadiretório e você tiver a combinação de JS ativada - o Magento não poderá gerar o arquivo combinado e o URI exclusivo associado para a mídia. Então, o que você encontrará no código-fonte do navegador é um caminho completo do servidor para o arquivo de mídia
/home/path/public_html/media/xxx
Caso contrário, o site pode parecer estar funcionando normalmente - sem erros críticos realmente visíveis.
Lembre-se de que esta prática é segura para hospedagem dedicada, mas pode apresentar problemas de segurança com hospedagem compartilhada se o processo do Apache não for chrootado por usuário.
Em nosso exemplo, o usuário SSH / FTP é sonassi, o usuário Apache é apachee o grupo éapache
Adicione o usuário FTP / SSH ao grupo Apache
Mais importante, precisamos garantir que o usuário FTP / SSH faça parte do grupo Apache, em nosso exemplo, seu apache(mas também é comum www-data)
usermod -a -G apache sonassi
Continue adicionando ao grupo quantos usuários você tiver para FTP / SSH.
Redefinir permissões originais
Portanto, antes de começarmos, vamos garantir que todas as permissões estejam corretas.
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 {} \;
Tornando as alterações permanentes
ACLs e bits fixos
As ACLs no Linux nos permitem definir regras específicas, no nosso caso, quais arquivos de permissões devem herdar na criação. Um pedaço fixo (mencionado posteriormente) cuida da herança do grupo, mas não ajuda nas permissões, e é por isso que usamos ACLs.
Comece ativando o suporte a ACL na partição ativa; verifique se o seu Kernel foi compilado com o suporte a ACL .
Sua partição pode ser /, /home, /varou qualquer outra coisa, substitua conforme apropriado.
mount -o remount,acl /home
Agora as ACLs estão ativadas, podemos definir as regras da ACL e agrupar os bits permanentes:
setfacl -d -m u::rwx,g::rwx,o::rx /home/path/public_html/
chmod g+s /home/path/public_html/
Mas eu não tenho suporte a ACL
Se o seu Kernel não suporta ACLs, você também pode usar umask(que é uma configuração de tempo de execução para BASH, FTP e PHP) para definir as permissões de arquivo padrão. Magento geralmente define umask(0)em index.php, no entanto, seria do seu interesse para mudar isso.
Na sua index.phpmudança, a umasklinha a ser
umask(022);
E no seu ambiente BASH para SSH, defina isso em seu .bashrcou.bash_profile
umask 022
Para o seu servidor FTP, você precisará ler a documentação, mas o princípio é o mesmo.
Reverter tema para o padrão
É possível que seu tema ou pacote seja responsável por esse problema. Voltar ao tema Magento é uma maneira rápida de descobrir.
** Isso vem com a ressalva de que alguns módulos podem depender de certos recursos do tema *
Em vez de alterar qualquer coisa pelo painel de administração, é muito mais simples simplesmente renomear os diretórios incorretos.
Via SSH
mv ./app/design/frontend/myBrokenTheme{,.tmp}
mv ./skin/frontend/myBrokenTheme{,.tmp}
Ou através do seu cliente FTP, percorra e renomeie seu pacote para outra coisa. por exemplo.myBrokenTheme.tmp
Se isso resolver seu problema
Então você precisa se aprofundar um pouco sobre qual parte do modelo é problemática. Portanto, restaure seu pacote e tente o seguinte, testando entre cada um.
Essencialmente, o processo é habilitar gradualmente os diretórios à medida que você percorre a árvore de arquivos - até encontrar o arquivo incorreto.
- Renomeie o diretório de layout para
.tmp
- Renomeie o diretório do modelo para
.tmp
Em seguida, se uma correção resultar, renomeie todos os arquivos no diretório de layout para .tmp- (para os usuários SSH ls | xargs -I {} mv {} {}.tmpou rename 's/^/.tmp/' *)
Em seguida, ative gradualmente cada arquivo 1 por 1 até resolver.
Se isso não resolver seu problema
É possível que seus diretórios base/defaultou enterprise/defaulttenham sido contaminados - e melhor substituídos por uma versão limpa conhecida.
Você pode fazer isso baixando uma versão limpa do Magento e substituindo seus diretórios conforme necessário. Via SSH, você pode fazer isso:
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 .
Você também pode aproveitar diffos dois diretórios se quiser verificar as alterações.
diff -r base base.tmp
NB Este método causará mais erros durante o processo, pois a dependência do módulo determina a existência de arquivos específicos. Infelizmente, é o par para o curso.
Desativar módulos locais
Por padrão, o Magento define o caminho de inclusão do PHP para carregar classes na seguinte ordem
Local > Community > Core
Se um arquivo estiver em Local - carregue-o e não faça mais.
Se um arquivo estiver em comunidade - carregue-o e não faça mais.
Se um arquivo não puder ser encontrado em nenhum outro lugar - carregue-o do núcleo.
Novamente, em vez de desativar os módulos pelo painel de administração do Magento, é mais prático fazer isso no nível do arquivo.
Normalmente, para desativar um módulo da maneira "adequada", você deve editar o respectivo ./app/etc/modules/MyModule.xmlarquivo e definir <active>false</active>- no entanto, isso não impede que uma classe seja carregada.
Se outra classe estender uma determinada classe em um módulo (ignorando quaisquer declarações de dependência do Magento), ela ainda será carregada - independentemente de a extensão estar desabilitada ou não.
Então, novamente, o melhor meio de desativar uma extensão é renomear o diretório.
Comece desativando o local
Apenas renomeie o diretório via FTP ou use o seguinte comando SSH
mv ./app/code/local{,.tmp}
Desative a comunidade
mv ./app/code/community{,.tmp}
Se o problema for resolvido a partir de
Então, é um caso de entender de qual módulo em particular o erro ocorreu. Como no exemplo dado acima para o diagnóstico da embalagem, o mesmo processo se aplica.
Portanto, restaure o diretório X e tente o seguinte, testando entre cada um.
Essencialmente, o processo é ativar gradualmente os diretórios (módulos) um por um até que o erro ocorra novamente
- Renomeie todos os módulos no diretório para
.tmp(para os usuários SSH ls | xargs -I {} mv {} {}.tmpou rename 's/^/.tmp/' *)
- Habilite gradualmente cada módulo, um por um, removendo
.tmpdo nome do arquivo
Se o problema não for resolvido
Então é possível que o próprio núcleo esteja contaminado. O principal núcleo PHP do Magento consiste em
./app/code/core
./lib
Então, novamente, renomeie esses diretórios e copie em uma variante limpa. Supondo que você já baixou uma versão limpa do Magento como acima, via SSH, você pode fazer isso:
cd /home/path/public_html/app/code
mv core{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/app/code/core .
Se o problema ainda não tiver sido resolvido, substitua o libdiretório também
cd /home/path/public_html
mv lib{,.tmp}
cp -par /home/path/public_html/clean_mage/magento/lib .
Neste ponto, sua loja Magento não passará de uma instalação de baunilha com um banco de dados modificado.
Na verdade, alguns modelos ainda estão armazenados no banco de dados (por exemplo, incremento do pedido) - portanto, neste ponto, torna-se um caso de fazer essas edições manualmente. Até agora, todas as etapas acima foram reversíveis, sem danos duradouros. Mas se estivéssemos importando também um banco de dados Magento limpo - isso pode ser irreversível (exceto para restaurar um backup).
O guia acima serve para ajudá-lo a identificar um erro; não para corrigir o erro resultante.
Conteúdo fornecido voluntariamente em www.sonassi.com/knowledge-base/magento-debug-process e www.sonassi.com/knowledge-base/stop-magento-permissions-errors-permanently
