Gutenberg: Os iframes são uma solução viável de longo prazo para metacaixas?

1. ... Gutenberg atualmente usa dois iframes separados para a coluna principal e a barra lateral. Se houver suporte para metacaixas que aparecem após o Título, isso teoricamente resultará em um terceiro iframe. Isso apresentará algum problema sobre como os plug-ins enfileiram os ativos que devem afetar todas as metacaixas com iframes?

Fiz alguns testes de desempenho esta noite e me deparei com essa descoberta na minha guia Rede, que é alarmante. Parece que todos os ativos CSS e JS enfileirados na janela pai também estão sendo enfileirados no iframe da coluna principal e iframe da barra lateral - o que significa que cada ativo é solicitado um total de três vezes, efetivamente triplicando o número de solicitações de ativos ao usar Gutenberg .

O dano ao peso da página é reduzido com o cache do navegador habilitado, mas o número de solicitações de ativos ainda triplicou. Presumo que isso esteja sendo feito para que cada iframe tenha os ativos necessários para permitir que as metacaixas funcionem, mas certamente essa não pode ser a solução para o enfileiramento de ativos daqui para frente.

Obrigado por criar o problema e seus insights @kevinwhoffman. É bom pensar um pouco que o que temos hoje para metaboxes em Gutenberg é um experimento, em muitos aspectos é um padrão de espera enquanto o projeto define a direção a seguir. Ao dizer que funciona 'por enquanto', mas não é o que enviaríamos.

Tudo o que foi dito acima, eu acho que é importante olhar para que no futuro as metaboxes serão usadas. Quais são os casos (se houver) que não seriam convertidos em blocos? Todas as metaboxes precisam funcionar no celular? Existe alguma interface alternativa que não exploramos? Aposto que sim. No momento, trata-se de olhar para essas possibilidades e entrar em uma estrada que funcione para o estado agora e para o estado futuro.

No momento, os bugs que existem com a versão atual das metaboxes em Gutenberg precisam ser corrigidos e esse é o foco. O desempenho precisa vir para essa correção. Em termos de dispositivos móveis, as metaboxes são um problema há muito tempo, não as estamos piorando aqui. Dito isso, devemos trabalhar por uma solução melhor no futuro. É importante fazer um loopback e lembrar que esta é apenas uma solução 'hoje' à medida que iteramos e continuamos livres para pensar em uma opção melhor.

É bom pensar um pouco que o que temos hoje para metaboxes em Gutenberg é um experimento, em muitos aspectos é um padrão de espera enquanto o projeto define a direção a seguir. Ao dizer que funciona 'por enquanto', mas não é o que enviaríamos.

A abordagem iframe não funciona, nem mesmo apenas 'por enquanto'. Os problemas relacionados listados acima fornecem exemplos de metacaixas que não funcionam de maneiras principais. Além disso, mesmo que esses problemas sejam corrigidos, triplicar o peso da página e o número de solicitações não deve ser considerado "funcionando" em nenhuma circunstância.

Tudo o que foi dito acima, eu acho que é importante olhar para que no futuro as metaboxes serão usadas.

Respeitosamente, isso acontece sempre que o problema das metacaixas é levantado. Por favor, em vez de mudar a conversa para futuros meta-blocos, seria realmente útil enquadrar esta discussão em torno dos problemas enfrentados pelas meta-caixas existentes. De novo:

Esses problemas podem ser resolvidos sem a necessidade de modificação do tema ou plugin que gera a metacaixa?

Não vi nenhuma evidência até o momento que sugira que as metacaixas continuarão trabalhando com Gutenberg. Se a resposta for não, então devemos parar de fingir que o 5.0 será apenas mais uma versão do WordPress e começar a ser honestos sobre quebrar a compatibilidade com versões anteriores.

Oi kevin,

Obrigado pelo relatório detalhado. Acho que muitas das questões podem ser retocadas até certo ponto. Esta também é uma exploração para saber se a abordagem iframe funcionará e até onde ela pode ser levada, portanto, é bom ter esse tipo de diálogo e registrar as deficiências dessa abordagem.

É possível iniciar uma janela de conteúdo a partir de uma metacaixa que se estende além do iframe?

Você quer dizer uma caixa de luz modal que deve ocupar a página inteira?

Você quer dizer uma caixa de luz modal que deve ocupar a página inteira?

Esse seria um exemplo, mas estou me referindo mais a qualquer cenário em que o conteúdo precisa ser revelado e que não está dentro dos limites do iframe.

Por exemplo, posso clicar em um botão na barra lateral que acione uma caixa de conteúdo no centro da página? Se essa caixa de conteúdo estiver dentro do iframe, ela não ficará visível fora das dimensões do iframe na barra lateral.

A próxima etapa lógica seria, em vez disso, chamar a função no documento pai do iframe. Mas os plug-ins não são escritos para funcionar dessa forma, e exigir que eles sejam modificados iria anular todo o propósito de suportar as metacaixas _legacy_. Eu não posso enfatizar o suficiente que qualquer solução que seja decidida precisa funcionar sem modificação dos temas ou plug-ins existentes.

Sabendo o quão negativa é a implementação do iFrame em relação aos recursos do plugin / tema, acho que isso deve dar uma pausa no projeto. A verdadeira resposta aqui é o WordPress enviar a API Fields https://github.com/sc0ttkclark/wordpress-fields-api - sem isso, implementar metaboxes de forma eficaz com Gutenberg é virtualmente impossível se nos preocupamos com o desempenho.

Se realmente não enviarmos Gutenberg até que esteja "pronto", então eu digo que devemos dar igual atenção à API Fields para que as metboxes funcionem corretamente e sem problemas com React em Gutenberg.

A próxima etapa lógica seria, em vez disso, chamar a função no documento pai do iframe. Mas os plug-ins não são escritos para funcionar dessa forma, e exigir que eles sejam modificados seria anular todo o propósito de oferecer suporte a metacaixas legadas. Eu não posso enfatizar o suficiente que qualquer solução que seja decidida precisa funcionar sem modificação dos temas ou plug-ins existentes.

Sim, definitivamente uma preocupação que tive ao fazer isso. A comunicação cruzada entre iframes não parece muito boa. Existem outras alternativas para explorar também.

Certamente haverá casos, no entanto, em que certos plug-ins de temas serão corrompidos e não será possível acomodar todos os casos de uso possíveis. Acho que talvez o melhor objetivo seja criar uma boa experiência para a vasta maioria dos usuários e casos de uso . É perfeitamente possível que a solução iframe atual não atenda a esse objetivo.

Pode ser importante notar que em um Core Customizer Dev Note Post houve atenção para a remoção do uso de um iframe como uma _melhoria_. Implementar um iframe como solução aqui parece um retrocesso.

Oi mathetos,

Se realmente não enviarmos Gutenberg até que esteja "pronto", então eu digo que devemos dar igual atenção à API Fields para que as metboxes funcionem corretamente e sem problemas com React em Gutenberg.

Eu concordo que uma API Fields seria um pouco bom. No entanto, isso também exigiria que as pessoas adotassem a API de campos. Se muitos não estão dispostos a reescrever seu plugin / tema para Gutenberg, eu não acho que eles estariam dispostos a fazer isso para uma API Fields. Eu também acho que isso foi mencionado em uma edição anterior em algum lugar, então eu recomendaria pesquisar isso na história do GitHub e adicionar suas idéias sobre como a API Fields poderia beneficiar Gutenberg.

... não é possível acomodar todos os casos de uso possíveis, acho que talvez o melhor objetivo seja criar uma boa experiência para a vasta maioria dos usuários e casos de uso.

Eu concordo, e acho que esse objetivo seria muito mais alcançável se Gutenberg se limitasse a revisar o editor em vez de assumir o controle de toda a página. Então, poderíamos deixar os ganchos existentes no lugar e as metacaixas poderiam continuar a se comunicar umas com as outras como fazem agora. Além disso, o enfileiramento de ativos não seria um problema, pois funcionaria como hoje.

Estou totalmente de acordo com este conceito apresentado por Yoast, que me parece que manteria muito do trabalho já feito enquanto reduzia o escopo do projeto para focar no componente do editor.

Fonte: https://yoast.com/gutenberg-alternative-approach/

Também concordo totalmente com a proposta apresentada por Yoast. Ele fornece um bom estágio intermediário que fornece aos autores de plug-ins tempo para converter metaboxes em novos blocos. Então, como parte do plano para uma eventual substituição de toda a experiência do editor, o WP como um projeto pode dizer algo como "Nas versões x, metaboxes serão descontinuadas", portanto, temos um _plan_ em vigor para avançar em direção a um objetivo final melhor.

Apenas observando que esse conceito quebra metaboxes existentes, porque não há uma instância central do TinyMCE com a qual se comunicar. Em vez de suportar 80% das metaboxes, isso suportará 90% (eu criei esses números).

Este conceito não resolve o problema de compatibilidade com versões anteriores, mas apenas atrasa sua resolução para mais tarde com o mesmo problema. Gutenberg é o primeiro passo em direção às interfaces JS no WP e não para com Gutenberg.

Reutilizar peças de Gutenberg para construir este conceito é relativamente factível, mas este não é o UX para o qual queremos otimizar. Queremos construir o melhor editor possível primeiro e torná-lo disponível para pessoas sem problemas de compatibilidade com versões anteriores (instalações novas, sem metaboxes .. .).

Quando acharmos que a visão ideal de Gutenberg está pronta para ser lançada, teremos tempo para discutir as estratégias de caminho de atualização. Um conceito como este é uma opção para um caminho de atualização, mas definitivamente não como o produto final. Outros caminhos de atualização também são possíveis.

Vamos construir o melhor editor possível agora.

Quando acharmos que a visão ideal de Gutenberg está pronta para ser lançada, teremos tempo para discutir estratégias de caminho de atualização ...

Eu não poderia discordar mais disso. Por que dedicar milhares de horas para desenvolver o editor ideal se ele não pode ser compatível com os sites existentes? Se a primeira impressão é que ele quebra a IU da qual eles dependem, os usuários nunca terão a experiência do editor ideal em primeiro lugar.

Por que dedicar milhares de horas para desenvolver o editor ideal se ele não pode ser compatível com os sites existentes?

Só para ficar claro,

• é impossível ser 100% compatível com os sites existentes, não importa a opção que você escolha para o editor, porque os plug-ins têm acesso total ao DOM, qualquer coisa que você modificar no dom está quebrando a compatibilidade com versões anteriores
• Só há uma maneira de garantir 100% de compatibilidade com versões anteriores para qualquer alteração: Não faça a alteração. O plugin que desativa Gutenberg já está disponível.
• O editor já é compatível com um grande número de sites. Mas como tudo mais, quando quebra, é sempre mais visível.

é impossível ser 100% compatível com os sites existentes

Agora que isso está claro, vamos construir o editor que achamos que é o melhor para o futuro do WordPress.

Todas as metaboxes precisam funcionar no celular?

Sim, por que não?

Quais são os casos (se houver) que não seriam convertidos em blocos?

Para postagens de blog, eu entendo por que Blocks For Everything pode fazer sentido, mas isso pode ser ignorando o caso de uso geral para metadados: dados que não são vistos. Tipo, posso usar uma metabox para expor a interface do usuário para adicionar dados analíticos a uma postagem.

