O Guia Avançado do Desenvolvedor para o Arquivo wp-config.php

Publicados: 2022-09-28

Quão bem você realmente conhece wp-config ? Há uma quantidade surpreendente de poder nessas poucas linhas de PHP! Este artigo é um tour por alguns bits do wp-config que você talvez não conheça, mas realmente deveria.

Você sabe tudo o que há para saber sobre o arquivo wp-config.php ? Você já leu toda a página de documentação do WordPress sobre isso? Direto até o fim?

Se você já estiver familiarizado com o básico do wp-config , ler a documentação oficial do WordPress provavelmente será um festival de soneca adequado.

Se você quer o verdadeiro deleite do desenvolvedor, bem agrupado por assunto, e entregue com o que só poderia ser chamado de “entusiasmo totalmente desnecessário sobre algumas constantes PHP”, então fique por aqui: estou prestes a tornar wp-config.php legal novamente.

Milhouse dos Simpsons, com "wp-config" no rosto e a legenda "Minha mãe diz que sou legal".

Índice

  1. Quem deve ler isso?
  2. Por que você deve ler isso?
  3. O básico
  4. Visualizando constantes wp-config
  5. Quebrando o processo de carregamento do wp-config.php
    1. wp-config pode ser movido para cima
    2. A tela de configuração carrega se não houver um arquivo wp-config.php
    3. wp-config.php Carrega muito cedo
    4. Não mexa com wp-config.php!
  6. Verificando/Linting seu arquivo wp-config.php
  7. Protegendo o WordPress com wp-config.php
    1. Protegendo o wp-config.php dos visitantes do site
    2. Chaves/Sais Rotativos
    3. Movendo e escondendo coisas
    4. Desativando os Editores de Arquivos
    5. Desativando atualizações automáticas
    6. Como evitar solicitações HTTP externas
  8. Movendo coisas
    1. Movendo as tabelas User e Usermeta
    2. Mover diretórios de conteúdo, uploads e plug-ins
  9. Configurações relacionadas ao conteúdo
    1. Alterar URLs do site e do painel
    2. Configurações de postagem
    3. Postar revisões
    4. Alterando o intervalo de salvamento automático
  10. Empacotando

Quem deve ler isso?

Este artigo é destinado a desenvolvedores e usuários avançados que já sabem como editar o arquivo wp-config.php e estão cientes de algumas das configurações que você pode colocar nele.

Não vou dizer como editar o arquivo usando FTP ou cPanel, ou por que você não deve usar o MS Word para editá-lo.

Não vou lhe dizer como configurar seu banco de dados ou revisar as configurações herdadas que você estava usando em 2013, mas realmente não deveria precisar de mais. E a maioria dos anfitriões cuidará do básico para você de qualquer maneira.

Se você é novo no wp-config.php , não faltam guias que lhe darão o básico, ou você sempre pode se aprofundar na documentação oficial.

Por que você deve ler isso?

Sim, sim, eu ouço você. Se os detalhes básicos do que você pode colocar neste artigo são todos abordados em outro lugar, e se o seu host cuida da maioria dos fundamentos de qualquer maneira, por que você deveria ler isso? E, de fato, por que estou gastando meu tempo escrevendo isso?

Bem, se você está feliz com a edição wp-config.php e conhece o básico do que ele faz, provavelmente você é pelo menos um desenvolvedor WordPress de nível intermediário.

Você provavelmente é pelo menos parcialmente responsável por hospedar sites grandes, provavelmente para clientes. Então você precisa saber como você pode usar esse arquivo em uma emergência. E ter uma compreensão suficiente deste arquivo que, se você o editar, não fará algo errado.

Além disso, você quase certamente desejará bloquear certos recursos do WordPress além do que seu host permitirá que você configure automaticamente.

É provável que existam coisas que você nem sabe que pode fazer com wp-config.php ! Alguns “Ah!” momentos a ter.

Este artigo é um ponto de referência útil para configurar alguns dos componentes internos do WordPress. Então continue lendo, marque e compartilhe com seus amigos e colegas.

O básico

