Arquivos Principais Modificados? Como Restaurar Arquivos Principais do WordPress com Segurança

Você está olhando para uma tela branca onde sua página inicial costumava estar. Talvez seja um erro 500 em vez disso, ou um alerta de plugin de segurança dizendo que os arquivos principais do WordPress foram modificados.

Eu substituí arquivos principais em sites que quebrei sozinho e em sites que apareceram já quebrados. O que quer que o tenha trazido aqui, a correção é a mesma, e é menos destrutiva do que parece.

Restaurar arquivos principais do WordPress significa trocar os próprios arquivos de programa do WordPress (aqueles em wp-admin, wp-includes e seu diretório raiz) por cópias limpas do WordPress.org. Seus posts, páginas, mídia, temas, plugins e configurações não se movem. Eles vivem em outro lugar.

Duas coisas dão errado quando as pessoas tentam fazer isso sozinhas.

A primeira é excluir o wp-content junto com as pastas principais, o que transforma um reparo de 20 minutos em uma reconstrução completa. A segunda é pegar a versão mais recente do WordPress quando o site está executando algo mais antigo, o que força um salto de versão principal em um site que já está instável.

Neste post, mostrarei como confirmar se os arquivos principais são o problema antes de excluir qualquer coisa, três maneiras de substituí-los e o que fazer quando substituí-los não for a solução real.

Principais conclusões:

• Verifique antes de excluir qualquer coisa: wp core verify-checksums responde em um comando se os arquivos principais são o problema, e uma passagem limpa significa que você estaria substituindo arquivos que nunca estiveram quebrados.
• Combine sua versão em vez de pegar a mais recente: instalar o WordPress mais recente em um site antigo força uma atualização principal não planejada e uma alteração no esquema do banco de dados em um site que já está instável.
• Você tem três caminhos: o botão Reinstalar versão X.X.X se você puder fazer login, um comando WP-CLI se você tiver SSH e uma troca manual de FTP se você não tiver nenhum dos dois.
• Exclua as pastas principais em vez de substituí-las: a substituição deixa arquivos adicionados pelo invasor dentro de wp-admin e wp-includes porque nada na compilação oficial substitui um arquivo que não faz parte dela.
• Arquivos principais limpos não limpam um site invadido: backdoors em wp-content/uploads, mu-plugins maliciosos e linhas de banco de dados injetadas sobrevivem, que é o ponto em que uma restauração completa supera um reparo arquivo por arquivo.

Sumário

Quais Arquivos São Arquivos Principais do WordPress?

Antes de excluir qualquer coisa, você precisa saber quais pastas contam como arquivos principais do WordPress e quais são suas. Errar nisso é o erro mais caro em todo o processo.

Veja o que conta como arquivo principal:

• Tudo em wp-admin. Este é o painel de administração em si, todas as telas em que você faz login.
• Tudo em wp-includes. Estas são as bibliotecas nas quais o WordPress é executado. É a maior pasta em número de arquivos e a que tem maior probabilidade de ser marcada como modificada.
• Os arquivos PHP soltos no seu diretório raiz. Arquivos como index.php, wp-login.php, wp-settings.php e wp-cron.php ficam ao lado das suas pastas, e eles também são substituídos.

Quais Arquivos do WordPress Você Não Deve Substituir?

Veja o que você deve deixar em paz:

• wp-content. Ele contém uploads específicos do site, plugins instalados, temas, mu-plugins e, às vezes, artefatos de hospedagem ou implantação. O WordPress envia uma cópia desta pasta, mas a sua é única.
• wp-config.php. Ele contém suas credenciais de banco de dados. Substitua-o e seu site não conseguirá encontrar seu próprio conteúdo.
• .htaccess. Não é um arquivo principal, mas o WordPress escreve nele. Salve uma cópia e deixe o original no lugar.
• Qualquer coisa que seu host ou seu desenvolvedor adicionou. Arquivos de verificação de domínio, scripts personalizados, um robots.txt editado manualmente. Se não veio no download do WordPress, ele fica.

Exclua wp-content e você não estará mais restaurando arquivos principais. Você estará reconstruindo seu site do zero.

Quando Você Precisa Restaurar Arquivos Principais do WordPress?

