wp-config.php

wp-config.php é o arquivo de configuração mais importante de qualquer instalação WordPress. Vive na raiz do site, é lido em toda requisição antes de qualquer outra coisa, e contém as definições críticas que dizem ao WordPress como conectar ao banco, quais chaves de segurança usar para criptografar cookies, qual prefixo aplicar nas tabelas, e dezenas de constantes opcionais que controlam tudo desde modo debug até limite de memória PHP. Editar esse arquivo é poder; editar errado é quebrar o site.

O que é o wp-config.php

Quando você instala o WordPress, um dos primeiros passos é criar o wp-config.php. O instalador pede dados de conexão com o banco (host, nome, usuário, senha) e escreve esses valores em arquivo PHP no diretório raiz. A partir daí, toda vez que o WordPress carrega, ele inclui esse arquivo logo no início para saber onde se conectar.

Quem busca o que é wp-config costuma estar tentando aplicar uma alteração específica (mudar prefixo de tabela, ativar debug, definir memória) ou diagnosticar erro de conexão. Em ambos os casos, o ponto de partida é entender que esse arquivo é PHP normal: pode receber qualquer constante PHP, qualquer condicional, qualquer lógica.

O nome wp-config.php é fixo. WordPress não procura outro arquivo para configuração. Há apenas uma exceção: o instalador inicial usa wp-config-sample.php como template e copia para wp-config.php no setup. Depois disso, o sample some do fluxo e fica só como referência.

Em hospedagens gerenciadas, o wp-config.php costuma ter customizações próprias da hospedagem: variáveis de ambiente injetadas, constantes de cache em memória, configurações específicas da infra. Editar diretamente sem ler o que está lá pode quebrar integrações importantes que você nem sabia existir.

Principais constantes do wp-config

As constantes obrigatórias são quatro: DB_NAME (nome do banco), DB_USER (usuário do banco), DB_PASSWORD (senha do banco), DB_HOST (servidor do banco, geralmente localhost). Sem qualquer uma delas, o WordPress retorna o clássico erro “Erro ao estabelecer conexão com o banco”.

$table_prefix é o prefixo de todas as tabelas. Padrão é wp_, mas alterar para algo único (sitexpto_, blogabc_) é boa prática de hardening: ataques automatizados que assumem prefixo padrão falham antes de qualquer query. Importante: trocar prefixo em site existente exige rename de todas as tabelas via SQL, não só editar a constante.

As chaves AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY (e seus salts equivalentes) são usadas para criptografar cookies de sessão e gerar nonces. WordPress oferece um gerador oficial em api.wordpress.org/secret-key/1.1/salt/. Trocar essas chaves invalida todas as sessões logadas, útil em incidentes de segurança.

WP_DEBUG ativa modo debug. Em desenvolvimento, define como true para ver erros na tela. Em produção, sempre false, ou combine com WP_DEBUG_LOG=true para registrar erros em arquivo sem exibir ao visitante. WP_DEBUG_DISPLAY=false oculta erros mesmo com debug ativo. Configurar wp-config nesses três pontos cobre o cenário padrão.

Como editar wp-config.php com segurança

O caminho mais seguro é via SFTP. Conecte ao servidor com cliente SFTP (FileZilla, Cyberduck, Transmit), baixe wp-config.php para o computador local, edite com editor de texto decente (VS Code, Sublime, Notepad++) e suba de volta. Sempre faça backup do original antes.

Para edições rápidas, gerenciador de arquivos do cPanel ou painel da hospedagem funciona, mas tem maior risco de erro porque a interface web pode adicionar caracteres invisíveis ou trocar encoding. Para mudanças complexas, sempre prefira editor offline.

Antes de salvar, releia tudo. Erro de sintaxe PHP no wp-config.php derruba o site inteiro com White Screen of Death. Faltou ponto-e-vírgula, sobrou aspas, parêntese desbalanceado: qualquer um desses erros bloqueia o WordPress de carregar. Use lint PHP ou um IDE para detectar antes do upload.

Sempre coloque suas constantes acima da linha que diz “That’s all, stop editing! Happy publishing.” Tudo abaixo dessa linha é executado pelo WordPress automaticamente, e mexer ali pode quebrar coisas. Mantenha customizações em bloco próprio acima, com comentário explicando o que cada constante faz. Combine com testes em WP-CLI ou em ambiente staging.

Boas práticas de segurança

O wp-config.php contém as senhas do banco e as chaves de criptografia. Vazamento desse arquivo é incidente grave. A primeira proteção é mover o arquivo para um nível acima da raiz do site quando o servidor permite. WordPress busca em ../wp-config.php se não encontra na raiz. Servidores Apache e Nginx em hospedagens modernas suportam essa configuração.

A segunda camada é bloquear acesso direto via .htaccess (Apache) ou nginx.conf (Nginx). Regra simples: deny all para wp-config.php. Mesmo se alguém tentar acessar example.com/wp-config.php diretamente, recebe 403 Forbidden. Combine com proteção contra vulnerabilidades via firewall e htaccess bem configurado.

A terceira camada é definir DISALLOW_FILE_EDIT como true. Isso desabilita o editor de arquivos do painel admin, fechando vetor clássico de invasão: atacante que comprometeu admin não consegue mais editar plugin ou tema via wp-admin para injetar backdoor. Cada admin compromettido perde poder de execução de código.

A quarta camada é definir FORCE_SSL_ADMIN como true e usar HTTPS em todo o site. Sem isso, login e cookies trafegam em texto puro pela rede, expostos a interceptação. Combine com backup regular, atualização agressiva de plugins e auditoria periódica para fechar a stack de segurança em torno do wp-config.

Para times que querem wp-config.php sempre hardenizado e configurado por padrão sem precisar editar manualmente em cada site, a FULL Services entrega a stack profissional já com wp-config.php pré-configurado dentro do plano da hospedagem parceira: chaves regeneradas, debug desligado em produção, FORCE_SSL_ADMIN ativo, DISALLOW_FILE_EDIT ligado e bloqueios de acesso direto via servidor. Em vez de hardenizar arquivo a arquivo, o site roda em uma camada validada em produção desde o primeiro deploy.