A equipe de desenvolvimento do Gutenberg confirma que a API Meta Box não será formalmente obsoleta

A discussão em torno de como Gutenberg lidará com metaboxes esquentou no fim de semana depois que um participante comentou sobre o problema do GitHub com preocupação com a remoção do suporte a metaboxes do marco mais recente.

“Vejo que este problema vital foi removido de qualquer marco”, disse @steveangstrom. “Foi despriorizado novamente, enquanto sinos e assobios para edição de blogs dão muito trabalho e são adicionados aos betas. Isso é muito preocupante para o futuro do WordPress como CMS.”

James Nylen, um dos principais desenvolvedores do projeto, assegurou aos seguidores do tópico que a equipe de Gutenberg não se esqueceu do problema, mas que é “um problema extremamente complicado que estamos apenas começando a investigar, junto com muitos, muitas outras prioridades para que o editor funcione bem.” Ele também pediu ajuda da comunidade para planejar e testar implementações para suportar meta boxes.

Esta resposta deixou muitas coisas obscuras. Os participantes da discussão, muitos dos quais são desenvolvedores preocupados com a perspectiva de ter que reescrever todas as suas meta caixas como componentes React, estão se perguntando por que as meta caixas não podem funcionar ao lado do novo editor Gutenberg e por que a equipe escolheu incluir meta caixas no o escopo do projeto.

“É possível substituir o editor de postagem TinyMCE existente pelo Gutenberg, deixando o resto da interface, incluindo meta caixas e ganchos existentes, inalterados?” Kevin Hoffman perguntou. Quando Nylen esclareceu que Gutenberg, como escrito hoje, pretende ser um editor post_content , Hoffman resumiu as preocupações que muitos desenvolvedores expressaram:

Se o Gutenberg realmente pretende ser um editor de post_content , então as meta boxes devem ser deixadas em paz, pois não estão preocupadas com post_content .

Além disso, a necessidade de uma API para traduzir metaboxes PHP em metaboxes React é um problema fabricado. Não tem que ser um problema, mas se tornou um problema porque em algum momento ao longo da linha foi decidido que reescrever o editor post_content também deveria mudar completamente a forma como as meta boxes funcionam.

Você descreveu o tremendo desafio de escrever tal API em #2251. Traduzir metaboxes PHP em React para uma solução popular de campos personalizados como o ACF é bastante desafiador, quanto mais tentar fazê-lo para cada implementação de meta box que existe hoje, popular ou não. Não escala.

Como os contribuidores do Gutenberg compartilharam que eles apenas começaram a investigar o problema da meta box, agora está claro por que não há um roteiro de como o projeto lidará com metaboxes PHP “legadas”. Em julho, Nylen disse: “Se eu tivesse que adivinhar onde vamos parar aqui: as metaboxes atuais serão movidas para uma área de “legado” e forneceremos APIs, documentação e exemplos para registrar metabox-block de 'novo estilo' -coisinhas.”

Desenvolvedores de plugins que gerenciam bibliotecas de meta box, agências e outras partes interessadas estão seguindo o ticket para descobrir como planejar o WordPress 5.0, que foi direcionado como o lançamento do Gutenberg. Andrey Savchenko perguntou se o WordPress planeja descontinuar formalmente a API da meta box, o que finalmente atraiu uma resposta clara da equipe. Matias Ventura respondeu:

“O WordPress pretende descontinuar formalmente a API Metabox?”
Não.

A questão que ainda não foi totalmente respondida é como funcionam as meta-caixas no contexto do editor Gutenberg. Eles devem permanecer os mesmos ou evoluir? Como podemos avançar em direção aos objetivos de design com o mínimo de interrupção possível?

Esta questão tem perdurado não por falta de vontade, mas por falta de recursos. O foco principal deste projeto é oferecer uma interface de edição de conteúdo rica que otimize a manipulação direta do conteúdo do usuário através da noção de blocos. (Tendo usado meta-caixas extensivamente para vários projetos, acredito que os blocos podem oferecer um avanço melhor para muitas dessas necessidades, proporcionando uma melhor experiência ao usuário.)”

Ventura listou várias opções que a equipe considerou para lidar com meta boxes e solicitou ajuda da comunidade para construir a melhor solução:

• Se detectarmos que uma meta-caixa está registrada, podemos retornar à interface antiga, nada muda.
• Poderíamos dividir a edição do conteúdo e a modificação das metainformações em duas telas ou estágios.
• Podemos tentar ver o quão viável é renderizá-los como estão (PHP) abaixo do conteúdo: #2251.
• Um tema/plugin/CPT pode cancelar o registro da nova interface conforme necessário.
• Vários itens que dependiam de meta boxes podem ser convertidos em blocos para UI (ainda armazenando dados separadamente).
• Poderíamos implementar a extensibilidade de meta boxes baseada em API, como a API Fields.

Quando pressionado a responder à pergunta de por que meta caixas estão sendo incluídas no contexto do novo editor, o líder de design do Gutenberg, Joen Asmussen, esclareceu como a equipe decidiu incluir meta caixas no escopo do projeto:

Gutenberg começou apenas com a caixa do editor. O objetivo inicial era unificar várias interfaces diferentes em uma única interface de bloco unificada. Rapidamente ficou claro que, para criarmos uma experiência atraente girando em torno dessa interface de bloco unificada, precisávamos considerar todo o fluxo de escrita, incluindo configurações e publicação.

Se o ponto forte do WordPress é facilitar a criação de postagens ricas para qualquer pessoa, então não podemos apenas projetar para aqueles que já sabem como usar o editor. Temos que considerar os usuários que nunca usaram o WordPress antes e o que eles esperam de uma interface de publicação moderna. Caso contrário, estaríamos apenas adicionando carga cognitiva a uma interface já pesada.

A questão de como as meta boxes se encaixam no contexto do editor Gutenberg ainda está em aberto. Os participantes da discussão estão ansiosos para que essa pergunta seja respondida por causa da compatibilidade com versões anteriores e também porque afeta as decisões em andamento sobre o desenvolvimento do Gutenberg e o design da tela.

“Eu entendo completamente quanto trabalho foi feito para a abordagem de substituição da 'tela'”, comentou Xavi Ivars sobre o assunto. “Mas um projeto que começou com o objetivo de substituir o 'editor de conteúdo pós' não deveria voltar para a comunidade antes de decidir unilateralmente que substituiria toda a tela do editor?”

A API da meta box não está sendo preterida, mas também não há um caminho claro para como o Gutenberg suportará meta boxes PHP “legadas”. A equipe de Gutenberg disse que o problema não foi resolvido devido à falta de recursos. O projeto precisa da participação da comunidade e de uma comunicação melhor se a equipe chegar a uma solução que conduzirá perfeitamente a maioria dos sites WordPress à era Gutenberg com o mínimo de quebra.

Atualmente, a viabilidade de renderizar metaboxes PHP legadas abaixo do conteúdo é repleta de desafios e ainda está em debate. Se não houver tempo ou recursos de cliente suficientes para os desenvolvedores reescreverem seu trabalho em metaboxes baseadas em JS, então um caminho claro para desativar a interface do Gutenberg pode ser necessário para sites que precisam preservar as metaboxes “PHP” legadas .