WordPress 4.9 em retrospetiva: a versão anterior ao Gutenberg

O WordPress 4.9 “Tipton” (lançado em 2017) foi uma versão especial. Foi a última grande versão antes do WordPress 5.0, que tornou o Gutenberg o editor predefinido.

Saiba mais sobre os serviços de desenvolvimento WordPress da WPPoland.

O WordPress 4.9 importa porque melhorou os fluxos de trabalho reais de editores e programadores mesmo antes de o Gutenberg mudar por completo o modelo de edição. Esta retrospetiva fica pelo que dizem o anúncio oficial, o guia de campo do 4.9 em make.wordpress.org e a página da versão na documentação do WordPress, com ligações para que possa confirmar cada ponto.

#Quando saiu o WordPress 4.9 e quem o liderou

O WordPress 4.9 “Tipton”, assim chamado em homenagem ao músico e chefe de banda de jazz Billy Tipton, foi anunciado a 16 de novembro de 2017 no anúncio oficial. A página da versão na documentação do WordPress data o lançamento de 15 de novembro, que é o mesmo momento visto a partir de um fuso horário dos Estados Unidos. Foi a última grande versão em que o editor clássico era o predefinido.

Segundo o anúncio, a versão foi liderada por Mel Choyce e Weston Ruter. Credita 443 colaboradores, 185 deles pela primeira vez, e saiu totalmente traduzida em 43 línguas. A página da documentação acrescenta dois números úteis quando analisa uma instalação antiga: a versão da base de dados manteve-se em 38590 e a versão corresponde à revisão 42195 do Trac.

O guia de campo do 4.9, publicado antes do lançamento, conta cerca de 400 erros, 181 melhorias, 7 pedidos de funcionalidade e 42 tarefas fechadas no ciclo.

Porque é que o 4.9 importa em retrospetiva:

• foi a última versão com o editor clássico como predefinido,
• trouxe o CodeMirror para o núcleo, e essa biblioteca continua por trás dos campos de código do painel,
• concluiu o trabalho de changesets do Personalizador iniciado no 4.7,
• o próprio anúncio foi escrito no Gutenberg e pedia aos leitores que testassem o novo editor.

#O que mudou no Personalizador do WordPress 4.9

#Rascunhos e alterações agendadas no Personalizador

Pela primeira vez era possível fazer alterações de design (cores, CSS, widgets, menus), guardá-las como rascunho e voltar mais tarde, sem publicar nada.

A base técnica era anterior ao botão. Os changesets, uma forma de guardar alterações pendentes do Personalizador como um artigo do tipo customize_changeset identificado por um UUID, chegaram no WordPress 4.7. Como explica Weston Ruter na nota para programadores sobre changesets no 4.9, o 4.7 não tinha interface para eles. Um changeset ficava num artigo auto-draft que era apagado ao fim de uma semana, a menos que voltasse a mexer nele.

O WordPress 4.9 acrescentou a interface. Depois da primeira alteração aparece um botão com uma roda dentada junto ao botão de publicar, que abre as definições de publicação: publicar, guardar rascunho ou agendar. Uma ligação para ignorar as alterações repõe o Personalizador no último estado publicado.

Antes do 4.9, fazer alterações de design significava:

• editar o site em produção (arriscado),
• usar um ambiente de staging (mais configuração),
• colar CSS à mão (difícil de reverter).

O agendamento funciona porque um changeset entra em produção quando o artigo passa ao estado publish. A nota mostra que o mecanismo já existia antes da interface, com um comando WP-CLI que agenda uma alteração do título do site:

wp post create \
    --post_type=customize_changeset \
    --post_name=$( uuidgen ) \
    --post_status=future \
    --post_date="2018-01-01 00:00:00" \
    --post_content='{"blogname":{"value":"Happy New Year!"}}'

Um aviso prático da mesma nota continua válido. Os changesets agendados são publicados através do WP-Cron, normalmente no minuto seguinte à hora marcada. Num site com poucas visitas o cron pode não correr a tempo, e a nota recomenda uma tarefa cron do sistema que chame wp-cron.php a cada minuto quando a hora exata importa.

