Gutenberg: O impacto econômico da linha do tempo do lançamento de Gutenberg

Criado em 11 dez. 2017  ·  37Comentários  ·  Fonte: WordPress/gutenberg

ANTES DE PUBLICAR SEU PROBLEMA: - Esses comentários não aparecerão quando você enviar o problema. - Tente adicionar o máximo de detalhes possível. Seja específico! - Por favor, adicione a versão de Gutenberg que você está usando na descrição. - Se você estiver solicitando um novo recurso, explique por que deseja que ele seja adicionado. - Pesquise neste repositório o problema e se ele foi corrigido ou já relatado. - Certifique-se de usar o código mais recente antes de registrar bugs. - Desative todos os plug-ins para garantir que não seja um problema de conflito de plug-ins.

Visão geral do problema

Como um profissional de marketing voltado para os negócios, minha percepção de Gutenberg não é sobre sua beleza ou facilidade de uso. Em vez disso, estou muito preocupado (e desde junho de 2017) com o cronograma de Gutenberg, a rapidez com que está sendo iterado e o impacto econômico que terá e, francamente, o desgaste.

Isenção de responsabilidade

Sou a equipe de marketing CoRep da Make.WordPress, sou proprietário de uma empresa e trabalhei anteriormente para uma empresa de desenvolvimento de plug-ins e agência de publicidade muito bem-sucedida, que dependem do WordPress para seu modelo de negócios. Embora eu vá escrever sobre isso em meu próprio blog, pensei em colocar meu dinheiro onde está minha boca e ser uma voz oficial, em vez de uma voz nos bastidores.

Comentei no nº 3902, mas a preocupação econômica é separada e merece seu próprio problema.

https://github.com/WordPress/gutenberg/issues/3902#issuecomment -350588051

Compatibilidade com versões anteriores

É meu entendimento que o WordPress, como um projeto e comunidade, está comprometido com a compatibilidade com versões anteriores. Para ser justo, já ouvi essa discussão principalmente ao considerar a compatibilidade de back-end com PHP. E eu entendo as frustrações com os desenvolvedores que desejam usar a funcionalidade PHP7 +.

No entanto, os desenvolvedores de PHP são capazes de embrulhar o código depreciado. A nova experiência Gutenberg (editor) sobrecarrega em grande escala os desenvolvedores de plugins e temas em um curto período de quatro meses.

Análise SWOT

Para auxiliar na estratégia de marketing tanto interna (Make Teams, WordPress Developers) quanto externa (clientes, usuários finais, agências), uma análise SWOT deve ser feita por nós.

Aqui está um exemplo:

Pontos fortes: Facilidade de uso, tecnologia moderna, possibilidades com RV, etc.
Fraquezas: acessibilidade, problemas de SEO, compatibilidade
Oportunidades: novos desenvolvedores, novos clientes, tecnologia moderna, melhor interface do usuário
Ameaças: atrito (perda de WP para Wix, et al), impacto econômico, perda de voluntários

Atrito

O desgaste é um risco real. Compartilhei o artigo do Morten no LinkedIn e um comerciante afiliado começou a ter uma conversa que acho que deveríamos ouvir. 29% da Internet usa WordPress. A implementação precisa gerenciar as expectativas, educar e dar às pessoas tempo para aprender.

Não somos a Apple. Não ditamos e esperamos que as pessoas se adaptem. Acreditamos na democratização da publicação. Esta é a chave para nossa cultura como software.

https://twitter.com/JessicaGottlieb/status/940033708299448321

https://twitter.com/JessicaGottlieb/status/940040642855518208

https://twitter.com/JessicaGottlieb/status/940104882425442307

Impacto econômico de um cronograma apertado

As empresas funcionam com base nos orçamentos do ano fiscal, não nos cronogramas para lançamentos de software. É fácil para nós, internamente, ficarmos entusiasmados com recursos incríveis e grandes possibilidades apenas para esquecer os proprietários de pequenas empresas, os desenvolvedores de plug-ins e temas e os blogueiros.

Os desenvolvedores de plug-ins e temas, por exemplo, precisam mudar os orçamentos de marketing (como isso afetará os patrocínios do WordCamp, por exemplo) para o desenvolvimento e suporte de produtos. Eles precisam treinar a si próprios e a seus desenvolvedores para aprender profundamente JavaScript, React e Vue (possivelmente) para criar metaboxes compatíveis. As empresas de desenvolvimento de plug-ins também precisam decidir se darão suporte a seus clientes legados. Caso decidam apoiar ambos, a dívida técnica agora se torna de natureza financeira, pois eles gastam mais horas (tempo) e / ou orçamento (dinheiro) mantendo os clientes atuais. Caso não o façam, correm o risco de perder clientes atuais por atrito.

As agências que usam o WordPress geralmente têm contratos de um ano. O site é construído e usado para publicar conteúdo regularmente para geração de leads, SEO e desenvolvimento de negócios. A agência terá que garantir que os sites de seus clientes permaneçam em 4.9.x ou sejam totalmente compatíveis com Gutenberg. Muitas agências criam temas personalizados em estruturas ou com ACF. Esses temas precisarão ser trabalhados (isso se traduz em mudança no orçamento). Pessoalmente, recomendei muitos dos meus clientes e amigos da minha agência para se prepararem para outubro passado. Muitos aumentaram seu orçamento para serem preparados.

As pequenas empresas costumam recorrer ao WordPress pelos motivos que promovemos: SEO técnico, facilidade de publicação, propriedade de seus próprios dados. Convencê-los a ficar, quando outra opção pode ser mais barata (WIX, Squarespace, até mesmo Dot Com), pode se tornar um desafio. As empresas não tomam decisões com base na lealdade da comunidade; eles tomam decisões com base nas finanças.

Solução possível

Eu adoraria ver a versão que será enviada com o conjunto 5.0 mais cedo ou mais tarde. Isso permitirá que educadores WordPress, agências, empresas, o Make Team e oficinas de desenvolvimento preparem o público em geral para o lançamento com materiais de marketing, documentação e, é claro, código compatível.

Continue iterando. Deve iterar. Mas a economia que depende do WordPress precisa de tempo para aprender e aceitar.

Obrigado pelo seu tempo.

Comentários muito úteis

Eu queria dar uma pequena perspectiva sobre a linha do tempo conforme planejado atualmente. Digo planejado porque à medida que avançamos para o 5.0 a comunidade, o líder do 5.0 e a equipe principal trabalharão juntos para descobrir o caminho para a fusão. Observe que ele não foi mesclado e pelo menos 11 versões são esperadas - 1 acaba de ser lançada.

É importante notar que todos os lançamentos têm uma fase de candidato a lançamento, o 5.0 não será exceção. Também vale a pena dizer é algo que várias pessoas têm, haverá por muito tempo a opção do plugin do editor clássico e até mesmo de ativá-lo pela rede. Esse plugin não vai a lugar nenhum no lançamento do 5.0 e provavelmente vai ficar por um bom tempo, o editor clássico em si ainda está sendo mantido.

Campos personalizados não foram perdidos, há um plugin incrível sendo trabalhado e um post aqui: https://riad.blog/2017/12/11/with-gutenberg-what-happens-to-my-custom- Campos/.

As Metaboxes têm alguns caminhos potenciais para atualizar, no momento está funcionando o melhor deles. Como o sistema será padronizado e qual será a experiência do usuário em relação a isso. Nada está definido em pedra, tudo está sendo trabalhado para a melhor experiência do usuário. Os usuários são todos os tipos de pessoas - aqueles que realmente escrevem, criadores de temas, fabricantes de plug-ins e muito mais.

Eu sei que a mudança é difícil e assustadora, todos nós a sentimos. Eu sim, você precisa e é ainda pior quando não conseguimos entender a mudança. Gostaria de apontar as pessoas para wordpress.org/gutenberg como um ponto de partida para entender o projeto. Eu digo ponto de partida a partir daí você pode ir para o manual: wordpress.org/gutenberg/handbook. Aqui, por exemplo, está a seção de compatibilidade que considero importante compartilhar:

O projeto Gutenberg está lidando ativamente com questões de compatibilidade. Os blocos são o novo mecanismo de fato para construir recursos de conteúdo, e recomendamos que os desenvolvedores migrem todos os recursos que eles oferecem e que são bem encapsulados por blocos. No entanto, o suporte para a funcionalidade WordPress existente permanecerá e haverá caminhos de transição para códigos de acesso, metacaixas e tipos de postagem personalizados:

Shortcodes.

  • Continuará trabalhando sem mudanças.
  • Existe um novo “bloco de shortcode” para ajudar a inseri-los.
  • Existe um mecanismo planejado para visualizá-los no lugar.

Meta-caixas.

  • Alguns continuarão a trabalhar sem alterações na nova IU.
  • Alguns precisarão de atualizações (especialmente aqueles que dependem do DOM para operar). *
  • Vários podem ser convertidos em blocos nativos (particularmente aqueles que são renderizados no front-end).
  • Alguns podem fazer a transição para novos pontos de extensão nativos de Gutenberg fora da área de conteúdo.
  • Haverá um mecanismo para metacaixas conflitantes para carregar o editor clássico em vez de um aviso.

Tipos de postagem personalizados.

  • São apoiados por Gutenberg.
  • Requer declaração REST API (show_in_rest).
  • Pode optar por não declarar o suporte do “editor”.
  • Será capaz de declarar blocos suportados e padrão.
  • Certas metacaixas que dependem da estrutura específica da tela de edição atual não têm garantia de funcionamento no Gutenberg e podem precisar de alterações antes de serem carregadas corretamente.

Eu encorajaria todos vocês a considerarem o que eu disse qual é o caminho certo para sua configuração específica. Cada pessoa pode querer ou precisar adotar uma abordagem diferente com Gutenberg. O importante é que ninguém no dia 1 espera que você tenha feito blocos. Seria incrível se as pessoas tivessem, mas a realidade é que haverá opções para você atualizar lentamente. Muita documentação, educação e discussão precisam acontecer. Isso é ótimo porque toda a comunidade está envolvida e pode fazer isso.

Por último, por favor, não tenha medo. WordPress é uma comunidade e, embora tópicos como esse possam parecer assustadores, Gutenberg não é e a última coisa que todos os envolvidos no projeto querem é que você se sinta assustado. Aqueles que fazem Gutenberg se importar, aqueles na comunidade se preocupam. WordPress é um projeto incrível que realmente respeita as coisas incríveis que as pessoas estão fazendo. Eu o encorajo a descobrir o caminho que será melhor para você e então explorar, se divertir e se empolgar com os blocos. Tenha seu plano e, em seguida, veja como você pode construir a partir daí.

Se você tiver alguma dúvida sobre Gutenberg, em qualquer contexto, o canal # core-editor em chat.wordpress.org está sempre disponível para você. Você também pode assistir naquele canal o trabalho que está acontecendo e ver os encontros semanais às 18:00 UTC de quarta-feira e geralmente hangout. Vamos todos trabalhar juntos no caminho a seguir.

Todos 37 comentários

Ótimo post Bridget, obrigado por escrever isso. Isso ecoa minhas preocupações.

Eu trabalhava para uma empresa que, na época em que saí, tinha mais de 400 sites WordPress com temas personalizados (criados com uma estrutura interna) e estava em um processo de anos de migração de ~ 200 mais de um CMS antigo em além de novas construções. Embora empresas como essa sem dúvida estejam monitorando Gutenberg de perto e se preparando, imagino que uma boa parte do tempo dos desenvolvedores será gasta instalando algo para desativá-lo, e não tentando fazer com que mais de 400 sites funcionem com Gutenberg.

Eu mesmo cuido de 30 sites e é isso que farei, e então examinarei cada site posteriormente e verei quais podem ser facilmente atualizados e, em seguida, tentarei descobrir o que fazer com o resto.

Dependendo da complexidade dos sites, os desenvolvedores simplesmente não podem se dar ao luxo de gastar muito tempo nisso para sites existentes, porque não podemos cobrar por isso, a menos que um cliente peça especificamente que seu tema seja atualizado para se adequar a Gutenberg. Construímos nossas estruturas de preços de manutenção em torno da compatibilidade com versões anteriores que sempre foi um ponto forte do WordPress, embora isso me lembre das longas migrações do Drupal 6 para 7 que testemunhei colegas trabalhando em uma função anterior - a diferença é que o Drupal sempre foi assim portanto, os contratos e as estruturas de preços refletem isso.

Eu tenho uma cláusula em meus contratos que se um site deixar de ser compatível com a versão mais recente do WordPress ou um plugin, ele continuará a ser executado na última versão compatível até que uma solução seja encontrada. Nunca pensei que precisaria usar essa cláusula para o WordPress em si.

Por outro lado, há usuários que criaram seu próprio site DIY usando temas gratuitos ou feitos comercialmente com base em metaboxes e códigos de acesso cujos sites irão quebrar repentinamente em algum ponto se Gutenberg não for claramente opcional. Certamente isso será terrível para a retenção.

Eu imagino que uma boa parte do tempo dos desenvolvedores será gasta na instalação de algo para desativá-lo

Exatamente meus pensamentos.

Dei uma olhada no plugin do Editor Clássico, com o qual o usuário ainda precisa marcar uma caixa para remover o Gutenberg completamente. Então, eu iria bifurcar isso e instalá-lo nos sites dos meus clientes ou simplesmente definir a versão para 499.x antes do lançamento do 5.0.

E então posso, no meu próprio tempo, migrar meus clientes para Grav, Kirby ou qualquer outra coisa que eu queira, porque todos nós sabemos que a maioria dos clientes realmente não se importa com o CMS que seus sites estão executando!

