Como Usar o Editor Clássico no WordPress: Instalação, Configuração e Quando Realmente Faz Sentido

O WordPress Classic Editor é um editor de conteúdo WYSIWYG baseado em TinyMCE que antecede o sistema de blocos Gutenberg introduzido no WordPress 5.0. Apresenta uma tela de edição única e linear — visualmente semelhante ao Microsoft Word — onde texto, mídia e HTML coexistem num campo contínuo em vez de blocos discretos e empilháveis. Para utilizadores que precisam de o instalar hoje, a resposta curta é: instale o plugin oficial Classic Editor do repositório de plugins do WordPress, ative-o e configure o editor padrão em Definições > Escrita.

Essa resposta de duas frases cobre a questão principal. O restante deste guia aborda as diferenças arquitetónicas entre os dois editores, as razões técnicas legítimas para escolher um em detrimento do outro, casos extremos de configuração e os cenários em que forçar o Classic Editor cria mais problemas do que resolve.

Classic Editor vs. Editor de Blocos Gutenberg: Uma Comparação Técnica

Antes de alterar qualquer definição, vale a pena compreender entre o que está realmente a alternar. A decisão não é puramente cosmética.

A diferença operacionalmente mais significativa é o armazenamento de conteúdo. O Classic Editor guarda HTML limpo. O Gutenberg envolve cada unidade de conteúdo em anotações de comentários HTML que funcionam como delimitadores de blocos. Se alguma vez migrar conteúdo entre sistemas — para um CMS headless, um gerador de sites estáticos ou uma plataforma não-WordPress — o output do Classic Editor é muito mais fácil de analisar e portar. A gramática de blocos do Gutenberg é proprietária do parser do WordPress.

Por Que Razão Programadores e Proprietários de Sites Ainda Escolhem o Classic Editor

Compatibilidade com Plugins e Temas Legados

Muitos plugins comerciais — particularmente construtores de formulários mais antigos, extensões de e-commerce e plugins de tipos de post personalizados — registam meta boxes que injetam campos diretamente no ecrã de edição de posts. No Gutenberg, estes meta boxes são relegados para um painel lateral recolhível renderizado dentro de um shim de compatibilidade em iframe. Este shim nem sempre se comporta corretamente: surgem conflitos de JavaScript, a lógica condicional falha e alguns frameworks de UI de meta boxes (como os diálogos jQuery UI, por exemplo) não inicializam corretamente dentro do contexto de documento aninhado.

Se o seu site depende de plugins que utilizam add_meta_box() com UIs complexas dependentes de JavaScript, o Classic Editor elimina toda esta classe de problemas.

Restrições da REST API

O editor Gutenberg faz pedidos contínuos em segundo plano à REST API do WordPress — para obter padrões de blocos, guardar automaticamente rascunhos, recuperar o estado de bloqueio de posts e validar permissões de utilizadores. Em ambientes de servidor reforçados onde a REST API é intencionalmente restringida (via add_filter('rest_authentication_errors', ...) ou regras ao nível do servidor que bloqueiam /wp-json/), o Gutenberg falhará parcial ou completamente ao carregar. O Classic Editor não tem tal dependência e funcionará normalmente sob estas restrições.

Controlo de Editor por Função em Multisite

Em instalações WordPress Multisite, os administradores de rede precisam por vezes de impor uma experiência de edição consistente em todos os subsites — particularmente quando estão envolvidos editores não técnicos. O plugin Classic Editor suporta uma opção Settings > Writing para não permitir a alternância de editor por utilizador, bloqueando todos os utilizadores no Classic Editor independentemente das suas preferências individuais. O Gutenberg não oferece nenhum mecanismo equivalente de imposição ao nível da rede sem código personalizado.

Velocidade de Fluxo de Trabalho para Conteúdo com Muito Texto

Para editores que produzem grandes volumes de conteúdo textual — artigos de notícias, documentação, processos legais — o modelo de tela única do Classic Editor é genuinamente mais rápido. Não é necessário inserir um novo bloco, selecionar um tipo de bloco ou navegar entre painéis de definições de blocos. Pressiona Enter e continua a escrever. Para editores que trabalham com o teclado e utilizam atalhos do separador HTML, isto é relevante.

