Um dos arquivos mais importantes de uma instalação do WordPress é o arquivo de configuração. Ele reside no diretório raiz e contém definições constantes e instruções em PHP que fazem o WordPress funcionar da maneira que você deseja. O arquivo wp-config.php armazena dados como detalhes de conexão com banco de dados, prefixo da tabela, caminhos para diretórios específicos e um monte de configurações relacionadas a características específicas que vamos mergulhar neste post.

O arquivo wp-config.php básico

Quando você instala o WordPress pela primeira vez, você é solicitado a inserir as informações necessárias, como detalhes do banco de dados e prefixo da tabela. Algumas vezes seu host irá configurar o WordPress para você, e você não será solicitado a executar manualmente a configuração. Mas quando você estiver executando manualmente a instalação de 5 minutos, você será solicitado a inserir alguns dos dados mais relevantes armazenados no wp-config.

Quando você executar a configuração, você será solicitado a inserir dados que estão armazenados no arquivo wp-config.php
Quando você executar a configuração, você será solicitado a inserir dados que estão armazenados no arquivo wp-config.php

Aqui está um arquivo wp-config.php básico:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');

/** MySQL database username */
define('DB_USER', 'username_here');

/** MySQL database password */
define('DB_PASSWORD', 'password_here');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

define('AUTH_KEY',		'put your unique phrase here');
define('SECURE_AUTH_KEY',	'put your unique phrase here');
define('LOGGED_IN_KEY',		'put your unique phrase here');
define('NONCE_KEY',		'put your unique phrase here');
define('AUTH_SALT',		'put your unique phrase here');
define('SECURE_AUTH_SALT',	'put your unique phrase here');
define('LOGGED_IN_SALT',	'put your unique phrase here');
define('NONCE_SALT',		'put your unique phrase here');

$table_prefix  = 'wp_';

/* That's all, stop editing! Happy blogging. */

Normalmente, este arquivo é gerado automaticamente quando você executa a configuração, mas ocasionalmente o WordPress não tem privilégios para escrever na pasta de instalação. Nesta situação, você deve criar um arquivo wp-config.php vazio, copiar e colar conteúdo do wp-config-sample.php, e definir os valores apropriados para todas as constantes definidas. Quando terminar, faça o upload do seu arquivo para a pasta raiz e execute o WordPress.

Nota: definições constantes e instruções PHP vêm em uma ordem específica que nós nunca devemos mudar. E nunca devemos adicionar conteúdo sob a seguinte linha de comentário:

/* That's all, stop editing! Happy blogging. */

Primeiro, venham as definições das constantes de banco de dados que você deveria ter recebido do seu host:

  • DB_NAME
  • DB_USER
  • DB_PASSWORD
  • DB_HOST
  • DB_CHARSET
  • DB_COLLATE

Seguindo os detalhes do banco de dados, oito chaves de segurança tornarão o site mais seguro contra hackers. Quando você executar a instalação o WordPress irá gerar automaticamente chaves de segurança e sal, mas você pode alterá-las a qualquer momento, adicionando qualquer string arbitrária. Para melhor segurança, considere o uso do gerador online.

A variável $table_prefix armazena o prefixo de todas as tabelas do WordPress. Infelizmente, qualquer um sabe seu valor padrão e isso poderia abrir o banco de dados do WordPress para uma vulnerabilidade, que pode ser facilmente corrigida definindo um valor personalizado para $table_prefix ao executar a configuração.

Para alterar o prefixo da tabela em um site funcional, você deve executar várias consultas no banco de dados, depois editar manualmente o arquivo wp-config.php. Se você não tem acesso ao banco de dados ou não tem o conhecimento necessário para construir consultas personalizadas, então você pode instalar um plugin como Change Table Prefix que irá renomear tabelas e nomes de campos do banco de dados, e atualizar o arquivo de configuração sem nenhum risco.

Nota: é uma boa prática fazer backup de arquivos WordPress e banco de dados mesmo que você vá alterar o prefixo da tabela com um plugin.

Até agora a análise tem se limitado à configuração básica. Mas temos à nossa disposição muitas constantes que podemos definir para habilitar funcionalidades, personalizar e assegurar a instalação.

Sobre a Configuração Básica: Editando o Sistema de Arquivo