@doubleedesign É bom que você tenha essa cláusula. Eu começaria a educar sua base de clientes mais cedo ou mais tarde, para que você possa acostumá-los com a ideia.

@senlin Piet,

Você está dizendo que pode sair do WordPress?

@gidgey Bridget,

Estou seriamente olhando para outros CMSs e já criei alguns sites com Grav CMS.

Então, sim, você pode realmente dizer que há mais de 50% de chance de eu abandonar o WP quando Gutenberg cair no WP 5.0.

E algo mais a considerar:

Se você está iniciando um projeto de médio porte agora, que definitivamente construirá com o ACF se escolher o WP, você realmente escolheria o WP?

Eu sei que não. Prefiro ter a curva de aprendizado, do que dizer ao cliente em 4 meses que o site que desenvolvi não pode mais ser editado ou atualizado.

É disso que tenho medo - em grande escala.

Agradeço sua honestidade e não culpo você de forma alguma. É um marketing
questão com certeza.

Na segunda-feira, 11 de dezembro de 2017 às 14h41, Piet Bos [email protected] escreveu:

@gidgey https://github.com/gidgey Bridget,

Estou seriamente olhando para outros CMSs e já reuni um
alguns sites com Grav CMS.

Então, sim, você pode realmente dizer que há mais de 50% de chance de que eu
vai cair WP quando Gutenberg cair no WP 5.0.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-350882640 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AV3JZs__wiuV2FslRNQMRkxvCoRKWnEJks5s_a-kgaJpZM4Q93ul
.

-
Cell 949 370 4059
www.bridgetwillard.com

É exatamente sobre isso que tenho conversado com meus amigos e clientes.

Suspirar. Obrigado pelo seu feedback, Piet.

Na segunda-feira, 11 de dezembro de 2017 às 15h01, Piet Bos [email protected] escreveu:

E algo mais a considerar:

Se você está iniciando um projeto de médio porte agora, com certeza
construído com ACF se você escolhesse o WP, você realmente escolheria o WP?

Eu sei que não. Eu prefiro ter a curva de aprendizado, do que dizer o
cliente em 4 meses que o site que desenvolvi não pode mais ser editado ou
não pode mais ser atualizado.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-350887165 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AV3JZrxdz6HgF-9vGrhvZPC5Bi7prd2Nks5s_bQ7gaJpZM4Q93ul
.

-
Cell 949 370 4059
www.bridgetwillard.com

Se você está iniciando um projeto de médio porte agora, que definitivamente construirá com o ACF se escolher o WP, você escolheria o WP?

Alguma história de fundo: eu comecei minha carreira como um desenvolvedor Júnior de Drupal e aprendi WP paralelamente para meus próprios clientes. Meu próximo trabalho foi 100% WordPress, então, embora eu quisesse ficar nos dois ecossistemas, uma longa história, resumindo, na realidade, fazia mais sentido ficar principalmente com o WP.

A primeira coisa que me atraiu para o ACF foi basicamente que ele trouxe algo que eu amava sobre o Drupal - a capacidade de especificar campos para tipos de conteúdo facilmente no back-end - para o WP. Existem tantos usos para isso. É fácil para os clientes preencherem um formulário com seu conteúdo sem se preocupar com formatação e layout, e então eu controlo a exibição com o modelo. Esta é a base de como eu construo sites.

Então, se eu não posso mais construir assim e Gutenberg não funciona para meus clientes (já posso pensar em alguns que odiariam porque não querem pensar em formatação ou layout, esse é o meu trabalho), então não, Eu não escolheria WP em alguns casos. Eu provavelmente voltaria para o Drupal. Não para todos, e provavelmente nem mesmo para a maioria - eu ainda estarei trabalhando com o WP - mas definitivamente para alguns.

Obrigado por nos informar, Leesa.

Minha suposição (e esperança) é que o plugin ACF será convertido. Mas está ligado
para fazer seus blocos, não no WordPress Core. Eu imagino que eles são
também esperando pela versão "navio" de Gutenberg antes de investir muitos
recursos (tempo e dinheiro). Isso é o que eu faria.

Na segunda-feira, 11 de dezembro de 2017 às 15:10, Leesa Ward [email protected]
escreveu:

Se você está iniciando um projeto de médio porte agora, com certeza
construído com ACF se você escolhesse o WP, você realmente escolheria o WP?

Alguma história de fundo: eu comecei minha carreira como um desenvolvedor Júnior de Drupal e aprendi WP
ao lado para meus próprios clientes. Meu próximo trabalho foi 100% WordPress, então enquanto eu
queria ficar em ambos os ecossistemas, uma longa história curta, na realidade, fez mais
sentido para ficar principalmente com WP.

A primeira coisa que me atraiu na ACF foi basicamente que trouxe
algo que adorei no Drupal - a capacidade de especificar campos para conteúdo
digita facilmente no backend - em WP. Existem tantos usos para
isto. É fácil para os clientes preencherem um formulário com seu conteúdo, sem
tendo que me preocupar com a formatação e layout, e então eu controlo a exibição
com o modelo. Esta é a base de como eu construo sites.

Então, se eu não consigo mais construir assim e Gutenberg não funciona para o meu
clientes (já posso pensar em alguns que odiariam porque não
quero pensar sobre formatação ou layout, esse é o meu trabalho), então não, eu
não escolher WP em alguns casos. Eu provavelmente voltaria para o Drupal. Não para
todos, e provavelmente nem mesmo para a maioria - ainda estarei trabalhando com WP

  • mas definitivamente para alguns.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-350889174 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AV3JZmN-TRB-9rQgHSqACUhcz9CqdOl-ks5s_bZtgaJpZM4Q93ul
.

-
Cell 949 370 4059
www.bridgetwillard.com

Minha suposição (e esperança) é que o plugin ACF será convertido.

Sim, com certeza, acredito que sim, e é por isso que não estou imediatamente voltando às pressas para o Drupal para tudo;) Não muito diferente do WooCommerce, ele se tornou a espinha dorsal do ecossistema.

Mas, ainda é uma preocupação, pois o desenvolvedor precisa de tempo para tornar o ACF compatível. O que significa que aqueles que usam intensamente o plugin não podem converter sites existentes até que o façam. O que poderia tornar a já curta linha do tempo ainda mais curta.

Concordo totalmente com a sugestão de que Gutenberg seja opcional por pelo menos um ano. Isso dá aos desenvolvedores de plug-ins uma oportunidade de fazer um trabalho completo para tornar seus plug-ins compatíveis, além de dar aos desenvolvedores tempo para integrar essas mudanças e educar os clientes.

