FWIW, quando conversei com desenvolvedores da web, todos eles usam metaboxes para conteúdo, de modo que tenham o máximo de controle. Não tenho certeza se as metaboxes serão consideradas "legado" para muitas pessoas, mas sim parte do futuro. Pode valer a pena entrar em contato com o pessoal do WordPress VIP para saber sua opinião.

Não tenho certeza se as metaboxes serão consideradas "legado" para muitas pessoas, mas sim parte do futuro. Pode valer a pena entrar em contato com o pessoal do WordPress VIP para saber sua opinião.

Minhas desculpas, essa frase foi ruim. Metaboxes estão aqui para ficar. É por isso que a barra lateral da metabox está recebendo uma atualização na forma da nova barra lateral "Configurações de postagem".

O que eu quis dizer é que as novas metaboxes devem ser escritas em JS e aparecerão na barra lateral Post Settings ao lado das stock. Metaboxes escritas em PHP devem, idealmente, ser atualizadas para JS, mas devem continuar a funcionar em sua forma PHP também. É para isso que serve o painel "Configurações estendidas", e ele fica lá na parte inferior, não porque não queremos que façam parte da barra lateral, mas sim porque é muito difícil misturar metaboxes PHP e JS em uma barra lateral.

Existem alguns grandes desafios no envio de metaboxes gerenciadas por PHP via JS e Ajax, principalmente em como lidar com a atualização da renderização da metabox para refletir o estado recém-salvo: https://core.trac.wordpress.org/ticket/7756

Eu me pergunto se incorporar uma metabox legada por meio de um iframe poderia ser uma solução aqui, onde o iframe src é algo como /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings e apenas produz aquela metabox no documento.

O que eu quis dizer é que as novas metaboxes devem ser escritas em JS e aparecerão na barra lateral Post Settings ao lado das stock.

Isso significa que as metaboxes do JavaScript só podem ser colocadas na barra lateral e não podem fazer parte da seção "configurações estendidas"? No topo da minha cabeça, posso pensar em muitos plug-ins em que a barra lateral realmente não fornece espaço suficiente e torna a barra lateral potencialmente confusa. Apenas alguns plug-ins que podem ter problemas com esta abordagem:

• Yoast SEO: fornece um grande número de campos, que provavelmente não cabem na barra lateral - poderia talvez ter uma metabox da barra lateral que abrisse um modal para mais opções, mas isso parece trabalhar em torno de uma limitação desnecessária

• Plug-ins de campo personalizado / criadores de página de arrastar e soltar - substituem ou substituem parcialmente a área de conteúdo principal e, portanto, precisam de bastante espaço na tela. O potencial de construtores de página inteira garante que construam sua própria interface totalmente personalizada como uma visualização separada, mas em alguns casos, vários campos extra estruturados são necessários além da área de conteúdo principal (e eu aprecio que Guttenburg deve reduzir a necessidade desses tipos plug-in, mas também não pode abranger todos os casos de uso)

• WooCommerce - adiciona metaboxes para dados de pedidos e itens de linha, enquanto remove o editor principal (Woo planeja construir sua própria interface personalizada, mas eu suspeito que isso ainda está muito longe, e outros plug-ins estarão em uma situação semelhante)

(Estou assumindo que Guttenburg está planejado para eventualmente substituir as visualizações post-new / post-edit.php atuais, em vez de simplesmente ser uma alternativa?)

Ha, obrigado @braders - Yoast UX-er checando aqui com a mesma pergunta :)

Nossa metabox é realmente muito grande e ampla agora, pois faz muitas coisas. Não nos importaríamos em trabalhar mais esses recursos nas diferentes metaboxes da barra lateral para oferecer uma integração mais estreita, mas eu gostaria de saber se isso será possível. Por exemplo, podemos adicionar pontuações de SEO à caixa Publicar como fazemos atualmente? E se não, podemos ainda conectar na caixa de configurações estendidas mesmo se nossa metabox estiver codificada em JS?

Devemos absolutamente procurar tornar as novas configurações de postagem plugáveis, para que você possa adicionar metaboxes javascript à barra lateral. Talvez seja hora de abrir um tíquete para isso. Este tíquete é principalmente para metaboxes escritas em PHP, que precisam funcionar de forma transitória.

Na mesma linha das metaboxes na seção estendida, houve alguma discussão ou maquete feita sobre como um tipo de postagem que não oferece suporte à edição de conteúdo de postagem seria apresentado? Nesses casos, as metaboxes na área intermediária são utilizadas para a experiência de edição primária. Gutenberg deve apresentar um modo "Somente Título"? Ou o título da postagem deve ser tratado de forma diferente na ausência do editor.

Na mesma linha das metaboxes na seção estendida, houve alguma discussão ou maquete feita sobre como um tipo de postagem que não oferece suporte à edição de conteúdo de postagem seria apresentado? Nesses casos, as metaboxes na área intermediária são utilizadas para a experiência de edição primária. Gutenberg deve apresentar um modo "Somente Título"? Ou o título da postagem deve ser tratado de forma diferente na ausência do editor.

Seria bom criar um tíquete separado para! Com capturas de tela do tipo de postagem existente, se você tiver! ✨

Também quero enfatizar que muitos plug-ins usam tipos de postagem personalizados que dependem de metacaixas sem um editor de conteúdo. Se o tipo de postagem for registrado sem suporte para editor , deve haver um modo apenas de título que abre a tela inteira para uso por metacaixas.

1 para entrar em contato com o WordPress VIP. Este também é um problema no tópico do Calypso: https://github.com/Automattic/wp-calypso/issues/587

Recurso realmente importante para o topo do mercado!

Eu me pergunto se incorporar uma metabox legada por meio de um iframe poderia ser uma solução aqui, onde o iframe src é algo como /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings e apenas produz aquela metabox no documento.

Eu também tive essa mesma ideia. Também é uma boa ideia por motivos de sandbox e gerenciamento de sessão. Em seguida, podemos identificar casos de uso comuns deste recurso e implementar uma API para lidar com eles.

Eu queria entrar como desenvolvedor de plugins e como alguém que usa o WordPress principalmente como uma ferramenta de comércio eletrônico. Também porque @kevinwhoffman me disse para fazer isso.

Eu cansei Gutenberg hoje e literalmente não posso processar isso como sendo WordPress sem ver como metaboxes e botões de edição (adicionados via gancho media_buttons) fazem parte disso.

Também não sou um grande fã do estado atual do editor do WordPress e da metabox-palooza. Acabei de contar e no download (tipo de postagem de produto do Easy Digital Download) de postagem única eu tenho 14 metacaixas personalizadas adicionadas pelo Yoast, Easy Digital Downloads e meu próprio código personalizado usando CMB2. É muito, mas preciso disso. WordPress é bastante inútil sem essa interface e o que ela expõe.

Estou preocupado que isso não tenha sido considerado desde o início, pois já trabalhei em muitos sites onde a interface de campos personalizados adicionada com ACF, Pods, CMB2 etc. foi toda a experiência de edição.

Aqui estão minhas preocupações técnicas:
1) Botões adicionados por meio dos media_buttons. Em meu plugin Caldera Forms (80K + instalações ativas), usamos esta ação para adicionar um botão de inserção de formulário que abre um modal para inserir o código de acesso no editor de postagem. Talvez mudássemos para um bloco personalizado em Gutenberg.
2) Como a ação save_post permanece compatível com versões anteriores? Muitos plug-ins, temas e códigos personalizados se conectam em save_action e acessam $ _POST super global. Não é um bom design, mas é um problema técnico que afeta milhões de sites.
3) Houve uma sugestão de renderizar metaboxes legadas em um iFrame. Isso me preocupa, pois não é possível acessar o conteúdo de um iframe via JavaScript.

@ Shelob9 hi!

Houve uma sugestão de renderizar metaboxes legadas em um iFrame. Isso me preocupa, pois não é possível acessar o conteúdo de um iframe via JavaScript.

Acessar o conteúdo de um iframe via JavaScript _é_ possível, desde que esteja no mesmo domínio, como seria neste caso.

Como a ação save_post permanece compatível com versões anteriores? Muitos plug-ins, temas e códigos personalizados se conectam em save_action e acessam $ _POST super global. Não é um bom design, mas é um problema técnico que afeta milhões de sites.

Há muito que podemos fazer para facilitar a transição de metaboxes legadas para Gutenberg. Há uma diferença fundamental em como os dados são modelados em Gutenberg e na tela de pós-edição atual. Ou seja, os dados agora são modelados pela primeira vez. Com a modelagem de dados, podemos finalmente usar interfaces JavaScript para manipular o estado de postagens e postmeta de maneiras que são impossíveis usando $_POST e a ação save_post , muito menos ser capaz de _preview_ alterações para postmeta. Ao rotear alterações postmeta através do modelo, isso permitirá que postmeta seja visualizado pela primeira vez. Portanto, embora Gutenberg possa incluir metaboxes legadas sempre que possível, elas sempre serão inerentemente limitadas em quanto podem aproveitar as vantagens da nova interface. Acho que isso é tão real quanto a realidade de que temos dívidas técnicas.

Acho que é a decisão intencional e consciente de Matt de que a dívida técnica deve ser cancelada se o WordPress quiser evoluir de uma forma que permanecerá relevante no futuro. Quanto mais conseguirmos atualizar o ACF, os Pods e o CMB2 para usar o modelo de dados apresentado por Gutenberg, acho que mais fácil será essa transição. Sem dúvida, haverá muitos desafios e muito trabalho pela frente!

@westonruter agradece por deixar o propósito da área de Configurações estendidas muito mais claro.

Suspeito que parte da discussão aqui também é parcialmente sobre o espaço disponível na tela.

Parece que as metaboxes Gutenberg JS podem ter acesso à barra lateral comutável (o que está bom para mim) enquanto as metaboxes PHP legadas têm acesso a uma área muito mais ampla disponível na parte inferior da tela (o que também está bom para mim).

Infelizmente, espero que esse desejo de espaço de tela disponível possa interferir na discussão pretendida sobre como lidar com metaboxes legadas de PHP.

Concordo que, em vez de oferecer suporte a todos os métodos antigos, os fabricantes de plug-ins devem reconsiderar suas metaboxes e como eles podem se integrar melhor com o novo layout. Ao mesmo tempo, também concordo que possibilidades semelhantes de integração também devem ser oferecidas no novo editor (e espero que sim). Acredito que # 1352 seja o principal lugar para discutir isso atualmente. Este problema é para discutir como forneceremos compatibilidade com versões anteriores para metaboxes PHP não atualizadas no lançamento.

Gostaria de saber se incorporar uma metabox legada por meio de um iframe poderia ser uma solução aqui

Acessar iframes não é uma experiência muito empolgante para usuários de leitores de tela. Alguma outra opção?

Só queria entrar aqui, a barra lateral simplesmente não é grande o suficiente para a maioria das metacaixas que vemos em plug-ins e temas. Forçar-nos a amontoar as coisas neste pequeno espaço é um retrocesso na minha opinião. Acho que este novo editor é ótimo, mas não se isso significar sacrificar como usamos as metacaixas hoje.

Eu concordo totalmente com

Em resposta a @westonruter, obrigado por esclarecer sobre a compatibilidade com versões anteriores. Acho que precisa ficar MUITO claro que o WordPress 5.0 ou onde quer que isso aconteça não é compatível com as versões anteriores, já que essa era a expectativa do usuário.

Também estou preocupado com a forma como as metaboxes serão tratadas, especialmente em certos tipos de postagem personalizados, onde o editor de conteúdo pode não ser o foco principal do CPT. Vou escolher WooCommerce aqui porque é um plugin bem conhecido, mas há muitos outros plug-ins e temas que têm problemas semelhantes.

Por exemplo, os pedidos do WooCommerce não têm editor de conteúdo - simplesmente não é necessário. Os detalhes sobre o pedido são o que é importante, não a edição de conteúdo, e por direito deve ser o foco principal dessa página.

Os CPTs como este terão a capacidade de remover o editor se não for necessário? O plugin não parece estar totalmente integrado com metaboxes customizadas em CPTs, então é difícil dizer se isso foi considerado ou não.

Os produtos WooCommerce também trazem à tona outro problema em que existem duas áreas de conteúdo - uma para a descrição do produto e outra para a breve descrição do produto. Será necessário que um tenha precedência sobre o outro na área do editor "principal", enquanto o outro fica preso na barra lateral? Parece uma experiência de edição menos do que ideal para o que está na barra lateral.

Pode haver uma opção para registrar intencionalmente essas configurações na área abaixo (ou acima?) Do editor em vez de empilhá-las todas na barra lateral? Isso pode ser semelhante aos parâmetros de contexto e prioridade atuais add_meta_box . Talvez, até mesmo alterne entre vários editores de conteúdo (ou outras metaboxes) que pertençam à seção mais ampla da página.

Talvez eu esteja faltando alguma coisa aqui (corrija-me se estiver errado), mas parece que um grande esforço está sendo feito para um editor melhor quando, na realidade, nem todos os usos do WordPress exigem algo diferente do que é usado hoje.

PERGUNTA como definimos um CPT para não usar Gutenberg (equivalente a nenhum editor) e APENAS mostrar as metaboxes de largura total das quais nossos negócios dependem.
Eu confio em metaboxes. Na maioria das vezes, meus CPTs são assim
'supports' => array( 'title' )
E são estendidos a partir daí. Considere aqueles de nós que criaram ferramentas de negócios para clientes usando CPTs com metaboxes como entrada de dados de formulário restrita e guiada, em vez de para a redação de artigos.
Meu trabalho é principalmente extensões customizadas para CMB2 que fazem interface com os sistemas cliente. EG, listagens de imóveis que utilizam sistemas de terceiros

Não quero parecer dramático, mas continuarei no WP4.9 até que isso seja resolvido e estou muito preocupado com o futuro. Eu entendo que Gutenberg está "cancelando a dívida com o passado"! Mas a dívida recai sobre pessoas como eu.

O tema aqui parece ser que o problema não é com Guttenburg, mas sim com a falta de compatibilidade com versões anteriores.

Existem alguns problemas reais de Guttenburg, para os quais tíquetes separados devem ser levantados (permitir que metaboxes usem largura total, mock-up Guttenburg sem suporte de editor), mas Gutturnberg não pode replicar totalmente as telas atuais e nem deve tentar IMHO.

No entanto, eu me pergunto se mais deveria ser feito para tornar Guttenburg opt-in / opt-out. Algumas ideias:

• Eu acho que a maioria dos CPTs atuais faz uso pesado de metaboxes em vez do editor principal. Então, talvez os autores do plugin devam optar pelo Gutturnberg com 'supports' => array( 'gutenburg' ) ou similar

• Para postagens e páginas, Guttenburg deve ser opcional como configuração do site. Seria até possível perguntar aos usuários se desejam usar o Guttenburg após a atualização 5.0 e armazenar essa escolha no banco de dados.

• Ou, alternativamente, os temas poderiam declarar suporte via post_type_supports (), mas isso poderia prejudicar seriamente a aceitação - ou os temas poderiam ser cancelados, o que não ajudaria os usuários de temas legados e sem manutenção que não são mais atualizados. (Talvez um plug-in remove-guttenburn seja suficiente para usuários de temas legados?)

Mas, independentemente da implementação, acho que a visão atual deve permanecer, mesmo que esteja cada vez mais escondida da maioria dos usuários ...

Gosto da ideia teórica de CPTs solicitando explicitamente 'supports' => array( 'gutenberg' ) para manter a funcionalidade existente no caso de o sinalizador de suporte 'gutenberg' não ser definido. Isso me pouparia muito trabalho consertando sites antigos para clientes irritados que atualizassem para o WP5.

Noto que os 'suportes' => recursos existentes (título, editor, autor, ...) têm nomes muito autodescritivos, Gutenberg se destaca como um nome de _projeto_ aqui. Eu me pergunto se um nome de recurso mais descritivo seria considerado para esse uso; talvez "editor de blocos"? 'supports' => array( 'block-editor' )

É claro que seria necessária uma estratégia para detectar erros como 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) . Eu presumiria que o sinalizador 'editor de bloco' simplesmente anularia o modo 'editor' antigo.

Outro plugin dev aqui com preocupações.

Se a meta da barra lateral só for acessível via JS, o que isso significa para metaboxes registradas em PHP com um contexto de side ? Movê-los para a seção de configurações estendidas proposta revoga a ideia de que essas metaboxes são contextuais.

Como todos sabemos, as barras laterais não são apenas uma decisão de design atraente; eles frequentemente mantêm conteúdo relacional de uma forma que ajuda o usuário a entender a prioridade de seu conteúdo e a relação com o conteúdo principal. Atribuir a uma metabox side um contexto diferente devido a uma barreira técnica parece um pouco errado.

Considerando a JS-ificação progressiva da área administrativa, essas metaboxes "legadas" também fornecem aos desenvolvedores de plug-ins e temas um ponto de montagem natural para React / Vue / outros aplicativos autocontidos para fornecer funcionalidade adicional à página de edição.

O editor parece ótimo, mas não se esqueça do resto da página.

Tive a oportunidade de pensar um pouco mais sobre isso e, com algum contexto compartilhado por outros aqui, acho que há outra questão. Este novo editor está nos forçando a ter um único layout e fluxo de trabalho; por que estamos removendo a personalização? A capacidade de esculpir a entrada de dados por cliente é o que torna o WordPress e a maioria das outras soluções realmente excelentes. Quanto mais eu brinco com este editor, mais parece uma versão inchada do Customizer, onde a área de visualização foi substituída por um editor e a barra lateral apenas mudou de lado.

Também foi mencionado que poderíamos usar isso para escrever postagens, mas permitir que os CPTs adicionem suporte para isso. Eu também não acho que isso funcionará. As organizações de notícias adorariam esse tipo de editor, mas também precisam de fluxos de trabalho personalizados em torno de conteúdo adicional, programação, incorporações, infográficos e outros dados necessários.