Para coisas como os tipos de postagem personalizados, que podem ser compostos APENAS de metacaixas, tenho problemas para entender a nova IU. Como o WordPress carece de uma API CRUD abrangente para dados, muitos desenvolvedores usam WP_Query e seu conjunto de APIs relacionadas como um substituto e usam metacaixas nas telas de edição do CPT para isolar a IU para adicionar dados específicos ou associações. Muitos (a maioria) dos tipos de postagem personalizados desestimulam ou ignoram o uso tradicional de "conteúdo" - então, para postagens de blog, sim, o conteúdo está na frente e no centro, mas para muitos casos de uso de CMS, um WYSIWYG não faz muito sentido.

Nesta iteração atual, o suporte Meta Box é um complemento, quando na realidade de muitas pessoas, Meta Boxes SÃO a UI, a API, o mecanismo que usam para compor seu CMS. <iframe> s são os gulag.

E estamos esquecendo os valores nos quais o WP foi construído para sempre: devo ser capaz de atualizar para a versão mais recente do WP e não terei que reescrever nada. Tenho tantos projetos à solta no WP que nunca mais tocarei. Posso ter certeza de que alguns deles não vão quebrar muito com essa mudança?

Vou terminar com este exemplo: se uma das minhas "velhas" metacaixas acionar a IU para a mídia abrir, como isso funcionará neste "novo" cenário, de dentro de um iframe, sem alguém (um cliente com quem não trabalho mais ) reescrevendo o código?

Enquanto acompanhei essas conversas, não posso deixar de sentir que os poderosos que estão se desenvolvendo e fazendo as fotos em relação a Gutenberg não usam ou lidam com metaboxes eles próprios. Parece um tipo de argumento do tipo fins-justificam-os-meios, em que é fácil dizer isso porque os meios não são significativamente valorizados para começar.

Por favor, entenda que, para muitos de nós, temos dezenas de sites que quebrariam instantaneamente quando atualizados para o WordPress 5.0 - um produto que historicamente ensinou às pessoas que é seguro atualizar porque é maníaco por compatibilidade com versões anteriores. O que está sendo discutido aqui não é uma pequena quebra (por exemplo, estilo), mas um impedimento potencial que tornaria o lado administrativo de milhares (ou mais) de sites instantaneamente inutilizáveis. Isso é assustador. Como uma indústria, vendemos às pessoas a confiabilidade sólida do WordPress.

Como @staylor apontado acima, na maioria de nossos sites (sites corporativos de complexidade média a alta) as metaboxes _são_ a IU. O editor (se for usado) é apenas uma parte dela.

Quando acharmos que a visão ideal de Gutenberg está pronta para ser lançada, teremos tempo para discutir as estratégias de caminho de atualização. Um conceito como este é uma opção para um caminho de atualização, mas definitivamente não como o produto final. Outros caminhos de atualização também são possíveis.

Acho que pode ser um erro adiar isso muito. Especialmente porque muitas organizações precisarão de pelo menos 1-2 trimestres para se preparar.

Há um ditado que ouvi de vários desenvolvedores líderes de WordPress que acho importante lembrar aqui: quando alguém adota o WordPress para seu site, eles não estão adotando o WordPress 3.7 ou o WordPress 4.8, eles estão adotando o WordPress. Tornar esse caminho o mais contínuo possível é absolutamente necessário. Isso quebrará as coisas, e tudo bem (existem quebras de compatibilidade com versões anteriores em quase todos os lançamentos do WordPress), mas elas precisam ser minimizadas, documentadas e comunicadas.

é impossível ser 100% compatível com os sites existentes

Se você não vai ser compatível, vá e quebre as coisas. Chame a primeira versão de WP ++ ou WPNG. É muito melhor declarar com antecedência que as coisas provavelmente vão quebrar e deixar as pessoas se prepararem para isso. O atual "engano", como se as coisas funcionassem normalmente, é ruim para todos.

Iframes são becos sem saída em termos de usabilidade. Abriu um widget de seleção de data baseado em jquery em uma caixa-meta e fiquei surpreso ao clicar em algum outro lugar aleatório da janela e não fechá-lo. Levei um minuto para perceber que o evento de clique estava na janela pai e não se propagou para o iframe. Fiquei surpreso, mas acabei entendendo, mas como você vai explicar isso aos usuários? Você espera que cada plugin responda às perguntas de cada usuário sobre essas expectativas triviais de experiência do usuário.
E como você espera que os links externos funcionem?

Existem grandes razões pelas quais as pessoas usam iframes apenas como último recurso.

Minha sugestão produtiva é não declarar a meta box pronta, contanto que o yoast seo não funcione corretamente nele. É um pouco complexo em termos de interações e é instalado em um monte de sites. Se o gutenberg não funcionar com ele, provavelmente ninguém o usará.

Minha sugestão produtiva é não declarar a meta box pronta

Como apontado por @karmatosed acima: "É bom pensar um pouco que o que temos hoje para metaboxes em Gutenberg é um experimento, em muitos aspectos é um padrão de espera enquanto o projeto define a direção a seguir. Em dizer que é uma que funciona 'por enquanto', mas não é o que enviaríamos. "

Para fornecer alguns dados do mundo real, quero compartilhar esta interface de um site WordPress em que trabalhei no passado. O campo de conteúdo é uma parte secundária desse tipo de postagem personalizada e, embora alguns dos campos personalizados da metabox possam ser convertidos em blocos, a maioria contém dados que são usados ​​pelo administrador, por um serviço de terceiros por meio da API REST, ou usado para adicionar metadados à entrada. Embora possa parecer um pouco caótico, esta configuração foi projetada especificamente para trabalhar com o fluxo de trabalho do cliente e usa um modelo de conteúdo estrito baseado em separação clara para garantir que versões futuras do site possam lidar com cada tipo de conteúdo independentemente.

Refatorar este site para funcionar dentro da realidade de Gutenberg levará muito tempo e exigirá recursos substanciais, portanto, a menos que as metaboxes sejam tratadas de uma forma que corresponda exatamente ao que já existe, o proprietário deste site provavelmente irá reverter para uma versão pré-Gutenberg do WP e permanecer lá por um período indefinido de tempo.

Para referência, embora pareça extenso, não é nem a configuração da metabox mais complexa que criei nem a configuração mais complexa que já vi. O que este exemplo mostra é a solução alternativa do mundo real, por meio de metaboxes, para atender à necessidade de modelagem de conteúdo adequada e separação além do blob de conteúdo, algo que Gutenberg _deve_ lidar com graça e funcionalidade.

Tornar esse caminho o mais contínuo possível é absolutamente necessário.

Acordado

Isso quebrará as coisas, e tudo bem (existem quebras de compatibilidade com versões anteriores em quase todos os lançamentos do WordPress), mas elas precisam ser minimizadas, documentadas e comunicadas.

Acordado

é impossível ser 100% compatível com os sites existentes, não importa a opção que você escolha para o editor porque os plug-ins têm acesso total ao DOM, qualquer coisa que você modificar no dom está quebrando a compatibilidade com versões anteriores

Concordo, não acho que alguém discordaria de você aqui. No entanto, acho que ainda há espaço para discutir o que está quebrado e quando está quebrado. Esse tipo de decisão _também_ afeta o tipo de trabalho que os desenvolvedores precisam fazer para consertar o que está quebrado. Há uma diferença significativa entre ajustar as coisas porque os seletores dom foram modificados, versus ter que reescrever um modelo de conteúdo personalizado para se ajustar ao novo paradigma de Gutenberg, onde metaboxes apenas funcionam :) A contenção em torno de metaboxes indica para mim que é algo que provavelmente não é uma boa coisa para ter como alvo a quebra no lançamento inicial de Gutenberg no núcleo.

Entendi que tudo isso é um experimento, acho que @kevinwhoffman também. Eu vejo essa questão como uma _avaliação_ bem pensada deste experimento e deve ser considerada assim. Este experimento será suficiente como solução final? Não. Qual é a próxima experiência?

Eu também não acho que veremos um grande aumento de desenvolvedores convertendo seu trabalho existente para Gutenberg até que uma proposta de mesclagem esteja em vigor, com isso em mente, o que quebra no lançamento inicial de Gutenberg _sim_ importa.

tldr; Esperamos romper com Gutenberg? Sim! Mas ainda devemos ser seletivos sobre _o_ que_ quebramos e até que ponto essa quebra vai na iteração _inicial_ de Gutenberg fundido com o núcleo.

Sim, todos nós já conhecemos o desenvolvimento do WordPress o suficiente para esperar que algumas coisas quebrem de uma versão para a próxima. E, de certa forma, esse é exatamente o meu ponto. Enquanto estivermos apresentando o Gutenberg como apenas mais uma atualização do WordPress, ele não deve quebrar nada mais ou menos do que qualquer outra atualização. Se quebrarmos essa confiança, não importa o quão bom o editor seja no final do dia.

Aqui está uma captura de tela atual de um plugin que venho desenvolvendo nos últimos meses. Nessa situação, um editor visual não tem valor algum e tentar encaixar o tipo de interface necessária em uma interface projetada para edição visual de conteúdo não faz sentido.

Na verdade, estou considerando seriamente se devo me preocupar em continuar desenvolvendo isso para WordPress, visto que todo o meu trabalho pode ser desfeito na próxima versão.

Como você pode ver, preciso acessar o carregador de mídia em meus metacampos, e relegar a maior parte da página para um iframe tornaria essa interface extremamente desajeitada.

Existem milhões de interfaces como essa em plug-ins, ferramentas e sites personalizados, construídos no WordPress. Tratar esses usuários como cidadãos de segunda classe, em favor da "nova gostosura" dos blocos é inaceitável. As Metaboxes precisam manter seu nível atual de integração e destaque na página de edição.

Eu apoio fortemente a visão de Gutenberg de Yoast. Não está claro para mim como "atualizar o editor visual" foi reinterpretado para ser "substituir toda a interface de pós-edição" pela equipe de Gutenberg, mas parece diretamente em desacordo com o chamado "Nave de Teseu".

Nesse caso, a falta de orientação e suporte claros para os fluxos de trabalho padrão existentes está prejudicando ativamente os desenvolvedores agora. Como posso avançar construindo um projeto, sem um conjunto confiável de ganchos e ferramentas em que posso confiar? É injusto pensar que um projeto de software tão grande mudaria totalmente o fluxo de trabalho padrão para desenvolvedores em uma única atualização. e é uma loucura que essas conversas só estejam acontecendo agora, em novembro, quando o plano é ter uma fusão aprovada no início do ano.

@aaronjorbin bem, parece que há um problema de comunicação aqui como em https://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/ foi dito explicitamente

Esta versão inclui suporte para metacaixas há muito aguardado (precisa de testes!),

não é uma "ideia" não é um "experimento", é apenas algo que, como todo software, ainda pode incluir bugs. Eu não o teria testado se fosse chamado de "experimento" naquele post.

Voltando ao assunto, vejo que o principal problema aqui é a tentativa de evitar declarar uma quebra. Do meu conhecimento limitado de framewoks JS, é muito difícil estar "meio grávida" deles, e uma vez que você decidiu que o controle da tela principal é feito com eles, tudo precisa ser feito com eles, portanto, a única maneira de avançar é torne as metacaixas cidadãos de primeira classe na tela de edição do gutenberg.
Como é improvável que plug-ins "legados" se adaptem, isso significa que o gutenberg precisa ser uma opção explícita de aceitação para sites existentes. Eu odeio a ideia de um fork de UX, mas pelo menos assim haverá um caminho a seguir que funcionará, e se for declarado agora, as pessoas serão capazes de se preparar.

