gutenberg wordpress

Fase 1 do projeto Gutenberg: O editor de Blocos

Lançado oficialmente no WordPress 5.0, em dezembro de 2018, o Projeto Gutenberg (Fase 1) marcou a maior e mais controversa mudança na experiência de criação de conteúdo do WordPress desde o seu início.

O projeto tinha como missão audaciosa modernizar a plataforma para o futuro digital. A Fase 1 concentrou-se inteiramente na substituição do antigo editor visual (TinyMCE, ou Editor Clássico) por uma nova experiência baseada em blocos.

O principal objetivo de Gutenberg era claro: capacitar os usuários a criar layouts ricos e complexos sem a necessidade de manipular código HTML, shortcodes ou depender de Page Builders de terceiros.

editor blocos

O “Porquê” por trás da Mudança Radical

A motivação para o Gutenberg foi apresentada pelo cofundador do WordPress, Matt Mullenweg no WordCamp Europe 2017. Para ele, o projeto era vital para que o WordPress pudesse “superar seus concorrentes”, como o Medium e plataformas de construção de sites mais visuais.

Em essência, a Fase 1 buscava resolver três problemas centrais que o Editor Clássico não conseguia lidar:

  1. Unificação de Conteúdo: O Classic Editor exigia que o usuário alternasse constantemente para o modo HTML para corrigir quebras de linha e manipulação de shortcodes. O Gutenberg visava acabar com essa dependência de shortcodes e padronizar a forma como plugins e temas adicionam funcionalidade ao conteúdo.
  2. Layout sem Código: Permitir que usuários casuais criassem estruturas complexas (colunas, botões, galerias) com facilidade.
  3. Experiência Visual: Aproximar a experiência de edição (backend) do resultado final publicado (frontend).

A Essência do Bloco: A Base da Fase 1

O conceito central da Fase 1 é o bloco. No Editor de Blocos, cada elemento do conteúdo é um objeto manipulável. O editor se posicionou no “ponto ideal” de flexibilidade: mais visual e poderoso do que o TinyMCE Clássico, mas mais leve e com código mais limpo do que a maioria dos Page Builders.

Essa mudança deu início à transformação do WordPress de uma simples plataforma de blogs para um framework de construção de sites.

Costumo falar muito em palestras (até hoje) que devemos nos acostumar a chamar o agora editor nativo de Editor de Blocos, e não de Gutenberg, para evitar confusão na cabeça dos usuários mais leigos que podem acabar pensando que ainda precisam instalar um plugin para ter blocos, quando isso já é nativo do sistema. O plugin Gutenberg segue existindo, mas agora como um ambiente que serve de base para lançar os novos blocos e testá-los arduamente antes de os inserir oficialmente numa futura e nova versão do WordPress… então deixemos para usar em nossos sites quando estiverem maduros, e não através de um plugin que serve para testes (e pode apresentar problemas devido a isso).

“O Desastre Gutenberg”: A Controvérsia no Lançamento

Apesar do potencial, o lançamento do Gutenberg foi o momento mais divisivo na história do WordPress. A comunidade se dividiu entre a visão de “futuro necessário” e a de um “desastre” imposto pela liderança.

Críticas e Preocupações Técnicas:

  • Quebra de Retrocompatibilidade: O maior temor da comunidade de desenvolvimento era o impacto em milhões de sites existentes. A dependência de recursos antigos, como Meta Boxes e custom fields avançados (usados por plugins como Yoast SEO e ACF), foi ignorada inicialmente, gerando a preocupação de que a fusão “quebraria muita coisa”.
  • Armazenamento de Dados (A “Gambiarra”): A decisão de armazenar os dados dos blocos no campo post_content como HTML com comentários inseridos (“), em vez de uma estrutura de dados dedicada (JSON), foi amplamente criticada como uma solução técnica falha. Isso, para muitos, garantiu que os problemas estruturais de conteúdo do WordPress persistiriam.
  • Sentimento de imposição: Muitos não concordavam com um novo editor ainda com problemas, ainda “verde”, fosse colocado como o editor oficial do WordPress e defendiam que ele continuasse como um plugin opcional por mais tempo, tendo mais tempo de se preparar para uma mudança grandiosa não só na parte técnica mas esperando melhorias na usabilidade dos blocos (que falaremos a seguir).
  • Desvio de Rota Unilateral: O ceticismo atingiu o pico quando o projeto foi visto como um desvio da filosofia open-source democrática do WordPress. Para críticos, a mudança foi forçada pelo Matt para atender a uma necessidade comercial de sua empresa competir com modelos fechados de plataformas como Squarespace e Wix, negligenciando a base de usuários profissionais e desenvolvedores.

Usabilidade e Resistência Comunitária:

  • UX Confuso: Naquele momento da fase 1, o novo editor foi frequentemente descrito como lento, menos eficiente e confuso, tanto para iniciantes quanto para usuários experientes. A experiência de seleção de blocos aninhados e a detecção complexa de cliques foram problemas recorrentes que demoraram a ser corrigidos.
  • Resistência Persistente: O descontentamento com a nova interface foi tão generalizado que levou à criação e adoção maciça de plugins oficiais para restaurar a experiência de edição tradicional (e passaram a chamar esta interface anterior de Editor Clássico). Isso indicava uma profunda rejeição inicial de uma parte significativa da base de usuários, que avaliou o editor de blocos de forma majoritariamente negativa.
  • Curva de Aprendizagem: Muitos usuários se sentiram “confusos e ligeiramente perplexos” com a nova interface, percebendo que a promessa de ser “como o Word” não se concretizou imediatamente, exigindo um processo de adaptação (onboarding).