Além disso, deve haver uma opção (por exemplo, através do plugin do Editor Clássico) para manter o Gutenberg desligado e manter o editor clássico por ainda mais tempo depois disso, para sites que simplesmente não serão convertidos devido a restrições de custo / tempo . A vida útil de um site de pequeno a médio porte significa que, em alguns anos, o cliente pode querer um redesenho de qualquer maneira e, então, obterá o Gutenberg quando chegar a hora.

@doubleedesign Leesa mostra um grande ponto aqui:

eles [clientes] não querem pensar em formatação ou layout, esse é o meu trabalho

E isso também é uma das coisas que me deixa zangado / desapontado! O fato de haver construtores de páginas é uma coisa. Claro que existe mercado para isso, mas não é o meu mercado nem o dos meus clientes.
Então, por que todos agora são empurrados para o WP se tornando um construtor de páginas? E usar a frase _democratizar a publicação_ para isso NÃO significa que está certo.

Quando eu construo sites para clientes, eles são altamente personalizados e fazem exatamente de acordo com os desejos do cliente. Meus clientes não cometem erros quando se trata de edição de conteúdo, porque (com o ACF) eu crio uma experiência de back-end que não deixa espaço para erros.

Eu estava assistindo a apresentação de @ mor10 onde ele mencionou que os desenvolvedores de temas podem conduzir os usuários através do conteúdo.

Já faço isso há anos !!! Sem Gutenberg!

Entrei no WP em 2005 e tenho usado-o com muito prazer desde então. Desenvolvi vários plug-ins, alguns mais populares do que outros, e desenvolvi uma especialidade que me manteve fora das ruas, por assim dizer.

Como costumo dizer aos meus clientes, o mundo do site está em constante movimento e acho que o tempo que passei intensamente com o WP está chegando ao fim e novas fronteiras a serem descobertas estão no horizonte para mim.

Eu só não gosto da maneira como está terminando, mas, novamente, às vezes um rompimento é mais fácil com um empurrão do que deixá-lo morrer lentamente ...

O fato de haver construtores de páginas é uma coisa. Claro que existe mercado para isso, mas não é o meu mercado nem o dos meus clientes ...

Meus clientes não cometem erros quando se trata de edição de conteúdo, porque (com o ACF) eu crio uma experiência de back-end que não deixa espaço para erros.

@senlin , é como se você estivesse lendo minha mente! ;)

O fato de haver construtores de páginas é uma coisa. Claro que existe mercado para isso, mas não é o meu mercado nem o dos meus clientes ...

Meus clientes não cometem erros quando se trata de edição de conteúdo, porque (com o ACF) eu crio uma experiência de back-end que não deixa espaço para erros.

@senlin , @doubleedesign , exatamente o mesmo aqui.

Gutenberg é certamente um projeto interessante e ambicioso, mas não tem utilidade para 99% dos meus clientes.

Uso o WordPress há 10 anos e estou envolvido com a comunidade francesa desde o início, mas desta vez, é a primeira versão que me assustou por todos os motivos que você mencionou ...

Eu queria dar uma pequena perspectiva sobre a linha do tempo conforme planejado atualmente. Digo planejado porque à medida que avançamos para o 5.0 a comunidade, o líder do 5.0 e a equipe principal trabalharão juntos para descobrir o caminho para a fusão. Observe que ele não foi mesclado e pelo menos 11 versões são esperadas - 1 acaba de ser lançada.

É importante notar que todos os lançamentos têm uma fase de candidato a lançamento, o 5.0 não será exceção. Também vale a pena dizer é algo que várias pessoas têm, haverá por muito tempo a opção do plugin do editor clássico e até mesmo de ativá-lo pela rede. Esse plugin não vai a lugar nenhum no lançamento do 5.0 e provavelmente vai ficar por um bom tempo, o editor clássico em si ainda está sendo mantido.

Campos personalizados não foram perdidos, há um plugin incrível sendo trabalhado e um post aqui: https://riad.blog/2017/12/11/with-gutenberg-what-happens-to-my-custom- Campos/.

As Metaboxes têm alguns caminhos potenciais para atualizar, no momento está funcionando o melhor deles. Como o sistema será padronizado e qual será a experiência do usuário em relação a isso. Nada está definido em pedra, tudo está sendo trabalhado para a melhor experiência do usuário. Os usuários são todos os tipos de pessoas - aqueles que realmente escrevem, criadores de temas, fabricantes de plug-ins e muito mais.

Eu sei que a mudança é difícil e assustadora, todos nós a sentimos. Eu sim, você precisa e é ainda pior quando não conseguimos entender a mudança. Gostaria de apontar as pessoas para wordpress.org/gutenberg como um ponto de partida para entender o projeto. Eu digo ponto de partida a partir daí você pode ir para o manual: wordpress.org/gutenberg/handbook. Aqui, por exemplo, está a seção de compatibilidade que considero importante compartilhar:

O projeto Gutenberg está lidando ativamente com questões de compatibilidade. Os blocos são o novo mecanismo de fato para construir recursos de conteúdo, e recomendamos que os desenvolvedores migrem todos os recursos que eles oferecem e que são bem encapsulados por blocos. No entanto, o suporte para a funcionalidade WordPress existente permanecerá e haverá caminhos de transição para códigos de acesso, metacaixas e tipos de postagem personalizados:

Shortcodes.

  • Continuará trabalhando sem mudanças.
  • Existe um novo “bloco de shortcode” para ajudar a inseri-los.
  • Existe um mecanismo planejado para visualizá-los no lugar.

Meta-caixas.

  • Alguns continuarão a trabalhar sem alterações na nova IU.
  • Alguns precisarão de atualizações (especialmente aqueles que dependem do DOM para operar). *
  • Vários podem ser convertidos em blocos nativos (particularmente aqueles que são renderizados no front-end).
  • Alguns podem fazer a transição para novos pontos de extensão nativos de Gutenberg fora da área de conteúdo.
  • Haverá um mecanismo para metacaixas conflitantes para carregar o editor clássico em vez de um aviso.

Tipos de postagem personalizados.

  • São apoiados por Gutenberg.
  • Requer declaração REST API (show_in_rest).
  • Pode optar por não declarar o suporte do “editor”.
  • Será capaz de declarar blocos suportados e padrão.
  • Certas metacaixas que dependem da estrutura específica da tela de edição atual não têm garantia de funcionamento no Gutenberg e podem precisar de alterações antes de serem carregadas corretamente.

Eu encorajaria todos vocês a considerarem o que eu disse qual é o caminho certo para sua configuração específica. Cada pessoa pode querer ou precisar adotar uma abordagem diferente com Gutenberg. O importante é que ninguém no dia 1 espera que você tenha feito blocos. Seria incrível se as pessoas tivessem, mas a realidade é que haverá opções para você atualizar lentamente. Muita documentação, educação e discussão precisam acontecer. Isso é ótimo porque toda a comunidade está envolvida e pode fazer isso.

