Gutenberg respeita o suporte do editor declarado por um CPT e não carregará se não for compatível.

Se isso significa que Gutenberg não carrega de jeito nenhum e o editor Classic é usado em seu lugar, então isso nos coloca no caminho para um administrador WP fraturado que é dividido entre os ambientes Gutenberg e Classic. Isso seria ruim para o WordPress de várias maneiras.

• Os novos usuários teriam que aprender as maneiras principais e sutis em que os dois tipos de interface diferem. Ações tão simples quanto publicar uma postagem ou mudar para a visualização de texto funcionam de maneira diferente nos editores Gutenberg e Classic.

• Os desenvolvedores existentes seriam forçados a manter a funcionalidade de seus temas e plug-ins em ambos os ambientes. Não estamos falando sobre um período de transição; estamos falando indefinidamente. Plug-ins que se destinam a estender qualquer tipo de postagem seriam os mais afetados. Se esses desenvolvedores acabarem convertendo suas metacaixas em blocos, eles ainda terão que manter as metacaixas antigas no caso de alguém usar seu plug-in em um tipo de postagem que não seja de Gutenberg.

• Os desenvolvedores de novos plug-ins entrando no desenvolvimento do WordPress teriam que aprender como construir plug-ins de duas maneiras diferentes. Supondo que eles adotem os blocos de Gutenberg, sua funcionalidade de plug-in pode nem estar disponível em tipos de postagem usando o editor Clássico.

Por mais que eu acredite que devemos fazer as metacaixas funcionarem, simplesmente desligar o Gutenberg não é a melhor solução a longo prazo.

Se isso significa que Gutenberg não carrega de jeito nenhum e o editor Classic é usado em seu lugar, então isso nos coloca no caminho para um administrador WP fraturado que é dividido entre os ambientes Gutenberg e Classic.

Nos casos em que um CPT não deseja habilitar o editor de forma alguma, esse parece ser o melhor caminho a seguir. É simplesmente uma visão de administrador diferente, otimizada para uma experiência diferente. (A visão "ordens" de Woo, por exemplo.) Não ajudaria ninguém tentar renderizá-los dentro do contexto de Gutenberg.

É semelhante ao advento do Customizador - era um novo paradigma de interface que fazia algumas das mesmas coisas em um contexto diferente. Sempre precisaremos de uma interface de "gerenciamento" e uma interface de "edição". Em parte, é assim que avançamos, esclarecendo os diferentes propósitos das interfaces.

Mas, devido ao aumento do escopo de Gutenberg, não se trata apenas de habilitar ou desabilitar o tipo de editor. Como Gutenberg agora determina toda a interface de edição, há uma lista completa de efeitos colaterais associados ao tipo de editor que listei acima.

Sempre precisaremos de uma interface de "gerenciamento" e uma interface de "edição".

Essas são exatamente as funções que o editor e as metacaixas cumprem hoje. Não são experiências isoladas. Eles trabalham juntos.

então, talvez o aumento do escopo deva ser abordado, e Gutenberg deve ser restrito à área povoada por wp_editor() . Certamente resolveria muitos problemas de compatibilidade.

Oportunista

Abordar o aumento do escopo é minha preferência e algo que muitos de nós temos reclamado nos últimos meses. Isso nos permitiria melhorar o editor sem dividir a experiência do administrador.

Habilitando Gutenberg por tipo de postagem

Com relação à capacidade de desabilitar Gutenberg por tipo de postagem, quero enfatizar que evitar o problema não é o mesmo que chegar a uma solução. Desativar o Gutenberg por tipo de postagem pode evitar a incompatibilidade da meta box para alguns plug-ins, mas prejudica o panorama do WordPress a longo prazo.

Se você não consegue ver o porquê, imagine ser um novo desenvolvedor de plugins entrando na indústria daqui a dois anos, após a fusão de Gutenberg.