O Legado da Fase 1

Apesar da turbulência, a Fase 1 foi um ponto de não-retorno. O lançamento forçado garantiu a adesão, e o projeto evoluiu rapidamente com o feedback da comunidade.

  • Novo Ecossistema: O modelo de blocos estimulou uma nova geração de plugins e temas que se integram nativamente à experiência de edição.
  • Superação da Curva de Aprendizagem: Embora difícil no início, muitos usuários que persistiram descobriram que, para a criação de conteúdo estruturado, o Gutenberg se tornou uma ferramenta superior ao Editor Clássico. Embora encontre resistência até hoje, é inegável que é mais simples criar seções mais complexas, como colunas, no editor de blocos.

O Editor de Blocos é a fundação da visão de futuro do WordPress.

A Fase 1 estabeleceu o princípio do bloco, abrindo caminho para as fases seguintes, que visam estender o poder dos blocos ao design de todo o site, culminando no Full Site Editing (FSE).

A partir daqui, o WordPress visava deixar para trás a imagem de ser apenas uma ferramenta de blogs e se tornar um construtor visual nativo… o que se mostrou um longo caminho a começar a ser mais real.

Conclusão: O Legado dos Bloco

A Fase 1 do Projeto Gutenberg foi, inegavelmente, um momento de dor do crescimento para o WordPress. Não foi apenas uma atualização de editor; foi uma ruptura fundamental com o passado, implementada em meio a intensa controvérsia e resistência massiva.

Apesar das críticas válidas sobre a arquitetura de dados e a usabilidade inicial – que exigiram a criação de ferramentas de reversão e geraram anos de debate – o projeto atingiu seu objetivo primário: modernizar o WordPress. Ao estabelecer o princípio do bloco, o Gutenberg transformou o CMS de uma ferramenta focada em blogs para um verdadeiro framework de construção visual.

Falando das críticas, eu concordo muito com os que acharam o lançamento prematuro e sofri na pele isso, pois, trabalhando no WordPress.com nesse período, fomos a primeira equipe do mundo a prestar suporte para a ferramenta, e mesmo pessoas experientes no WordPress sentiam dificuldade clara para utilizar e aprender um editor que ainda apresentava diversos problemas de usabilidade, alguns que só foram realmente resolvidos durante a fase 2 do projeto.

A Fase 1 foi o preço de entrada para a próxima era. Ela forçou o ecossistema a evoluir, deu aos usuários mais controle de design do que nunca (e, é claro, note que estou falando das funções nativas do WordPress, e não comparando com seu plugin pagebuilder favorito) e pavimentou o caminho para as ambições futuras do Full Site Editing (FSE).

O veredito final? O Gutenberg pode não ter sido a atualização que todos queriam, mas foi a revolução que o WordPress precisava para se manter relevante na web moderna. Não feita da forma certa e com muitas críticas válidas, mas ainda assim melhorias eram necessárias e o caminho escolhido pode não ter sido o melhor, mas foi melhor do que ficar parado no tempo vendo outras plataformas ficarem melhores.

E, gostemos ou não, o bloco veio para ficar. Eu já me acostumei com eles, mas sigo vendo pontos de melhorias… mas isso sempre teremos né?

Posts Similares

  • WordPress 7.0: O que esperar da próxima versão?
    |

    WordPress 7.0: O que esperar da próxima versão?

    Se você acompanha o ecossistema WordPress há algum tempo, sabe que o ciclo de lançamentos é constante. Mal nos acostumamos com as novidades da série 6.x, e a comunidade de desenvolvimento (Core Team) já começou oficialmente a traçar o caminho para o WordPress 7.0. Com base nas recentes discussões no canal Make WordPress Core e…

  • Migração WordPress – Importando arquivos XML maiores que 2 Mb

    Nosso querido WordPress tem uma conhecida função no painel administrativo que nos permite exportar todo o conteúdo criado em nosso blog para um arquivo XML, para assim permitir que importemos tais dados em uma nova instalação de nosso blog (normalmente usado na hora da migração de servidor). Tal função funciona muito  bem se vocês estiver…

  • Plugins de SEO para WordPress: Análise dos 3 melhores da atualidade

    Qual é o melhor plugin de SEO para WordPress? Essa é uma pergunta que me fazem com frequência. Participei recentemente de um debate sobre qual plugin seria o melhor, e decidi elaborar uma lista comparando a características dos três plugins de SEO mais populares (em termos de downloads) para oferecer uma melhor compreensão do que…

  • Taxonomias personalizadas no WordPress: Como utilizar?

    Em geral,  taxonomias (do grego tassein = “para classificar” ) são utilizadas para classificar e organizar coisas referentes a um mesmo grupo. Por padrão, taxonomias no WordPress são tags e categorias que o WordPress está usando para os posts. Além destes dois, o WordPress permite que desenvolvedores criem suas próprias taxonomias ao desenvolver um tema, utilizando funções para…

  • Como colocar Gravatar nos comentários do WordPress 2.7

    Como vi que algumas pessoas tem chegado ao blog através de buscas, tentando descobrir como adicionar as imagens de Gravatar ao seu blog WordPress, resolvi escrever esta dica. Pra começo de conversa, o Gravatar só irá aparecer em seu site se este estiver corretamente configurado para isso. Para tal, vá em wp-admin -> Configurações ->…

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *