A tela branca da morte do WordPress: um guia para a recuperação
Publicados: 2023-01-10O WordPress, como o MacOS e até o Windows agora, tem uma infame “tela branca da morte” ou “WSOD” para abreviar. O WSOD aparece quando algo dá muito errado. Você está enfrentando uma tela em branco ou quase branca por motivos desconhecidos. O que agora?
O que é a tela branca da morte do WordPress (WSOD)?
É improvável que você encontre a “tela branca da morte” (WSOD) em um site WordPress em condições normais. É simplesmente uma tela branca em branco que aparece em vez da interface pública de front-end ou back-end de um site WordPress. Isso significa que o WordPress travou e não será carregado corretamente.
Porque? O que deu errado?
Desde que o WordPress 5.2 foi lançado em maio de 2019, o WordPress possui um modo de recuperação para protegê-lo do WSOD. Sem o modo de recuperação, os problemas de compatibilidade gerariam muitos WSODs e usuários frustrados do WordPress. Se o seu servidor estiver usando uma versão do PHP ou MySQL que não seja suportada por um plug-in, tema ou extensão que você está instalando, em vez de interromper seu site, você obterá o Modo de Recuperação. Hoje, um erro PHP Out-of-Memory (OOM) é provavelmente o cenário remanescente mais comum que contornará a proteção WSOD, deixando você com uma tela totalmente em branco.
Eu verifiquei com o contribuidor principal do WordPress, Marius Jensen, para descobrir o que mais poderia causar um verdadeiro WSOD hoje em dia. Marius é o autor do plug-in Site Health (agora Health Check and Troubleshooting), cujo conceito e recursos acabaram entrando no núcleo do WordPress. (Foi assim que obtivemos o Modo de Recuperação e outras proteções.) Marius confirmou que a única maneira de fazer o WordPress travar com uma tela totalmente em branco é interromper o fluxo de execução do PHP para que o manipulador de erros fatais não funcione como deveria. Quebrar a conexão entre o PHP e seu servidor HTTP conseguirá isso. Você não receberá nenhum feedback de solução de problemas na tela. Isso seria frustrante, mas se você estiver simplesmente trabalhando dentro do WordPress, instalando e configurando plugins, é improvável que isso aconteça.
A tela branca da morte significa que o WordPress foi hackeado?
Não, um WSOD não significa que os bandidos pegaram você. No entanto, em casos raros, pode ser um efeito colateral de uma violação de segurança. Se você acha que hackers comprometeram seu site, acesse o guia de Kathy Zant, Como limpar um site WordPress invadido.
Um erro de codificação PHP, um conflito entre dois ou mais plug-ins ou um problema no ambiente do servidor são as causas mais prováveis de um WSOD. Felizmente, não são catástrofes! Seu site e seu conteúdo não foram perdidos. Se desejar, você mesmo pode corrigir um WSOD.
Neste artigo, veremos a lista de possíveis diagnósticos e curas para o WSOD. Você aprenderá como dar vida ao seu site WordPress. Você também aprenderá como o WordPress funciona em um nível mais profundo.
Visualizar visualização
A tela branca da morte do WordPress: eu fiz isso?
Sim. A Tela Branca da Morte é provavelmente o resultado de algo VOCÊ fez no seu site WordPress.
A causa de um WSOD geralmente é encontrada em um plug-in do WordPress que você acabou de instalar e ativar. Ou pode ser o resultado de uma atualização recente. Um plug-in adicionado ou atualizado recentemente pode estar em conflito com outro plug-in. Nesse cenário, um plug-in está tentando fazer a mesma coisa que outro ou está agindo com propósitos contraditórios.
Se um plug-in, tema ou trechos de código PHP com defeito estiverem causando um erro fatal, você poderá obter um WSOD. Eles podem conter um erro de sintaxe, um bug ou código que não é compatível com a versão do PHP que você está usando. Se você ou seu host acabou de atualizar sua versão do PHP - o que é bom! — plug-ins incompatíveis começarão a gerar erros e podem derrubar seu site com um WSOD. Se você estiver usando o WordPress 5.2 ou superior como deveria, os problemas de incompatibilidade ativarão o Modo de recuperação, que é muito mais útil do que um WSOD verdadeiro.
Normalmente, o culpado é o que acabou de ser alterado com um plug-in, tema ou código personalizado.
Uma vez que o WSOD geralmente é uma resposta ao que foi alterado por último (ou muito recentemente) que afeta a funcionalidade do seu site. Revise todas as alterações recentes. Concentre-se nas mudanças que parecem mais prováveis de causar um problema. Se você acabou de instalar um novo plug-in ou modificou algum código de tema, esses são os primeiros lugares a procurar para ver o que pode ter dado errado.
Quando o WordPress está praticamente morto
Todos os WSODs não são iguais e alguns nem mesmo são verdadeiros WSODs.
Você pode receber algum tipo de mensagem de erro em vez de uma tela completamente branca. Pode ser uma mensagem de erro do servidor sobre um erro HTTP 500 ou uma conexão de banco de dados perdida. Pode ser uma mensagem de erro crítica do WordPress. Ou, seu site pode carregar normalmente para os visitantes, mas quando você tenta fazer login, obtém a tela branca da morte. O oposto pode ser verdadeiro em outros casos: você pode fazer login no painel do WordPress, mas o front-end público do seu site está dando a todos uma tela em branco.
Se a sua experiência WSOD se encaixa em qualquer uma dessas descrições, boas notícias! Seu site está praticamente morto. Não será difícil revivê-lo.
Se você se deparar com uma tela branca completamente em branco ao visitar seu site WordPress ou tentar fazer login, esse é o verdadeiro WSOD. Você terá que cavar um pouco mais fundo para determinar o que está causando isso.
Modo de recuperação do WordPress e a tela branca da morte
Felizmente para qualquer pessoa que enfrenta um WSOD, o Recovery Mode foi introduzido no WordPress 5.2 para eliminá-lo. O Recovery Mode detecta muitos erros fatais e ajuda a corrigi-los. Se você não estiver usando a versão principal mais recente do núcleo do WordPress, comece por aí. Atualize-se!
Graças ao modo de recuperação do WordPress, é raro ver uma tela branca completamente em branco quando algo dá errado. Você verá com mais frequência uma janela branca sobre uma tela cinza com a seguinte mensagem a partir do WordPress 6.1:
Versões mais antigas do WordPress mostrarão mensagens com palavras semelhantes, como “O site está passando por dificuldades técnicas”.
Se você navegar para um URL de back-end /wp-admin
, também haverá um aviso solicitando que você verifique sua conta de e-mail de administrador para obter mais informações:
Em outros casos, você pode ver uma tela branca com texto em negrito descrevendo um “Erro interno do servidor” com algum tipo de explicação e orientação para reparar seu site.
Bem-vindo à Recuperação
Este é o modo de recuperação. O WordPress está tentando ajudá-lo a se recuperar.
A primeira coisa a fazer é verificar o endereço de e-mail associado à sua conta de administrador do WordPress. O WordPress tenta identificar erros fatais de PHP em todo o código que está executando.
Se possível, o WordPress irá “pausar” um plugin ou outro código que esteja com defeito. O WordPress impedirá que o código ruim seja executado. Em seguida, ele relatará os detalhes aos administradores por e-mail.
No e-mail do Modo de Recuperação, você encontrará instruções e um link temporário para fazer login no WordPress em Modo de Recuperação. (Este link é válido por 24 horas. Depois disso, um novo será enviado se o site ainda apresentar um erro crítico.)
DICA PRO: Se você não receber o e-mail do modo de recuperação, poderá fazer login no WordPress no modo de recuperação de qualquer maneira adicionando o seguinte endereço ao URL do site base quando estiver conectado como administrador: /wp-login.php?action=entered_recovery_mode
.
Aqui está sua oportunidade de investigar mais. Se o Recovery Mode identificou um plug-in específico como a causa do seu WSOD, desative-o. Isso trará seu site de volta para todos. Então você pode investigar quaisquer problemas conhecidos para este plugin. Verifique se há uma atualização para ele. Entre em contato com as pessoas responsáveis por mantê-lo.
Nem toda tela branca da morte é igual no WordPress
Em alguns casos excepcionais, algo deu errado em outro lugar no WordPress ou no ambiente do seu servidor. Um processo de atualização ou instalação pode ter parado, deixando seu site preso no modo de manutenção. Você, seu provedor de hospedagem ou um plug-in instalado podem ter modificado os arquivos php.ini
ou .htaccess
com resultados inesperados. Seu ambiente existente pode não suportar os requisitos de um plug-in recém-instalado.
O modo de recuperação do WordPress não é capaz de lidar com essas situações, mas produzirá mensagens de erro visíveis em uma tela branca. O front-end do seu site pode estar inacessível, mas a tela de login do administrador e a interface do back-end podem estar funcionando normalmente.
Essas não são situações WSOD verdadeiras, mas são igualmente irritantes. Geralmente, uma das seguintes condições os causa:
1. Você está preso no modo de manutenção
Ao atualizar o núcleo, plug-ins ou temas do WordPress, o WordPress entra no “Modo de manutenção”. Navegar para qualquer parte do site mostrará uma tela cinza com uma janela de mensagem branca que diz:
Às vezes, isso não desaparece em um minuto, mas a hospedagem WordPress gerenciada de qualidade notará e corrigirá isso com um processo automatizado. Se você esperou alguns minutos sem alterações, pode sair do modo de manutenção excluindo o arquivo .maintenance
na pasta raiz do aplicativo/web onde o WordPress está instalado. (Para vê-lo, pode ser necessário habilitar a exibição de arquivos “invisíveis” liderados por um ponto no nome do arquivo.)
Quando não houver nenhum arquivo .maintenance
presente, seu site será carregado conforme o esperado.
2. Você atingiu um limite de upload de arquivo ou tamanho de postagem
Seu site pode atingir o tempo limite para uma tela branca em um processo de upload, pós-publicação ou envio de formulário porque você está enviando muitos dados.
Solução: Aumente o limite de conteúdo da postagem em wp-config.php
:
ini_set('pcre.recursion_limit',20000000); ini_set('pcre.backtrack_limit',10000000);
Solução: Aumente o limite de upload de arquivo e tamanho de postagem em php.ini
:
upload_max_filesize = 256M post_max_size = 256M
Estender o tempo (em segundos) antes que uma postagem ou qualquer envio de formulário expire também pode ajudar. Também é possível aumentar o tempo que o PHP tem para executar scripts e analisar a entrada. Além disso, podemos aumentar o número de variáveis permitidas em um envio de formulário. Por fim, podemos especificar o limite de tempo após o qual o PHP tratará os dados enviados como lixo:
max_execution_time = 300 max_input_time = 300 max_input_vars = 1000 sessão.gc_maxlifetime = 1000
Ou em .htaccess
, httpd.conf
ou virtualhost
:
php_value upload_max_filesize 256M php_value post_max_size 256M php_value max_execution_time 300 php_value max_input_time 300 php_value max_input_vars 1000 php_value sessão.gc_maxlifetime 1000
Ou em um trecho de código personalizado para WordPress ou um arquivo de tema functions.php
:
@ini_set( 'upload_max_filesize', '256M' ); @ini_set( 'post_max_size', '256M' ); @ini_set( 'max_execution_time', '300' ); @ini_set('max_input_time', '300' ); @ini_set('max_input_vars', '1000'); @ini_set('session.gc_maxlifetime', '1000' );
Os valores de memória e tempo nesses parâmetros são apenas recomendações. Para garantir que eles estejam funcionando e verificar seus valores atuais, use a ferramenta Site Health na interface de administração do WordPress.
Junto com o Recovery Mode, o WordPress 5.2 introduziu a ferramenta Site Health. É muito útil para diagnosticar problemas e obter informações técnicas sobre as configurações do seu site e o ambiente do servidor. Encontre-o no menu do administrador em Ferramentas > Integridade do site. Você também pode se beneficiar dos recursos estendidos no plug-in Health Check and Troubleshooting para WordPress.
3. O PHP está sem memória
PHP é a linguagem de script do lado do servidor na qual o núcleo do WordPress é baseado. Um WSOD aparece se não houver memória suficiente para o PHP executar o WordPress e seus plugins ativos. Você pode ver isso indicado em uma mensagem de erro ou log.
Dependendo do seu plano de hospedagem, você pode aumentar o limite de memória do PHP para todos os aplicativos em seu servidor ou uma instância específica do WordPress. Peça ajuda à equipe de suporte técnico do seu host se não tiver certeza do que fazer.
wp-config.php
Normalmente, adicionar a seguinte configuração ao seu arquivo wp-config.php
em sua pasta WordPress irá definir o limite de memória front-end para WordPress para 256 MB neste exemplo:
define('WP_MEMORY_LIMIT', '256M');
128 a 256 MB devem ser mais do que adequados. Você também pode definir a memória máxima ou de back-end alocada para PHP (256 MB no próximo exemplo também) adicionando a seguinte linha a wp-config.php
também:
define('WP_MAX_MEMORY_LIMIT', '256M');
O segundo número é o limite máximo de memória definindo a memória total que o PHP tem disponível para si. O primeiro número é a memória para o WordPress rodando dentro desse limite maior de PHP. O limite máximo de memória do PHP deve ser igual ou superior ao limite de memória do aplicativo WordPress.
php.ini
Outra forma de definir o limite máximo de memória do PHP é com uma configuração em um arquivo php.ini
localizado na sua pasta do WordPress:
memory_limit = 256M
Certifique-se de que não há ponto e vírgula no início da linha! E observe que o php.ini
afetará apenas a instância do WordPress (ou qualquer outro aplicativo PHP) em execução na pasta ou sob a pasta em que o arquivo php.ini
está localizado. Se você tiver acesso ao seu servidor ou raiz da web, um arquivo php.ini
localizado lá controlará as configurações ambientais para todos os aplicativos PHP, a menos que eles tenham seu próprio arquivo php.ini
que especifique condições diferentes.
.htaccess
Uma terceira maneira de definir o limite de memória do PHP é através do arquivo .htaccess
em sua pasta WordPress se você estiver usando Apache ou Litespeed como seu servidor HTTP. Como nos exemplos acima, .htaccess precisa ter uma linha sem comentários como esta para definir um limite máximo de PHP de 256 MB:
php_value memory_limit 256M
Erros na sintaxe das configurações do aplicativo e do servidor em wp-config.php
, php.ini
e .htaccess
também podem causar um WSOD. Você pode precisar corrigi-los manualmente ou substituí-los por seus padrões originais se estiverem quebrando seu site. Se você estiver usando um servidor web Apache ou Litespeed, o arquivo .htaccess
que controla como eles operam pode ser alterado por muitos plugins do WordPress. Erros introduzidos em qualquer um desses arquivos podem abrir um WSOD e derrubar seu site.
4. Seu servidor HTTP está travando
HTTP (ou sua forma criptografada e segura HTTPS) é o protocolo de transferência de hipertexto que transforma um servidor da web em um servidor da web. É assim que os servidores fornecem páginas da Web (documentos HTTP) para clientes (como navegadores) mediante solicitação.
Os servidores HTTP comumente usados para sites WordPress são Apache, Litespeed e NGINX. Suas telas de erro parecem um pouco diferentes e podem variar na maneira como os navegadores as exibem, mas todas relatam os mesmos códigos de erro HTTP.
Um erro HTTP 500, também conhecido como Erro interno do servidor, indica que há um problema inesperado com o servidor HTTP que o impede de atender às solicitações HTTP. Outros códigos de erro do servidor 5xx, especialmente 502 (Bad Gateway), 503 (Serviço indisponível) e 504 (Gateway Timeout), indicam que seu servidor está sobrecarregado ou inacessível. O erro interno 500 é uma solução para falhas no servidor que o impedem de retornar a página/documento solicitado.
Seu navegador pode fornecer sua própria visão exclusiva das telas de erro HTTP e pode exibir seus próprios códigos de erro especiais. O Google Chrome (e outros navegadores baseados no Chromium) lista e explica todos os seus próprios códigos de erro internamente se você navegar para chrome://network-errors/
na sua barra de endereço enquanto estiver usando o Chrome.
Problemas do lado do servidor
O software de servidor HTTP comumente usado para sites WordPress inclui Apache, Litespeed e NGINX. Muitos hosts do WordPress os usam com cache para maximizar o desempenho.
Se uma atualização forçada do navegador ou a limpeza dos cookies e do cache do navegador não eliminar a tela de erro 500, você pode estar pegando alguns arquivos de cache do lado do servidor ruins. O cache do lado do servidor pode causar muita confusão quando não está funcionando bem, então você também deve tentar limpá-lo. Seu painel de controle de hospedagem ou interface de administração do WordPress pode ter controles de limpeza de cache.
As causas comuns de um erro HTTP 500 podem incluir as seguintes condições do lado do servidor:
- O limite de memória do PHP foi excedido.
- Outros erros do PHP quando o PHP não está configurado para exibir erros.
- Permissão insuficiente para acessar arquivos e pastas do servidor.
- Erros de sintaxe no arquivo de configuração .htaccess.
Já abordamos os limites de memória do PHP e como aumentá-los. Vamos nos aprofundar na depuração do PHP na próxima seção abaixo.
Permissões incorretas não devem acontecer na hospedagem moderna e gerenciada do WordPress, mas são comuns na hospedagem compartilhada tradicional. Os arquivos devem ser definidos como 664 ou 644, as pastas devem ser definidas como 775 ou 755 e wp-config.php deve ser definido como 660, 600 ou 644. Saiba mais sobre como alterar as permissões de arquivos em WordPress.org.
Se você fez alterações em seu arquivo .htaccess ou está usando um plug-in (geralmente ou em cache) que o altera, talvez seja necessário revisá-lo quanto a erros, restaurá-lo ou recriar um novo arquivo .htaccess funcional. Saiba mais sobre .htaccess
em WordPress.org.
Problemas do lado do cliente
Os erros HTTP 500 também podem ser causados no lado do cliente (no seu navegador) por outras condições:
- Configurações incorretas do navegador.
- Um cache corrompido.
- Arquivos JavaScript corrompidos executados em seu navegador.
- Problemas de conectividade com a Internet.
Tente carregar seu site em um navegador diferente para eliminar o problema do navegador atual. Se você tiver um problema com o navegador, tente redefini-lo para as configurações padrão. Desative quaisquer extensões de navegador ou plug-ins que você instalou para ver se eles estão interagindo mal com seu site.
Se o seu problema estiver relacionado a arquivos de cache inválidos, a área de administração sem cache do WordPress ainda pode estar acessível para você. Se você ainda conseguir fazer login na interface de administração do WordPress, poderá usar as opções de limpeza de cache ou tentar as etapas adicionais de solução de problemas discutidas abaixo.
Também é possível que um erro HTTP 500 seja causado por um problema com o banco de dados, um problema com um plug-in ou tema em um site WordPress ou um problema com o próprio WordPress.
Para solucionar um erro HTTP 500, você deve ativar o registro de erros para seu servidor HTTP e PHP. Em seguida, verifique quais erros aparecem em ambos. Você também pode verificar e potencialmente aumentar o limite de memória PHP, desativar plug-ins e mudar para um tema padrão para ver se alguma dessas ações traz seu site de volta.
Veremos essas etapas com mais detalhes a seguir. Se segui-los não acabar com o erro 500, entre em contato com a equipe de suporte do seu host para obter mais assistência.
Quando o WordPress está realmente morto
Se você está obtendo uma tela completamente branca em todas as páginas de front-end e back-end do seu site WordPress sem nenhum feedback de erro visível, essa é a experiência WSOD completa. Você pode obter algumas mensagens de erro e informações de diagnóstico se souber como acessar seus logs de erro do PHP e logs do servidor HTTP. Ativar a depuração do PHP para WordPress é outra opção. Seu host pode ter algumas ferramentas para tornar a depuração mais acessível para você. Mas se esse não for o caso, você pode simplesmente seguir esta lista de curas para o WSOD comum até encontrar sua solução.
Uma lista de verificação principal para solucionar problemas e corrigir a tela branca da morte do WordPress
Para corrigir a tela branca da morte do WordPress, seguir as etapas a seguir levará você a uma solução. Eles estão organizados na ordem das causas mais comuns do WSOD, conforme eu os experimentei, mas você pode experimentá-los em qualquer ordem.
Faz mais sentido priorizar as soluções que parecem ser mais relevantes para sua situação particular.
A etapa de registro e depuração de erros (nº 2) é a mais técnica, mas é completa e sempre informa o que está causando o encerramento do WordPress.
Forneci links para alguns plug-ins gratuitos que podem ser ferramentas úteis de diagnóstico e reparo. Você também pode achar o iThemes Security especialmente útil para seu recurso de verificação e reparo de banco de dados, bem como sua detecção de alteração de arquivo. Ele ainda possui ferramentas de servidor para uma visão mais profunda das configurações e recursos do servidor.
Em último caso, um backup bom e recente colocará seu site on-line novamente em seu último estado bom. Backup Buddy é o melhor plugin para esta função.
Limpe o cache e os cookies do seu navegador
As páginas em cache do seu site no navegador e no servidor podem mostrar algo diferente do que realmente está acontecendo. Vamos ter certeza de que você está vendo o que o WordPress está mostrando aos novos visitantes do seu site.
Primeiro, limpe o cache e os cookies do seu navegador. Isso encerrará sua sessão de usuário se você estiver conectado ao WordPress ou a qualquer outro site, de modo que esteja olhando para ele como qualquer outro visitante.
Em seguida, use o painel de hospedagem e o administrador do WordPress (se disponível) para limpar qualquer cache do lado do servidor que seu host e os plug-ins de cache do WordPress estejam criando. Tente desligar todo o cache do seu site e servidor. Execute uma atualização forçada em seu navegador. Se isso resolver o problema, pode ser que você tenha configurações de cache ativadas que não estão funcionando em seu sistema. Por meio de um processo de eliminação, você pode identificar quais funcionam e quais não.
2. Procure erros de PHP
O código PHP no núcleo, temas ou plugins do WordPress pode gerar um erro fatal que fará o WordPress desistir do fantasma com uma tela branca da morte.
Para obter mais informações sobre erros fatais do PHP e o que os está causando, você pode ativar o relatório de erros do PHP e enviá-lo para a tela, um arquivo de log ou ambos. Erros fatais provavelmente apontarão para a origem do WSOD.
Como um aplicativo da Web baseado em PHP, o WordPress possui seu próprio sistema de relatório de diagnóstico para depuração que ajuda você a aproveitar as funções de registro de erros do PHP. Para ligá-lo e controlá-lo, verifique se há uma linha em wp-config.php
que diz:
define('WP_DEBUG', verdadeiro);
Pode ser necessário adicioná-lo ou alterar o valor de falso para verdadeiro. Isso diz ao WordPress para ativar a depuração do PHP.
Você também pode pegar um atalho instalando e ativando o plugin WP Debugging. Ele ativará a depuração do PHP para WordPress sem que você tenha que modificar wp-config.php
diretamente.
Os parâmetros wp-config.php
adicionais mostrados abaixo imprimirão a saída de depuração na tela como HTML e um arquivo chamado “error_log” por padrão:
define( 'WP_DEBUG_DISPLAY', true ); define( 'WP_DEBUG_LOG', true );
Também pode ser útil forçar o WordPress a usar as versões não otimizadas de suas dependências CSS e JavaScript na chance de estarem causando um problema:
define( 'SCRIPT_DEBUG', verdadeiro );
O plug-in Debug Bar é uma ferramenta adicional e complementar útil. Ele mostrará os dados de depuração em uma interface agradável.
Para que isso aconteça, no php.ini
deve haver uma linha que dê à constante error_reporting
um valor diferente de NONE
, como error_reporting = E_ALL
. Não deve haver um ponto e vírgula no cabeçalho desta linha; isso o torna um comentário em vez de uma configuração ativa. Observe que você receberá todos os erros, avisos e avisos do PHP se usar E_ALL
. Use um valor diferente como E_ERROR
para registrar apenas erros de tempo de execução fatais que causam a falha do WordPress.
3. Verifique se há conflitos de tema e plug-in
A depuração de erros de PHP conforme descrito na etapa anterior deve apontar para um tema claro ou arquivo de plug-in como a fonte de seu WSOD. Você também pode fechar com uma abordagem de processo de eliminação menos técnica.
Temas de solução de problemas
A tela branca da morte geralmente é causada por conflitos entre temas e/ou plugins do WordPress. Para identificar a(s) origem(s) do conflito, você pode tentar desativar todos os seus plug-ins e mudar para os pacotes de temas padrão atuais e não modificados com o núcleo do WordPress, como o Twenty Twenty-Three.
Comece com o tema — é o mais simples de testar. Se mudar seu tema ativo para um tema padrão não modificado e em bom estado colocar seu site online novamente, você sabe que seu problema está no tema que você está usando.
Dê uma olhada no arquivo functions.php
do seu tema, se houver. Se você mudou recentemente, essa é uma provável fonte de sua aflição. O arquivo functions.php
é onde o código funcional personalizado é adicionado para uso com um tema quando ele é ativado. Código incorreto e erros de sintaxe aqui fornecerão um WSOD.
Solução de problemas de plug-ins
Você pode desativar plugins sem acesso ao administrador do WordPress através da linha de comando/SSH ou SFTP simplesmente movendo as pastas de plugins para fora da pasta /wp-content/plugins/
temporariamente. Minha prática é criar uma subpasta de plug-in chamada “A” para que apareça primeiro no diretório /plugins
classificado alfabeticamente. Em seguida, movo todas as outras pastas de plugins para “A”.
Depois de fazer isso, recarregue seu site. O WordPress se comportará como se todos os plugins tivessem desaparecido. Eles ainda estão instalados, mas desativados. Se a tela branca da morte desaparecer, você pode tentar reativar seus plug-ins e tema um por um, atualizando sua página inicial a cada vez para ver qual deles causa a falha do site.
Meks Quick Plugin Disabler é uma ferramenta útil que desativa rapidamente todos os plugins ativos e os reabilita de dentro do administrador do WordPress ao seu comando.
4. Repare arquivos principais corrompidos
Seu WSOD pode ser consequência de arquivos do núcleo corrompidos do WordPress. Embora isso seja improvável, é simples reinstalar rapidamente a versão mais recente do WordPress com um clique na área de atualizações do painel do WordPress. Isso não prejudicará nenhum de seus plug-ins, temas ou conteúdo existente, portanto, é uma maneira boa e fácil de confirmar se seus arquivos principais estão corretos.
Se nenhuma das etapas acima ajudar, o WSOD pode ser causado por um problema com o ambiente do servidor que está além do seu alcance. Nesse caso, pode ser necessário entrar em contato com seu provedor de hospedagem para obter assistência. Como último recurso, você também pode reverter seu site para um estado “último válido” restaurando um backup.
Como prevenir um WSOD — Conselho para proprietários e construtores de sites WordPress
O WordPress estava funcionando muito bem – e então, de repente, você tem a Tela Branca da Morte!
Isso provavelmente ocorre porque VOCÊ mudou algo crítico para o funcionamento do WordPress.
Se você estiver usando uma conta sólida de hospedagem gerenciada do WordPress com Liquid Web ou Nexcess que esteja devidamente configurada com recursos suficientes para as coisas que você está fazendo com ela, 99% das maneiras de quebrar o WordPress com um WSOD podem ser evitadas.
O problema é que os donos de sites não evitam essas práticas!
O que não fazer
- Codificação Cowboy. Adicionar ou editar código funcional em um site ativo via SFTP, linha de comando ou editores de código e insersores de script dentro do administrador do WordPress. Um pequeno erro derrubará o site. Alterar arquivos de configuração como
.htaccess
ewp-config.php
também pode derrubar um site. Em vez disso, trabalhe em um teste local ou em um site de teste ao vivo (mas não público). - Instalando temas duvidosos, plugins e extensões. Instalar software de baixa qualidade ou mesmo nulo em um site ativo é um convite para problemas. Simplesmente adicionar muitas coisas de uma vez pode tornar difícil determinar o que é uma mudança significativa. Semelhante à codificação cowboy, a instalação de novos produtos de código em um site ativo é arriscada. Teste bem em um local privado ou site de teste primeiro.
- Cache complicado. Existem vários tipos de cache do lado do servidor que seu host pode oferecer que podem não funcionar bem com todos os plug-ins de cache e otimização de desempenho. Ao implementar novos métodos ou configurações de cache, teste cuidadosamente em ambientes locais e de teste antes de implementar alterações em um site ativo.
- Atualizando tudo de uma vez. Você pode atualizar em lote muitos temas e plugins de uma só vez. Normalmente isso funciona, mas se o seu servidor atingir o tempo limite, você pode ficar preso no modo de manutenção. Além disso, o código recém-atualizado pode apresentar novos bugs, conflitos ou problemas de compatibilidade. Se isso acontecer e seu site cair, será mais difícil identificar a origem do problema. Pode ser qualquer número de itens se você atualizar vários temas, plug-ins e extensões de uma só vez. O código atualizado pode ser testado localmente e em sites de teste ao vivo antes de lançá-lo em seu site público principal.
Dicas para uma vida sem WSOD
O WSOD pode acontecer em qualquer site WordPress, mas não deve ser motivo de alarme. Seguir as dicas deste guia pode ajudá-lo a identificar o problema e corrigi-lo rapidamente antes que os visitantes do site percebam.
Problemas com um site WordPress ressaltam a importância da manutenção e cuidados adequados. Melhor do que reagir aos WSODs, você pode aprender a trabalhar no WordPress de uma forma que nunca exponha seus visitantes a mensagens de erro e telas em branco.
Faça suas alterações com cuidado e deliberadamente. Lide com seus possíveis WSODs em um teste local ou ambiente de preparação. Essas são ferramentas e recursos padrão para a maioria dos hosts gerenciados do WordPress atualmente. Se você seguir essas práticas recomendadas básicas, não precisará se preocupar com a tela branca da morte do WordPress.
O melhor plugin de segurança do WordPress para proteger e proteger o WordPress
Atualmente, o WordPress é responsável por mais de 40% de todos os sites, tornando-se um alvo fácil para hackers com intenções maliciosas. O plug-in iThemes Security Pro elimina as suposições sobre a segurança do WordPress para facilitar a segurança e a proteção do seu site WordPress. É como ter um especialista em segurança em tempo integral na equipe que constantemente monitora e protege seu site WordPress para você.
Dan Knauss é generalista de conteúdo técnico da StellarWP. Ele é escritor, professor e freelancer trabalhando com código aberto desde o final dos anos 1990 e com WordPress desde 2004.