• Como desenvolvedor, você escreve a IU do plugin como um bloco ou como uma caixa-meta? Se quiser oferecer suporte a todos os tipos de postagem, você terá que escrever como ambos.
• Quando um usuário está procurando por plug-ins, ele está ciente de que a funcionalidade prometida em sua página de plug-in funciona apenas em tipos de postagem habilitados para Gutenberg? Eles ficarão desapontados quando descobrirem que não podem usá-lo junto com o editor Classic?
• Quando esse mesmo usuário entrar em contato com você para obter suporte, você sabe se eles estão perguntando sobre como o seu plugin funciona no editor Clássico ou no editor Gutenberg. Esse cliente sabe a diferença?
• Quando você deseja adicionar funcionalidade meses após o lançamento, está disposto a multiplicar seu tempo de desenvolvimento para construir essa funcionalidade tanto na caixa meta do PHP quanto no bloco JS?

Essas são apenas algumas das questões que confundem o cenário quando avançamos com dois editores e nenhum caminho para a singularidade na IU.

show_in_rest

O fato de que as postagens não podem usar Gutenberg quando show_in_rest não está definido é apenas outro exemplo de funcionalidade não relacionada que afeta a experiência de edição. Não há razão para que minha preferência por visibilidade de postagem pública na API REST afete a interface que utilizo ao editar. Eu entendo as razões técnicas, mas a lógica não está lá, e eu suspeito que muitos desenvolvedores nem mesmo estão cientes de que isso é uma limitação neste momento.

Como Gutenberg saiu do escopo dos parâmetros wp_editor () ainda me deixa perplexo. Se o "editor" de Gutenberg for restringido a wp_editor (), então a "ativação como uma opção" por tipo de postagem se torna uma realidade e muito mais gerenciável e expansível no futuro. Eu ainda não vi uma explicação racional sobre por que o aumento do escopo de Gutenberg não pode ser reduzido e apenas estar contido em wp_editor ().

Não faz sentido que Gutenberg seja habilitado para tipos de postagem personalizados que não usam o editor e que não são exibidos diretamente no frontend.

Já vi vários sites onde os CPTs são usados ​​não apenas para tipos de post genuínos, mas como um método de criação de interfaces administrativas para várias configurações e elementos.

Por exemplo, um site de autor em que trabalhei tem CPTs para "Livros" e "Links de compras". Ter Gutenberg como editor das páginas de listas de livros faz todo o sentido. Mas os "Links de loja" não têm postagens ou páginas próprias, mas são usados ​​para fornecer a lógica para links para livrarias online em cada página do "Livro". O modelo da página Livros exibe links da loja para páginas de produtos que correspondem à região (por exemplo, Reino Unido, EUA) e formato (por exemplo, ebook, impressão), inserindo o ISBN armazenado em um metacampo de postagem na estrutura de URL de cada loja online - veja as capturas de tela.

Os CPTs podem não ser a melhor maneira de gerenciar esse tipo de dados e configurações, mas existem muitos sites que agruparam várias funções usando CPTs sem editor e metacampos personalizados - eu poderia fornecer outros exemplos desse tipo de uso. Seria confuso e contraproducente forçar o editor de Gutenberg a CPTs que não usam o editor de forma alguma.

Não faz sentido que Gutenberg seja habilitado para tipos de postagem personalizados que não usam o editor e que não são exibidos diretamente no frontend.

Não, não faz sentido, mas contanto que Gutenberg seja uma substituição de tela inteira, a decisão de incluir ou excluir Gutenberg tem ramificações maiores que vão além do fato de você querer um editor em seu tipo de postagem ou não.

Por exemplo, imagine que você é um desenvolvedor de plug-ins e deseja que a metacaixa "Configurações do link da loja" esteja disponível em um tipo de postagem que usa Gutenberg e um segundo tipo de postagem que não usa. Ao distribuir um plugin para milhares de usuários que esperam que ele funcione com qualquer tipo de postagem, você não tem o luxo de escolher. É quando as perguntas mencionadas em https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341867663 entram em jogo.