Que tal fazer este editor se comportar como um editor de tela inteira / sem distrações? Dessa forma, poderíamos ter o melhor dos dois mundos sem sacrificar a funcionalidade e o código "legado". (Aliás - acho ridículo que a maneira como atualmente construímos metacaixas esteja sendo chamada de "legado ..." neste projeto).

Obrigado pelo seu tempo pessoal, é apreciado.

Que tal fazer este editor se comportar como um editor de tela inteira / sem distrações?

+1

Vou reiterar minha preocupação principal: os CPTs geralmente não exigem o 'editor' porque a postagem é construída a partir de metaboxes grandes e agrupadas dinamicamente em um fluxo de trabalho orientado do usuário (por exemplo, dados do produto WooCommerce).

Essas metaboxes não vão caber na gaveta de "configurações estendidas" proposta porque formam elementos de entrada de conteúdo principal e precisam ser proeminentes no editor de postagem, com largura total e aberta. Com isso em mente, o # 952 parece uma concessão muito pequena, pois relega a entrada de dados importantes em uma gaveta fechada.

Se for esperado que nós, desenvolvedores, _refatoremos_ todas as nossas soluções metabox antigas em blocos, então alguém da Automaticc precisa afirmar isso de forma clara e pública antes que o martelo caia no 5.0. Não vejo nenhum sinal de que a equipe tenha considerado essa parte do mercado e as implicações para os negócios.

Muitos bons pensamentos já foram adicionados aqui, então vou apenas acrescentar estes pensamentos simples:

Em vez de ter um expansor de "Configurações estendidas" na parte inferior para todas as coisas legadas, por que não apenas fazer um expansor para cada metabox que fica na parte inferior exatamente assim, quando a metabox está nos contextos normal e avançado, e então usar as configurações laterais para o contexto lateral?

Não parece que estamos muito longe de uma solução. E se o tipo de postagem não suportar o editor, apenas oculte o editor, mas todo o resto aparecerá da mesma forma. É um layout razoável. Basta fornecer opções como definir a metabox expandida padrão.

Certamente não me importo com a ideia de considerar o método atual de renderizar metaboxes legado e fornecer um método novo, orientado por js e preferido, de construir os campos. Podemos então mudar gradualmente sem ter que entrar em pânico com as coisas quebrando imediatamente no 5.0.

Espero que esses pensamentos ajudem. Se outra pessoa já disse algo a esse respeito, considere isso como um acordo. 😄

Eu gostaria de adicionar dois outros ganchos valiosos à discussão: edit_form_after_title e edit_form_after_editor que atualmente fornecem controle completo sobre a IU pós-edição. Obviamente, Gutenberg não é apenas um substituto para "wp_editor", é uma versão completamente diferente da interface do usuário (e como parece atualmente, sua futura expansibilidade modular).

Vejo que questões como essa estão tentando resolver o problema, mas acho que não é sobre "o que acontece com nossas metaboxes", é mais sobre a questão para onde o WordPress está se dirigindo como um "produto".

É fácil identificar a meta de médio prazo de estabelecer tal solução: será muito fácil mover isso para o front-end (e talvez se aproximar de alguns concorrentes).

Do ponto de vista de desenvolvedores / negócios / planejamento, seria útil entender a intenção (futura) de 'Gutenberg', ou alguém pode me indicar uma declaração de missão ou algo semelhante?

Mais algumas opiniões minhas ...

Observo que os 'suportes' => recursos existentes (título, editor, autor, ...) têm nomes muito autodescritivos, Gutenberg se destaca como um nome de projeto aqui. Eu me pergunto se um nome de recurso mais descritivo seria considerado para esse uso; talvez "editor de blocos"? 'suporta' => array ('editor de blocos')

Eu concordo - parece um detalhe que pode ser resolvido assim que a abordagem for acordada agreed

É claro que seria necessária uma estratégia para detectar erros como 'suporte' => array ('título', 'editor', miniatura ',' editor de bloco '). Eu presumiria que o sinalizador 'editor de bloco' simplesmente anularia o modo 'editor' antigo.

Eu consideraria Gutenberg estendendo os suportes de tipo de postagem atuais - então, se não houvesse suporte para editor , Gutenburg mostraria apenas opções de título / barra lateral / estendidas. Então, talvez o suporte de Gutenburg seja mais bem tratado como um argumento de registro de CPT separado, em vez de ser parte da matriz de suportes.

Em vez de ter um expansor de "Configurações estendidas" na parte inferior para todas as coisas legadas, por que não apenas fazer um expansor para cada metabox que fica na parte inferior exatamente assim, quando a metabox está nos contextos normal e avançado, e então usar as configurações laterais para o contexto lateral?

Eu pessoalmente gosto dessa ideia - Se esses painéis pudessem ser reordenados e ocultados o máximo possível no momento, isso poderia ser uma solução ideal ...

Possivelmente, também deve haver uma maneira de definir um (ou mais?) Ou como aberto no carregamento da página - especialmente se o tipo de postagem não for compatível com o editor principal.

Também foi mencionado que poderíamos usar isso para escrever postagens, mas permitir que os CPTs adicionem suporte para isso. Eu também não acho que isso funcionará. As organizações de notícias adorariam esse tipo de editor, mas também precisam de fluxos de trabalho personalizados em torno de conteúdo adicional, programação, incorporações, infográficos e outros dados necessários.

Se a nova tela baseada em reação for tão plugável quanto as telas de edição antigas, não há razão para que esses fluxos de trabalho personalizados não possam ser adicionados ao topo da página / barra lateral / abaixo do editor ou em outro lugar na página. (Isenção de responsabilidade: eu não tenho um conhecimento profundo do React, então resta saber o quanto os ganchos mais complexos estarão fora do PHP). Também # 1352

Acho que a confusão aqui se deve ao fato de haver uma diferença fundamental em como Gutenberg está repensando o editor para ser o primeiro bloco . Em outras palavras, devemos deixar de pensar em adicionar metaboxes e, em vez disso, pensar em adicionar blocos. Os campos que você antes colocaria em metaboxes, agora serão colocados em blocos.

Quando você define um tipo de postagem personalizado, isso provavelmente inclui os blocos necessários e quais são apenas permitidos. Para um tipo de postagem personalizado que não tem suporte para editor , ainda teria o "editor" exibido em Gutenberg, mas poderia essencialmente desativar o _inserter_. Os blocos que aparecem no editor seriam travados no lugar de acordo com o que o tipo de postagem requer. Se os blocos não tivessem sido preenchidos, eles apareceriam como _placeholders_. Observe que esses blocos podem então armazenar suas propriedades em postmeta, assim como as metaboxes fazem atualmente, mas eles fariam isso de forma normalizada em vez de ad hoc por meio da ação save_post e $_POST global.

Portanto, acho que o resultado final aqui será basicamente o mesmo. Os autores de plug-ins continuarão a obter uma “caixa” para colocar os campos personalizados. Só que eles aparecerão em blocos em vez de metaboxes.

Acho que a confusão aqui se deve ao fato de haver uma diferença fundamental em como Gutenberg está repensando o editor para ser o primeiro bloco. Em outras palavras, devemos deixar de pensar em adicionar metaboxes e, em vez disso, pensar em adicionar blocos. Os campos que você antes colocaria em metaboxes, agora serão colocados em blocos.

@westonruter Isso parece sensato o suficiente para metaboxes contendo conteúdo, mas muitas metaboxes servem a meta de postagem específica que não faria sentido no conteúdo de postagem.

Obrigado @westonruter pelo esclarecimento, mas isso levanta algumas novas questões para mim.

Os blocos que armazenam seus dados como post_meta parecem um tipo de bloco fundamentalmente diferente do que vi até agora na demonstração. Esses dados também seriam armazenados de forma redundante no fluxo do conteúdo da postagem?

Existe alguma coisa que impede um autor de adicionar mais do que um número aceitável de blocos a uma postagem? (Adicionar vários campos post_meta quando apenas um faz sentido)

Eu tenderia a concordar com @westonruter sobre explorar blocos como um portal para metadados. O que eu sugeriria, porém, é separar a ideia de um bloco do post_content. Um bloco em um tipo de postagem personalizada não deve necessariamente ser um membro do que sai de post_content no front end. Aqui está um exemplo usando o plugin Calendário de Eventos (minha interpretação) pela tribo moderna.

Nessa situação, o conteúdo principal são os detalhes do evento, não a área de conteúdo de forma livre. O plugin usará os metadados de seu tipo de postagem personalizado para montar sua própria marcação e post_content é meramente o texto descritivo que é impresso na parte inferior da página. Por causa disso, o bloco de detalhes do evento não deve ser movível, apagável ou realmente fazer parte da saída do conteúdo. Deve, no entanto, aparecer primeiro, porque representa o conteúdo principal para este tipo de postagem.

WooCommerce seria outro exemplo em que um ou mais blocos de informações do produto devem ter precedência sobre o texto descritivo em um tipo de postagem do produto, mas não devem ser blocos opcionais que o usuário deve inserir.

Acho que o conceito fundamental para blocos deve ser montar a interface de usuário adequada para a postagem e não necessariamente implicar onde os dados serão armazenados ou renderizados no frontend.

... devemos deixar de pensar em adicionar metaboxes e, em vez disso, pensar em adicionar blocos.

Isso faz sentido para o conteúdo, mas muitos plug-ins usam tipos de postagem personalizados para não conteúdo, como formulários ou pagamentos. Esses tipos de postagem não se parecem de forma alguma com uma postagem de blog, nem seus metacampos abstratos se beneficiam de um editor de bloco. Forçar que toda a configuração seja feita por blocos remove a tela aberta na qual os desenvolvedores de plug-ins passaram a confiar, a mesma tela aberta que tornou o ecossistema de plug-ins o que é hoje.

A abordagem atual parece ser o primeiro bloco com metacaixas confinadas a uma função de suporte. Embora os blocos beneficiem muitos plug-ins focados em conteúdo, a necessidade de definir configurações abstratas ainda se beneficiará dos rótulos óbvios e das entradas familiares que as metacaixas fornecem. Nesses casos, os desenvolvedores devem ter a liberdade de usar a tela inteira.

@westonruter Você pode esclarecer que o que você está dizendo é que se meu tipo de postagem personalizada exigisse certos campos extras, eu teria esses dados inseridos em um bloco?

Nesse caso, tenho algumas perguntas de acompanhamento:

1) Eu seria capaz de tornar esse bloco um padrão? Ou seja, sempre foi mostrado naquele tipo de postagem e não pôde ser removido. Por exemplo, se meu plug-in criou eventos e cada evento tinha uma data de início e término, o bloqueio para as datas de início e término seria necessário e no conteúdo da postagem ao editar o tipo de postagem personalizada do evento por padrão?

2) Como os dados seriam salvos desse bloco? Pelo que entendi, agora os dados dos blocos são armazenados como comentários HTML em post_content. Como obteríamos os dados desses blocos para postar meta? Por exemplo, para meu plug-in de evento hipotético, como eu colocaria as datas de início e término na meta de postagem para que eu pudesse consultar por eles?

3) Qual é a razão para tudo isso seguir a direção do editor de conteúdo principal e aplicá-lo aos tipos de postagem personalizados? Existe algum teste de usuário que respalde essa direção de design, especialmente em relação aos tipos de postagem personalizados que não representam uma postagem / artigo de blog?

@kevinwhoffman Ainda não vejo um conflito fundamental para os blocos. As configurações abstratas ainda podem ser consideradas conteúdo, mas de um tipo diferente: são todos dados. Cada bloco não precisa ter uma representação visual “no conteúdo”. Eu acho que poderia haver muitos “metablocos” também, armazenando dados em postmeta em vez de post_content . Os blocos que estão sendo editados podem ser estilizados para ter títulos / rótulos semelhantes a como as metaboxes são apresentadas hoje.

@ Shelob9 sim, se o seu tipo de postagem personalizada exigisse campos extras, acho que eles seriam apresentados em um bloco. Se você tiver um tipo de postagem personalizada de “produto”, pode haver um bloco product-details singular que contém campos para o preço, variações e assim por diante.

1. Eu seria capaz de tornar esse bloco um padrão? Ou seja, sempre foi mostrado naquele tipo de postagem e não pôde ser removido. Por exemplo, se meu plug-in criou eventos e cada evento tinha uma data de início e término, o bloqueio para as datas de início e término seria necessário e no conteúdo da postagem ao editar o tipo de postagem personalizada do evento por padrão?

Sim, exatamente. Tipos de postagem personalizados, formatos de postagem e modelos de página podem simplesmente envolver o conceito de blocos obrigatórios que estão “bloqueados”, incapazes de serem removidos ou reordenados. Um exemplo disso seria um bloqueio para o trecho da postagem: https://github.com/WordPress/gutenberg/issues/1288#issuecomment -310544967

1. Como os dados seriam salvos desse bloco? Pelo que entendi, agora os dados dos blocos são armazenados como comentários HTML em post_content. Como obteríamos os dados desses blocos para postar meta? Por exemplo, para meu plug-in de evento hipotético, como eu colocaria as datas de início e término na meta de postagem para que eu pudesse consultar por eles?

A maioria dos blocos hoje armazenam seus dados em HTML dentro de post_content mas não é necessário. Por exemplo, em https://github.com/WordPress/gutenberg/issues/1288 você pode ver a discussão de um bloco de Excerto armazenando seu conteúdo em post_excerpt e um bloco de Imagem em destaque armazenando seu conteúdo em postmeta. Portanto, você definitivamente deve ser capaz de ter um bloco event-details com datas de início e término armazenadas em postmeta.

1. Qual é a justificativa para que tudo siga na direção do editor de conteúdo principal e se aplique aos tipos de postagem personalizados? Existe algum teste de usuário que respalde essa direção de design, especialmente em relação aos tipos de postagem personalizados que não representam uma postagem / artigo de blog?

Conforme acima, os dados podem ser obtidos e salvos em post_content , postmeta, termos ou qualquer outro lugar. A ideia de ser “primeiro o bloco” é ter um _bloco_ de construção comum que tudo usa e, ao fazer isso, os componentes do bloco podem ser reutilizados ao máximo no WordPress. Esse é o meu entendimento.

@westonruter - Obrigado pelo esclarecimento. Isso é muito útil porque não há muitas informações sobre como este editor se relaciona com tipos de postagem que não sejam postagens / artigos de blog, etc.

Espero ver a documentação sobre como escrever um "metablock" em breve.

Devemos considerar o que estamos ensinando ao usuário por meio da experiência de edição de postagem e como isso mapeia para tipos de postagem personalizados.

Ao editar um Post padrão no editor de blocos, o usuário aprende que cada bloco representa o conteúdo. As configurações associadas ao conteúdo estão disponíveis em um painel / caixa-meta que fica fora do editor de bloco. O conteúdo vive em blocos. As configurações estão em painéis. Já foi dito que o que o usuário vê no editor de bloco deve ser uma prévia da página quando publicada.

Em seguida, combinar as configurações e o conteúdo no editor de blocos para tipos de postagem personalizados quebra a ideia de que o editor de blocos é uma prévia. Acho que devemos deixar o editor de bloco fazer o que faz de melhor, que é editar conteúdo, e capacitar os desenvolvedores a construir interfaces de configuração que não compartilhem os mesmos requisitos de um bloco de conteúdo.

Tenho trabalhado em um extenso plugin que adiciona metacaixas como WooCommerce e EDD fazem. Na maioria das vezes, removo o editor de conteúdo da tela, pois não é necessário. Estou um pouco preocupado com a possibilidade de não ser algo que devamos fundir com Gutenberg.
Caso contrário, para onde iria tudo isso.

Eu concordo com @kevinwhoffman que se os blocos vão representar meta, eles precisam de uma dica visual para o usuário de que eles são de alguma forma diferentes do conteúdo da postagem e não devem ser esperados na saída. Uma maneira de resolver isso é um divisor. Isso é essencialmente apenas uma reinterpretação da forma como o conteúdo é separado das metaboxes agora.

Isso não resolve todos os problemas para mim, mas acho que é uma maneira interessante de dar uma facelift nas metaboxes e provavelmente poderia ser bastante compatível com os plug-ins existentes, mas isso não seria uma experiência de primeira classe para o usuário.

Aqui está uma tentativa de informar o usuário quando um meta-bloco é o conteúdo principal, o conteúdo da postagem é usado como descrição e há meta-blocos adicionais.

@brentjett Obrigado pelas maquetes. Como você apontou, a necessidade de separar as configurações do conteúdo é importante, mas não vejo a vantagem de exigir que uma caixa de configurações como o Yoast seja um bloqueio em primeiro lugar.

• Ele _não_ representa o conteúdo da página, quebrando assim a ideia de que o editor de bloco é uma prévia do conteúdo da página.
• _Não_ requer várias instâncias.
• Ele _não_ se beneficia de ser reposicionado no meio de outros blocos de conteúdo.
• Ele _deve_ estar presente na página por padrão.

Cada uma dessas características vai contra o comportamento padrão de um bloco. Claro, existem várias discussões para fazer blocos de uso único que podem ser travados na posição e presentes por padrão. Mas por que transformar um bloco em uma metacaixa quando, em vez disso, poderíamos nos concentrar em melhorar a implementação da metacaixa que já serve a esse propósito?

Não vejo a vantagem de exigir que uma caixa de configurações como Yoast seja um bloqueio em primeiro lugar.

Vamos voltar aqui por um minuto. Duas coisas. Um é o suporte para metaboxes antigas escritas em PHP, para as quais temos a gaveta "configurações estendidas" simulada neste post.

A outra coisa é responder à pergunta: se quiséssemos redesenhar isso do zero, como seria hoje?