Depois de ler a discussão e pensar sobre os projetos que construo com o WordPress e as coisas que vejo as pessoas fazerem com o WordPress, cheguei à conclusão de que Gutenberg deveria optar por tipos de postagem personalizados. Isso permitirá que os sites atuais que usam CPT para dados estruturados continuem a funcionar e que novos sites onde o WordPress seja usado como um CMS sejam construídos. Gostaria apenas de lembrar que ao registrar um tipo de postagem podemos declarar explicitamente o suporte para o campo do editor junto com outros recursos. Então, por que não adicionar suporte explícito para Gutenberg lá? É claro que isso não resolverá o problema das metacaixas adicionadas a postagens e páginas, mas permitirá que o WordPress seja usado como um CMS no futuro.

Pode adicionar um novo problema com esses iframes. Quando a sessão do usuário termina, a tela de login do WP é exibida duas vezes no Gutenberg e dentro do iframe.

Apenas para os desenvolvedores estarem cientes disso.

Mais eu sigo tudo isso mais estou convencido de que a única maneira possível seria como a Microsoft fez.

Windows XP = WordPress sem Gutenberg
Windows 10 = Wordpress com Gutenberg.

Esses 2 não podem ser misturados e atualizados com pacotes de outro.

Joomla e Drupal fizeram isso. Por que não. Não é algo que eu prefiro, mas o que é alternativo.

Depois de ler a discussão e pensar sobre os projetos que construo com o WordPress e as coisas que vejo as pessoas fazerem com o WordPress, cheguei à conclusão de que Gutenberg deveria optar por tipos de postagem personalizados.

Um administrador dividido seria um dos piores resultados que podem surgir de Gutenberg. Descrevi os motivos em https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341752490.

Essa discussão está ficando realmente kafkiana. Parece que não importa quantas pessoas proponham acordos pragmáticos para os pontos de dor atuais, existem algumas pessoas-chave que parecem completamente impermeáveis ​​à crítica. Infelizmente, essas pessoas são as que têm a palavra final, porque até agora a discussão mostrou que algumas pessoas-chave podem atropelar centenas de desenvolvedores preocupados. Eu me preocupo com todos os danos que isso está causando ao ecossistema WordPress. Faça de Gutenberg o editor, não a tela de edição. Não quebre o WordPress.

Kevin Hoffman:

Estou totalmente de acordo com este conceito apresentado por Yoast, que me parece que manteria muito do trabalho já feito enquanto reduzia o escopo do projeto para focar no componente do editor. Fonte: https://yoast.com/gutenberg-alternative-approach/

Acredito que o caminho proposto pelo Yoast seria uma grande melhoria para o WordPress Core. Um novo editor para criar conteúdo, que muitos usuários adotariam como uma melhoria em relação ao atual. Uma etapa menor para o WordPress, mas uma grande melhoria para o usuário.

Este é um assunto acalorado. Admito que às vezes nós (pelo menos eu) podemos ser indiferentes em meus comentários e peço desculpas por isso. Estamos recebendo muito feedback, bom, ruim, objetivo, inútil e às vezes é difícil distinguir entre eles. Nós somos humanos. Tente estar do outro lado da equação, ser aquele que constrói essa coisa e recebe todo esse feedback. A TI pode parecer próxima a “ataques pessoais”, os cérebros tendem a reagir sendo desdenhosos, não devemos.

As pessoas que comentam e lêem postagens de blog geralmente pensam que estamos descobrindo os problemas das metacaixas e tudo o que está relacionado. Não estivessem. Estamos trabalhando em Gutenberg há um ano. Talvez você tenha acabado de descobrir / experimentou o Gutenberg, mas nós não, nós trabalhamos nisso há tempo suficiente para nos sentirmos confortáveis ​​com a maioria dos problemas de compatibilidade com versões anteriores e temos respostas para a maioria deles.

Por favor, tenha a mente aberta e vamos começar respondendo a algumas perguntas:

Qual é o objetivo de Gutenberg?

Não é, e nunca foi, o objetivo principal de Gutenberg é pavimentar o caminho para o futuro do WordPress Core. Tecnicamente, aproveitando a API REST, a IU do lado do cliente e unificando os conceitos básicos: Widgets, códigos curtos, blocos, Metaboxes de conteúdo sob um conceito único "Um bloco" e experiente respondendo a estas perguntas: Como simplificar a construção de sites (pense em personalizações) e publicação de conteúdo (think editor) em WordPress.

Qual é o objetivo do Editor Gutenberg?

Ao contrário do que você lê aqui e ali, o foco sempre foi sobre o redesenho de toda a página. A primeira maquete da Página do Editor de Gutenberg foi exibida na segunda ou terceira reunião semanal de Gutenberg. Ainda estávamos na fase de prototipagem. Meses antes do primeiro alfa. O design ficou próximo do que temos agora.

E as Metaboxes, elas são importantes para o WordPress?

Eles são. Como códigos curtos, botões TinyMCE personalizados, eles são muito usados ​​e abusados ​​para estender a página do editor do WordPress.

Qual é a diferença entre Shortcodes, Botões TinyMCE e Metaboxes?

A principal diferença é que “Metaboxes” não tem “propósito”, é apenas uma forma de estender a página do editor sem consistência enquanto os Shortcodes e os botões TinyMCE têm um.

Os códigos curtos são uma string convertida em conteúdo na fase de renderização, os botões TinyMCE são botões personalizados adicionados à barra de ferramentas TinyMCE e usam a API TinyMCE para se comunicar com o conteúdo do editor. Metaboxes? Não sei, podem ser qualquer coisa, basta adicionar um monte de HTML, Javascript e PHP para estender a página do editor e como ela se comporta ao salvar.

Essa falta de “propósito” é um problema ou uma vantagem?

Bem! Ele pode ser visto como um “profissional”, porque um plugin pode fazer tudo o que quiserem com o editor, incluindo coisas como:

• Substituindo qualquer botão, textarea, input, div, qualquer coisa. Acesso total ao DOM
• Usando qualquer variável javascript global, incluindo a instância global do TinyMCE

Flexível certo! Mas e as atualizações do WordPress. Qualquer atualização na tela do editor. Qualquer atualização do TinyMCE, qualquer mudança de classe, qualquer novo div , qualquer botão removido / movido, qualquer mudança está quebrando a compatibilidade com plug-ins porque, como um desenvolvedor Core WordPress, você não sabe para que plug-ins está usando Metaboxes.

Podemos concluir que, para o longo prazo do WordPress, os Metaboxes estão bloqueando sua evolução (independentemente de Gutenberg)?

Sim, eles estão. E a história da Internet provou tantas vezes que uma tecnologia que não evolui morre. (por favor, não reaja com 👎 Se você não gostar desta resposta, é um fato e não uma opinião)

Ok, mas então como podemos mover o WordPress para frente se estamos presos com Metaboxes?

Essa é uma boa pergunta e antes de responder, precisamos entender o uso atual de Metaboxes em plug-ins WordPress

Para que servem os plug-ins atuais do Metaboxes?

Eu diria que existem duas categorias de plug-ins “Metaboxes”:

• Metaboxes como conteúdo (frequentemente armazenadas em post meta, mas nem sempre)
• Metaboxes como aprimoramento da experiência do editor (SEO, verificação ortográfica, ...)

Ok, sabendo disso, como podemos seguir em frente?

Precisamos de três coisas:

• Fornece uma maneira de construir ou atualizar esses plug-ins enquanto o Gutenberg (ou qualquer atualização do WordPress) é enviado.
• Fornece os melhores caminhos de atualização possíveis para as pessoas que usam esses plug-ins. Isso inclui: veja se esses plugins ainda funcionam com as evoluções que estão por vir e como minimizar a quebra.

Ok, mas você não disse que qualquer alteração na página do editor quebrará os plug-ins (incluindo a substituição apenas da área de conteúdo)?

Direito! Portanto, se o nosso desejo é não quebrar nenhum plugin, ficamos com uma opção única. Fornece uma maneira de permanecer com a página de edição atual sem alterações. É exatamente para isso que serve o plugin para desativar o Gutenberg.

Eu pessoalmente não chamaria isso de um bom caminho de atualização, não é nem mesmo uma atualização, algo melhor?

Este caminho de atualização (desabilitando Gutenberg) é uma necessidade, mas sim, podemos fazer melhor. Se você der uma olhada nos plugins usando Metaboxes, 90% deles não tem nenhuma interação com a área de conteúdo, portanto, se substituirmos apenas a área de conteúdo (abordagem yoast), estaremos quebrando 10% dos plugins.

Portanto, a única maneira sem quebra é desabilitando Gutenberg.

A experiência do usuário Gutenberg ideal consiste em substituir os plug-ins metaboxes por plug-ins que fornecem a mesma funcionalidade com as novas APIs de extensibilidade de Gutenberg.

Dito isso, notamos que a maioria dos plug-ins usando Metaboxes estão usando-os como conteúdo sendo salvo para postar meta e podemos fazer com que funcionem na tela do Gutenberg para desfrutar de toda a experiência enquanto os autores dos plug-ins atualizam seus plug-ins.

Esta é a solução iframe de que todos falam?

Sim, ele é. Mostramos as metacaixas em iframes, o que tem suas desvantagens (link, modais, recarga de ativos), mas ao mesmo tempo permite que 80% dos plug-ins funcionem enquanto desfruta de toda a Experiência Gutenberg. Esta solução acabou de chegar e ainda estamos fazendo experiências com ela. O que é certo é que não há como fazer todas as metaboxes funcionarem e fazer alterações no editor.

Entendo, você pode recapitular as possibilidades de atualização, por favor?

Certo.

1- Desabilite o Gutenberg: não quebre 100% dos plugins
2- Gutenberg substitui apenas a área de conteúdo: 90% dos plugins funcionam, o UX sofre
3- Gutenberg substitui a tela inteira: 80% dos plugins funcionam, o UX é melhor
4- Gutenberg com plug-ins compatíveis: Melhor UX possível

Então o que precisamos fazer?

Nosso objetivo é construir a 4ª opção porque é a melhor opção para o futuro do WordPress. Nosso objetivo também é construir Gutenberg de uma forma que possamos reutilizar suas peças para atingir a 2ª e a 3ª opções, se necessário.

Como posso optar por uma opção em vez de outra?

Isso ainda não foi decidido. Ter um plugin para escolher o caminho de atualização que você deseja é uma possibilidade. O downgrade automaticamente detectando algumas Metaboxes é uma opção ...

Essa é minha opinião para explicar o raciocínio por trás dessas questões, por favor, se você quiser responder com palavras como "ridículo", "mal gerenciado", "implementação ruim" ... minha paciência como um desenvolvedor simples que passou o ano inteiro pensando sobre o O melhor caminho possível para o WordPress como um todo (núcleo e comunidade) está perto do limite. Eu pessoalmente posso não responder mais sobre este assunto, mas estou ouvindo comentários e adaptarei meu raciocínio se for convencido por comentários.

Estamos todos no mesmo barco, queremos o melhor para WordPress.

Explicações muito completas, Riad. Obrigado por reservar um tempo para escrevê-los. Deixe-me ajudá-lo a ficar longe desse limite com 💪 e 🤗. Espero que ajude.

Com relação às metaboxes, eu ficaria extático se tivesse uma API Fields no núcleo. Reescreveria nossos plug-ins apenas para se livrar de toda a confusão que as soluções de metaboxes personalizadas tendem a se reunir depois de algum tempo.

