Gutenberg: Uma maneira de desativar o editor de Gutenberg no código?

Veja também:

• https://github.com/WordPress/gutenberg/blob/master/docs/faq.md#will -i-be-able-to-opt-out-of-gutenberg-for-my-site
• https://wordpress.org/plugins/classic-editor/

Olá @aduth atualizou o título para fazer mais sentido - procurando por opções de código :) obrigado

Eu acho que essa seria uma função muito útil para muitos desenvolvedores. Na verdade, eu iria mais longe e sugeriria que acho que Gutenberg deveria estar ativo apenas em novas instalações do WordPress que são da versão 5.0, em vez de estar ativo em sites que estão atualizando para a versão 5.0 do WordPress - quando a fusão no núcleo acontece.

Se isso fosse combinado com uma forma de ativar / desativar no código, os desenvolvedores poderiam ativá-lo quando pronto.

Você poderia explicar por que precisa fazer isso por meio de código?

Se for um problema de visibilidade / controle do cliente, você sempre pode instalar o plug-in mencionado acima como um "Plug-in obrigatório": https://codex.wordpress.org/Must_Use_Plugins

Como uma mudança de código é rápida e fácil - habilitar um plugin 1) não é meu código e 2) não é tão simples quanto adicionar algum código - adicionar à lista de dependências não é uma maneira prática nem sensata de abordar esse problema.

Definir uma constante pode ser o seu código, mas a lógica que opera na referida constante não seria tanto o seu código quanto o plug-in "Editor Clássico" mantido oficialmente.

Devo esclarecer que não estou tentando ser argumentativo, mas sim tentando entender melhor por que essas abordagens são atraentes, certificando-me de que existem opções suficientes, embora também não ofereça tantas que sejam excessivas para manter.

Por que a funcionalidade do plugin não pode fazer parte do núcleo? Só estou perguntando porque estou curioso :)

Eu gostaria de espelhar a necessidade da habilidade de ligar / desligar o editor de Gutenberg. Minha situação particular é que um dos meus sites WordPress é construído sobre um tema que tem um editor personalizado (por exemplo: Avia Editor no tema Enfold).

Quando Gutenberg é habilitado, o fluxo de trabalho para nossos editores muda. Eles têm que ir para Todas as postagens> ou Páginas> e clicar em "Editor clássico" e, em seguida, clicar no botão do Editor de layout avançado, que invoca o Editor integrado do tema em vez de simplesmente clicar em "Editar" na página que desejam editar , ou na página de visualização. Precisamos desse editor, porque a aparência do nosso site é padronizada em torno dos modelos que construímos com esse editor.

Embora o processo pareça trivial para a maioria, a mudança no fluxo de trabalho para dezenas de Editores causaria algumas dores de cabeça de suporte.

Meus 2 centavos.

Acho que a diferença é apenas "psicológica". Tê-lo no Core significa que o teremos indefinidamente, o que prejudica a adoção do Gutenberg, onde tê-lo como um plug-in significa que vamos suportá-lo por algum tempo (acho que Matt disse vários anos) e em algum ponto pararíamos.

Não sei se isso precisa ser dividido em um problema separado ou não, mas gostaria de expressar meu apoio à ideia de @wpmark de habilitar Gutenberg apenas para novas instalações do WordPress 5.0 e oferecê-lo como uma opção para as pessoas ao atualizar (a menos que o plugin do Editor Clássico ou algum outro recurso de "desabilitar" seja usado).

Se você quiser ler, minha justificativa para isso é fornecida em um post que escrevi e é uma combinação da grande mudança na interface do usuário para meus clientes e as mudanças de código que podem ser necessárias para suportar Gutenberg adequadamente (que em no caso dos meus clientes pode não haver orçamento para).

Parece que Gutenberg será ótimo para pessoas que não conhecem o WordPress instalando um novo blog e começando. E será ótimo para as pessoas que atualizam e pensam "Yay - novo editor - terei isso, por favor". Mas para outros será um choque enorme. E, em alguns casos de uso, o GB pode não ser uma boa interface para editar um tipo de postagem personalizada, ou "blocos" podem não ser um bom modelo de dados para as informações que estão sendo editadas.

Também parece que as vozes dos desenvolvedores e proprietários de pequenas empresas precisam ser ouvidas sobre este tópico. Eu conheço muitas pequenas lojas de desenvolvimento de WordPress e essa mudança vai ser dolorosa por todos os motivos descritos em minha postagem do blog. Não ouvi um desenvolvedor ou pequena agência dizer que a habilitação automática de GB para sites atualizados é uma boa ideia. Já ouvi muitos recuando com a ideia.

Este tipo de usuário WordPress (e lojas de desenvolvimento como a minha são grandes apoiadores e proponentes do WordPress, então realmente esperamos que você escute) entende bem seus usuários, sabemos em profundidade o que construímos no WordPress e se é ou não se encaixará bem na interface do usuário GB sem modificação, e PRECISAMOS a capacidade de gerenciar essa alteração em nome de nossos clientes.

Sei que podemos instalar o plug-in do Editor Clássico e talvez ainda seja necessário fazer isso para remover a possibilidade de nossos clientes habilitarem o GB por conta própria. E se GB for opcional para sites atualizados, isso envolveria naturalmente ter um código para desativá-lo no núcleo. Isso deixaria @ smp303 (e outros que querem uma maneira de desabilitá-lo no core) felizes também!

Espero que as opiniões dos desenvolvedores e pequenas empresas de WordPress como a minha sejam ouvidas enquanto o plano de fusão no núcleo é produzido. Nossos meios de subsistência podem ser afetados por essa mudança e algumas pessoas sentem que essa mudança está sendo forçada a eles muito rapidamente. Dê-nos mais opções para gerenciar a transição e considere que o GB não será a coisa certa para todos quando for adicionado ao núcleo pela primeira vez.

Um filtro no núcleo WP ou uma constante para wp-config.php, parecem duas opções sólidas de poder ter.

Ecoando @rosswintle e sua excelente postagem no blog com o

Tem de haver uma maneira de habilitar Gutenberg para aqueles que o desejam, mas não de aplicá-lo para aqueles que não o desejam. Eu sou razoavelmente fácil sobre se isso acontece em código ou por meio de um plug-in - na verdade, como alguém que mantém mais de 50 sites WordPress usando um console de gerenciamento, a instalação de um plug-in em massa para desativar o Gutenberg faria mais sentido prático (embora menos geek) mas meh, contanto que isso possa ser feito. Mesmo uma opção de configurações no painel estaria ok, IMO - um padrão de "Gutenberg: desligado" ainda melhor ...

O argumento de Ross sobre sites retroativos com Gutenberg também é válido. Praticamente qualquer pessoa que constrói para clientes sabe que a grande maioria gasta seu orçamento para lançar e não tem nenhum orçamento depois disso. Modernizar Gutenberg, treinar clientes de novo, uma interface diferente - pensar que qualquer pessoa pagará por isso além de desenvolvedores e proprietários de negócios é uma terra de fantasia.

Apenas gostaria de ecoar os sentimentos de @ smp303 , @dmje e @rosswintle.

Poder colocar uma ação simples em functions.php para desativar Gutenberg parece a coisa mais simples e óbvia a se fazer.

Não posso deixar de sentir que a abordagem do plugin foi usada para tornar um pouco mais difícil do que o necessário para contornar Gutenberg.

Eu sei que a equipe central colocou muito esforço em Gutenberg, mas seu sucesso deve ser determinado por seus méritos, não limitando a capacidade de evitá-lo. Além disso, pense nos desenvolvedores de WP tendo que desenvolver para um editor totalmente novo, aprender a reagir e ainda desenvolver e manter o material legado - a sobrecarga é ENORME.

Também gostaria de ecoar isso - também gostaria da opção de desabilitar o editor de Gutenberg via código e não via plugin.

Veja também este tíquete do Trac que foi criado e agora fechado como wontfix : # WP43068

Por @ dd32 em https://core.trac.wordpress.org/ticket/43068#comment : 6

Eu não acho que iremos apoiar uma constante para isso e, em vez disso, simplesmente direcionaremos as pessoas para o plugin e talvez um mu-plugin wrapper para ele, simplesmente porque o plugin existente não é apenas um switch, ele vai para envolver o código que não está no núcleo sendo usado.

O WordPress tem tentado se afastar das constantes, já que são muito difíceis de mudar mais tarde no caminho "Oh, eu quero Gutenberg, por que ele está desativado? Oh, meu plugin SEO aleatório (ou ex-desenvolvedor) pensei que eu não faria quero e desativei à força, ótimo .. agora quem posso consertar isso para mim "(usuário final)

Eu posso ver porque algumas pessoas gostariam de desativá-lo, mas não vejo nenhuma necessidade de que seja feito dessa maneira.

Acho que podemos fechar com segurança como wontfix , que pode mudar mais tarde (e voltaremos a visitá-lo então), mas não espero que mude.

Obrigado a todos pelo feedback. Eu entendo que há alguma controvérsia na decisão de exigir o plug-in do Editor Clássico para desabilitar o editor de bloco totalmente, então eu gostaria de conversar sobre as várias opções.

Nos próximos anos, o conceito de "bloco" para gerenciar os dados do site se tornará o principal método para pensar, dispor, interagir e editar dados. O editor de blocos que vem no WordPress 5.0 é o primeiro grande passo nessa direção, o foco da Personalização de Gutenberg este ano é o próximo passo, junto com o Tema de Gutenberg.

Claro, nem todo mundo estará 100% pronto para o editor de blocos quando o WordPress 5.0 for lançado. Essa é uma realidade prática da qual todos estão cientes e não queremos deixar as pessoas sem uma forma viável de atualizar para o WordPress 5.0. Com isso em mente, existem algumas maneiras diferentes de desabilitar Gutenberg, dependendo do seu caso de uso específico.

Se você registrar as metacaixas que não funcionam com o editor de blocos, poderá facilmente marcar essa metacaixa como incompatível .