Por último, por favor, não tenha medo. WordPress é uma comunidade e, embora tópicos como esse possam parecer assustadores, Gutenberg não é e a última coisa que todos os envolvidos no projeto querem é que você se sinta assustado. Aqueles que fazem Gutenberg se importar, aqueles na comunidade se preocupam. WordPress é um projeto incrível que realmente respeita as coisas incríveis que as pessoas estão fazendo. Eu o encorajo a descobrir o caminho que será melhor para você e então explorar, se divertir e se empolgar com os blocos. Tenha seu plano e, em seguida, veja como você pode construir a partir daí.

Se você tiver alguma dúvida sobre Gutenberg, em qualquer contexto, o canal # core-editor em chat.wordpress.org está sempre disponível para você. Você também pode assistir naquele canal o trabalho que está acontecendo e ver os encontros semanais às 18:00 UTC de quarta-feira e geralmente hangout. Vamos todos trabalhar juntos no caminho a seguir.

@karmatosed Tammie,

Metaboxes têm alguns caminhos potenciais para atualização

A coisa é antes de GB minhas metaboxes estão bem e elegantes. Eles podem estar ativos em sites que não gerencio mais. E os clientes daqueles sites que desenvolvi há alguns anos? De repente, o conteúdo do site não pode mais ser editado.

Eu sei que a mudança é difícil e assustadora, todos nós a sentimos.

Este tipo de observações são desnecessárias, pois parecem realmente condescendentes e paternalistas! Indicar às pessoas a leitura de pilhas de documentação que nem mesmo foram concluídas e ainda é um trabalho em andamento é ridículo na minha opinião.
uma. Eu não tenho tempo para isso e b. esta discussão não é sobre a compreensão do GB, mas sobre o impacto econômico da linha do tempo do lançamento de Gutenberg

Quanto à lista do que precisa ser feito em relação aos shortcodes, metaboxes e CPTs, mostra que é ainda pior do que eu pensava.

Os CPTs não funcionarão mais sem declarar show_in_rest ?!?!?! Agora devo voltar aos sites dos clientes e refazer de 3 a 5 anos de trabalho?

Esse, Tammie, é exatamente o impacto econômico que @gidgey (Bridget) trouxe com este post! Que você pareça não entender isso é, na melhor das hipóteses, assustador, especialmente porque você é um evangelista da GB!

@karmatosed Obrigado por sua resposta completa.

Haverá por muito tempo a opção do plugin do editor clássico e até de sua ativação via rede. Esse plugin não vai a lugar nenhum no lançamento do 5.0 e provavelmente vai ficar por um bom tempo, o editor clássico em si ainda está sendo mantido.

Para sites que usarão o editor clássico em um futuro previsível, ele precisa ser instalado antes do lançamento do 5.0? O ideal para mim nesses casos é que o Gutenberg nunca esteja ligado, por assim dizer - não que eu faça login apressadamente em todos os meus sites para desligá-lo.

Eu sei que a mudança é difícil e assustadora, todos nós a sentimos.

Este tópico não é tanto uma voz de Stewie Griffin "Algo está errado com a casa! Eu não gosto de mudanças!" coisa. É sobre a velocidade disso. Você diz que não espera que ninguém construa blocos quando o 5.0 for lançado ... mas sem intervenção, os back-ends do site terão essa interface, novos sites em desenvolvimento precisarão ser alterados ou uma atualização planejada; novos sites sendo planejados / com escopo definido terão um monte de pontos de interrogação sobre seus planos.

Além disso, clientes com sites existentes, mas sem planos de manutenção ou desenvolvedores ativos, podem ficar confusos e, se o site quebrar, ficarem irritados. Os departamentos de TI receberão solicitações de suporte para algo sobre o qual não sabem nada, e os desenvolvedores atenderão a ligações de clientes anteriores irados.

Tudo isso vai ocupar uma quantidade significativa do tempo de todos. Sei que Gutenberg está em beta há algum tempo, mas não é o mesmo que ser capaz de usá-lo em sites reais com clientes reais para confirmar quais são os verdadeiros pontos problemáticos para nossos sites e para nossos clientes.

haverá opções para você atualizar lentamente

Uma transição lenta precisa ser o padrão e a expectativa. Isso provavelmente já foi sugerido, mas certamente pode haver um prompt "Escolha seu editor" ao atualizar para o 5.0. Isso seria particularmente útil para clientes sem um desenvolvedor / mantenedor ativo que está preocupado com as mudanças.

@senlin

Isso, Tammie, é * exatamente o impacto econômico que @gidgey (Bridget) trouxe com este post! Que você pareça não entender isso é, na melhor das hipóteses, assustador, especialmente porque você é um evangelista da GB!

A resposta padrão às preocupações dos desenvolvedores parece ser "Mas Gutenberg é incrível !!!" No momento, não me importa o quão incrível seja, vou descobrir isso no devido tempo, através do uso adequado dele após o lançamento. No momento, me preocupo com o que vai acontecer e o que preciso fazer a respeito dos mais de 30 sites que mantenho no momento e dos poucos que tenho em desenvolvimento.

Os usuários são todos os tipos de pessoas - aqueles que realmente escrevem, criadores de temas, fabricantes de plug-ins e muito mais.

@karmatosed Isso também é um pouco condescendente e não está ajudando o quão alienados alguns desenvolvedores estão se sentindo atualmente. Sabemos que não somos os únicos usuários. Na verdade, houve comentários neste mesmo tópico expressando nossas preocupações sobre o impacto sobre a escrita de alguns desses usuários, porque eles são nossos clientes. Não estamos fazendo apenas como queremos codificar (embora isso seja um elemento, mas não é relevante para este tópico).

@senlin vamos passar das acusações de intenção, todos nos importamos com o que acontece aqui e o respeito é importante.

Compartilhei o que fiz com a intenção de informar, não com a intenção de patrocinar. É importante notar que vejo o valor desta discussão, eu me engajei e estou engajado aqui. Eu também vejo o ponto da discussão. O que eu senti foi que compartilhar os recursos que temos agora era importante para traçar um caminho.

Vamos prosseguir a partir deste ponto e mergulhar em uma resposta ao seu comentário:

E os clientes daqueles sites que desenvolvi há alguns anos?

É por isso que adicionei as citações da documentação, para mostrar os possíveis substitutos que estão sendo trabalhados. Dependerá da metabox, mas esse fallback é potencialmente o que acontece.

Algo que vale a pena observar para aqueles que estão trabalhando nisso aprender: compartilhar os exemplos em que você está pensando é importante. Isso ajuda na conversa bidirecional.

@doubleedesign , obrigado por sua resposta também.

Para sites que usarão o editor clássico em um futuro previsível, ele precisa ser instalado antes do lançamento do 5.0?

O plugin do editor clássico precisa ser ativado hoje. Isso significaria tê-lo ativo no dia 5.0.