Como Instalar o Plugin Classic Editor

O Classic Editor não está incluído no núcleo do WordPress. É mantido como um plugin oficial pela equipa de Colaboradores do WordPress e está disponível no repositório de plugins do WordPress.org.

Método 1: Instalar através do Painel do WordPress

1. Inicie sessão no seu painel de administração do WordPress (/wp-admin).
2. Navegue até Plugins > Adicionar Novo Plugin.
3. No campo de pesquisa, escreva Classic Editor.
4. Localize o plugin criado pelos WordPress Contributors — verifique o autor, pois existem plugins imitadores com nomes semelhantes.
5. Clique em Instalar Agora e depois em Ativar.

Método 2: Instalar via WP-CLI

Se gerir o WordPress a partir da linha de comandos — o que é prática padrão em qualquer ambiente de Alojamento VPS — o WP-CLI é significativamente mais rápido do que a UI do painel:

wp plugin install classic-editor --activate

Para instalá-lo em toda a rede numa instalação Multisite:

wp plugin install classic-editor --activate-network

Método 3: Upload Manual

Descarregue o ZIP do plugin em wordpress.org/plugins/classic-editor e faça o upload através de Plugins > Adicionar Novo Plugin > Carregar Plugin, ou extraia-o diretamente para o seu servidor:

cd /var/www/html/wp-content/plugins/
unzip classic-editor.zip

Após a extração, ative via WP-CLI ou pelo painel.

Configurar as Definições do Classic Editor

Uma vez ativado, o plugin expõe duas opções de configuração em Definições > Escrita.

Editor Padrão para Todos os Utilizadores

A primeira opção define o padrão para todo o site. Pode escolher entre o Classic Editor e o Editor de Blocos. Definir isto para Classic Editor significa que cada novo post e página abre no TinyMCE por padrão.

Permitir que os Utilizadores Alternem Editores

A segunda opção controla se os utilizadores individuais podem substituir o padrão do site por post. Quando ativada, ao passar o cursor sobre um post na lista Posts > Todos os Posts são reveladas duas ligações de ação: Editar (abre no padrão do site) e Editar (Classic Editor) ou Editar (Editor de Blocos) dependendo do padrão atual.

Configuração recomendada para a maioria dos sites legados:

• Editor padrão: Classic Editor
• Permitir que os utilizadores alternem: Não

Isto impede que os editores abram acidentalmente conteúdo no Gutenberg e injetem inadvertidamente comentários de gramática de blocos em posts que foram criados no Classic Editor — uma mistura que pode causar anomalias de renderização em alguns temas.

Utilizar a Interface do Classic Editor

O Separador Visual (Modo WYSIWYG)

O separador Visual renderiza o seu conteúdo através da pré-visualização baseada em iframe do TinyMCE. A barra de ferramentas fornece:

• Formatação de texto: Negrito (Ctrl+B), Itálico (Ctrl+I), Rasurado, Sublinhado
• Estilos de parágrafo: Título 1 a Título 6, Pré-formatado, Citação em bloco
• Listas: Ordenadas e não ordenadas, com controlos de avanço/recuo
• Ligações: Inserir/editar hiperligações com atributos de destino e título
• Inserção de média: Abre a Biblioteca de Média do WordPress para imagens, vídeo, áudio e documentos
• Colar do Word: Remove a marcação HTML proprietária do Microsoft Word ao colar
• Modo de escrita sem distrações: Alternância de ecrã completo que oculta toda a UI de administração

A barra de ferramentas tem duas linhas. Se apenas vir uma linha, clique no botão Alternar Barra de Ferramentas (o último ícone na primeira linha) para revelar a segunda linha, que inclui o seletor de estilo de parágrafo, cor do texto, mapa de caracteres e desfazer/refazer.

O Separador Texto (Modo HTML Puro)

O separador Texto expõe o HTML puro armazenado em post_content. Este não é um editor de código completo — não tem realce de sintaxe nem numeração de linhas — mas dá-lhe acesso direto à marcação. Cenários úteis:

