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

  • TudoParaWordPress no SearchLabs 2010 – Colabore com a palestra !

    TudoParaWordPress no SearchLabs 2010 – Colabore com a palestra !

    Como alguns já devem saber, fui convidado para palestrar no SearchLabs 2010, sobre o tema SEO para WordPress, graças ao grande sucesso deste blog (que jamais aconteceria sem as visitas, comentários e apoio de vocês) e a palestra de Seo para WordPress ministrada no BlogCamp RJ 2009 em parceria com o amigo @PabloAlmeida. A palestra…

  • Utilizando o operador de módulo no loop

    Na maior parte das linguagens de programação existe um operador específico, por vezes esquecido pelos programadores, para operações de módulo. Seu símbolo, na maioria das linguagens, é a % (o que pode causar alguma confusão para os novatos). O PHP não foge à regra e também possui este operador de módulo, sendo o seu símbolo…

  • Como excluir as páginas do resultado de busca ?

    Uma maneira de se excluir as páginas do resultado de busca é usar o plugin Search Exclude. Entretanto, como sou adepto da filosofia “Quanto menos plugins melhor”, outra solução interessante é adicionar um filtro no functions.php que adicione na busca apenas as categorias desejadas, excluindo assim todo o restante:

  • Diferença entre WordPress.org e WordPress.com

    Toda vez que dou uma palestra em algum canto do Brasil falando sobre WordPress e os benefícios de se usar esta fantástica ferramenta de gerenciamento de conteúdo para gerenciar seu site/blog, busco deixar clara a diferença entre os dois modelos disponíveis para o uso do WordPress: WordPress.org e WordPress.com. Sobre o WordPress.org Quando ministro tais…

  • Shortcode do ACF

    Shortcode do ACF

    O Shortcode do ACF pode ser utilizado em sua postagem para exibir o valor de um campo personalizado simples, como o de texto. Se você não sabe o que é um shortcode, recomendamos a leitura da documentação oficial do WordPress, no Codex. Requisitos ACF v3.1.1 ou superior Como Utilizar Place the shortcode marker with the desired field within your…

  • Segurança: Alterando o prefixo do Banco de Dados do WordPress

    Uma das coisas incríveis do WordPress é que ele é um sistema de publicação dinâmica, que utiliza um banco de dados para armazenar informações de seu site: posts, opções e configurações de plugins e temas – todos estes dados são armazenados no banco de dados do seu site. É como se fosse cérebro da sua…

Deixe um comentário

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