Vale a pena repetir que as metacaixas isoladas em seu próprio tipo de postagem são as menos afetadas por Gutenberg, então temos que considerar como isso afeta a funcionalidade do plugin que atende aos tipos de postagem.

Sim, eu posso ver que plugins tendo que suportar interfaces de Gutenberg e não-Gutenberg seria um grande problema contínuo

Acho que a questão então é como Gutenberg deve lidar com CPTs que não suportam o editor - como Gutenberg funciona em contextos onde não faz sentido construir uma página a partir de blocos, onde ela é apenas meta dirigida?

... como Gutenberg deve lidar com CPTs que não suportam o editor - como Gutenberg funciona em contextos onde não faz sentido construir uma página a partir de blocos, onde ela é apenas meta dirigida?

Se Gutenberg diminuísse e apenas substituísse o editor como no conceito Yoast que mencionei em https://github.com/WordPress/gutenberg/issues/3304#issuecomment -341474018, então habilitar ou desabilitar Gutenberg se tornaria bastante simples.

• Se editor estiver habilitado, então o editor de bloco está presente e as metacaixas podem aparecer acima ou abaixo dele, dependendo dos ganchos usados.
• Se editor estiver desabilitado, o editor de bloco estará ausente e as metacaixas deslizarão para cima para se tornar a interface primária para o tipo de postagem.

É essencialmente assim que funciona hoje e, ao manter esse comportamento, permitiria que os plug-ins fizessem a transição gradual das metacaixas para blocos nos casos em que isso fizesse sentido. Isso também evitaria muitas das perguntas confusas listadas acima, que estão associadas a uma experiência de administração dividida.

Acho que "aumento de escopo" é um termo estranho de se usar, dada a postagem inicial e a aprovação que o projeto recebeu . Parece depreciativo para o trabalho que já vem sendo feito, em público, desde 11 de janeiro, onde começamos a discutir e pesquisar como melhorar a experiência de edição como um todo . Nada nos incomodou, esse sempre foi o plano, e é por isso que não há um prazo definido para o foco.

Seja como for, gostaria de falar um pouco sobre a perspectiva do O status quo é a saída mais fácil, mas nem sempre a maneira certa.

Adicionar blocos ao editor existente sem repensar o fluxo teria adicionado complexidade onde já havia complexidade .

Dado o mandato - para repensar a pós-autoria para envolver blocos para substituir códigos de acesso, HTML personalizado, widgets e muito mais - eu estaria desperdiçando minha responsabilidade como designer por não olhar para todo o fluxo de escrita, edição e publicação de forma holística.

Não estou convencido de que o WordPress será relevante em cinco anos , a menos que o projeto como um todo dê passos ousados ​​para encontrar o futuro. Um núcleo de JavaScript foi anunciado nas palestras do Estado da Palavra por anos. Tendo isso em mente, e a oportunidade que temos de simplificar radicalmente a autoria de um rico conteúdo de postagem, olhar para toda a experiência de edição em vez de uma pequena janela não é apenas uma oportunidade, mas seria indiscutivelmente negligente projetar de outra forma, apesar dos desafios que isso traz com isso.

É impossível projetar um bom editor sem olhar para a tela inteira . Isso é inconveniente, torna o projeto difícil e, devido ao legado do WordPress, torna-o ainda mais difícil. Não tem sido fácil e ainda temos muito a fazer, principalmente em torno de como Gutenberg pode ser estendido nativamente. Mas dar meio passo, construir Gutenberg para substituir apenas a área de texto de conteúdo, seria um grande desserviço para o WordPress e um péssimo design para arrancar.

É possível carregar um componente do Gutenberg , apenas a tela do editor, na tela de edição atual. Será uma experiência altamente comprometida e um Frankenstein de IU, mas pode ser um caminho a explorar para garantir um bom caminho de migração do 4.9 para o 5.0. Mas deve ficar claro que esta não é a experiência padrão, nem a ideal.