• Inserir embeds <iframe> puros que o TinyMCE removeria ou escaparia
• Adicionar atributos HTML personalizados que a UI do separador Visual não expõe
• Depurar problemas de renderização causados pela limpeza automática de tags do TinyMCE

Comportamento crítico a compreender: O TinyMCE realiza sanitização de HTML quando muda do separador Texto de volta para o separador Visual. Fechará tags não fechadas, removerá certos elementos (como <script> em algumas configurações) e normalizará espaços em branco. Se escrever HTML puro no separador Texto, verifique sempre se sobrevive a uma ida e volta ao Visual antes de publicar.

Os Meta Boxes de Excerto, Campos Personalizados e Discussão

Abaixo da tela principal do editor, o Classic Editor apresenta o conjunto completo de meta boxes nativos do WordPress no seu layout original:

• Excerto: Resumo em texto simples utilizado por temas e plugins de SEO para meta descrições
• Campos Personalizados: Pares chave-valor armazenados em wp_postmeta — acessíveis diretamente sem mudar para um painel lateral
• Discussão: Definições de comentários e trackback por post
• Slug: Campo de slug de URL editável (também na caixa Publicar)
• Autor: Reatribuir a autoria do post sem navegar para outro local

Estes meta boxes estão sempre visíveis e a largura total no Classic Editor. No Gutenberg, estão ocultos na barra lateral ou renderizados no iframe de compatibilidade — uma diferença de UX significativa para fluxos de trabalho que dependem muito de campos personalizados.

Alternar Entre Editores por Post

Se ativou a opção “Permitir que os utilizadores alternem”, o alternador de editor por post funciona da seguinte forma:

A partir da lista de posts:

1. Vá a Posts > Todos os Posts.
2. Passe o cursor sobre o título do post.
3. Clique em Editar (Classic Editor) ou Editar (Editor de Blocos) conforme necessário.

A partir do interior do editor:

No Gutenberg, uma ligação com o texto Mudar para Classic Editor aparece no menu de três pontos (canto superior direito). No Classic Editor, uma ligação com o texto Mudar para Editor de Blocos aparece perto do topo do ecrã.

Aviso: Mudar um post que foi criado no Gutenberg para o Classic Editor — e depois guardá-lo — preservará as anotações de comentários de gramática de blocos no HTML puro. Estes comentários são inofensivos para a renderização no front-end, mas aparecerão como texto literal no separador Texto do Classic Editor, o que pode ser confuso. Mudar de volta para o Gutenberg irá analisá-los corretamente. O cenário inverso (conteúdo do Classic Editor aberto no Gutenberg) é limpo, uma vez que o Gutenberg envolve HTML não reconhecido num bloco Clássico automaticamente.

Desativar o Classic Editor Sem o Plugin

Se quiser forçar o Gutenberg e impedir que o Classic Editor seja utilizado — ou se quiser desativar o Gutenberg sem instalar um plugin — o WordPress fornece um filtro hook:

// In functions.php or a site-specific plugin — disable Gutenberg for all post types
add_filter( 'use_block_editor_for_post', '__return_false' );

Isto alcança o mesmo efeito que o plugin Classic Editor para edição de posts, mas não afeta o Editor de Site (Edição de Site Completo). Para uma desativação completa do Gutenberg incluindo FSE:

add_filter( 'use_block_editor_for_post', '__return_false' );
add_filter( 'use_widgets_block_editor', '__return_false' );
remove_theme_support( 'widgets-block-editor' );

Esta abordagem é preferível em ambientes onde a instalação de plugins adicionais é restringida por política, ou onde se pretende que a lógica de desativação seja controlada por versão no seu tema ou plugin em vez de depender do estado de ativação de um plugin de terceiros.

Classic Editor e Ambientes de Alojamento WordPress

O plugin Classic Editor em si é leve e não impõe requisitos significativos do lado do servidor. No entanto, o contexto mais amplo do seu ambiente de alojamento afeta a experiência de edição de formas que vale a pena notar.