Da mesma forma, há uma discussão sobre a adição de um sinalizador semelhante para CPTs (# 2457), de modo que os CPTs que não requerem a funcionalidade do editor de bloco possam optar por não fazê-lo.

Estes são os dois principais casos de uso de longo prazo para desativar o editor de blocos - situações em que ele não funciona ou não se ajusta aos padrões de uso.

Com essas coisas em mente, vamos pensar sobre os próximos anos de como o WordPress irá potencialmente evoluir (observe que estou muito olhando para uma bola de cristal aqui - as coisas nesta lista não acontecerão necessariamente nesta ordem, período de tempo ou até mesmo - é apenas um cenário potencial que dependerá muito de como a versão do WordPress 5.0 vai acabar).

• O Customiser usa o conceito de bloco para tudo. Para 99% dos novos sites, os blocos são a única coisa necessária para criar sites inteiros. A manipulação de blocos é como os sites são construídos.
• Novos temas irão evoluir em torno da construção de sites inteiramente de blocos. A experiência do usuário padrão do WordPress é construída com blocos.
• Ao mesmo tempo, o wp-admin começará a adotar a interface do aplicativo JavaScript que Gutenberg está trazendo. Mudar para o Editor Clássico ainda é possível, é claro, mas não corresponde ao resto da interface do WordPress.

Vou reiterar que ao longo de vários anos, haverá plug-ins como o Editor Clássico para restaurar as interfaces mais antigas, mas não será necessariamente possível que essas interfaces sejam mantidas no Core. Embora seja uma opção razoável desabilitar o editor de blocos no WordPress 5.0, você estaria prestando um enorme desserviço aos seus clientes se chegasse ao WordPress 5.5 ou 6.0 e ainda estivesse usando o Editor Clássico. Para pegar um exemplo, assim como as melhores práticas de layout de site evoluíram de layouts de tabela para várias iterações de layouts CSS e agora layouts de grade, as melhores práticas de desenvolvimento do WordPress também evoluíram.

Então, voltando à questão original, uma única opção baseada em código para desativar o editor de bloco não é uma solução viável a longo prazo, ela não pode ser expandida para fornecer opções apropriadas para o desenvolvimento futuro do WordPress Core, realmente presta um desserviço a todos aqui se criássemos essa opção. O plugin do Editor Clássico, no entanto, pode continuar a evoluir para se ajustar a qualquer paradigma que o futuro traga. Ele oferece um ambiente mais descontraído onde pode ser desenvolvido especificamente para atender às necessidades das pessoas que o exigem, em vez de precisar se adequar às necessidades mais gerais de todo o mundo WordPress.

O problema com o editor de Gutenberg não são os blocos ou o conceito de blocos - é que o próprio editor não é bom. É, atualmente, muitas vezes mais confuso do que o editor existente - que, por si só, está longe de ser perfeito. E, à medida que nos aproximamos do tempo (previsto para abril, eu acho?) E as pessoas expressam mais e mais preocupações, o feedback nunca é "você está certo, aqui está como planejamos resolver isso", é exatamente como você fez acima "bem, isso está acontecendo, então é melhor embarcar".

O interesse em desativar Gutenberg, pelo menos o meu interesse, não é o futuro dos blocos vs widgets e o roadmap de longo prazo do personalizador - é que o editor real realmente é uma merda. Eu não quero usar isso. Meus clientes não querem usar. Não é uma coisa legal de se usar. E, a razão de não ser muito bom, é o conceito básico de que cada parágrafo e pedaço de texto é um "bloco" e todos nós odiamos isso.

Essa é a razão pela qual queremos desligar isso. Ir para Gutenberg é, para muitos, uma experiência altamente desagradável e profundamente perturbadora tanto para os clientes quanto para o desenvolvimento.

Não me importo com o futuro roteiro. Preocupo-me em perder meus clientes e meu negócio e até agora ninguém na equipe de Gutenberg parece compartilhar essa preocupação. O que devemos fazer quando a plataforma central de nossa receita está avançando a todo vapor em uma direção que não queremos ir? E o que devemos fazer quando nossas preocupações são deixadas de lado em nome do "roteiro do futuro"?

Sou totalmente a favor da substituição de widgets, inserções e códigos de acesso em um sistema de bloco universal. Acho que é uma boa ideia - estou por trás disso. Gosto de tentar dar aos usuários mais controle sobre o layout do site - por que não?

Estou preocupado porque a ferramenta real de criação de conteúdo é, atualmente, uma bagunça quente e quente que nenhum dos meus clientes (mais de 300) quer usar. Eles realmente olham para isso com horror, e todas as pequenas demos e vídeos do YouTube e palestras gravadas em WordPress estão apenas mostrando o quanto eles odeiam.

Eles não querem escrever em blocos! Eles não querem um editor baseado em bloco! Todos eles odeiam isso - eles querem que funcione como o MS Word ou Google Docs, porque é o que eles normalmente usam para escrever coisas. Isso é o que eles querem.

Como posso dar isso a eles quando tudo o que o WordPress quer fazer é enfiar bloqueios em suas gargantas?

A única alternativa que tenho é desligar Gutenberg. Portanto, quero um método confiável de fazer isso. No mínimo, até que esse trem de desenvolvimento volte a si e crie algo que realmente valha a pena usar - não como um mecanismo de bloco, mas como um editor de verdade.

Preciso de um editor funcional onde o texto NÃO seja baseado em blocos. Quando Gutenberg fornecerá isso? Responda e direi que não precisamos mais de uma maneira de desativar Gutenberg. Até então, tenha alguma empatia real e cuidado com os milhões de usuários e empresas do WordPress e forneça uma maneira de desligar o Gutenberg que podemos ter fé - isso significa código, não outro plugin.

Deve haver uma maneira de desativar Gutenberg no nível do código. Por favor, faça-nos essa cortesia. Não dê outra resposta banal - apenas nos dê uma maneira de desligar a maldita coisa se tudo der errado.

@pento , Por anos houve uma opção fácil por usuário de desligar o tinymce, e embora muito do desenvolvimento fosse específico do tinymce, ninguém sugeriu que a opção fosse removida.

Não ouvi ainda ninguém sugerir a remoção dessa opção como parte do gutenberg, e não faz muito sentido para mim que você possa ir de gutenberg para editor baseado em texto sem ser capaz de continuar usando o atual do tinymce. Tendo em mente que o tinymce ainda terá que ser suportado como parte do widget de texto e da API wp_editor, não faz nenhum sentido de desenvolvimento ou UI forçar as pessoas a instalar plug-ins para expor APIs centrais mantidas ativamente.

Mesmo se, por qualquer motivo, você não quiser alterar essa opção do usuário para incluir a configuração relacionada ao gutenberg, a partir de um POV de desenvolvimento de software, desde que você suporte a desativação do gutenberg, deve ser uma API que faz parte do gutenberg e mantida como parte de seu desenvolvimento. Como mostra o plug-in do importador, até mesmo os plug-ins "principais" ficam fora de sincronia e tornam-se inutilizáveis ​​principalmente porque não fazem parte do desenvolvimento real do núcleo.

Recusar-se a manter tal API como parte do núcleo significa que não há compromisso de permitir que as pessoas desabilitem o gutenberg mesmo no 5.1, uma versão que provavelmente será em 2018. Você não pode esperar que as pessoas sejam capazes de fazer planos de médio prazo com tal incerteza.

@pento Obrigado pela resposta longa e detalhada. Não acho que seja apenas uma questão de COMO desabilitar o Gutenberg, mas também se e como ele será habilitado por padrão. Acho que sua resposta cobre ambos, mas também me incomoda.

Eu, pelo menos, estou muito surpreso de que a implicação aqui e em outros lugares é que o editor clássico será removido do WP e o plugin "Editor Clássico" o adicionará de volta. Este é um entendimento correto? Parece uma péssima ideia para mim, mas não consigo articular o porquê agora.

@markkap também wp_editor - como eles serão mantidos no núcleo se o TinyMCE for removido?

E editar o código meta_box / CPT para evitar o carregamento do Gutenberg é bom, mas, na verdade, sou um freelancer solitário que provavelmente constrói cerca de 60-80 sites para clientes. Não vou editar todo esse código e muitos desses pequenos clientes não vão querer me pagar para fazer isso. Eu preferiria MUITO que fosse opt-in do que opt-out: Gutenberg deve ser ativado quando eu declarar suporte para ele. O padrão aqui é, novamente, para trás. Você está forçando as pessoas a fazerem uma mudança para evitar que as coisas mudem / quebrem (fico feliz em levantar um problema separado para isso, se necessário).

você estaria prestando um enorme desserviço aos seus clientes se obtivesse o WordPress 5.5 ou 6.0 e ainda estivesse usando o Editor Clássico

(Também usando minha bola de cristal) Não acho que concordo necessariamente com isso. Acho que é impossível dizer que Gutenberg e os blocos serão uma experiência de edição melhor para todos os casos de uso futuros.

Também me encontro um pouco confuso aqui sobre a natureza dos "bloqueios". Provavelmente é uma questão de terminologia, mas implica que um ou mais dos seguintes são verdadeiros:

• Há uma mudança de paradigma que estou lutando para fazer ou entendi mal algo
• O novo paradigma não está sendo comunicado muito bem
• As maneiras como o WordPress é usado por desenvolvedores como eu para construir ferramentas de gerenciamento de conteúdo para clientes não são bem compreendidas
• As maneiras como o WordPress é usado por desenvolvedores como eu para construir ferramentas de gerenciamento de conteúdo para clientes são bem compreendidas e estão sendo ignoradas

Você disse:

Nos próximos anos, o conceito de "bloco" para gerenciar os dados do site se tornará o principal método para pensar, dispor, interagir e editar dados.

Isso me assusta um pouco e eu voltarei a isso.

A página Gutenberg em https://wordpress.org/gutenberg não parece concordar com esta descrição. Ele chama os blocos de "blocos de conteúdo" e explica que:

[blocos] são uma forma unificada de estilizar o conteúdo

_Observação: Eu sou um desenvolvedor de back-end e penso muito em termos de dados: quais dados existem em um sistema, quais propriedades os itens de dados têm, como os itens de dados estão relacionados e como os dados são consultados e manipulados._

Meu entendimento é que "blocos" são seções de conteúdo que podem ser usadas para formar um post, uma página, o que for. Eles são armazenados principalmente dentro do conteúdo da postagem no banco de dados usando comentários HTML para compatibilidade com versões anteriores, mas você também pode configurar blocos para salvar dados em outros lugares como post_meta. (Observação: isso _sente_ como um hack para manter pessoas como eu felizes em colocar metadados em blocos - não parece uma decisão de design bem pensada sobre a natureza dos blocos)

Sua implicação no que você diz é que os blocos devem conduzir _tudo_. Eles são como os "dados do site" serão gerenciados. Isso, e outras coisas que você disse, implicam que os blocos não são apenas seções de conteúdo, mas algum tipo de dispositivo de interface do usuário que pode ser conectado a qualquer coisa: opções de site, personalizações, metadados sobre postagens, widgets, menus, campos de perfil de usuário, tudo.

Portanto, acho que precisamos de esclarecimento sobre a natureza de um "bloqueio".

Se o que você está insinuando estiver correto, acho que isso representa um mal-entendido fundamental de como o WordPress é usado por pessoas como eu. E acho que essa abordagem será o que me levará a sair do trem do WordPress e encontrar um CMS alternativo para alguns projetos. O WordPress será para blogs e revistas, mas muitas das oportunidades apresentadas por tipos de postagem personalizados desaparecerão.

Os metadados no WordPress são como descritos: dados sobre dados. São informações que fornecem propriedades adicionais aos itens de conteúdo. Os metadados NÃO são conteúdo. E, IMO, não é adequado para ser colocado em "blocos" como eu os entendo. Alguns dos tipos de postagem que eu crio não têm conteúdo além de um título: eles têm apenas propriedades / campos / metadados.

Se o que você descreve aqui é verdade, eu me pergunto por que o status de postagem não é um bloqueio? Por que não são categorias e blocos de tags? Por que o trecho não é um bloco?

Eu, pessoalmente, não acho que estes sejam "blocos" da forma como os entendo porque não são conteúdos, são informações sobre o conteúdo. Sua localização na IU é importante. É importante como o usuário interage com esses bits de informação.

Algumas das post_meta que eu crio são as mesmas.

Eu (acho que vou) gosto de Gutenberg e blocos para criar posts e páginas. Mas ou eu entendi mal "blocos", ou o projeto entendeu mal como as pessoas usam dados que não serão adequados para "blocos".

Estou feliz por ter isso esclarecido e estou disposto a ser persuadido. Mas ter blocos como "o método principal para pensar, definir, interagir e editar dados" não parece se adequar às coisas que construo no WordPress.

E, voltando ao problema principal aqui, é por isso que não acredito que o editor clássico deva ser removido do núcleo, e é por isso que não quero que meus usuários tenham Gutenberg automaticamente ligado quando eu os atualizar para a v5 .0.

@rosswintle, você resumiu isso de forma absolutamente perfeita em todos os sentidos e praticamente todos os desenvolvedores com quem

Adicionando meu +1 para tornar Gutenberg a experiência de edição padrão apenas para novas instalações.

Como @rosswintle disse, existem centenas de milhares de desenvolvedores WP com clientes que não estarão interessados ​​em pagar pelo tempo para reverter para o Editor Clássico. Deixe os sites existentes continuarem como estão (é claro que disponibilize o novo editor, mas também mude de volta se não for o que eles esperavam) e implemente Gutenberg com novas instalações.

Pense em todos os proprietários de pequenas empresas com sites WP. Sites que foram desenvolvidos anos atrás e estão funcionando bem, sem nenhum novo desenvolvimento. De repente, esses usuários estão tendo Gutenberg forçado sobre eles e não apenas precisam aprender uma nova interface (esses usuários podem não ser muito experientes em tecnologia em primeiro lugar e Gutenberg pode ou não ser mais intuitivo para eles), mas pode impedir de editar o conteúdo do site.

Também é preciso considerar a reputação do WordPress, onde ainda estamos tentando nos livrar da opinião de que o WP está cheio de vulnerabilidades de segurança. @wpmark e eu até tivemos uma conversa aleatória com alguém no início da semana, em que uma das primeiras coisas que eles mencionaram quando souberam que desenvolvemos com o WordPress foi "como você protege seus sites".
Existe o risco de os usuários acharem seus sites corrompidos ou difíceis de trabalhar? Como isso afetará a reputação da WP nos próximos anos?

Definitivamente, acho que os novos sites devem ser habilitados para Gutenberg, e esse pode ser um grande recurso que é anunciado do alto durante a instalação de 5 minutos, mas deixe os sites legados continuarem como estão.

Eu não queria que a questão de apenas ativar Gutenberg para novas instalações se perdesse nesta também válida preocupação sobre a facilidade de desativação. Aqui está um problema específico para ele https://github.com/WordPress/gutenberg/issues/4423

Por favor, adicione suas idéias, votos e comentários a este. @joffff @wpmark @rosswintle @markkap @dmje

Spot em @rosswintle.

Gutenberg deve ser ativado quando eu declarar apoio a ele. O padrão aqui é, novamente, para trás. Você está forçando as pessoas a fazerem uma mudança para evitar que as coisas mudem / quebrem (fico feliz em levantar um problema separado para isso, se necessário).

Não poderia concordar mais com isso se tentasse. Não acho que os garotos e garotas que pressionam Gutenberg entendam isso.

Só para acrescentar ao que Ross disse de um ângulo empresarial (ele cobriu bem o lado do pequeno freelancer): os sites que gerencio para um PLC multinacional são como petroleiros. Mudanças fundamentais como essa levam muito tempo para serem implementadas. Os testes precisam ser conduzidos e, mesmo assim, eles precisam ser inseridos em um cronograma de lançamento semanal, que faz parte de um processo detalhado de revisão e aprovação de código.

Isso vai causar uma enorme dor de cabeça para mim e minha equipe. Na verdade, as chances são de que provavelmente terminaremos no 4.9.x até que possamos verificar completamente o impacto de Gutenberg após o lançamento do RC final para o 5.0.0. Isso pode levar semanas ou até meses. Esta não é uma solução rápida.

Também me encontro um pouco confuso aqui sobre a natureza dos "bloqueios". Provavelmente é uma questão de terminologia, mas implica que um ou mais dos seguintes são verdadeiros:

• Há uma mudança de paradigma que estou lutando para fazer ou entendi mal alguma coisa.
• O novo paradigma não está sendo comunicado muito bem.
• As maneiras como o WordPress é usado por desenvolvedores como eu para construir ferramentas de gerenciamento de conteúdo para clientes não são bem compreendidas.
• As maneiras como o WordPress é usado por desenvolvedores como eu para construir ferramentas de gerenciamento de conteúdo para clientes são bem compreendidas e estão sendo ignoradas.

Eu absolutamente sinto que é o último. Não tenho dúvidas de que os membros da equipe de Gutenberg sabem e entendem como a maioria dos desenvolvedores profissionais constrói sites usando WordPress.

No entanto, essa abordagem é totalmente incompatível, levando o WordPress para uma abordagem de construtor de sites, que a Automattic precisa para que o WordPress.com continue competindo contra nomes como Squarespace, Wix et al.

O WordPress não pode ser um construtor de sites e um CMS profissional ao mesmo tempo. Simplesmente não pode ser feito. Ele percorreu uma linha tênue entre os dois, permitindo aos usuários movê-lo em qualquer direção por meio de plug-ins. (Em direção a um site building usando Beaver Builder, Divi et al e em direção a um CMS profissional com plug-ins como ACF e CMB). No entanto, agora está claro que o CMS está se movendo firmemente na direção dos construtores de sites. Os sites que usam campos personalizados que se danem.

Finalmente, seu ponto sobre os blocos e o banco de dados está correto.

Acho que é um indicativo de muitos problemas que a equipe do WordPress deve enfrentar primeiro, antes de olhar para coisas como Gutenberg:

• Atualizando a versão mínima do PHP
• Implementar dados semânticos nativos (por meio de campos personalizados) e alterar a estrutura do banco de dados para contabilizá-los.

Como nota final, os caras da Statamic demonstraram como isso deveria ser tratado com seu novo tipo de campo Bard. Uma interface de editor opcional que resolve os mesmos problemas que Gutenberg, mas de uma forma muito mais inteligente e menos perturbadora.

Não vale a pena repetir minhas opiniões, elas já foram expressas acima. Estou de acordo com o consenso geral - deve ser uma opção considerada para habilitar Gutenberg não obrigatório na mudança de 4.x para 5.0.

Como a maioria dos desenvolvedores aqui atendo vários clientes, alguns muito experientes em tecnologia, outros nem tanto, mas empurrá-los nesta direção, suponho, só causará confusão para a maioria.

Em termos de qualquer coisa que possa quebrar; da perspectiva do cliente, eles já criaram e gastaram um orçamento para a solução fornecida, eles não vão perceber que podem precisar de outro orçamento para suporte ou para consertar problemas causados ​​por algo que não foi feito por eles ou por mim.

Entre o desenvolvedor / designer ou fornecedor da solução cuidadosamente considerada fornecida a eles, o cliente e o fornecedor, devem escolher quando permitir uma mudança tão importante sem ter que cumprir algo obrigatório.

Só para jogar isso lá fora. Embora o WordPress não siga estritamente a abordagem de controle de versão semântica, a versão 5.0.0 é uma mudança significativa.

Se a Automattic não está disposta a mudar sua estratégia em relação a Gutenberg - e vamos ser honestos, essa seria a coisa certa a fazer - então a única outra opção é fazer do 4.9 uma versão LTS.

Dessa forma, os patches de segurança poderiam ser aplicados ao 4,9 pelos próximos - digamos - 5 anos. Isso é bastante tempo para os desenvolvedores de sites migrarem seus sites para Gutenberg ou para longe do WordPress (que eu suspeito que será a opção mais popular).

Bem, todo mundo com certeza gosta de escrever longos comentários aqui. 😉 É noite para mim, então não vou abordar tudo, mas gostaria de tocar em alguns problemas.

Eu, pelo menos, estou muito surpreso que a implicação aqui e em outros lugares é que o editor clássico será removido do WP e o plugin "Editor Clássico" o adicionará de volta. Este é um entendimento correto?

Isso não é correto. Mencionei em meu comentário anterior que as metacaixas e os CPTs podem retornar ao Editor Clássico automaticamente - eles não seriam capazes de fazer isso se o código do Editor Clássico fosse removido. 🙂

TinyMCE é usado por Gutenberg para alimentar os blocos de texto editáveis ​​- isso não vai a lugar nenhum. Funções como wp_editor() podem ser mantidas com relativa facilidade no Core sem a necessidade de ser movidas para um plugin - eu esperaria que continuassem a funcionar indefinidamente.

Sua implicação no que você diz é que os bloqueios devem conduzir tudo. Eles são como os "dados do site" serão gerenciados. Isso, e outras coisas que você disse, implicam que os blocos não são apenas seções de conteúdo, mas algum tipo de dispositivo de interface do usuário que pode ser conectado a qualquer coisa: opções de site, personalizações, metadados sobre postagens, widgets, menus, campos de perfil de usuário, tudo.

Isso é exatamente o que estou dizendo. Bem, os metadados não são um bloco, embora possam informar como um bloco é usado ou exibido.

Portanto, acho que precisamos de esclarecimento sobre a natureza de um "bloqueio".

Certo. Um bloco é um pedaço de HTML que se ajusta a outros blocos. Existem várias APIs que tornam o trabalho com blocos agradável e fácil, mas é isso o que acontece.

Um bloco _não_:

• Um pedaço de HTML armazenado em post_content (embora alguns blocos usem esse método de armazenamento).
• Estático (embora alguns blocos sejam).
• Gerado dinamicamente (embora alguns outros blocos sejam).

@rosswintle , você mencionou metadados algumas vezes, e eu gostaria de esclarecer a que você está se referindo. Você poderia me dar alguns exemplos do que considera ser metadados?

Se o que você descreve aqui é verdade, eu me pergunto por que o status de postagem não é um bloqueio? Por que não são categorias e blocos de tags? Por que o trecho não é um bloco?

Apenas uma sugestão e não tenho certeza se é ou deveria ser uma opção de tema, mas por que não em add_theme_support () como a maioria das funcionalidades desenvolvidas recentemente era no passado?

Dessa forma, os patches de segurança poderiam ser aplicados ao 4,9 pelos próximos - digamos - 5 anos.

Dado que o WordPress 3.7 foi lançado há pouco mais de 3 anos, e seu lançamento de segurança mais recente foi há 6 semanas, acho que é razoável supor que o WordPress 4.9 receberá patches de segurança por um longo tempo.

@eirichmond : add_theme_support() pode ser necessário para o foco de Personalização de Gutenberg, mas a maioria dos temas suportará conteúdo baseado em editor de bloco sem nenhuma modificação.

add_theme_support () pode ser necessário para o foco de Personalização de Gutenberg, mas a maioria dos temas suportará conteúdo baseado em editor de bloco sem quaisquer modificações

@pento Qual é exatamente o foco da Personalização do Gutenberg, por favor? O que isso significa? Você mencionou que _maioria_ dos temas oferecerá suporte a conteúdo baseado em blocos. Você pode indicar, portanto, por que um tema não o ofereceria?

Vejo temas com barras laterais que não suportam certos blocos porque o bloco indica que é de largura total, por exemplo, imagem da capa.

Qual é exatamente o foco da Personalização do Gutenberg, por favor? O que isso significa?

Matt falou sobre isso no State of the Word - os três focos deste ano são:

• Editor de gutenberg
• Personalização Gutenberg
• Tema de Gutenberg

O editor Gutenberg é o que vem no WordPress 5.0. A personalização do Gutenberg está apenas começando a acontecer e está analisando a personalização do site e como isso funciona no paradigma do bloco. O tema de Gutenberg será o tema padrão deste ano e provavelmente começará no final do ano.

você pode indicar, portanto, por que um tema não o apoiaria?

Esperançosamente, todos os temas irão funcionar. 🙂 Alguns blocos têm algum CSS associado a eles (as imagens da capa são um bom exemplo aqui), então há a possibilidade de algo não parecer exatamente correto. No entanto, não há nada que faça um tema parar de funcionar.

Posso lembrar às pessoas que Gutenberg não é um projeto Automattic, não vamos desvalorizar os esforços e o trabalho de não Automatticistas que contribuem

Eu também ainda não estou certo de por que um plug-in não é suficiente, os argumentos que eu vi argumentam que as pessoas não gostam de Gutenberg, ou que elas têm um fluxo de trabalho já configurado, todos os problemas que foram mencionados antes, e todos corrigidos instalando e habilitando o plugin do editor clássico.

Lembre-se de que também há precedentes no plug-in de links.

Mas de qualquer maneira, vamos ser construtivos:

Eu atualizei para o WP 5.0 e Gutenberg substituiu meu Editor Personalizado / Não gosto / Preciso de mais tempo com os clientes

O que eu faço?

Instale o plugin do editor clássico e ative-o. Problema resolvido. Agora Gutenberg foi substituído pelo editor clássico que temos no 4.9

Desvantagens?

Você não obterá nenhum dos recursos mais recentes do Gutenberg, e novos recursos no futuro podem não fazer sentido no editor clássico. Por exemplo, se os blocos de linha e coluna chegaram em 5.1, não vejo como isso faz sentido no editor clássico

Tenho muitos sites de clientes, não estou instalando e ativando em todos os sites, e se um cliente desativar?

Use-o como um plugin MU:

• Coloque a pasta do plugin em wp-content/mu-plugins
• Coloque um arquivo na pasta mu-plugins que contenha o seguinte:

<?php
require( 'classic-editor/classic-editor.php' );

Agora o plugin está sempre carregado e não pode ser desativado. Nenhuma etapa adicional além de colocar os arquivos é necessária. Você pode então carregar o arquivo e a pasta em cada site uma vez e não precisa se preocupar com isso novamente.

Lições do plugin do editor clássico

Existem muitas funções úteis neste plugin para coisas como detectar se Gutenberg está ativado, e a maior parte é remover ganchos e substituí-los.

Ele ainda adiciona uma área de configurações com uma opção de ativar os 'links do editor clássico' para que, em vez de substituir Gutenberg, você obtenha o que vê com o plug-in gutenberg ativado do link 'editor clássico' na tela de postagens, para que oferece 3, não 2 opções.

Eu recomendo fortemente que as pessoas realmente dêem uma olhada no plugin, testem-no e vejam como ele é construído.

Lembre-se de que somos uma comunidade, não o assunto de uma equipe de produtos Automattic. Se ele quebrar, temos todo um ciclo de lançamento do WP durante o qual testamos e corrigimos. Vejo muitas partes interessadas neste tópico que têm a habilidade técnica para consertar o plugin e muito mais. Se for realmente tão importante, então tenho certeza de que alguém irá intensificar, assim como as pessoas que trabalham no núcleo intensificaram

@rosswintle , você mencionou metadados algumas vezes, e eu gostaria de esclarecer a que você está se referindo. Você poderia me dar alguns exemplos do que considera ser metadados?

@pento Claro:

Exemplo de país:

Um tipo de postagem "País" que tem um nome (título), uma descrição (conteúdo) e:

• população
• URL da imagem da bandeira
• classificação (e outros fatores, possivelmente codificados de alguma forma)
• "comunidades" relacionadas (relações com postagens de outro tipo)

Veja: http://peoplesunderthreat.org

Exemplo de imóveis:

Um tipo de "propriedade" que tem:

• preço
• tipo
• número de quartos
• data de construção
  etc.

Exemplo de evento:

Um tipo de "evento" que tem:

• encontro
• Tempo
• detalhes de recorrência
• localização
  etc

Há muitos.

Tendo habilitado e jogado um pouco, tenho algumas preocupações importantes ... Vou me concentrar na principal por agora:

WooCommerce quebra completamente ... como se nem estivesse lá durante a edição de um produto. E imagino que muitos outros plug-ins também não funcionarão completamente. Então, qual é o plano para ajudar a comunidade a ser compatível? E quanto tempo vamos conseguir?

@tomjn

todos os argumentos que vi argumentam que as pessoas não gostam de Gutenberg ou que têm um fluxo de trabalho já configurado

"não gosto" é possivelmente o termo errado. Acho que as pessoas estão apresentando bons argumentos para Gutenberg não ser adequado para muitos dos casos de uso do WordPress. Não é um caso de preferência ou gosto, é um caso de adequação.

E os desenvolvedores só querem opções para fazer isso. Posso alternar outros recursos importantes como depuração, editores de código, multisite, atualizações automáticas e revisões de postagem em wp-config.php. Alguns recursos são habilitados apenas por temas que os suportam usando add_theme_support . Por que não podemos ter opções no código para alternar Gutenberg da mesma maneira, de modo que os desenvolvedores possam usar um fluxo de trabalho adequado para uma mudança tão importante?

Um dos problemas aqui é que os desenvolvedores (não necessariamente eu, mas outros) não sentem que estão sendo ouvidos enquanto expressam preocupações sobre Gutenberg. Adicionar isso como um gesto simbólico para ajudá-los ajudaria a mantê-los um pouco mais interessados. Mesmo que por alguma razão filosófica você não concorde que é a coisa certa a fazer, veja isso como um ramo de oliveira que pode ser oferecido a desenvolvedores que não estão felizes.

Lembre-se de que também há precedentes no plug-in de links.

O plugin de links é um mau exemplo aqui. Ele preservou a funcionalidade existente no núcleo se você o estava usando e apenas removeu a funcionalidade para novas instalações (ou se você não estava usando).

EU GOSTO deste precedente.

Isso é o que está sendo defendido em # 4423

O que realmente me impressiona é que os desenvolvedores centrais e Matt estão assumindo que o mundo todo vai adotar completamente o conceito de "Blocos" e o editor de Gutenberg sem questionar. Eu acho que está tudo muito bem, mas esta abordagem do "nosso jeito ou o jeito alto" que eles estão usando com Gutenberg não só não é amigável, mas pode impactar seriamente o estado do WordPress como um todo.

Tem havido muitas ideias realmente excelentes ao longo dos tempos que simplesmente não aderiram porque simplesmente não foram adotadas pelas massas. Betamax era um formato muito superior, mas simplesmente se manteve firme e o VHS venceu. E se Gutenberg e os blocos simplesmente não aderirem? O que acontecerá com o WordPress então?

Depois, há o fator de confiança. A grande maioria dos usuários do WordPress nem mesmo entende o que é o WordPress. Eles apenas o usam porque a marca WordPress é popular, e não importa como você olhe para ele, o WordPress para a maioria das pessoas é apenas uma marca. As marcas vivem e morrem pela confiança do consumidor.

Quando a atualização 5.0 finalmente for lançada e um milhão de sites WordPress mudarem isso drasticamente, como irão reagir os usuários finais, que não seguem nada sobre o mundo WordPress?

A maioria dos meus clientes é como se dizia "mal consigo ligar um computador" ou apenas querem que o que pagaram funcione conforme prometido. Essas são as pessoas que confiaram no WordPress para fazer o que prometeu cumprir. Se um dia essa promessa for quebrada por causa do formato totalmente novo para gerenciar o conteúdo de seu site, de repente muda. Então, sua confiança no WordPress será quebrada e as pessoas IRÃO simplesmente desistir de algo se não confiarem mais nele.

Acredito que é daí que vem a maior parte da preocupação dos desenvolvedores. Construímos ótimos sites WordPress personalizados que funcionam exatamente como nossos clientes desejam e agora está tudo "quebrado" por causa de Gutenberg, e não temos opção para evitar o que poderia ser um grande desastre.

O único objetivo do Gutenberg é aumentar a participação do WordPress Marke, mas pode facilmente fazer exatamente o oposto. Ele pode realmente afastar as pessoas do WordPress. Gutenberg pode se tornar a nova Coca para o WordPress, e o WordPress não é tão grande quanto a Coca que poderia se recuperar como a Coca fez. As pessoas passarão para outra coisa e não olharão para trás.

Você continua falando "Isso afetaria o futuro da adoção de Gutenberg, blá, blá, blá", mas é realmente simples assim. Ou todo mundo vai adorar e a necessidade de removê-lo via código ou plugin, ou o que quer que seja se tornará irrelevante, ou o Gutenberg se tornará apenas um recurso estranho que ninguém realmente usa como o Press This.

Como está agora, a direção tomada será que Gutenberg será um sucesso ou o WordPress como um todo poderá falhar. Nós, os desenvolvedores com as preocupações, estamos apenas tentando não bagunçar completamente uma ótima ferramenta de gerenciamento de conteúdo. Sabemos melhor do que ninguém como nossos clientes abordam e usam o WordPress. Os desenvolvedores principais e Matt estão apenas olhando para estatísticas e participações de mercado, e você sabe o que isso nos trouxe? Os Ghostbusters são reiniciados.

Realmente queremos trabalhar com você para que isso aconteça, mas seria melhor se pudéssemos controlar como isso é apresentado ao mundo, em vez de forçar usuários desavisados. Tudo o que estamos pedindo é uma maneira de facilitarmos aos nossos clientes o novo editor. Realmente não é pedir muito.

Se Gutenberg vai realmente ser a inovação que prometeu ser, ótimo! Todos entram no trem de Gutenberg. Do contrário, pedimos apenas a opção de não torná-lo um grande desastre.

É como se você soubesse que não será bem recebido e que deseja tanto que isso aconteça que sente que a única maneira de conseguir isso é apenas forçado a todos. É como se os políticos contassem uma mentira ousada sobre como uma lei de impostos que beneficiará a todos para que seja aprovada quando, na realidade, apenas os super-ricos irão realmente se beneficiar dela.

É como o que o grande Dr. Cox disse uma vez.

Ajude-me a ajudá-lo.Ajude-me a ajudá-lo.Ajude-me a ajudá-lo.Ajude-me a ajudá-lo.

WooCommerce quebra completamente ... como se nem estivesse lá durante a edição de um produto. E imagino que muitos outros plug-ins também não funcionarão completamente. Então, qual é o plano para ajudar a comunidade a ser compatível?

@ smp303 Não é o lugar para discutir isso, mas estamos trabalhando na compatibilidade com WooCommerce + Gutenberg agora. Fique de olho no blog de desenvolvimento do

Talvez uma analogia melhor do que "New Coke" seja o Windows 8.

Essa foi uma visão nova e ousada para uma mentalidade de computação mais móvel que saiu pela culatra terrivelmente porque mudou muitas suposições de uso de base. Sim, nas configurações profundas, um usuário poderia recuperar muito de sua experiência anterior com o Windows, mas a menos que estivessem atualizados nas revistas de tecnologia, os usuários não tinham ideia de como fazer isso. O resultado foi uma catástrofe para o Windows.

Gutenberg está caminhando muito rapidamente pelo mesmo caminho. Ele está fazendo uma mudança monstruosa, totalmente impulsionado pela empresa e não pela comunidade, e está deixando (suponho, poucos detalhes sobre isso eu posso ver) um caminho bastante obscuro por meio de um plugin externo para voltar ao editor tradicional para aqueles que não gostam desta nova metodologia.

Eu acho que se Automattic / WordPress não fornecer um meio nas Configurações para desativar o Gutenberg para milhões de usuários casuais do WordPress, eles irão se arrepender profundamente. Gutenberg é uma mudança tremenda. Haverá MUITAS respostas dos usuários.

Neste tópico, estamos tentando avisá-lo sobre isso e avisar que um plugin externo NÃO será suficiente. Você precisa fornecer aos usuários uma "saída" para Gutenberg, mesmo que apenas para permitir um período de ajuste. Se pudermos ativá-lo em nossos Temas existentes por meio do código, podemos evitar um desastre.

Estamos tentando, desesperadamente, ajudar aqui. Um plugin externo NÃO vai ser suficiente. Uma opção para reverter para o editor clássico precisa ser incorporada. Faça isso como parte do lançamento ou forneça uma maneira de fazermos isso por meio de um código que podemos construir em nossos temas.

Do ponto de vista lógico, estou tentando entender a filosofia de permitir que os desenvolvedores declarem uma metabox, dentro de add_meta_box () para NÃO suportar Gutenberg, o que faz com que a tela do editor, em qualquer lugar em que a metabox seja usada, mostre a "versão clássica" da tela do editor. Por que então alguns desenvolvedores se opõem a uma constante definida no arquivo wp-config.php? Se eu posso declarar que o material de Gutenberg NÃO deve ser usado em uma área do código, por que não podemos declarar para ser usado em outras áreas como definimos atualmente?

Tenha em mente que, para uma constante, o plugin do editor clássico precisaria ser empacotado com o WordPress, com um carregador personalizado, e permanecer lá para sempre. Ele ainda pode estar lá em 10, 15 anos, quando o que quer que Gutenberg seja substituído vier.

Mesmo assim, para aqueles que precisam ou querem os dois editores, o plugin ainda é necessário de qualquer maneira.

Não se esqueça de que você ainda pode instalar e configurar o plugin na v4.9 antes da chegada de Gutenberg.

Eu acho que se Automattic / WordPress não fornece

@robmcclel Automattic não é WordPress, WordPress.org! = WordPress.com, uma é uma comunidade de código aberto, a outra é um serviço terceirizado pago. A Automattic não lança versões do WordPress, o WordPress não é um produto interno da Automattic, nem o Gutenberg. Existem muitos contribuidores não-Automattic, leads de lançamento, etc. fazendo coisas fora do Automattic.

"Mesmo assim, para aqueles que precisam ou querem os dois editores, o plugin ainda é necessário de qualquer maneira."

Na verdade, pelo que foi discutido aqui e em outros lugares, se um tipo de postagem personalizado ou metabox declarar que não oferece suporte a gutenberg, a tela do editor retrocede automaticamente ... sem a necessidade do plugin "Editor Clássico". Este é um dos problemas que muitos têm com o estado atual do projeto gutenberg, existem muitas opiniões / declarações sobre o que acontece em certas situações e muitas vezes essas declarações / opiniões diferem de outras.

Tenha em mente que, para uma constante, o plugin do editor clássico precisaria ser empacotado com o WordPress, com um carregador personalizado, e permanecer lá para sempre.

@tomjn Espere! Então você está dizendo que todo o sistema de caixa-meta está sendo retirado do núcleo?

Não, eu não fiz nenhuma menção às metaboxes. Mas tenha em mente que existem metaboxes em Gutenberg, sugerir que estão sendo retiradas implica que você não testou Gutenberg e ignora que uma grande parte do ecossistema depende delas. Isso seria um grande problema para wordcamp.org, wordpress.org etc.

Para referência, não sou membro da equipe de Gutenberg, simplesmente observo e aplico o bom senso. Só porque trabalho na Automattic não significa que tenha poderes especiais com Gutenberg. Eu tenho tanto a dizer quanto todos os outros aqui, e se eu quisesse mudar isso, faria isso contribuindo com código e corrigindo problemas, assim como qualquer outra pessoa faria.

@tomjn Então o que você disse não faz sentido para mim. O "Editor Clássico" é basicamente uma página de administração com caixas meta e funcionalidade para salvar e tal. Isso significa que para ser capaz de alternar entre Gutenberg e Classic, deve haver código embutido no núcleo que permitiria as duas opções e todo o código para a funcionalidade Classic permaneceria no lugar.

Isso significaria que o plug-in Classic nada mais seria do que uma maneira de acionar a troca. Parece que seria muito mais fácil apenas construir uma coisa do tipo de suporte constante ou tema no núcleo do que ter que construir e manter um plugin.

Se tudo no Classic ainda está no núcleo, por que fazer um plugin apenas para ativá-lo?

E daí se ele tiver que permanecer no lugar. Já existe uma tonelada de código antigo e obsoleto no núcleo do WordPress. Um gatilho Classic embutido não faria muita diferença no grande esquema das coisas.

Não vamos ser falsos aqui, Tom. A Automattic é a força motriz por trás de Gutenberg. Nenhuma quantidade de 'mas não está' vindo dos funcionários da Automattic vai mudar o fato de que é tão óbvio quanto o sol no céu em um dia claro.

Gutenberg é basicamente o bebê de Matt; assim como é Automattic. Ele dirigiu o projeto. Ele tem sido seu maior líder de torcida.

Gutenberg tem sérios benefícios operacionais para a Automattic - ou seja, dando-lhe um produto para igualar a sensação de jogo com seus maiores concorrentes. O mesmo não pode ser dito para o resto da comunidade.

Sim, muitos usuários do WordPress fazem uso de construtores de páginas por meio de plug-ins. No entanto, outra grande parte faz uso intenso de campos personalizados por meio de plug-ins como ACF e CMB (e seus muitos garfos). Essa parte da comunidade clama há anos pelo projeto WordPress para implementar campos personalizados como um recurso nativo.

No entanto, não deu frutos porque o financiamento não estava lá para que isso acontecesse e cada vez que é levantado, sofre aquele problema de código aberto tão comum de morte por debate em comitê.

Muitos outros problemas de prensagem também sofreram o mesmo destino - como mudar a versão do min-PHP para algo que não está em fim de vida há mais de 7 anos .

Esses são apenas alguns exemplos de coisas que deveriam ter sido feitas anos atrás e ainda não foram alcançadas porque o financiador principal do projeto não o apoiou.

A Automattic lançou seu peso em Gutenberg - em grande parte como resultado direto de Matt estar no assento do motorista. Um grande número de horas comerciais foi dedicado a torná-lo realidade. Isso se traduz em financiamento direto do financiador principal do projeto WordPress - Automattic.

Não vejo como isso é relevante para o tíquete?

@rosswintle Isso é muito relevante. Existem muitos desenvolvedores que desejam uma maneira fácil de optar por desligar o Gutenberg. É bastante óbvio que os poderes da não querem nos dar isso e tornar o mais inconveniente possível desligar Gutenberg.

A força motriz por trás dessa decisão é a agenda da Matt e da Automattic para aumentar sua participação no mercado de sites DIY. Está claro que as preocupações da comunidade não estão sendo atendidas por causa da influência de Matt e da Automattic sobre o projeto. É daí que vem 100% da frustração das comunidades sobre Gutenberg.

Uma vez que a direção do projeto Gutenberg foi amplamente influenciada por Matt e Automattic, é relevante nesta discussão como em todas as discussões sobre o projeto.

@tomjn

A partir de Gutenberg e deste próximo lançamento, o WordPress é um produto da Automattic. Acreditar em qualquer outra coisa é tolice. .Com ou .Org não importa - o programa WordPress agora é um produto da Automattic. Os desenvolvedores e outros trabalhando nisso agora não são mais do que estagiários não remunerados da Automattic.

A comunidade quer Gutenberg como um plugin. Matt não. Matt é o chefe da Automattic. Matt é o líder autoproclamado para este lançamento. As pessoas que lideram o desenvolvimento de Gutenberg são funcionários da Automattic. Matt está forçando isso. Não há outra decisão ou debate - ele tem 51% dos votos e está exercendo.

Não se iluda pensando que o WordPress é, de alguma forma, um produto democrático ou comunitário. É o produto da Automattic agora, embora tenha sido enquadrado ou comercializado no passado, e agora eles estão direcionando o foco, o ritmo e as decisões de desenvolvimento.

@rosswintle , é relevante para o tíquete na medida em que a comunidade está pedindo métodos para desligar Gutenberg, e a equipe de Gutenberg está respondendo que o plug-in será a única maneira de fazer isso, independentemente de como a comunidade grande todo está pedindo.

Matt e a Automattic estão reforçando sua autoridade sobre isso. É melhor fechar este bilhete e todos os outros semelhantes, porque a nossa voz já não é relevante senão para transmitir simpatia e dar-nos um espaço para desabafar. Esse ingresso pode nem mesmo existir.

A Automattic é responsável por isso, não a comunidade. Precisamos enfrentar isso e nos preparar para o impacto, porque isso está acontecendo e a única saída é o Classic Editor Plugin, e mesmo isso é um pouco de caridade. Não haverá mais nada.

Eu, pessoalmente, não vejo como discutir quem está tomando as decisões aqui ajuda a levar a questão adiante. Ele está sendo desenvolvido como um projeto de código aberto e isso significa que você pode ter uma voz, e eu encorajo as pessoas a usarem suas vozes de forma construtiva, ajudando a desenvolver opções e uma justificativa para implementar essas opções.

A última postagem sobre o tópico do pedido foi feita por @tomjn , seguida por algumas perguntas relevantes de @wpstudio e @jawittdesigns

Tenha em mente que, para uma constante, o plugin do editor clássico precisaria ser empacotado com o WordPress, com um carregador personalizado, e permanecer lá para sempre. Ele ainda pode estar lá em 10, 15 anos, quando o que quer que Gutenberg seja substituído vier.

Uma constante nunca foi descontinuada? (Pergunta genuína) Parece que o WPLANG estava na v4.0? Isso é uma coisa filosófica sobre a natureza das constantes? Um filtro seria melhor? Um filtro seria aceitável para @ smp303 ?

Mesmo assim, para aqueles que precisam ou querem os dois editores, o plugin ainda é necessário de qualquer maneira.

Por que é que?

@jawittdesigns pergunta com razão:

Se tudo no Classic ainda está no núcleo, por que fazer um plugin apenas para ativá-lo? E daí se ele tiver que permanecer no lugar. Já existe uma tonelada de código antigo e obsoleto no núcleo do WordPress. Um gatilho Classic embutido não faria muita diferença no grande esquema das coisas.

e @pento praticamente descartou a remoção da maior parte dele :

TinyMCE é usado por Gutenberg para alimentar os blocos de texto editáveis ​​- isso não vai a lugar nenhum. Funções como wp_editor () podem ser mantidas com relativa facilidade no Core, sem a necessidade de serem movidas para um plug-in - eu esperaria que continuassem a funcionar indefinidamente.

Finalmente:

Não se esqueça de que você ainda pode instalar e configurar o plugin na v4.9 antes da chegada de Gutenberg.

Todos nós estamos cientes disso. Estamos tentando defender métodos diferentes que ofereçam opções aos desenvolvedores que possuem fluxos de trabalho diferentes.

@rosswintle - É importante discutir isso porque, em última análise, saber quem está tomando as decisões esclarece a probabilidade de nossos pedidos serem aceitos e como formulá-los para serem o mais influentes possível.

No entanto, sim, você está certo quanto ao fato de que esse problema específico não é o lugar certo para discuti-lo. A recusa de ceder em nossos pedidos é - no entanto - indicativo do fato de que estamos em uma posição de fraqueza em comparação com aqueles que conduzem a decisão.

De qualquer forma. Você fez alguns pontos positivos no último post. Na verdade, deixe-me pegar sua citação:

Tenha em mente que, para uma constante, o plugin do editor clássico precisaria ser empacotado com o WordPress, com um carregador personalizado, e permanecer lá para sempre. Ele ainda pode estar lá em 10, 15 anos, quando o que quer que Gutenberg seja substituído vier.

Devemos presumir que, uma vez que tudo o que substitui Gutenberg apareça, não teremos a mesma discussão novamente? O grande USP do WordPress sempre foi sua dedicação à compatibilidade com versões anteriores em comparação com seus concorrentes. Isso funcionou bem até agora. Como todos nós apontamos, Gutenberg quebra isso. Há muito pouca escolha para ficar com o que temos agora, exceto o que é efetivamente um hack oficial sancionado.

O fato é que o código ainda está no núcleo. É uma abordagem muito mais inteligente e elegível permitir o uso de uma constante - uma única linha de código - sobre um plugin que precisará ser mantido separadamente que acabará sendo centenas de linhas de código.

O fato é que o código ainda está no núcleo. É uma abordagem muito mais inteligente e elegível permitir o uso de uma constante - uma única linha de código - sobre um plugin que precisará ser mantido separadamente que acabará sendo centenas de linhas de código.

Este é o meu ponto inteiramente ... Não é apenas um nicho de quantidade de pessoas que vão precisar disso. Devido ao fato de que o Gutenberg atualmente quebra uma grande quantidade de plugins e temas etc etc ... Outro plugin não é uma correção, é um hack, uma dependência. Não é a maneira correta de corrigir um problema que pode acabar afastando um grupo de pessoas que fazem os melhores sites WordPress que existem.

A outra opção, que mais me assusta, é que as pessoas simplesmente fiquem com o 4.9 e não atualizem os sites. Em seguida, eles se tornam instáveis ​​e abertos para hackers, e trazem o nome de WordPress.

Simplesmente não me parece que se tenha pensado o suficiente nisso e, portanto, por que um plugin é a solução final.

Se TinyMCE vai continuar "por baixo" de Gutenberg para certos blocos, então por que não abordar a situação desta forma:
Pré-5.0 (também conhecido como sites atuais com WordPress) teria Gutenberg desabilitado por padrão com um filtro / constante tornando mais fácil habilitar Gutenberg.
5.0+ (também conhecido como sites WordPress instalados a partir do 5.0) teriam Gutenberg ativado por padrão com um filtro / constante tornando-o fácil de desativar.

Desta forma, qualquer pessoa que queira usar o Gutenberg terá facilidade em fazer essa escolha e quem não estiver pronto ou disposto a usar o Gutenberg (por qualquer motivo) também terá facilidade em fazer essa escolha. Às vezes, parece que alguns querem tomar uma atitude agonizante na colina de Gutenberg quando parecem haver soluções mais práticas (no curto prazo).

@wpstudio Isso é basicamente o que o # 4423 está pedindo.

Como @rosswintle , acho importante trazer esse problema de volta aos trilhos para aqueles que o fizeram e ficaram satisfeitos com os últimos comentários. Obrigado por aqueles que estão discutindo com respeito.

No entanto, deve ser dito que, independentemente do que você sinta sobre uma empresa e suas motivações, muitas pessoas estão trabalhando na Gutenberg em muitas empresas diferentes. Assim como no WordPress, isso é feito de contribuições da comunidade (não apenas de uma empresa). Fazer declarações abrangentes não é justo para aqueles que estão trabalhando nisso. Também não é justo para aqueles que começaram este problema e querem uma solução.

Espero que esta questão volte ao normal e continue a debater respeitosamente o ponto desta questão.

@karmatosed , @ntwb , @tomjn e outros neste tópico, Se meu pequeno discurso acima ofendeu, peço desculpas por isso. Este é um assunto extremamente importante e digno de debate - se é que vamos debatê-lo.

Pelos tópicos acima, acho que é bastante aparente que Gutenberg pode ser desabilitado no Core, já que os outros componentes terão que permanecer como parte do Core, então ele está apenas desligando Gutenberg. O que faz sentido, já que atualmente existe como um plugin e muitos sites podem executá-lo corretamente. Portanto, salvo uma razão técnica até então não apresentada, isso significa que esta decisão não é técnica, é filosófica.

E, esse é o verdadeiro cerne da questão. Não acho que a comunidade como um todo esteja de acordo com isso. Nem mesmo perto. É por isso que a decisão está sendo colocada (observe que eu disse "colocado" e não "culpado") com Matt, porque ele parece ser a força motriz por trás disso. E, aparentemente, por trás da decisão inabalável de tornar Gutenberg parte do Core e do lançamento 5.0.

A questão é "Por quê?"

Eu posso certamente ver o raciocínio por trás de forçar Gutenberg a estar no Core. Eu acho que os "blocos" são muito importantes para a sobrevivência futura e o uso generalizado do WordPress, .org ou .com. Eu faço. Estou atrás de "blocos '100%.

No entanto, não acho que o próprio Gutenberg, como método de entrega desses "blocos", seja um sistema bem pensado. Apenas neste tópico, existem 3 casos de uso diferentes (eu, @rosswintle e @ smp303 ) e Gutenberg não parece satisfazer nenhum de nós. Na verdade, está nos preocupando bastante - para nós, nossa empresa e nossos usuários.

A decisão de colocar o Gutenberg no Core faz sentido para a Automattic porque força todos os desenvolvedores de plug-ins a adotá-lo e reescrever seus plug-ins para trabalhar com ele. Isso é muito bom para WordPress.com e, possivelmente, bom para WordPress.org. Mas, novamente, alguns casos de uso não se beneficiarão com os blocos, mas esperamos que a existência de blocos também não os prejudique.

No entanto, isso significa que um grupo muito pequeno de pessoas está tomando decisões econômicas e de negócios muito poderosas para um número muito grande de pessoas. Só para mim, mudar para blocos custará centenas de horas e milhares de dólares, mais o tempo de desenvolvimento perdido por ter que tirar recursos de minhas metas planejadas (que a comunidade que eu atendo realmente deseja) a fim de revisar seções significativas de meu sistema para atender às demandas daqueles tomadores de decisão desconhecidos (novamente, estou assumindo que Matt é uma grande parte desse grupo de tomada de decisão).

Eu não me sentiria tão mal com isso - ou tão assustado, para ser honesto - se Gutenberg estivesse resolvendo os problemas para mim. Mas não é. Até agora, está tornando minha vida muito pior. As coisas podem melhorar, mas não vejo uma grande mudança na direção do desenvolvimento. Parece que 95% das decisões sobre uso, implementação, UI / UX, bem como meios e métodos, foram todas decididas por um pequeno grupo de outras pessoas sem muito debate ou contribuição.

O WordPress controla mais de 25% de toda a Internet. Isso se traduz em milhões de sites, bilhões de páginas da web e, possivelmente, centenas de bilhões de dólares. Do New York Times ao punhado de blogueiros de livros em minha rede. De sites de comércio eletrônico massivos a livros autografados individuais vendidos pelos autores que eu atendo. Isso é enorme - ENORME. É praticamente uma utilidade global mundial.

No entanto, a decisão de reescrever uma parte significativa dos fundamentos para tudo isso - afetando muitos milhões de pessoas - foi aparentemente tomada sem debate. Tudo, desde a interface até a dependência do REACT (controlado pelo Facebook que se provou altamente predatório, basta perguntar ao SnapChat). Todas essas decisões foram tomadas, em grande parte, unilateralmente.

Se tudo isso fosse apenas para alimentar um módulo no JetPack, ninguém se importaria. Isso é negócio do WordPress.com. Mas não é. Ele está transformando as bases de toda a Internet.

O que me leva ao aqui e agora. A comunidade, definitivamente os membros da comunidade neste tópico, está pedindo controle sobre o produto e o negócio que construíram usando o código aberto e o código WordPress.org disponível publicamente. Estamos pedindo a capacidade de proteger a nós e aos nossos usuários, e a única maneira que podemos pensar em fazer isso é pedindo uma maneira de desligar o Gutenberg. Estamos pedindo que essa capacidade seja parte do Core, assim como adicionar Gutenberg é fazer parte do Core.

A capacidade de desligar o Gutenberg pode ser adicionada ao Core? Quem é que toma essa decisão e direciona os leads a fazê-lo? Qual é o mecanismo para fazer essa pergunta? A resposta está em debate? Será submetido a votação? Existe um processo de comentário? Se sim, onde?

E, @karmatosed , você está 100% certo ao dizer que a seção "Problemas" do Github não é o melhor lugar para se ter esse debate. Concordo que este repo deve ser deixado em grande parte com o propósito pretendido, que é identificar e resolver questões técnicas diretamente relacionadas ao Plug-in Gutenberg.

Infelizmente, não parece haver nenhum outro lugar para ter essa discussão. Quer dizer, há a seção de Comentários do Plug-in Gutenberg, mas é um fórum bastante limitado para esse tipo de conversa.

Haverá um site criado para discutir Gutenberg? Não apenas sua implementação, mas para comentar e discutir a interface? O cronograma de lançamento? (Por exemplo, quais critérios governam se Gutenberg e WP5.0 estão "concluídos" e prontos para lançamento? Quem toma essa decisão? ") Haverá testes de usuário da interface de Gutenberg? Existe uma maneira de coletar dados e feedback de @ O "

Houve um vídeo interessante no YouTube pedindo às pessoas que experimentassem usar Gutenberg e avaliassem sua intuitividade (link aqui: https://youtu.be/7iWRBLCP-l0) - há outros como este? Existe um esforço em grande escala para testar Gutenberg? Em caso afirmativo, onde esses dados são mantidos? Como esses dados são compartilhados? A comunidade pode ver isso? Ele está sendo usado para impulsionar o design?

O problema que estamos enfrentando agora com Gutenberg - e de fato é a força motriz por trás dessa mesma discussão - é que a comunidade se sente muito isolada desse processo. Sentimos que isso está acontecendo conosco. Na verdade, isso está sendo imposto a nós. Abrir o processo para comentários e debates, permitindo novas vozes e ideias sobre coisas como interface, compartilhamento de dados e percepções do usuário, ajudaria muito a aliviar esses medos e preocupações.

E, fazer dos blocos uma capacidade do Core, mas mantendo Gutenberg como um plugin, poderia tornar tudo muito menos assustador e muito mais palatável para a comunidade como um todo. Eu adoraria isso, pessoalmente. Dê à comunidade tempo para explorar e desenvolver abordagens alternativas para Gutenberg - diferentes interfaces e casos de uso - mas ainda incentive o desenvolvimento e o futuro de blocos.

Então, isso foi muito longo, mas, novamente, onde mais nós teríamos esse debate além daqui? E, esse debate é MUITO importante. Pode ser a discussão mais importante da internet no momento, considerando o número de pessoas e empresas afetadas.

Depois de fazer uma pequena pesquisa sobre isso, parece que tudo o que você precisa, em um arquivo mu-plugin é o seguinte para desabilitar Gutenberg com código, a menos que eu tenha esquecido alguma coisa - o que é provável!

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

Para o contexto, tenho o plugin Gutenberg ativo e o código acima em um arquivo na pasta mu-plugins . Agora, todas as telas de pós-edição usam o editor clássico.

Algumas coisas a serem observadas:

• gutenberg_can_edit_post_type não é o nome do filtro final - gutenberg nomes serão renomeados antes da fusão no Core.
• Este filtro significa apenas "não carregue o editor de bloco", não significa "use o editor clássico". Funciona no momento, mas não é garantido que funcione no futuro. Conforme o código específico do Clássico (por exemplo, edit-form-advanced.php ) é movido para o plugin do Editor Clássico, ele deixará de voltar ao editor clássico e explicitamente espera que você carregue seu próprio editor.

@rosswintle : retomando o tópico da semana passada :

A maneira mais fácil de pensar sobre isso é "se os dados aparecerem entre <body> e </body> , são conteúdos e, no final, caberão em um bloco". Para WordPress 5.0, isso é um pouco mais limitado - apenas o que vem entre <article> e </article> são blocos. 😉

Portanto, para dar um exemplo, um tipo de posto de propriedade imobiliária. O preço é armazenado no postmeta, mas é conteúdo. Você pode ter um bloco chamado "Property Lede", ele tem alguns itens para preencher - o preço, o endereço, o tipo de edifício, o número de quartos / banheiros / garagens, esse tipo de coisa. Você provavelmente terá outros blocos também - tempos de inspeções, recursos, fotos, plantas baixas, agente, etc. Usando modelos de bloco , você configura o editor de bloco para que, quando o tipo de postagem property estiver sendo editado, os blocos já estão localizados e não podem ser movidos. O fluxo de trabalho para o usuário final não é diferente de como é agora um fluxo de trabalho baseado em metabox existente, mas se assemelha muito mais à saída final.

Isso foi um pouco prolixo, mas esperançosamente define o cenário - qualquer coisa que se pareça com conteúdo _é_ conteúdo, independentemente de onde os dados estão armazenados ou como podem ser manipulados ou formatados antes de serem exibidos no front-end. Alguns blocos podem armazenar seus dados em post_content , mas essa não é a característica definidora do que os torna conteúdo - ser exibido no frontend é o que os torna conteúdo.

E as informações que não são exibidas no front-end? O nome do proprietário? Relacionamentos com a visualização de compromissos? Isso é "conteúdo"? Isso deve ser inserido em um "bloco"?

Categorias / tags / taxonomias podem ou não ser exibidas no front-end. Eles são "blocos"?

O status da postagem pode ser exibido no front-end, mas isso definitivamente não é um bloqueio.

Você disse anteriormente:

metadados não são um bloco, embora possam informar como um bloco é usado ou exibido.

O que é ótimo. Mas por que, então, os desenvolvedores estão sendo informados de que, no futuro, os metadados devem ser editados usando a interface de bloco?

Esta é a verdadeira confusão para mim. Eu entendo porque os blocos de Gutenberg são bons para editar o que está entre as tags body , mas não entendo porque os blocos são bons para editar outros dados que não estão entre essas tags.

Parece-me que é essa confusão que está fazendo com que os desenvolvedores queiram desligar o Gutenberg. Alguns de nossos usos do WordPress possuem MUITA informação que não é exibida no front end e, no entanto, estamos sendo informados de que, no futuro, um editor de front-end é o que devemos usar como uma interface para esses dados.

Espero que isso comunique a confusão.

Então, sobre essas maneiras de desativá-lo ...?

@pento o bloco doc para essa função não indica de forma alguma que este filtro seja temporário:

/**
 * Filter to allow plugins to enable/disable Gutenberg for particular post types.
 *
 * <strong i="7">@since</strong> 1.5.2
 *
 * <strong i="8">@param</strong> bool   $can_edit  Whether the post type can be edited or not.
 * <strong i="9">@param</strong> string $post_type The post type being checked.
 */

Qual é o propósito desse filtro senão fazer conforme descrito?

Além disso, @pento em relação a isso:

Este filtro significa apenas "não carregue o editor de bloco", não significa "use o editor clássico". Funciona no momento, mas não é garantido que funcione no futuro. Conforme o código específico do Classic (por exemplo, edit-form-advanced.php) é movido para o plugin do Editor Clássico, ele irá parar de voltar para o editor clássico e explicitamente espera que você carregue seu próprio editor.

Disseram-nos em vários lugares que se os tipos de postagem declararem show_in_rest => false ou uma caixa-meta na tela de edição de postagem declarar '__block_editor_compatible_meta_box' => false, , o editor clássico será carregado. Parece que você está dizendo que isso não fará parte do núcleo e, portanto, como pode ser o caso se você não ativou o plugin do editor clássico?

Para voltar ao editor Clássico é detectado algo que não suporta Gutenberg, então certamente o editor Clássico deve permanecer parte do núcleo - portanto, certamente não precisamos do plugin para invocar esta funcionalidade?

E as informações que não são exibidas no front-end? O nome do proprietário? Relacionamentos com a visualização de compromissos? Isso é "conteúdo"? Isso deve ser inserido em um "bloco"?

Claro que há espaço para meta informações também - isso é discutido em # 3330. A principal coisa que gostaria de observar é que muito do que é conhecido como "metadados" é, na verdade, conteúdo.

Categorias / tags / taxonomias podem ou não ser exibidas no front-end. Eles são "blocos"?

Bem, eles são meta para a postagem, mas possivelmente conteúdo para o site. O foco da Personalização de Gutenberg provavelmente incluirá um bloco que usa esses metadados para produzir conteúdo. 🙂 No entanto, é improvável que um bloco no editor de bloco os use como conteúdo, daí porque as taxonomias estão na barra lateral, não em um bloco.

O que é ótimo. Mas por que, então, os desenvolvedores estão sendo informados de que, no futuro, os metadados devem ser editados usando a interface de bloco?

Não estamos dizendo que todos os metadados se encaixam na interface do bloco. Alguns podem, mas não precisam. O ponto principal é que _a maioria_ dos_ usos existentes de metacaixas se encaixam na interface do bloco, a maneira mais fácil de diferenciá-los é pensar se ele é exibido no front end ou não. # 3330 discute conceitos para editar metadados com mais detalhes.

Posso dizer categoricamente que os metadados _não_ precisam ser editados na interface do editor de bloco. Se não for conteúdo, ou não se relacionar de alguma forma com o conteúdo, ele não pertence lá - existem outros lugares para inserir a interface para editar esses metadados.

Então, sobre essas maneiras de desativá-lo ...?

Se você construir sites, use o plugin do Editor Clássico. Se você construir plug-ins, use os sinalizadores compat CPT e meta box. 🙂

Se você construir sites, use o plugin do Editor Clássico. Se você construir plug-ins, use os sinalizadores compat CPT e meta box. 🙂

Isso é bom para sites que construiremos daqui para frente ou para clientes que temos "nos livros" e cuidamos de seus sites. No entanto, e os clientes cujos sites construímos no passado e estão funcionando bem, atualização automática etc. Eles provavelmente clicarão em atualizar para WordPress v5.0.

Esses sites não terão o plugin Classic Editor instalado e não terão nenhum sinalizador nessas metacaixas / CPTs porque foram codificados quando Gutenberg não estava por perto. Esses sites vão ter problemas e deixar seus proprietários confusos e francamente bastante irritados. Por favor, me corrija se eu estiver errado aqui.

@wpmark acertou em cheio .

Usarei o plugin do Editor Clássico se for necessário no futuro. Usarei os sinalizadores compat CPT e metacaixa se for necessário no futuro. Mas tenho dezenas de indivíduos, empresas e instituições de caridade / organizações sem fins lucrativos de todas as formas e tamanhos para os quais já criei sites. Ainda tenho relações de trabalho com alguns deles. Outros mudaram e estão apenas administrando o site, ou trabalham com outro desenvolvedor ou nenhum desenvolvedor.

É irreal esperar mudanças no código ou a instalação de um plugin em cada site que precisa dele.

Este é o território # 4423, na verdade.

Para todas as conversas importantes, este tíquete não tem rótulos ou proprietário. Se não vai acontecer, vale a pena mantê-lo aberto?

gutenberg_can_edit_post_type (ou o que quer que seja chamado no Core) e '__block_editor_compatible_meta_box' => false voltará à interface clássica do WordPress 5.0. Versões futuras do WordPress podem mudar esse comportamento, no entanto.

gutenberg_can_edit_post_type apenas sinaliza se deve ou não carregar o editor de bloco. Por enquanto, o comportamento padrão ao não carregar o editor de bloco é carregar o Classic, mas a suposição desse filtro é que, se você não estiver carregando o editor de bloco, está fornecendo sua própria interface. Pode ser o plugin do Editor Clássico, pode ser uma interface personalizada. Mas é provável que uma versão futura do WordPRess veja que o código Classic será movido para o Editor Classic.

Uma situação semelhante existe para a bandeira __block_editor_compatible_meta_box . Por enquanto, ele volta para a interface Clássica, mas uma versão futura do WordPress pode ver o comportamento padrão alterado para permanecer no editor de bloco e mostrar um aviso onde a metacaixa estaria.

Claro, nenhuma dessas mudanças vai acontecer sem pesquisa e contato com os proprietários do site - meu ponto é que essas configurações existem principalmente para o propósito de transição para Gutenberg. O plugin do Editor Clássico é a opção estável para forçar o uso da interface Clássica.

Consulte # 3902 para obter mais discussões sobre esses problemas.

Sobre o assunto de informar os proprietários de sites, o WordPress 5.0 não será lançado no vácuo. Existem muitas ferramentas que podemos usar para informar os proprietários de sites sobre as mudanças que estão por vir e para que saibam se o site funcionará ou não. Futuros lançamentos do WordPress 4.9.x incluirão informações sobre o editor de blocos , há planos em andamento para coletar dados sobre a compatibilidade de plug-ins (automatizados e coletados - # 4072) e estamos abertos a outras opções para garantir que os proprietários do site estejam cientes de o que está vindo.

Para todas as conversas importantes, este tíquete não tem rótulos ou proprietário. Se não vai acontecer, vale a pena mantê-lo aberto?

Não tive nenhum problema em mantê-lo aberto enquanto discutíamos, mas, neste ponto, não vejo necessidade de mantê-lo aberto mais. Para abordar a questão original, uma opção baseada em código para recorrer ao editor clássico não está nos cartões.

@pento Por que você fechou isso? O problema ainda não foi resolvido.

Você está apenas provando o ponto de que a comunidade não está sendo ouvida fechando isto.

Eu realmente acho que você deveria reabri-lo, para que possamos chegar a uma resolução sobre isso.

A resolução foi não - eles não permitirão uma forma de desabilitar Gutenberg no código. Você tem que contar com um plugin.

Completamente infeliz e insatisfeito com isso, mas pelo menos tentei.

A resolução foi não - eles não permitirão uma forma de desabilitar Gutenberg no código. Você tem que contar com um plugin.

Onde e quando isso aconteceu? Não há menção de uma decisão aqui.

Ou essa é apenas a reação típica da equipe principal, fingindo ouvir e simplesmente desligando-a?

Que tipo de resolução você está querendo neste momento?

Se você quiser desabilitar Gutenberg usando uma constante, isso não vai acontecer. Fomos ouvidos e a ideia foi rejeitada.

Não tive nenhum problema em mantê-lo aberto enquanto discutíamos, mas, neste ponto, não vejo necessidade de mantê-lo aberto mais. Para abordar a questão original, uma opção baseada em código para recorrer ao editor clássico não está nos cartões.

De @pento - é por isso que fechou

Bem, espero que eles pelo menos liberem o plugin antes da atualização para que possamos instalá-lo e ativá-lo para que a experiência do usuário não seja interrompida.

Quero dizer, o suporte para metacaixa ainda está quebrado no 2.0 e não estou muito confiante de que funcionará neste momento.

O plugin já existe: https://wordpress.org/plugins/classic-editor/

Para responder à pergunta original de @ smp303 .

1. Em wp-config.php adicione

define( 'ENABLE_GUTENBERG', false );

1. Em um arquivo chamado my-hacks.php na pasta mu-plugins , que você pode ter que criar o código

<?php // (C) Bobbing Wide 2015-2018
if ( defined( "ENABLE_GUTENBERG" ) && !ENABLE_GUTENBERG ) {
    add_filter( 'gutenberg_can_edit_post_type', '__return_false' ); 
}   

props @tomjn @wpmark

Você pode fazer isso hoje sem ter Gutenberg ou o editor clássico instalado.
Mas esteja avisado que o nome do filtro pode mudar quando o código é incorporado ao núcleo.
... em que ponto alguém estará escrevendo documentos e, em seguida, você pode adicionar outra linha.

Observações: o arquivo chamado my-hacks.php foi introduzido em 2003 e obsoleto em 200x.
Mas não há nada impedindo você de implementá-lo como um plug-in obrigatório em mu-plugins .

Se você quiser ver como é difícil remover o código obsoleto, incluindo o campo de opção associado a ele
consulte WordPress TRAC # 33741 - Remova as referências a my-hacks.php e a opção hack_file

Ainda mais fácil ... em wp-config.php

$_GET['classic-editor'] = true;

Acho que o conceito de bloco está errado. Na minha opinião, um bloco deve ser um post. Portanto, se precisarmos de vários conteúdos em uma postagem, devemos poder ter postagens filhas. Como o Twitter, onde uma página é feita por muitos tweets independentes.

Dentro de uma postagem, precisamos apenas de um editor de texto.

Não temos orçamento para fazer uma atualização de todas as nossas páginas. Se o wp não oferecer compatibilidade de longo prazo, muitos usos apenas mudaremos no futuro para uma comunidade mais estável, pois a porta estaria aberta para novas empresas.

Agora o wordpress é legal por causa da comunidade. 5.0 significa começar do 0. Assim, como qualquer outro framework.

Duas linhas de desenvolvimento podem ser uma boa ideia ao invés de desativar ou não. WP normal e WP Gutenberg. Pelo menos pelos próximos 5 anos. Então, Gutenberg teria tempo para ficar estável e ter uma comunidade também, como WP.

Seria bom se muitos de vocês, como desenvolvedores, tivessem um problema por que não entrar e continuar
Github com um tíquete que propõe um método de trabalho para resolver seu problema ao invés de apenas escrever infinitamente porque você não pode ajudar a construir uma solução com o projeto atual de Gutenberg.

Traga suas habilidades de programação para ajudar a resolver o problema.

Sou designer visual e atualmente faço planos para ajudar dois de meus clientes a mover os processos de edição para Gutenberg e estou projetando e construindo um novo site para um cliente com um site com mais de vinte anos que eles não podem manter.

Entre e ajude a levar o WordPress.org adiante como ferramenta de construção de sites.

@TomDesign você já tentou ler a discussão? A equipe GB não quer a funcionalidade como parte do plug-in, então, a menos que em "Traga suas habilidades de programação para ajudar a resolver o problema" você queira dizer que alguém deve hackear suas contas para adicionar um código que não quer, não tenho certeza de como escrever código é até remotamente relevante aqui.

@tomdesign I aumentei o requisito de ter um Plano de Migração Viável em # 4981
Eu indiquei que vai dar muito trabalho. E é algo que considero necessário.

Tenho certeza de que há alguns desenvolvedores que gostariam de usar nossas habilidades de programação para garantir uma migração tranquila. Mas não queremos perder nosso tempo desenvolvendo algo que será rejeitado imediatamente. Na minha opinião, a migração merece um projeto em si, com cada requisito avaliado de forma lógica. É importante o suficiente ter uma proposta bem documentada que nos levará lá a longo prazo.

O pedido original de Simon era uma solução de curto prazo para um problema de longo prazo.
Acredito que o processo de migração de conteúdo vai durar anos.

Oi pessoal,
Lendo os comentários, acho que este é o lugar certo para compartilhar um bom plugin sobre Gutenberg.
Eu gostaria de apresentar um plugin gratuito que permite que você gerencie o editor de Gutenberg.
É chamado Gutenberg Manager e permite que você habilite / desabilite o editor nos vários tipos de postagem (páginas e postagens incluídas). Ele tem mais recursos, mas eu os deixo para você.

Nós lemos toneladas de postagens de pessoas reclamando sobre a futura implementação do Gutenberg dentro do núcleo do WP 5.0 e isso nos levou a encontrar uma solução simples.

O Gutenberg Manager resolve este problema e permite, por exemplo, continuar usando Elementor, Visual Composer, Siteorigin Builder ou Cornerstone sem qualquer problema, mesmo após o WP 5.0.
Desde o primeiro feedback do usuário no WP.org, o plugin parece ser apreciado :)

Por este motivo, gostaria de apresentá-lo ao Gutenberg Manager -> https://wordpress.org/plugins/manager-for-gutenberg/

O plugin pode ser usado por desenvolvedores em seus próprios temas e plugins graças a alguns ganchos úteis. Há um gancho para OCULTAR o painel de opções do plugin para que o usuário final não o veja no backend do WP (ótimo recurso para desenvolvedores que desejam incluir o Gutenberg Manager em seus projetos).

Também estamos fazendo acordos com as equipes dos Construtores mais famosos para ativar parcerias e colaborações. Desta forma, esperamos tornar a transição para Gutenberg um pouco menos traumática!

Obrigado a todos pela atenção,
Bom trabalho.

@unCommonsTeam, posso perguntar como você está desabilitando o editor Gutenberg no plugin, quando, por exemplo, as opções estão selecionadas na tela de configurações?

Claro, @wpmark ,

dê uma olhada na linha 79 -> https://github.com/unCommonsTeam/gutenberg-manager/blob/master/inc/core.php

Melhor

@unCommonsTeam, obrigado por voltar para mim. Provavelmente estou errado aqui, mas olhando parece que o plugin está apenas removendo todas as coisas adicionadas pelo plugin Gutenberg. Isso é algo que sugeri acima usando:

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

No entanto, foi informado por @pento que não era uma solução robusta, pois colocava um editor de volta no WordPress. Consulte https://github.com/WordPress/gutenberg/issues/4409#issuecomment -357912790

@wpmark sim essa função remove todas as coisas adicionadas pelo plugin Gutenberg, mas a função só é chamada em páginas de backend específicas e não para todas as backend .. Por exemplo, se você decidir desabilitar o editor de Gutenberg nas Páginas, mas deseja usá-lo nos Postagens .. Então eu acho que é aceitável.

Melhor

@unCommonsTeam parece um ótimo plugin, mas acho que teria os mesmos problemas que minha solução, pois realmente precisa adicionar um editor de volta ao WordPress.

Pelo que @pento estava dizendo é que removendo as adições de Gutenberg, isso apenas afirma que o editor de blocos não é desejado, mas você deve substituí-lo por algo - que é o que o plugin de editor clássico faz.

Como @pento afirmou:

Este filtro significa apenas "não carregue o editor de bloco", não significa "use o editor clássico". Funciona no momento, mas não é garantido que funcione no futuro.

Portanto, eu acho (e devo ser corrigido, é claro) que seu plugin está fazendo o mesmo (mas é claro que muito melhor e com muitas opções legais para flexibilidade, etc.) do que minha tentativa acima.

Outra coisa em que estava pensando é que o nome que Gutenberg ficará por aí quando o projeto for mesclado ao núcleo ou, por exemplo, essas funções (por exemplo, gutenberg_init ) serão renomeadas para (por exemplo) block_editor_init .

@wpmark você está certo. Esperamos que no WP 5 eles deixem o editor clássico lá. No entanto, podemos tentar adicionar uma opção para incluir o editor clássico via plugin. Se a equipe de desenvolvimento do WP decidir remover o editor clássico, achamos que nosso plugin se tornará muito popular :)

Sobre o gutenberg nomear você está certo, provavelmente teremos que consertar nosso plugin substituindo os nomes dos ganchos.

Além disso, nosso plugin irá oferecer outros recursos baseados no editor Gutenberg (habilitar / desabilitar blocos específicos, novos blocos, etc). Portanto, achamos que será útil para as pessoas que usam o editor de Gutenberg também.

Felicidades

Esta pode ser uma boa ideia que resolverá quase todo o estouro e debate:

Se Gutenberg vier desabilitado por padrão no núcleo, junto com o editor clássico ainda mantido, isso poderia economizar o mercado de tema e plug-in do WordPress de ~ $ 1 bilhão e vasta faixa de internet com muitos problemas, perda monetária, incidentes de suporte, além de economizar muito no WP de prestígio e perda de confiança como plataforma.

O Gutenberg, embora seja um editor mais moderno, parece ter sido criado para as necessidades do WordPress.com e meios semelhantes que fornecem serviços de blog / hospedagem usando o WordPress. Tudo isso está muito bem. No entanto, não deve levar a um choque e um chute nas bolas para o resto do ecossistema. Uma vasta faixa de internet, sites de pessoas e seu sustento serão afetados com a direção atual.

O WordPress.com pode ter o padrão Gutenberg ativado, enquanto o WP vem com ele desativado, portanto, fornecendo o melhor dos mundos para todo o ecossistema.

Eu tenho que concordar com o codebard, que o gutenberg seja desabilitado por padrão e o editor clássico continue a ser mantido. Atualmente, tenho as atualizações automáticas desativadas exatamente por este motivo - não quero que blogueiros em minha rede multisite de repente vejam esse tipo de editor de "criador de páginas" e certamente não quero que o editor clássico seja completamente substituído com gutenberg.

No mínimo, devemos ser capazes de desabilitar gutenberg com uma instrução define, como define ('DISABLE_GUTENBERG', true); Um grande problema em ter um plugin para desabilitar o gutenberg é que ficaríamos dependentes do desenvolvedor para manter e atualizar o plugin, quando necessário. O que faríamos durante os dias ou semanas em que o plugin para de funcionar porque o desenvolvedor está de férias ou ocupado demais para atualizar o plugin. Há também o problema de que as pessoas que usam o plug-in terão que atualizá-lo por conta própria.

Parece forçar o gutenberg sobre nós e então encontrar soluções alternativas para desativá-lo como uma reflexão tardia é uma maneira realmente retrógrada de fazer as coisas. Desative o gutenberg por padrão. Muitos de nós que querem apenas um blog simples estão achando cada vez mais difícil usar o wordpress, pois parece estar evoluindo para um construtor de sites.

Outra observação, no caso de redes multisite, o administrador da rede deve ser capaz de decidir se o gutenberg deve ser disponibilizado na rede.

@WebTrooper, o plugin Classic Editor é mantido pela equipe de desenvolvedores do WordPress (o mesmo pessoal que mantém o Core) e o Gutenberg Ramp é mantido pela Automattic, então ambos devem ser imunes aos fatores de "desenvolvedor em férias" ou "muito ocupado".

Observe que o VIP tem um compromisso com o plugin Gutenberg Ramp, que está em uso no site de nossos clientes e em nossos próprios sites. Estar de férias ou muito ocupado se alguma coisa quebrou pode significar sites de clientes quebrados, que é a última coisa que o VIP deseja.

Eu também observaria que esses plug-ins podem ser bifurcados, Automattic e os autores e do plug-in do editor clássico não possuem nenhum conhecimento secreto que os permitiu construir esses plug-ins, nem são tecnicamente grandes ou complexos. Existem centenas de agências em todo o mundo com desenvolvedores capazes de manter qualquer um dos plugins.

Como um aparte, muitas pessoas defendem a desativação do gutenberg por padrão, mas eu notei que independentemente dos méritos desses argumentos, todos eles falham em dizer quando exatamente o GB deve estar ativado por padrão. A conclusão lógica é uma situação perpétua do editor clássico.

É 2934, o império galáctico saltou para o sistema, 300 cruzadores de batalha. A rede local de notícias planetárias acionou o editor clássico para escrever uma reportagem para os habitantes locais. Ninguém disse a eles sobre Gutenberg antes de começarem a construir o local

Sempre sugeri que fosse ativado por padrão para NOVAS instalações.

Mas, para as instalações existentes, sugiro uma abordagem conduzida pelo usuário, permitindo que as pessoas optem pelo Gutenberg, experimentem, mantenham se gostarem e voltem ao editor clássico se não gostarem. O WordPress poderia coletar estatísticas e feedback se / quando as pessoas voltassem para ajudar no desenvolvimento e na documentação da mudança.

Quando algum tipo de massa crítica de sites ativos com ele ativado for atingido, você poderá ativá-lo por padrão. E não, não vou escolher um número no ar. Mas poderíamos medir o uso e agir adequadamente.

Alternativamente, 12 de abril de 2020 será suficiente. 😉

Isso está acontecendo com versões antigas do PHP, certo? O WordPress tem sido incansável em sua compatibilidade com versões anteriores do PHP 5.2 porque as pessoas ainda o usam, em muitos casos provavelmente sem saber ou se importar. O WordPress analisa cuidadosamente as estatísticas; colocar muito esforço na coordenação com os hosts e assim por diante; e guiando gentilmente as pessoas em um caminho de atualização. E presumivelmente o projeto irá, em algum ponto, agir sobre os dados de uso de que precisa para tomar uma decisão.

Ainda assim, com uma interface de usuário totalmente nova para edição, que usuários conhecem e se preocupam com a abordagem é forçá-la sobre eles?

Por mais que eu esteja realmente começando a defender Gutenberg em alguns casos, eu realmente espero que a proposta de mesclagem leve em conta as preocupações de pessoas como eu, que gerenciam muitos sites para usuários finais, muitos dos quais têm poucas habilidades de TI, são não está confiante com a tecnologia e ficará confuso e desorientado por Gutenberg.

Eu acho que Gutenberg também deveria estar desligado para novas instalações, devido às razões importantes abaixo:

• Existe uma quantidade quase infinita de tutoriais, recursos, how-tos e tudo o que você pode imaginar, todos baseados no editor existente. Isso torna a entrada de pessoas no WordPress MUITO fácil.

• Essa facilidade de entrada é muito importante, pois como eles começam tão facilmente assim, as pessoas entendem que 'WordPress é fácil' e prontamente têm uma percepção calorosa da plataforma, uma atitude mais receptiva e confiante para aprender mais

• Todos estes se combinam na percepção de 'WordPress simplesmente funciona', e eles o recomendam confortavelmente a seus colegas. Foi assim que pudemos crescer para abranger 30% da internet.

• A consistência das informações é importante. E não há como todos os recursos da internet serem atualizados para refletir o gutenberg, mesmo no futuro. Isso criará muita confusão. E, infelizmente, a reação do usuário comum será 'eu instalei, mas NÃO FUNCIONA', só porque ele não consegue descobrir como fazer as coisas e as coisas não são iguais ao tutorial que ele usa. Não se engane, nenhum esforço de atualização eliminará essa confusão a respeito de recursos, tutoriais e assim por diante.

Portanto, Gutenberg deve ser opcional e alternável para manter a 'compatibilidade com versões anteriores' não apenas em termos de temas, plug-ins de conteúdo criado por construtor de páginas existentes etc., mas também em termos dos recursos que temos online. Uma plataforma não é 'tão fácil' e você não pode recomendá-la para as pessoas que dizem 'apenas instale e google ...' quando o google traz muitos recursos diferentes, obsoletos e atualizados, misturados. E se você tem alguma experiência em SEO, você sabe que será ...

Com Gutenberg, podemos explorar o mercado supostamente crescente de 'construtores de sites' (wix, squarespace etc), e o mercado potencial de 'blogs fáceis' (a la medium etc). Mas, se quebrarmos até mesmo uma fração de 30% da Internet, ou o mercado de temas / plug-ins de ~ $ 1 bilhão ao fazer isso, será um chute nas bolas, do qual podemos não nos recuperar em uma década.

Você não pode instalar um plugin de PHP clássico, então a comparação com PHP não é relevante, são milhões de sites que estariam garantidos de quebrar, sem nenhuma solução baseada em WP que resolveria isso, daí a análise cuidadosa. Também tenha em mente que o próximo lançamento tem um prompt que instala o plugin clássico, os usuários não estão apenas sendo solicitados a instalar o plugin Gutenberg.

De qualquer forma, esse problema foi encerrado, as decisões foram tomadas. Uma questão fechada é um lugar ruim para tentar mudar uma abordagem que está sendo planejada em outro lugar.

Mas tenha em mente que Gutenberg pode ser alternado, existem plug-ins para ativá - lo

Percebi que, independentemente dos méritos desses argumentos, todos eles falham em dizer quando exatamente o GB deve estar ativado por padrão.

E, ao que parece, mesmo se as pessoas que argumentam tivessem feito alguma sugestão sobre quando isso deveria acontecer, ela seria rejeitada de qualquer maneira. Então, por que trazer isso à tona?

Eu sei como funcionam os tickets fechados. Você fez um aparte bastante sarcástico aqui. Portanto, tentei oferecer algo construtivo em resposta.

@tomjn eu vou echo @rosswintle aqui dizendo sim nós têm sugerido que deveria ser no apenas para novas instalações, por padrão - https://github.com/WordPress/gutenberg/issues/4423. Este é outro assunto encerrado, encerrado sem nenhuma discussão real sobre o ponto.

Eles não estão dispostos a ouvir, existe um plugin, blá, blá, blá, está fechado. Não mova nada para ver aqui. É tudo sobre .com ninguém se preocupa com .org não há dinheiro para o Automático aí.

@ smp303 você pode identificar quem são eles ?

@rosswintle Nenhum sarcasmo foi intencional, o Gutenberg 0.1.0 foi lançado 14 meses atrás, e a única maneira de evitar que sites rodando no 5.2 quebrem é apoiá-los e tentar atualizá-los. Sites cuja tela de pós-edição quebraria com Gutenberg podem instalar o plugin do editor clássico sem exigir mudanças no nível do servidor, a comparação não é justa

Eles não estão dispostos a ouvir, existe um plugin, blá, blá, blá, está fechado. Não mova nada para ver aqui. É tudo sobre .com ninguém se preocupa com .org não há dinheiro para o Automático aí.

Eu tenho que concordar. Seja aqui ou no fórum de suporte do WordPress, parece que eles não se importam nem um pouco, embora muitas pessoas na comunidade sejam contra isso. Como o WordPress é um código aberto, gostaria de sugerir a alguém que crie uma petição a respeito desse assunto. Eu pessoalmente acredito e sugiro que o GB deve ser um plugin como o Jetpack em vez de fundi-lo no núcleo.

Na nota lateral: @karmatosed Já que você não conseguiu responder e responder minha pergunta em um dos comentários no fórum do WordPress sobre Gutenberg, eu me pergunto por que meu comentário desapareceu repentinamente. Boa jogada!

Este tópico mudou de discussão por que não há uma opção baseada em código para desabilitar Gutenberg para ataques pessoais implícitos ou diretos de contas de sockpuppet.

Agradeço que algumas pessoas se apaixonem por esse tópico e é uma pena que este tópico tenha seguido esse caminho, mas a decisão não vai mudar.

O plugin do Editor Clássico é a opção de reverter para o editor clássico em um site inteiro. Ele está sendo anunciado com destaque no próximo lançamento do WordPress 4.9.8 como uma opção de instalação agora, em preparação para o WordPress 5.0.

Se você é um construtor de sites que deseja excluir seus clientes do editor de blocos, instalar o plug-in do Editor Clássico (e contribuir com relatórios de erros ou correções ) é a melhor solução de longo prazo para garantir que o editor clássico continue disponível.

Para metaboxes, já é possível optar por sair do editor de bloco , esta API será mesclada no Core. Para CPTs, o filtro gutenberg_can_edit_post_type será renomeado quando for mesclado (provavelmente para block_editor_can_edit_post_type ou algo dessa natureza), mas também estará disponível como uma opção baseada em código.

Para evitar que esse tópico fique mais lento, vou bloqueá-lo.

Todos os envolvidos nesta discussão são absolutamente bem-vindos para continuar participando da preparação de Gutenberg para o WordPress 5.0, mas esteja ciente de que ataques pessoais não são bem-vindos e resultarão no bloqueio de problemas ou no banimento de contas.