Agora, para as pessoas que têm configurações de metaboxes complexas, a API Fields é a sua salvação, desde que sejam construídas em cima de uma estrutura como ACF ou CMB. Os desenvolvedores dessas estruturas precisam apenas mudar para a nova API e está tudo bem. Não é uma tarefa fácil, mas boa para todos. Agora, para aqueles com material "codificado" por aí, agora é um bom momento para reorganizar as coisas de uma forma mais limpa e preparada para o futuro. Você está em melhor forma, Gutenberg ou não.

Nós somos humanos. Tente estar do outro lado da equação, ser aquele que constrói essa coisa e recebe todo esse feedback. A TI pode parecer próxima a “ataques pessoais”, os cérebros tendem a reagir sendo desdenhosos, não devemos.

Existem humanos trabalhando muito em Gutenberg. Existem humanos cujos meios de subsistência (seus temas e plug-ins) serão afetados por Gutenberg. E há humanos que usam os temas e plug-ins afetados por Gutenberg para fazer seu próprio trabalho. Estamos todos cuidando uns dos outros e queremos o melhor para o WordPress no final do dia. Embora possamos discordar veementemente sobre o que "melhor" significa.

Ao contrário do que você lê aqui e ali, o foco sempre foi sobre o redesenho de toda a página. A primeira maquete da Página do Editor de Gutenberg foi exibida na segunda ou terceira reunião semanal de Gutenberg ...

Os mockups por si só não sinalizavam que a base de código de toda a página de edição seria reescrita no React. Ninguém poderia saber, olhando para uma maquete, que ganchos essenciais seriam removidos ou as metacaixas quebradas. No entanto, quando se tornou óbvio para mim que a aquisição de página inteira representaria um problema para as metacaixas, expressei essa preocupação em 15 de junho , um dia antes de 0.1.0 ser marcado para lançamento. Quatro meses e 15 lançamentos depois, foi a primeira vez que realmente vimos metacaixas aparecerem na interface, dentro de iframes.

Eu criei este problema com base em minha experiência acompanhando e testando Gutenberg desde seus estágios pré-alfa. Este é apenas o último problema relacionado aos desafios contínuos da metacaixa, mas, mais importante, é o primeiro baseado em testes concretos de uma implementação da metacaixa de Gutenberg.

A principal diferença é que “Metaboxes” não tem “propósito”, é apenas uma forma de estender a página do editor sem consistência enquanto os Shortcodes e os botões TinyMCE têm um.

Isso novamente sinaliza um mal-entendido fundamental de como as metacaixas são usadas pelos desenvolvedores de plug-ins e temas. Esperamos que os códigos de acesso e os botões TinyMCE precisem ser adaptados porque são realmente usados ​​no editor de conteúdo. As metacaixas não são.

Sugerir que as metacaixas - os blocos de construção básicos do desenvolvimento personalizado do WordPress - não têm propósito novamente, diz à comunidade que Gutenberg está priorizando a experiência central de uma "instalação nova" às custas dos desenvolvedores de plugins e temas.

Qualquer atualização na tela do editor. Qualquer atualização do TinyMCE, qualquer mudança de classe, qualquer novo div, qualquer botão removido / movido, qualquer mudança está quebrando a compatibilidade com plug-ins, porque como um desenvolvedor Core WordPress, você não sabe para que plug-ins está usando Metaboxes.

Podemos não saber o propósito de uma metacaixa, mas conhecemos os requisitos fundamentais para registrar uma metacaixa e os ganchos que ela usa. Sabemos que nenhum deles foi desenvolvido para funcionar com iframes. Por anos, nós entendemos como estender e aprimorar o WordPress sem quebrá-los. Novamente, se 5.0 é apenas mais uma versão do WordPress, a quantidade de quebra não deve ser diferente de qualquer outra versão.

Mostramos as metacaixas em iframes, o que tem suas desvantagens (link, modais, recarga de ativos), mas ao mesmo tempo permite que 80% dos plug-ins funcionem enquanto desfruta de toda a Experiência Gutenberg.

Se você tiver alguma evidência para esses números de 80% / 90% que são constantemente referenciados, compartilhe-a. Do contrário, não use estatísticas hipotéticas ao pedir à comunidade para tomar uma decisão dessa magnitude.

Pare e reavalie agora, não depois

Depois de toda essa discussão e do que eu pensei ser a prova de que iframes não são uma solução viável de longo prazo, me deparei com https://github.com/WordPress/gutenberg/issues/3165#issuecomment -341476059 que parece adicionar um terceiro iframe para Gutenberg.

Já passou da hora de parar de buscar o editor ideal, como se as limitações não existissem, e começar a considerar uma abordagem que não quebra o WordPress.

Falando como um desenvolvedor que tem observado e discutido o editor de Gutenberg desde o primeiro dia, lamento dizer que o argumento de Riad tem algumas grandes lacunas.

Em primeiro lugar, as pessoas têm levantado a questão das metaboxes desde o primeiro dia, junto com várias outras questões que ainda estão no ar. na fase de simulação, fomos informados de que "tudo é o melhor caso visual, trataremos das metaboxes mais tarde". Então, na fase de protótipo, foi "Tudo isso é uma prova de conceito, as metaboxes serão tratadas mais tarde". Então, quando a primeira iteração do plug-in de recursos foi lançada (o que não foi, como uma grande surpresa para ninguém, não foi uma reescrita do zero, e apenas uma nova versão do código de prova de conceito atual), o argumento de repente tornou-se "interfaces legadas como metaboxes terão algum suporte por enquanto". Então, quando o clamor público se tornou ensurdecedor, foi "nós falamos mal, metaboxes não são legados". Mas agora, esse argumento está apenas empurrando a agenda do "legado" novamente.

Metaboxes não são códigos legados, porque atualmente não há uma substituição viável.

Em metaboxes, posso adicionar trivialmente um editor aninhado cheio de recursos usando wp_editor . Gutenberg atualmente não tem UI para blocos aninhados e não está previsto para o lançamento 5.0, portanto, não pode fazer o equivalente, sem uma grande quantidade de código de UI personalizado.

Esse é um único exemplo, mas degradar a experiência das metaboxes não é uma solução aceitável, até que Gutenberg esteja além da paridade. Isso não vai acontecer no WP 5.0

Aqui está um roteiro para o plano de "administração unificada" para Gutenberg que realmente funcionaria:

• limitar a liberação inicial para a área atualmente preenchida por wp_editor, mas fornecer a IU completa do Bloco dentro desse espaço
• promover e expandir a flexibilidade e os recursos que a interface do usuário em bloco permite, enviando uma API de campos que torna trivial projetar naquele espaço
• conforme a popularidade crescer, substitua outras partes da interface do usuário por instâncias de Gutenberg em área restrita semelhantes. Menus, widgets, personalizador e a Biblioteca de mídia são interfaces relativamente estagnadas para os desenvolvedores e podem se beneficiar de uma estrutura de IU comum.
• conforme a IU comum se torna mais flexível e poderosa, as pessoas vão escolher usá-la em vez de metaboxes, porque ela oferece um conjunto comum de ferramentas e mais opções
• gradualmente mesclar os buracos entre as instâncias isoladas de Gutenberg, à medida que o desenvolvimento nesses espaços estagna.

Dessa forma, os desenvolvedores podem começar a utilizar o Gutenberg nas ferramentas de produção sem perder os recursos atuais que possuem. Gutenberg se beneficiará de todos os casos de uso de ponta desenvolvidos para esses desenvolvedores, criando uma solução flexível que realmente atenderá às necessidades daqueles que atualmente usam metaboxes.

Quando as metaboxes forem descontinuadas, os autores dos plug-ins terão tido tempo suficiente para aprender e usar os benefícios do Gutenberg na natureza, e será a escolha óbvia.

Gutenberg é como um carro-conceito. Reduza agora e envie uma melhoria iterativa para o editor (não para a página do editor). Então, nos próximos um ou dois anos, você pode conduzir o projeto para 100% de cobertura do administrador.

Eu só quero entrar na perspectiva de um provedor de serviço ao cliente que referenciou o compromisso vocal do WordPress com a compatibilidade com versões anteriores para aliviar as preocupações do cliente sobre atualizações quebrando seus sites. Com isso, reconheço que meu uso do WordPress provavelmente distorceu / enviesou minha percepção da tela de edição.

Até o momento, parece que esse problema foi punido / descartado / minimizado quando, no meu mundo, as metabaixas têm sido um _maior_ argumento de venda para o WordPress, uma vez que os tipos de postagem personalizados se tornaram facilmente disponíveis para uso generalizado. Estou feliz que essa discussão esteja acontecendo.

Gutenberg é um projeto impressionante, sim, mas os clientes com quem trabalhei estão realmente muito felizes com as soluções baseadas em metacaixas que foram fornecidas. Ter a opção de desativar o Gutenberg é bom, mas estou preocupado com a possibilidade de desativação via plugin. Apesar de meus melhores esforços para orientar os clientes, não imagino que eles estariam dispostos a instalar um novo plug-in por conta própria, nem saberiam o que é Gutenberg, mesmo que seja claramente apresentado em uma tela de boas-vindas de atualização.

É possível (talvez até provável) que os plug-ins de meta box que usei em sites de clientes possam ser atualizados para serem "compatíveis com o Gutenberg", mas mesmo assim todo o fluxo de trabalho vai mudar para esses clientes durante a noite. Parece que está pedindo muito a esses clientes quando o fluxo de trabalho existente tem funcionado bem para eles desde que seu site foi entregue há muito tempo.

Eu defendo totalmente o objetivo de Gutenberg melhorar a experiência do usuário, mas na minha opinião não podemos evitar o precedente que foi criado (intencional ou não) para usar metacaixas para edição de conteúdo. Acho que a abordagem do Yoast é ótima, é algo que marca uma série de caixas de seleção para uma ampla variedade de soluções potenciais para esse problema.

Apenas meus dois centavos, ansioso para observar o resultado aqui.

O número de plugins trabalhando com o Gutenberg pode ser de 80%, 90% ou 0% como em nossos testes, o que deve ser evitado é que milhares e milhares de proprietários de sites têm que descobrir por si mesmos se sua configuração provavelmente funcionará ou não com Gutenberg. Isso seria uma enorme perda de tempo (= dinheiro), causaria muita confusão e mataria muita confiança.

Gostaria de ver plug-ins / temas marcados como compatíveis / não compatíveis com Gutenberg (ou 'não relevantes'), para que os proprietários de sites possam ser informados sobre problemas em potencial antes que isso se torne ativo em seus sites e possam agir de acordo. Os dados não podem vir apenas dos proprietários de plug-ins, mas também de testes da comunidade durante o período de teste beta (o verdadeiro beta ..., e esse período deve ser longo, não apenas algumas semanas.) E além.

Estou ciente de que isso nunca será completo ou 100% preciso, mas deve ser possível para os plug-ins mais importantes.

PS.
Para meus próprios projetos (uma plataforma de microssites de intranet para um cliente> 30.000 funcionários e um monte de sites de pequenas empresas / sem fins lucrativos), decidimos desativar Gutenberg até que estivesse pelo menos um ano de sucesso na selva.

De qualquer maneira, as porcentagens não contam toda a história. Qualquer discussão sobre o impacto de Gutenberg precisa considerar quantos sites são afetados por sua implementação de metabox, em vez de quantos plug-ins são afetados. Gutenberg poderia impactar apenas um punhado de plug-ins e ainda afetar milhões de usuários, já que alguns dos plug-ins mais amplamente usados ​​dependem de metaboxes e campos personalizados - ACF e Yoast SEO são dois exemplos óbvios.