Arquivos principais ficam intocados por meses. Quando eles quebram, é quase sempre uma de algumas poucas causas. Saber qual delas você está enfrentando muda a forma como você lida com a limpeza depois.

Veja quando substituir arquivos principais é a decisão certa:

• Uma atualização principal falhou no meio do processo. A conexão caiu, o servidor atingiu o tempo limite ou o PHP atingiu seu limite de memória. Você fica com alguns arquivos da versão antiga e alguns da nova, e o WordPress não tem como conciliar os dois.
• Uma verificação relatou que os arquivos principais do WordPress foram modificados. Wordfence, Sucuri e muitos hosts gerenciados comparam seus arquivos com as versões oficiais do WordPress.org. Um arquivo principal modificado significa que algo mudou no código que ninguém deveria editar.
• Seu site foi hackeado. Atacantes injetam código em arquivos principais porque esses arquivos são carregados em cada solicitação. Substituí-los limpa o código injetado (não limpa o resto da infecção, sobre o qual voltarei mais tarde).
• Arquivos foram corrompidos durante uma transferência. Uma sessão FTP interrompida ou uma migração incompleta deixa arquivos truncados para trás. Eles parecem normais em uma listagem de arquivos e falham na segunda vez que o PHP tenta executá-los.
• Uma tela branca ou erro 500 sobreviveu à solução básica de problemas. Se você desativou todos os plugins, mudou para um tema padrão e o erro não mudou, os arquivos principais são o próximo lugar a procurar.
• Alguém editou um arquivo principal de propósito. Isso acontece com mais frequência do que você imagina. A edição persiste até que uma atualização a substitua ou o arquivo pare de corresponder ao que o WordPress espera.

Há uma situação em que restaurar arquivos principais não o ajudará em nada: um plugin ou tema quebrado. Este processo não mexe em wp-content, então se esse for o problema real, você fará todo o trabalho e cairá no mesmo erro. O Passo 1 é como você descobre isso antes de gastar uma hora com isso.

O Que Você Precisa Antes de Começar

Veja o que ter pronto antes de restaurar arquivos principais do WordPress:

• Um backup completo feito agora mesmo. Armazene-o em um local separado do servidor que você está prestes a modificar (recomendo Duplicator Cloud). Se você estiver executando o Duplicator Pro, é isso que transforma uma tarde ruim em uma restauração de um clique.
• Acesso através de pelo menos um destes: O painel do WordPress, SFTP ou FTP (FileZilla é gratuito e faz o trabalho), o Gerenciador de Arquivos do seu host ou SSH. Você só precisa de um, e qual deles você tem decide seu método na Etapa 4.
• Seu número exato da versão do WordPress, anotado. Se o painel estiver inativo, abra wp-includes/version.php via FTP e leia a linha $wp_version perto do topo.
• Cópias locais de wp-config.php e .htaccess. Baixe ambos antes de tocar em qualquer coisa.
• 15 a 30 minutos, dependendo do método que você acabar usando.

Se o seu site tiver tráfego real, faça isso durante uma hora de pouco movimento. Ele ficará parcialmente quebrado enquanto o upload é executado.

Como Restaurar Arquivos Principais do WordPress

O processo executa seis etapas. Três delas são iguais, não importa o quê, e a Etapa 4 é onde você escolhe um caminho com base no acesso que você ainda tem.

Veja como restaurar seus arquivos principais do WordPress:

• Etapa 1: Confirme se os arquivos principais são o problema. Uma verificação de checksum informa se você está corrigindo a coisa certa antes de excluir algo que não pode desfazer.
• Etapa 2: Faça backup do site antes de substituir qualquer coisa. Uma transferência que falha no meio da troca pode derrubar o site inteiro, e esta é a etapa que torna isso recuperável.
• Etapa 3: Corresponda à versão do WordPress que você está restaurando. Baixar a versão errada transforma um reparo em uma atualização não planejada em cima de um site quebrado.
• Etapa 4: Substitua os arquivos principais. Escolha o painel, WP-CLI ou FTP com base no acesso que você tem e execute apenas um dos três.
• Etapa 5: Execute a atualização do banco de dados e limpe os resíduos. Código novo contra um esquema antigo, um arquivo .maintenance travado e caches desatualizados são lidos como "ainda está quebrado" quando os arquivos já estão bons.
• Etapa 6: Verifique se a restauração funcionou. Um site que carrega não é prova de nada, e uma segunda passagem limpa de checksum é.

Etapa 1: Confirme se os Arquivos Principais São o Problema

Pule esta etapa e você pode passar uma hora substituindo arquivos que nunca estiveram quebrados. Eu já fiz isso. Um arquivo principal corrompido e um erro fatal de plugin parecem idênticos na parte frontal.

WP-CLI resolve a questão em um comando.

WP-CLI é a ferramenta de linha de comando do WordPress, e você a executa via SSH (uma conexão de terminal com seu servidor). A maioria dos hosts gerenciados já a tem instalada, então verifique antes de assumir que ela não está disponível.

Conecte-se via SSH, entre no seu diretório do WordPress e execute:

wp core verify-checksums

WordPress.org publica um checksum para cada arquivo em cada versão, que é uma pequena impressão digital do conteúdo desse arquivo. O comando baixa a lista para sua versão e a compara com o que está no seu servidor.

Uma instalação limpa retorna uma única linha de sucesso. Uma danificada nomeia cada arquivo que não consegue verificar:

Warning: File doesn't verify against checksum: wp-includes/version.php

Error: WordPress installation doesn't verify against checksums.

Um resultado é um alarme falso que vale a pena reconhecer. readme.html falha constantemente porque os hosts o modificam ou excluem. O comando detecta o idioma da sua instalação sozinho, então você só precisa do sinalizador --locale (wp core verify-checksums --locale=de_DE, por exemplo) se ele adivinhar errado.

Em seguida, execute-o novamente com --include-root:

wp core verify-checksums --include-root

Esse sinalizador avisa sobre arquivos localizados no seu diretório raiz que não fazem parte do WordPress. Em um site hackeado, é frequentemente onde você encontra o que quer que tenha causado isso em primeiro lugar.

Se você não tem acesso SSH, tem três outras maneiras de verificar:

• Execute uma varredura do Wordfence. Sua comparação de arquivos principais faz o mesmo trabalho a partir do painel e mostra exatamente o que mudou em cada arquivo.
• Use a ferramenta de integridade de arquivos do seu host. A maioria dos hosts gerenciados tem uma, geralmente em uma seção de segurança ou ferramentas.
• Compare manualmente. Baixe uma cópia nova da sua versão do WordPress, abra o arquivo suspeito de ambas as cópias e leia-os lado a lado.

Agora leia seus resultados honestamente antes de prosseguir. Se as somas de verificação (checksums) estiverem limpas, seus arquivos principais estão bem, e seu problema é um plugin, um tema ou seu banco de dados.

Substituir os arquivos principais não resolverá nenhum desses problemas.

Você estará pronto para a Etapa 2 quando tiver em mãos uma lista de arquivos específicos que falharam na verificação ou um resultado limpo que diz para você procurar em outro lugar.

Etapa 2: Faça Backup do Site Antes de Substituir Qualquer Coisa

Você está prestes a excluir duas pastas que o WordPress precisa para funcionar. Se o upload que as substitui falhar no meio do processo, seu site passará de quebrado a inexistente.

Esse é um problema pior do que o que você tem agora.

Faça um backup completo, cobrindo tanto seus arquivos quanto o banco de dados. Certifique-se de enviar uma cópia para um local diferente do servidor que você está prestes a editar. Uma cópia externa é o único tipo que sobrevive a uma falha no nível do servidor.

Duplicator é minha ferramenta favorita para isso. Vá para Duplicator Pro » Backups e clique em Add New.

Escolha a predefinição de backup Full Site e selecione pelo menos dois locais de armazenamento (eu gosto de usar Local e Duplicator Cloud).

Você terminará com dois arquivos: o arquivo compactado (archive), que contém seu site e banco de dados comprimidos, e o instalador (installer), que é o script PHP que restaura tudo.

Se algo der errado durante o processo de restauração de arquivos, recarregue esses arquivos em seu servidor e inicie o instalador do Duplicator.

Se você não estiver usando o Duplicator, faça um backup manual. Aqui está o mínimo necessário para esta etapa:

• Baixe wp-content, wp-config.php e .htaccess para o seu computador via FTP.
• Exporte seu banco de dados do phpMyAdmin como um arquivo .sql.