É aqui que estamos propondo _blocos_, como uma nova interface que pode unificar muitas outras díspares. Já estamos sugerindo que os blocos podem ser superiores a códigos de acesso, HTML customizado, widgets e um recurso para incorporações. Dependendo do que a metabox faz, não há razão para que ela também não inclua essa interface.

Acordado. E falando por Yoast por um segundo, planejamos integrar em muitos lugares ao redor do novo editor, aprimorando a experiência que gutenberg pretende, em vez de construir um grande bloco para emular nossa metabox antiga, mas houve outros exemplos mencionados acima que iriam trabalho como um bloco também eu acho. Sim, dá um pouco de trabalho, mas se descobrir que este editor vai entusiasmar os usuários do wordpress assim que ganhar um pouco mais de tração, é uma excelente oportunidade para repensar como nos integramos a ele e acho que nossos produtos ficarão melhores como resultado.

Portanto, temos dois casos funcionais _legacy_:
MetaBoxes que manipulam meta-dados (como Yoast), e temos MetaBoxes que foram usados ​​para fornecer uma interface estruturada para inserir conteúdo (como WooCommerce).

Desenvolvendo para o futuro
Se começarmos do zero ("cancelar nossa dívida com o passado"), então é verdade que colocar metadados na gaveta "avançada" proposta pode funcionar. Além disso - a entrada de conteúdo estruturado pode caber em uma interface bloqueada de ordem de bloco dentro de Gutenberg. Ambos são inteiramente hipotéticos, mas potencialmente funcionariam como implementações para futuros desenvolvimentos do WP CMS.

problemas de CMS de negócios legados
99% do meu trabalho é fornecer soluções de negócios sob medida diretamente para as empresas de meus clientes. Portanto, minha preocupação não são as grandes coisas que posso construir no futuro, mas os fatos concretos e frios da funcionalidade do site do meu cliente e relações comerciais. Que propostas existem para migrar os negócios baseados em soluções CMS existentes para Gutenberg? Na minha situação, cada cliente tem uma solução CMS personalizada diferente, construída na estrutura WP estabelecida. Para mim, a frase "cancelar a dívida com o passado" = "Jogar o bebê fora com a água do banho".

Preocupações
Se Gutenberg for enviado como núcleo no WP5.0, acredito que meus clientes terão sites não funcionais. Então, cada site precisará ser refeito e cada cliente suavizado. Cerca de 40 clientes podem querer que eu repare seus CMS naquela semana.

• sites baseados em meta-box CMS legados e sua base de usuários parecem não essenciais para a equipe principal
• a proposta de sorteio "avançado" # 952 foi despriorizada, indicando falta de interesse em toda a área.
• não há método proposto para resolver o problema de "dívida para com o passado" / CMS

É aqui que estamos propondo blocos, como uma nova interface que pode unificar muitos outros díspares. Já estamos sugerindo que os blocos podem ser superiores a códigos de acesso, HTML customizado, widgets e um recurso para incorporações.

Os blocos fazem sentido para todas essas coisas - códigos de acesso, HTML personalizado, widgets, incorporações. Todos são formas de conteúdo que aparecem na página. Eu concordo, bloqueie todos eles.

As configurações não são nenhuma dessas coisas. As configurações têm requisitos distintos que não se sobrepõem ao comportamento fundamental de um bloco. Em muitos casos, essas caixas de configurações armazenam meta-postagens que não têm relação com a apresentação inicial de uma postagem. Parece desnecessário analisar o não conteúdo ao lado do conteúdo sempre que uma postagem é exibida.

Outra coisa a se considerar é o que acontece quando o usuário muda para o modo Texto. Eles verão um monte de comentários HTML representando caixas de configurações ao lado do conteúdo da postagem? O usuário excluirá essas coisas desconhecidas?