O sistema de arquivos WordPress é bem conhecido por usuários e hackers. Por este motivo, você pode considerar mudar a estrutura de arquivos embutida movendo pastas específicas em locais arbitrários e definindo as URLs e caminhos correspondentes no arquivo wp-config. Primeiro, podemos mover a pasta de conteúdo, definindo duas constantes. A primeira define o caminho completo do diretório:

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/site/wp-content' );

O segundo define a nova URL do diretório:

define( 'WP_CONTENT_URL', 'http://example.com/site/wp-content' );

Podemos mover apenas a pasta do plugin definindo as seguintes constantes:

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/wp-content/mydir/plugins' );
define( 'WP_PLUGIN_URL', 'http://example.com/wp-content/mydir/plugins' );

Da mesma forma, podemos mover a pasta de uploads, definindo o novo caminho do diretório:

define( 'UPLOADS', 'wp-content/mydir/uploads' );

Nota: Todos os caminhos são relativos à ABSPATH, e não devem conter uma barra de chumbo.

Quando terminar, organize as pastas e recarregue o WordPress.

A imagem mostra a estrutura de arquivos embutida em comparação com uma estrutura personalizada
A imagem mostra a estrutura de arquivos embutida em comparação com uma estrutura personalizada

Não é possível mover a pasta /wp-content/themes do arquivo wp-config, mas podemos registrar um novo diretório de temas em um plugin ou em um arquivo de funções de um tema.

Características para Desenvolvedores: Modo de Depuração e Consultas de Salvamento

Se você é um desenvolvedor você pode forçar o WordPress a mostrar erros e avisos que o ajudarão na depuração de temas e plugins. Para habilitar o modo de depuração você só precisa definir o valor WP_DEBUG como verdadeiro, como mostrado abaixo:

define( 'WP_DEBUG', true );

WP_DEBUG é definido como falso por padrão. Se você precisar desativar o modo de depuração, você pode simplesmente remover a definição, ou definir o valor da constante como falso.

Quando você estiver trabalhando em um local vivo, você deve desativar o modo de depuração. Erros e avisos nunca devem ser mostrados aos visualizadores do site, pois podem fornecer informações valiosas para os hackers. Mas e se você tiver que depurar de qualquer maneira? Nessas situações, você pode forçar o WordPress a manter a memória de erros e avisos no arquivo debug.log, colocado na pasta /wp-content. Para habilitar este recurso, copie e cole o seguinte código no seu arquivo wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Para que este recurso funcione, primeiro precisamos habilitar o modo de depuração. Depois, definindo WP_DEBUG_LOG para true forçamos o WordPress a armazenar mensagens no arquivo debug.log, enquanto definimos WP_DEBUG_DISPLAY para false as escondemos da tela. Finalmente, definimos para 0 o valor da variável display_errors do PHP para que as mensagens de erro não sejam impressas na tela. wp-config nunca é carregado do cache. Por este motivo, é um bom lugar para sobrescrever as configurações do php.ini.

Nota: Este é um ótimo recurso que você pode aproveitar para registrar mensagens que o WordPress não imprimiria na tela. Como exemplo, quando a ação publish_post é acionada, o WordPress carrega um script que salva os dados, e depois redireciona o usuário para a página de edição de posts. Nesta situação você pode registrar as mensagens, mas não imprimi-las na tela.

Outra constante de depuração determina as versões de scripts e estilos a serem carregados. Defina SCRIPT_DEBUG para true se você quiser carregar versões não compactadas:

define( 'SCRIPT_DEBUG', true );

Se o seu tema ou plugin mostrar dados recuperados do banco de dados, você pode querer armazenar os detalhes da consulta para posterior revisão. A constante SAVEQUERIES força o WordPress a armazenar informações da consulta em $wpdb->queries array. Estes detalhes seriam impressos adicionando o seguinte código ao modelo de rodapé:

if ( current_user_can( 'administrator' ) ) {
        global $wpdb;
        echo '<pre>';
        print_r( $wpdb->queries );
        echo '</pre>';
}

Para uma análise mais profunda deste recurso, consulte Como Construir Consultas Eficientes no WordPress.

Quando o seu site crescer, você pode querer reduzir o número de revisões posteriores. Por padrão, o WordPress salva automaticamente as revisões a cada 60 segundos. Podemos alterar este valor definindo um intervalo personalizado no wp-config da seguinte forma:

define( 'AUTOSAVE_INTERVAL', 160 );