Eu disse que este não era um artigo para iniciantes, mas devemos estabelecer os fatos básicos para ter certeza de que estamos no mesmo ponto de partida.

O arquivo wp-config.php fica na raiz da sua instalação do WordPress (pode ficar em outros lugares, mas chegaremos a isso), é carregado como parte da inicialização do WordPress e permite que você configure o núcleo do WordPress.

É essencial para o funcionamento do WordPress. Ele armazena um conjunto de constantes que permitem especificar:

  • A conexão do banco de dados e o prefixo da tabela que o WordPress usa.
  • Informações de segurança como salts e chaves de autenticação.
  • Configurações para outros recursos do núcleo do WordPress, como WP_CACHE e WP_DEBUG .
  • Configurações para plugins que podem adicionar suas próprias opções ao arquivo.
  • Suas próprias opções de configuração.

Fundamentalmente, wp-config.php é um arquivo específico do ambiente. Seu conteúdo pode (e deve!) ser diferente para sites diferentes. Mesmo as cópias locais, de teste e ao vivo do mesmo site terão valores diferentes no arquivo.

O WordPress vem com um wp-config-sample.php que contém o mínimo de detalhes que o WordPress precisa para funcionar. Você pode copiar isso para o seu próprio wp-config.php como parte da instalação, mas hoje em dia isso geralmente é feito para você.

Finalmente, apenas observe que é possível que quando você abrir um arquivo wp-config.php de um site existente você possa ver algumas constantes PHP antigas para recursos legados, como permissões de arquivo padrão e credenciais de FTP para executar atualizações. Não os abordaremos aqui, pois é improvável que você precise usá-los.

Visualizando constantes wp-config

Existem algumas maneiras de verificar rapidamente os valores das constantes do WordPress sem SSH para um servidor remoto e abrir o arquivo.

O recurso Site Health do núcleo do WordPress permite visualizar alguns valores básicos navegando até Ferramentas -> Saúde do site -> Informações -> Constantes do WordPress. As constantes do banco de dados também podem ser vistas na seção “Banco de dados” da mesma página.

Constantes do banco de dados, mostradas aqui na seção Banco de dados da página WordPress Site Health.

O plugin Query Monitor tem um painel “Environment” onde você pode ver algumas constantes wp-config comumente usadas.

O painel "Ambiente" do plugin Query Monitor, mostrando algumas constantes wp-config comumente usadas.

WP-CLI, a interface de linha de comando do WordPress, possui um comando wp config que pode ser usado para obter e definir constantes em wp-config.php . Isso normalmente exigiria que você SSH primeiro, mas se você configurar aliases em sua configuração WP-CLI, poderá criar um atalho rápido para visualizar e modificar constantes em arquivos wp-config remotos.

Quebrando o processo de carregamento do wp-config.php

É útil saber quando o arquivo wp-config.php é carregado, pois isso determina algumas das coisas que você pode e não pode fazer com ele. É um bom exercício para rastrear o processo de carregamento:

  • O WordPress começa a carregar com o arquivo index.php . Isso requer o arquivo wp-blog-header.php .

  • Praticamente a primeira coisa que wp-blog-header.php faz é carregar wp-load.php .

  • Em seguida, wp-load.php define a constante ABSPATH (o diretório básico do WordPress) e inicializa error_reporting() antes de carregar wp-config.php .