Tudo isso pode ser simplificado tratando os blocos como conteúdo e as configurações como um componente de IU separado. Mesmo se não tivéssemos que considerar as metacaixas legadas (que é um grande problema

@steveangstrom A seção de preocupações é um ótimo resumo das preocupações que ainda não foram respondidas.

Esta é uma grande discussão sobre o que será possível no futuro e tudo parece ótimo, o WordPress como é realmente precisa disso. Para mim, como desenvolvedor de plugins, não é grande coisa, farei um bloco ou dois e serei bom. Mas o que acontece com os clientes de Steve e os milhões de sites que foram vendidos para clientes com expectativa de compatibilidade com versões anteriores?

Eu entendo essas preocupações, pois também tenho muitos clientes cujos sites provavelmente serão interrompidos com a atualização. Alguns pensamentos meus:

Usamos amplamente o ACF para gerenciamento de conteúdo. Por exemplo, podemos ter vários editores tinymce por postagem ou em um repetidor. se o objetivo é substituir o tinymce, como faríamos para usar vários "recipientes de bloco"? Eu entendi que agora existe apenas um "container de bloco", certo?

Outro recurso ACF que não se encaixa no fluxo de pós-edição são as páginas de opções. Eu realmente não vejo como isso funcionaria em uma página de opções.

Para aqueles que desejam compatibilidade com versões anteriores - alguém provavelmente fará um plugin para restaurar a experiência de edição atual, se não houver tempo / recursos para atualizar para o gutenberg (isso é algo que planejo usar). Além disso, a versão 5.0 seria um problema de versão principal, o que significa que alterações significativas estão OK (pelo menos de acordo com os padrões da Semver ).

WordPress não segue sempre.

@westonruter Acho que isso faz sentido:

Os campos que você antes colocaria em metaboxes, agora serão colocados em blocos.

Mas, como vamos de lá (metaboxes) para cá (blocos)? Tanto em termos de backcompat para código (plug-ins que ainda não foram atualizados para Gutenberg) e backcompat para dados (como exibimos dados metabox existentes em um novo bloco de conteúdo, uma vez que um plug-in é atualizado para ele; é um plug-in problema de escopo?).

Mas, como vamos de lá (metaboxes) para cá (blocos)? Tanto em termos de backcompat para código (plug-ins que ainda não foram atualizados para Gutenberg) e backcompat para dados (como exibimos dados metabox existentes em um novo bloco de conteúdo, uma vez que um plug-in é atualizado para ele; é um plug-in problema de escopo?).

Essas são boas perguntas. Exploraremos as respostas à medida que implementamos esses recursos.

Se eu tivesse que adivinhar onde terminaremos aqui: as metaboxes atuais serão movidas para uma área "legada" e forneceremos APIs, documentação e exemplos para registrar blocos de metaboxs de "novo estilo".

@nylen e quanto à _rendição_ das metaboxes atuais?

É uma boa notícia que as metacaixas estão sendo priorizadas, mas precisamos considerar uma solução que vai além de colocar as metacaixas antigas em uma gaveta ou confiná-las em uma área "legada".

Existem incontáveis ​​sites hoje que são construídos principalmente com meta-caixas por meio de plug-ins como Campos personalizados avançados. Estamos falando de interfaces de tela inteira aqui, não apenas uma ou duas caixas na parte inferior de uma postagem. Tenho certeza de que o ACF será atualizado para funcionar com o Gutenberg, mas esses sites não serão reconstruídos.

Portanto, a questão permanece: o que acontece com uma interface que não tem editor e é composta inteiramente de metacaixas?

Portanto, a questão permanece: o que acontece com uma interface que não tem editor e é composta inteiramente de metacaixas?

A ideia aqui, e me corrija se eu estiver errado @mtias , é que você apenas esconda a área de conteúdo com seu plugin, e tudo que você vê são metaboxes onde o conteúdo estaria.

Que tal fazer este editor se comportar como um editor de tela inteira / sem distrações?

+1. Esta é uma boa ideia, pois não afeta o editor atual com metacaixas. Embora o editor sem distrações tenha estado lá por muito tempo, ele não é muito usado. O editor de Gutenberg pode pegar isso e melhorar em vez de reescrever a tela do editor.

Além disso, seria melhor se registrássemos o suporte para o editor de Gutenberg com o parâmetro supports quando register_post_type .

Finalmente, como desenvolvedor de metacaixas, adoraria ver uma nova API para fazer com que as metacaixas funcionem para o novo editor. Como você pode ver aqui, muitos desenvolvedores usam metacaixas como uma forma de fornecer conteúdo adicional para as postagens. Esses conteúdos podem ser categorizados, pesquisados ​​posteriormente. Não são apenas blocos de conteúdo simples como conteúdo de postagem. Portanto, se houver um novo substituto para a função add_meta_box() , estou feliz em refatorar meu plugin Meta Box para trabalhar com ele.

Concordo com tudo o que foi dito sobre: ​​fazer com que as metaboxes padrão ainda funcionem / tenham um lugar. Como o desenvolvedor principal do CMB2, posso garantir que haverá um clamor bastante significativo se o CMB2 for quebrado de alguma forma quando o WordPress 5.0 for lançado. Certamente não quero dizer isso como uma ameaça, mas simplesmente como uma realidade.

Quanto mais conseguirmos atualizar o ACF, os Pods e o CMB2 para usar o modelo de dados apresentado por Gutenberg, acho que mais fácil será essa transição.

Definitivamente, estarei procurando fazer isso a longo prazo, mas não tenho certeza se é uma expectativa justa que as bibliotecas da metabox tenham isso em vigor quando o gutenberg for lançado. (Concedido, essa pode não ser a expectativa)

I can guarantee there will be a pretty significant outcry if CMB2 is somehow broken when WordPress 5.0 is released

E mesmo se for atualizado, as instalações antigas serão interrompidas.

Observe também que os grupos de campos no ACF não precisam estar em metaboxes, mas também há o estilo 'Contínuo (sem metabox)' com as opções 'Lado', 'normal - após o conteúdo' e 'alto - entre o título e o editor (!!!) '. O último importante para criar um fluxo significativo de edição.

Lembre-se de que existem muitos desenvolvimentos individuais críticos por aí, que nunca serão atualizados porque ninguém vai pagar por isso. Romper essas implementações será o assassino final para WP em ambientes corporativos.

@ wsydney76 Observe também que os grupos de campos no ACF não precisam estar em metaboxes, mas há também o estilo 'Seamless (sem metabox)' com as opções 'Side', 'normal - after content' e 'high - entre o título e editor (!!!) '. O último importante para criar um fluxo significativo de edição.

É importante notar que isso não é algo que "simplesmente funciona" no WordPress, mas requer um código de plug-in personalizado para remover a IU usual da metabox - portanto, é razoável supor que isso exigirá trabalho adicional do ACF para funcionar com Gutenburg.

Simplifique. Quando o tipo de postagem personalizado não tem suporte para editor (Gutenberg) declarado, use sua imaginação, habilidades em CSS e seus designers centrais mais talentosos para converter o editor inteiro em outra coisa. Faça com que pareça algo que o cliente / usuário não vê quando estiver na tela de pós-edição (nativa). É apenas uma questão de aparência. Os clientes não se importam se Gutenberg funciona em segundo plano ou não, eles não se importam, mesmo que sejam informados sobre isso por desenvolvedores da web. Eles são tipos visuais de pessoas.

Em relação à compatibilidade com versões anteriores, propus uma versão de suporte de longo prazo do WordPress em fevereiro, muito antes do anúncio de Gutenberg chegar ao 5.0.

Naquele ponto parecia uma tarefa improvável, mas agora que está acontecendo, é ainda mais importante discutir a criação de uma versão 4.9 do LTS, cortando o suporte pré-4.9 e focando no 5.0.

A postagem pode ser encontrada aqui:
https://khromov.se/wordpress-needs-another-long-term-support-version/

10 anos + desenvolvedor WordPress aqui. Como muitos apontaram, esse desenvolvimento é ótimo para conteúdo. É uma solução padrão realmente necessária para blocos de conteúdo dinâmico com marcação personalizada. Dito isso, isso limita o uso de tipos de postagem de maneiras que desviam do conteúdo e aproximam o WordPress de uma estrutura.

Por exemplo: eu construí um conjunto de plug-ins que permitem não apenas criar campos para tipos de post (como muitos outros), mas também criar relacionamentos entre eles (ou seja, um para um, um para muitos e assim por diante). Isso (junto com mais recursos) transforma os tipos de postagens em algo muito próximo de modelos em frameworks como Laravel ou Rails, e eu uso uma DSL para trabalhar com esses postes, seus dados e seus relacionamentos.

Esse tipo de uso está longe de ser incomum, e o próprio WordPress incentivou o uso criativo de tipos de postagem, permitindo que os desenvolvedores declarassem os tipos de postagem como não públicos. Sinalizadores como 'public','ublic_queryable 'e' show_ui 'destinam-se a permitir que os desenvolvedores usem tipos de postagem para outros fins que não um simples relacionamento de espelho 1: 1 com uma página pública no site

Como Gutenberg se encaixa nessa visão?

Não vejo outra solução além de manter este editor opcional, ou seja, ele ainda deve substituir o TinyMCE, mas o editor deve permanecer opcional, assim como o TinyMCE é opcional agora.

Se pudermos continuar criando tipos de post que não suportam o editor e pudermos continuar usando metaboxes nesses tipos de post, acredito que um consenso poderá ser alcançado muito mais rápido.

A adoção do novo editor por desenvolvedores de temas e plug-ins pode ficar mais lenta com esse tipo de abordagem, mas honestamente não vejo outra saída que não signifique seguir o caminho 4,9 LTS, o que permitiria o início de novos projetos com WP 5.0 e projetos legados para ficar com 4.9 LTS.

ATUALIZAÇÃO: quando escrevi este comentário, o título do tópico era diferente e a possibilidade de descontinuar metaboxes estava sendo discutida (ou seja, a equipe principal ainda não havia respondido claramente a esta pergunta com um "não" firme como fez nos comentários abaixo). Em tal cenário, gutenberg teria simplesmente suportado blocos dinâmicos e ignorado os muitos outros casos de uso para metaboxes, daí meu comentário acima.

Tendo gasto algum tempo lendo os comentários de todos, parece-me que o resultado provável desta evolução da tela de edição é fornecer uma nova API de metaboxes que funcione dentro dessa tela de edição baseada em js. Ou seja, não perdemos realmente a capacidade de usar postagens de maneiras criativas, como mencionei acima, mas simplesmente obtemos uma nova API para fazer isso e a IU será baseada em js.

Estamos planejando usar os Pods 2.7 para construir um aplicativo com base em React usando a API REST do WordPress e GatsbyJS .
O Gutenberg será compatível com Pods?

Vejo que esse problema vital foi removido de qualquer marco. Sua prioridade foi _novamente_, enquanto sinos e assobios para edição de blogs dão muito trabalho e são adicionados aos betas. Isso é muito preocupante para o futuro do Wordpress como um CMS.

Fiz meus próprios geradores de código inspirados no GenerateWP. Para meu uso próprio e privado no localhost, não público.
De qualquer forma, eu me pergunto como ficaria no Gutenberg quando a troca fosse feita. Campos ACF, muito código PHP personalizado para visualização.

Não nos esquecemos deste problema. Em vez disso, é uma questão extremamente complicada que estamos apenas começando a examinar, junto com muitas, muitas outras prioridades para fazer o editor trabalhar bem.

Algumas das dificuldades que encontraremos ao conectar metaboxes podem se tornar aparentes após a leitura do # 2251, que também contém algumas informações sobre as próximas etapas de uma perspectiva técnica.

O ponto principal que quero enfatizar sobre essa questão, aqui, é que precisamos da ajuda da comunidade para planejar e testar essa implementação.

Aqui está um ponto de partida para uma lista de plug-ins a serem observados:

Plugin                                      Active installs
======                                      ===============
advanced-custom-fields                           1,000,000+
custom-post-type-ui                                400,000+
meta-box                                           200,000+
types                                              200,000+
cmb2                                               100,000+
pods                                                50,000+
custom-field-suite                                  40,000+
wck-custom-fields-and-custom-post-types-creator     20,000+
piklist                                             10,000+
carbon-fields                                        2,000+

Plug-ins que não aparecem acima, provavelmente porque não estão no diretório de plug-ins do WP.org:

• Gerente de campo

Se você souber de outros plug-ins amplamente usados ​​que realizam uma tarefa semelhante, informe-nos aqui nesta edição.

Se você é o desenvolvedor de um desses plug-ins e / ou pode fornecer detalhes sobre quais ganchos do WordPress qualquer um desses plug-ins usa para adicionar suas metaboxes e enfileirar quaisquer scripts ou folhas de estilo relacionados, informe-nos aqui nesta edição ou crie um novo problema para cada plugin específico na lista acima. A coleta dessas informações é demorada e será extremamente útil para futuros esforços de desenvolvimento, para ter tudo em um só lugar. Por exemplo:

Advanced Custom Fields adiciona suas metaboxes registrando um gancho contra admin_enqueue_scripts . Este gancho verifica se o carregamento da página atual é post.php ou post-new.php , e se for, adiciona uma ação admin_head que chama add_meta_box . O núcleo WP faz suas do_meta_boxes chamadas logo após essa ação, em edit-form-advanced.php .

Finalmente, se você é um desenvolvedor familiarizado com a maneira como o WordPress atualmente renderiza e salva metaboxes, sua entrada aqui e / ou no # 2251 é apreciada .

Oi pessoal,
Elliot aqui - ACF dev.

O ACF usa a ação admin_enqueue_scripts para realizar a "lógica de correspondência do grupo de campos" e, em seguida, a ação admin_head para adicionar metaboxes (via add_meta_box() ). Ele não usa a ação add_meta_boxes .

Posso fazer uma pergunta óbvia aqui? Por que estamos discutindo as 'dificuldades' das metaboxes? Eles são parte integrante de todos os sites WP. Certamente a lógica da metabox pode permanecer como está e conviver com a nova área do editor de Gutenberg.

Certifique-se de marcar em @woocommerce também. Eles são provavelmente o maior plugin da metabox.

obrigado
E

Oi pessoal-

Ainda estou formulando alguns pensamentos e ideias, mas gostaria de fazer uma pergunta rápida porque parece que a discussão está ficando um pouco focada demais.

Por que estamos falando apenas em adicionar campos às metacaixas? O sistema atual nos permite adicionar qualquer coisa. Dados, javascript para acertar APIs de terceiros para usar suas ferramentas, uma exibição rápida de notas ou informações de ajuda, e até fotos de gatinhos fofos dando um high five nas pessoas (ok, talvez não este, mas quem sabe né ?!).

O que estou tentando mostrar aqui é que as metacaixas são recipientes universais que podem conter uma variedade de coisas que incluem, mas não se limitam a, campos. No momento, é muito fácil fazer isso com PHP, no entanto, estamos atualmente pedindo às pessoas que saibam como escrever um Componente React apenas para inserir, digamos, algum texto?

Como eu disse, estou apenas tentando adicionar ao contexto da conversa.

Obrigado,

Kevin - Desenvolvedor Líder para Piklist

Esta pergunta foi mencionada em muitos comentários acima, mas não foi respondida que eu saiba:

É possível substituir o editor de postagem TinyMCE existente com Gutenberg, deixando o resto da interface, incluindo metacaixas e ganchos existentes, inalterado?

Este escopo estreito permitiria que Gutenberg fosse incluído ou excluído dos tipos de postagem personalizados, definindo o suporte editor ao registrar o tipo de postagem.

• Se o suporte para editor estiver registrado, então Gutenberg estará presente na tela de edição com as metacaixas existentes continuando a funcionar como funcionam hoje em torno do editor atual.
• Se o suporte para editor não estiver registrado, o Gutenberg não será carregado e a tela em branco estará disponível para as metacaixas como está hoje.

Essa abordagem parece evitar o enorme desafio de compatibilidade com versões anteriores com implementações de metacaixa existentes, enquanto libera recursos para fazer o melhor editor possível.

Posso fazer uma pergunta óbvia aqui? Por que estamos discutindo as 'dificuldades' das metaboxes?

@elliotcondon - se um problema de desenvolvimento é difícil de resolver, a única maneira de chegar a uma solução é trabalhar as dificuldades. Comecei a fazer isso no # 2251, mas conforme explicado lá, não será uma tarefa rápida ou fácil de consertar.

Obrigado por confirmar as informações que coletei sobre como o ACF registra suas metaboxes. Para fazer mais algum progresso na implementação em relação ao ACF especificamente, aqui estão as próximas coisas que seriam úteis saber:

• Quais scripts e folhas de estilo são enfileirados para controlar a funcionalidade das metaboxes ACF
• Quais ações são responsáveis ​​por enfileirá-los
• Quaisquer condições que controlam se eles são enfileirados ou não.

Por que estamos falando apenas em adicionar campos às metacaixas?

Eu gostaria de chegar a um lugar onde o código de Gutenberg não tenha que se importar muito com o que uma metabox está realmente fazendo.

Com esse objetivo, @kevinpmiller , aqui estão as próximas coisas que seria útil saber sobre o Piklist:

• Quais ações são responsáveis ​​por chamar add_meta_box para registrar metaboxes
• Quaisquer condições que controlam se eles estão registrados ou não (por exemplo, a tela atual é post.php ou post-new.php )

Nesta edição, vamos manter a conversa focada em fazer metaboxes PHP existentes funcionarem junto com a interface de Gutenberg.

No momento, é muito fácil fazer isso com PHP, no entanto, estamos atualmente pedindo às pessoas que saibam como escrever um Componente React apenas para inserir, digamos, algum texto?

Sim, precisamos elaborar um conjunto de APIs para criar metaboxes de "novo estilo". Aqui está o que temos hoje para os blocos - espero que seja bem semelhante, com metaboxes sendo registradas como "blocos" que podem salvar em algum lugar diferente de post_content : http://gutenberg-devdoc.surge.sh/

A discussão sobre metaboxes de novo estilo deve acontecer em # 1684 ou em uma edição separada para propor uma API técnica.

Se o suporte para editor não estiver registrado, Gutenberg não será carregado e a tela em branco estará disponível para as metacaixas como está hoje.

@kevinwhoffman - Gutenberg, conforme escrito hoje, pretende ser um editor post_content . Portanto, é lógico que se o suporte para editor não estiver habilitado, pelo menos por agora, nós o desabilitamos. Esta também é uma tarefa muito fácil do ponto de vista do código. Você pode criar um novo problema para isso, e vou marcá-lo com o rótulo Good First Task ?

Gutenberg, conforme escrito hoje, pretende ser um editor post_content .

@nylen Se Gutenberg realmente pretende ser um editor de post_content , então as metacaixas devem ser deixadas sozinhas, pois não estão preocupadas com post_content .

Além disso, a necessidade de uma API para traduzir as metacaixas do PHP em metacaixas do React é um problema fabricado. Não precisa ser um problema, mas se tornou um problema porque em algum lugar ao longo da linha foi decidido que reescrever o editor post_content também mudaria completamente o funcionamento das metacaixas.

Você descreveu o tremendo desafio de escrever tal API em # 2251. Traduzir as metacaixas de PHP em React para uma solução de campos customizados popular como o ACF é desafiador o suficiente, muito menos tentar fazer isso para cada implementação de caixa de metades que existe hoje, popular ou não. Não tem escala.

@kevinwhoffman - Muito bem dito. Isso reflete exatamente meus pensamentos, bem como muitos outros desenvolvedores com quem conversei.

Não desejo tirar esse problema do tópico, mas não entendo por que é necessário haver alguma dificuldade de 'metabox' ao introduzir um novo construtor de página JS. Isso é o que quero dizer quando digo:

Por que estamos discutindo as 'dificuldades' das metaboxes

Estou feliz em ler isso:

Se o suporte do editor não estiver registrado, o Gutenberg não será carregado e a tela em branco estará disponível para as metacaixas como está hoje.

Se o acima for verdadeiro, toda a lógica wp-admin (ações, funções, etc) deve permanecer a mesma (ish) para a tela de edição de uma postagem. Portanto, não deve haver nenhuma razão para que o HTML da metabox não possa ser renderizado como tem feito há anos.

@nylen
O ACF enfileira alguns arquivos JS e CSS para estilizar e interagir com o elemento HTML da metabox ACF.
ACF usa as ações 'admin_enqueue_scripts' para adicionar esses ativos
Muitos outros plug-ins e temas enfileiram estilos / scripts - por que isso seria um problema?
ACF não usa JS para salvar metadados. Ele usa a ação save_post para salvar quaisquer $_POST dados - coisas bem normais.

Além disso, a necessidade de uma API para traduzir as metacaixas do PHP em metacaixas do React é um problema fabricado.

Não é bem isso que estamos fazendo. É mais como: uma vez que não estamos mais usando o processo de carregamento tradicional post.php , precisamos escolher o que precisamos dele.

Se o suporte do editor não estiver registrado, o Gutenberg não será carregado e a tela em branco estará disponível para as metacaixas como está hoje.

Para esclarecer: este não é o caso atualmente, mas seria uma coisa razoável explorar em um PR. Se você está interessado em ver isso funcionando hoje, por favor ajude, será muito mais rápido.

@kevinwhoffman @elliotcondon @nylen Ou melhor ainda, que tal:

• Se o suporte block-editor estiver registrado, use Gutenberg.
• Se o suporte para editor estiver registrado, use o TinyMCE.
• Se nenhum suporte não estiver registrado, nem o Gutenberg nem o TinyMCE serão carregados.

Não sou a favor de fragmentar a experiência WP Admin com base na presença ou ausência de Gutenberg.

Se Gutenberg = New React Meta Boxes e No Gutenberg = Old PHP Meta Boxes, então um administrador fragmentado é a direção que estamos tomando.

As metacaixas devem funcionar da mesma forma em todos os lugares, independentemente da presença de um editor.

Exemplo: Digamos que eu tenha um plugin que adiciona uma metacaixa para classificar as postagens em 5 estrelas. O plugin é construído para que qualquer tipo de postagem possa ser avaliado. Por que a parte interna dessa metacaixa deve mudar com base no fato de o tipo de postagem usar um editor ou não?

@kevinwhoffman

Não sou a favor de fragmentar a experiência WP Admin com base na presença ou ausência de Gutenberg.

Isso foi em resposta à minha sugestão sobre block-editor ou algo mais?

BTW, não vejo minha sugestão como uma fratura da experiência, eu vejo como base para sua sugestão de incluir metacaixas existentes se elas existirem na configuração do WordPress.

@mikeschinkel A capacidade de habilitar ou desabilitar Gutenberg é necessária, mas a ideia de Gutenberg determinar o comportamento da

@kevinwhoffman Estou de acordo com você, aliás.

Em Pods, estamos fazendo coisas normais, documentadas e padronizadas usando as mesmas ações do ACF e CMB2. Estamos todos fazendo isso da maneira recomendada agora.

+1 sobre a capacidade de continuar usando metacaixas ao lado de Gutenberg, em última análise, as pessoas serão capazes de usar Gutenberg para coisas que pertencem diretamente ao conteúdo e para todo o resto ainda há metacaixas que eles adoram para atributos e informações adicionais sobre uma "postagem "(de qualquer tipo).

-1 sobre ter que reescrever tudo no React, pelo menos suportar ambos por um longo tempo até que todos tenham tempo para se familiarizar com o método React e ele suporta mais / resolve as dificuldades para implementações de meta box. Não acho que haja um momento em que as metacaixas do PHP devam ser eliminadas gradualmente, mantenha-as para backcompat e deixe os plug-ins migrarem conforme a documentação da metacaixa do React e as habilidades do desenvolvedor melhorem nessa área.

Após a discussão neste tíquete, bem como as conversas públicas e privadas que dele decorrem, acho que há uma questão crítica que deve ser respondida aqui:

O WordPress pretende descontinuar formalmente a API Metabox?

Se a resposta for Não, então todo o “vamos mudar as coisas e aleijá-las um pouco” é um fracasso. Se a API permanecer compatível com os padrões de compatibilidade retroativa do núcleo do WordPress, a expectativa total é que qualquer implementação existente da metabox funcione. Como as coisas no WordPress fazem.

Se a resposta for Sim, então essa é uma enorme mudança na política de compatibilidade com versões anteriores e o fim da era para o desenvolvimento do WordPress como um todo. Requer não apenas “resolver” metaboxes em Gutenberg. Isso exigiria uma enorme reeducação e esclarecimento de que o período de muitos anos de desenvolvimento do núcleo do WordPress feito de uma certa maneira e fornecendo certo nível de expectativas de compatibilidade com versões anteriores acabou.

Infelizmente a resposta atual parece não ser

A tela Post Edit é _a_ tela mais personalizada em todo projeto que vai além de um blog simples.

Essas personalizações não se limitam ao registro de metaboxes. Qualquer gancho que as telas de administração de edição oferecem está em uso no mesmo projeto. E para os casos em que não há gancho, os desenvolvedores usam jQuery para injetar elementos de IU na página.

Portanto, para essas personalizações, deve haver um caminho a seguir.

Para metaboxes, Fieldmanager é a ferramenta de escolha, por ser aprovada por VIP. Fieldmanager é poderoso, mas focado em um conjunto limitado de campos. Muitas vezes, as bases de código legado não podem ser adaptadas para usar o Fieldmanager ou outra biblioteca de utilitários.

Assim, muitas metaboxes ainda são construídas usando código personalizado. Código customizado significa uma combinação de PHP e JavaScript, geralmente com interações orientadas a Ajax.

A sugestão de colocar todas essas metaboxes cuidadosamente elaboradas de sua posição pretendida em uma área abaixo do editor é absurda.

Qualquer regressão das opções de personalização na tela de pós-edição disponível agora será inaceitável.

Se o código existente precisar ser atualizado, você pode contar de 12 a 18 meses a partir do momento em que todas as novas APIs são finalizadas para que essas atualizações aconteçam nos projetos do cliente. O que significa que deve haver um período de execução dupla, onde as APIs legadas e as novas APIs coexistem.

Eu não entendo por que Metaboxes tem que fazer alguma coisa com Gutenberg? É apenas uma página de backend, tela. Pode ser organizado de centenas de maneiras.
Você disse que a implementação atual quebra React.

Deixe os desenvolvedores escolherem se eles vão amarrar sua Metabox a Gutenberg, ou mantê-los fora.
Todo esse problema é porque você assume que todos terão que fazer blocos de Gutenberg, de uma forma ou de outra. E se eles não quiserem, não precisam disso.

Segundo grande problema para mim pessoalmente. Eu sempre tive problemas com javascript, sou anti-talento para esta linguagem.
Ok, nem tudo gira em torno de mim, mas só para dizer. Não será mais fácil adicionar Metaboxes do que antes.

Acho que @Rarst resumiu o problema de forma maravilhosa. A comunidade precisa de uma resposta clara e parece que a equipe de desenvolvimento parece inclinada a seguir a direção da suspensão de uso, mas ela simplesmente não consegue explicá-la claramente porque está tentando encontrar uma solução primeiro, o que eu respeito completamente. Não precisamos que uma comunidade entre em pânico por meses, mas, ao mesmo tempo, essa mesma comunidade precisa estar alerta o suficiente e um caminho aberto à frente. Este é, honestamente, um compromisso difícil de encontrar.

@ fklein-lu Discordo totalmente que o Fieldmanager deve ser a "ferramenta de escolha". Eu nem mesmo vejo isso na lista dos 10 principais plugins de campos.
https://github.com/WordPress/gutenberg/issues/952#issuecomment -320523428

Como muitos outros disseram, embora eu compreenda o desejo de tornar as metaboxes e Gutenberg uma interface coerente e conectada, mudar a forma como as metaboxes funcionam apresenta complexidades incríveis que podem acabar como um grande impedimento para as pessoas. A história nos mostrou que a introdução de grandes incompatibilidades entre as versões pode fragmentar fortemente uma comunidade.

Como alguém adicionaria Metaboxes à tela de backend do Dashboard?
Não tem nada a ver com Gutenberg.

@khromov Leia o que realmente escrevi, em vez de a postagem que está se referindo, saberia por que Fieldmanager não está na lista dos dez primeiros.

@ fklein-lu Não tenho certeza por que você acha que estou citando errado, aqui está o contexto completo: "Para metaboxes, Fieldmanager é a ferramenta de escolha, por ser aprovada pelo VIP.". Eu não conheço ninguém que use Fieldmanager, então tenho dificuldade em entender essa citação.

Estou ciente de que Fieldmanager não está no WPorg. O que estou dizendo é que não temos dados de uso dele. Eu duvido muito que rivalizasse com alguns dos plug-ins mais populares, e também tem muito pouco suporte da comunidade, exceto aqueles que o usam para VIP, que é uma minoria desaparecendo da quantidade total de desenvolvedores.

Em nossa agência, acreditamos que em algum lugar no 3.x o WordPress passou de Blogging-System para Content Management System. No momento, podemos moldar o conteúdo como o projeto precisa ser e usamos tipos de postagem personalizados e metacaixas para criar uma ampla variedade de conteúdo diferente, não apenas texto.

Se o editor de blocos se tornar obrigatório no 5.0, acreditamos fortemente que isso seria um retrocesso ideológico do CMS para o sistema de blog. Existem toneladas de aplicativos corporativos que executam o WordPress como uma solução de reserva de hotel, uma plataforma de trabalho, um CMS sem cabeça para um aplicativo, serviços de localização, etc, e muitos desses casos de uso nem mesmo têm o editor ativado.

A compatibilidade total com versões anteriores com a implementação atual da metabox é uma OBRIGAÇÃO absoluta. Romper isso quebrará a confiança de clientes e usuários nos próximos anos. Minha solução favorita seria algo nas linhas de ´theme_supports´ e a usabilidade sem distração.

TL; DR: Não espere que os clientes corporativos atualizem seus códigos nos próximos 12 meses para outras coisas além da manutenção. Adicione uma política / aviso de suspensão de uso com um cronograma apropriado. Espere uma grande queda na confiança no WordPress, quando você forçar uma mudança (mesmo para melhor) em termos de backend e usabilidade de código.

Tornou-se de alguma forma como política, ou votação / eleições, não codificação. Algumas pessoas decidiram que os antigos Metaboxes são "velhos", "atrasados", "limitadores" e não há mais lugar para eles. Sem quaisquer argumentos e razões reais contra eles. Eu não os vi, exceto que React e outros scripts são turbo-modernos.

Eu ainda o apóio na busca de soluções para abandonar as velhas Metaboxes e fazê-lo como você imaginou do jeito de Gutenberg. Mas parece que você não tem ideia de como resolver isso.

Difícil discutir tudo isso quando muito ainda é buraco negro para mim. E eu não sou o único.

Apenas para afirmar o quanto sou objetivo neste assunto, ou tentar:

• Eu ainda acho que o TinyMce e a velha pós-tela (com Metaboxes) são as coisas mais bonitas que já vi no mundo do CMS. Funções, filtros, expansões e belo design. Sim, pura beleza e prazer.
• Apesar disso, aceitei Gutenberg desde o primeiro dia. Sim, livre-se de todo esse "velho", troque e nunca mais olhe para trás.

Eles sabiam de algo que eu não sei. Eles possuem código. Mas não tenho mais certeza.

Segunda coisa, esqueci, e é muito importante neste contexto. Já é mencionado algumas vezes aqui.
Eu faço as coisas de maneira um pouco diferente dos outros. A razão pela qual aceitei Gutenberg (pelo menos um deles) desde o primeiro dia é que, pessoalmente, não terei nenhum problema para convencer as pessoas que criei sites a usarem Gutenberg. É um grande choque quando você força sobre eles algo tão diferente do TinyMce.
Eu faço todas as atualizações do plugin e do núcleo do WP para todos eles gratuitamente. Então, neste dilema, quando eles têm que escolher entre Gutenberg e parar de quaisquer atualizações para o resto do tempo. Acho que a escolha deles é óbvia,

Muitos outros desenvolvedores, empresas, cobram por atualizações. Portanto, este dilema não será tão fácil então.

@khromov Eu trabalho para a Alley, que mantém o Fieldmanager. Estamos monitorando ativamente a rosca enquanto a direção do produto é determinada. Seria justo dizer que a base de usuários do WordPress.org geralmente não usa o Fieldmanager, mas o plugin tem ampla adoção como uma biblioteca e estrutura personalizada / corporativa.

Também quero marcar com +1 @Rarst e @kevinwhoffman. Manter o suporte total para as metaboxes existentes ainda pode permitir um futuro em que substituiremos as metaboxes "legadas" por equivalentes de Gutenberg TBD. Mas a incerteza agora em torno da compatibilidade com versões anteriores deve ser mitigada o mais rápido possível.

O número de instalações de plugins do WordPress.org não pode ser a única métrica para a inclusão ou exclusão de um plug-in ou biblioteca. Conheço um site _único_ que usa o Fieldmanager extensivamente e atende cerca de 24 milhões de visitantes únicos por mês.

Portanto, embora apenas um pequeno número de desenvolvedores possa usar um plug-in específico, eles são responsáveis ​​por desenvolver e manter sites que obtêm uma quantidade desproporcional de tráfego e muita visibilidade.

Portanto, eles não podem ser deixados de fora desta discussão. Considero que a equipe de Gutenberg na Automattic deve colaborar com a equipe VIP para obter uma visão desses casos de uso.

Esses projetos corporativos se movem em velocidades mais lentas. Há muito trabalho envolvido na atualização de metaboxes e outros elementos da IU que não são trabalhos de codificação reais. Não há nem mesmo desenvolvedores empresariais suficientes para atualizar todos esses sites no prazo 5.0.

Conforme apontado por outras pessoas neste tópico, é necessário que haja um caminho de atualização que leve esse ritmo em consideração. Assim, as mudanças podem acontecer gradativamente, como parte do trabalho de manutenção proativa.

@ fklein-lu veja acima, estamos ouvindo e você sempre pode entrar em contato se quiser colaborar no código!

Quanto ao VIP e ao mercado corporativo, espero que haja mais do que algumas conversas sobre esse tópico no WordCamp for Publishers na próxima semana em Denver . Dito isso, entramos em contato com Gutenberg devs &

Com relação ao cronograma "5.0", neste ponto os engenheiros corporativos que entrevistei estão assumindo que haveria um caminho de exclusão fácil o suficiente para usar o editor TinyMCE e metaboxes existentes. Acredite que a equipe de Gutenberg também deu a essa suposição.

E eu tenho um site que usa Jetpack e tenho apenas 2 visitantes únicos por dia.
Pare de se ofender tão facilmente. É WordPress, não uma discussão sobre a nova versão do Joomla. :)