É claro, você pode diminuir o intervalo de auto-salvamento, também.

Cada vez que salvamos nossas edições, o WordPress adiciona uma linha à tabela de posts, para que possamos restaurar as revisões anteriores de posts e páginas. Esta é uma funcionalidade útil que pode se transformar em um problema quando nosso site cresce muito. Felizmente, podemos diminuir o número máximo de revisões de posts a serem armazenados, ou desativar a funcionalidade de forma alguma.

Se você quiser desativar as revisões posteriores, defina a seguinte constante:

define( 'WP_POST_REVISIONS', false );

Se você quiser limitar o número máximo de revisões, em vez disso, adicione a seguinte linha:

define( 'WP_POST_REVISIONS', 10 );

Por padrão, o WordPress armazena posts, páginas, anexos e comentários por 30 dias, depois os apaga permanentemente. Podemos alterar este valor com a seguinte constante:

define( 'EMPTY_TRASH_DAYS', 10 );

Podemos até mesmo desativar o lixo, definindo seu valor como 0, mas considere que o WordPress não permitirá mais que você restaure o conteúdo.

Tamanho de Memória Permitido

Ocasionalmente você pode receber uma mensagem como a seguinte:

Erro fatal: Tamanho de memória permitido de xxx bytes esgotados…

O tamanho máximo de memória depende da configuração do servidor. Caso você não tenha acesso ao arquivo php.ini, você pode aumentar o limite de memória apenas para o WordPress configurando a constante WP_MEMORY_LIMIT no arquivo wp-config. Por padrão, o WordPress tenta alocar 40Mb para o PHP para sites únicos e 64MB para instalações de vários sites. É claro, se a memória alocada ao PHP for maior que 40Mb (ou 64Mb), o WordPress irá adotar o valor máximo.

Dito isto, você pode definir um valor personalizado com a seguinte linha:

define( 'WP_MEMORY_LIMIT', '128M' );

Se necessário, você pode definir um limite máximo de memória, também, com a seguinte declaração:

define( 'WP_MAX_MEMORY_LIMIT', '256M' );

Atualizações Automáticas

A partir da versão 3.7, o WordPress suporta atualizações automáticas para lançamentos de segurança. Este é um recurso importante que permite aos administradores do site manter seu site seguro o tempo todo.
Você pode desativar todas as atualizações automáticas, definindo a seguinte constante:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Talvez não seja uma boa idéia desativar as atualizações de segurança, mas a escolha é sua. Por padrão, as atualizações automáticas não funcionam com versões principais, mas você pode habilitar qualquer atualização principal definindo WP_AUTO_UPDATE_CORE da seguinte forma:

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );

O valor padrão é minor:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Uma constante adicional desativa as atualizações automáticas (e qualquer atualização ou mudança em qualquer arquivo). Se você configurar DISALLOW_FILE_MODS para true, todas as edições de arquivos serão desabilitadas, mesmo as instalações e atualizações de temas e plugins. Por este motivo, sua utilização não é recomendada.

Configurações de Segurança

Podemos usar o arquivo wp-config para aumentar a segurança do site. Além das mudanças na estrutura de arquivos que vimos acima, podemos bloquear algumas funcionalidades que poderiam abrir vulnerabilidades desnecessárias. Primeiro de tudo, podemos desabilitar o editor de arquivos fornecido no painel de administração. A constante a seguir irá esconder a tela do Appearance Editor:

define( 'DISALLOW_FILE_EDIT', true );

Nota: considere que alguns plugins não poderiam funcionar corretamente se esta constante for definida como verdadeira.

disallow_file_edit
disallow_file_edit

Um recurso de segurança é a Administração sobre SSL. Se você comprou um certificado SSL, e ele está configurado corretamente, você pode forçar o WordPress a transferir dados sobre SSL em qualquer sessão de login e administração. Use a seguinte constante:

define( 'FORCE_SSL_ADMIN', true );

Verifique o Codex se você precisa de mais informações sobre Administração sobre SSL.

Outras duas constantes permitem bloquear solicitações externas e listar hospedagens admitidos.

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'example.com,*.anotherexample.com' );

Neste exemplo, primeiro desativamos todos os acessos de hosts externos, depois listamos os hosts permitidos, separados por vírgulas (wildcards são permitidos).

Outras Configurações Avançadas