Em planos de alojamento partilhado, o painel de administração do WordPress pode parecer lento porque a execução de PHP e as consultas à base de dados competem com outros inquilinos no mesmo servidor. O Classic Editor é mensuravelmente mais leve do que o Gutenberg neste contexto — menos chamadas à REST API, sem sobrecarga de renderização React e um payload JavaScript menor significam carregamentos de página mais rápidos no admin. Se estiver num plano de Alojamento Web Partilhado e achar o editor de blocos lento, o Classic Editor é uma otimização prática.

Num VPS com cPanel, tem controlo total sobre os limites de memória PHP, configuração de OPcache e cache de consultas MySQL. Neste ambiente, ambos os editores têm bom desempenho, e a escolha torna-se puramente uma preferência de fluxo de trabalho em vez de uma necessidade de desempenho.

Para instalações WordPress de alto tráfego em Servidores Dedicados, a escolha do editor tem essencialmente zero impacto no desempenho do front-end — a interface de edição é apenas carregada por utilizadores admin autenticados, e o output HTML publicado é o que importa para a velocidade da página.

Armadilhas Comuns e Casos Extremos

TinyMCE a remover HTML válido: A configuração valid_elements e extended_valid_elements do TinyMCE controla quais as tags e atributos HTML permitidos no editor Visual. Por padrão, remove tags como <article>, <section>, <figure> (em configurações mais antigas) e quaisquer atributos de dados personalizados. Se o seu conteúdo requer estes, deve estender os elementos permitidos do TinyMCE através do filtro tiny_mce_before_init:

add_filter( 'tiny_mce_before_init', function( $init ) {
    $init['extended_valid_elements'] = 'span[*],div[*],section[*],article[*]';
    return $init;
} );

Conflitos de gravação automática: O Classic Editor utiliza a função JavaScript wp_autosave() mais antiga, que envia pedidos POST para wp-admin/post.php com action=autosave. Se o seu servidor tiver limitação de taxa agressiva ou uma regra WAF que bloqueie pedidos POST repetidos para wp-admin, as gravações automáticas falharão silenciosamente. Monitorize os registos de erros do seu servidor se ocorrer perda de conteúdo.

Classic Editor e temas de Edição de Site Completo (FSE): Se o seu tema ativo for um tema FSE (que declara "blockTemplates": true em theme.json), o Classic Editor ainda funcionará para conteúdo de posts e páginas, mas o Editor de Site (/wp-admin/site-editor.php) é inteiramente baseado em Gutenberg e não é afetado pelo plugin Classic Editor. Não pode utilizar o Classic Editor para editar modelos de temas FSE.

Comportamento de desativação do plugin: Desativar o plugin Classic Editor não converte o seu conteúdo. Os posts criados no Classic Editor permanecem como HTML limpo. Os posts criados no Gutenberg retêm a sua gramática de blocos. O Gutenberg analisará ambos corretamente. Não há risco de perda de dados ao desativar o plugin.

Matriz de Decisão: Qual Editor Deve Utilizar?

Utilize o Classic Editor se:

• O seu site utiliza plugins com UIs de meta box complexas que falham na camada de compatibilidade do Gutenberg
• O seu servidor restringe a REST API do WordPress
• Está a migrar conteúdo para uma plataforma não-WordPress e precisa de HTML limpo e portátil
• A sua equipa editorial é grande, não técnica e treinada no fluxo de trabalho do Classic Editor
• Está a executar o WordPress num ambiente de alojamento partilhado com recursos limitados

Utilize o Gutenberg se:

• Está a construir novos sites sem dependências de plugins legados
• O seu tema é baseado em blocos ou compatível com FSE
• Precisa de blocos reutilizáveis, padrões de blocos ou layouts complexos de múltiplas colunas sem um construtor de páginas
• Está a construir blocos personalizados com register_block_type() para projetos de clientes
• Quer aproveitar o Editor de Site para personalização completa do tema

Utilize ambos (com alternância por utilizador ativada) se:

• Tem uma equipa mista onde alguns editores preferem o Classic e outros preferem o Gutenberg
• Está num período de transição a migrar um site legado para uma arquitetura baseada em blocos
• Diferentes tipos de post no seu site têm requisitos de complexidade diferentes