@ fklein-lu Concordo absolutamente com você. Mas se alguma coisa fosse a "ferramenta de escolha" para os campos da metabox, eu acho que seria a API Fields proposta.

@davisshaver Acho que é a coisa

Obrigado a todos por participarem aqui e expressarem preocupações e ideias. Este está se tornando um longo tópico, mas tentarei esclarecer alguns pontos.

O WordPress pretende descontinuar formalmente a API Metabox?

Não.

A questão que ainda não foi totalmente respondida é _como funcionam as metacaixas no contexto do editor gutenberg_. Eles devem permanecer os mesmos ou evoluir? Como podemos avançar em direção às metas de design com o mínimo de interrupção possível?

Este problema tem persistido não por falta de vontade, mas por falta de recursos. O foco principal deste projeto é oferecer uma interface de edição de conteúdo rica que otimiza a manipulação direta do conteúdo do usuário por meio da noção de blocos. (Tendo usado meta-caixas extensivamente para vários projetos, acredito que os blocos podem oferecer um melhor passo em frente para muitas dessas necessidades, enquanto fornecem uma melhor experiência do usuário.)

No entanto, existem várias maneiras pelas quais as metacaixas e a extensibilidade podem ser tratadas:

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

Ou qualquer combinação destes.

Nós definitivamente apreciaríamos qualquer ajuda da comunidade na construção da melhor solução aqui, pois, novamente, a falta de certeza não é uma falta de vontade; apenas que as soluções possíveis precisam ser exploradas na prática e as compensações - design e desenvolvimento - claramente escritas.

Não.

Obrigado , acho que muitas pessoas simplesmente exalaram.

A questão que ainda não foi totalmente respondida é como as metacaixas funcionam no contexto do editor gutenberg.

Por que _são_ metacaixas no contexto do editor de Gutenberg?

A resposta parece ser que Gutenberg pretende substituir todo o editor de post _screen_ por uma implementação baseada em JS. Não acompanhei o desenvolvimento para estar ciente das razões disso.

Mas eu ainda acho que foi um ponto muito válido levantado - se o escopo de Gutenberg é ser um componente do editor, então substituir o escopo _screen_ parece excessivamente ambicioso. _Se_ o escopo de Gutenberg é (pelo menos parcial) a substituição do _admin_ do WordPress como um todo, é _incrivelmente_ um escopo mais amplo e exigente. Não que substituir o editor “apenas” seja fácil.

No entanto, existem várias maneiras pelas quais as metacaixas e a extensibilidade podem ser tratadas

O escopo do Gutenberg foi substituir o componente _editor_ principal e a interface de usuário administrativa existente continua a funcionar? _Isto_ está sendo considerado, se não, por que?

Só posso falar pelo plugin do gerenciador de campo que construí e que atualmente usamos em mais de 60 projetos diferentes no momento. Mencionarei brevemente o que essa mudança parece significar para ele, na esperança de que isso possa ajudar qualquer pessoa a pensar sobre seu próprio cenário.

Como tive o trabalho de construir uma arquitetura altamente desacoplada com classes e interfaces abstratas comuns, tudo o que terei de fazer é adicionar um novo "local". Aqui estão os componentes de arquitetura relevantes para o meu ponto:

• Localização: onde o grupo de campo é anexado (por exemplo, postagem, página, termo de taxonomia etc.), com uma variante para cada local (por exemplo, Localização de Postagem e Configurações funciona com metacaixas). Esta classe instancia todas as partes móveis mencionadas abaixo
• Armazenamento de dados de localização: a camada que é responsável por recuperar e persistir os dados, com uma variante para cada localização (por exemplo, o post DataStore funciona com o post meta, Configurações funciona com opções etc.)
• Visualização da localização: quando necessário, como é o caso da página de configurações, é uma classe Visualização que contém o modelo e quaisquer funções auxiliares

Agora, no contexto de Gutenberg, se eu for apoiar este novo editor, tudo que terei que fazer pessoalmente é adicionar um novo local, chamado Gutenberg, e este local terá:

• Seu próprio método de inicialização que o conectará ao editor de Gutenberg. Eu imagino que isso será principalmente baseado em javascript, então minha biblioteca irá registrar e carregar os scripts comuns necessários para este propósito.

• Sua própria visão / modelo: terei que criar um componente de reação para cada tipo de campo. Isso não é grande coisa, a camada de visualização é bastante simples de fazer quando todas as outras peças estão configuradas corretamente. Esses componentes serão então aninhados no componente de reação da metabox. Isso tudo é muito semelhante ao que eu já faço para as metaboxes html baseadas em php, ou seja, campos html> grupo de campos html> localização (página de configurações html, metabox etc.)

• Sua própria classe de armazenamento de dados. Eu não imagino que essa classe seja muito diferente do armazenamento de dados de localização de post, já que será baseado em post meta (imagino que ninguém esteja pensando em descontinuar post meta tão cedo).

• Nova peça: os pontos finais. Esses novos componentes baseados em reação precisarão ser capazes de se comunicar com o armazenamento de dados para recuperar e manter os valores. Como eles vivem completamente no lado do cliente, eles precisarão de endpoints como uma ponte para falar com o armazenamento de dados de localização, com o armazenamento de meta para recuperar os componentes que devem ser carregados em qualquer contexto, etc.

Se eu não estou perdendo nada importante (admito que não tive tempo de verificar Gutenberg ainda), esta é mais ou menos a essência do que eu acho que teria que fazer para apoiar nativamente este novo "local". Eu também tenho verificações integradas para cada local e seus filtros para ter certeza de que o que o desenvolvedor está pedindo é possível, por exemplo, se eu tentar adicionar um grupo de campo a um tipo de postagem "projetos" onde o formato se o tipo de postagem for "vídeo ", mas que o CPT não suporta formatos de postagem, a biblioteca lançará uma exceção. Espero poder fornecer o mesmo feedback com este novo local, por exemplo, se eu adicionar um grupo de campo a um local de Gutenberg onde o tipo de postagem é "comentários", espero poder saber se esse tipo de postagem foi registrado para apoiar Gutenberg.

Isso acabou sendo um pouco mais longo do que eu esperava, meu mal. Eu adoraria ouvir a resposta de qualquer pessoa envolvida no desenvolvimento de Gutenberg ou qualquer autor de bibliotecas com preocupações semelhantes que tenha algum feedback para compartilhar.

Obrigado.

O objetivo do Gutenberg é substituir o componente principal do editor e a interface de usuário administrativa existente continua a funcionar? Isso está sendo considerado, se não, por que?

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

Se o ponto forte do WordPress é tornar mais fácil para qualquer um criar publicações valiosas, então não podemos criar apenas para aqueles de nós que já sabem como usar o editor. Temos que considerar os usuários que nunca usaram o WordPress antes e o que eles esperam de uma interface de publicação moderna. Caso contrário, estaríamos apenas adicionando carga cognitiva a uma interface já pesada.

Ainda não terminamos e não é fácil, mas estamos trabalhando nisso todos os dias.

☝️ Eu atualizei o título e a descrição do tíquete para corrigir alguns equívocos.

O novo editor de Gutenberg e o futuro da ButterBean

Conforme solicitado no comentário acima , estou listando a estrutura da metacaixa ButterBean. Posso criar um novo tíquete, se necessário.

Repo: https://github.com/justintadlock/butterbean/tree/dev

Para fins de teste, a estrutura está incluída neste plug-in: https://github.com/justintadlock/custom-content-portfolio

ButterBean é uma estrutura drop-in construída com Backbone.js e Underscore.js. É fortemente modelado a partir do personalizador no núcleo do WP.

É um framework jovem, mas estou planejando implementar vários plug-ins neste ano. No momento, eu e outros hesitamos em fazer isso por causa da orientação de Gutenberg. E não tenho certeza se não devo simplesmente começar do zero no React ou em qualquer estrutura JS que será finalmente decidida a ser adicionada ao WP central a seguir.

Ganchos usados

A seguir estão os principais ganchos WP usados ​​(bastante padrão para a maioria dos frameworks meta box, imagino):

load-post.php
load-post-new.php 
add_meta_boxes
save_post 
admin_enqueue_scripts
admin_footer 
admin_print_footer_scripts

Criado # 2265 para documentar ganchos relevantes para CMB2.

Adicionado rótulo Design para encorajar as pessoas a adicionar maquetes adicionais.

Em geral, acho que os dados que não fazem parte do conteúdo exibido não deveriam fazer parte da área do editor principal. Nem tudo é um bloco.

1) A maioria das minhas metacaixas personalizadas são feitas com Fieldmanager . A meu ver, eles deveriam "apenas funcionar" sem nenhum trabalho adicional necessário além da atualização. cc / @mboynes e @bcampeau , pois podem ser capazes de fornecer valor a esta discussão.

2) Algumas de nossas metacaixas personalizadas são uma mistura de jQuery e PHP. Por exemplo, temos uma metacaixa "Um ou nenhum" que é um rádio com um botão "limpar". Supondo que isso vai quebrar, eu esperaria que houvesse exemplos de como eu crio isso em Gutenberg e que haveria uma quantidade significativa de tempo para eu atualizar para uma versão do WordPress que exige Gutenberg antes que meu código seja quebrado.

3) Eu tenho outra metabox que combina algum código jQuery e PHP que desativa o botão publicar até que uma seleção seja feita. Semelhante ao meu segundo exemplo, supondo que isso vai quebrar, eu esperaria que houvesse exemplos de como eu crio isso em Gutenberg e que haveria uma quantidade significativa de tempo para eu atualizar para uma versão do WordPress que exige Gutenberg antes meu código quebra.

4) Eu removi a caixa meta da categoria no passado e substituí-a por: 1) uma seleção de rádio 2) Uma versão sem a capacidade de adicionar novas categorias (isso era idiota).

5) Usei post_submitbox_misc_actions para adicionar opções à metabox de publicação que não precisam estar em sua própria metabox.

Quanto ao que quero dizer com uma quantidade significativa de tempo, eu diria cerca de 2 anos a partir do ponto em que a API de Gutenberg é congelada.

Já que estamos nisso, gostaria de lembrar a todos aqui que nem todos usam apenas metaboxes para estender a tela de postagem. Alguns de nós também usam os seguintes ganchos:

• 'edit_form_top'
• 'edit_form_after_title'
• 'edit_form_before_permalink'
• 'edit_form_after_editor'
• 'edit_form_advanced'

Só quero apoiar o que edit_form_[POSITION] ganchos. O Piklist faz uso intensivo de meta-caixas, fluxos de trabalho e outras coisas.

Obrigado novamente pelo seu tempo, pessoal.

A questão de saber se Gutenberg é um substituto de editor ou de tela é importante responder o mais rápido possível, não apenas para aqueles preocupados com a compatibilidade com versões anteriores, mas também para aqueles que estão desenvolvendo Gutenberg. A resposta a essa pergunta afeta muitas das decisões que estão sendo feitas todos os dias sobre como Gutenberg funciona e onde os controles estão localizados.

Ficou claro desde o primeiro beta que já estamos no caminho certo para a substituição da tela, mas essa decisão de reformular a tela também é o que criou os problemas de suporte a caixa de meta e ganchos ausentes. Se a resposta a essas questões for "não substitua a tela inteira", me preocupo com o fato de que tanto trabalho já foi feito sob a suposição da substituição da tela que seria difícil voltar atrás.

Em primeiro lugar, é ótimo ver um progresso real nisso.

Uma observação é que as extensões da tela de edição raramente funcionam isoladas. Por exemplo, o ACF altera os campos visíveis com base nos eventos de alteração JS na caixa de seleção pós-pai.

Considerando que o DOM será diferente em um contexto de Gutenburg e que o React provavelmente seja menos adequado para ouvintes de eventos externos, como podemos continuar a disponibilizar esses dados para metaboxes e outros códigos de plug-in. Uma possibilidade é que o Redux store seja disponibilizado para metaboxes, mas não sei se isso é possível, desejado ou dá flexibilidade suficiente.

Isso se torna ainda mais problemático quando as metaboxes são carregadas em um iframe ou ajaxadas na página.

Ficou claro desde o primeiro beta que já estamos no caminho certo para a substituição da tela, mas essa decisão de reformular a tela também é o que criou os problemas de suporte a caixa de meta e ganchos ausentes. Se a resposta a essas questões for "não substitua a tela inteira", me preocupo com o fato de que tanto trabalho já foi feito sob a suposição da substituição da tela que seria difícil voltar atrás.

Eu entendi completamente quanto trabalho foi feito em relação à abordagem de substituição de "tela". Mas um projeto que começou com o objetivo de substituir o "editor de conteúdo da postagem" não deveria ter voltado para a comunidade antes de decidir unilateralmente que substituiria toda a tela do editor?

Não quero descartar o enorme trabalho que foi feito (o editor realmente parece incrível), mas muito WordPress depende de metacampos que não são estritamente de "conteúdo" e muitos deles não cabem dentro mesmo recipiente Gutenberg (a menos que seja completamente forçado). Para mim, parece mais "temos uma solução e precisamos criar um problema para ela" do que o contrário, que era a declaração original de Gutenberg (o editor de conteúdo de postagem é bastante confuso, os códigos de acesso são tudo menos fáceis de usar - apesar de abordagens como Shortcake -, etc).

A maquete

@rilwis Eu acho que você deveria

Para inspiração de design, você pode verificar os temas Admin de backend gratuitos e comerciais (capturas de tela). Ou qualquer outra plataforma.

Dashboard, mas imagine Gutenberg:

Talvez a API Fields proposta resolva alguns dos problemas relacionados ao suporte de metaboxes no novo editor

O cenário que devemos considerar é o que acontece quando o WordPress é atualizado com Gutenberg e os plug-ins que implementam as metacaixas não são .

Este é o "pior cenário" que representa a maior ameaça para interromper a experiência do administrador, mas não será incomum dado o número de sites com plug-ins de meta box, incluindo jogadores de grande nome e soluções personalizadas únicas.

Contar com a atualização desses plug-ins de metacaixa não deve fazer parte da equação, a menos que estejamos dispostos a reconhecer as mudanças significativas em grande escala. A API Fields é uma ótima ideia, mas não devemos presumir que melhorar a maneira como os campos personalizados são tratados no futuro terá qualquer impacto no código que foi escrito antes que essa API existisse.

É claro que:

• Não vamos quebrar a compatibilidade com versões anteriores em grande escala.
• Não vamos bifurcar a página do editor usando algum mecanismo de detecção.
• Teremos um único editor e experiência de edição.
• Há muitos casos de uso acima que a implementação atual de Gutenberg não pode acomodar.

Portanto:

O caminho a seguir é repensar a tela de pós-edição de uma forma que abrace o novo e o antigo. Isso provavelmente significa retroceder na implementação atual de Gutenberg de alguma maneira. É um desafio de design, não o fim do mundo.

@dmccan Não, essas declarações não são "claras" como todas as soluções propostas até agora:

• Divide a experiência do administrador entre novo / antigo.
• Depende de atualizações de plugins para bloquear suas metacaixas.
• Depende de uma API Fields inexistente.
• Requer que a nova interface tenha o registro cancelado para evitar o problema completamente, o que novamente dividiria a experiência do administrador.

Não enfatizei que o pior cenário era melodramático; Fiz isso para definir as restrições dentro das quais devemos abordar o problema.

Portanto, parece que Gutenberg provavelmente deverá permanecer um plugin de recursos por muito tempo, um que as pessoas podem escolher para selecionar se gostam ou optar por não se não, possivelmente até mesmo incluído como um plugin com o núcleo.

Resolver todos os problemas que ele precisa resolver para ter uma experiência de editor único levará muito tempo de calendário. Basta olhar para o ASP.NET original da Microsoft e como ele resolveu mal o problema geral da web. Eventualmente, o AJAX surgiu e o resto é história.

Forçar uma mudança muito rapidamente pode fazer com que o WordPress se torne uma verdadeira plataforma legada.

PS O requisito do "editor único" parece irreal. Se os usuários tivessem a opção de usar o antigo ou o novo, o novo poderia evoluir com o tempo até que não houvesse mais nenhum benefício em usar o antigo. Mas enquanto houver instalações usando os ganchos existentes _ (eu acredito) _ é irresponsável ir com uma solução de editor único. #jmtcw

@kevinwhoffman - Acho que concordamos, mas talvez eu não tenha sido prolixo o suficiente.

Acho que meus pontos principais são claros e a solução final os engloba. Por exemplo, não acredito que o WordPress vá quebrar a compatibilidade com versões anteriores em grande escala, apesar do que as pessoas em busca de soluções possam propor neste momento.

As soluções propostas até agora estão faltando, e é aí que entra minha conclusão, que precisamos repensar a implementação atual de Gutenberg para abraçar tanto o novo quanto o antigo. Acho que fazer isso é realmente o único caminho a seguir.

@mikeschinkel - Não imagino que Gutenberg seja a única opção de editor no Core em 2017. Pode muito bem ser que comece como uma escolha do usuário e evolua ao ponto de cobrir todas as bases essenciais, ou leva o hora de acertar.

Em qualquer caso, o que estou sugerindo é um retrocesso para incorporar Gutenberg em alguma versão atualizada da tela do editor atual, em vez de jogar tudo fora e depois nos perguntar como podemos lidar com todas as funções essenciais. Eu acho que isso é factível e possivelmente não é um grande retrocesso, uma vez que as pessoas aceitem isso. Esse curso provavelmente seria mais rápido e forneceria uma melhor experiência ao usuário final.

Talvez eles (codificadores principais) devam falar com o Matt. Ele começou tudo isso e agora eles não têm respostas.

@dmccan Uma coisa que acredito que será extremamente importante é que tudo o que for implementado tem um modelo de extensibilidade fácil. O WordPress é conhecido por seu modelo de fácil extensibilidade com ação de plug-in e ganchos de filtro e, sem isso, Gutenberg será tão ruim para o WordPress quanto o sistema de gerenciamento de mídia atual, que é muito difícil de estender.

Como uma nota lateral, embora eu nunca tenha usado React ou Vue _ (eu sou um desenvolvedor PHP) _ a discussão sobre React exigindo um sistema de compilação e que muitas pessoas acharam Vue muito mais fácil de usar do que React me deixou super ansioso se Gutenburg terá um modelo de extensibilidade fácil de aprender e usar ou não, e se isso significará ou não que podemos continuar a usar o WordPress para projetos de clientes.

Apenas meu feedback para observar minha preocupação, não há necessidade de responder diretamente a isso.

Acho que sei do que se trata.
Nunca foi sobre editor de conteúdo, nunca sobre "fluxo de escrita", "rompendo com o antigo .... para trás" etc ...

Trata-se de um editor de temas visuais de front-end completo.

Desculpe por enviar e-mails para todos vocês. Meu último comentário sobre este assunto específico.

@Rarst @kevinwhoffman : Estou totalmente de acordo com você sobre se Gutenberg é ou não um substituto de editor ou de tela . É um ponto bem pensado. E espero que a equipe de desenvolvimento possa voltar ao ponto inicial e à natureza de Gutenberg - um editor, e manter tudo o mais como está agora. São 2 peças diferentes e podem ser usados ​​com ou sem o outro. Portanto, é melhor mantê-los como coisas separadas.

Além disso, criei o # 2308 para listar os ganchos relevantes do plug-in Meta Box.

@ahmadawais Obrigado pela menção.

@nylen Vale a pena adicionar Postagens 2 Postagens à lista de plug-ins a serem considerados. Embora não seja mais compatível, espero que ainda seja amplamente usado.

@nylen Eu mantenho meus campos personalizados do desenvolvedor do plugin

Eu concordo com os comentários sobre o Gutenberg Editor ser apenas isso, a parte de edição de conteúdo. Não tenho certeza por que ou como ele foi desviado para ser uma substituição completa de tela. Todos os construtores de páginas populares fazem isso direito, basta substituir o TinyMCE por algo que torne mais fácil compor o conteúdo.

Além disso, as metacaixas normalmente não fazem parte do conteúdo e, mesmo que estejam relacionadas ao conteúdo, geralmente não fazem sentido ser um bloco.

Pegue um diretório de pessoal, por exemplo. Por que eu iria querer que os campos das informações da pessoa fossem um bloco? Não é como se você desejasse que eles adicionassem outros blocos quando eles deveriam estar inserindo Nome, Sobrenome, etc ...

tldr; Gutenberg só deve substituir o editor TinyMCE para tipos de postagem que precisam de composição de conteúdo.

Apenas adicionando meus dois centavos aqui.

Por que não deixá-lo como está agora? O que quero dizer é isso.

• Mantenha as duas opções de edição ao passar o mouse sobre o título do post como está agora, mas altere-o para que, por padrão, clique no título o levará a Gutenberg. Em seguida, faça com que o link Edit vá para Gutenberg e tenha um link adicional para a tela de edição de classes. Talvez chame de algo como Classic Edit .
• Adicione algum tipo de sinalizador de suporte para o tipo de postagem e postagem da página, para que Gutenberg possa ser desabilitado se um desenvolvedor quiser fazer isso. Se Gutenberg não estiver habilitado, faça com que o link do título vá para a página de edição "clássico", remova o link Edit para Gutenberg e o texto do link Classic Edit mudará para Edit
• Assim, os tipos de postagem personalizados têm suporte de Gutenberg, como Editor, Imagem em destaque, etc. Dessa forma, um CPT não precisa oferecer suporte a Gutenberg.
• Em seguida, atualize o estilo das páginas de edição clássicas. Atualizadas as metacaixas e os estilos da barra lateral para corresponder ao estilo de Gutenberg. Mova até mesmo as metacaixas de excertos e comentários para as barras laterais, como em Gutenberg.

Acho que isso deixaria todo mundo feliz. Gutenberg estaria ativado por padrão para os tipos de postagem e de página. Se os desenvolvedores precisarem usar metacaixas em vez de Gutengerg, eles podem. Isso daria aos plug-ins e desenvolvedores de tema tempo para converter para Gutenberg e daria aos usuários finais a capacidade de se ajustar a Gutenberg sem interferir em seu fluxo de trabalho pela mudança do editor.

E dará aos desenvolvedores tempo para começar a vender a ideia de usar o Gutenberg para os usuários finais. As pessoas tendem a não gostar de mudanças. Deixá-los se acostumar com o novo editor seria muito melhor do que apenas uma mudança difícil.

Isso também separaria os dois, o que permitiria os dois métodos de salvamento diferentes. Gutenberg pode usar JS e o clássico pode continuar usando PHP.

Eu adicionaria algum tipo de aviso, como se um usuário salvasse uma postagem com Gutenberg e, em seguida, tentasse editá-la com o clássico para que soubessem que, se salvarem a postagem, isso substituirá o salvamento anterior do outro editor. Pode haver algo como uma meta de postagem para indicar qual editor foi usado pela última vez.

É uma ideia. Pode ser uma ideia estúpida, mas acho que aliviaria todas as preocupações que muitos desenvolvedores estão tendo.

Estou totalmente de acordo com os pontos que muitas pessoas levantaram sobre o escopo de Gutenberg hoje. Este projeto começou primeiro como uma (muito necessária) melhoria no editor de conteúdo. Lendo este tópico, não posso deixar de sentir que estamos criando problemas que não precisam existir . Se mantivermos o plano original de adicionar Gutenberg ao editor (não substituir a tela inteira), isso resolverá muitos problemas, não apenas em relação às Meta Boxes.

Ao renovar completamente a tela, temo que isso cause muitos problemas para editores de conteúdo não técnicos. O blogueiro / autor médio verá uma tela completamente diferente e entrará em pânico. Se a atualização for direcionada apenas ao editor, a experiência de integração pode ser muito mais controlada.

Outra maneira de abordar isso pode ser usar o mesmo fluxo de trabalho do Beaver Builder . Ou seja, manter a página normal de pós-edição (com as seções normais da Meta Box, etc.), então o Gutenberg pode ser iniciado através de um botão. Isso pode levar você para uma nova tela. Muito parecido com os comentários sobre como direcionar o modo de escrita livre de distração.

Também concordo com as pessoas que sugerem manter a IU da metacaixa existente e alterar apenas o editor de conteúdo.

Acho que a maioria de nós reconhece que o principal fator para impulsionar uma plataforma é inovar. É evidente que o WordPress está lentamente tentando se mover em direção a uma abordagem baseada em JS para experiências mais ricas que podem corresponder (e superar!) O que todo mundo está fazendo. Se formos honestos, todo o sistema metaboxes e a IU da tela de edição atual podem parecer um tanto desatualizados, mas como desenvolvedores estamos tão acostumados com isso que é uma segunda natureza para nós e deixamos de levar em conta a curva de aprendizado existente é para isso.

Ler todo este tópico esclarece duas coisas para mim:

• É óbvio que a equipe principal deseja empurrar para uma tela de edição totalmente baseada em js e, imho, tudo bem
• Talvez se todos nós pudermos aceitar o ponto acima, podemos mover a conversa em direção ao suporte legado e às estratégias de migração para buscar

Assim que entendermos como a versão js das metaboxes eventualmente funcionará (existe uma API proposta?), Poderemos começar a pensar em como criar uma ponte que torne nossa tecnologia existente (plug-ins, gerenciadores de campos etc.) trabalhar com esta nova abordagem.

Se uma discussão focada em API já está acontecendo, alguém poderia apontar a mim e a qualquer outra pessoa que não saiba onde isso está acontecendo na direção certa? Obrigado!

Existe um motivo para não dividir o editor em duas telas navegadas por guias?

Minha opinião é que Gutenberg é,

• Uma tentativa de arrumar a tela do editor
• Uma tentativa de adicionar funcionalidade de construtor de página / layout ao núcleo
• Uma tentativa de minimizar a necessidade de metaboxes, tornando mais fácil para os desenvolvedores criar novos blocos de conteúdo.

Os problemas, conforme destacado acima e como a maioria de nós, desenvolvedores e usuários finais, podemos sentir e prever, é que Gutenberg,

• Remove as opções de formato de estilo do editor dos autores
• Força os autores a usar um fluxo de trabalho não intuitivo que requer muitos cliques do mouse para adicionar blocos
• Quebra muitos plug-ins antigos, alguns dos quais são mantidos e outros não.
• Converte WordPress no que parece uma plataforma de tweet.

Usar Guttenberg para criar conteúdo tem a mesma estranheza de projetar um modelo de e-mail no Mautic ou MailChimp. A IU de Guttenberg funcionaria bem para design de template, mas não para pós-criação de formato longo.

Devemos nos concentrar em aumentar a fluidez do fluxo de trabalho, não na introdução de uma IU de criação de conteúdo para iniciar e parar.

A IU para Guttenberg parece ótima, mas não é realista esperar que os usuários finais fiquem felizes com ela enquanto está em qualquer lugar perto de sua forma atual. Isso atrapalha a criação de conteúdo.

O bloco de texto é quase inútil. Um widget de texto não deve limitar os autores ao uso de apenas alguns formatos de fonte. Isso irritará muitos autores.

Aqui estão minhas sugestões:

• Introduzir Tabify Edit Screens no editor de página.
• Mova metaboxes para sua própria guia de página na tela do editor.
• Use uma página não baseada no React para as metaboxes (página oculta atrás de uma guia do editor)
• Use uma tela baseada em TinyMCE padrão (ou um editor rico em recursos semelhantes) que funciona bem para formatos longos e que não insiste que os autores usem blocos.
• Apresente o Guttenberg Blocks como um complemento para o TinyMCE ou similar ao TinyMCE.
• Apresente o Shortcake ao editor baseado em TinyMCE para que os autores possam ver visualmente o conteúdo dos blocos e para que os autores possam editar o conteúdo diretamente no fluxo da página, sem a necessidade de clicar em um botão de edição para cada bloco.
• Torne mais fácil para os desenvolvedores adicionar novos blocos a Guttenberg ligando add_shortcode () na criação de blocos, por exemplo, add_shortcode ('tag', 'função', 'guttenberg true / false'). Adapte add_shortcode de forma que torne o shortcode automaticamente compatível com Guttenberg; isso permitirá que os desenvolvedores convertam facilmente algumas / muitas de suas metaboxes em códigos de acesso que funcionam com Guttenberg.

O que realmente estou dizendo é que Guttenberg precisa ser dividido em 3 tarefas:

• Limpeza da tela do editor
• IU do editor aprimorada
• Estrutura de extensão do editor aprimorada.

Eu diria que a maioria das pessoas usa o WordPress para criar conteúdo de formato longo e não deseja ser forçada a usar blocos para criar seu conteúdo. Os blocos são ótimos para a criação do layout da página, mas irritantes quando usados ​​sempre que uma postagem é escrita.

Tenho uma cliente que está na casa dos 80 anos. Ela só quer criar conteúdo. Ela não quer ser forçada a reaprender a usar a tela do editor. Demorou mais de um ano para se acostumar com o Visual Composer e é um construtor de páginas fácil de usar.

Eu me desviei do tópico do tópico original, mas isso precisa ser dito: Guttenberg vai matar o WordPress.

Se Guttenberg for apresentado em sua forma atual, o WordPress será bifurcado e a versão de Guttenberg morrerá.

Talvez o novo editor faça mais sentido se você usar o WordPress para um site de blog e criar um tema PHP para ele, mas hoje em dia muitas pessoas usam o WordPress como um CMS para construir aplicativos da web usando React, PODS / ACF e a API REST do WordPress. Daí a necessidade de apoiar metaboxes e campos de relacionamento para links avançados entre CPTs.

Em primeiro lugar, acho que Gutenberg será incrível.

Dito isso, acho que todos concordamos que quebrar sites / funcionalidades quebra a confiança, e isso não é legal. Todos nós queremos poder confiar uns nos outros, e nossos clientes / clientes querem / precisam confiar em nós.

Acho que a melhor coisa que podemos fazer é incluir um filtro que os desenvolvedores possam usar para voltar à tela do editor "legado".

Dessa forma, podemos aplicar nossa própria lógica para determinar se estamos prontos para Gutenberg ou não. Se um usuário estiver usando uma metacaixa que vai quebrar completamente em Gutenberg, podemos escolher reverter para o modo legado.

Então, podemos trabalhar em nosso próprio ritmo para migrar nossas metacaixas ou ideias para que se encaixem em Gutenberg, enquanto mantemos postagens antigas que dependem de nossas metacaixas "legadas" funcionando como deveriam.

Por que as metaboxes herdadas não podem ser renderizadas nos locais (contexto) para os quais estão registradas e continuar funcionando como atualmente?

Portanto, primeiro renderize a seção do editor de Gutenberg (opcional), seguida por qualquer caixa de metacaixa de contexto normal / avançada registrada (legado) (com seu título registrado), em seguida, a barra lateral com a nova coluna Post Settings e sob essa qualquer lado registrado (legado) metacaixa de contexto (com seu título registrado).

É claro que a metacaixa herdada teria o mesmo estilo da nova caixa Configurações de postagem, tudo pareceria bem integrado.

Talvez fosse necessário um script legacy-meta-box.php que seria carregado quando necessário, por exemplo, quando add_meta_box é chamado.

Se pensarmos apenas nas soluções atuais de metacaixas como "legadas" e exigirmos que usem o editor antigo, sem nunca pensar nas razões para usá-las em primeiro lugar e, em seguida, trabalhar em melhores maneiras de fornecer essa funcionalidade no novo editor, então os sites atuais simplesmente permanecerão legados e nunca serão atualizados. Este será um grande problema para aqueles que gerenciam sites de clientes.

O motivo pelo qual usamos os campos ACF em quase todos os nossos projetos é para controlar os dados para que sejam exibidos de forma consistente no site. Aqui estão dois exemplos em que estamos trabalhando atualmente; Um grande site de eventos e um festival com obras / instalações que precisam ser vinculadas aos artistas, mas exibidas separadamente. Em ambos os casos, o "conteúdo", a peça que Gutenberg está substituindo, representa apenas cerca de 10% do conteúdo da tela de edição e é, na verdade, a peça menos importante. Para o site de eventos, os dados importantes são o tipo de evento, categoria de evento, data, hora, local, organizador, etc. Você pode publicar uma entrada de evento significativa sem inserir nenhum conteúdo no editor. Para o site do festival, precisamos ser capazes de selecionar um artista e vinculá-lo a uma obra, selecionar o local das obras no site do festival e fazer o upload de uma imagem destacada, novamente o conteúdo é um extra, não uma necessidade. Para todo o conteúdo da página "normal" nesses sites, Gutenberg não é flexível o suficiente (e nem deveria ser por padrão, eu não acredito) e nós continuaríamos usando um construtor de páginas com mais recursos (Beaver Builder) para melhor opções de design.