WP_CACHE set to true inclui wp-content/advanced-cache.php script. Esta constante só tem efeito se você instalar um plugin de cache persistente.

CUSTOM_USER_TABLE e CUSTOM_USER_META_TABLE são usadas para definir tabelas personalizadas de usuários que não sejam as tabelas padrão wp_users e wp_usermeta. Estas constantes habilitam um recurso útil que permite aos usuários do site acessar vários sites com apenas uma conta. Para que este recurso funcione, todas as instalações devem compartilhar a mesma base de dados.

A partir da versão 2.9, suporte a WordPress Otimização Automática de Banco de Dados. Graças a este recurso, configurando WP_ALLOW_REPAIR para true, o WordPress irá reparar automaticamente um banco de dados corrompido.

O WordPress cria um novo conjunto de imagens cada vez que você edita uma imagem. Se você restaurar a imagem original, todos os conjuntos gerados permanecerão no servidor. Você pode sobrescrever este comportamento configurando IMAGE_EDIT_OVERWRITE para true, para que, quando você restaurar a imagem original, todas as edições serão deletadas do servidor.

Bloqueio wp-config.php

Agora sabemos porque o wp-config.php é um dos mais importantes arquivos WordPress. Então, por que não o escondemos para os hackers? Primeiro de tudo, podemos mover o wp-config um nível acima da pasta raiz do WordPress (apenas um nível). Entretanto, esta técnica é um pouco controversa, então eu sugeriria a adoção de outras soluções para proteger o arquivo. Se seu site está rodando no Apache Web Server, você pode adicionar as seguintes diretivas ao arquivo .htaccess:

<files wp-config.php>
order allow,deny
deny from all
</files>

Se o site estiver rodando no Nginx, você pode adicionar a seguinte diretiva ao arquivo de configuração:

location ~* wp-config.php { deny all; }

Nota: estas instruções devem ser adicionadas somente após a configuração estar completa.

Se seu site passou por múltiplas migrações ou você o comprou de outra pessoa, é recomendável que você crie um novo conjunto de chaves de segurança do WordPress. Essas chaves são um conjunto de variáveis aleatórias que melhoram a criptografia das informações armazenadas nos cookies do usuário. Desde o WordPress 2.7 já existem 4 chaves diferentes: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, e NONCE_KEY.

Por padrão, eles são gerados aleatoriamente para você. Mas o WordPress na verdade tem uma ferramenta gratuita que você pode usar para gerar novas chaves aleatórias. Você pode então simplesmente atualizar suas chaves atuais que estão armazenadas em seu arquivo wp-config.php.

Chaves de segurança WordPress
Chaves de segurança WordPress

Leia mais sobre as chaves de segurança do WordPress.

E finalmente, você deve verificar duas vezes e garantir que suas permissões sejam reforçadas em seu arquivo wp-config.php. Tipicamente os arquivos no diretório raiz de um site WordPress serão definidos como 644, o que significa que os arquivos são legíveis e graváveis pelo dono do arquivo e legíveis pelos usuários do grupo dono daquele arquivo e legíveis por todos os outros. De acordo com a documentação do WordPress, as permissões no arquivo wp-config.php devem ser configuradas para 440 ou 400 para impedir que outros usuários no servidor o leiam. Você pode mudar isso facilmente com seu cliente FTP.

permissões do wp-config.php
permissões do wp-config.php

Resumo

Neste post, eu listei muitas constantes do WordPress que podemos definir em um arquivo wp-config. Algumas dessas constantes são de uso comum, e suas funções são fáceis de entender. Outras constantes permitem funcionalidades avançadas que requerem um profundo conhecimento de WordPress e administração do site.

Eu listei as características mais comuns, deixando de lado algumas características avançadas que poderemos discutir em posts futuros. Se você quiser explorar funcionalidades e constantes não listadas aqui, sinta-se à vontade para iniciar uma conversa nos comentários abaixo e vamos mergulhar fundo.

Carlo Daniele Kinsta

Carlo é um apaixonado por webdesign e desenvolvimento frontend. Ele tem mais de 10 anos de experiência com WordPress e colaborou com diversas universidades e instituições educacionais na Itália e na Europa. Carlo já publicou inúmeros artigos e guias sobre WordPress, tanto em sites italianos quanto internacionais, além de revistas impressas. Você pode seguir ele no LinkedIn e no X.