Acho que a questão então é como Gutenberg deve lidar com CPTs que não suportam o editor - como Gutenberg funciona em contextos onde não faz sentido construir uma página a partir de blocos, onde ela é apenas meta dirigida?

@CalebWoodbridge já é assim que funciona. Veja: https://github.com/WordPress/gutenberg/blob/master/lib/register.php#L290

Eu diria que usar o termo 'aumento do escopo' não é correto. É um termo que certamente não se aplica a um projeto que pretende fazer o que Gutenberg é.

Perdoe-me por colocar um ponto lateral nisso, mas acho que vale a pena dizer. Assim como o respeito é dado aos desenvolvedores quando eles dizem algo técnico, pense nos designers sob a mesma luz. Os designers que trabalham neste projeto têm muita experiência e habilidade, eu respeito profundamente o trabalho e é um prazer ser o líder de design de um projeto com designers tão incríveis.

Sinto-me honrado por ter a oportunidade de trabalhar com os designers que estão em Gutenberg. É um prazer diário e algo que nem sempre conseguimos no WordPress. Na maioria das vezes, como um designer básico, você é uma pessoa solitária, tem sido incrível trabalhar juntos.

A experiência é fundamental quando olhamos para a abordagem de design. @jasmussen na visão original juntamente com @matias definem a base de uma experiência completa. Como segundo líder de design, é algo que valorizo ​​e desejo preservar.

Um dos grandes problemas com o WordPress no passado, de uma perspectiva de design, foi uma espiral de pequenas iterações em cima de pequenas iterações. Embora funcione para os primeiros, com o tempo, ele se soma a uma experiência mantida em conjunto com remendos de melhorias. Há muito WordPress que sofre com isso. O editor é uma, a mídia é outra e há muito mais coisas que podem ser apontadas.

Gutenberg nos deu espaço para remover os patches, para ver o que temos e reconstruir. Isso nos deu como resultado o início de uma forte linguagem visual para avançar para a Personalização e além. Para realmente ter uma linguagem visual que mova o WordPress para os próximos 10 anos. Sim, temos que pensar muito à frente.

Eu quero fazer uma observação também contra Frankendesigns. Cada designer no mundo, em algum momento, teve alguém sugerindo que eles 'apenas colocassem x aqui ou y ali'. Isso não permite que o designer faça o design. Como projeto, estamos em uma espiral descendente se não permitirmos que os designers façam o design. Esse é o tipo de processo que, para ser franco, mata o fogo nos designers. Vamos manter o fogo aceso.

Esta é uma nota pessoal, que vai além de Gutenberg. Sou apaixonado por criar um espaço onde os designers possam prosperar e crescer - nem sempre como um projeto. Vamos mostrar com Gutenberg que fazemos isso. Paixão é ótimo, mas respeite a visão do design assim como fazemos no WordPress a visão técnica. Vamos ouvir designers tanto quanto ouvimos aqueles que falam sobre a estrutura JS mais recente.

A ponto de ser ousado criado por @jasmussen , um bom design é ousado. Sempre foi. Também requer espaço para explorar e pensar, Gutenberg tem sido incrível para isso. Temos (ainda temos) um espaço onde podemos explorar ideias que antes achávamos ser um projeto demais para abordar. Houve liberdade para iterar, experimentar e tentar. Isso produziu um design incrível, não vamos nos esquecer disso.

Quero ser claro, não estou dizendo que Gutenberg está 'pronto' ou perfeito como design. Precisamos iterar e testar. O que não precisamos é retroceder, afastar-nos da forte linguagem de design estabelecida. Não precisamos de Frankendesign. O que precisamos é testar, obter feedback e permitir que os designers iterem.

Um dos grandes problemas com o WordPress no passado, de uma perspectiva de design, foi uma espiral de pequenas iterações em cima de pequenas iterações. Embora funcione para os primeiros, com o tempo, ele se soma a uma experiência mantida em conjunto com remendos de melhorias.

