Desativar o editor de arquivos do WordPress é uma medida simples para reduzir risco em sites administrados por várias pessoas. A mudança impede que alguém edite arquivos de tema ou plugin diretamente pelo painel administrativo.
Isso não resolve todos os problemas de segurança. Também não substitui backup, controle de usuários, atualização de plugins e proteção de login. Mas ajuda em um ponto sensível: se uma conta administrativa for usada de forma indevida, o invasor terá menos caminhos para alterar arquivos pelo próprio WordPress.
Neste guia, você vai ver quando essa configuração faz sentido, como aplicar no arquivo wp-config.php, como validar o resultado e quais cuidados tomar para não bloquear sua própria rotina técnica.
O que muda ao desativar o editor de arquivos do WordPress
O WordPress pode exibir, no painel, uma área para editar arquivos de temas e plugins. Em muitos sites, essa função quase nunca é necessária. Ainda assim, ela fica disponível para usuários com permissões altas.
Ao desativar o editor de arquivos, o painel deixa de permitir alterações diretas em arquivos como functions.php, folhas de estilo, modelos de tema e arquivos de plugins. Na prática, você evita que uma mudança feita às pressas dentro do admin derrube o site.
Um exemplo comum: alguém copia um trecho de código da internet e cola no arquivo functions.php pelo painel. Se faltar um caractere ou se o código for incompatível, o site pode apresentar erro crítico. Sem editor no painel, esse tipo de alteração precisa passar por um acesso técnico mais controlado, como SFTP, SSH, Git ou painel da hospedagem.
A mudança também reduz impacto em caso de conta administrativa comprometida. Se o login de um administrador for acessado por terceiros, ainda será grave. Porém, a pessoa não terá o mesmo caminho imediato para editar arquivos pelo painel.
Quando vale a pena bloquear a edição pelo painel
Essa configuração faz sentido para a maioria dos sites em produção. Ela é especialmente útil em quatro cenários.
Primeiro, sites institucionais com equipe de conteúdo. Redatores e editores não precisam mexer em arquivos. Administradores também raramente devem editar código pelo painel.
Segundo, lojas WooCommerce. Uma alteração incorreta em tema ou plugin pode afetar carrinho, checkout e páginas de produto. Nesse caso, mudanças técnicas devem ser testadas antes.
Terceiro, sites de empresas com mais de um administrador. Quanto mais pessoas têm acesso elevado, maior a chance de erro humano ou conta mal protegida.
Quarto, sites mantidos por agência ou freelancer. O cliente pode continuar publicando conteúdo, mas alterações de código devem ficar em fluxo separado.
A recomendação pode não servir para um site de teste local, usado apenas por você para aprendizado. Mesmo assim, é bom se acostumar com uma rotina mais segura desde cedo. Se você ainda está montando o ambiente, veja também o guia de instalação em /guias/como_instalar_wordpress_passo_a_passo/.
Pré requisitos antes de mexer no wp config
Antes de alterar o wp-config.php, faça três verificações.
A primeira é ter um backup recente. O arquivo de configuração é pequeno, mas importante. Um erro de digitação pode deixar o site inacessível. Se você ainda não tem rotina clara, leia o guia sobre /hospedagem/backup_wordpress_antes_de_alterar_site/ antes de continuar.
A segunda é confirmar que você tem acesso aos arquivos fora do painel do WordPress. Pode ser pelo gerenciador de arquivos da hospedagem, por SFTP ou por SSH. Em ambientes VPS, como na LetsCloud, o ideal é manter acesso SSH restrito, usuário técnico separado e backup antes de mudanças em produção.
A terceira é saber onde está o arquivo correto. O wp-config.php fica na raiz da instalação do WordPress, normalmente no mesmo nível das pastas wp-admin, wp-content e wp-includes.
Se você não encontra esse arquivo, pare antes de testar alterações aleatórias. Procure o caminho da instalação no painel da hospedagem ou peça ajuda ao responsável técnico.
Passo a passo para desativar o editor de arquivos
O processo é curto. O cuidado está em aplicar no lugar certo.
- Acesse os arquivos do site pela hospedagem, SFTP ou SSH.
- Localize o arquivo
wp-config.phpna raiz do WordPress. - Faça uma cópia do arquivo antes de editar.
- Abra o arquivo em um editor de texto simples.
- Insira a constante abaixo antes da linha que diz que a edição deve parar e o WordPress deve ser carregado.
define('DISALLOW_FILE_EDIT', true);
Em muitas instalações, a linha de referência aparece como comentário antes do carregamento do WordPress. O importante é não colocar a constante depois do final do carregamento, pois ela pode não ser aplicada no momento esperado.
Depois de salvar, envie o arquivo de volta ao servidor se você estiver usando SFTP. Se estiver editando direto no painel da hospedagem, salve e feche.
Não altere outras constantes no mesmo momento. Quando você muda várias coisas de uma vez, fica mais difícil descobrir a causa se algo falhar.
Como validar se o bloqueio funcionou
Depois da alteração, entre no painel do WordPress com uma conta administrativa.
Vá até a área de aparência e plugins. A opção de editor de arquivos não deve aparecer. Dependendo da versão e do idioma do painel, o nome pode variar, mas a ideia é a mesma: a tela de edição direta de arquivos deve ficar indisponível.
Em seguida, faça uma validação simples do site público. Abra a página inicial, uma página interna e um post. Se houver loja, teste também uma página de produto e o carrinho sem finalizar compra real.
Se o site carregar normalmente e o editor sumir do painel, a configuração foi aplicada.
Também vale registrar a mudança em uma rotina de manutenção. Uma anotação simples já ajuda: data, arquivo alterado, linha adicionada e responsável. Para equipes maiores, combine isso com regras de acesso. O guia sobre /guias/permissoes_usuarios_wordpress_seguranca/ ajuda a organizar quem pode fazer o quê no painel.
Como editar arquivos depois dessa mudança
Desativar o editor do painel não impede manutenção técnica. Ele apenas muda o caminho correto.
Para ajustes simples de CSS, prefira o personalizador, o editor do tema quando seguro ou o campo de CSS adicional do WordPress. Para alterações estruturais, use um tema filho, ambiente de teste ou versionamento.
Para código PHP, evite editar o tema ativo diretamente em produção. O caminho mais seguro é testar em ambiente separado, validar erros e só depois publicar.
Se você usa LetsCloud ou outra VPS, uma boa prática é criar um ambiente de teste ou snapshot antes de mexer em arquivos. Assim, uma mudança mal sucedida não depende apenas da memória de quem editou.
Para mudanças de plugins e temas, não misture edição de arquivo com atualização automática sem teste. O guia /guias/atualizar_wordpress_plugins_temas_sem_quebrar_site/ mostra uma rotina mais segura para esse tipo de manutenção.
Erros comuns que podem tirar o site do ar
O erro mais comum é inserir a constante com aspas erradas copiadas de algum editor visual. Use aspas simples ou duplas normais. Evite colar a partir de documentos formatados.
Outro erro é deixar espaço, caractere invisível ou texto antes da abertura do PHP em arquivos que não deveriam ter isso. Se o site exibir tela branca ou mensagem de cabeçalho já enviado, volte para a cópia anterior do arquivo.
Também acontece de a pessoa editar o wp-config.php errado. Isso é comum quando há mais de uma instalação no servidor, por exemplo um site principal e um WordPress em /blog.
Há ainda o risco de acreditar que essa configuração basta. Não basta. Se todos usam a mesma conta administrativa, se não há autenticação de dois fatores e se o login está exposto a tentativas repetidas, o site continua frágil. Para reforçar esse ponto, veja o guia sobre /guias/proteger_login_wordpress/.
Por fim, não use essa mudança como desculpa para dar perfil de administrador a quem só publica conteúdo. Bloquear o editor ajuda, mas o princípio continua o mesmo: cada pessoa deve ter apenas o acesso necessário.
Checklist final de segurança
Antes de considerar o trabalho concluído, confira:
- Backup recente feito e testado quando possível.
- Acesso aos arquivos confirmado fora do painel do WordPress.
- Constante
DISALLOW_FILE_EDITadicionada aowp-config.php. - Painel revisado para confirmar que o editor sumiu.
- Site público testado em páginas principais.
- Usuários administrativos revisados.
- Mudança registrada em checklist de manutenção.
Se o site é importante para vendas, atendimento ou captação de contatos, faça essa alteração em horário de menor movimento. Não precisa transformar uma tarefa simples em projeto grande. Mas também não vale alterar arquivo crítico sem plano de volta.
Perguntas frequentes
Desativar o editor de arquivos melhora a segurança do WordPress?
Sim, melhora um ponto específico. A medida reduz a chance de alterações diretas em arquivos pelo painel. Ela não garante segurança total e deve ser combinada com backup, senhas fortes, autenticação de dois fatores, permissões corretas e atualização responsável.
Posso fazer isso sem acesso SFTP ou SSH?
Pode, se sua hospedagem oferece gerenciador de arquivos confiável. Mesmo assim, tenha cuidado. Se você errar o wp-config.php e perder acesso ao site, precisará de algum caminho para restaurar o arquivo anterior.
Essa configuração impede atualização de plugins e temas?
Não. A constante DISALLOW_FILE_EDIT bloqueia a edição direta de arquivos pelo painel. Ela não é a mesma coisa que bloquear instalação ou atualização. Ainda assim, atualizações devem seguir uma rotina com backup e teste.
Preciso de plugin para desativar o editor de arquivos?
Não necessariamente. A configuração no wp-config.php é direta e evita instalar mais um plugin apenas para isso. Alguns plugins de segurança também oferecem essa opção, mas você deve entender o que foi alterado para não depender de uma tela sem saber onde a regra está aplicada.
Próximo passo recomendado
Depois de bloquear o editor de arquivos, revise as contas administrativas. Essa é a continuação natural da proteção. Comece por /guias/permissoes_usuarios_wordpress_seguranca/ e, em seguida, avalie autenticação de dois fatores para reduzir risco de acesso indevido.