#Ligações de pré-visualização para clientes

Pré-visualizar um changeset é uma operação apenas de leitura, por isso qualquer pessoa com o UUID pode ver o site com as alterações pendentes aplicadas, com sessão iniciada ou não. O WordPress 4.9 transformou isto numa ligação de pré-visualização que pode enviar a colegas e clientes. O anúncio apresenta-a como forma de recolher opiniões antes de agendar a publicação, e era assim que as agências a usavam.

#Bloqueio de design e gravação automática no Personalizador

Como um rascunho guardado passou a carregar para qualquer utilizador que abra o Personalizador, duas pessoas podiam sobrepor o trabalho uma da outra. A resposta do 4.9 foi o bloqueio de changesets, inspirado no bloqueio de artigos: um segundo utilizador vê um aviso de bloqueio e pode voltar atrás ou assumir o controlo, e o Personalizador usa o WP Heartbeat para manter o bloqueio ativo.

A gravação automática também melhorou. Se fechasse o navegador por engano, o Personalizador oferecia-se para restaurar o último auto-draft da próxima vez que o abrisse, e as páginas ou artigos criados a partir do Personalizador durante um rascunho apareciam marcados como rascunhos de personalização na lista do administrador.

#Changesets em modo linear e em modo ramificado

O núcleo funciona no que a nota chama modo linear: só pode existir um changeset guardado como rascunho ou agendado de cada vez. Se agendar uma alteração de título para a próxima semana, não pode publicar hoje uma alteração independente da descrição sem ignorar ou publicar ambas. A mudança de tema também fica bloqueada enquanto existir um changeset em rascunho ou agendado.

Os sites com vários utilizadores intensivos do Personalizador podem recuperar o comportamento antigo, em que cada sessão tem o seu próprio changeset, com um filtro:

add_filter( 'customize_changeset_branching', '__return_true' );

#Explorar e mudar de tema no Personalizador

O Personalizador ganhou um novo explorador de temas. O anúncio diz que era possível pesquisar, explorar e pré-visualizar mais de 2600 temas sem sair do Personalizador, com filtros por assunto, funcionalidades e esquema, e o guia de campo nota que pela primeira vez se podiam instalar temas do WordPress.org no mesmo fluxo.