Tenho acompanhado o desenvolvimento de Gutenberg de longe há muitos meses e _sei_ que o problema das metaboxes já existe há muito tempo. Eu apoio a filosofia por trás de Gutenberg e acho que, eventualmente, Gutenberg se tornará uma parte muito poderosa do núcleo do WordPress que permite que o WordPress seja um software viável e competitivo por muitos anos no futuro. Estou TÃO a bordo com todo o conceito de Gutenberg e seu objetivo.

O que eu _não_ entendo é o desejo de ir de 0 a 100 de uma vez. Por que uma versão iterativa não é o caminho que está sendo seguido aqui? Por que as duas opções são 'quebrar nada' ou 'quebrar tudo'?

Metaboxes são a razão pela qual o WordPress é tão poderoso quanto é. Seu objetivo é estender a tela de edição.

Eu acho ótimo que Gutenberg queira revisar a tela inteira, mas eu simplesmente não acho que isso seja realista de fazer de uma vez, especialmente se isso significa tratar um dos componentes mais importantes do WordPress (no que diz respeito ao desenvolvimento personalizado ... que é uma grande parte do sucesso do WordPress) como um aparte.

2- Gutenberg substitui apenas a área de conteúdo: 90% dos plugins funcionam, o UX sofre

A UX não sofre. Os usuários verão como a seção do editor sendo renovada. Isso lhes dará uma nova maneira de criar conteúdo - uma maneira que a maioria deles achará empoderadora após se ajustar, e não quebrará nenhum fluxo de trabalho existente ou os deixará se perguntando como realizar as coisas que costumavam realizar em o editor.

4- Gutenberg com plug-ins compatíveis: Melhor UX possível

Este é um objetivo excelente, mas é o objetivo de longo prazo. Eventualmente sim, com certeza, deve ser Gutenberg com plug-ins que funcionam junto ou dentro da experiência Guteneberg.

Nosso objetivo também é construir Gutenberg de uma forma que possamos reutilizar suas peças para atingir a 2ª e a 3ª opções, se necessário.

Não tenho certeza do que isso significa. Você quer construir o Gutenberg partindo do pressuposto de que todos os plug-ins funcionam apenas com ele e usar essa solução para pedalar de volta às opções 2 e 3? Construindo primeiro em direção ao 2 e, em seguida, iterando para 3, não é isso que nos levará a 4?

Eu gosto do roteiro proposto por @gschoppe , como um desenvolvedor que constrói sites WordPress personalizados, esta é uma abordagem que posso seguir, uma que não afetará negativamente os desenvolvedores ou seus clientes ou usuários normais do WordPress, e ainda nos levará até o fim objetivo de Gutenberg - embora em um ritmo mais fácil de engolir.

Junto com as preocupações de Kevin sobre iframes, gostaria de apontar algumas questões de acessibilidade. Primeiro, embora os usuários que experimentam um site visualmente experimentem framesets e iframes como um todo coeso junto com o resto da página, os usuários de leitores de tela não. Os usuários de leitores de tela experimentam cada quadro em um conjunto de quadros e cada iframe, como uma parte distinta, separada do resto da página, porque as páginas da Web são experimentadas de maneira linear. Alguns leitores de tela, (principalmente o Jaws para Windows, que é o que tem maior participação de mercado de acordo com a pesquisa anual de uso do leitor de tela da WEBAIM), têm uma configuração para ignorar os quadros, incluindo os embutidos, porque podem ser muito chocantes para algumas telas usuários leitores. Quando a configuração de ignorar quadros é chamada, o conteúdo dentro de quadros e iframes desaparece. Mesmo que Gutenberg siga todas as melhores práticas de acessibilidade quando se trata de iframes, pedir aos usuários que desabilitem essa configuração para poder editar totalmente o conteúdo também os expõe a cada instância de iframe e quadro de pior prática na rede. A única outra alternativa para esses usuários é pedir-lhes para criar um perfil separado apenas para usar o Gutenberg, o que não é um processo simples, porque significa que eles precisam configurar cada configuração do navegador e configuração de voz novamente. Isso também significa que eles precisam manter pelo menos dois perfis de navegador separados. Serei a primeira pessoa a dizer ao Jaws para usuários do Windows que migrem para o NVDA em tempo integral por motivos. Gutenberg usar iframes para suporte da metabox não é um desses motivos.

.. minha paciência como um simples desenvolvedor que passou o ano inteiro pensando no melhor caminho possível para o WordPress como um todo (núcleo e comunidade) está perto do limite.

Eu juro que odeio ser rude, mas você pode precisar ser mais grosso nesse caso. Você está frustrado com as respostas em face de um "ano inteiro" que passou pensando sobre isso e obrigado por fazê-lo, mas essas são decisões que vão impactar vários anos de trabalho que outros fizeram.

No meu caso, pelo que estou lendo, quase todos os sites que construí nos últimos 3 anos podem quebrar instantaneamente. Não sou mais responsável por esses sites, mas o que vai acontecer na agência onde eu trabalhava quando dezenas de clientes ligam ao mesmo tempo com sites quebrados. Como isso afetará essa pequena agência, seu trabalho diário, seus resultados financeiros? Como isso afetará seus clientes? Essas são minhas preocupações e sou apenas um pequeno (figurativamente) desenvolvedor neste ecossistema relativamente grande.

Admito que às vezes nós (pelo menos eu) podemos ser indiferentes em meus comentários e peço desculpas por isso.

As pessoas estão preocupadas e ficando frustradas e parece-me que têm todo o direito de fazê-lo, porque a percepção é que a equipe que trabalha em Gutenberg tem pouca compreensão de como as metacaixas estão sendo usadas, pouca preocupação com qual será o impacto, e seguirá em frente com sua visão, não importa o quê.

Fico triste em escrever isso, mas nem em um milhão de anos eu sugeriria que alguém iniciasse um grande projeto com WordPress agora.

2- Gutenberg substitui apenas a área de conteúdo: 90% dos plugins funcionam, o UX sofre

@youknowriad , como você pode dizer que a UX não sofre com Gutenberg versus TinyMCE? Estou genuinamente fazendo essa pergunta, não zombando. Posso dizer que o UX realmente sofre muito em Gutenberg em comparação ao TinyMCE e às metacaixas. Eu o encorajaria a descobrir isso por si mesmo:

(1) Desconectando o mouse.
(2) Se você estiver em um Mack, pressione command + f5 e tente realizar algo produtivo usando o VoiceOver.
(3) Se estiver em um PC, baixe o NVDA, instale-o, desconecte o mouse e execute o mesmo teste. Tente fazer algo produtivo com Gutenberg nessas circunstâncias.

Eu acho que você vai descobrir que a experiência do usuário é um pesadelo absoluto neste ponto. Isso não quer dizer que não possa mudar para melhor. Gutenberg oferece uma oportunidade para o WordPress limpar muitas dívidas técnicas no que diz respeito à acessibilidade, e se isso for feito com cuidado e corretamente, então algumas grandes conquistas podem ser obtidas. Mas se isso for feito de maneira incorreta ou descuidada, muito do trabalho que a Equipe de Acessibilidade do WordPress e outros colaboradores importantes fizeram desde 2012 precisarão ser reiniciados. Eu gostaria de ver o WordPress como um projeto que não cometesse o mesmo erro com que começou: não considerar a acessibilidade da web desde o início, o que significa que a equipe de acessibilidade e outros contribuidores preocupados se encontraram tentando acessibilidade após o fato, o que é uma tarefa que nunca pode ser alcançado, já que o WordPress não é uma base de código estagnada.

Eu entendo que vocês estão trabalhando em Gutenberg há um ano. Também entendo que trabalhar nisso é difícil por si só, e que feedback negativo não ajuda nessa situação. Por fim, entendo que pode parecer que aqueles de nós que estão sendo tão críticos quanto nós parecem estar chamando seu bebê de feio ou simplesmente reagindo ao medo da mudança e, como criador, isso é frustrante na melhor das hipóteses e doloroso na pior . Mas falando por mim, o bebê não é feio. Ele tem muito potencial não realizado para ser o garoto mais legal do bairro ou o idiota que torna a vida de todos miserável. Eu gostaria de ver que fosse o primeiro e não o último. Com relação às metacaixas especificamente, elas são um grampo literal do desenvolvimento personalizado do WordPress, provavelmente mais do que códigos de acesso ou botões TinyMCE. Eles não devem ser escovados levemente ou colocados em um iframe até que possamos descobrir como nos livrar deles.

Minha história simples com o WordPress é que ele tem sido meu mecanismo de escolha de sites para criar sites para clientes individuais, pequenos negócios e empresas por mais de uma década. Nesse tempo, três coisas fizeram do WordPress a ferramenta de escolha:

1. Código aberto. Acho que esse público pode concordar como isso é poderoso e vantajoso.
2. Fácil de usar. O WordPress tornou incrivelmente fácil para não desenvolvedores criar e atualizar conteúdo. Isso foi enorme nos meus primeiros anos de criação de sites para indivíduos e empresas.
3. Definindo conteúdo. Tipos de post personalizados, taxonomias personalizadas e metacaixas personalizadas. Quando tudo que levou a isso atingiu uma singularidade, não acho que estou alcançando quando digo que é quando o WordPress era "vendável" para a comunidade empresarial como mais do que apenas um software de blog. (WordCamp Phoenix 2012 - CMB. Excelente redação de Justin Tadlock sobre a definição de tipos de postagem, taxonomias e metacaixas.)

Eu iria mais longe a ponto de dizer metacaixas personalizadas - essa capacidade de criar interfaces de administração personalizadas, criando uma ótima experiência do usuário para as pessoas, é enorme. Quebre isso e você está quebrando o WordPress .

A ideia por trás de Gutenberg, tornando a experiência do editor de conteúdo mais poderosa, é uma ótima ideia. Vale a pena fazer, mas deve ser bem feito, com cuidado e sem pressa. No momento, parece muito apressado e longe de estar pronto.

@jchristopher diz muito bem:

Eu defendo totalmente o objetivo de Gutenberg melhorar a experiência do usuário, mas na minha opinião não podemos evitar o precedente que foi criado (intencional ou não) para usar metacaixas para edição de conteúdo. Acho que a abordagem do Yoast é ótima, é algo que marca uma série de caixas de seleção para uma ampla variedade de soluções potenciais para esse problema.

@jnicol e @aurooba fazem ótimos pontos e fazem boas perguntas. Por que parece que é tudo ou nada em vez de mais um roteiro iterativo? A alternativa de Yoast é muito mais sensata do que o que foi visto e acho que o “experimento iframe” prova isso. Obrigado, @amandarush , por

@aaronjorbin disse antes, quando alguém adota o WordPress, eles não estão adotando o WordPress (versão-número-aqui), eles estão adotando o WordPress como um todo.

Existe uma outra versão disso, que qualquer pessoa no atendimento ao cliente provavelmente ouve com frequência. Quando alguém chega até você e diz que precisa de um novo site (não estamos falando de blogs), geralmente não diz: “Preciso de um novo site Wordpress” ou "Quero um novo site Drupal" etc. Eles querem apenas um novo site, que funcione e funcione bem.

O WordPress tem sido a melhor solução para milhões de sites: facilidade de uso e código aberto sendo a chave. Quebrar as metacaixas personalizadas (esqueça os números do plugin, e todos os sites existentes com UIs de administrador personalizadas?) Com uma implementação apressada de uma nova interface do editor prejudica a facilidade de uso.

minha paciência como um desenvolvedor simples que passou o ano inteiro pensando sobre a melhor maneira possível de seguir em frente para o WordPress como um todo (núcleo e comunidade) está perto do limite.

