Erro 500 ou "erro crítico" no seu website (também após uma atualização do WordPress)
Vê um ecrã em branco, 500 Internal Server Error ou, no WordPress, Ocorreu um erro crítico neste site? Então o código do seu website está a bloquear. Normalmente, o servidor em si continua a funcionar sem problemas. Com os passos abaixo, na maioria dos casos, consegue encontrar a causa por si próprio.
Primeiro: o que mudou recentemente?
Um erro 500 quase nunca surge do nada. Acabou de atualizar um plugin, um tema ou o WordPress, alterou a versão do PHP ou modificou algo no .htaccess? Então reverta primeiro exatamente essa alteração. Normalmente, essa é a solução mais rápida.
Consulte o registo de erros
O registo de erros indica qual o ficheiro e qual a linha que provoca o erro. Inicie sessão no DirectAdmin e abra System Info & Files › Site Summary / Statistics / Logs. Escolha o seu domínio e abra o registo de erros. As linhas mais abaixo são as mais recentes. Se aparecer, por exemplo, PHP Fatal error com um caminho para wp-content/plugins/naam-van-plugin, fica a saber qual o plugin responsável.
Não há nada útil no registo de erros? Ative temporariamente o registo do WordPress
O WordPress consegue escrever os seus próprios erros num ficheiro de registo. Abra o wp-config.php em public_html (faça primeiro uma cópia) e coloque estas linhas acima da linha /* That's all, stop editing! */. Se já existir uma linha com WP_DEBUG, altere essa linha em vez de a acrescentar novamente.
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
Volte a carregar a página com o erro. O WordPress escreve agora as mensagens em wp-content/debug.log, sem as mostrar aos seus visitantes. Este último ponto é importante: mensagens de erro no ecrã revelam caminhos e outros dados.
debug.log encontra-se numa pasta que o seu website disponibiliza a qualquer pessoa. Quem souber o endereço pode lê-lo. Por isso, volte a definir WP_DEBUG como false assim que tiver encontrado a causa e elimine o debug.log. Se pretender manter o registo durante mais tempo, indique em WP_DEBUG_LOG um caminho fora de public_html em vez de true, por exemplo '/home/gebruiker/domains/seudominio.pt/wp-debug.log'.WordPress: erro crítico após uma atualização
Após uma atualização de um plugin, de um tema ou do próprio WordPress, esta é de longe a causa mais frequente. Se já não conseguir aceder à administração do WordPress, proceda da seguinte forma:
- Verifique a sua caixa de correio. Em caso de erro crítico, o WordPress envia frequentemente um e-mail para o endereço do administrador com uma ligação para o modo de recuperação. Com essa ligação, inicia sessão enquanto o plugin ou tema com problemas está temporariamente desativado, podendo então desativá-lo ou repor a versão anterior.
- Não recebeu nenhum e-mail? Desative os plugins através do DirectAdmin. Abra o File Manager e aceda a
domains/seudominio.pt/public_html/wp-content. Mude o nome da pastapluginspara, por exemplo,plugins-uit. O WordPress desativa então todos os plugins. - O seu site voltou a funcionar? Reponha o nome da pasta para
pluginse, no WordPress, volte a ativar os plugins um a um, até o erro reaparecer. Assim fica a saber qual é. Se já o souber pelo registo de erros, mude apenas o nome da pasta desse plugin. - O problema está no tema? Nesse caso, em
wp-content/themes, mude o nome da pasta do seu tema ativo. O WordPress recorre então a um tema predefinido, se ainda estiver instalado. - Alterou recentemente a versão do PHP? Reponha-a em Select PHP version. Consulte Alterar a versão e as definições do PHP.
Regressar a uma versão funcional
Não consegue resolver o problema e o site ainda funcionava ontem? Então reponha uma cópia de segurança.
- WebOké Backups: em O meu WebOké, escolha um momento anterior ao erro e reponha apenas a pasta do seu website e, se necessário, a base de dados. Consulte WebOké Backups: consultar, repor ou transferir uma cópia de segurança.
- Installatron: se o Installatron criou uma cópia de segurança antes da atualização, reponha-a em My Backups. Consulte Criar e repor cópias de segurança no Installatron.
Verifique o seu .htaccess
Uma única linha incorreta no .htaccess provoca imediatamente um erro 500 em todo o site. Um exemplo conhecido é uma linha deixada por um plugin de segurança, como php_value auto_prepend_file com um caminho para um ficheiro que já não existe.
- No DirectAdmin, abra System Info & Files › File Manager.
- Aceda a
domains/seudominio.pt/public_html. Não vê nenhum .htaccess? Os ficheiros cujo nome começa por um ponto estão ocultos. Ative a apresentação de ficheiros ocultos no File Manager. - Mude o nome de
.htaccesspara, por exemplo,.htaccess-oud. - Volte a carregar o seu website. Se o erro desaparecer, o problema está no .htaccess. Remova a linha incorreta e reponha o nome original do ficheiro.
Outras causas
- Memória insuficiente: se o registo de erros indicar
Allowed memory size ... exhausted, aumente omemory_limitem Select PHP version. - Permissões de ficheiros incorretas: as pastas devem ter 755 e os ficheiros 644. Nunca defina nada como 777: isso não resolve nada e torna o seu site vulnerável.
- Armazenamento cheio: se o seu pacote estiver cheio, o seu website deixa de conseguir gravar dados. Verifique em Disk Usage no painel do DirectAdmin.
Com a Saúde do domínio, vê de uma só vez se o seu domínio, o website e o certificado SSL estão em ordem.
Consulte também no manual do DirectAdmin: Mostrar e editar ficheiros ocultos como o .htaccess e Resumo do site e registos: o registo de erros e o registo de acessos.
Explicação detalhada com capturas de ecrã: O meu website está em branco ou apresenta um erro 500 no manual do DirectAdmin.
Quer aprender mais? Siga o curso gratuito de WordPress, lição 5.4 Menos é mais: limpar e resolver conflitos ou lição 7.2 Manter as atualizações em dia.