Você estará pronto para seguir em frente quando souber onde seu backup está e como você o restauraria.

Etapa 3: Corresponder à Versão do WordPress que Você Está Restaurando

Todos os tutoriais sobre este tópico dizem para baixar a versão mais recente do WordPress. Isso é um bom conselho se o seu site já estiver executando a versão mais recente. É uma armadilha se não estiver.

Digamos que você esteja duas versões principais atrasado. Você insere os arquivos principais mais recentes e ainda não consertou nada. O que você fez foi forçar uma atualização de versão principal mais uma alteração no esquema do banco de dados em um site instável, no meio de uma emergência, sem testes.

Restaure a versão que você está usando. Atualize mais tarde, de propósito, quando o site estiver saudável.

Veja como encontrar o número da sua versão:

• Do painel: vá para Painel » Atualizações. A versão que você está executando é informada no topo da tela.
• Via FTP: abra wp-includes/version.php e leia a linha $wp_version perto do topo do arquivo. Isso funciona quando nada mais funciona.
• Via SSH: execute wp core version e ele exibirá o número.

Agora, baixe essa compilação exata do arquivo de releases do WordPress em vez da página principal de download. A página principal serve apenas a versão atual.

O download dos arquivos principais do WordPress é um único zip contendo wp-admin, wp-includes, wp-content e os arquivos soltos da raiz. Corresponda à string de versão completa, não apenas ao número principal. Uma diferença de um lançamento pontual ainda é um conjunto diferente de arquivos.

Se você for pelo caminho do WP-CLI, pode pular o download completamente. O comando no Método 2 abaixo lê sua versão e baixa os arquivos correspondentes em uma única etapa.

Você estará pronto para a Etapa 4 quando tiver um zip do WordPress em seu computador que corresponda ao seu site ou um terminal aberto e esperando.

Etapa 4: Substitua os Arquivos Principais

Esta é a etapa em que os arquivos danificados saem e os limpos entram. Existem três maneiras de fazer isso, e todas elas substituem os arquivos do programa do WordPress por cópias verificadas do WordPress.org, deixando seu conteúdo e configurações intocados.

Qual delas você usa depende do acesso que você tem:

• Método 1: O botão do painel. Use este se você ainda puder fazer login no WordPress. É o mais rápido por uma grande margem.
• Método 2: WP-CLI. Use este se você tiver SSH. É o mais preciso e é o único que fixa sua versão dentro do mesmo comando.
• Método 3: FTP Manual. Use este quando você não tiver nenhum dos dois. Funciona em qualquer host e tem o maior número de maneiras de dar errado.

Método 1: Use o Botão Reinstalar do Painel

Se o wp-admin ainda carregar, comece aqui. É a maneira mais rápida de reinstalar o core do WordPress, e você não precisará tocar em uma única pasta.

Vá para Painel » Atualizações. Quando você já estiver na versão atual, o WordPress informa isso e oferece para reinstalar essa versão para você, com um botão Reinstalar versão X.X.X.

Clique nele. O WordPress baixará a atualização, descompactará a atualização do core, verificará os arquivos descompactados, instalará a versão mais recente e atualizará o banco de dados. Ele termina com uma mensagem de sucesso na mesma tela.

Saiba uma limitação antes de começar. Isso reinstala a versão que o WordPress acredita que você deveria estar usando, portanto, não pode retroceder. Se uma atualização ruim foi o que quebrou seu site, este botão não a desfará.

Ele também substitui arquivos em vez de excluir pastas, e o Método 2 também faz isso. Qualquer coisa que um invasor adicionou dentro de wp-admin ou wp-includes permanece no lugar. Se você estiver limpando um hack, use o Método 3 ou confirme depois com uma verificação de checksum que nada extra foi deixado.

Alguns hosts interrompem o processo com uma caixa de diálogo Informações de Conexão solicitando credenciais de FTP. Esse é um problema de propriedade de arquivo, e a seção de solução de problemas abaixo cobre a correção.

Método 2: Use WP-CLI

O WP-CLI é o que eu uso sempre que tenho acesso ao terminal. Conecte-se via SSH, mova-se para o seu diretório do WordPress e execute:

wp core download --version=$(wp core version) --force --skip-content