Vou ser franco, aqui:

Este e alguns outros comentários como este me fazem pensar que alguns de vocês deveriam se afastar de papéis de tomada de decisão neste projeto. Se você não pode aceitar um feedback honesto e bem pensado, mas crítico sobre um produto, então, francamente, você não deve estar em uma função de tomada de decisão em uma equipe de produto. Já estive no seu lugar várias vezes, geralmente em reuniões cara a cara e, nos casos de sucesso, todos na sala perceberam que, por mais acalorado que o debate ficasse, era sobre entregar o melhor produto que podíamos aos clientes. Receber críticas sobre ideias e direção de produtos faz parte de ser um tomador de decisões em uma equipe de produtos e deve levar a um produto melhor, porque ninguém consegue pensar na melhor maneira de fazer tudo. Isso vale para as equipes também.

Não tenho dúvidas de que todos na equipe principal desejam fornecer uma revisão do WordPress incrível, mas você inevitavelmente chega perto de um projeto; você sabe o que foi debatido, considerado, rejeitado, etc. e é difícil puxar para cima e ver as coisas de uma perspectiva externa. Mas você não é a totalidade da comunidade WP; você não pode ser. O que você está ouvindo são preocupações válidas sobre a direção do produto. Se você não pode levar isso em consideração, pense no que está sendo dito e por que está sendo dito, então, por favor, afaste-se de tomar decisões sobre a direção de Gutenberg.

Alternativamente (e isso seria MUITO melhor), assuma esses pensamentos. Considere verdadeiramente o que as pessoas estão dizendo. Entenda nossas preocupações como pessoas que administram negócios que usam o WordPress e entendam que estamos preocupados não apenas conosco, mas também com nossos clientes.

Uso o WP desde o início de 2008 e não consigo pensar em um novo recurso ou decisão que criou tanta divisão em todo aquele tempo quanto a introdução de Gutenberg, em sua forma atual.

Embora o WordPress seja voltado para os usuários, é apenas uma ferramenta, e os usuários simplesmente não serão capazes de fazer uso dessa ferramenta se não tiverem profissionais do WP por perto para ajudá-los a atingir seus objetivos.

Estou vendo referências de querer atender aos usuários de uma nova instalação (o que? ~ 1% do aumento da web por ano?), Mas isso parece estar à custa da base de usuários existente (~ 28%), o a maioria deles provavelmente está executando um plug-in que tem pelo menos uma caixa-meta. Isso parece um fraco senso de negócios em qualquer escala.

Eu entendo a ideologia: criar um editor de melhor caso e, em seguida, usar um padrão de adaptador para envelhecer conversando com o novo. O problema é que PHP e JS são tecnologias diferentes e passar esse problema para a terra dos iframes HTML não é viável, por todas as razões apresentadas anteriormente.

Foi a primeira passagem, foi uma experiência, mas este esforço não teve sucesso. Quanto mais rápido for confirmado, mais rápido podemos passar para a próxima sugestão.

No entanto, ninguém propôs uma solução adequada quando se trata do caso de metacaixas que satisfaça todas as partes.

Isso significa que uma parte precisa ceder - e se são 10-50 desenvolvedores pró-Gutenberg, ou centenas / milhares de desenvolvedores que estão _assustados_ ou o impacto que as mudanças terão para eles, quanto mais para seus usuários, veremos.

Depois que todas as sugestões de soluções alternativas forem esgotadas, talvez haja uma concessão de que substituir a página inteira não é viável para todas as partes. Pelo menos não no único golpe que está sendo tentado.

Voltando à questão original - os iframes são a solução de longo prazo para as metacaixas? Vários desenvolvedores (e não vamos esquecer, eles também são usuários) explicaram por que a resposta é não.

Temos tido uma discussão bastante construtiva aqui. Lembrar:

Criticamos ideias, códigos e pixels, não os humanos por trás deles. Podemos ter opiniões diferentes sobre o melhor caminho a seguir, mas não questionamos as credenciais. Quando nos dirigimos a indivíduos, é para levantá-los e dar-lhes crédito por um trabalho bem executado. Com tanta coisa acontecendo no mundo, temos que cuidar uns dos outros. Este é um desafio monumental, mas vamos chegar lá juntos.

Deixe-me lembrar a todos que metaboxes em Gutenberg foi o resultado de um @ BE-Webdesign se intensificando e fazendo isso, independentemente de todos os outros com pouca ajuda, surgindo do nada. Se não fosse por @ BE-Webdesign, não haveria metaboxes em Gutenberg. Dos 47 comentários deixados aqui, talvez apenas 2 pessoas realmente tocaram no código da metabox para fins de revisão e UX.

O problema fundamental aqui, porém, é como colocar com segurança as metaboxes na página como cidadãos de 1ª classe sem construir código inseguro, levando a uma troca de kludges hacky ou pegadinhas.

• A primeira iteração envolveu um pegadinho, fazendo o WP fingir que estava na página edit.php e gerar as metaboxes dessa forma. Os relatórios iniciais indicaram que ele tinha problemas de compatibilidade e era muito hacky, e não era uma solução viável. Isso ocorre porque muitos plug-ins só registram metaboxes se certas circunstâncias forem atendidas e não confiam no WP para saber quando renderizá-los
• A segunda iteração que foi mesclada usa iframes, de modo que as metaboxes estão sendo exibidas no editor clássico, embora com tudo, exceto a metabox removida. Isso é um pouco confuso, mas fez com que as metaboxes funcionassem, embora com problemas
• Também existe uma solução em que buscamos o código HTML e o inserimos no atacado em um componente, o que seria uma catástrofe de segurança, apesar de ser a solução super óbvia. Daí porque não foi feito desta forma.

Minha sugestão é:

em vez de carregar o Gutenberg em uma página de configurações, vamos carregá-lo na página principal dos editores clássicos, carregar metaboxes em seu ambiente nativo e, em seguida, içar seu nó DOM do contêiner em um componente via JS

Em seguida, usamos um tipo diferente de alternância para garantir que o editor clássico ainda possa ser usado. Deste jeito:

• evitamos o absurdo do iframe
• metaboxes funcionam como sempre funcionaram no que diz respeito ao registro
• o JS existente funciona conforme o esperado e não são necessários hacks para fazer as coisas funcionarem no lado do PHP

Além disso, o design do yoast é bonito, mas para onde vai o meta-bloco?

Infelizmente, tenho muito pouca experiência com js no nível necessário para contribuir com código real para Gutenberg. Estou apenas começando a mergulhar no mundo do desenvolvimento do WordPress, em vez de desenvolver em cima dele. Portanto, o melhor que posso fazer é fornecer meu feedback, testar o editor (eu uso ativamente Gutenberg em meu blog pessoal) e fornecer sugestões / idéias. Se eu _pudesse_ contribuir com código, com certeza o faria. Se houver outra maneira de ajudar, adoraria saber. Porque eu me importo muito com isso. :)

Contribuir vem de várias formas. Embora o tempo e o esforço investidos no desenvolvimento dessa tentativa sejam apreciados, os testes e a discussão que evitam custos irrecuperáveis ​​futuros podem ser igualmente valiosos. Por exemplo, há vários problemas abertos recentemente relacionados à implementação do iframe. Poderíamos passar muito mais horas tentando consertar esses problemas, ou poderíamos usar o teste e a lógica neste tópico para determinar se uma direção diferente é necessária. Espero que essa seja a conclusão a que chegamos como um grupo.

Deixe-me lembrar a todos que metaboxes em Gutenberg foi o resultado de um @ BE-Webdesign se intensificando e fazendo isso, independentemente de todos os outros com pouca ajuda, surgindo do nada. Se não fosse por @ BE-Webdesign, não haveria metaboxes em Gutenberg.

Embora o elogio e a adoração sejam bons 😄, definitivamente tive ajuda, e é em grande parte um esforço de equipe de muitas pessoas.

Minha sugestão é:

em vez de carregar o Gutenberg em uma página de configurações, vamos carregá-lo na página principal dos editores clássicos, carregar> metaboxes em seu ambiente nativo e, em seguida, içar seu nó DOM do contêiner em um componente via JS

Sim, esta é provavelmente a próxima iteração e acho que é uma ótima sugestão, bem como uma ideia construtiva. Ainda não tenho 100% de certeza de como fazer isso de forma limpa, mas é inteiramente possível não usar iframes e ter a mesma experiência do usuário aprimorada que Gutenberg já está fornecendo. Haverá atualizações para melhorar a experiência da metacaixa, o que provavelmente envolverá a eliminação de iframes. O método iframe serviu como uma forma de ver como o suporte a meta box poderia ser implementado, agora melhorias melhores serão feitas. Quando as coisas estavam sendo exploradas pela primeira vez com metacaixas há muitos meses (não é um tópico novo), fazia sentido avançar com a abordagem iframe, devido ao estado de Gutenberg naquela época, agora que foi fundido e muitas outras peças foram movidas ao redor, o uso de iframes provavelmente não é mais necessário, do ponto de vista técnico. Mais trabalho precisará ser feito.

@ BE-Webdesign Obrigado por seus esforços e contribuições aqui. Vamos encerrar isso e começar um novo problema quando essa abordagem estiver pronta para discussão.

Pare e reavalie agora, não depois

Nem todo mundo está acostumado com essa abordagem de design de projeto, mas este é um projeto que segue uma contínua reavaliação diária de quase tudo. Compare as maquetes originais com o editor atual. As coisas mudam. A maioria das peças não é gravada em pedra. A única maneira de avaliar verdadeiramente se algo vai funcionar é realmente fazê-lo. Nem todo mundo aborda o design de produto da mesma maneira, mas acho que a rápida iteração de Gutenberg tem servido bem, em vez de tentar descobrir o que é desconhecido com antecedência.

Obrigado a todos pela discussão. Fico feliz que a conversa tenha sido redirecionada no final para o problema do tópico: _a abordagem atual para metacaixas em um iframe é viável_? Com a resposta sendo não. Os iframes são um detalhe de implementação que podemos eliminar com relativa facilidade. Então, vamos nos concentrar nisso.

Gostaria de acrescentar, como algumas considerações finais, que não mudar nada na tela de edição seria o caminho mais simples para nós fazermos. Também não seria justo com os objetivos do projeto e os usuários de longo prazo do WordPress. O que algumas pessoas chamam de abordagem pragmática não é concomitante com a direção de design que este projeto teve desde o início - rumo à personalização total do site - e o que ditou nossas decisões até agora. Nada aqui tem que ser uma solução final, estamos explorando o que é possível dentro das premissas de design e colocando-o lá para teste. Isso não pode ser construído somente por nós e sinceramente acolhemos toda a ajuda que pudermos obter de todos vocês, pois há vários problemas difíceis enterrados no caminho a serem superados.

O WordPress sempre se move com o usuário e assumimos o fardo de descobrir caminhos de desenvolvimento para facilitar as transições para nosso código existente. Como projeto, dissemos antes que não estávamos retirando o suporte para metacaixas do WordPress, mas também que tínhamos que explorar quais decisões de interface teríamos que tomar dentro do novo paradigma, incluindo a possibilidade de carregar o editor clássico quando detectamos metacaixas que não podemos manipular ou que entram em conflito direto com um editor que busca delinear mais claramente o que é conteúdo e o que é metadado. Existem pessoas por aí que poderiam se beneficiar da experiência padrão de Gutenberg agora. Como desenvolvedores, temos o privilégio de poder fabricar soluções, mas também a responsabilidade de não iludir as mudanças que temos que fazer para permitir que pessoas, que de outra forma teriam dificuldades, tenham sua presença na web aberta.