Tentar reconciliar declarações como esta com declarações públicas como esta http://matiasventura.com/post/gutenberg-or-the-ship-of-theseus/ torna muito difícil para os usuários sentir que estão recebendo uma comunicação honesta sobre o trabalho sendo feito. O WordPress é usado por milhões de pessoas de milhões de maneiras, e ficou bastante claro que, no que diz respeito a aspectos técnicos como o suporte à metabox ou o formato de pós-armazenamento, é necessária uma abordagem incremental, com o mínimo de quebra possível. Essa decisão complicou várias partes da implementação e forçou decisões que não são ótimas, mas têm melhor suporte de várias maneiras.

Não é razoável manter o desenvolvimento de um padrão e o design de outro. Às vezes, o 'design arrojado' precisa ser reduzido para uma produção razoável. Isso é bem conhecido na fabricação de automóveis e é por isso que é fácil comparar Gutenberg a um carro-conceito.

Claro, você quer um design holístico que use javascript para todo o administrador, mas não pode ser a versão v5 sem quebrar a experiência de milhões de usuários. Em vez disso, se você reduzir para focar no editor, em vez de na página de edição, poderá fornecer uma experiência muito melhor (que pode atingir muitos de seus objetivos secundários com o uso criterioso de CSS), sem interrupções.

Então, ao fornecer uma API Fields bem documentada, você pode converter plug-ins e temas para a mentalidade de blocos de Gutenberg durante o próximo ano, tornando mais fácil e lógico produzir a mesma interface. Rapidamente, metaboxes se tornam a velha maneira de fazer as coisas, e todos os plug-ins de alto valor irão mudar para blocos ... mais uma vez, isso tem que acontecer organicamente. Forçar as mãos das pessoas ao descontinuar recursos ou criar uma interface dividida onde os autores de plug-ins precisam codificar tanto para gutenberg quanto para metaboxes é insustentável.