Veja o que cada parte faz:

• --version=$(wp core version) lê a versão que seu site está executando e baixa essa versão exata.
• --force substitui os arquivos existentes. Sem ele, o WP-CLI se recusa a tocar em um diretório que já contém o WordPress.
• --skip-content deixa o wp-content fora do download inteiramente, para que seus temas, plugins e uploads nunca cheguem perto da substituição.

Não use wp core install aqui, mesmo que o nome pareça certo. Esse comando executa a rotina de instalação do WordPress em um site novo, e é a ferramenta errada para um site que já existe.

Antes de pressionar Enter, saiba que --force não pede confirmação. Se alguém editou deliberadamente um arquivo principal neste site, essa edição desaparece no segundo em que o comando é executado. Geralmente é esse o objetivo, mas verifique com quem construiu o site se você não tiver certeza.

Em seguida, confirme o resultado:

wp core verify-checksums

Uma passagem limpa significa que a parte de arquivos do seu problema está resolvida.

Método 3: Substitua os Arquivos Manualmente via FTP

Quando você não consegue acessar o painel e não tem SSH, faz o mesmo trabalho manualmente: retire as duas pastas principais do servidor e coloque novas em seus lugares.

Nenhum dos movimentos individuais é difícil. A sequência é o que protege os arquivos que você precisa manter, então vale a pena segui-la em ordem.

1. Desative seus plugins se você ainda conseguir acessar o painel. Pule esta etapa se não conseguir. Isso é uma precaução, não um requisito.
2. Descompacte o download do WordPress no seu computador. Você verá wp-admin, wp-includes, wp-content e um punhado de arquivos soltos.
3. Exclua wp-admin e wp-includes no servidor. Ambas as pastas, completamente. Deixe todo o resto exatamente onde está.
4. Envie os novos wp-admin e wp-includes da sua cópia descompactada para o mesmo local.
5. Envie os arquivos raiz soltos da nova compilação e substitua os antigos. Não exclua sua pasta raiz primeiro. Você levaria wp-config.php e .htaccess junto com ela.
6. Copie os arquivos de dentro do novo wp-content para o seu wp-content existente. Copie para dentro dele. Nunca o substitua.
7. Confirme se wp-config.php e .htaccess ainda estão na sua raiz. Se algum deles estiver faltando, envie a cópia que você salvou anteriormente.

A Etapa 3 dessa lista é onde as pessoas hesitam, porque excluir parece mais arriscado do que sobrescrever. É o oposto.

Sobrescrever apenas substitui arquivos que existem em ambas as cópias. Qualquer coisa que um invasor colocou dentro de wp-admin ou wp-includes não faz parte da compilação oficial, então nada a sobrescreve, e ela passa por toda a sua limpeza intacta. Excluir as pastas primeiro é o que torna isso uma correção real em vez de cosmética.

Defina suas expectativas de tempo também. wp-includes por si só tem mais de mil arquivos, e o FTP os move um por um. Vinte minutos é normal em uma conexão lenta, e transferências interrompidas podem acontecer.

Se o upload continuar falhando, envie o zip para o seu servidor como um único arquivo e extraia-o lá com o Gerenciador de Arquivos do seu host. Uma transferência grande é muito mais confiável do que mil pequenas.

Você terminou esta etapa quando sua estrutura de pastas corresponder à cópia nova, wp-config.php estiver intacto e o site carregar, mesmo que ele o cumprimente com um prompt de atualização de banco de dados.

Etapa 5: Execute a Atualização do Banco de Dados e Limpe os Restos

Seus arquivos estão limpos agora, mas o WordPress ainda pode estar no estado em que a atualização falha o deixou. Três pequenas limpezas finalizam o trabalho.

Comece visitando /wp-admin. Pode ser que você precise fazer login novamente, o que é normal.

Se o WordPress detectar que seu banco de dados precisa ser atualizado para corresponder ao código, ele exibirá uma tela de Atualização do Banco de Dados Necessária com um botão Atualizar Banco de Dados do WordPress. Clique nele e deixe o processo ser concluído.

Faça isso imediatamente, pois até que você o faça, seu site estará executando um código novo contra um esquema antigo.