@mtias Eu realmente aprecio seu comentário sensato, especialmente a parte sobre "WordPress sempre se move com o usuário".

Infelizmente, isso está totalmente em desacordo com o que @youknowriad tem comunicado neste tópico, e como vocês dois trabalham na Automattic, recomendo que falem com ele sobre a direção do produto, porque agora estamos recebendo sinais confusos.

Infelizmente, você não abordou o esboço de Yoast proposto, que nos daria toda a flexibilidade de Gutenberg ao mesmo tempo em que seria compatível com as metaboxes existentes. Por que ninguém reconhece por que você não está considerando essa abordagem?

Infelizmente, isso está completamente em desacordo com o que @youknowriad tem comunicado neste tópico

Eu acho que você apenas entendeu mal o que eu disse, eu estava apenas enumerando fatos e compartilho pensamentos de @mtias 100%

@mtias

O que algumas pessoas chamam de abordagem pragmática não é concomitante com a direção de design que este projeto teve desde o início - rumo à personalização total do site

Eu realmente discordo dessa visão. Fazer um aprimoramento iterativo restrito ao próprio editor, mas com o poder de substituir metaboxes, bem como liberar e promover uma API de campos, seria uma maneira suave de fazer a transição da massa de plug-ins para um paradigma de bloco, simplesmente pela facilidade de uso , em comparação com a paisagem fragmentada que temos agora.

Fazendo essa transição intermediária sem problemas, você tornaria muito mais fácil descontinuar a geração / manipulação direta de DOM na tela post_edit, porque, a essa altura, a solução padrão na prática não envolveria mais essa manipulação. Não acredito que alguém esteja dizendo "a manipulação direta do DOM precisa ser a experiência primária para sempre". Eles estão dizendo "É a solução primária agora".

se você pode manter a flexibilidade completa de manipulação de dom com uma solução de tela inteira, vá em frente ... mas esse parece ser um objetivo muito elevado, e eu duvido que qualquer forma de içamento da tela de edição clássica seja realmente capaz de entregar em qualquer nível razoável de compatibilidade. Talvez eu esteja errado, mas parece um hack incrivelmente complicado tentar fazer a transição de usuários, quando uma abordagem mais iterativa poderia fazer o mesmo trabalho.

Ao reter a primazia do paradigma atual, enquanto lança o novo, você incentiva a adoção sem prejudicar a experiência atual de ninguém. Então, depois que a maioria dos fluxos de trabalho fez a transição para um paradigma de bloco, o controle de dom direto pode ser descontinuado em favor de uma solução de tela inteira.

Não é trair os objetivos do projeto, simplesmente abordar o cronograma de lançamento para tornar a mudança mais gerenciável para milhares de agências e desenvolvedores.

@youknowriad Deixe-me postar alguns trechos do que você escreveu para apoiar o que estou dizendo:

aproveitando a API REST, a interface do usuário do lado do cliente e unificando os conceitos básicos: widgets, códigos de acesso, blocos, caixas de conteúdo de conteúdo sob um conceito exclusivo “Um bloco”

Ninguém pediu que "metaboxes de conteúdo" fossem transformadas em blocos e isso não foi comunicado até que Gutenberg lançou sua versão inicial. Na verdade, é disso que trata o cerne da discussão. Não vou repetir o que outros disseram muito melhor, apenas que metaboxes muitas vezes não são conteúdo de página.

Ao contrário do que você lê aqui e ali, o foco sempre foi sobre o redesenho de toda a página. A primeira maquete da Página do Editor de Gutenberg foi exibida na segunda ou terceira reunião semanal de Gutenberg. Ainda estávamos na fase de prototipagem.

A equipe de Gutenberg dizia que os esboços eram apenas para exibição e não o design final. Além disso, um esboço não pode mostrar se toda a tela de edição foi convertida para React ou se apenas recebeu um estilo diferente. O fato de que a página inteira seria redesenhada foi uma grande surpresa para todos com quem falei.

Qual é a diferença entre Shortcodes, Botões TinyMCE e Metaboxes?
A principal diferença é que “Metaboxes” não tem “propósito”, é apenas uma forma de estender a página do editor sem consistência enquanto os Shortcodes e os botões TinyMCE têm um.

Este é um grande equívoco que deve levantar sobrancelhas dentro do Automattic. (E espero que @mtias e @m estejam ouvindo). Simplesmente não é verdade e eu realmente questiono seu julgamento após esta declaração.

Podemos concluir que, para o longo prazo do WordPress, os Metaboxes estão bloqueando sua evolução (independentemente de Gutenberg)?
Sim, eles estão.

Eu diria que quase ninguém concorda com você aqui, e acho que a Automattic precisa submeter isso a uma votação para determinar a direção do produto.

Eu também questiono @mtias dizendo coisas como pessoas precisando contribuir. É óbvio que a equipe de Gutenberg associada à Automattic não está se mexendo um centímetro e está evitando todas as críticas.

Eu tenho literalmente zero de fé que se eu fizesse um PR para reduzir Gutenberg para ser apenas o componente de edição, seria considerado pela equipe de Gutenberg, devido a declarações feitas por alguns indivíduos dentro da Automattic.

@mtias ,

Gostaria de acrescentar, como algumas considerações finais, que não mudar nada na tela de edição seria o caminho mais simples para nós fazermos. Também não seria justo com os objetivos do projeto e os usuários de longo prazo do WordPress.

Indo um passo de cada vez não, de forma alguma, comprometer os objetivos do projeto. Você ainda pode ir para a personalização em tamanho real se esse for o objetivo, mas ao fazer isso de forma gradual, você trará o resto da comunidade de desenvolvedores com você.

O Customizer é um excelente exemplo disso. Sim, tem seus críticos, mas o conceito final será realizado com o tempo, como um recurso que permite a certos grupos de usuários utilizar o WP de forma eficiente como ferramenta de gerenciamento de seu site.

Existem pessoas por aí que poderiam se beneficiar da experiência padrão de Gutenberg agora.

Absolutamente. Mas também há um número consideravelmente maior de pessoas que teriam uma experiência prejudicial com o Gutenberg padrão agora.

Espero que possamos seguir em frente com respeito e separar as pessoas do produto em nossas respostas. Paixão é ótimo, mas é importante pensarmos nos humanos com quem interagimos em tópicos como este. Cada pessoa envolvida neste projeto se preocupa, eles não estariam entrando nesses tópicos e interagindo se não o fizessem. Agora, vamos respirar fundo e lembrar o quanto todos nós nos preocupamos com o WordPress e queremos, no fundo de nossos comentários, manter esta comunidade segura e produtiva para todos.

@khromov , como líder de design deste projeto, assim como Matias é o líder de tecnologia, estou 100% atrás de @youknowriad. Eu entendo que você é apaixonado, mas não está sendo respeitoso. Ajuste a abordagem que você está adotando chamando uma única pessoa. Vamos parar de ser pessoais.

É importante também lembrar que muitos dos que trabalharam em Gutenberg foram membros da comunidade WordPress antes, foram (ainda são) contribuidores principais antes. Sim, isso inclui a mim mesmo. Vou falar superpessoal aqui. Assim que você fizer uma RP, por favor me avise e eu darei uma olhada e verificarei se ela tem o mesmo respeito que todas as avaliações, não importa de onde elas venham. Por favor, vamos continuar vendo este projeto como um 'nós v eles'. Não é, e temos alguns contribuidores não automáticos incríveis aqui, essa afirmação os prejudica.

@khromov

Geralmente sou visto como um detrator de Gutenberg, pois minhas postagens e comentários destacam os problemas que vejo com a abordagem e implementação, mas sinto que os objetivos e o progresso de Gutenberg são às vezes mal interpretados nos comentários, devido a uma falha de comunicação ou falta de compreensão de objetivo geral do projeto.

Os blocos não são uma forma visual de representar e editar o conteúdo da postagem, eles também não precisam fazer parte de um menu seletor de conteúdo ou arrastar / soltar. Eles podem ser usados ​​para essas coisas, é claro, e esse é o fluxo de trabalho que muitas das partes visíveis de Gutenberg destacaram. No entanto, ignore o que você sabe sobre esse paradigma por um momento e, em vez disso, olhe para ele desta forma:

Os blocos devem ser uma estrutura de controle fundamental para o site, independentemente da interface ou armazenamento.

• Os widgets estão programados para se tornarem blocos. Isso NÃO significa que eles existirão no editor e serão salvos no post_content. Significa simplesmente que eles serão controlados por um sistema construído em uma estrutura JavaScript, com uma única API comum.
• O Customizer está programado para ser substituído por blocos. A interface provavelmente permanecerá (aproximadamente) a mesma, mas as seções do Customizador serão controladas pela mesma API.
• A página de plug-ins, o editor de tema, o próprio painel, estão todos programados para eventualmente se tornarem blocos. Se a ideia dessas seções, exatamente como estão, é impossível de imaginar recriada com uma API comum, então você provavelmente tem alguns conceitos errados ligados ao que é um bloco, no jargão do WordPress.

O problema não é que as metaboxes não possam ser recriadas dentro do paradigma de bloco; na verdade, blocos não front-end que são adicionados programaticamente a um tipo de postagem, bloqueados no local e armazenados em pós-meta em vez de post_content a versão 5.0 do WordPress (corrija-me se eu estiver errado).

Em essência, isso cobre todas as necessidades de meta-campos triviais, como caixas de texto e seleções. Você poderia duplicar exatamente essa interface em blocos, se quiser, ou poderia simplificar parte dela, com base na nova linguagem visual que bloqueia o fornecimento ... isso seria inteiramente sua escolha.

O problema não é que as metaboxes nunca possam ser blocos. O problema é que, neste momento, existem interfaces feitas em metaboxes, que ainda não são suportadas em blocos (seja por WordPress ou terceiros), e reimplementar esse trabalho é uma tarefa hercúlea para desenvolvedores, especialmente porque essas ferramentas não foram construídas a partir de uma API comum como a API Fields proposta, mas de uma maneira confusa que modifica diretamente o DOM da página e enfileira os recursos de forma ad-hoc e não gerenciada.

Este estado atual também causa problemas para os desenvolvedores. Por exemplo, se você usar o Visual Composer, junto com o Piklist para campos, o Piklist substituirá muitos de seus estilos de administração, tornando a navegação do VC muito difícil.

Ou se você estiver usando WooCommerce junto com qualquer plug-in que enfileire a nova versão da Biblioteca Select2, um ou outro quebrará sua interface de administração, com um erro JS crítico.

A mesma coisa pode acontecer se dois plug-ins diferentes dependerem de versões diferentes da estrutura CMB2.

Os blocos pretendem resolver esses problemas introduzindo uma estrutura comum em torno das várias adições de página. Parte dessa estrutura será focada em oferecer recursos visuais de arrastar e soltar wiz-bang para o editor, mas a maioria não está realmente ligada a isso. É apenas garantir que as coisas que aparecem no administrador sejam gerenciadas de uma maneira comum.

Agora, há argumentos válidos de que o WordPress prosperou em uma atitude de desenvolvimento do Velho Oeste, e que essa estrutura comum levanta a barreira de entrada para desenvolvedores que não sabem reagir. E há argumentos válidos de que a interface Block não alcançará nada perto de uma ampla adoção de desenvolvimento antes do lançamento. Existem até mesmo argumentos válidos de que a API de bloco atual é um pouco ingênua e não leva em consideração muitos fluxos de trabalho comuns, tornando impossível adaptar plug-ins até que esses recursos sejam criados e documentados.