É bom que você mencione a revisão da mídia como uma área que precisa ser retrabalhada ... essa é uma área que sofreu com a reforma incontrolável e inflexível. Foi a primeira seção do WordPress a abraçar totalmente uma estrutura JS e foi um grande retrocesso para os desenvolvedores. A falta de customização na Biblioteca de mídia não é um sinal de que ela é perfeita, mas sim de que falta um design cuidadoso que leve em consideração os casos de uso atuais e futuros. Eu tentei modificar a interface de mídia muitas vezes, apenas para descobrir que alguém, em algum ponto, decidiu que os componentes principais deveriam ser embutidos em código nos modelos de backbone. Eu literalmente encontrei um desses casos ontem! (como você pode ver no sétimo parágrafo aqui: https://gschoppe.com/wordpress/disable-attachment-pages/)

Ajustar Gutenberg de volta ao editor, ao invés da página de edição, daria a você um caminho a seguir que não quebra tudo. Depois que Gutenberg estiver bem estabelecido como a base das interfaces de postagem personalizadas, a visão somente do JavaScript pode mudar para assumir o controle do resto da página de edição. Esse tipo de iteração é absolutamente crucial em grandes pacotes de software, a menos (como matt afirmou ser inaceitável) que você ofereça lançamentos LTS e faça de cada versão principal uma mudança de última hora completa.

Existem dois poços nos quais você corre o risco de cair e você identificou um. Sim, sem mudar para uma interface unificada usando tecnologias modernas, o WordPress provavelmente morrerá na próxima meia década. Mas também, se o WordPress falhar em fornecer suporte adequado para sua enorme comunidade de desenvolvedores e usuários profissionais durante esta transição, ele morrerá muito antes.

Faça uma pausa, diminua o ritmo e entregue algo que abra a caixa de ferramentas para os usuários, sem interromper o fluxo de trabalho existente. Em seguida, você pode escalar para a frente, versão por versão. Você tem um belo carro-conceito, mas o que precisamos é de um carro de produção que funcione para todos os casos extremos da direção no mundo real. Mas, ao fornecer o conceito, você pode pegar essa ideia e aplicá-la a um escopo mais limitado e, em um ano, esses princípios estarão onipresentes

@gschoppe , obrigado por responder.

Primeiro, alguma clareza. Não concordo que meu comentário contradiga a postagem de Matias. Eu me mantenho com o post que ele fez integralmente, é a minha visão também e nós somos os líderes desse projeto unidos na forma como enxergamos os rumos. Sua opinião pessoal é sua, então vamos prosseguir a partir desse ponto.

Não é razoável manter o desenvolvimento de um padrão e o design de outro.

Concordo e meu comentário não visa que o design seja mais ouvido ou tenha diferentes padrões, trata-se de ouvir todas as vozes, aplicando o mesmo padrão a todas.

É bom que você mencione a revisão da mídia como uma área que precisa ser retrabalhada ... essa é uma área que sofreu com a reforma incontrolável e inflexível.

Eu adoraria ver uma mídia se concentrando desde o início em designers e desenvolvedores, mas não foi o caso.

Mas também, se o WordPress falhar em fornecer suporte adequado para sua enorme comunidade de desenvolvedores e usuários profissionais durante esta transição, ele morrerá muito antes.

É interessante você dizer isso, pois ninguém está tirando nenhuma funcionalidade. Nenhuma sugestão de design de Gutenberg fez isso. De uma forma ou de outra, todas as funcionalidades existentes podem ser executadas, mesmo se isso for usando o plugin do editor clássico.

Não consigo pensar em nada mais Frankendesign do que confiar em iframes para montar uma IU. Embora eu entenda que as metacaixas são uma grande chave para o processo de design, parte do design é lidar com as limitações. Seguir em frente como se essas limitações não existissem ou adiar o plano de transição para o fim aumentará a preocupação de uma comunidade já preocupada e cética.

Se o plano de longo prazo para Gutenberg fosse território de plugins, então eu diria que experimente sem limites. Mas se ele não está destinado a ser um plug-in que as pessoas têm que optar por aderir ao invés de não, então ele tem que lidar de forma realista com o core e toda a bagagem que ele traz consigo.

meu comentário não visa que o design seja mais ouvido

Cada designer no mundo, em algum momento, teve alguém sugerindo que eles 'apenas colocassem x aqui ou y ali'. Isso não permite que o designer faça o design. Como projeto, estamos em uma espiral descendente se não permitirmos que os designers façam o design. Esse é o tipo de processo que, para ser franco, mata o fogo nos designers. Vamos manter o fogo aceso.

Em todas as empresas do mundo, os designs são ajustados às restrições de implementação. Se a compatibilidade com versões anteriores para metaboxes for uma restrição, o design precisa aceitá-la e trabalhar dentro das restrições.

Para ser franco, o suporte completo para metaboxes, sem perda de acessibilidade, é uma restrição de design ou não? Gostaria de uma resposta clara, assim como milhares de outras pessoas.

Nenhuma sugestão de design de Gutenberg fez isso. De uma forma ou de outra, todas as funcionalidades existentes podem ser executadas, mesmo se isso for usando o plugin do editor clássico.

Atualmente, Gutenberg coloca todos os meta-campos em um iframe. Isso quebra a funcionalidade em um nível muito profundo. Estamos na era da acessibilidade, e pegar o método principal esperado de criar experiências de usuário personalizadas e prendê-lo em um iframe remove fundamentalmente toda a acessibilidade dessas ferramentas. Ele também triplica o número de solicitações necessárias para carregar o editor e oferece aos usuários uma interface do usuário terrível, prendendo experiências modais de tela inteira em uma área minúscula.

Atualmente, este tópico discute se Gutenberg deve ser opt-in ou opt-out para tipos de postagem personalizados. Se optar por aderir, as decisões de interface do usuário anteriormente consistentes feitas por desenvolvedores que desejam oferecer suporte a todos os tipos de postes serão divididas entre a experiência de Gutenberg e a experiência clássica, exigindo o dobro do trabalho de desenvolvimento para fornecer uma experiência de usuário razoável para ambos e garantindo que não haja consistência da experiência do usuário.

Atualmente, a função wp_editor() (que é a forma de práticas recomendadas para implementar uma cópia completa da experiência de edição em páginas que não são de edição) não fornece uma interface de Gutenberg, o que significa que não posso criar experiências de edição personalizadas em páginas que não sejam de postagem ... qual é o meu caminho a seguir, além de dar aos usuários uma experiência de usuário dividida?

Embora o plug-in para remover o Gutenberg possa resolver alguns problemas, você não pode enviá-lo como uma solução para desenvolvedores de plug-ins. Eles não têm a liberdade de dizer "se você deseja uma interface de usuário consistente e acessível em todos os tipos de postagem, é necessário desativar o novo editor".

A remoção de recursos NÃO é compatibilidade com versões anteriores para o fluxo de trabalho padrão. A remoção de recursos é o último recurso para 1% dos usuários que não podem ser acomodados como experiências de primeira classe. Nesse caso, nenhum dos exemplos que dei são problemas de 1%.

Para adicionar um pouco de óleo às chamas: Na semana passada, tive um grande problema com o uso de iFrames, ou seja, eles podem funcionar bem em sistemas desktop, mas em 90% dos casos testados, eles falham muito em dispositivos móveis / responsivos. Depois de vasculhar vários tópicos de fóruns de mensagens, artigos na rede e perguntas no Stack Overflow, decidi abandonar totalmente a abordagem iframe, porque a capacidade de resposta fica terrivelmente complicada com em .. ugh. Algumas tarefas de conversão foram bastante fáceis de serem feitas, como "usar um redirecionamento para o subdomínio real onde o projeto reside" em vez de depender de um iframe para colocar uma bela decoração, também conhecida como mostrando apenas o suposto domínio principal, mas outras foram muito mais miseráveis.

No entanto, em comparação com a enorme quantidade de trabalho que eu teria que fazer para obter o RWD adequadamente e, acima de tudo, confiável E de fácil manutenção, para trabalhar com iframes, a recuperação foi muito menos trabalhosa e, portanto, a melhor saída.

Resumindo, embora os iframes pareçam à primeira vista uma saída fácil, eles são uma escolha de design MUITO RUIM, não apenas por causa de (muitos) problemas de acessibilidade.

Apenas meus 0,02 centavos,
cu, w0lf.

Obrigado @mtias por mostrar este problema.
Abaixo estou postando minhas idéias sobre como o Gutenberg pode abrir portas para os desenvolvedores de plugins do WordPress.

Classe CSS personalizável para qualquer bloco existente

Necessário: classe CSS para cada wrapper de bloco e acesso total para personalizá-lo. Será ótimo se Gutenberg exigir classe CSS no elemento superior, mesmo de desenvolvedores de terceiros.

Objetivo: Desta forma, podemos adicionar classes personalizadas aos blocos para estilização avançada. Também podemos usar classes para adicionar animações ou outras propriedades de bloco avançadas.

Exemplo de uso: Criamos um site para um grande cliente com uma linguagem de design estritamente definida. O editor lateral deve ser capaz de criar blocos com um número predefinido de estilos criados por nosso designer, especialmente para este cliente.

Atributos de dados personalizáveis ​​para qualquer bloco existente

Necessário: Possibilidade de adicionar atributos de dados personalizados para qualquer wrapper de bloco.

Objetivo: uma alternativa mais limpa e flexível às classes CSS personalizadas descritas acima. Com atributos de dados, podemos estilizar qualquer elemento da página. Além do estilo, os atributos de dados personalizados podem ser usados ​​para armazenar metadados adicionais para JS.

Exemplo de uso:

• blocos responsivos : marque um bloco para ser mostrado apenas no celular / desktop
• blocos condicionais : marque um bloco a ser mostrado / escondido com JS <div data-condition="if-adblock"... , <div data-condition="if-from-facebook"...
• animação de bloco : marque um bloco a ser animado <div data-animation="on-load animation-style-3"...
• desenho do bloco : <div data-skin="dark"...