Eu encorajaria totalmente, sempre que possível, as pessoas a experimentarem o Gutenberg hoje nos sites. Ao tentar, bugs, problemas e feedback podem ser enviados para aqueles que estão trabalhando nisso. Isso é crucial para obter essa discussão bidirecional.

_Isso dependerá_ da metabox, mas esse fallback _potencialmente_ é o que acontece.

。。。

Dependerá da metabox, mas esse fallback é potencialmente o que acontece.

Admito que não estive envolvido em um projeto de software desse tamanho, então não sei se isso é normal, mas estou nervoso com todas as partes que ainda parecem ser incertas tão perto do lançamento.

@doubleedesign só para deixar claro, eu não estava dispensando desenvolvedores aqui:

Sabemos que não somos os únicos usuários. Na verdade, houve comentários neste mesmo tópico expressando nossas preocupações sobre o impacto sobre a escrita de alguns desses usuários, porque eles são nossos clientes.

Eu estava dizendo que é sobre a experiência de todos, desenvolvedores, designers, usuários. Eu queria ter certeza nesse ponto, pois sinto que foi mal interpretado. Eu estava dizendo que tudo importa e não descartando a experiência do desenvolvedor.

Para resumir o que eu estava dizendo:

  • Quando o 5.0 for lançado, as coisas não quebrarão. Existem opções para evitar isso. Mais opções podem ser adicionadas.
  • Para garantir que as coisas não quebrem, é necessário feedback. Testar, dizer à equipe onde estão os problemas e quais configurações estão falhando, é essencial. Isso não quer dizer que aqueles que estão trabalhando nisso não estão testando, é apenas cada caso de estresse que existe, ninguém sabe. A comunicação bidirecional é a chave.
  • O modo como o Gutenberg é enviado é um detalhe para o 5.0. A equipe agora está se concentrando no produto, recebendo feedback, respondendo e iterando. Isso não descarta nada, mas é aí que entra a liderança do 5.0, a comunidade; descobrir como o Gutenberg é enviado.

@karmatosed

Quando o 5.0 for lançado, as coisas não quebrarão.

Isso é uma garantia ou apenas um resumo do que você estava dizendo, sem qualquer valor atribuído a isso?

@gidgey Acho que também uma solução potencial a https://gettingreadyforgutenberg.com/

Sei que isso principalmente se refere a um sintoma potencial, ao invés de uma preocupação abrangente que você tem. Do ponto de vista puramente filosófico, me pergunto se estamos subestimando a resiliência do tipo de pessoa que essa comunidade atrai.

Não posso prever o futuro (embora esteja no topo da minha lista de desejos por superpotências), mas você está certo de que haverá um grande impacto econômico. Acho que temos que entrar nessa mudança com os olhos abertos e obrigado por verbalizar suas preocupações abertamente aqui para discussão. São conversas como essa que nos ajudam a nomear nossos medos para que possamos enfrentá-los da melhor maneira possível. 🤗

Exatamente, Josepha. Minha intenção não é fomentar o medo, mas consciência.

Obrigado Piet e Tammie por seus comentários também.

Esta foi uma grande e necessária discussão.

Na terça - feira, 12 de dezembro de 2017 às 8:16 AM, josephahaden
escreveu:

@gidgey https://github.com/gidgey Acho também uma solução potencial em
o midterm é este site de crowdsourcing para obter e fornecer ajuda
transição de produtos para Gutenberg: https://gettingreadyforgutenberg.com/

Eu percebo que trata principalmente de um sintoma potencial, ao invés de um
preocupação abrangente que você tem. De um ponto de vista puramente filosófico, eu
me pergunto se estamos subestimando a resiliência do tipo de pessoa que esta
comunidade atrai.

Não posso prever o futuro (embora esteja no topo da minha lista de desejos para super
poderes), mas você está certo de que haverá um grande impacto econômico. eu penso
temos que entrar nessa mudança com nossos olhos abertos, e obrigado por
verbalizando suas preocupações abertamente aqui para discussão. São conversas
assim, que nos ajudam a nomear nossos medos para que possamos enfrentá-los da melhor maneira
posso. 🤗

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-351101104 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AV3JZpL52P_idTCVbWhTT9qAnAnHjgfyks5s_qbegaJpZM4Q93ul
.

-
Cell 949 370 4059
www.bridgetwillard.com

Os CPTs não funcionarão mais sem declarar show_in_rest ?!?!?! Agora devo voltar aos sites dos clientes e refazer de 3 a 5 anos de trabalho?

Meu entendimento é que é o contrário; Os CPTs que não declaram explicitamente show_in_rest não usarão Gutenberg por padrão. Gutenberg usa a API REST para obter e salvar dados de postagem, portanto, se o CPT não suportar a API REST, Gutenberg não poderá trabalhar com ela.

Portanto, cerca de 95% dos CPTs usarão o editor Classic por padrão, sem a necessidade de alterações.

https://github.com/WordPress/gutenberg/blob/9864a6092a965d2985307ed2456f83148a1dee78/lib/register.php#L303 -L338

Os CPTs que não declaram explicitamente show_in_rest não usarão Gutenberg por padrão.

Na verdade, este é um "bug" na API porque qualquer CPT com "show_ui" => true deve poder ser editado em Gutenberg. E espero que isso seja corrigido antes da fusão.

@iandunn Esse é um grande problema para o progresso futuro de Gutenberg, já que Gutenberg não deve ser meramente um substituto do editor, mas uma maneira totalmente nova de gerenciar visualizações. Se os CPTs bloqueiam Gutenberg, Gutenberg não pode ir além do editor.

Concordo plenamente aqui em que o problema para mim não é a mudança. Se não mudássemos ou avançássemos, ainda estaríamos presos ao WordPress v1, que na época era incrível, mas está longe de ser tão bom quanto agora.

A preocupação é o momento do lançamento. Estamos sendo informados de que Gutenberg será lançado em algum momento no início de 2018, o que é muito preocupante e, na minha opinião, muito cedo.

A maioria dos projetos em WordPress (pensando na API REST) ​​eram plug-ins por meses ou até anos antes de serem introduzidos no núcleo, e nem mesmo plug-ins que os usuários realmente notariam. Este é o primeiro grande desenvolvimento de que me lembro que afetará massivamente todos os usuários do WordPress. Quer você seja um desenvolvedor, editor de design ou de conteúdo, isso afetará você de uma forma ou de outra.

Para atenuar esse efeito e tornar a transição mais suave, só precisamos de mais tempo. No momento, como a maioria neste tópico e em muitos desenvolvedores da comunidade WordPress que conheço, usamos ferramentas como o ACF para criar sites personalizados de acordo com as necessidades do cliente. Fazer o mesmo daqui para frente, em um curto espaço de tempo, exigirá que eu aprenda uma linguagem totalmente nova usando Javascript e React, o que é irreal em um período de 4 a 6 meses.