Em seguida, procure no seu diretório raiz por um arquivo chamado .maintenance e exclua-o se ele estiver lá. O WordPress cria esse arquivo no início de uma atualização e o remove quando a atualização é concluída. Quando uma atualização falha no meio do processo, o arquivo permanece, e os visitantes veem a mensagem de manutenção.

É um arquivo oculto, portanto, ele não aparecerá na sua lista de arquivos até que você ative a exibição de arquivos ocultos. No FileZilla, isso é Servidor » Forçar exibição de arquivos ocultos, e na maioria dos gerenciadores de arquivos de hospedagem, é uma caixa de seleção Mostrar arquivos ocultos nas configurações.

Em seguida, limpe todos os caches que você tiver: seu plugin de cache, o cache do servidor da sua hospedagem, sua CDN e seu próprio navegador. Se pular esta etapa, você pode perder 20 minutos depurando uma página que já foi corrigida.

Reative seus plugins se você os desativou durante o Método 3.

Você terminará aqui quando o painel carregar, o aviso de atualização desaparecer e seu site for renderizado no front-end.

Etapa 6: Verifique se a Restauração Funcionou

Um site que carrega não é o mesmo que um site que foi corrigido. Antes de fechar a aba, revise esta lista.

Aqui está o que verificar:

• Execute novamente wp core verify-checksums. Uma passagem limpa é a única prova definitiva de que seus arquivos principais correspondem à versão oficial.
• Carregue seu front-end desconectado em uma janela de navegação anônima. Visualizações conectadas ocultam problemas de cache e erros de permissão.
• Clique nas páginas importantes. Sua página inicial, um post individual, um arquivo de categoria, a tela de login e qualquer formulário ou checkout que você dependa.
• Re-salve seus permalinks. Vá para Configurações » Permalinks e clique em Salvar alterações sem mudar nada. Isso regenera suas regras de reescrita, que é o motivo usual para posts começarem a retornar 404s após uma troca de arquivos.
• Confirme seus URLs. Em Configurações » Geral, verifique se o Endereço do WordPress (URL) e o Endereço do Site (URL) estão exatamente como estavam antes.
• Leia seu log de erros. Qualquer coisa nova lá vale a pena lidar agora, enquanto você ainda se lembra do que mudou.

Em seguida, faça mais um backup. Seu site está em um estado conhecido e bom neste exato momento, que é o estado que vale a pena capturar, e é uma cópia muito mais útil para manter do que a de emergência que você fez na Etapa 2.

E Se Substituir os Arquivos Principais Não Resolver o Problema?

Às vezes, você passa por todas as etapas, as somas de verificação retornam limpas e o site ainda está com problemas. Quando isso acontece, os arquivos principais danificados eram um sintoma em vez da causa.

Três cenários explicam a maioria desses casos:

• O site foi invadido. A substituição de arquivos principais remove o código injetado dos arquivos principais e nada mais. Um backdoor em wp-content/uploads, um arquivo de tema modificado ou algo escondido em mu-plugins sobrevivem a isso. O sinal mais claro são os arquivos PHP na sua pasta de uploads, onde apenas mídias deveriam estar.
• O banco de dados também sofreu danos. Seus arquivos estão bem e seu conteúdo também não. Links de spam injetados na tabela de posts, um siteurl reescrito na tabela de opções e contas de administrador desconhecidas sobrevivem a uma restauração principal.
• As somas de verificação passam e o site ainda apresenta erros. Isso aponta para um plugin, um tema ou uma incompatibilidade de versão do PHP. A Etapa 1 o colocou no caminho certo; os arquivos principais nunca foram o problema.

Em todos os três casos, restaurar o site inteiro a partir de um backup confiável é melhor do que tentar consertar arquivo por arquivo. Você para de adivinhar o que está limpo.

No Duplicator Pro, encontre um backup anterior ao início do problema e restaure-o.

Se esse backup estiver no Google Drive, Dropbox ou outro local de armazenamento conectado, você pode restaurá-lo diretamente do WordPress sem precisar baixar e reenviar o arquivo primeiro.

Se o WordPress não carregar, envie novamente o backup com o qual você começou para o seu diretório raiz. Inicie o instalador do Duplicator com um URL como: https://seusite.com/installer.php