Este processo de carregamento, e o código em wp-load.php em particular, podem nos ensinar algumas coisas interessantes. Aqui está esse código:

 /* * If wp-config.php exists in the WordPress root, or if it exists in the root and wp-settings.php * doesn't, load wp-config.php. The secondary check for wp-settings.php has the added benefit * of avoiding cases where the current directory is a nested installation, eg / is WordPress(a) * and /blog/ is WordPress(b). * * If neither set of conditions is true, initiate loading the setup process. */ if ( file_exists( ABSPATH . 'wp-config.php' ) ) { /** The config file resides in ABSPATH */ require_once ABSPATH . 'wp-config.php'; } elseif ( @file_exists( dirname( ABSPATH ) . '/wp-config.php' ) && ! @file_exists( dirname( ABSPATH ) . '/wp-settings.php' ) ) { /** The config file resides one level above ABSPATH but is not part of another installation */ require_once dirname( ABSPATH ) . '/wp-config.php'; } else { // A config file doesn't exist. // [Code here to load the setup screen for in-browser configuration] }

O que vemos aqui?

wp-config.php pode ser movido para cima

Primeiro, o comentário nos diz que podemos colocar wp-config.php na “raiz do WordPress”. O que não menciona é que a “raiz” pode realmente ser um diretório acima do ABSPATH onde o wp-load.php mora.

Podemos ver essa verificação adicional no elseif onde ele procura dirname( ABSPATH ) . '/wp-config.php' dirname( ABSPATH ) . '/wp-config.php' . A condição adicional no elseif é explicada no comentário.

A tela de configuração carrega se não houver um arquivo wp-config.php

Segundo, podemos ver que se um arquivo de configuração não existir, ele carregará a tela de configuração.

É perfeitamente possível que você nunca tenha visto essa tela antes. Ele permite que você insira as informações de configuração inicial, como as credenciais do banco de dados, em uma interface de usuário baseada na web:

A tela de configuração do WordPress raramente vista. O WordPress carrega isso se não encontrar um arquivo de configuração, permitindo que você defina as opções de configuração manualmente.

Este é um recurso do WordPress que vale a pena conhecer. Se você colocar os arquivos principais do WordPress em um servidor da Web disponível publicamente, mas não criar um arquivo wp-config.php , outra pessoa (ou, mais provavelmente, um bot) pode aparecer e configurar o WordPress à sua maneira e possivelmente comprometer sua hospedagem.

wp-config.php Carrega muito cedo

A terceira coisa a notar é que wp-config.php é carregado muito cedo na sequência de inicialização do WordPress. Isso significa que:

  1. Há muita coisa que não podemos fazer em wp-config.php . Por exemplo, não podemos adicionar ganchos (ações ou filtros) aqui porque as funções e estruturas de dados para fazer isso ainda não foram carregadas. E não temos acesso a nenhuma das funções, objetos e APIs internos do WordPress.

  2. Temos muito controle sobre o que acontece a seguir. Como o arquivo é carregado tão cedo, ele tem muita influência sobre o WordPress. Isso é bom e ruim. Podemos facilmente fazer o WordPress morrer completamente. Mas também podemos acessar qualquer coisa que esteja definida em wp-config.php de praticamente qualquer outro lugar no WordPress.

Não mexa com wp-config.php!

A última coisa que aprendemos com esse processo é que com esse grande poder vem uma grande responsabilidade.

Na parte inferior do arquivo wp-config.php estão estas linhas:

 /* Add any custom values between this line and the "stop editing" line. */ /* That's all, stop editing! Happy publishing. */ /** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/' ); } /** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php';

Existem algumas instruções aqui, mas a linha “parar de editar” é importante. Após esta linha está a continuação da sequência de inicialização do WordPress. Adicionar um novo código no lugar errado provavelmente só resultará no novo código sem nenhum efeito. Mas para estar seguro, recomendo seguir estas instruções. Eles estão lá por um bom motivo.

Verificando/Linting seu arquivo wp-config.php

Se você está trabalhando em produção, você realmente não quer colocar nenhum erro no arquivo wp-config.php . Erros aqui podem quebrar seu site e você pode não receber uma mensagem de erro útil exibida quando isso acontecer.

Você pode executar o php na linha de comando com a opção -l (“lint”) para verificar seu arquivo wp-config.php quanto a erros fatais de sintaxe do PHP.

$ php -l wp-config.php

Erro de análise: erro de sintaxe, token inesperado "require_once" em wp-config.php na linha 9

Erros ao analisar wp-config.php

Você pode até escrever um script de shell para…

  1. Copie wp-config.php para um arquivo temporário,
  2. Edite o arquivo temporário,
  3. Lint o arquivo temporário e
  4. Copie-o de volta apenas se não tiver erros de sintaxe.

Se você estiver satisfeito com a linha de comando, é mais seguro usar os comandos WP-CLI, como wp config set <name> <value> para definir valores com segurança, em vez de fazê-lo manualmente.

Você também pode listar seus valores de configuração com WP-CLI (este é um exemplo com algumas entradas removidas - você entendeu!):

$ wp lista de configuração
+----------+--------------------------- -------------------+----------+
| nome | valor | tipo |
+----------+--------------------------- -------------------+----------+
| root_dir | /Usuários/smithers/sites/snpp | variável |
| webroot_dir | /Usuários/smithers/sites/snpp/public | variável |
| table_prefix | wp_ | variável |
| WP_HOME | https://snpp.test | constante |
| WP_SITEURL | https://snpp.test/ | constante |
| DB_NAME | snpp | constante |
| DB_USER | raiz | constante |
| DB_PASSWORD | Montgomery | constante |
| DB_HOST | 127.0.0.1 | constante |
| DB_CHARSET | utf8mb4 | constante |
| DB_COLLATE | | constante |
| DB_PREFIX | wp_ | constante |
| WP_DEBUG | 1 | constante |
| WP_DEBUG_LOG | 1 | constante |
| WP_DEBUG_DISPLAY | | constante |
| WP_ENVIRONMENT_TYPE | desenvolvimento | constante |
| DISABLE_WP_CRON | | constante |
| DISALLOW_FILE_EDIT | 1 | constante |
+----------+--------------------------- -------------------+----------+

Essas duas técnicas podem realmente poupar alguns problemas e impedir que você se preocupe por colocar acidentalmente um ponto e vírgula no lugar errado em um arquivo tão importante.

Protegendo o WordPress com wp-config.php

A segurança é um tópico perpetuamente quente no WordPress. Algumas configurações que podemos alterar no arquivo wp-config colocam mais ferramentas em nossa caixa de ferramentas de segurança.

Essas partes do arquivo wp-config definitivamente não são as únicas coisas que você deve usar para obter uma boa segurança do WordPress. Certifique-se de entender completamente a segurança do site, além das informações na seção a seguir.

Protegendo o wp-config.php dos visitantes do site

Seu arquivo wp-config fica no diretório raiz do seu site por padrão, e por acaso contém informações críticas, como detalhes de login do banco de dados e sais de senha. Você não deseja que essas informações estejam disponíveis publicamente, portanto, certifique-se de que seu arquivo wp-config esteja protegido contra visitantes do site.

Sua empresa de hospedagem geralmente fará isso por você. Você pode verificar tentando acessar o arquivo do seu navegador adicionando /wp-config.php logo após o seu domínio. Este URL pode ser diferente se você tiver movido o arquivo.

Se você colocou o arquivo wp-config no diretório acima do diretório raiz do seu site, não poderá vê-lo. Na maioria dos outros casos, você receberá uma mensagem de erro do PHP ao tentar visitar o arquivo de qualquer maneira, então geralmente não há nada a fazer aqui. Mas se você quiser protegê-lo adequadamente, poderá fazê-lo modificando a configuração do seu servidor web (Apache ou nginx) para bloquear o acesso a ele.

Por fim, se você estiver armazenando o arquivo do seu site no Git, é importante não armazenar o arquivo wp-config em seu repositório Git. Fazer isso pode vazar informações críticas sobre seu site, mas, além disso, você provavelmente deseja uma versão diferente desse arquivo em cada ambiente. Portanto, é melhor adicioná-lo ao seu .gitignore e gerenciar manualmente os arquivos em cada ambiente.

Chaves/Sais Rotativos

O que são chaves/sais?

A seção keys and salts é uma das partes mais misteriosas do wp-config . Esse conjunto de constantes de aparência estranha ajuda na criptografia de coisas como cookies e nonces. Sem entrar em detalhes – como o WP Engine tem – eles adicionam uma camada extra de aleatoriedade que torna as coisas mais difíceis de descriptografar se você não conhece os sais e as chaves.

Por que “girar” teclas/sais?

Em primeiro lugar, “girar” é apenas uma palavra chique para “mudança”. Não sei por que usamos “rotate”. Não é como se voltássemos ao mesmo conjunto de chaves!

Você provavelmente deve alterar suas chaves e sais se o site tiver sido invadido, pois você não pode garantir que as chaves e os sais ainda sejam secretos. Mas você pode querer rodá-los regularmente de qualquer maneira, como com senhas, apenas para ter certeza de que ninguém sabe o que são.

O problema com a rotação de chaves/sais

A mudança de chaves e sais não é isenta de dor. Qualquer um que tenha um conjunto de cookies vai perdê-lo. Portanto, qualquer pessoa logada será inicializada e qualquer pessoa com um carrinho WooCommerce o esvaziará.

Como girar chaves/sais

Quero dizer, você pode editar o arquivo wp-config e apenas digitar alguns novos caracteres aleatórios sobre os antigos. Mas isso seria tedioso e os humanos não são muito bons em aleatoriedade.

Então, deixe-me falar sobre algumas maneiras de definir novas chaves/salts em seu wp-config .

  1. Adicione chaves manualmente de um gerador: você pode usar o gerador wordpress.org para obter o código que você precisa. Basta copiar e colar no arquivo wp-config no lugar dos valores antigos.
  2. Use um plug-in: muitos plug-ins de segurança, como Sucuri Security, iThemes Security e Malcare, têm esse recurso. E Salt Shaker é um plugin dedicado que automatizará esse processo em um cronograma para você.
  3. Use WP-CLI. Já dissemos o quão incrível é o WP-CLI? Nós fizemos? OK. Bem, estamos dizendo de novo! E você pode usar o comando wp config shuffle-salts para fazer esse trabalho em segundos.

Movendo e escondendo coisas

O pessoal de segurança dirá que “segurança por obscuridade” não é segurança, mas algumas pessoas ainda gostam de esconder suas coisas do WordPress para colocar algumas barreiras adicionais aos hackers.

O arquivo wp-config oferece várias opções para fazer isso, e abordaremos isso nas seções posteriores sobre como mover coisas e desativar a edição de arquivos.

Desativando os Editores de Arquivos

O WordPress tem um recurso útil que permite editar arquivos em temas e plugins de dentro do painel de administração. Editar wp-config.php permite desativar esses editores de arquivos! Algumas pessoas gostam de desativá-los para a paz de espírito.

Agora eu sei que há um argumento de segurança de que se alguém tiver acesso de administrador ao seu site - o que é necessário para usar esses editores - então eles podem fazer o upload de um plug-in e fazer o que quiserem de qualquer maneira. Ter esses editores ativados não fornece aos hackers mais poder do que eles já têm.

No entanto, embora a segurança não possa realmente ser melhorada desativando-os, a verdadeira razão para fazê-lo é impedir que as pessoas realmente autorizadas como administradores os usem. Se você é uma agência, provavelmente não quer que seus clientes descubram que podem editar todos os seus arquivos de tema, certo?

Muitos hosts apenas desabilitarão esse recurso por padrão. Mas se você quiser fazê-los desaparecer, é tão simples quanto adicionar:

 define( 'DISALLOW_FILE_EDIT', true );

Ou se você realmente deseja bloquear seu sistema de arquivos, há DISALLOW_FILE_MODS , que abordaremos na próxima seção.

Desativando atualizações automáticas

Quer você os ame ou os odeie, as atualizações automáticas do WordPress tiveram um impacto líquido positivo no ecossistema do WordPress e são difíceis de ignorar. Mas nem todo mundo quer que seu software cuide de si mesmo!

Portanto wp-config oferece controle sobre o processo de atualizações automáticas com um conjunto simples de constantes autoexplicativas que você pode definir:

 # Disable all core updates: define( 'WP_AUTO_UPDATE_CORE', false ); # Enable all core updates, including minor and major: define( 'WP_AUTO_UPDATE_CORE', true ); # Enable core updates for minor releases (default): define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Se você quiser algo mais extremo, você pode DISALLOW_FILE_MODS :

 define( 'DISALLOW_FILE_MODS', true );

Mas isso impede o WordPress de gravar qualquer coisa em disco relacionada ao núcleo, temas, plugins ou traduções e desativa as notificações por e-mail sobre atualizações menores. Foi descrito por um colaborador principal como “louco estúpido de usar, a menos que você saiba exatamente o que está fazendo”.

Um pouco menos extremo é AUTOMATIC_UPDATER_DISABLED . Isso permite que você instale plugins e temas, mas não os atualizará ou o software principal. Ele também desativa as atualizações de tradução.

 define( 'AUTOMATIC_UPDATER_DISABLED', true );

Há um guia detalhado sobre tudo isso no wordpress.org, incluindo algumas outras opções, como usar filtros para um controle mais refinado.

Por fim, observo que, se o seu site for controlado por versão, é provável que o WordPress tenha desativado as atualizações para você de qualquer maneira. Por exemplo, a presença de um diretório .git na raiz do site (ou vários outros arquivos em vários lugares diferentes) desativará as atualizações automáticas sem que você precise adicionar nada ao wp-config .

Configurando HTTPS

A configuração de HTTPS costumava ser um desafio. Com o advento de certificados de segurança gratuitos e confiáveis ​​de lugares como LetsEncrypt e Cloudflare, muitos hosts configurarão isso para você com alguns cliques. Essa configuração provavelmente deve ser considerada herdada, mas talvez você ainda precise dela para alguma coisa.

A constante FORCE_SSL_ADMIN diz ao WordPress para sempre usar SSL para as páginas de login e WordPress Dashboard. Isso garante que credenciais e cookies seguros não possam ser enviados sem criptografia.

Mas, como eu disse, uma boa empresa de hospedagem simplificará a configuração de HTTPS em seu site, então faça isso.

Como evitar solicitações HTTP externas

Finalmente, em segurança, você pode bloquear solicitações HTTP externas. Isso significa que o WordPress não pode entrar em contato com outros lugares na internet para fazer coisas como fazer chamadas de API ou baixar atualizações.

Permitir que o WordPress entre em contato com serviços externos por HTTP geralmente é uma boa ideia, pois permite obter atualizações, instalar plugins e temas, e muitos plugins serão interrompidos se você desativar as solicitações HTTP.

Mas o núcleo do WordPress e muitos plugins e temas enviam “telemetria” ou “dados de uso” de volta aos servidores centrais. Isso pode ser bom – ajuda os desenvolvedores de plugins e temas a saber quem está usando seu software e como. Mas se você tiver um site que contenha dados particularmente confidenciais, convém desativá-lo. E você pode fazer isso com:

 define( 'WP_HTTP_BLOCK_EXTERNAL', true );

Se você quiser ter uma lista de hosts que podem ser contatados, você também pode fazer isso:

 define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );

Observe que a lista de hosts acessíveis é uma lista separada por vírgulas e subdomínios curinga são permitidos. E você pode monitorar quais hosts estão sendo contatados usando o plug-in Log HTTP Requests.

Movendo coisas

Nem toda instalação do WordPress é igual. Alguns hosts ou estruturas gostam de mover diretórios por motivos de segurança ou para manter o código e os ativos específicos do site separados do núcleo do WordPress. Meu artigo sobre como usar o Git e o Composer para gerenciar o WordPress aborda alguns benefícios dessa abordagem.

Então, quais opções o WordPress oferece para – por falta de um termo melhor – “mover coisas”?

Alterando o prefixo do banco de dados

O WordPress usa o prefixo do nome da tabela de banco de dados wp_ por padrão. Esse prefixo é adicionado a todos os nomes de tabelas de banco de dados e é usado em alguns outros lugares também, por exemplo, a opção <prefix>user_roles na tabela de opções e as metaentradas de usuário <prefix>capabilities .

Hackers ou invasores podem usar o prefixo padrão em um ataque, tentando descobrir ou modificar suas tabelas de banco de dados. Portanto, algumas pessoas recomendam alterá-lo do padrão.

A opção wp_config $table_prefix permite que você faça isso e você provavelmente deve configurá-la para uma string curta, mas aleatória, sufixada com um sublinhado:

 $table_prefix = 'b4F8az_';

Isso dirá ao WordPress para usar nomes de tabela como b4F8az_posts em vez de wp_posts .

Você não deve atualizar nenhum código para atender a essa alteração (a menos que o código esteja muito mal escrito), mas se você estiver alterando isso em um site existente, precisará fazer algumas atualizações em seu banco de dados - e não apenas renomear as mesas!

Alguns plugins de segurança fazem isso para você e existe um plugin que pode fazer isso também. É altamente recomendável fazer um backup do seu banco de dados antes de fazer isso e observe que a seleção de um prefixo de tabela não padrão é melhor feita ao instalar o WordPress, não ao alterá-lo enquanto seu site está em andamento.

Uma observação curiosa sobre isso é que $table_prefix é uma variável, não uma constante. É a única variável definida no arquivo de configuração de amostra que o WordPress oferece a você! E se você ainda estiver curioso: sim, os comandos wp config do WP-CLI cuidam disso para você sem que você precise saber!

Movendo as tabelas User e Usermeta

Eu nunca vi isso sendo feito, e só aprendi que isso poderia ser feito ao escrever este artigo, mas você também pode alterar completamente os nomes das tabelas user e usermeta.

Acho que isso ajuda a evitar um ataque de injeção de SQL que tenta “SELECT * FROM wp_usermeta;”, mas fico feliz em ouvir outras razões para fazer isso.

De qualquer forma, as constantes CUSTOM_USER_TABLE e CUSTOM_USER_META_TABLE são o que você precisa:

 define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' ); define( 'CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta' );

Há algumas advertências que vale a pena conhecer antes de usar essas constantes. Verifique os documentos oficiais antes de usar este recurso. E como usar um prefixo de tabela personalizado, isso é definitivamente melhor feito ao instalar um novo site, em vez de modificá-lo posteriormente.

Mover diretórios de conteúdo, uploads e plug-ins

Também é possível mover todo o diretório wp-content , o diretório de uploads e os diretórios de themes e plugins . Coisas a observar:

  • Em alguns desses casos, você precisa definir a URL e o diretório.
  • Você precisa ter cuidado ao usar caminhos completos ou caminhos relativos conforme apropriado.
  • Nenhuma dessas configurações deve ter uma barra final.

Consulte a documentação oficial para detalhes – não vou repetir tudo isso aqui.

Por fim, observe que um plugin ou tema mal codificado pode atrapalhar se você alterá-los. Isso nunca deveria acontecer, mas vale a pena saber.

Se você é um desenvolvedor de plugins ou temas, é importante lembrar que esses caminhos podem mudar. Portanto, certifique-se de não codificar caminhos para diretórios ou URLs. Funções úteis para você aqui são:

wp_upload_dir
plugins_url
plugin_dir_url
plugin_dir_path
get_stylesheet_directory
get_stylesheet_directory_uri
get_template_directory – observe que, para um tema filho, isso retorna a localização do tema pai
get_template_directory_uri

Há uma lista mais completa de funções como essas no manual do desenvolvedor do WordPress.

Por fim, além de mover arquivos dentro da instalação do WordPress, você também pode mover o local do wp-admin ou alterar o local do seu site. E wp-config.php pode ajudar com isso também.

Configurações relacionadas ao conteúdo

Afinal, o WordPress é um sistema de gerenciamento de conteúdo. Então você esperaria algumas das constantes que você pode usar em wp-config.php para controlar as opções de conteúdo. Vamos dar uma olhada e ver o que podemos fazer.

Alterar URLs do site e do painel

Estes sempre me confundiram.

Para definir a URL do seu site, você precisa usar a constante WP_HOME , não a constante WP_SITEURL .

A constante WP_SITEURL não altera a URL do seu site.

Confuso?

A descrição oficial do que o WP_SITEURL faz é “o endereço onde residem seus arquivos principais do WordPress”. Isso também é confuso porque é um URL, não um diretório.

Não me culpe por isso, sou apenas o seu guia turístico do dia!

A configuração WP_HOME e WP_SITEURL substitui as entradas home e siteurl na tabela de banco de dados wp_options . Então isso, pelo menos, faz sentido.

 // NOTE: These must not have trailing slashes define( 'WP_HOME', 'https://helfish.media' ); define( 'WP_SITEURL', 'https://hellfish.media/wordpress` );

Você pode usar essas constantes depois de mover um site para uma nova URL, para colocar o site em funcionamento enquanto você corrige o banco de dados corretamente. Você pode até optar por deixá-los no lugar depois.

A configuração WP_SITEURL também pode ser usada quando você move seus arquivos principais do WordPress para um diretório diferente.

O uso deles também impede que uma ou duas consultas ao banco de dados sejam executadas para obter os valores da tabela de opções, portanto, pode haver um ganho marginal de desempenho. No entanto, se você estiver fazendo cache de objetos, esse ganho provavelmente será insignificante.

Há mais detalhes nos documentos oficiais e até mesmo um artigo de suporte completo sobre como alterar a URL do site. Além disso, esse artigo inclui a obscura constante RELOCATE para wp-config.php que eu nunca tinha ouvido falar antes de pesquisar este artigo.

Por fim, ao mover sites, observe que essa não é a única coisa que você precisa alterar. Uma pesquisa e substituição completa do banco de dados para as strings de URL é recomendada.

Configurações de postagem

Existem algumas configurações diferentes que você pode modificar quando se trata de postagens. A maioria deles está relacionada com revisões posteriores ou com o recurso de salvamento automático.

Postar revisões

O comportamento padrão do WordPress é salvar todas as revisões feitas em posts e páginas. A vantagem disso é que é fácil reverter para versões anteriores. As desvantagens são que todas essas revisões ocupam espaço no banco de dados e podem afetar o desempenho do site diminuindo a velocidade das consultas ao banco de dados.

É possível desabilitar completamente as revisões de postagem modificando o valor WP_POST_REVISIONS em seu arquivo wp-config.php . O padrão é verdadeiro. Para desativar as revisões, você pode configurá-lo como false:

 define( 'WP_POST_REVISIONS', false );:

Alguns hosts, incluindo o WP Engine, desabilitam as revisões de postagem por padrão. Eu recomendo verificar com seu provedor de hospedagem antes de fazer qualquer alteração. Isso varia de host para host, mas se você estiver com o WP Engine, não poderá habilitar revisões por meio wp-config , pois ele será substituído no nível do servidor.

Se o seu host controlar isso e você tentar alterá-lo, não necessariamente quebrará algo, mas poderá estar perdendo seu tempo.

Se você está preocupado com as revisões de posts que atrasam as consultas do banco de dados, uma opção melhor pode ser limitar o número de revisões que o WordPress armazena. Isso é controlado pela constante WP_POST_REVISIONS , que você pode definir para o número máximo de revisões que deseja manter:

 define( 'WP_POST_REVISIONS', 5 );

Alterando o intervalo de salvamento automático

Você também pode diminuir a frequência com que o salvamento automático é acionado. O padrão é a cada 60 segundos, mas você pode alterá-lo para o que quiser. Se você é paranóico, você pode querer definir isso para 20 ou 30 segundos.

É importante ter em mente quanto tempo leva um salvamento automático. Você não quer que eles se sobreponham fazendo com que aconteçam com muita frequência, então não defina esse valor para, por exemplo, um segundo. Não é muito provável que o salvamento automático demore mais do que o padrão de 60 segundos, mas você pode aumentar o intervalo se desejar salvar as solicitações:

 define( 'AUTOSAVE_INTERVAL', 120 ); // Seconds

Empacotando

Há muito potencial no wp-config que está apenas esperando para ser desbloqueado. Espero que este passeio tenha ajudado a destacar apenas um pouco do que é possível. Em um artigo futuro, examinarei mais recursos avançados inerentes ao wp-config , incluindo instalações multisite e depuração. Também analisarei o desempenho, incluindo como ajustar os limites de memória, problemas de CRON e tipos de ambiente.

Sem dúvida, há outros tesouros à espreita na documentação oficial, esperando para serem descobertos. Quais dicas você encontrou para usar wp-config ? Deixe-me saber nos comentários.