Muitos tópicos aqui nos dizem para ler a documentação e aprender tudo sobre Gutenberg. Não é que eu não esteja disposto a aprender Javascript e React e Gutenberg - Eu adoraria e parece que se você fosse construir algo novo em WordPress, esse é o caminho a percorrer. No entanto, como muitos neste tópico, tenho um negócio para administrar, clientes atuais para cuidar e, realisticamente, não posso aprender isso em tão curto espaço de tempo. Eu simplesmente não tenho tempo.

Estou genuinamente preocupado com o que acontecerá aos sites dos clientes quando o WordPress versão 5 chegar e espero muitos clientes insatisfeitos. Admito que ainda não chegamos lá e espero que o caminho para a versão 5 do WordPress com Gutenberg seja tranquilo. Devo admitir, porém, que nada do que estou ouvindo está me convencendo de que esse será o caso, com mensagens contraditórias.

Nunca antes houve uma questão tão polêmica na comunidade. Disseram-nos para não nos preocuparmos, mas sem nenhuma evidência sólida para comprovar isso. Só espero que tudo corra melhor do que eu esperava.

Pensando alto, mas eu me pergunto se as pessoas têm vários momentos em suas cabeças para pensar quando o 5.0 está sendo lançado.

Minhas costas do guardanapo são:

Gutenberg continua com lançamentos semanais regulares como um plug-in (com um feriado bem merecido) até por volta do início de abril.

Em seguida, Gutenberg será proposto para fusão no Core. Isso provavelmente levará pelo menos uma semana de trabalho logístico, talvez 2 semanas. Então, estamos olhando para meados de abril.

Em versões anteriores, após a fusão do projeto de recursos, houve uma janela de uma semana antes do Beta 1 ser lançado. Direi 25 de abril (de novo, esta é a minha opinião, não uma programação firme).

R Releases desse tamanho provavelmente precisarão de pelo menos 4 betas, mas acho que 5 podem ser mais seguros aqui. Portanto, diremos que é o final de maio antes de chegarmos ao RC1.

Um período de RC de 3 semanas para acertar quaisquer arestas coloca o lançamento em torno de 19 de junho, que é apenas cerca de 1 ano após a estreia mundial de Gutenberg na WCEU 2017 (ignorando que o trabalho estava em andamento antes disso e as postagens estavam em make.wordcamp.org/ núcleo, alguns meses antes, delineando alguns dos primeiros trabalhos)

Quando penso no fato de que estamos essencialmente em um ponto em que a API está estável, leva mais 6 meses para preparar. Obviamente, há uma necessidade de mais documentação em curto prazo para ajudar a tornar mais fácil para as pessoas construírem em cima de Gutenebrg, mas isso é essencialmente 2 quartos para se preparar para os tipos de eventos aquáticos, ou 13 sprints de 2 semanas para as pessoas mais ágeis.

_Partindo do AWP Facebook Group_

Concordo com a necessidade de educar. No entanto, não levará muito tempo, como desenvolvedores / criadores de sites, para testar o Gutenberg em alguns sites existentes. Se você tiver um site de teste / local para um site já concluído, basta instalar o Gutenberg nele e testar. Levei cerca de meia hora para testar o Gutenberg em 3 sites (atualizei o WordPress e todos os plug-ins desses sites). Um que estava usando o Beaver Builder era perfeitamente adequado para as páginas, contanto que eu usasse o Beaver Builder (que é a coisa perfeitamente razoável a se fazer) e os postes (sem construtor) funcionassem bem fora da caixa.
Os outros dois sites foram alimentados com o uso intenso de ACF e descobri que as metacaixas não estão salvando no momento. Ainda não descobri, e provavelmente irei reportar no GitHub (vi que já havia alguns problemas sobre o assunto) quando tiver algum tempo.

Eu pessoalmente confio na equipe principal e em todos os contribuidores que estão trabalhando muito duro no Gutenberg, que quando o 5.0 for lançado, ele funcionará imediatamente para uma porcentagem muito alta de todos os sites. O objetivo, a meu ver, não é quebrar a maioria dos sites que rodam no WordPress.
No entanto, temos que retribuir à comunidade, pelo menos, relatando quaisquer incompatibilidades que encontrarmos ao longo do caminho.

Além disso, não posso concordar totalmente com o ponto de "vai custar muito". O que irá? Instalando o plugin do editor clássico? Se você tiver um contrato de suporte com seus clientes, como parte da atualização 5.0 que você fará, instale também o plug-in Classic Editor. Estrondo! Você Terminou :)
Se você não tem um contrato de suporte, reserve um dia (ou quanto tempo você precisar - você tem alguns meses) para criar uma lista de clientes anteriores para os quais você construiu sites. Envie para si mesmo e para Bcc a todos e escreva algo nos moldes de

Ei, eu só queria avisar que com o WordPress 5.0, que está agendado para lançamento em, uma grande atualização será feita em torno da experiência de publicação / edição. Como esta é uma atualização realmente importante, ela pode ter efeitos potencialmente negativos no gerenciamento do conteúdo do seu site.
Não se desespere! Existe uma solução realmente fácil, que ainda permitirá que você atualize com segurança - basta instalar e ativar o plugin "Editor Clássico". Isso garantirá que você continue usando a mesma interface com a qual está acostumado.
Como sempre, recomendo que você faça essas atualizações em um site de teste, ou pelo menos faça um backup do seu site antes de atualizar o WordPress.
Se você quiser saber mais sobre a próxima atualização, fique à vontade para ler sobre ela aqui

Se você precisar de alguma ajuda, será um prazer ajudar.
Atenciosamente,

Estrondo! Você Terminou. Sim, talvez você precise responder a uma série de perguntas nesse ponto, mas isso só solidificará a satisfação de seus clientes. Eles verão que você se preocupa com eles e com o bem-estar do site, mesmo depois de concluí-lo. Se você não quer avisar seus clientes, então não o faça, para mim valeria a pena.


Algumas ideias que não postei no Facebook:

  • Seria uma boa ideia criar um ponteiro (é assim que eles eram chamados, certo?) Após atualizar para o 5.0 que informa as pessoas sobre o Gutenberg, e que eles podem instalar o plugin do Editor Clássico para obter sua IU antiga de volta. Isso pode reduzir drasticamente o número de pessoas frustradas que correm para o Google / desenvolvedor / suporte / etc. para ajuda.
  • Qualquer pessoa que afirme que terá que mudar tudo o que está fazendo atualmente para desenvolver sites WordPress personalizados - por favor, entenda que não será o caso. Na pior das hipóteses, você só precisa instalar um único plugin (ou adicionar o código equivalente ao seu tema / plugin) e pronto .
  • Para qualquer um que diga que não há tempo suficiente para ajustar (mesmo os autores de plug-ins) - por favor, há mais de 4 meses. Gutenberg não é algo que está sendo trabalhado nos bastidores e será lançado na cabeça de todos sem aviso prévio. Novamente, se você testar agora, saberá se precisa fazer alguma alteração. Se algo não funcionar - contribua criando um problema.