Lista de Verificação Técnica Prática

Antes de mudar o seu site de produção para o Classic Editor, verifique o seguinte:

• ] Confirme que a versão do plugin Classic Editor está atualizada (verifique [wordpress.org/plugins/classic-editor para a versão mais recente)
• [ ] Teste todas as UIs de meta box dos plugins ativos no Classic Editor num ambiente de teste antes de implementar em produção
• [ ] Reveja os seus filtros tiny_mce_before_init se tiver configurações TinyMCE personalizadas que possam entrar em conflito com os padrões do plugin
• [ ] Decida a política de “permitir alternância” e documente-a para a sua equipa editorial
• [ ] Se utilizar WP-CLI, confirme que o plugin está ativado com wp plugin list --status=active
• [ ] Verifique se o seu tema não depende de estilos de blocos específicos do Gutenberg (classes CSS wp-block-*) para renderização no front-end
• [ ] Faça uma cópia de segurança da sua base de dados antes de fazer quaisquer alterações de alternância de editor num site com conteúdo Gutenberg existente
• [ ] Se estiver numa rede Multisite, decida se ativa em toda a rede ou por site e imponha via Settings > Writing ao nível da rede

Complete a configuração do seu WordPress com um domínio devidamente protegido, garantindo que os seus Certificados SSL são válidos e se renovam automaticamente — o painel de administração do WordPress transmite cookies de autenticação que devem ser protegidos por HTTPS independentemente do editor que utilizar.

Para equipas que gerem fluxos de trabalho editoriais que incluem notificações por email, comunicações com autores ou integrações de newsletters, uma configuração dedicada de Alojamento de Email garante que os emails transacionais do WordPress (reposições de palavra-passe, notificações de comentários, alterações de estado de posts) são entregues de forma fiável em vez de serem encaminhados através do sendmail padrão de um servidor partilhado.

FAQ

O plugin Classic Editor afeta a renderização no front-end ou o desempenho do site?

Não. O plugin Classic Editor apenas modifica a interface de edição do lado do admin. Não tem qualquer impacto na forma como o WordPress renderiza páginas para os visitantes. O desempenho do front-end é determinado pelo seu tema, camada de cache e configuração do servidor — não pelo editor que foi utilizado para escrever o conteúdo.

Mudar do Gutenberg para o Classic Editor irá corromper o meu conteúdo existente baseado em blocos?

Não. O Gutenberg armazena anotações de blocos como comentários HTML dentro de post_content. O Classic Editor exibirá este HTML puro no seu separador Texto e tentará renderizá-lo no separador Visual. O conteúdo não é eliminado nem corrompido. Se guardar um post do Gutenberg no Classic Editor sem o editar, as anotações de blocos são preservadas. Se editar e guardar, o TinyMCE pode normalizar alguns espaços em branco, mas não removerá as anotações de comentários.

Posso utilizar o Classic Editor para alguns tipos de post e o Gutenberg para outros?

Sim, mas não através da UI de definições do plugin Classic Editor. Precisa de utilizar o filtro use_block_editor_for_post_type no código:

add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
    if ( $post_type === 'product' ) {
        return false; // Use Classic Editor for WooCommerce products
    }
    return $use_block_editor;
}, 10, 2 );

O plugin Classic Editor vai ser mantido permanentemente?

O WordPress.org comprometeu-se a manter o plugin Classic Editor com atualizações de segurança e compatibilidade até pelo menos 2024, e continua a receber atualizações para além desse compromisso. No entanto, não recebe novas funcionalidades — está em modo de manutenção. Para novos projetos a longo prazo, o Gutenberg é a direção estratégica do núcleo do WordPress.

O Classic Editor funciona com o WooCommerce?

Sim. O editor de produtos do WooCommerce foi historicamente construído sobre meta boxes do Classic Editor. Versões recentes do WooCommerce (8.x+) introduziram um novo editor de produtos construído sobre blocos, mas o formulário de produto legado baseado no Classic Editor permanece disponível e é o padrão para a maioria das instalações. O plugin Classic Editor não interfere com os ecrãs de edição de produtos do WooCommerce.