Uma restauração retorna seu site ao momento em que o backup foi feito, então tudo o que foi publicado ou encomendado desde então vai junto. Em um site comprometido, essa geralmente é a decisão correta, porque uma limpeza parcial que omite um backdoor o coloca de volta aqui em uma semana.

O Duplicator não verifica nem remove malware. Ele fornece uma cópia limpa de um site que funcionava. Combine-o com um scanner de segurança se você estiver lidando com uma infecção ativa.

Para o método manual, Como Restaurar Manualmente Seu Site WordPress cobre a restauração de arquivos e bancos de dados manualmente, e Como Restaurar um Site Apenas com Backup do Banco de Dados cobre o que fazer quando o banco de dados é tudo o que você tem.

Solução de Problemas: Erros Comuns Após Restaurar Arquivos Principais

Essas são as falhas que surgem com mais frequência após a troca de arquivos principais. Trabalhe a partir do sintoma que você está observando.

Por que meu site diz "Brevemente indisponível para manutenção agendada"?

Você recebe uma página em branco simples com uma única linha de texto, e ela não desaparece.

O WordPress grava um arquivo chamado .maintenance no seu diretório raiz quando uma atualização começa e o exclui quando a atualização termina. Se a atualização falhou no meio, esse arquivo ainda está lá, e o WordPress não tem como saber que o trabalho nunca foi concluído. O WordPress para de considerar o arquivo após 10 minutos, mas uma atualização com falha pode deixar seu site parcialmente atualizado nesse ínterim.

Exclua .maintenance do seu diretório raiz via FTP com os arquivos ocultos ativados. Via SSH, wp maintenance-mode deactivate faz a mesma coisa. Seu site retorna no momento em que o arquivo é removido.

Por Que Me Pedem Informações de Conexão FTP?

Você clica em Reinstalar versão X.X.X e o WordPress abre uma caixa de diálogo de Informações de Conexão pedindo um nome de host, nome de usuário e senha. Este é um problema de propriedade de arquivo.

O WordPress grava arquivos diretamente apenas quando eles pertencem ao mesmo usuário que executa o servidor web. Quando não pertencem, ele solicita credenciais de FTP para que possa gravá-los de outra forma.

Insira as credenciais da conta FTP que possui seus arquivos do WordPress, e ele continuará. Se você não as tiver, peça ao seu provedor para corrigir a propriedade, que é a solução real.

Você também encontrará conselhos online sobre como adicionar define('FS_METHOD', 'direct'); ao wp-config.php. Às vezes funciona, mas contorna o sintoma e pode falhar mais tarde de maneiras mais difíceis de diagnosticar do que a caixa de diálogo.

Por Que Recebo uma Tela Branca Após Substituir os Arquivos Principais?

Nada carrega, nem o front-end nem o admin, e não há texto de erro para trabalhar. Três causas cobrem quase todos esses casos: uma transferência FTP que terminou incompletamente, permissões de arquivo incorretas durante o upload ou um erro fatal de PHP que está sendo suprimido.

Reenvie o wp-includes primeiro, pois é a pasta maior e a mais provável de ter perdido arquivos. Em seguida, verifique suas permissões, que devem ser 644 para arquivos e 755 para pastas.

Se a tela ainda estiver em branco, adicione define('WP_DEBUG', true); e define('WP_DEBUG_LOG', true); ao wp-config.php e leia o arquivo wp-content/debug.log. Isso transforma uma tela branca em um nome de arquivo e um número de linha.

Por Que as Verificações de Integridade Ainda Falham Após uma Reinstalação Limpa?

Você substituiu tudo e o wp core verify-checksums ainda está gerando avisos. Geralmente são três coisas: readme.html é sinalizado porque seu provedor o modifica ou remove, o comando escolheu o idioma errado para sua instalação ou algo nessas pastas genuinamente não pertence a elas.

Se todos os arquivos forem sinalizados, execute-o novamente com sua localidade (wp core verify-checksums --locale=fr_FR, por exemplo) e veja o que resta. Um aviso de "Arquivo não deve existir" significa que algo extra está dentro de uma pasta principal e a substituição não o removerá. Exclua wp-admin e wp-includes completamente e envie cópias novas, que é a diferença que o Método 3 faz.

Por Que o WordPress Diz que uma Atualização Já Está em Andamento?