E finalmente...

Por favor, por favor - seja gentil com todos os contribuidores. Eu entendo que grandes mudanças são frustrantes, mas coloque-se por apenas um minuto no lugar de um colaborador que está trabalhando em Gutenberg ou por trás dele. Como você se sentiria se milhares de dedos apontassem para você e dissessem "o que você está fazendo é ruim e você deveria se sentir mal. Não queremos a sua inovação"? Trabalhe com, em vez de contra, os contribuidores. Ajude-os a encontrar todas as combinações de código / plug-ins / temas que eles não poderiam encontrar. Ajude a tornar a transição mais fácil e melhor para todos. Retribua à comunidade: coração:

Paz: v:

@senlin

Estou seriamente olhando para outros CMSs e já criei alguns sites com Grav CMS.

Então, você está disposto a investir tempo para aprender outro CMS, mas não para instalar um plugin que apenas mantém a experiência como está? Você entende que qualquer coisa da qual você não seja o único desenvolvedor pode, em algum momento no futuro, fazer uma escolha da qual você não gosta / com a qual concorda e colocá-lo na mesma situação? Você é livre para fazer o que quiser, é claro, para mim parece apenas uma decisão ilógica, dada a situação como eu a entendo (talvez nós apenas a entendamos de forma diferente?).

Os CPTs não funcionarão mais sem declarar show_in_rest ?!?!?! Agora devo voltar aos sites dos clientes e refazer de 3 a 5 anos de trabalho?

Como está agora, se você CPT não declarar show_in_rest , ele será apenas padronizado para o editor padrão (então você nem saberá que Gutenberg está instalado editando uma postagem em seu CPT). No entanto, como @youknowriad mencionado acima, isso deve ser corrigido no futuro, de forma que show_in_rest padrão o valor de show_ui quando ausente.

Você já teve a chance de testar o Gutenberg com um dos sites que você construiu anteriormente? Se não, eu recomendo instalá-lo em um site de desenvolvimento, para que você tenha uma melhor imagem do que funciona e do que não funciona com sua configuração.

@ nikolov-tmw Nikola,

Então, você está disposto a investir tempo para aprender outro CMS

Sim, de fato!

mas não instalar um plugin que apenas mantém a experiência como está?

Mantém a experiência por quanto tempo exatamente?

Você é livre para fazer o que quiser, é claro

Uau, obrigado, eu realmente precisava da sua permissão!

talvez nós apenas entendamos isso de forma diferente?

provavelmente

Você já teve a chance de testar o Gutenberg com um dos sites que você construiu anteriormente?

Na verdade, instalei-o em alguns sites

Se não, eu recomendo instalá-lo em um site de desenvolvimento, para que você tenha uma melhor imagem do que funciona e do que não funciona com sua configuração.

Obrigado por assumir!

Acho que, no final das contas, o impacto econômico depende de como você constrói os sites (para os clientes). Você mencionou o Beaver Builder, já mencionei antes (role para cima) que os construtores de páginas não são algo que eu uso ou meus clientes desejam. Então, duas coisas diferentes que você está comparando aqui, na verdade.

O impacto econômico que mudar para Gutenberg terá para mim é tão grande que, na verdade, prefiro mudar para uma forma diferente de construir sites. Obrigado pela sua compreensão e respeito por isso!

Muitos pontos importantes aqui. Eu concordo com quase todos eles. Acho que a solução real é fazer com que o Wordpress implemente o Gutenberg como uma OPÇÃO. Deixe-nos escolher usar o editor Tiny MCE sem precisar instalar um plugin.

Eu entendo os dois lados. As chances e as preocupações. Não tenho ideia se Gutenberg atrairá novos usuários do WordPress ou ofenderá os existentes. Mas, como desenvolvedor, devo dizer que tudo o que li sobre como Gutenberg se tornará parte do WordPress Core parece errado.

Estou com saudades de @m nesta conversa. Onde está a conversa sobre compatibilidade retroativa do passado? Se você deseja transições suaves, não deve forçar alterações significativas. Não forneça um plug-in para voltar ao editor clássico. Torne o editor clássico o padrão para qualquer atualização do WordPress existente para 5.0. Faça do Gutenberg uma opção para quem se atualiza. Você já pensou nas milhares de instalações do WordPress fazendo uma atualização automática? Você não alcançará 90% dos usuários para lhes dizer como podem 'resolver' o problema de Gutenberg. Simplesmente não o ative. Conte sua história sobre isso na tela de atualização do WordPress. Diga às pessoas por que pode ser interessante. Se Gutenberg é o futuro, você pode ativá-lo a cada nova instalação do WordPress, mas nunca padronizar para Gutenberg após uma atualização.

WooCommerce mudou para CRUD. Uma mudança significativa. E não foi tão bom quanto o esperado. No entanto, não quebrou a compatibilidade com versões anteriores. Os desenvolvedores tiveram tempo para se adaptar depois que o CRUD foi introduzido. Por que não fazer o mesmo com Gutenberg?

Você fala sobre a melhor documentação de Gutenberg. Multar. Mas desenvolvendo plugins e aplicativos baseados em WordPress eu aprendi a melhor documentação do código-fonte. Portanto, você simplesmente tem que esperar até que o Gutenberg final chegue, pois você não sabe o que mudará durante o desenvolvimento de Gutenberg.

Se eu fosse o líder do projeto, seguiria um plano simples:

  1. Gutenberg não obteria o editor ativo para atualizações do WordPress. Apenas para novas instalações do WordPress
  2. O plugin para mudar para o editor clássico faria parte do núcleo. Suas configurações seriam visíveis nas opções gerais de publicação do WordPress.
  3. Os CPTs funcionariam como antes. Se eles declararem suporte ao editor, eles usarão o editor clássico como padrão. Se eles usarem Gutenberg, eles terão que declará-lo.
  4. Metaboxes funcionariam como antes. Não importa se eles lidam com conteúdo, taxonomias ou coisas personalizadas. Simplesmente não há razão para que o editor tenha qualquer impacto na lógica de negócios.
  5. E por último, mas não menos importante para mim, Gutenberg não seria nada mais do que qualquer outro construtor de páginas. Portanto, eu daria uma olhada em todo o excelente trabalho desses desenvolvedores e como eles conseguiram NÃO quebrar nenhum dos principais recursos do WordPress ;-)

Só meus 2 centavos

falando de impacto econômico:

alguns afirmam que [GB] é um bug que devo resolver, pois sugeri o WordPress em primeiro lugar.

https://deliciousbrains.com/wordpress-gutenberg/#comment -3700968927

Obrigado a todos que dedicaram seu tempo para ponderar. Este é um feedback significativo para consultar à medida que o projeto avança.

Encerrando este problema, pois não há nada imediatamente acionável.

Esta página foi útil?
0 / 5 - 0 avaliações