O outro fator importante em tudo isso é a ordem do conteúdo na tela de edição. Para um evento, você precisa definir um título, mas em um fluxo de edição ideal, você deseja que algumas das informações importantes, como data, hora, etc., sejam inseridas ANTES de inserir qualquer "conteúdo" no "editor". Precisamos ter a capacidade de controlar onde está o conteúdo na página de edição, antes ou depois do "conteúdo".

A ideia de apenas criar outra guia com todas as metacaixas "legadas" nela seria horrível. Isso quebraria totalmente o fluxo de edição para muitos usos de CPTs, escondendo o conteúdo dos usuários de uma forma que acho que eles achariam muito difícil de descobrir.

O projeto precisa ser MUITO mais inteligente sobre isso. Um processo com guias pode funcionar muito bem se você puder escolher (em algum tipo de modelo de página) quais bits estão em quais guias. Você também precisaria de um mecanismo para guiar o usuário por cada guia. No entanto, também acredito que para itens de CPT mais curtos, você PRECISA ter a capacidade de manter tudo em uma página com certos elementos-chave acima do conteúdo do editor (blocos obrigatórios, se preferir).

Em suma, a maioria das soluções sobre as quais as pessoas estão falando não parecem ter a flexibilidade da tela de edição atual.

É por isso que estou assustado com a linha do tempo 5.0 para isso, parece que pode ser ótimo com o tempo, mas se for apressado, a fragmentação destruirá toda a boa vontade dos desenvolvedores e clientes. O WordPress está negociando em sua flexibilidade, compatibilidade com versões anteriores e facilidade de uso geral. Não podemos sacrificar isso pelo novo brinquedo brilhante. Olhe para os requisitos de PHP para WordPress, estamos falando literalmente anos antes de o PHP 5.6 ou 7 ser um requisito. A comunidade reconheceu que não importa o quão frustrante seja esse período de tempo, é necessário não quebrar sites. Não é EXATAMENTE o mesmo tipo de problema?

Mudanças como essa, embora sejam ótimas para a plataforma, precisam ser bem pensadas e gerenciadas ou arriscam a própria base sobre a qual o WordPress foi construído.

@avocadesign - Alguns pontos positivos. Poderemos registrar metacaixas JavaScript a partir de agora, embora pareça que o pensamento atual é ter dois locais ... o que não é tão flexível como você mencionou.

@avocadesign - bem explicado. O post_content nem sempre é o foco de uma postagem e seus 'eventos e artistas' são um bom exemplo. Seria ótimo ver algumas capturas de tela mostrando o back-end e o front-end desses tipos de postagem para que possamos ajudar os desenvolvedores a visualizar como o WP está sendo usado como um CMS e como um cliente típico funciona por meio de uma tela de pós-edição.

@avocadesign

Se apenas pensarmos nas soluções atuais de metacaixas como "legadas" e exigirmos que usem o editor antigo

No que eu sugeri (acima do seu comentário), as metacaixas 'legadas' são posicionadas sob o editor de Gutenberg (se o tipo de postagem precisar disso) ou sob o bloco Configurações de postagem (dependendo do contexto para o qual estão registradas). Não vejo nenhum requisito para manter o antigo editor por perto.

Concordo que uma interface com guias não funcionaria. O que você acha da minha sugestão. A meu ver, isso daria a você toda a flexibilidade com a qual está acostumado e permitiria que você mudasse para o novo sistema quando estiver pronto.

Se Gutenberg se tornasse parte do núcleo, você seria capaz de construir uma IU ainda melhor para os exemplos que mencionou. Ele consistiria parcialmente em um bloco de Festival personalizado (tipo de formulário WYSIWYG) e configurações relacionadas em uma ou mais seções de Configurações de postagem (baseadas em JS). O usuário se beneficiaria com uma interface mais rápida com feedback direto.

O WordPress está negociando em sua flexibilidade, compatibilidade com versões anteriores e facilidade de uso geral. Não podemos sacrificar isso pelo novo brinquedo brilhante.

Discordo. Acho que você deveria dar um pouco mais de crédito ao Gutenberg. Eles estão trabalhando muito em uma solução que funcione para todos. Eles estão ouvindo e procurando casos de uso (exatamente como aquele que você mencionou). Nada está definido ainda, nem o lançamento do qual Gutenberg "pode" fazer parte.
Se Gutenberg não resolver todos os problemas atualmente em discussão, você pode confiar que não fará parte da versão 5.0. Já vimos isso acontecer inúmeras vezes com outros recursos também.

Aqui está um exemplo de uma interface que construí com Campos personalizados avançados para um cliente que gerencia propriedades de hotéis.

• O tipo de postagem personalizada Propriedade usa 18 campos personalizados em 10 guias.
• As guias mantêm todas as informações pertinentes em uma tela e acessíveis ao editor com o clique de um botão.
• Os tipos de campo incluem texto simples e campos de número, além de galerias ACF e campos de relacionamento.
• O suporte para editor não foi declarado no registro de tipo de postagem personalizado, o que significa que toda a IU depende de metacaixas personalizadas.

Este tipo de IU é representativo de muitos sites WordPress personalizados, onde uma série de campos personalizados contém uma mistura de conteúdo na página e metadados "invisíveis" usados ​​para organizar postagens.

A comunidade precisa saber o que acontece com esse tipo de interface depois que Gutenberg é apresentado, e não acho que pedir a @elliotcondon para migrar tudo para React a tempo do lançamento seja uma expectativa realista.

@kevinwhoffman

A comunidade precisa saber o que acontece com este tipo de interface depois que Gutenberg é apresentado

Você está certo, mas o objetivo desta edição # 952 é _encontrar_ essa resposta discutindo e sugerindo alternativas. O que funcionaria o que não. Em algum momento no futuro, quando todos pensarem que todos nós chegamos a algo que funcionaria em todos os casos legados e futuros, só então isso poderá ser implementado e a comunidade (de usuários) poderá ser explicada como funcionará. Atualmente é simplesmente muito cedo para esperar uma resposta da equipe a essa pergunta IMHO.

Acho que o caso de uso que você fornece e o que @avocadesign fornece vai ajudar muito a equipe.

Em relação ao seu exemplo, minha sugestão (veja algumas reações acima) simplesmente mostraria todas as caixas conforme mostrado na imagem (com o novo estilo de Gutenberg, é claro).

@kevinwhoffman

Gutenberg provavelmente aceitará os CPTs, da mesma forma que o seu CPT não declara suporte para o editor atual. Não vejo por que nunca seria opt-in para CPTs, já que a maioria das coisas no WordPress são extremamente flexíveis, Gutenberg não será diferente. Atualmente só funciona para postagens.

Eu duvido muito que Gutenberg mudaria alguma coisa para uma interface como essa, nem é a intenção. Dito isso, pode ser interessante explorar o que Gutenberg oferece e ver se você pode criar uma experiência de edição mais atraente para seu cliente usando-o.

Por exemplo, você pode criar um bloco de propriedade / propriedades, que pode ser usado para permitir que seu cliente incorpore informações de propriedade em outras postagens, etc. com rapidez e facilidade. Então, durante a edição em Gutenberg, eles poderiam alterar as mesmas informações que você vê no ACF enquanto olham para as informações de propriedade exibidas dentro de Gutenberg. Gutenberg não está ultrapassando a interface de administração do WordPress, ele está substituindo a funcionalidade do editor e muito provavelmente levará ao bloqueio de modelos de conteúdo baseados.

Coisas boas estão vindo de Gutenberg, não dores de cabeça!

Aqui está a tela de edição de eventos para o site mencionado acima com os campos ACF acima do post_content e, em seguida, a metacaixa padrão do Calendário de eventos abaixo de post_content.

O site será aberto para muitos usuários não técnicos, não estamos falando de uma equipe editorial treinada, estamos falando da média de Joe que nunca usou WordPress antes ou foi treinado além da ajuda que fornecemos no site.

Nós definimos dessa forma para garantir que os usuários encontrem e digitem o tipo de evento, a categoria, o cabeçalho e as imagens em destaque para cada evento. Também podemos usar as posições de metacaixa existentes para fornecer documentação de ajuda relevante na tela para ajudá-los a editar o evento e fornecer suporte a novos usuários de uma forma não intrusiva.

Além disso, tenha em mente que estamos logados como um administrador, os usuários não administradores têm várias metacaixas da barra lateral ocultas para reduzir ainda mais a confusão visual que veem.

O "conteúdo" não é tão relevante quanto as várias metacaixas para inserir um evento com sucesso. Um evento não será exibido no site se uma data não for inserida corretamente ou uma categoria selecionada. O que me preocupa em toda essa discussão são os mock ups como na edição # 1352, onde as metacaixas são relegadas para a parte inferior da tela em uma seção dobrável. Posso garantir que, por experiência própria, teríamos usuários não treinados nunca vendo as metacaixas, apenas inserindo a data e o local diretamente na área de conteúdo como texto simples e reclamando que seu evento não estava aparecendo no sistema. Simplesmente não é detectável o suficiente para usuários não treinados em tipos de postagem que exigem informações estruturadas.

Além disso, temos campos obrigatórios nesta interface e se a caixa-meta for recolhida, o usuário receberá um aviso, mas não será capaz de encontrar facilmente a causa do problema.

Metaboxes ou a próxima iteração de seu tipo de funcionalidade precisam ser cidadãos de primeira classe e precisamos da capacidade de colocá-los acima do conteúdo, ao lado do conteúdo ou abaixo do conteúdo, a fim de fazer interfaces utilizáveis ​​para nossos clientes.

Gutenberg provavelmente aceitará os CPTs, da mesma forma que o seu CPT não declara suporte para o editor atual.

O registro do suporte para Gutenberg em CPTs não foi confirmado e, honestamente, parece mais evitar o problema das metacaixas do que resolvê-lo. Se a única maneira de os sites existentes acessarem Gutenberg for registrar o suporte para ele por código, isso limitaria severamente o público potencial.

Também não devemos fingir que as metacaixas personalizadas são usadas apenas em tipos de postagem personalizados. Eles têm a mesma probabilidade de existir em postagens e páginas regulares.

Gutenberg não está ultrapassando a interface administrativa do WordPress, está substituindo a funcionalidade do editor ...

Isso é impreciso. Como existe hoje, Gutenberg _is_ uma substituição de tela inteira para a tela de pós-edição.

@ BE-Webdesign e @kevinwhoffman

Além disso, por que os CPTs devem perder os aspectos de Gutenberg que são claramente melhores do que a tela de edição atual?

Os controles de publicação sendo movidos para o topo para que não sejam confundidos com o conteúdo e uma estética geral mais limpa são definitivamente pontos fortes do rumo desse projeto.

Por não ter um plano decente de como criar funcionalidade equivalente ao que existe atualmente para CPTs com necessidades complexas (via metabaixas), estamos ignorando uma grande parte da base de usuários e relegando-os para uma segunda classe, experiência sem suporte.

IMHO que simplesmente é uma merda.

Não estou nem mesmo argumentando que as metaboxes precisam funcionar prontamente como existem atualmente. Pode haver uma maneira nova e melhor de implementar esse tipo de flexibilidade de interface.

O que me preocupa é que a equipe de desenvolvimento realmente não parece entender os problemas de muitos desenvolvedores com a aplicação de uma primeira abordagem "post_content" aqui. Usamos o Beaver builder em TODOS os nossos sites, exceto para CPT's onde precisamos de saída de dados estruturados. Uma ferramenta de criação de páginas, que é o que Gutenberg é, é ótima para postagens e páginas com necessidades de conteúdo individuais. É terrível para dados estruturados. Para dados estruturados, consistência de interface, campos obrigatórios e outras prioridades de layout superam o conteúdo de formato livre sempre.

@kevinwhoffman

Também não devemos fingir que as metacaixas personalizadas são usadas apenas em tipos de postagem personalizados. Eles têm a mesma probabilidade de existir em postagens e páginas regulares. Isso é impreciso. Como existe hoje, Gutenberg é um substituto de tela inteira para a tela de pós-edição.

Sim, mas não está substituindo toda a interface de administração, a que me referia. Você está comparando um projeto incompleto com a experiência atual. # 2251, quando estiver completo, irá introduzir as todo-poderosas metacaixas de volta, então não será tão diferente, e será muito melhor. Provavelmente haverá algumas coisas que certos autores de plug-ins podem ter que ajustar, mas na maior parte, estou confiante de que tudo correrá bem.

@avocadesign

Além disso, por que os CPTs devem perder os aspectos de Gutenberg que são claramente melhores do que a tela de edição atual?

Ninguém disse que sim? Não há muita diferença entre adicionar suporte de editor para um CPT e adicionar suporte para editor de bloco.

Por não ter um plano decente de como criar funcionalidade equivalente ao que existe atualmente para CPTs com necessidades complexas (via metabaixas), estamos ignorando uma grande parte da base de usuários e relegando-os para uma segunda classe, experiência sem suporte.

Acho que existe um plano decente em vigor, talvez não seja claro, mas estou muito confiante de que Gutenberg atenderá às necessidades da grande maioria de todos os tipos de usuários, até mesmo os excederá, quando tudo estiver dito e feito.

Ninguém disse que sim? Não há muita diferença entre adicionar suporte de editor para um CPT e adicionar suporte para editor de bloco.

Eu me preocupo que a etapa falada por muitos neste tópico de fazer Gutenberg optar por CPTs irá resultar em muitos dos atuais casos de uso complexos a serem ignorados em Gutenberg no curto a médio prazo e efetivamente forçar casos de uso como os eventos um ilustrado acima para usar o sistema existente porque Gutenberg não é flexível o suficiente. Isso está efetivamente forçando os atuais casos de uso complexos a perder as outras vantagens do projeto.

Estamos sendo informados de "não se preocupe, vai ficar tudo bem", mas você está certo @ BE-Webdesign quando sugere que o plano não está claramente apresentado para alguns de nós, simplesmente não consigo ver em tudo como isso vai ser resolvido de forma satisfatória no curto prazo - se for então, sinta-se à vontade para apontar a discussão ou questão para me esclarecer.

Editar:
O que quero dizer com "curto prazo" é o lançamento do 5.0 ao público, o início de 2018 parece ser o objetivo aqui. A longo prazo, em 2 ou 3 anos, posso ver isso sendo resolvido com muito mais sucesso.

@BennyVL & @dmccan Flexibilidade é o problema chave aqui. Corrija-me se eu estiver errado, mas nada do que estou vendo sugerido pelos desenvolvedores que estão trabalhando nisso é tão flexível quanto o que temos atualmente.

Com ACF e outros plug-ins, posso registrar metaboxes facilmente acima do conteúdo (abaixo do título), abaixo do conteúdo e na barra lateral. O design da interface depende de mim. Não obriga que o editor seja o primeiro, não obriga que o editor esteja mesmo presente. Posso registrar novas metaboxes, posso cancelar o registro ou mover outras.

O que eu quero é uma solução que permaneça tão flexível no longo prazo. Se as metaboxes precisam ser atualizadas para um formato JS novinho em folha, se tornam blocos adequados ou alguma outra mudança precisa acontecer para tornar isso possível, não me incomoda. Quero que a flexibilidade de que desfrutamos atualmente seja incluída em Gutenberg, independentemente do método usado para chegar lá.

O que eu quero é uma solução que permaneça tão flexível no longo prazo. Se as metaboxes precisam ser atualizadas para um formato JS novinho em folha, se tornam blocos adequados ou alguma outra mudança precisa acontecer para tornar isso possível, não me incomoda. Quero que a flexibilidade de que desfrutamos atualmente seja incluída em Gutenberg, independentemente do método usado para chegar lá.

Esse é o objetivo e o que a maioria das pessoas deseja.

Tenho ouvido muitas conversas sobre o problema da metacaixa e o que acontecerá com este novo editor. Minha opinião pessoal é que Gutenberg deve se concentrar apenas no editor e não em toda a tela de edição da página. Mas parece que a decisão já foi tomada.

Oi pessoal,

Sou o desenvolvedor líder de Carbon Fields e gostaria de adicionar a lista de ações / filtros que usamos que podem ser afetados:

Filtros:

• postbox_classes_{$page}_{$id}

Ações:

• init
• admin_menu
• admin_init
• wp
• admin_enqueue_scripts
• in_admin_header
• admin_notices
• admin_print_footer_scripts
• save_post
• edit_comment
• media_buttons
• edit_form_after_title (posicionamento de açúcar - não crítico)

Minhas perguntas:

• Se vamos manter as metacaixas legadas, como elas interagiriam com as alterações de dados?
• Que tipo de eventos (jQuery? Alguma implementação exposta de um emissor?) E quais eventos exatamente podemos esperar do novo editor (por exemplo, sucesso de envio, falha etc.)?
• Esses eventos estarão disponíveis para metacaixas legadas ou apenas para implementações do React?

PS:
Eu só quero agradecer à equipe de Gutenberg por todo o trabalho árduo e esforço e me deixa animado que o WordPress está se movendo em direção a ferramentas e soluções modernas (mesmo que a jornada pareça assustadora)!

Apoiar metacaixas é muito importante ...

... para milhares de desenvolvedores e usuários do wordpress.

WordPress não pode ignorar o grande plugin player ...