Você tenta reinstalar e recebe a mensagem "Outra atualização está em andamento". O WordPress define um bloqueio em sua tabela de opções quando uma atualização principal é iniciada, para que duas atualizações não possam ser executadas ao mesmo tempo. Uma atualização travada deixa esse bloqueio para trás sem nada para limpá-lo.

O bloqueio expira sozinho após 15 minutos, então esperar não lhe custa nada além de tempo. Para limpá-lo agora, execute wp option delete core_updater.lock, ou abra sua tabela de opções no phpMyAdmin, encontre a linha core_updater.lock e exclua-a.

Nada Está Funcionando: E Agora?

Você trabalhou na lista e o site ainda está fora do ar. Neste ponto, pare de consertar e comece a restaurar.

Volte para o backup que você fez na Etapa 2. Se você ainda conseguir acessar o painel, execute uma restauração com um clique em Duplicator Pro » Backups. Se não conseguir, faça o upload novamente do arquivo e do instalador para o seu diretório raiz e inicie o instalador no seu navegador, que funciona sem uma instalação do WordPress funcional por trás dele.

Se você não tiver um backup, entre em contato com seu provedor e pergunte sobre um snapshot do lado do servidor. A maioria dos provedores mantém backups diários em uma janela rotativa, mesmo em planos compartilhados, e o suporte pode restaurar um para você.

Perguntas Frequentes (FAQs)

Arquivos Principais Limpos São a Base: Veja o Que Fazer a Seguir

Você substituiu os arquivos do programa do WordPress por cópias verificadas e confirmou isso com uma verificação de checksum. Essa verificação é mais importante do que o site simplesmente carregar novamente. Um site pode carregar perfeitamente bem com um arquivo principal modificado executando silenciosamente o código de outra pessoa em cada solicitação, e é por isso que a etapa de diagnóstico veio antes de qualquer outra coisa.

Três hábitos o livram disso a partir de agora.

• Agende seus backups em vez de fazê-los quando você se lembrar.
• Faça um backup novo após cada atualização bem-sucedida, para que seu estado mais recente conhecido como bom nunca esteja a mais de uma restauração de distância.
• Execute wp core verify-checksums como uma verificação mensal rotineira em vez de uma medida de emergência, porque um arquivo principal modificado que você pega durante uma verificação de integridade é um problema muito menor do que um que você descobre quando o site sai do ar.

Mais uma coisa que vale a pena fazer enquanto você já está em wp-config.php. Adicione define('DISALLOW_FILE_EDIT', true); para desativar os editores de temas e plugins integrados, o que fecha o caminho mais fácil para qualquer pessoa com acesso de administrador alterar um arquivo de dentro do painel. Em seguida, adicione um pequeno arquivo .htaccess em wp-content/uploads que impede a execução de PHP lá:

<Files *.php>

Require all denied

</Files>

Essa segunda opção é a sintaxe do Apache 2.4, então no nginx você vai querer o bloco de localização equivalente na configuração do seu servidor. Juntos, eles fecham as duas portas que colocaram a maioria das pessoas nessa posição para começar, e nenhuma delas leva mais de um minuto.

Pare de Consertar Sites WordPress Manualmente

Substituir arquivos principais manualmente funciona. Também custa uma tarde, e só ajuda se você pegar o problema antes que ele se espalhe. Um backup recente e uma restauração de um clique transformam essa longa sessão de depuração em dois minutos.

Duplicator Pro é o que mais de 1,5 milhão de usuários ativos confiam para backups agendados, restaurações de um clique direto do armazenamento em nuvem e uma URL de recuperação de desastres que ainda funciona quando o WordPress não carrega. Cada plano pago vem com um reembolso de 14 dias sem perguntas.

Se este tutorial ajudou, estes guias também valem a pena ser marcados.

• Como Restaurar o WordPress a Partir de um Backup (Em Menos de 5 Minutos)
• Como Restaurar Manualmente Seu Site WordPress
• Como Restaurar um Site Apenas com Backup do Banco de Dados
• Como Fazer Downgrade da Sua Versão do WordPress e Reverter Atualizações Ruins
• Como restaurar seu site WordPress de um backup do Google Cloud
• Como Restaurar um Site WordPress para uma Data Anterior Sem Backup