Mas argumentar que a Metabox free-for-all, como é, é a solução definitiva e deve ser preservada para a eternidade não oferece um grande caminho a seguir para ninguém. Para que o WordPress seja capaz de oferecer melhores opções para todos os usuários, devs incluídos, algum tipo de sistema comum precisa existir.

Teria sido bom se este sistema fosse uma API Fields comum, anos atrás, de forma que todas essas mudanças seriam na maioria apenas uma substituição da etapa de renderização para aquela API, mas do jeito que está, um caminho a seguir precisa ser encontrado.

Dito isso, ainda sou fortemente a favor da solução provisória proposta pela Yoast, como sendo a melhor maneira do mundo real de avançar em direção a uma eventual interface do usuário comum. Continuo crítico, é claro, mas quero ter certeza de que somos críticos dos fatos, e não de mal-entendidos.

Infelizmente, isso está totalmente em desacordo com o que @youknowriad tem comunicado neste tópico, e como vocês dois trabalham na Automattic, recomendo que falem com ele sobre a direção do produto, porque agora estamos recebendo sinais confusos.

Eu diria que quase ninguém concorda com você aqui, e acho que a Automattic precisa submeter isso a uma votação para determinar a direção do produto.

É óbvio que a equipe de Gutenberg associada à Automattic não está se mexendo um centímetro e está evitando todas as críticas.

Eu tenho literalmente zero de fé que se eu fizesse um PR para reduzir Gutenberg para ser apenas o componente de edição, seria considerado pela equipe de Gutenberg, devido a declarações feitas por alguns indivíduos dentro da Automattic.

Eu gostaria apenas de afirmar o óbvio, mas Gutenberg é um projeto da comunidade WordPress, não um produto Automattic . Eu posso ser um automatizador, mas isso não me dá mais autoridade neste projeto do que qualquer outra pessoa, seja um freelancer, CEO de agência ou um desenvolvedor dedicado cumprindo um compromisso de 5% da empresa, ao contrário do que algumas pessoas sugeriram. Da mesma forma, o próprio WordPress é um projeto comunitário, não um projeto Automattic.

Automattic não "lança" ou "constrói" WordPress, e Gutenberg não é um produto Automattic

Além disso, antes que esta conversa se torne ainda mais emocional e as pessoas percam de vista a floresta por causa das árvores, gostaria de dedicar um tempo para avaliar a dificuldade da tarefa que foi atribuída à equipe de Gutenberg e como eles estão lidando com ela. em geral. Eles foram encarregados de criar um paradigma que se tornará a base de toda a experiência de administração do WordPress, dentro de restrições que apenas permitem que demonstrem sua eficácia em um pequeno canto da interface.

A quantidade de mal-entendidos causados ​​pela ideia de que "o editor está assumindo" é imensa e deve ser muito difícil de administrar. Sua função é criar os blocos de construção comuns para o administrador do WordPress e testá-los reconstruindo o editor. Embora eu acredite que essa tarefa seria muito mais palatável e flexível para o público se eles estivessem apenas reconstruindo a interface wp_editor() e expandindo a partir daí, é compreensível que todos os componentes conectados da 'experiência de edição' façam um ensaio mais completo para o novo paradigma proposto.

Eu entendo e agradeço o ano de esforço dedicado a este trabalho. Ainda sou crítico em relação a algumas das decisões tomadas e acredito que há tempo para fazer algumas modificações que irão melhorar muito a adoção inicial, mas estou totalmente de acordo com o objetivo geral de eventualmente fornecer uma estrutura mais estruturada para a experiência de administração do WordPress , para desenvolvedores e usuários.

@karmatosed

O motivo pelo qual mencionei @youknowriad é que ele foi o único envolvido na discussão. Uma discussão que envolveu centenas de desenvolvedores e milhares de horas sem nenhum avanço, apesar de haver um consenso claro do lado dos desenvolvedores. Não acho desrespeitoso questionar a legitimidade das decisões tomadas quando são feitas por um pequeno grupo de desenvolvedores, mesmo que isso envolva chamar pessoas específicas.

Apesar disso, tive uma conversa privada com @youknowriad e ele me explicou o roteiro que está por

@tomjn

Eu respeitosamente discordo. As decisões importantes são tomadas por automáticos e, depois de uma conversa com @youknowriad , entendi que a direção do produto já está definida por muito tempo, então não há nada para nós, colaboradores regulares, fazermos a não ser corrigir bugs e talvez alguns efeitos visuais menores ajustes.

@gschoppe Eu só queria que essa "mudança de paradigma" fosse discutida abertamente e feita em colaboração com a comunidade de desenvolvedores. Talvez seja essa a intenção, mas nesse caso o lado da comunicação não está funcionando muito bem.

Por que ninguém reconhece por que você não está considerando essa abordagem?

@khromov tivemos já , e em alguns outros lugares nos chats editor, etc. Esse problema em particular foi sobre a implementação iframe.

Eu tenho literalmente zero de fé que se eu fizesse um PR para reduzir Gutenberg para ser apenas o componente de edição, seria considerado pela equipe de Gutenberg, devido a declarações feitas por alguns indivíduos dentro da Automattic.

De modo nenhum. Nós mesmos o consideramos muito cedo, vendo-o muito limitador e inadequado para conduzir a visão que tínhamos. Ainda pode ser um meio-termo razoável para muitos e pode ser um bom plugin para explorar. O trabalho necessário para que isso acontecesse, porém, melhoraria Gutenberg em geral, tornando-o mais reutilizável, então eu não me oporia a pessoas trabalhando nele. Se alguém trabalhou nesse tipo de RP, provavelmente sugiro adicionar uma configuração na seção Escrita para alternar o comportamento em vez de torná-lo o padrão.

Temos recursos significativos em torno de blocos aninhados, blocos globais, modelos de bloco declarados, colunas, etc., que realmente se beneficiam da planilha de conteúdo sendo a página inteira e, de outra forma, pareceria ruim, limitando o que os desenvolvedores podem fazer e o que os usuários podem experimentar. Existem também ferramentas interessantes, como o esboço do documento, que se integram perfeitamente e em tempo real no editor de tela inteira, que seriam concebidas em uma mera substituição do TinyMCE.

Dar um passo de cada vez não compromete, de forma alguma, os objetivos do projeto.

Definitivamente! Propusemos uma abordagem em estágios, da postagem original de novos focos de Matt, que apenas considera as etapas de forma diferente. Geralmente, há três estágios para o projeto Gutenberg: do editor de postagem, aos modelos de página e à construção do site. O que é primordial é que o paradigma é aquele em que o conteúdo é uma área única, com o _bloco_ como conceito primário, e onde o resultado pode ser representado visualmente com clareza e sem abstrações excessivas.

Absolutamente. Mas também há um número consideravelmente maior de pessoas que teriam uma experiência prejudicial com o Gutenberg padrão agora.

Claro, e é por isso que há um plugin para voltar à experiência atual à vontade, e teremos mecanismos para lidar com incompatibilidades, permitindo que mais coisas sejam ativadas (digamos, se você se sentir confortável com suas metacaixas mostrando em Gutenberg você pode declarar apoio a ele, ou vice-versa).

@gschoppe Sei que tivemos nosso quinhão de divergências no passado, mas agradeço seus comentários aqui e sua vontade de participar, mesmo sob os diferentes pontos de vista. Você faz alguns pontos positivos sobre o fator de aglutinação do bloco. Talvez um dia nos encontremos em uma conferência WC e possamos embarcar em uma divertida discussão filosófica sobre o navio do paradoxo de Teseu. Quem sabe. 😉

Você da Automattic não deve reclamar que não podemos respeitar seu trabalho e que estamos pressionando muito você.
Não para o salário mensal de 7.000 - 10.000 € que você recebe. Boba. Não é como quando as pessoas reclamam no WP Trac para os desenvolvedores voluntários.
Se Gutenberg lhe der dor de cabeça, converse com seu chefe. Ele deu a você uma tarefa impossível de fazer.

Em segundo lugar, vocês são codificadores muito melhores do que a maioria das pessoas que comentaram aqui. Por que você tentou passar na solução "Iframes"?
Eu te disse, você trata as pessoas como crianças. Vamos tentar com iframes e ver se as pessoas gritam muito, se emocionam muito. Se houver muito ruído, afastamo-nos dos iframes.

Por que você tentou passar na solução "Iframes"?
Eu te disse, você trata as pessoas como crianças. Vamos tentar com iframes e ver se as pessoas gritam muito, se emocionam muito. Se houver muito ruído, afastamo-nos dos iframes.

Quando o suporte a meta box foi implementado pela primeira vez, o novo editor existia em uma página de administração inteiramente nova, não post.php, o editor carregava de forma diferente e, em geral, havia muitas restrições, parte da resolução do problema de meta box usando iframes, iluminou alguns dessas restrições, que não existem mais e, como resultado, as metacaixas, muito provavelmente não precisarão mais usar iframes.

Este projeto favorece a melhoria incremental entre as versões em vez da perfeição em uma única versão. Ninguém está tentando ver se as pessoas vão gritar. A realidade é que a abordagem iframe funcionou bem para a maioria das metacaixas, apesar de como as pessoas a transformaram. Agora ele será melhorado ainda mais, e haverá cada vez menos 😱 🙀.

@StaggerLeee , seja respeitoso com todos neste projeto, não importa onde eles trabalhem. Assim como você gostaria que alguém o tratasse bem, faça o mesmo com os outros.

Não irei, como líder de design deste projeto, ver declarações pessoais como você fez a ninguém. Não me importa onde alguém trabalhe ou qualquer um de seus antecedentes, são detalhes pessoais que você não tem o direito de mencionar. Deixe de lado o pessoal e volte a se concentrar no produto.

Agora, vamos seguir em frente e nos concentrar em fazer o melhor produto possível. Eu absolutamente entendo que seus pontos muitas vezes vêm de um lugar de paixão. Você pode ser respeitoso e apaixonado, por favor, volte a ser assim.

Você da Automattic não deve reclamar que não podemos respeitar seu trabalho e que estamos pressionando muito você.
Não para o salário mensal de 7.000 - 10.000 € que você recebe. Boba. Não é como quando as pessoas reclamam no WP Trac para os desenvolvedores voluntários.
Se Gutenberg lhe der dor de cabeça, converse com seu chefe. Ele deu a você uma tarefa impossível de fazer.

@StaggerLeee Eu gostaria de ter recebido tanta dica Auto mas o Automattic não é o Google, e posso ganhar mais em outro lugar do mundo WP. Minha presença aqui é puramente por minha própria conta, não sou pago para estar aqui, nem muitas outras pessoas que estão trabalhando nisso. Na verdade, sou pago para fazer revisões de código e ajudar a lançar clientes empresariais!

Portanto, acredite que a mensagem foi recebida, a prova está na guia Pull Requests na parte superior, isso não é uma conspiração da Automattic para quebrar seu código e p ** s de seus clientes (_não se esqueça, a Automattic tem clientes pagantes que use metaboxes também_)

Para aqueles que ainda estão preocupados com iframes , sugiro olhar aqui neste pedido Pull (https://github.com/WordPress/gutenberg/pull/3345) que está tentando desfazer os iframes e implementar minha sugestão feita anteriormente.

Como as próximas iterações de implementações de metaboxes, seria bom testar e identificar problemas de compatibilidade, jogar frutas podres no A8C pode parecer bom, mas não ajuda.