... como Advacend Custom Fields Pro (https://github.com/elliotcondon/acf/issues/622), WooCommerce ou Yoast SEO.

Sou responsável pelo projeto do conjunto de ferramentas , que usa fortemente tipos, campos e taxonomia personalizados.

Queremos tornar nossos plug-ins compatíveis com Gutenberg.

Isso é o que eu entendo:

• Precisaremos usar uma nova API para exibir os campos personalizados e taxonomia em páginas e postagens, quando eles usam Gutenberg.
• Não precisamos fazer nada sobre Gutenberg para CPTs, porque eles usarão o editor WordPress normal e não Gutenberg.

Isso está correto? Em caso afirmativo, você poderia gentilmente me referir à documentação da API para exibição de caixas personalizadas no Gutenberg?

Acho que os documentos ainda estão evoluindo. Existem alguns documentos em https://github.com/WordPress/gutenberg/tree/master/docs - http://gutenberg-devdoc.surge.sh/

Estou ouvindo o que @ BE-Webdesign e outros estão dizendo sobre a intenção de minimizar a interrupção - obrigado, isso é reconfortante - mas só queria adicionar meu valor de 5p (ok, ok, meu valor normal de 105p).

Qualquer um que já esteja desenvolvendo por um tempo se lembrará da dor de criar manualmente interfaces da web para bancos de dados personalizados - enfadonho, demorado, sujeito a erros e muito caro em termos de tempo de desenvolvedor.

WordPress plus Advanced Custom Fields (Pro) é uma ótima ferramenta para criar com eficiência sites baseados em banco de dados personalizados (e até ferramentas de gerenciamento de dados de intranet) com front-ends atraentes, verificação rigorosa de entrada de dados, interfaces de usuário intuitivas e consistentes, etc. ser escalonável para enormes volumes de dados relacionais, mas em muitos casos eles não precisam ser; são sistemas simples que podem ser criados de maneira econômica para os clientes. Isso é o que torna o WordPress um CMS realmente útil (e, na verdade, um RDBMS leve), não apenas uma plataforma de blog.

Eu (e tenho certeza que muitas outras) pequenas empresas usam WP + ACF (ou plug-ins de dados personalizados semelhantes) para criar sites e sistemas sob medida para organizações clientes e indivíduos que não têm grandes orçamentos de TI. Se a introdução de Gutenberg for feita sem a devida consideração pelo suporte aos fluxos existentes de edição / entrada de dados, metaboxes etc., eu tenho dois problemas "não técnicos", mas ainda assim significativos:

1 / Meus usuários finais precisarão de novo treinamento (é fácil para nós, como técnicos, esquecer o quão confusos usuários não técnicos podem ficar com as mudanças de interface - eu escrevi o plugin Clarify Password Reset porque estava perdendo muito tempo resolvendo usuários que foram totalmente bloqueados pelo novo processo de redefinição de senha introduzido em 4.3).

2 / Além de atualizar meus próprios plug-ins para uma abordagem diferente da metabox, terei que gastar tempo atualizando e testando todos os meus sites de clientes com um nível profissional de diligência, certificando-me de que todos e quaisquer plug-ins de terceiros que estou usando também conseguiram atualizar sua base de código corretamente. (E isso em uma situação em que não tenho controle sobre a rapidez com que os plug-ins de terceiros são atualizados, seja antes ou (pior ainda) em algum momento após a versão 5.0 - então, o planejamento da carga de trabalho se torna realmente difícil.)

Em nenhum dos casos acima, eu acharia certo cobrar de meus clientes taxas adicionais por esse trabalho adicional; afinal, escolhi a plataforma para construir seus sites e sistemas, e não é como se eles tivessem solicitado qualquer mudança ou melhoria. Talvez eu seja "legal demais" ou ingênuo nesse aspecto, mas, como as pessoas mencionaram acima, é uma questão de confiança; confiamos que o WordPress não nos deixará na merda, quebrando a compatibilidade com versões anteriores, de modo que nossos clientes possam confiar que não iremos incomodá-los por taxas extras inesperadas. O resultado líquido é que repentinamente tenho uma enorme quantidade de trabalho extra não remunerado para, de alguma forma, encaixar - possivelmente com urgência, se os sites forem ativamente interrompidos pela atualização imediatamente - enquanto continuo a fazer trabalho remunerado suficiente para me manter à tona.

Eu realmente gosto de usar o WordPress, e investi muito tempo aprendendo as cordas, desenvolvendo meus próprios frameworks de projeto úteis, etc. - ao ponto de agora ganhar a maior parte da minha vida (e alimentar minha família, etc.) através de projetos de desenvolvimento baseados em WordPress. Também tentei retribuir, reservando um tempo para lançar formalmente pequenos plug-ins úteis que desenvolvi no WordPress.com, porque valorizo ​​o OSS, o desenvolvimento baseado na comunidade, etc. Acho que isso é principalmente um apelo para resolver os problemas mencionado neste problema, encadeie o máximo possível; caso contrário, concordo que há um perigo real de que a base de código seja bifurcada. Como um fã do WordPress e contribuidor do plugin, eu acho que este é um resultado REALMENTE ruim; no entanto, como um desenvolvedor solo que depende do WP para ganhar a vida, posso ter que escolher a versão bifurcada (ou seja, compatível com versões anteriores) por necessidade econômica. Por favor, não deixe isso acontecer!

@konamac faz alguns pontos importantes, alguns dos quais eu postei em outro tópico.

Para tirar vantagem disso, é totalmente inaceitável não nos dar uma resposta tranquilizadora sobre o futuro das metaboxes.

1. Não há uma resposta direta ao suporte futuro das metaboxes existentes. Este é um movimento extremamente frustrante e pesado contra agências de desenvolvimento e autores de temas / plugins. "Gutenberg é open source, então descubram-se" é irresponsável.

2. Gutenberg é incrível. Eu amo a interface, o design visual e acho que esse é o caminho do futuro em termos de edição de conteúdo. Mas está muito aquém do necessário para considerá-lo para uma versão 4.9 ou 5.0.

3. Tudo o que devo ser capaz de fazer no legado é tudo o que devo ser capaz de fazer em Gutenberg.

4. Opções de tela
5. Metabaixas (ACF, Yoast, etc)
6. Permalinks ?! Não consigo nem começar a entender por que isso ainda não é editável em 1.0
7. O bloco de conteúdo clássico NÃO carrega corretamente em ambientes de host local
8. A documentação DEVE ser a chave para criar diferentes blocos de estilo. Dê vários exemplos, vários casos de uso. Nem todo desenvolvedor de tema é backend, então não faça suposições. Seja cristalino
9. As configurações de bloqueio precisam ser corrigidas. É muito difícil dizer quais configurações estão disponíveis por bloco. Parece aleatório. Quando preciso editar as configurações de bloqueio e quando não?
10. Todas as tags de comentários em torno do editor de texto Gutenberg são ... tristes de ver.

Alguns de nós estão ficando extremamente frustrados com esse processo. Deve ser uma resposta muito simples.

Gutenberg protegerá o uso atual de metaboxes / ACF, e existem planos em vigor para garantir esse suporte indefinidamente?

Não precisamos saber qual é a solução agora - sabemos que você está descobrindo. Mas ainda não temos uma resposta CLARA sobre isso. O ACF, em particular, precisa funcionar da mesma maneira que sempre para oferecer suporte a clientes mais antigos que NÃO concordarão em ser cobrados pela atualização - especialmente ao discutir a remoção do editor legado em algum momento (como você pode começar a ter essa conversa agora ?! )

Amo Gutenberg. Mas eu tenho que entrar no coro - isso está ficando ridículo. A maneira como a equipe do projeto comunicou essa expectativa não foi simples. Sim ou não é tudo o que procuramos.

@ BE-Webdesign

quando estiver completo, irá introduzir as todo-poderosas metacaixas de volta em

Posso, portanto, sugerir que você escreva um post inteiro sobre este assunto, que você de fato indicou, que as metacaixas, como estão agora, vão ficar, por favor. Isso evitaria muitos desenvolvedores preocupados na comunidade que estão preocupados com seus negócios.

Além disso, eu encorajaria a equipe a fazer disso uma prioridade para adicioná-los agora. Isso evitaria muito da negatividade em torno do projeto, tenho certeza.

Conforme declarado em # 2308, copiei os ganchos que o plug-in Meta Box usa ao criar / salvar campos personalizados:

• Scripts e estilos são enfileirados usando admin_enqueue_scripts . Verificamos a tela atual (por meio de get_current_screen ) para garantir que os scripts e estilos sejam enfileirados apenas para essas páginas. Para o plugin principal, ele verifica por tipos de post. Para extensões (termo meta, meta do usuário, página de configurações), verifica mais taxonomias, página de perfil do usuário ou páginas de configuração.
• Também usamos print_media_templates para imprimir modelos de sublinhados.
• Os scripts que usamos no plugin incluem: seletor de cores, sublinhado, backbone, scripts de mídia, tinymce (para o campo do editor)
• Usamos init para inicializar todos os ganchos para o plugin.
• As meta-caixas são registradas usando ganchos add_meta_boxes .
• Metabaixas ocultas usam default_hidden_meta_boxes .
• Também conectamos post_edit_form_tag para permitir o upload de arquivos.
• Usamos save_post_{$post_type} e edit_attachment , add_attachment para salvar valores meta para postagens e anexos.

O que há de errado em construir ganchos para exibir metaboxes acima / abaixo / barra lateral de Gutenberg?

Percebi que também posso fazer o que os desenvolvedores terceirizados fazem de melhor, e lançar outra chave enorme no trabalho.

Mattias nos diz que metaboxes podem ser reinventados como blocos que armazenam em post_meta. Se essa é uma meta de fusão, então há alguns problemas a resolver:

Muitas metaboxes registram the_editor($custom_id); para que isso seja suportado no contexto de Gutenberg, uma interface e api para criar blocos aninhados é necessária desde o primeiro dia, ou estamos dizendo que metaboxes só podem ter a interface do editor de segunda classe , sem nenhum dos benefícios dos blocos. Isso será particularmente problemático para o grande número de agências que atualmente projetam usando layouts flexíveis ACF, pois elas precisarão de uma maneira de criar blocos de Gutenberg separados para vários contextos e áreas. Mesmo "pensando em blocos", não vejo uma boa maneira de resolver o problema de "área de conteúdo seguida por parte de modelo seguida por área de conteúdo" sem oferecer suporte ao aninhamento em "metablocos" desde o primeiro dia.

Decorrente disso, está a preocupação técnica de aninhamento em relação aos blocos que não são armazenados em post_content. Mattias diz que os blocos serão capazes de armazenar em postmeta, mas se um bloco pode definir onde ele é armazenado, como funcionará o aninhamento, quando um bloco pai armazena em postmeta e o usuário adiciona um filho que armazena em um post_meta diferente ... (Ou, no caso patológico, um bloco aninhado que Tha armazena no postmeta contém um bloco que armazena no mesmo campo postmeta.

Isso leva a uma terceira preocupação do metabox. Se Gutenberg for uma substituição completa da página de edição, em vez de uma substituição de the_editor() , como as pessoas poderão enfileirar e usar blocos em outras páginas e em outros contextos, como metaboxes ou painéis de administração personalizados que usam the_editor() . À primeira vista, parece que a resposta será "eles não podem". O que leva a sérias preocupações sobre se Gutenberg adiciona flexibilidade às implementações de CMS personalizadas ou a remove.

Se os usuários tiverem a opção de Gutenberg, e isso é tão revolucionário para eles quanto afirmado, não ser capaz de fornecer essa nova interface nesses casos pode ser desastroso para as agências.

Não há uma resposta direta ao suporte futuro das metaboxes existentes.

Eu disse várias vezes que vamos levar em conta as metacaixas. A única incerteza é o que é tecnicamente viável e como será exibido na nova IU.

Não estamos tentando quebrar nada - códigos de acesso, campos personalizados, etc - tudo ainda deve funcionar. A interface do usuário para interagir com eles pode mudar (a menos que você desabilite Gutenberg completamente), e certos casos de uso para metacaixas serão mais adequados para blocos posteriores.

Gutenberg é incrível. Eu amo a interface, o design visual e acho que esse é o caminho do futuro em termos de edição de conteúdo.

Estou feliz em ouvir!

Permalinks ?! Não consigo nem começar a entender por que isso ainda não é editável em 1.0

Porque a API REST ainda não oferece suporte para isso. Qualquer ajuda é bem-vinda: https://github.com/WordPress/gutenberg/issues/1285

Eu disse várias vezes que vamos levar em conta as metacaixas.

@mtias Acho que a confusão em relação ao suporte de metacaixas resulta de

Eu disse várias vezes que vamos levar em conta as metacaixas.

@mtias minhas desculpas, devo ter perdido seu esclarecimento em outro lugar. Fico feliz em saber! Torne a iteração atual visualmente mais atraente e objetiva e será um grande sucesso.

Eu entendo o que você está dizendo sobre o suporte à API REST, vou assistir o tópico para atualizações.

Obrigado por esclarecer. Agora que tenho esse insight, estou a todo vapor para Gutenberg - todos os meus medos foram postos de lado.

@kevinwhoffman certo, acho que o cerne da questão é que a "funcionalidade existente" também inclui a apresentação - e, uma vez que Gutenberg muda significativamente a IU para voltar à anterior, seria necessário que o plug-in fosse desativado. Como as metacaixas se encaixam na nova IU e como as metacaixas antigas podem ser suportadas sem intervenção do desenvolvedor são as coisas que estão sendo trabalhadas. Não sei exatamente como isso vai funcionar, então não fui capaz de prometer um resultado específico. Eu também acho que isso poderia resultar em uma apresentação mais clara dos recursos das metacaixas.

@brograhamer não precisa de desculpas, é um grande tópico! Não queremos apressar nada, e este é um projeto bem grande com muitas partes móveis. Às vezes, algumas coisas podem parecer negligenciadas, mas isso não significa que não estamos planejando resolvê-las.

Atualmente, estou construindo um aplicativo da web usando ACF com 10 tipos de postagem personalizados que não usam o editor tinymce. Estou usando o recurso Título e cerca de 15 campos ACF em média para cada CPT.
Atualmente você pode declarar quais recursos (ou seja, editor, miniatura, trecho, etc) um CPT suporta.
Será possível ocultar / remover o bloco de parágrafo "Escreva sua história", bem como o ícone "Inserir bloco" da tela de edição?

@ cr101 Acho que se você retirar o "editor" de seus suportes de CPT, provavelmente deveríamos retirar o insersor de bloco e os blocos de Gutenberg, parece lógico para mim.

Por outro lado, com a v1 das metaboxes, os painéis das metaboxes podem ser expandidos da parte inferior, se mantivermos isso, devemos garantir que esteja sempre "aberto" para CPTs sem suporte de "editor". Pode não ser necessário se as metaboxes forem sempre mostradas no editor (como algumas das sugestões de design acima)

Não tenho certeza se este é o lugar certo para isso, mas e os principais metacampos personalizados? Tem havido muita conversa sobre plug-ins de terceiros, mas e sobre os principais metacampos personalizados. Eu sei que esses não são tão populares, mas posso pensar em alguns sites em que trabalhei que os usam.

Existe algum plano para integrar os principais metacampos personalizados em Gutenberg?

Olá @jawittdesigns ,

Tenho certeza que as metaboxes centrais (pelo menos a maioria delas) já foram reimplementadas em Gutenberg! Eles apresentam alguns fluxos de trabalho mais agradáveis ​​sobre como lidar com taxonomias, etc.

Nem todo mundo usa o WordPress para blogs. Muitos de nós usamos o WordPress como um CMS. No momento, estamos construindo um aplicativo da web usando a API REST do WordPress e ACF. Temos 10 tipos de post customizados e cada CPT tem 20 campos customizados e todos os CPTs estão vinculados uns aos outros por meio de relacionamentos bidirecionais usando os campos ACF Relationship e Post Object e o plugin ACF Post-2-Post.

Gutenberg não é útil para nós em sua forma atual, pois nem mesmo usamos o editor atual. Estamos usando apenas a caixa de texto Título para nossos CPTs e o resto são campos personalizados que são armazenados na tabela post_meta.

Eu acredito fortemente que o editor de Gutenberg não deve se tornar parte do núcleo em seu estado atual. Eu reconheço que o WordPress como um projeto precisa jogar um pouco para aqueles criadores de sites que não trabalham com seus próprios temas personalizados ... no entanto, o editor de Gutenberg parece ser um ataque direto àqueles de nós que usam Campos Personalizados Avançados para fazer entradas complexas de conteúdo bastante “à prova de idiotas” para proprietários de sites, dando-lhes uma maneira muito específica de inserir seu conteúdo. O editor de Gutenberg em seu 'estado atual parece ser um ataque direto àqueles de nós que usam ACF.
Com o plugin Gutenberg, o link de edição no cabeçalho envia o usuário diretamente para a interface do Gutenberg, que não mostra NENHUMA das metacaixas ACF e não possui guia de opções de tela no topo da tela para ativá-las. Sim, o usuário pode voltar para a matriz de página / postagem e escolher a opção “editor clássico” e, em seguida, ver as metacaixas, mas isso significa que uma etapa extra precisa ser realizada pelo editor do site para chegar aos campos ACF. Não é exatamente ideal, considerando que o objetivo de usar ACF em muitos casos era tornar a edição de layouts complexos mais fluida e direta para um editor não técnico.

Que problema de longa duração este tem sido!

Com a fusão de # 3345 e # 3554, o suporte da metacaixa está em um estado que consideramos _feature complete_. Observe que isso é diferente de _complete_, já que obviamente ainda há trabalho a ser feito para polir a experiência da metacaixa, particularmente em torno de estilo, manipulação de JavaScript mais complexa e determinação de regras para voltar ao editor clássico.

Obrigado a todos que participaram construtivamente desta edição. Eu entendo que tem sido um processo difícil e, às vezes, controverso. Para obter uma documentação sobre como Gutenberg lida com as metacaixas e como você (se preferir) pode marcar as metacaixas como incompatíveis com Gutenberg, consulte o manual .

Se você encontrar bugs associados a plug-ins ou metacaixas específicos, abra um novo problema para que possa ser rastreado e corrigido corretamente.

Com respeito, isso deve estar longe de ser um recurso completo.

@coffeeneed Se você quiser ser construtivo, abra um novo problema com detalhes suficientes para nossa ajuda. obrigado