Mudar de tema também se tornou menos destrutivo. A documentação refere um mapeamento por estimativa de menus e widgets (Trac #39692), para que os menus e widgets ficassem mais vezes num sítio razoável no novo tema. O fluxo de criação de menus no Personalizador também foi refeito, com novas instruções para criar um menu e atribuí-lo a uma localização.

#Como o CodeMirror mudou a edição de código no WordPress 4.9

Os editores de código do painel receberam finalmente realce de sintaxe, linting e preenchimento automático. A nota sobre edição de código enumera quatro sítios que receberam o CodeMirror: o CSS adicional no Personalizador, o widget HTML personalizado e os editores de ficheiros de temas e plugins.

Era uma segunda tentativa. O realce de sintaxe nos editores de ficheiros apareceu no WordPress 2.8 com uma biblioteca chamada CodePress e foi retirado no 2.8.1 por problemas de compatibilidade com navegadores. A funcionalidade voltou a ser proposta no ticket #12423 do Trac e demorou oito anos a regressar.

O que o CodeMirror acrescentou no 4.9:

• Realce de sintaxe com modos incluídos como css, htmlmixed, javascript, php, sql, markdown e yaml.
• Fecho automático e correspondência de parênteses, chavetas e etiquetas.
• Linting com CSSLint, JSHint, HTMLHint e JSONLint.
• Preenchimento automático de propriedades CSS, etiquetas HTML e objetos DOM de JavaScript.

Quando um linter encontra um erro, o WordPress pede-lhe que o corrija antes de guardar. No CSS adicional e no widget HTML personalizado não é possível guardar enquanto o código não for válido; nos editores de ficheiros pode ignorar o aviso e guardar na mesma. No 4.7, o CSS adicional só contava chavetas e parênteses retos, o que dava falsos positivos quando uma chaveta estava dentro de um comentário. Essa verificação no servidor foi removida em favor do CSSLint.

Dois pormenores mostram o cuidado com que a mudança foi delimitada. O CodeMirror não foi adicionado ao separador de texto do editor de artigos, por preocupações de acessibilidade para utilizadores de leitores de ecrã e porque o Gutenberg ia substituir esse editor. E cada utilizador ganhou no seu perfil uma opção para desligar o realce de sintaxe.

#Edições PHP protegidas nos editores de temas e plugins

O anúncio resume-o como evitar o temido ecrã branco. O mecanismo, do ticket #21622 do Trac, é uma reversão. Ao guardar um ficheiro PHP no editor de temas ou de plugins, o WordPress guarda uma cópia do conteúdo anterior, escreve a sua alteração e faz um pedido loopback ao ecrã do editor com os seus cookies. Se esse pedido der um erro fatal, o ficheiro anterior é reposto. Caso contrário, um segundo pedido loopback verifica a página inicial. Perante qualquer erro fatal recebe a mensagem e a sua alteração fica no editor para a corrigir. Se os pedidos loopback não conseguirem concluir, a alteração é revertida e é-lhe indicado que use SFTP.

As gravações passam a ser feitas por Ajax, e sair da página com alterações por guardar abre uma caixa de confirmação. Antes do 4.9, o editor de plugins tentava detetar erros fatais desativando e reativando o plugin, o que podia deixar um plugin crítico desligado, e os temas não tinham qualquer proteção.

Os editores também mudaram nos pormenores. A primeira visita mostra um aviso de que editar ficheiros diretamente é arriscado, e o editor de temas remete para o CSS adicional. Passou a ser possível editar mais tipos de ficheiro (entre eles js, json, scss, md, svg e yml), abrir ficheiros a mais de dois diretórios de profundidade, e a lista de ficheiros passou a ser uma árvore expansível.

#Usar o editor de código do WordPress no seu próprio plugin

O CodeMirror no 4.9 é também uma API. A função wp_enqueue_code_editor() aceita um type de ficheiro, um nome de file ou um array de definições codemirror, escolhe valores predefinidos adequados à linguagem e devolve as definições, ou false quando o utilizador desligou o realce de sintaxe. O exemplo da nota transforma o campo de biografia do perfil num editor de HTML:

add_action( 'admin_enqueue_scripts', function() {
	if ( 'profile' !== get_current_screen()->id ) {
		return;
	}

	// Carrega o editor de código e as definições para HTML.
	$settings = wp_enqueue_code_editor( array( 'type' => 'text/html' ) );

	// Termina se o utilizador desligou o CodeMirror.
	if ( false === $settings ) {
		return;
	}

	wp_add_inline_script(
		'code-editor',
		sprintf(
			'jQuery( function() { wp.codeEditor.initialize( "description", %s ); } );',
			wp_json_encode( $settings )
		)
	);
} );

Antes de serem devolvidas, as definições passam pelo filtro wp_code_editor_settings, que pode usar para alterar opções como lineWrapping de forma global. O núcleo regista a biblioteca com o identificador wp-codemirror e expõe-na como wp.CodeMirror em vez de um objeto global CodeMirror, para não entrar em conflito com plugins que trazem a sua própria cópia. No Personalizador, o mesmo editor está disponível como controlo através de WP_Customize_Code_Editor_Control.

#Alterações nos widgets do WordPress 4.9

#Widget de galeria e multimédia no widget de texto

Adicionar galerias de fotografias à barra lateral passou a ser nativo. O widget de galeria seguiu os widgets de imagem e multimédia adicionados no WordPress 4.8, e a documentação regista-o como o ticket #41914 do Trac.

O widget de texto também mudou. Ganhou um botão para adicionar multimédia (imagens, vídeo e áudio) e começou a executar shortcodes. Esse pedido (Trac #10457) estava aberto há mais de oito anos, e significou que plugins e temas deixaram de precisar de add_filter( 'widget_text', 'do_shortcode' ). Os widgets de texto aceitam também oEmbeds, por isso um URL do YouTube colado no widget torna-se um leitor incorporado, e o widget de vídeo passou a lidar com fornecedores além do YouTube e do Vimeo.

No ecrã de widgets do administrador, um novo estado de alterações pendentes indica quando um widget foi guardado e pede confirmação se tentar sair sem guardar.

#Segurança, funções e alterações para programadores no WordPress 4.9

#Novas capacidades e segurança da conta

A página da documentação e o guia de campo registam várias alterações que interessam a quem gere utilizadores:

• as capacidades singulares activate_plugin e deactivate_plugin, verificadas contra um plugin concreto, para que uma função possa ativar uns plugins e outros não,
• capacidades próprias para instalar e atualizar ficheiros de idioma,
• uma ligação de confirmação enviada por email quando um utilizador tenta mudar o seu endereço de email (Trac #16470),
• uma inicialização mais fiável de funções e capacidades quando o código muda de site em multisite, além da nova função get_site_by().

#API JS do Personalizador, MediaElement e remoções

Para programadores, a API JavaScript do Personalizador perdeu muitos pontos de atrito enumerados no guia de campo: parâmetros predefinidos para os construtores, modelos base para controlos, um controlo de data e hora, e notificações a nível global, de painel e de secção. O MediaElement.js foi atualizado para a 4.2.6, que segundo o anúncio remove a dependência do jQuery, melhora a acessibilidade e corrige muitos erros.

Algumas coisas saíram do núcleo. O SWFUpload foi removido e o Press This passou a ser um plugin à parte. A API REST passou a exigir parâmetros com nome nas expressões regulares das rotas, pelo que as correspondências numéricas deixaram de funcionar. A documentação indica ainda que o núcleo e a sua bateria de testes unitários eram totalmente compatíveis com o então próximo PHP 7.2.

#Do WordPress 4.9 ao 5.0 e ao Gutenberg

#Cronologia do WordPress do 4.9 ao 6.x

2017 (4.9):

• Última versão com o editor clássico como predefinido
• Gutenberg em desenvolvimento como plugin, com o anúncio a pedir testadores
• CodeMirror fora do editor de artigos porque o Gutenberg ia substituí-lo

2018 (5.0):

• O Gutenberg foi introduzido como editor predefinido
• O plugin Classic Editor ficou disponível para os sites que queriam manter o ecrã antigo

2019 a 2021:

• O Gutenberg amadureceu a cada atualização
• Os padrões de blocos foram introduzidos
• O Full Site Editing (FSE) começou a ganhar forma

A partir de 2022:

• Temas de blocos e Editor do site no núcleo
• Os temas clássicos e o Personalizador continuam suportados

#Classic Editor e Gutenberg depois do 4.9

Apenas um ano depois do 4.9, o WordPress 5.0 chegou com o Gutenberg. A comunidade dividiu-se em dois campos:

Tradicionalistas:

• Mantiveram o plugin “Classic Editor”
• Continuaram a usar temas baseados em PHP
• Preferiram construtores de páginas (Elementor, Divi, WPBakery)
• O plugin Classic Editor continua a ter milhões de instalações ativas

Criadores modernos:

• Adotaram o modelo de Full Site Editing (FSE)
• Tudo, incluindo cabeçalho e rodapé, construído com blocos
• Adotaram temas de blocos como o Twenty Twenty-Three e o Twenty Twenty-Four
• Tiraram partido dos padrões de blocos e dos modelos

#Que funcionalidades do WordPress 4.9 continuam relevantes

#CodeMirror e rascunhos do Personalizador hoje

CodeMirror:

• Continua a ser usado nos editores de ficheiros de temas e plugins e no CSS adicional
• Continua disponível para plugins através de wp_enqueue_code_editor()

Rascunhos do Personalizador:

• Continuam disponíveis nos temas clássicos que usam o Personalizador
• O agendamento continua a depender do WP-Cron, por isso o conselho sobre cron de 2017 continua válido
• Os temas de blocos usam o Editor do site, com as suas próprias revisões e pré-visualização

Segurança no editor de ficheiros:

• A reversão por loopback do 4.9 continua a ser a razão pela qual uma edição PHP partida no painel raramente deita o site abaixo
• A constante DISALLOW_FILE_EDIT no wp-config.php continua a desligar por completo os editores de ficheiros em produção

#Diferenças entre o WordPress 4.9 e o WordPress 6.x

#Como mudou o desenvolvimento de temas desde o WordPress 4.9

Desenvolvimento de temas:

• 4.9: Modelos PHP, functions.php, hooks e filtros
• 6.x: Temas de blocos, theme.json, Editor do site

Na era do 4.9, construir um tema exigia conhecer bem o PHP, a hierarquia de modelos do WordPress e o sistema de hooks. Os temas de blocos definem-se sobretudo através do theme.json e de modelos HTML, com o PHP reservado para funcionalidades específicas.

Edição de conteúdos:

• 4.9: Editor clássico, shortcodes, widgets
• 6.x: Blocos Gutenberg, padrões, modelos

Personalização:

• 4.9: Personalizador, opções do tema
• 6.x: Editor do site, definições de blocos

Ferramentas para programadores:

• 4.9: CodeMirror, WP_DEBUG
• 6.x: Ferramentas de desenvolvimento de blocos como @wordpress/scripts

#Funcionalidades substituídas e adicionadas desde o WordPress 4.9

Substituído ou opcional:

• Editor clássico (disponível como plugin opcional)
• Muitas funcionalidades do Personalizador (substituídas pelo Editor do site nos temas de blocos)
• Ecrãs de widgets (áreas de widgets baseadas em blocos)

Continua lá:

• CodeMirror nos campos de código
• Edições PHP protegidas nos editores de ficheiros

Novo:

• Editor de blocos Gutenberg
• Full Site Editing
• Padrões de blocos
• theme.json para a configuração de temas
• Desenvolvimento do editor baseado em React

#O que os programadores podem aprender com o WordPress 4.9

#1. Primeiro a infraestrutura, depois a interface

Os changesets chegaram no 4.7 sem interface, e o 4.9 acrescentou por cima rascunhos, agendamento e bloqueio. Separar o armazenamento da interface permitiu entregar a funcionalidade em duas versões sem partir os sites existentes.

#2. Compatibilidade com versões anteriores no WordPress

O WordPress manteve a compatibilidade com versões anteriores mesmo em mudanças grandes. O plugin Classic Editor manteve os sites antigos a funcionar depois do 5.0, e o suporte de shortcodes no widget de texto eliminou um filtro que temas e plugins acrescentavam à mão.

#3. Redes de segurança para quem edita em produção

A reversão por loopback, o linting que impede guardar e o aviso nos editores de ficheiros partem do princípio de que as pessoas vão editar sites em produção. Preparar-se para isso revelou-se mais útil do que fingir que não acontece.

#Resumo do WordPress 4.9 e das suas principais conquistas

O WordPress 4.9 “Tipton” foi a última versão do WordPress “clássico” antes do editor Gutenberg.

Principais conquistas:

• Rascunhos, agendamento, bloqueio e ligações de pré-visualização no Personalizador
• CodeMirror com linting no CSS adicional, no widget HTML personalizado e nos editores de ficheiros
• Edições PHP protegidas que revertem os erros fatais
• Widget de galeria, shortcodes e multimédia no widget de texto
• Novas capacidades e confirmação da mudança de email

Para programadores:

• Leia o guia de campo do 4.9 se mantém um tema clássico, porque boa parte da API do Personalizador e do editor de código que usa vem daí
• Use wp_enqueue_code_editor() em vez de incluir a sua própria cópia do CodeMirror
• Configure um cron real se depende de changesets agendados