Gutenberg: ¿Una forma de deshabilitar el editor de Gutenberg en el código?

Ver también:

• 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/

Hola, @aduth actualizó el título para que tenga más sentido, buscando opciones de código :) gracias

Creo que esta sería una función muy útil para muchos desarrolladores. De hecho, iría tan lejos como para sugerir que creo que Gutenberg solo debería estar activo en nuevas instalaciones de WordPress que sean de la versión 5.0 en lugar de estar activo en sitios que están actualizando a la versión 5.0 de WordPress, cuando ocurre la fusión en el núcleo.

Si esto se combina con una forma de activar / desactivar en el código, los desarrolladores podrían activarlo cuando estén listos.

¿Podría explicar por qué necesita lograr esto a través del código?

Si se trata de un problema de visibilidad / control del cliente, siempre puede instalar el complemento mencionado anteriormente como un "complemento obligatorio": https://codex.wordpress.org/Must_Use_Plugins

Debido a que un cambio de código es rápido y fácil (habilitar un complemento es 1) no es mi código y 2) no es tan simple como agregar un código, agregar a la lista de dependencias no es una forma práctica ni sensata de abordar este problema.

Definir una constante puede ser su código, pero la lógica que opera en dicha constante no sería tanto su código como el complemento "Classic Editor" mantenido oficialmente.

Debo aclarar que no estoy tratando de ser argumentativo, sino de tener una mejor comprensión de por qué estos enfoques son atractivos, asegurándome de que existan suficientes opciones, sin ofrecer tantas como para ser excesivo mantener.

¿Por qué la funcionalidad del complemento no puede ser parte del núcleo? Solo preguntando porque tengo curiosidad :)

Me gustaría reflejar la necesidad de poder activar / desactivar el editor de Gutenberg. Mi situación particular es que uno de mis sitios de WordPress se basa en un tema que tiene un editor personalizado (por ejemplo: Avia Editor en el tema Enfold).

Cuando Gutenberg está habilitado, el flujo de trabajo de nuestros editores cambia. Deben ir a Todas las publicaciones> o Páginas> y hacer clic en "Editor clásico" y luego presionar el botón del Editor de diseño avanzado, que invoca el Editor integrado del tema en lugar de simplemente presionar "Editar" en la página que desean editar. o desde la página de vista previa. Necesitamos este editor porque la apariencia de nuestro sitio está estandarizada en torno a las plantillas que creamos con ese editor.

Si bien el proceso parece trivial para la mayoría, el cambio de flujo de trabajo para decenas de editores causaría algunos problemas de soporte.

Mis 2 centavos.

Creo que la diferencia es sólo "psicológica". Tenerlo en Core significa que lo tendremos indefinidamente, lo que perjudica la adopción de Gutenberg, donde tenerlo como complemento significa que lo apoyaremos durante algún tiempo (creo que Matt dijo varios años) y en algún momento dejaríamos de hacerlo.

No sé si esto debe dividirse en un problema separado o no, pero me gustaría expresar mi apoyo a la idea de @wpmark de habilitar solo Gutenberg para nuevas instalaciones de WordPress 5.0 y ofrecerlo como una opción para las personas al actualizar (a menos que se utilice el complemento Classic Editor o alguna otra función de "deshabilitación").

Si desea leerlo, mi razón fundamental para esto se da en una publicación de blog que escribí y es una combinación del gran cambio en la interfaz de usuario para mis clientes y los cambios de código que podrían ser necesarios para admitir Gutenberg correctamente el caso de mis clientes puede que no haya presupuesto para).

Parece que Gutenberg será genial para las personas nuevas en WordPress que instalan un nuevo blog y se ponen en marcha. Y será genial para las personas que se actualicen y piensen "Bien, nuevo editor, lo tendré, por favor". Pero para otros será un gran impacto. Y en algunos casos de uso, GB puede no ser una buena interfaz para editar un tipo de publicación personalizada, o los "bloques" pueden no ser un buen modelo de datos para la información que se está editando.

También se siente que las voces de los desarrolladores y propietarios de pequeñas empresas deben ser escuchadas sobre este tema. Conozco muchas tiendas pequeñas de desarrollo de WordPress y este cambio va a ser doloroso por todas las razones descritas en la publicación de mi blog. No he escuchado a ningún desarrollador o agencia pequeña decir que la habilitación automática de GB para sitios actualizados sea una buena idea. He escuchado a muchos retroceder ante la idea.

Este tipo de usuario de WordPress (y las tiendas de desarrollo como la mía son grandes partidarios y defensores de WordPress, por lo que realmente esperamos que escuche) entiende bien a sus usuarios, sabemos en profundidad lo que hemos construido en WordPress y si es o no. encajará bien en la interfaz de usuario de GB sin modificaciones, y NECESITAMOS la capacidad de gestionar este cambio en nombre de nuestros clientes.

Sé que podemos instalar el complemento Classic Editor, y es posible que debamos hacerlo para eliminar la posibilidad de que nuestros clientes habiliten GB. Y si GB resulta ser opcional para los sitios actualizados, naturalmente implicaría tener un código para deshabilitarlo en el núcleo. ¡Eso haría feliz a @ smp303 (y a otros que quieren una forma de deshabilitarlo en el núcleo) también!

Espero que las opiniones de los desarrolladores y las pequeñas empresas de WordPress como la mía se escuchen a medida que se produce el plan para fusionarse en el núcleo. Nuestros medios de vida pueden verse afectados por este cambio y algunas personas sienten que este cambio se les impone demasiado rápido. Bríndenos más opciones para administrar la transición y tenga en cuenta que GB no será lo correcto para todos cuando se agregue por primera vez al núcleo.

Un filtro en el núcleo de WP o una constante para wp-config.php, parecen dos opciones sólidas para poder tener.

Haciendo eco de @rosswintle y su excelente publicación de blog vinculada anteriormente: somos una de las muchas agencias que usan campos personalizados, metaboxes (ACF en particular) para brindar una experiencia de edición realmente rica. "WordPress como plataforma" era la promesa, y eso es lo que todos hemos estado haciendo durante los últimos años.

Tiene que haber una forma de habilitar Gutenberg para aquellos que lo quieran, pero no imponerlo para aquellos que no. Soy razonablemente fácil sobre si esto sucede en el código o mediante un complemento; en realidad, como alguien que mantiene más de 50 sitios de WordPress usando una consola de administración, una instalación masiva de complementos para deshabilitar Gutenberg tendría más sentido práctico (aunque menos geek), pero meh, siempre que se pueda hacer. Incluso una opción de configuración en el tablero estaría bien, en mi opinión, un valor predeterminado de "Gutenberg: apagado" incluso mejor ...

El punto de Ross sobre los sitios retroactivos con Gutenberg también es válido. Prácticamente cualquiera que cree para los clientes sabe que la gran mayoría gasta su presupuesto en el lanzamiento y luego no tiene ningún presupuesto después de eso. Modernizar Gutenberg, volver a capacitar a los clientes, una interfaz diferente: pensar que cualquiera pagará por esto, aparte de los desarrolladores y propietarios de negocios, es una tierra de fantasía.

Me gustaría hacerme eco de los sentimientos de @ smp303 , @dmje y @rosswintle.

Ser capaz de poner una acción simple en functions.php para deshabilitar Gutenberg parece la cosa más simple y obvia de hacer.

No puedo evitar sentir que se ha adoptado el enfoque del complemento para que sea un poco más difícil de lo necesario evitar a Gutenberg.

Sé que el equipo central se ha esforzado mucho en Gutenberg, pero su éxito debe estar determinado por sus méritos, no por limitar la capacidad de evitarlo. Además, piense en los desarrolladores de WP que tienen que desarrollar para un editor completamente nuevo, aprender a reaccionar y aún desarrollar y mantener material heredado: la sobrecarga es ENORME.

También me gustaría repetir esto; también me gustaría tener la opción de deshabilitar el editor Gutenberg a través del código y no a través del complemento.

Vea también este ticket de Trac que se creó y ahora está cerrado como wontfix : # WP43068

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

No creo que estemos apoyando una constante para esto, y en su lugar simplemente dirigiremos a las personas hacia el complemento y tal vez un contenedor mu-plugin para él, simplemente porque el complemento existente no es solo un interruptor, va para involucrar el uso de código que no está en el núcleo.

WordPress ha estado tratando de alejarse de las constantes, ya que son muy difíciles de cambiar más adelante "Oh, quiero Gutenberg, ¿por qué está deshabilitado? Oh, mi complemento de SEO aleatorio (o ex desarrollador) pensó que no lo haría lo quiero y lo desactivé a la fuerza, genial ... ahora, ¿quién puedo arreglar esto por mí? "(usuario final)

Puedo ver por qué algunas personas querrían deshabilitarlo, pero no veo la necesidad de hacerlo de esa manera.

Creo que podemos cerrar esto con seguridad como wontfix , eso puede cambiar más adelante (y lo volveremos a visitar entonces), pero no espero que lo haga.

Gracias a todos por los comentarios. Entiendo que existe cierta controversia sobre la decisión de requerir el complemento Classic Editor para deshabilitar el editor de bloques por completo, así que me gustaría conversar sobre las distintas opciones.

En los próximos años, el concepto de "bloque" para administrar los datos del sitio se convertirá en el método principal para pensar, diseñar, interactuar y editar los datos. El editor de bloques que viene en WordPress 5.0 es el primer paso importante en esa dirección, el enfoque de personalización de Gutenberg de este año es el siguiente paso, junto con el tema de Gutenberg.

Por supuesto, no todos estarán 100% listos para el editor de bloques cuando se lance WordPress 5.0. Esa es una realidad práctica que todos conocen y no queremos dejar a las personas sin una forma viable de actualizar a WordPress 5.0. Con eso en mente, existen algunas formas diferentes de deshabilitar Gutenberg, según su caso de uso particular.

Si registra metacajas que no funcionan con el editor de bloques, podrá marcar fácilmente

De manera similar, existe una discusión sobre la adición de una bandera similar para los CPT (# 2457), de modo que los CPT que no requieren la funcionalidad del editor de bloques puedan optar por no participar.

Estos son los dos casos de uso principales a largo plazo para deshabilitar el editor de bloques: situaciones en las que no funciona o no se ajusta a los patrones de uso.

Con estas cosas en mente, pensemos en los próximos años de cómo WordPress potencialmente evolucionará (tenga en cuenta que estoy mirando una bola de cristal aquí; las cosas en esta lista no necesariamente sucederán en este orden, período de tiempo o incluso en absoluto, es solo un escenario potencial que dependerá mucho de cómo termine la versión de WordPress 5.0).

• El Personalizador utiliza el concepto de bloque para todo. Para el 99% de los sitios nuevos, los bloques son lo único que se necesita para crear sitios completos. La manipulación de bloques es cómo se construyen los sitios.
• Los nuevos temas evolucionarán alrededor de sitios de construcción completamente a partir de bloques. La experiencia de usuario estándar de WordPress está construida con bloques.
• Al mismo tiempo, wp-admin comenzará a adoptar la interfaz de la aplicación JavaScript que trae Gutenberg. Por supuesto, todavía es posible cambiar al editor clásico, pero no coincide con el resto de la interfaz de WordPress.

Reiteraré que esto es en el transcurso de varios años, habrá complementos como Classic Editor para restaurar las interfaces más antiguas, pero no necesariamente será posible que esas interfaces se mantengan en Core. Si bien sería una opción razonable deshabilitar el editor de bloques en WordPress 5.0, estaría haciendo un flaco favor a sus clientes si llegara a WordPress 5.5 o 6.0, y todavía estuviera usando el Editor clásico. Para elegir un ejemplo, por mucho que las mejores prácticas de diseño de sitios hayan evolucionado desde diseños de tablas hasta varias iteraciones de diseños de CSS, y ahora los diseños de cuadrícula, las mejores prácticas de desarrollo de WordPress también evolucionan.

Entonces, para volver a la pregunta original, una sola opción basada en código para deshabilitar el editor de bloques no es una solución viable a largo plazo, no se puede expandir para brindar opciones apropiadas para el futuro desarrollo de WordPress Core, realmente no hace ningún favor a todos los presentes si creáramos esta opción. Sin embargo, el complemento Classic Editor puede seguir evolucionando para adaptarse a cualquier paradigma que traiga el futuro. Proporciona un entorno más relajado donde se puede desarrollar específicamente para satisfacer las necesidades de las personas que lo requieran, en lugar de tener que adaptarse a las necesidades más generales de todo el mundo de WordPress.

El problema con el editor de Gutenberg no son los bloques o el concepto de bloques, es que el editor en sí no es bueno. Actualmente, es muchas veces más confuso que el editor existente, que, en sí mismo, está muy lejos de ser perfecto. Y, a medida que nos acercamos al final del tiempo (¿se espera en abril, supongo?) Y la gente expresa más y más preocupaciones, la retroalimentación nunca es "tienes razón, así es como planeamos abordar eso" es tal como lo has hecho arriba "bueno, esto está sucediendo, así que mejor sube a bordo".

El interés en desactivar Gutenberg, al menos mi interés, no es el futuro de los bloques frente a los widgets y la hoja de ruta a largo plazo del personalizador, es que el editor real realmente apesta. No quiero usarlo. Mis clientes no quieren consumir. No es nada agradable de usar. Y, la razón por la que no es muy buena, es el concepto básico de que cada párrafo y fragmento de texto es un "bloque" y todos odiamos eso.

Esa es la razón por la que queremos desactivar esto. Ir a Gutenberg es, para muchos, una experiencia muy desagradable y profundamente preocupante tanto para los clientes como para el desarrollo.

No me importa la hoja de ruta futura. Me preocupa perder a mis clientes y mi negocio y hasta ahora nadie en el equipo de Gutenberg parece compartir esa preocupación. ¿Qué se supone que debemos hacer cuando la plataforma central de nuestros ingresos avanza a toda máquina en una dirección que no queremos ir? ¿Y qué se supone que debemos hacer cuando se dejan de lado nuestras preocupaciones en nombre de "la hoja de ruta del futuro"?

Estoy totalmente a favor de reemplazar widgets, inserciones y códigos cortos en un sistema de bloques universal. Creo que es una buena idea, estoy detrás de ella. Me gusta intentar que los usuarios tengan más control sobre el diseño de su sitio, ¿por qué no?

Estoy preocupado porque la herramienta de creación de contenido actual es, actualmente, un desastre que ni uno solo de mis clientes (más de 300) quiere usar. De hecho, lo ven con horror, y todas las pequeñas demostraciones y videos de YouTube y las charlas grabadas de WordPress solo les muestran cuánto lo odian.

¡No quieren escribir en bloques! ¡No quieren un editor basado en bloques! Todos odian eso, quieren que funcione como MS Word o Google Docs, porque eso es lo que normalmente usan para escribir cosas. Eso es lo que quieren.

¿Cómo puedo darles eso cuando todo lo que WordPress quiere hacer es empujar bloques por sus gargantas?

La única alternativa que tengo es apagar Gutenberg. Entonces, quiero un método confiable para hacerlo. Por lo menos hasta que este tren de desarrollo entre en razón y cree algo que realmente vale la pena usar, no como un mecanismo de bloqueo sino como un maldito editor.

Necesito un editor funcional donde el texto NO se base en bloques. ¿Cuándo Gutenberg proporcionará eso? Responde eso y te diré que ya no necesitamos una forma de desactivar Gutenberg. Hasta entonces, tenga un poco de empatía real y se preocupe por los millones de usuarios y empresas de WordPress y proporcione una manera de apagar Gutenberg en la que podamos tener fe, eso significa código, no otro complemento.

Es necesario que haya una forma de desactivar Gutenberg desde el nivel de código. Por favor, háganos esa cortesía. No dé otra respuesta trivial, solo denos una manera de apagar la maldita cosa si todo sale de lado.

@pento , durante años hubo una opción fácil por usuario para desactivar tinymce, y aunque gran parte del desarrollo era específico de tinymce, nadie había sugerido que la opción se eliminaría.

Todavía no escuché a nadie sugiriendo eliminar esa opción como parte de gutenberg, y no tiene mucho sentido para mí que puedas pasar de gutenberg a un editor basado en texto sin poder seguir usando el tinymce actual. Teniendo en cuenta que tinymce aún tendrá que ser compatible como parte del widget de texto y la API wp_editor, no tiene ningún sentido de desarrollo o interfaz de usuario obligar a las personas a instalar complementos para exponer las API principales mantenidas activamente.

Incluso si por alguna razón no desea cambiar esa opción de usuario para incluir la configuración relacionada con gutenberg, desde un punto de vista de desarrollo de software, siempre que vaya a admitir la desactivación de gutenberg, debe ser una API que sea parte de gutenberg y se mantenga como parte de su desarrollo. Como muestra el complemento importador, incluso los complementos "centrales" se desincronizan y se vuelven inutilizables principalmente porque no forman parte del desarrollo central real.

Negarse a mantener una API de este tipo como parte del núcleo significa que no hay ningún compromiso para permitir que las personas deshabiliten gutenberg incluso en 5.1, una versión que probablemente será en 2018. No se puede esperar que las personas puedan hacer planes a mediano plazo con tales incertidumbre.

@pento Gracias por la respuesta larga y detallada. No creo que esto sea solo un problema sobre CÓMO deshabilitar Gutenberg, sino también sobre si y cómo se habilitará de forma predeterminada. Creo que tu respuesta cubre ambos pero también me preocupa.

Por mi parte, estoy muy sorprendido de que la implicación tanto aquí como en otros lugares es que el editor clásico se eliminará de WP y el complemento "Classic Editor" lo agregará nuevamente. ¿Es esto un entendimiento correcto? Esto me parece una muy mala idea, pero no puedo explicar por qué en este momento.

@markkap también hace un buen punto sobre el widget de texto y wp_editor API: ¿cómo se mantendrán en el núcleo si se elimina TinyMCE?

Y editar el código meta_box / CPT para evitar la carga de Gutenberg está bien, pero en realidad, soy un autónomo solitario que probablemente construye alrededor de 60-80 sitios para clientes. No voy a editar todo ese código y muchos de esos pequeños clientes no querrán pagarme por hacerlo. Preferiría MUCHO que esto sea opt-in que opt-out: Gutenberg debería estar encendido cuando declaro que lo apoyo. El valor predeterminado aquí es, nuevamente, al revés. Estás obligando a las personas a hacer un cambio para evitar que las cosas cambien o se rompan (me complace plantear un problema por separado para esto si es necesario).

estaría haciendo un flaco favor a sus clientes si llegara a WordPress 5.5 o 6.0, y todavía estuviera usando el Editor clásico

(También usando mi bola de cristal) No creo que esté necesariamente de acuerdo con esto. Creo que es imposible decir que Gutenberg y los bloques serán una mejor experiencia de edición para todos los casos de uso en el futuro.

También me encuentro un poco confundido aquí acerca de la naturaleza de los "bloques". Esto es probablemente una cuestión de terminología, pero implica que una o más de las siguientes son ciertas:

• Hay un cambio de paradigma que estoy luchando por hacer o he entendido mal algo
• El nuevo paradigma no se comunica muy bien
• Las formas en que los desarrolladores como yo utilizan WordPress para crear herramientas de gestión de contenido para los clientes no se comprenden bien
• Las formas en que desarrolladores como yo utilizan WordPress para crear herramientas de gestión de contenido para los clientes se comprenden bien y se ignoran.

Has dicho:

En los próximos años, el concepto de "bloque" para administrar los datos del sitio se convertirá en el método principal para pensar, diseñar, interactuar y editar los datos.

Esto me asusta un poco y volveré a eso.

La página de Gutenberg en https://wordpress.org/gutenberg no parece estar de acuerdo con esta descripción. Llama a los bloques "bloques de contenido" y explica que:

[bloques] son ​​una forma unificada de diseñar contenido

_Nota: Soy un desarrollador de back-end y pienso mucho en términos de datos: qué datos existen en un sistema, qué propiedades tienen los elementos de datos, cómo se relacionan los elementos de datos y cómo se consultan y manipulan los datos.

Tengo entendido que los "bloques" son secciones de contenido que se pueden utilizar para incluir una publicación, una página, lo que sea. Se almacenan principalmente dentro del contenido de la publicación en la base de datos utilizando comentarios HTML para compatibilidad con versiones anteriores, pero también puede configurar bloques para guardar datos en otros lugares como post_meta. (Nota: esto _ se siente_ como un truco para mantener felices a las personas como yo al poner metadatos en bloques; no se siente como una decisión de diseño bien pensada sobre la naturaleza de los bloques)

Tu implicación en lo que dices es que los bloques deben impulsar _todo_. Son cómo se administrarán los "datos del sitio". Esto, y otras cosas que ha dicho, implican que los bloques no son solo secciones de contenido, sino algún tipo de dispositivo de interfaz de usuario que se puede conectar a cualquier cosa: opciones del sitio, personalizaciones, metadatos sobre publicaciones, widgets, menús, campos de perfil de usuario, todo.

Entonces creo que necesitamos una aclaración sobre la naturaleza de un "bloqueo".

Si lo que está insinuando es correcto, creo que esto representa un malentendido fundamental de cómo personas como yo usan WordPress. Y creo que este enfoque será lo que me empuje a bajarme del tren de WordPress y encontrar un CMS alternativo para algunos proyectos. WordPress será para blogs y revistas, pero muchas de las oportunidades que presentan los tipos de publicaciones personalizadas desaparecerán.

Los metadatos en WordPress son como se describe: datos sobre datos. Es información que otorga propiedades adicionales a elementos de contenido. Los metadatos NO son contenido. Y, en mi opinión, no es adecuado para ser colocado en "bloques" como yo los entiendo. Algunos de los tipos de publicaciones que creo no tienen más contenido que un título: solo tienen propiedades / campos / metadatos.

Si lo que describe aquí es cierto, entonces me pregunto por qué el estado de la publicación no es un bloqueo. ¿Por qué no son bloques de categorías y etiquetas? ¿Por qué el extracto no es un bloque?

Yo, personalmente, no creo que estos sean "bloques" como los entiendo porque no son contenido, son información sobre el contenido. Su ubicación en la interfaz de usuario es importante. La forma en que el usuario interactúa con estos bits de información es importante.

Algunos de los post_meta que creo son iguales.

Creo que me gustará Gutenberg y los bloques para crear publicaciones y páginas. Pero o entiendo mal los "bloques" o el proyecto ha entendido mal cómo la gente usa los datos que no se adaptarán a los "bloques".

Estoy feliz de que esto se aclare y estoy dispuesto a que me persuada. Pero tener bloques como "el método principal para pensar, diseñar, interactuar y editar datos" no parece encajar con las cosas que construyo en WordPress.

Y, volviendo al problema principal aquí, es por eso que no creo que el editor clásico deba eliminarse del núcleo, y es por eso que no quiero que mis usuarios activen automáticamente Gutenberg cuando los actualice a la v5. .0.

@rosswintle, lo ha resumido absolutamente perfectamente en todos los sentidos y casi todos los desarrolladores con los que he hablado sienten lo mismo. Solo espero que alguien esté escuchando estas preocupaciones y podamos encontrar una solución para todos.

Agregar mi +1 para hacer de Gutenberg la experiencia de edición predeterminada solo para nuevas instalaciones.

Como ha dicho @rosswintle , hay cientos de miles de desarrolladores de WP con clientes que no estarán interesados ​​en pagar el tiempo para volver al editor clásico. Deje que los sitios existentes continúen como están (por supuesto, haga que el nuevo editor esté disponible, pero también cambie si no es como esperaban) y despliegue Gutenberg con nuevas instalaciones.

Piense en todos los propietarios de pequeñas empresas con sitios WP. Sitios que se desarrollaron hace años que están funcionando bien sin ningún desarrollo nuevo. De repente, estos usuarios se ven obligados a Gutenberg y no solo necesitan aprender una nueva interfaz (estos usuarios pueden no ser muy expertos en tecnología en primer lugar y Gutenberg puede o no ser más intuitivo para ellos) sino que podría prevenir ellos de editar el contenido de su sitio.

También hay que considerar la reputación de WordPress, donde todavía estamos tratando de quitarnos la opinión de que WP está lleno de vulnerabilidades de seguridad. @wpmark y yo incluso tuvimos una conversación aleatoria con alguien a principios de semana en la que una de las primeras cosas que mencionaron una vez que supieron que desarrollamos con WordPress fue "cómo se protegen sus sitios".
¿Existe el riesgo de que los usuarios encuentren que sus sitios están dañados o sea difícil trabajar con ellos? ¿Cómo afectará eso a la reputación de WP en los próximos años?

Definitivamente creo que los sitios nuevos deberían estar habilitados para Gutenberg, y esta puede ser una gran característica que se grita desde los tejados durante la instalación de 5 minutos, pero deje que los sitios heredados continúen como están.

No quería que la cuestión de activar Gutenberg solo para nuevas instalaciones se perdiera en esta preocupación también válida sobre la facilidad de desactivación. Aquí hay un problema específico https://github.com/WordPress/gutenberg/issues/4423

Agregue sus pensamientos, votos y comentarios a ese. @joffff @wpmark @rosswintle @markkap @dmje

Spot en @rosswintle.

Gutenberg debería estar encendido cuando declaro que lo apoyo. El valor predeterminado aquí es, nuevamente, al revés. Estás obligando a las personas a hacer un cambio para evitar que las cosas cambien o se rompan (me complace plantear un problema por separado para esto si es necesario).

No podría estar más de acuerdo con esto si lo intentara. No creo que los chicos y chicas que empujan a Gutenberg entiendan esto.

Solo para agregar a lo que Ross ha dicho desde un ángulo empresarial (cubrió bien el lado de los pequeños autónomos): los sitios que administro para un PLC multinacional son como petroleros. Los cambios fundamentales como este tardan mucho en implementarse. Deben realizarse pruebas e incluso entonces, deben incluirse en un programa de lanzamiento semanal, que es parte de un proceso detallado de revisión y aprobación del código.

Esto va a causar un gran dolor de cabeza para mí y para mi equipo. De hecho, lo más probable es que terminemos con 4.9.x hasta que podamos verificar a fondo el impacto de Gutenberg después de que se haya lanzado el RC final para 5.0.0. Esto podría llevar semanas o incluso meses. Esto no es un arreglo rápido.

También me encuentro un poco confundido aquí acerca de la naturaleza de los "bloques". Esto es probablemente una cuestión de terminología, pero implica que una o más de las siguientes son ciertas:

• Hay un cambio de paradigma que estoy luchando por hacer o he entendido mal algo.
• El nuevo paradigma no se comunica muy bien.
• No se comprenden bien las formas en que los desarrolladores como yo utilizan WordPress para crear herramientas de gestión de contenido para los clientes.
• Las formas en que los desarrolladores como yo utilizan WordPress para crear herramientas de gestión de contenido para los clientes se comprenden bien y se ignoran.

Absolutamente siento que es lo último. No tengo ninguna duda de que los miembros del equipo de Gutenberg saben y entienden cómo la mayoría de los desarrolladores profesionales construyen sitios usando WordPress.

Sin embargo, ese enfoque es totalmente incompatible al mover WordPress hacia un enfoque de creador de sitios, que Automattic lo necesita para que WordPress.com continúe compitiendo contra empresas como Squarespace, Wix et al.

WordPress no puede ser un creador de sitios y un CMS profesional al mismo tiempo. Simplemente no se puede hacer. Ha caminado por una delgada línea entre los dos, lo que permite a los usuarios moverlo en cualquier dirección a través de complementos. (Hacia la construcción de un sitio usando Beaver Builder, Divi et al y hacia un CMS profesional con complementos como ACF y CMB). Sin embargo, ahora está claro que el CMS se está moviendo firmemente en la dirección de los constructores de sitios. Malditos sitios que usan campos personalizados.

Finalmente, su punto sobre los bloques y la base de datos es acertado.

Creo que es indicio de muchos problemas que el equipo de WordPress debería abordar primero antes de mirar cosas como Gutenberg:

• Actualización de la versión mínima de PHP
• Implementar datos semánticos nativos (a través de campos personalizados) y modificar la estructura de la base de datos para dar cuenta de ellos.

Como nota final, los chicos de Statamic han demostrado cómo debería haberse manejado esto con su nuevo tipo de campo Bard. Una interfaz de editor opcional que resuelve los mismos problemas que Gutenberg, pero de una manera mucho más inteligente y menos disruptiva.

No tiene sentido que repita mis opiniones, ya se han expresado anteriormente. Estoy de acuerdo con el consenso general: debería ser una opción considerada para permitir que Gutenberg no sea obligatorio en el paso de 4.xa 5.0.

Como la mayoría de los desarrolladores aquí, atiendo a varios clientes, algunos muy expertos en tecnología, otros no tanto, pero supongo que empujarlos en esta dirección solo causará confusión a la mayoría.

En términos de cualquier cosa que pueda romperse; desde la perspectiva de un cliente, ya ha creado y gastado un presupuesto para la solución proporcionada, no van a apreciar que pueden necesitar otro presupuesto para soporte o para solucionar problemas causados ​​por algo que no es de mi creación o de ellos.

Entre el desarrollador / diseñador o proveedor de la solución cuidadosamente considerada que se les entrega, el cliente y el proveedor, deben elegir cuándo habilitar un cambio tan importante sin tener que cumplir con algo obligatorio.

Solo para tirarlo por ahí. Aunque WordPress no sigue estrictamente el enfoque de control de versiones semántico, la versión 5.0.0 es un cambio radical.

Si Automattic no está dispuesto a cambiar su estrategia con respecto a Gutenberg, y seamos honestos, eso sería lo correcto, entonces la única otra opción es hacer 4.9 una versión LTS.

De esa manera, los parches de seguridad podrían aplicarse a 4.9 durante los próximos, digamos, 5 años. Eso es tiempo de sobra para que los desarrolladores de sitios web migren sus sitios a Gutenberg o se alejen de WordPress por completo (que sospecho que será la opción más popular).

Bueno, a todo el mundo le gusta escribir comentarios largos aquí. 😉 Es de noche para mí, así que no me ocuparé de todo, pero me gustaría abordar algunos temas.

Por mi parte, estoy muy sorprendido de que la implicación tanto aquí como en otros lugares es que el editor clásico se eliminará de WP y el complemento "Editor clásico" lo agregará nuevamente. ¿Es esto un entendimiento correcto?

Eso no es correcto. Mencioné en mi comentario anterior que los metaboxes y los CPT pueden volver al Editor clásico automáticamente; no podrían hacerlo si se eliminara el código del Editor clásico. 🙂

Gutenberg utiliza TinyMCE para impulsar los bloques de texto editables, eso no va a ninguna parte. Funciones como wp_editor() pueden mantener con relativa facilidad en Core sin necesidad de moverlas a un complemento; esperaría que continúen funcionando indefinidamente.

Su implicación en lo que dice es que los bloques deben impulsar todo. Son cómo se administrarán los "datos del sitio". Esto, y otras cosas que ha dicho, implican que los bloques no son solo secciones de contenido, sino algún tipo de dispositivo de interfaz de usuario que se puede conectar a cualquier cosa: opciones del sitio, personalizaciones, metadatos sobre publicaciones, widgets, menús, campos de perfil de usuario, todo.

Eso es exactamente lo que estoy diciendo. Bueno, los metadatos no son un bloque, aunque podrían informar cómo se usa o se muestra un bloque.

Entonces creo que necesitamos una aclaración sobre la naturaleza de un "bloqueo".

Por supuesto. Un bloque es un trozo de HTML que encaja con otros bloques. Hay un montón de API que hacen que trabajar con bloques sea agradable y fácil, pero a eso se reduce todo.

Un bloque _no es_:

• Un trozo de HTML almacenado en post_content (aunque algunos bloques usan ese método de almacenamiento).
• Estático (aunque algunos bloques lo son).
• Generado dinámicamente (aunque algunos otros bloques lo son).

@rosswintle , mencionaste metadatos varias veces y me gustaría aclarar a qué te refieres allí. ¿Podría darme algunos ejemplos de lo que considera metadatos?

Si lo que describe aquí es cierto, entonces me pregunto por qué el estado de la publicación no es un bloqueo. ¿Por qué no son bloques de categorías y etiquetas? ¿Por qué el extracto no es un bloque?

Solo una sugerencia y no estoy seguro de si es o debería ser una opción de tema, pero ¿por qué no en add_theme_support () ya que la mayoría de las funciones desarrolladas recientemente lo han sido en el pasado?

De esa manera, los parches de seguridad podrían aplicarse a 4.9 durante los próximos, digamos, 5 años.

Dado que WordPress 3.7 se lanzó hace poco más de 3 años, y su versión de seguridad más reciente fue hace 6 semanas, creo que es razonable suponer que WordPress 4.9 recibirá parches de seguridad durante mucho tiempo.

@eirichmond : add_theme_support() podría ser necesario para el enfoque de personalización de Gutenberg, pero la mayoría de los temas admitirán contenido basado en el editor de bloques sin ninguna modificación.

add_theme_support () puede ser necesario para el enfoque de personalización de Gutenberg, pero la mayoría de los temas admitirán contenido basado en el editor de bloques sin modificaciones

@pento ¿Cuál es exactamente el enfoque de personalización de Gutenberg, por favor? Qué significa eso? Mencionas que la mayoría de los temas admitirán contenido basado en bloques, ¿puedes indicar por qué un tema no lo admitiría?

Veo temas con barras laterales que no admiten ciertos bloques porque el bloque indica que es de ancho completo, por ejemplo, imagen de portada.

¿Cuál es exactamente el enfoque de personalización de Gutenberg, por favor? Qué significa eso?

Matt habló sobre esto en el Estado de la Palabra - los tres enfoques para este año son:

• Editor de Gutenberg
• Personalización de Gutenberg
• Tema de Gutenberg

El editor de Gutenberg es lo que viene en WordPress 5.0. La personalización de Gutenberg recién está comenzando a ponerse en marcha y está analizando la personalización del sitio y cómo funciona eso en el paradigma de bloques. El tema de Gutenberg será el tema predeterminado de este año y probablemente se pondrá en marcha más adelante en el año.

¿Puede indicar entonces por qué un tema no lo apoyaría?

Con suerte, todos los temas funcionarán. 🙂 Algunos bloques tienen algo de CSS asociado (las imágenes de portada son un buen ejemplo), por lo que existe la posibilidad de que algo no se vea exactamente bien. Sin embargo, no hay nada que pueda hacer que un tema deje de funcionar.

¿Puedo recordarle a la gente que Gutenberg no es un proyecto de Automattic, no devalúe los esfuerzos y el trabajo de los no automáticos que contribuyen

Tampoco tengo claro por qué un complemento no es suficiente, los argumentos que he visto argumentan que a la gente no le gusta Gutenberg, o que ya tienen un flujo de trabajo configurado, todos los problemas que se han mencionado antes y todo solucionado. instalando y habilitando el complemento del editor clásico.

Tenga en cuenta que también existe un precedente en el complemento de enlaces.

Pero de todos modos, seamos constructivos:

Actualicé a WP 5.0 y Gutenberg reemplazó mi editor personalizado / no me gusta / necesito más tiempo con los clientes

¿Qué debo hacer?

Instale el complemento del editor clásico y habilítelo, problema resuelto. Ahora Gutenberg se reemplaza con el editor clásico que tenemos en 4.9

¿Desventajas?

No obtendrá ninguna de las funciones más nuevas de Gutenberg, y es posible que las funciones nuevas en el futuro no tengan sentido en el editor clásico. Por ejemplo, si los bloques de filas y columnas llegaron en 5.1, no veo cómo eso tiene sentido en el editor clásico

Tengo muchos sitios de clientes, no estoy instalando y activando en todos los sitios, ¿qué pasa si un cliente se desactiva?

Úselo como un complemento MU:

• Coloque la carpeta del complemento en wp-content/mu-plugins
• Coloque un archivo en su carpeta mu-plugins que contenga lo siguiente:

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

Ahora el complemento siempre está cargado y no se puede desactivar. No se requieren pasos adicionales además de colocar los archivos. Luego puede cargar el archivo y la carpeta en cada sitio una vez y no tener que preocuparse por eso nuevamente.

Lecciones del complemento Classic Editor

Hay muchas funciones útiles en este complemento para cosas como detectar si Gutenberg está activado, y la mayor parte consiste en eliminar ganchos y reemplazarlos.

Incluso agrega un área de configuración con una opción para optar por los 'enlaces del editor clásico' para que, en lugar de reemplazar a Gutenberg, obtenga lo que ve con el complemento gutenberg activado del enlace del 'editor clásico' en la pantalla de publicaciones, de modo que te da 3 opciones, no 2.

Recomiendo encarecidamente a las personas que echen un vistazo al complemento, lo prueben y vean cómo está construido.

Recuerde, somos una comunidad, no los sujetos de un equipo de productos Automattic. Si se rompe, tenemos un ciclo completo de lanzamiento de WP durante el cual podemos probarlo y arreglarlo. Veo muchas partes interesadas en este hilo que tienen la habilidad técnica para arreglar el complemento y más. Si es realmente tan importante, entonces estoy seguro de que alguien dará un paso al frente, al igual que la gente que trabaja en el núcleo lo hizo

@rosswintle , mencionaste metadatos varias veces y me gustaría aclarar a qué te refieres allí. ¿Podría darme algunos ejemplos de lo que considera metadatos?

@pento Seguro:

Ejemplo de país:

Un tipo de publicación "País" que tiene un nombre (título), una descripción (contenido) y luego:

• población
• URL de la imagen de la bandera
• clasificación (y otros factores, posiblemente codificados de alguna manera)
• "comunidades" relacionadas (relaciones con publicaciones de otro tipo)

Ver: http://peoplesunderthreat.org

Ejemplo de bienes raíces:

Un tipo de "propiedad" que tiene:

• precio
• tipo
• número de habitaciones
• fecha de construcción
  etc.

Ejemplo de evento:

Un tipo de "evento" que tiene:

• fecha
• hora
• detalles de recurrencia
• ubicación
  etc

Hay muchos.

Habiéndolo habilitado y jugado un poco, tengo algunas preocupaciones importantes ... Me concentraré en la principal por ahora:

WooCommerce se rompe por completo ... como si ni siquiera estuviera allí al editar un producto. E imagino que muchos más complementos también se romperán por completo. Entonces, ¿cuál es el plan para ayudar a la comunidad a ser compatible? ¿Y cuanto tiempo tendremos?

@tomjn

Todos los argumentos que he visto argumentan que a la gente no le gusta Gutenberg, o que ya tienen un flujo de trabajo configurado

"no me gusta" es posiblemente el término incorrecto. Creo que la gente está dando buenos argumentos para que Gutenberg no sea adecuado para muchos de los casos de uso de WordPress. No es un caso de preferencia o gusto, es un caso de idoneidad.

Y los desarrolladores solo quieren opciones para hacer esto. Puedo alternar otras características importantes como la depuración, los editores de código, multisitio, actualizaciones automáticas y revisiones de publicaciones en wp-config.php. Algunas funciones se habilitan solo por temas que las admiten usando add_theme_support . ¿Por qué no podemos tener opciones en el código para alternar a Gutenberg de la misma manera para que los desarrolladores puedan usar un flujo de trabajo que se adapte a ellos para un cambio tan importante?

Uno de los problemas aquí es que los desarrolladores (no necesariamente yo, pero otros) no sienten que los escuchen mientras expresan preocupaciones sobre Gutenberg. Agregar esto como un gesto simbólico para ayudarlos te ayudaría a ponerlos de tu lado un poco más. Incluso si por alguna razón filosófica no está de acuerdo en que es lo correcto, considérelo como una rama de olivo que se puede ofrecer a los desarrolladores que no están contentos.

Tenga en cuenta que también existe un precedente en el complemento de enlaces.

El complemento de enlaces es un mal ejemplo aquí. Conservó la funcionalidad existente en el núcleo si la estaba usando y solo eliminó la funcionalidad para nuevas instalaciones (o si no la estaba usando).

ME GUSTA este precedente.

Esto es lo que se defiende en el n. ° 4423

Lo que realmente me atrapa es que los desarrolladores principales y Matt están asumiendo que todo el mundo simplemente va a adoptar completamente el concepto de "Bloques" y el editor de Gutenberg sin cuestionarlo. Supongo que todo está muy bien, pero este enfoque de "nuestro camino o el camino alto" que están usando con Gutenberg no solo no es fácil de usar, sino que puede afectar seriamente el estado de WordPress en su conjunto.

Ha habido muchas ideas realmente geniales a lo largo de los tiempos que simplemente no se mantuvieron porque simplemente no fueron adoptadas por las masas. Betamax era un formato muy superior, pero simplemente se mantuvo y VHS ganó. ¿Qué pasa si Gutenberg y los bloques simplemente no se pegan? ¿Qué pasará con WordPress entonces?

Luego está el factor de confianza. La gran mayoría de los usuarios de WordPress ni siquiera entienden qué es WordPress. Simplemente lo usan porque la marca WordPress es popular, y no importa cómo se mire, WordPress para la mayoría de las personas es solo una marca. Las marcas viven y mueren por la confianza del consumidor.

Cuando la actualización 5.0 finalmente se implemente y un millón de sitios de WordPress cambien repentinamente esto dramáticamente, ¿cómo van a reaccionar esos usuarios finales, que no siguen nada sobre el mundo de WordPress?

La mayoría de mis clientes son, como alguien dijo, "Apenas pueden encender una computadora" o simplemente quieren que lo que pagaron funcione como se prometió. Estas son las personas que confiaron en WordPress para hacer lo que prometió. Si un día esa promesa se rompe debido a un formato totalmente nuevo para administrar el contenido de su sitio, cambia repentinamente. Entonces su confianza en WordPress se romperá y la gente simplemente dejará algo si ya no confía en él.

Creo que de aquí proviene la mayor parte de la preocupación que tienen los desarrolladores. Creamos excelentes sitios personalizados de WordPress que funcionan exactamente para quienes quieren nuestros clientes y ahora todo se va a "estropear" debido a Gutenberg, y no se nos da ninguna opción para prevenir lo que podría ser un gran desastre.

El único propósito de Gutenberg es aumentar la participación de WordPress Marke, pero puede hacer exactamente lo contrario. De hecho, puede alejar a la gente de WordPress. Gutenberg podría convertirse en la nueva Coca-Cola para WordPress, y WordPress no es tan grande como Coca-Cola y podría recuperarse como lo hizo Coke. La gente pasará a otra cosa y no mirará hacia atrás.

Sigues hablando de "Impactaría el futuro de la adopción de Gutenberg, bla, bla, bla", pero es realmente así de simple. O a todos les encantará y la necesidad de eliminarlo a través de código o complemento, o lo que sea que se vuelva irrelevante, o Gutenberg se convertirá en una característica extraña que nadie realmente usa como Press This.

Tal como está ahora, la dirección que se tomará será que Gutenberg sea un éxito o WordPress en su conjunto podría fallar. Nosotros, los desarrolladores con las preocupaciones, solo estamos tratando de no estropear por completo una gran herramienta para la gestión de contenido. Sabemos mejor que nadie cómo nuestros clientes se acercan y utilizan WordPress. Los desarrolladores principales y Matt solo están analizando estadísticas y cuotas de mercado, ¿y sabes lo que nos consiguió? Los Cazafantasmas se reinician.

Realmente queremos trabajar con usted para que esto suceda, pero sería mejor si pudiéramos controlar cómo se presenta esto al mundo en lugar de forzarlo a los usuarios desprevenidos. Todo lo que pedimos es una forma de facilitar a nuestros clientes el acceso al nuevo editor. Realmente no es mucho pedir.

Si Gutenberg realmente va a ser la innovación que prometió ser, ¡genial! Todos se suben al tren de Gutenberg. Si no es así, solo pedimos la opción de no convertirlo en un gran desastre.

Es como si supieras que no va a ser bien recibido y quieres que esto suceda tanto que sientes que la única forma en que posiblemente tenga éxito es si se lo impone a todos. Es como cómo los políticos te dicen una mentira descarada sobre cómo un proyecto de ley de impuestos que beneficiará a todos para que se apruebe cuando en realidad solo los súper ricos se beneficiarán de él.

Es como lo que dijo una vez el gran Dr. Cox.

Ayudame a ayudarte.Ayudame a ayudarte.Ayudame a ayudarte.Ayudame a ayudarte.

WooCommerce se rompe por completo ... como si ni siquiera estuviera allí al editar un producto. E imagino que muchos más complementos también se romperán por completo. Entonces, ¿cuál es el plan para ayudar a la comunidad a ser compatible?

@ smp303 No es el lugar para discutir esto, pero estamos trabajando en la compatibilidad de WooCommerce + Gutenberg en este momento. Esté atento al blog de desarrollo de WooCommerce .

Quizás una mejor analogía que "New Coke" es Windows 8.

Esa fue una nueva visión audaz para una mentalidad de computación más móvil que fracasó terriblemente porque cambió demasiadas suposiciones de uso básico. Sí, en lo profundo de la configuración, un usuario podría recuperar gran parte de su experiencia previa con Windows, pero a menos que estuvieran al tanto de las revistas de tecnología, los usuarios no tenían idea de cómo hacerlo. El resultado fue una catástrofe para Windows.

Gutenberg avanza muy rápido por el mismo camino. Está haciendo un cambio monstruoso, completamente impulsado por la empresa y no por la comunidad, y está dejando (supongo que puedo ver algunos detalles sobre esto) una ruta bastante oscura a través de un complemento externo para volver al editor tradicional para aquellos a quienes no les gusta esta nueva metodología.

Creo que si Automattic / WordPress no proporciona un medio en la Configuración para deshabilitar Gutenberg para los millones de usuarios ocasionales de WordPress, lo lamentarán profundamente. Gutenberg es un cambio tremendo. Habrá MUCHOS rechazos por parte de los usuarios.

En este hilo estamos tratando de advertirle contra esto y advertirle que un complemento externo NO será suficiente. Debe proporcionar a los usuarios una "salida" a Gutenberg, aunque solo sea para permitirles un período de ajuste. Si podemos activarlo en nuestros temas existentes a través de código, posiblemente podamos evitar un desastre.

Estamos intentando, desesperadamente, ayudar aquí. Un complemento externo NO será suficiente. Es necesario incorporar una opción para volver al editor clásico. Hágalo como parte del lanzamiento o proporcione una forma de hacerlo a través de un código que podamos incluir en nuestros temas.

Desde un punto de vista lógico, estoy tratando de comprender la filosofía de permitir que los desarrolladores declaren un metabox, dentro de add_meta_box () para NO admitir Gutenberg, lo que hace que la pantalla del editor, en cualquier lugar donde se use el metabox, muestre la "versión clásica" de la pantalla del editor. Entonces, ¿por qué algunos desarrolladores se oponen a una constante definida en el archivo wp-config.php? Si puedo declarar que las cosas de Gutenberg NO se usarán en un área del código, ¿por qué no podemos declarar que se usarán en otras áreas como actualmente establecemos declaraciones de definición?

Tenga en cuenta que, para una constante, el complemento del editor clásico debería estar incluido con WordPress, con un cargador personalizado, y permanecer allí a perpetuidad. Todavía podría estar allí dentro de 10 o 15 años cuando aparezca lo que sea que Gutenberg sea reemplazado.

Incluso entonces, para aquellos que necesitan o quieren ambos editores, el complemento sigue siendo necesario de todos modos.

No olvide que aún puede instalar y configurar el complemento en v4.9 antes de la llegada de Gutenberg.

Creo que si Automattic / WordPress no proporciona

@robmcclel Automattic no es WordPress, WordPress.org! = WordPress.com, uno es una comunidad de código abierto, el otro es un servicio de pago de terceros. Automattic no lanza versiones de WordPress, WordPress no es un producto Automattic interno, y tampoco lo es Gutenberg. Hay muchos colaboradores que no son de Automattic, prospectos de lanzamiento, etc. que hacen cosas fuera de Automattic.

"Incluso entonces, para aquellos que necesitan o quieren ambos editores, el complemento sigue siendo necesario".

En realidad, de lo que se ha discutido aquí y en otros lugares, si un tipo de publicación personalizada o metabox declara que no es compatible con gutenberg, la pantalla del editor retrocede automáticamente ... sin la necesidad del complemento "Editor clásico". Este es uno de los problemas que muchos tienen con el estado actual del proyecto gutenberg, hay muchas opiniones / declaraciones sobre lo que sucede en determinadas situaciones y muchas veces esas declaraciones / opiniones difieren de otras.

Tenga en cuenta que, para una constante, el complemento del editor clásico debería estar incluido con WordPress, con un cargador personalizado, y permanecer allí a perpetuidad.

@tomjn ¡Espera! Entonces, ¿estás diciendo que todo el sistema de metabox se está eliminando del núcleo?

No, no mencioné en absoluto los metaboxes. Pero tenga en cuenta que los metaboxes existen en Gutenberg, sugerir que están siendo eliminados implica que no ha probado Gutenberg e ignora que una gran parte del ecosistema depende de ellos. Eso sería un gran problema para wordcamp.org, wordpress.org, etc.

Como referencia, no soy miembro del equipo de Gutenberg, simplemente observo y aplico el sentido común. El hecho de que trabajo en Automattic no significa que tenga poderes especiales con Gutenberg. Tengo tanto que decir como todos los demás aquí, y si quisiera cambiar eso, lo haría contribuyendo con código y solucionando problemas, como lo haría cualquier otra persona.

@tomjn Entonces, lo que dijiste no tiene ningún sentido para mí. El "Editor clásico" es básicamente una página de administración con metacajas y funcionalidad para guardar y demás. Eso significa que para poder cambiar entre Gutenberg y Classic, debe haber un código integrado en el núcleo que permita las dos opciones y todo el código para la funcionalidad Classic permanecerá en su lugar.

Eso significaría que el complemento Classic no sería más que una forma de activar el interruptor. Parece que sería mucho más fácil simplemente construir una cosa de tipo de soporte de tema o constante en el núcleo en lugar de tener que construir y mantener un complemento.

Si todo para Classic todavía está en el núcleo, ¿por qué crear un complemento solo para activarlo?

Y qué pasa si tiene que permanecer en su lugar. Ya hay un montón de código antiguo y obsoleto en el núcleo de WordPress. Un disparador Classic incorporado realmente no haría mucha diferencia en el gran esquema de las cosas.

No seamos falsos aquí Tom. Automattic es en gran medida la fuerza impulsora detrás de Gutenberg. Ninguna cantidad de "pero no lo es" de los empleados de Automattic va a cambiar el hecho de que es tan obvio como el sol en el cielo en un día despejado.

Gutenberg es en gran medida el bebé de Matt; como es Automattic. Ha impulsado el proyecto. Ha sido su mayor animador.

Gutenberg tiene serios beneficios operativos para Automattic, es decir, darle un producto para nivelar la sensación de juego con sus mayores competidores. No se puede decir lo mismo del resto de la comunidad.

Sí, muchos usuarios de WordPress usan creadores de páginas a través de complementos. Sin embargo, otra gran parte hace un uso intensivo de campos personalizados a través de complementos como ACF y CMB (y sus muchas bifurcaciones). Esa parte de la comunidad ha estado pidiendo a gritos durante años que el proyecto de WordPress implemente campos personalizados como una característica nativa.

Sin embargo, no se ha materializado porque la financiación no ha estado ahí para que esto suceda y cada vez que se menciona, ha sufrido ese problema de código abierto tan común del debate de la muerte por comité.

Muchos otros problemas de presión mucho más también han sufrido el mismo destino, como cambiar la versión min-PHP a algo que no ha estado al final de su vida útil durante más de 7 años .

Esos son solo algunos ejemplos de cosas que deberían haberse hecho hace años y que aún no se han logrado porque el principal patrocinador del proyecto no lo ha apoyado.

Automattic ha apoyado a Gutenberg, en gran parte como resultado directo de que Matt está en el asiento del conductor. Se ha dedicado una gran cantidad de horas de trabajo a hacerlo realidad. Eso se traduce en financiación directa del principal financiador del proyecto de WordPress: Automattic.

No veo cómo esto es relevante para el boleto.

@rosswintle Esto es muy relevante. Hay muchos desarrolladores que quieren una manera fácil de elegir apagar Gutenberg. Es bastante obvio que los poderes de no quieren darnos esto y hacer que sea lo más inconveniente posible apagar Gutenberg.

La fuerza impulsora detrás de esta decisión es la agenda de Matt y Automattic para aumentar su participación de mercado en el espacio del sitio web de bricolaje. Está claro que las preocupaciones de las comunidades no se están abordando debido a la influencia de Matt y Automattic sobre el proyecto. De aquí es de donde proviene el 100% de la frustración de las comunidades sobre Gutenberg.

Dado que Matt y Automattic influyeron en gran medida en la dirección del proyecto Gutenberg, es relevante en esta discusión como en todas las discusiones sobre el proyecto.

@tomjn

A partir de Gutenberg y esta próxima versión, WordPress es un producto de Automattic. Creer cualquier otra cosa es una tontería. .Com o .Org no importa: el programa WordPress ahora es un producto de Automattic. Los desarrolladores y quienes trabajan en él ahora no son más que pasantes no remunerados para Automattic.

La comunidad quiere a Gutenberg como complemento. Matt no lo hace. Matt es el director de Automattic. Matt es el líder autoproclamado para este lanzamiento. Las personas que lideran el desarrollo de Gutenberg son empleados de Automattic. Matt está forzando esto. No hay otra decisión o debate, tiene el 51% de los votos y lo está ejerciendo.

No se engañe pensando que WordPress tiene alguna forma o forma un producto democrático o comunitario. Ahora es el producto de Automattic, sin embargo, se enmarcó o comercializó en el pasado, y ahora están dirigiendo el enfoque, el ritmo y las decisiones del desarrollo.

@rosswintle , es relevante para el ticket en el sentido de que la comunidad está pidiendo métodos para apagar Gutenberg, y el equipo de Gutenberg está respondiendo que el complemento será la única forma de hacerlo, independientemente de lo que la comunidad como un gran conjunto está pidiendo.

Matt y Automattic están imponiendo su autoridad en esto. Bien podría cerrar este boleto y todos los demás, porque nuestra voz ya no es relevante más que para transmitir simpatía y darnos un lugar para desahogarnos. Es posible que este boleto ni siquiera exista.

Automattic está a cargo de esto, no la comunidad. Tenemos que afrontar eso y prepararnos para el impacto, porque esto está sucediendo y la única vía de salida es el complemento del editor clásico, e incluso eso es un poco de caridad. No habrá nada más.

Personalmente, no veo cómo discutir quién toma las decisiones aquí ayuda a avanzar en el tema. Se está desarrollando como un proyecto de código abierto, y eso significa que puede tener una voz, y animo a las personas a usar sus voces de manera constructiva ayudando a desarrollar opciones y una justificación para implementar estas opciones.

La última publicación sobre el tema de la solicitud realizada fue de @tomjn , seguida de algunas preguntas relevantes de @wpstudio y @jawittdesigns

Tenga en cuenta que, para una constante, el complemento del editor clásico debería estar incluido con WordPress, con un cargador personalizado, y permanecer allí a perpetuidad. Todavía podría estar allí dentro de 10 o 15 años cuando aparezca lo que sea que Gutenberg sea reemplazado.

¿Nunca se ha desaprobado una constante? (Pregunta genuina) ¿Parece que WPLANG podría haber estado en v4.0? ¿Es esto una cuestión filosófica sobre la naturaleza de las constantes? ¿Sería mejor un filtro? ¿Sería aceptable un filtro para @ smp303 ?

Incluso entonces, para aquellos que necesitan o quieren ambos editores, el complemento sigue siendo necesario de todos modos.

¿Porqué es eso?

@jawittdesigns pregunta con razón:

Si todo para Classic todavía está en el núcleo, ¿por qué crear un complemento solo para activarlo? Y qué pasa si tiene que permanecer en su lugar. Ya hay un montón de código antiguo y obsoleto en el núcleo de WordPress. Un disparador Classic incorporado realmente no haría mucha diferencia en el gran esquema de las cosas.

y @pento prácticamente ha descartado la eliminación de la mayor parte :

Gutenberg utiliza TinyMCE para impulsar los bloques de texto editables, eso no va a ninguna parte. Las funciones como wp_editor () se pueden mantener con relativa facilidad en Core sin necesidad de moverlas a un complemento; esperaría que continúen funcionando indefinidamente.

Finalmente:

No olvide que aún puede instalar y configurar el complemento en v4.9 antes de la llegada de Gutenberg.

Todos somos conscientes de esto. Estamos tratando de abogar por diferentes métodos que brinden opciones a los desarrolladores que tienen diferentes flujos de trabajo.

@rosswintle : es importante discutirlo porque, en última instancia, saber quién toma las decisiones arroja luz sobre la probabilidad de que nuestras solicitudes sean aceptadas y cómo expresarlas para que sean lo más influyentes posible.

Sin embargo, sí, tiene razón en que este tema en particular no es el lugar adecuado para discutirlo. La negativa a ceder en nuestras solicitudes es, sin embargo, indicativa del hecho de que estamos en una posición de debilidad en comparación con los que impulsan la decisión.

De todas formas. Haces algunos buenos puntos en la última publicación. De hecho, déjeme retomar su cotización:

Tenga en cuenta que, para una constante, el complemento del editor clásico debería estar incluido con WordPress, con un cargador personalizado, y permanecer allí a perpetuidad. Todavía podría estar allí dentro de 10 o 15 años cuando aparezca lo que sea que Gutenberg sea reemplazado.

¿Debemos suponer que una vez que surja lo que reemplace a Gutenberg no volveremos a tener la misma discusión? La gran USP de WordPress siempre ha sido su dedicación a la compatibilidad con versiones anteriores en comparación con su competencia. Eso ha funcionado bien hasta ahora. Como todos hemos señalado, Gutenberg rompe eso. Hay muy pocas opciones para seguir con lo que tenemos ahora, salvo lo que es efectivamente un truco autorizado oficialmente.

El hecho es que el código todavía está en el núcleo. Es un enfoque mucho más inteligente y eligante para permitir el uso de una constante, una sola línea de código, sobre un complemento que deberá mantenerse por separado y que terminará siendo cientos de líneas de código.

El hecho es que el código todavía está en el núcleo. Es un enfoque mucho más inteligente y eligante para permitir el uso de una constante, una sola línea de código, sobre un complemento que deberá mantenerse por separado y que terminará siendo cientos de líneas de código.

Este es mi punto por completo ... No es solo una cantidad específica de personas que lo necesitarán. Debido al hecho de que Gutenberg actualmente funciona correctamente, rompe una gran cantidad de complementos y temas, etc., etc. Otro complemento no es una solución, es un truco, una dependencia. No es la forma correcta de solucionar un problema que podría terminar alejando a un núcleo de personas que crean los mejores sitios de WordPress que existen.

La otra opción, la que más me asusta, es que la gente se quede con 4.9 y no actualice los sitios. Estos luego se vuelven inestables y se abren para la piratería, y bajan el nombre de WordPress.

Simplemente no siento que se haya pensado lo suficiente en esto y, por lo tanto, un complemento es la solución final.

Si TinyMCE va a seguir estando "debajo" de Gutenberg durante ciertos bloques, ¿por qué no abordar la situación de esta manera?
Pre-5.0 (también conocido como sitios actuales impulsados ​​por WordPress) tendría Gutenberg deshabilitado de forma predeterminada con un filtro / constante que facilita la habilitación de Gutenberg.
5.0+ (también conocidos como sitios de WordPress instalados en y después de 5.0) tendría Gutenberg habilitado de forma predeterminada con un filtro / constante que facilita su deshabilitación.

De esta manera, cualquier persona que quiera usar Gutenberg puede tomar esa decisión fácilmente y cualquiera que no esté listo o no esté dispuesto a usar Gutenberg (por cualquier motivo) también lo hará fácilmente. A veces, parece que algunos quieren hacer una última parada en la colina de Gutenberg cuando parece haber soluciones más prácticas (a corto plazo).

@wpstudio Esto es más o menos lo que pide # 4423.

Al igual que @rosswintle , creo que es importante volver a encarrilar este problema para aquellos que lo lograron y se complacieron con los últimos comentarios. Gracias por los que están discutiendo con respeto.

Sin embargo, hay que decirlo, independientemente de lo que sienta sobre una empresa y sus motivaciones, muchas personas están trabajando en Gutenberg en muchas empresas diferentes. Al igual que con WordPress, esto se hace a partir de contribuciones de la comunidad (no solo de una empresa). Hacer declaraciones radicales no es justo para quienes trabajan en esto. Tampoco es justo para aquellos que comenzaron este problema y quieren una solución.

Espero que este tema vuelva a encarrilarse y continúe debatiendo respetuosamente el punto de este tema.

@karmatosed , @ntwb , @tomjn y otros en este hilo, si mi pequeña perorata anterior se ofendió, me disculpo por eso. Este es un tema extremadamente importante y digno de debate, si es que vamos a debatirlo.

De los hilos anteriores, creo que es bastante evidente que Gutenberg se puede deshabilitar en Core, ya que los otros componentes tendrán que permanecer como parte de Core, por lo que solo está apagando Gutenberg. Lo cual tiene sentido, ya que actualmente existe como un complemento y muchos sitios pueden ejecutarlo bien. Entonces, salvo una razón técnica hasta ahora no presentada, eso significa que esta decisión no es técnica, es filosófica.

Y ese es el verdadero corazón de la misma. No creo que la comunidad en su conjunto esté de acuerdo con esto. Ni siquiera cerca. Es por eso que la decisión se está colocando (fíjense que dije "colocado", no "culpado") con Matt, porque parece ser la fuerza impulsora detrás de ella. Y, aparentemente, detrás de la decisión inquebrantable de hacer que Gutenberg forme parte de Core y la versión 5.0.

La pregunta es "¿Por qué?"

Ciertamente puedo ver el razonamiento detrás de obligar a Gutenberg a estar en Core. Creo que los "bloques" son muy importantes para la supervivencia futura y el uso generalizado de WordPress, .org o .com. Hago. Estoy detrás de "bloques" al 100%.

Sin embargo, no creo que Gutenberg en sí, como método de entrega de esos "bloques", sea un sistema bien pensado. Solo de este hilo, hay 3 casos de uso diferentes (yo, @rosswintle y @ smp303 ) y Gutenberg no parece satisfacer a ninguno de nosotros. De hecho, nos preocupa bastante, para nosotros, para nuestra empresa y para nuestros usuarios.

La decisión de poner Gutenberg en Core tiene sentido para Automattic porque obliga a todos los desarrolladores de complementos a adoptarlo y reescribir sus complementos para que funcionen con él. Esto es muy bueno para WordPress.com y, posiblemente, bueno para WordPress.org. Pero, nuevamente, algunos casos de uso no se beneficiarán de los bloques, pero es de esperar que la existencia de bloques tampoco los perjudique.

Sin embargo, esto significa que un grupo muy pequeño de personas está tomando decisiones económicas y comerciales bastante poderosas para una gran cantidad de personas. Solo para mí, cambiar a bloques será de cientos de horas y miles de dólares, más el tiempo de desarrollo perdido de tener que quitar recursos de mis objetivos planificados (que la comunidad a la que servicio realmente quiere) para revisar secciones importantes de mi sistema. para satisfacer las demandas de los tomadores de decisiones desconocidos (nuevamente, supongo que Matt es una gran parte de ese grupo de toma de decisiones).

No me sentiría tan mal por esto, ni tan asustado, para ser honesto, si Gutenberg me estuviera resolviendo los problemas. Pero no lo es. Hasta ahora, está empeorando mi vida. Las cosas pueden mejorar, pero no veo un gran cambio en la dirección del desarrollo. Parece que el 95% de las decisiones sobre el uso, implementación, UI / UX, así como los medios y métodos, han sido decididas por un pequeño grupo de otros sin mucho debate o aportación.

WordPress impulsa más del 25% de toda Internet. Eso se traduce en millones de sitios, miles de millones de páginas web y, posiblemente, cientos de miles de millones de dólares. Desde el New York Times hasta un puñado de blogueros de libros en mi red. Desde sitios masivos de comercio electrónico hasta libros individuales firmados vendidos por los autores a los que servicio. Eso es masivo - MASIVO. Es prácticamente una utilidad global mundial.

Sin embargo, la decisión de reescribir una parte significativa de los fundamentos de todo esto, que afecta a muchos millones de personas, aparentemente se tomó sin debate. Todo, desde la interfaz hasta la dependencia de REACT (controlado por Facebook, que ha demostrado ser muy depredador, solo pregúntale a SnapChat). Todas estas decisiones se han tomado, en gran parte, de forma unilateral.

Si todo esto fuera solo para alimentar un módulo en JetPack, a nadie le importaría realmente. Ese es el negocio de WordPress.com. Pero no lo es. Está transformando los cimientos de todo Internet.

Lo que me lleva al aquí y ahora. La comunidad, definitivamente los miembros de la comunidad en este hilo, está pidiendo control sobre el producto y el negocio que han construido utilizando el código de WordPress.org de código abierto y disponible públicamente. Estamos pidiendo la capacidad de protegernos a nosotros mismos y a nuestros usuarios, y la única forma en que podemos pensar en hacerlo es pidiendo una forma de apagar Gutenberg. Estamos pidiendo que esa capacidad sea parte de Core, al igual que agregar Gutenberg es ser parte de Core.

¿Se puede agregar a Core la capacidad de apagar Gutenberg? ¿Quién toma esa decisión y dirige a los clientes potenciales a hacerlo? ¿Cuál es el mecanismo para hacer esa pregunta? ¿Está la respuesta a debate? ¿Se someterá a votación? ¿Existe un proceso de comentarios? ¿Si es así, donde?

Y, @karmatosed , tienes toda la razón en que la sección "Problemas" de Github no es el mejor lugar para tener este debate. Estoy de acuerdo en que este repositorio debe dejarse en gran medida para su propósito previsto, que es identificar y resolver problemas técnicos directamente relacionados con el complemento Gutenberg.

Lamentablemente, no parece haber ningún otro lugar para tener esta discusión. Quiero decir, existe la sección Reseñas del complemento Gutenberg, pero ese es un foro bastante limitado para este tipo de conversación.

¿Habrá un sitio creado para discutir sobre Gutenberg? No solo su implementación, sino para comentar y discutir la interfaz? ¿El calendario de lanzamiento? (Por ejemplo, ¿qué criterio rige si Gutenberg y WP5.0 están "terminados" y listos para su lanzamiento? ¿Quién toma esa decisión? ") ¿Habrá pruebas de usuario de la interfaz de Gutenberg? ¿Hay alguna manera de recopilar datos y comentarios de @ ¿Tomjn es muy útil "Frontenberg"? Si es así, ¿esos datos serán publicados?

Hubo un video interesante en YouTube que le pedía a la gente que probara y usara Gutenberg y calificara su intuición (enlace aquí: https://youtu.be/7iWRBLCP-l0). ¿Hay otros como este? ¿Hay un esfuerzo a gran escala para probar Gutenberg? Si es así, ¿dónde se guardan esos datos? ¿Cómo se comparten esos datos? ¿Puede verlo la comunidad? ¿Se está utilizando para impulsar el diseño?

El problema que enfrentamos ahora con Gutenberg, y de hecho es la fuerza impulsora detrás de este mismo hilo, es que la comunidad se siente muy aislada de este proceso. Sentimos que nos está pasando. De hecho, eso se nos está imponiendo. Abrir el proceso para comentar y debatir, permitir nuevas voces e ideas sobre cosas como la interfaz, compartir datos e ideas de los usuarios, contribuiría en gran medida a aliviar esos temores y preocupaciones.

Y, hacer de los bloques una capacidad Core, pero manteniendo a Gutenberg como un complemento, podría hacer que todo sea mucho menos aterrador y mucho más aceptable para la comunidad en su conjunto. Me encantaría eso, personalmente. Dé tiempo a la comunidad para explorar y desarrollar enfoques alternativos a Gutenberg (diferentes interfaces y casos de uso), pero aún fomente el desarrollo y el futuro de los bloques.

Entonces, eso fue bastante largo, pero nuevamente, ¿dónde más podemos tener este debate aparte de aquí? Y este debate es MUY importante. Puede ser la discusión más importante en Internet en este momento, considerando la cantidad de personas y empresas afectadas.

Después de haber investigado un poco sobre esto, parece que todo lo que necesita, en un archivo mu-plugin , es lo siguiente para deshabilitar Gutenberg con código, a menos que me haya perdido algo, ¡lo cual es probable!

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

Para el contexto, tengo el complemento Gutenberg activo y el código anterior en un archivo en la carpeta mu-plugins . Ahora todas las pantallas de edición posterior utilizan el editor clásico.

Un par de cosas a tener en cuenta al respecto:

• gutenberg_can_edit_post_type no es el nombre de filtro final; los nombres de gutenberg cambiarán de nombre antes de fusionarse en Core.
• Este filtro solo significa "no cargar el editor de bloques", no significa "usar el editor clásico". Funciona por el momento, pero no se garantiza que funcione en el futuro. A medida que el código específico de Classic (por ejemplo, edit-form-advanced.php ) se mueve al complemento Classic Editor, dejará de recurrir al editor clásico y esperará explícitamente que cargue su propio editor.

@rosswintle : retomando el hilo de la semana pasada :

La forma más fácil de pensar en esto es "si los datos aparecen entre <body> y </body> , es contenido, y finalmente encajarán en un bloque". Para WordPress 5.0, esto es un poco más limitado: solo lo que se encuentra entre <article> y </article> son bloques. 😉

Entonces, para tomar un ejemplo, un tipo de publicación de propiedad inmobiliaria. El precio se almacena en postmeta, pero es contenido. Es posible que tenga un bloque llamado "Property Lede", tiene algunos elementos para completar: el precio, la dirección, el tipo de edificio, la cantidad de dormitorios / baños / garajes, ese tipo de cosas. Probablemente también tenga otros bloques: tiempos de inspección, características, fotos, planos de planta, agente, etc. Con las plantillas de bloques , configure el editor de bloques para que cuando se edite el tipo de publicación property , los bloques ya están ubicados y no se pueden mover. El flujo de trabajo para el usuario final no es muy diferente de cómo se ve ahora un flujo de trabajo existente basado en metabox, pero se parece mucho más al resultado final.

Eso fue un poco largo, pero con suerte establece la escena: cualquier cosa que parezca contenido _es_ contenido, independientemente de dónde se almacenen los datos, o cómo puedan manipularse o formatearse antes de que se muestre en la interfaz. Algunos bloques pueden almacenar sus datos en post_content , pero esa no es la característica definitoria de lo que los convierte en contenido: mostrarse en la interfaz es lo que los convierte en contenido.

Entonces, ¿qué pasa con la información que no se muestra en el front-end? ¿El nombre del propietario? ¿Relaciones con la visualización de citas? ¿Eso es "contenido"? ¿Se debe ingresar en un "bloque"?

Las categorías / etiquetas / taxonomías pueden mostrarse o no en el front-end. ¿Son "bloques"?

El estado de la publicación puede mostrarse en la interfaz, pero definitivamente no es un bloqueo.

Anteriormente dijiste:

los metadatos no son un bloque, aunque pueden informar cómo se usa o se muestra un bloque.

Lo cual está bien. Pero, ¿por qué, entonces, se les dice a los desarrolladores que en el futuro los metadatos deberían editarse utilizando la interfaz de bloque?

Esta es la verdadera confusión para mí. Entiendo por qué los bloques de Gutenberg son buenos para editar lo que está entre las etiquetas body , pero no entiendo por qué los bloques son buenos para editar otros datos que no están entre esas etiquetas.

Me parece que es esta confusión la que está provocando que los desarrolladores quieran desactivar Gutenberg. Algunos de nuestros usos de WordPress tienen MUCHA información que no se muestra en el front-end y, sin embargo, se nos dice que en el futuro un editor de front-end es lo que deberíamos usar como interfaz para estos datos.

Espero que esto comunique la confusión.

Entonces, ¿estas formas de deshabilitarlo ...?

@pento el bloque doc para esa función no indica en absoluto que este filtro sea temporal:

/**
 * 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.
 */

¿Cuál es el propósito de ese filtro si no hacer como se describe?

Además @pento con respecto a esto:

Este filtro solo significa "no cargar el editor de bloques", no significa "usar el editor clásico". Funciona por el momento, pero no se garantiza que funcione en el futuro. A medida que el código específico de Classic (por ejemplo, edit-form-advanced.php) se mueve al complemento Classic Editor, dejará de recurrir al editor clásico y esperará explícitamente que cargue su propio editor.

Se nos ha dicho en varios lugares que si los tipos de publicaciones declaran show_in_rest => false o un cuadro de meta en la pantalla de edición de publicaciones declara '__block_editor_compatible_meta_box' => false, , se cargará el editor clásico. Parece que desde arriba estás diciendo que esto no será parte del núcleo y, por lo tanto, ¿cómo puede ser ese el caso si no has activado el complemento del editor clásico?

Para recurrir al editor clásico, se detecta algo que no es compatible con Gutenberg, entonces seguramente el editor clásico debe seguir siendo parte del núcleo, por lo tanto, ¿seguramente no necesitamos el complemento para invocar esta funcionalidad?

Entonces, ¿qué pasa con la información que no se muestra en el front-end? ¿El nombre del propietario? ¿Relaciones con la visualización de citas? ¿Eso es "contenido"? ¿Se debe ingresar en un "bloque"?

Seguro que también hay espacio para la metainformación, que se analiza en el n. ° 3330. Lo principal que quería señalar es que mucho de lo que se conoce como "metadatos" es en realidad contenido.

Las categorías / etiquetas / taxonomías pueden mostrarse o no en el front-end. ¿Son "bloques"?

Bueno, son meta para la publicación, pero posiblemente contenido para el sitio. El enfoque de personalización de Gutenberg probablemente incluirá un bloque que utiliza esos metadatos para producir contenido. 🙂 Sin embargo, es poco probable que un bloque en el editor de bloques los use como contenido, de ahí que las taxonomías estén en la barra lateral, no en un bloque.

Lo cual está bien. Pero, ¿por qué, entonces, se les dice a los desarrolladores que en el futuro los metadatos deberían editarse utilizando la interfaz de bloque?

No estamos diciendo que todos los metadatos encajen en la interfaz del bloque. Algunos podrían, pero no es necesario. El punto es que _la mayoría_ de los usos existentes de las metacajas encajan en la interfaz del bloque, la forma más fácil de diferenciarlos es pensar si se muestra en la interfaz o no. # 3330 discute conceptos para editar metadatos con más detalle.

Puedo decirles categóricamente que los metadatos _no_ necesitan ser editados en la interfaz del editor de bloques. Si no es contenido, o no se relaciona de alguna manera con el contenido, no pertenece allí; hay otros lugares para insertar la interfaz para editar esos metadatos.

Entonces, ¿estas formas de deshabilitarlo ...?

Si crea sitios, use el complemento Classic Editor. Si crea complementos, use los indicadores de compatibilidad CPT y metabox. 🙂

Si crea sitios, use el complemento Classic Editor. Si crea complementos, use los indicadores de compatibilidad CPT y metabox. 🙂

Esto está bien para los sitios que creamos en el futuro, o los clientes que tenemos "en los libros" y cuidamos sus sitios. Sin embargo, ¿qué pasa con los clientes cuyos sitios construimos en el pasado y que funcionan bien, se actualizan automáticamente, etc.? Probablemente harán clic en actualizar a WordPress v5.0.

Estos sitios no tendrán instalado el complemento Classic Editor y no tendrán marcas en esas metacajas / CPT porque fueron codificados cuando Gutenberg no estaba presente. Esos sitios tendrán problemas y dejarán a sus propietarios confundidos y francamente bastante molestos. Por favor corríjame si me equivoco aquí.

@wpmark lo clavó.

Usaré el complemento Classic Editor si lo necesito en el futuro. Usaré las banderas de compatibilidad CPT y meta box si es necesario en el futuro. Pero tengo decenas de personas, empresas y organizaciones benéficas / sin fines de lucro de todas las formas y tamaños para las que ya he creado sitios. Con algunos de ellos todavía tengo relaciones laborales. Otros han seguido adelante y solo están ejecutando el sitio ellos mismos, o trabajan con otro desarrollador o no tienen ningún desarrollador.

No es realista esperar cambios de código o la instalación de un complemento en cada sitio que lo necesite.

Este es el territorio # 4423 realmente.

Para toda la conversación importante, este ticket no tiene etiquetas ni propietario. Si no va a suceder, ¿tiene algún sentido mantenerlo abierto?

gutenberg_can_edit_post_type (o como se llame en Core) y '__block_editor_compatible_meta_box' => false volverán a la interfaz clásica de WordPress 5.0. Sin embargo, las futuras versiones de WordPress pueden cambiar ese comportamiento.

gutenberg_can_edit_post_type solo marca si cargar el editor de bloques o no. Por ahora, el comportamiento predeterminado cuando no se carga el editor de bloques es cargar Classic, pero el supuesto de ese filtro es que, si no está cargando el editor de bloques, está proporcionando su propia interfaz. Ese podría ser el complemento Classic Editor, podría ser una interfaz personalizada. Pero es probable que una futura versión de WordPRess vea que el código clásico se moverá al editor clásico.

Existe una situación similar para la bandera __block_editor_compatible_meta_box . Por ahora, vuelve a la interfaz clásica, pero una versión futura de WordPress puede ver el comportamiento predeterminado cambiado para permanecer en el editor de bloques y mostrar una advertencia donde estaría el cuadro meta.

Por supuesto, ninguno de estos cambios sucederá sin investigar y sin llegar a los propietarios del sitio; mi punto es que estas configuraciones existen principalmente con el propósito de hacer la transición a Gutenberg. El complemento Classic Editor es la opción estable para forzar el uso de la interfaz Classic.

Consulte el n. ° 3902 para obtener más información sobre estos temas.

Sobre el tema de informar a los propietarios de sitios, WordPress 5.0 no se lanzará al vacío. Hay muchas herramientas que podemos utilizar para informar a los propietarios de sitios sobre los próximos cambios y para hacerles saber si su sitio funcionará o no. Las futuras versiones de WordPress 4.9.x incluirán información sobre el editor de bloques , hay planes en marcha para recopilar datos sobre la compatibilidad de los complementos (tanto automatizados como de fuentes múltiples - # 4072), y estamos abiertos a otras opciones para asegurarnos de que los propietarios del sitio estén al tanto. lo que viene.

Para toda la conversación importante, este ticket no tiene etiquetas ni propietario. Si no va a suceder, ¿tiene algún sentido mantenerlo abierto?

No tuve ningún problema en mantenerlo abierto mientras tuvimos esta discusión, pero en este punto, no veo la necesidad de mantenerlo abierto más. Para abordar la pregunta original, una opción basada en código para recurrir al editor clásico no está en las cartas.

@pento ¿Por qué

Solo está demostrando el punto de que no se está escuchando a la comunidad al cerrar esto.

Realmente creo que debería reabrirlo para que podamos llegar a una resolución al respecto.

La resolución fue no: no permitirán una forma de deshabilitar Gutenberg en el código. Tienes que confiar en un complemento.

Completamente infeliz e insatisfecho con esto, pero al menos lo intenté.

La resolución fue no: no permitirán una forma de deshabilitar Gutenberg en el código. Tienes que confiar en un complemento.

¿Dónde y cuándo sucedió eso? Aquí no se menciona ninguna decisión.

¿O es solo la reacción típica del equipo central al fingir escuchar y luego simplemente apagarlo?

¿Qué tipo de resolución quieres en este momento?

Si desea desactivar Gutenberg usando una constante, eso no sucederá. Nos han escuchado y la idea ha sido rechazada.

No tuve ningún problema en mantenerlo abierto mientras tuvimos esta discusión, pero en este punto, no veo la necesidad de mantenerlo abierto más. Para abordar la pregunta original, una opción basada en código para recurrir al editor clásico no está en las cartas.

De @pento - esta es la razón por la que cerró

Bueno, espero que al menos publiquen el complemento antes de la actualización para que podamos instalarlo y activarlo para que la experiencia del usuario no se interrumpa.

Quiero decir que el soporte de metabox todavía está roto en 2.0 y no estoy realmente seguro de que alguna vez funcione en este momento.

El complemento ya existe: https://wordpress.org/plugins/classic-editor/

Para responder a la pregunta original de

1. En wp-config.php agregue

define( 'ENABLE_GUTENBERG', false );

1. En un archivo llamado my-hacks.php en la carpeta mu-plugins , que puede que tenga que crear código

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

apoyos @tomjn @wpmark

Puede hacer esto hoy sin tener instalado Gutenberg o el editor clásico.
Pero tenga en cuenta que el nombre del filtro puede cambiar cuando el código se fusiona con el núcleo.
... en ese momento alguien estará escribiendo documentos, y luego puede agregar otra línea.

Notas: El archivo llamado my-hacks.php se introdujo en 2003 y quedó obsoleto en 200x.
Pero no hay nada que le impida implementarlo como un complemento obligatorio en mu-plugins .

Si desea ver lo difícil que es eliminar el código obsoleto, incluido el campo de opción asociado a él
vea WordPress TRAC # 33741 - Elimine las referencias a my-hacks.php y la opción hack_file

Incluso más fácil ... en wp-config.php

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

Creo que el concepto de bloque es incorrecto. En mi opinión, un bloqueo debería ser una publicación. Entonces, si necesitamos varios contenidos en una publicación, debemos poder tener publicaciones secundarias. Como Twitter, donde una página está formada por muchos tweets independientes.

Dentro de una publicación solo necesitamos un editor de texto.

No tenemos presupuesto para hacer una actualización de todas nuestras páginas. Si wp no ofrece compatibilidad a largo plazo, muchos de los usos simplemente los cambiaremos en el futuro a una comunidad más estable, ya que la puerta estaría abierta a nuevas empresas.

Ahora wordpress es genial gracias a la comunidad. 5.0 significa comenzar desde 0. Entonces, como cualquier otro marco.

Dos líneas de desarrollo podrían ser una buena idea en lugar de desactivarlas o no. WP normal y WP Gutenberg. Al menos durante los próximos 5 años. Entonces, Gutenberg tendría tiempo para mantenerse estable y tener una comunidad también, así como WP.

Sería bueno que muchos de ustedes, como desarrolladores, tuvieran un problema, ¿por qué no simplemente entrar y continuar?
Github con un ticket que propone un método de trabajo para resolver su problema en lugar de simplemente escribir un sinfín de por qué no puede ayudar a construir una solución con el proyecto actual de Gutenberg.

Traiga sus habilidades de programación para ayudar a resolver el problema.

Soy diseñador visual y actualmente estoy haciendo planes para ayudar a dos de mis clientes a trasladar los procesos de edición a Gutenberg y actualmente estoy diseñando y construyendo un nuevo sitio para un cliente con un sitio de más de veinte años que no pueden mantener.

Participe y ayude a que WordPress.org avance como herramienta de creación de sitios.

@TomDesign, ¿ha intentado siquiera leer la discusión? El equipo de GB no quiere la funcionalidad como parte del complemento, por lo que a menos que en "Traiga sus habilidades de programación para ayudar a resolver el problema" quiera decir que alguien debería piratear sus cuentas para agregar un código que no quieren, no estoy seguro de cómo escribir código es incluso remotamente relevante aquí.

@tomdesign planteé el requisito de tener un plan de migración
Le señalé que será mucho trabajo. Y es algo que siento que es necesario.

Estoy seguro de que hay bastantes desarrolladores a los que les gustaría poder utilizar nuestras habilidades de programación para garantizar una migración sin problemas. Pero no queremos perder el tiempo desarrollando algo que será rechazado de inmediato. En mi opinión, la migración merece un Proyecto por derecho propio, con cada requisito evaluado de manera lógica. Es lo suficientemente importante tener una propuesta bien documentada que nos lleve allí a largo plazo.

La solicitud original de Simon era una solución a corto plazo para un problema a largo plazo.
Creo que el proceso de migración de contenido durará años.

Hola chicos,
Al leer los comentarios, creo que este es el lugar adecuado para compartir un buen complemento sobre Gutenberg.
Me gustaría presentarles un complemento gratuito que le permite administrar el editor de Gutenberg.
Se llama Gutenberg Manager y le permite habilitar / deshabilitar el editor en los distintos tipos de publicaciones (páginas y publicaciones incluidas). Tiene más funciones pero te las dejo a ti.

Hemos leído toneladas de publicaciones de personas que se quejan de la futura implementación de Gutenberg dentro del núcleo en WP 5.0 y esto nos ha llevado a encontrar una solución simple.

Gutenberg Manager resuelve este problema y permite, por ejemplo, seguir usando Elementor, Visual Composer, Siteorigin Builder o Cornerstone sin ningún problema incluso después de WP 5.0.
Desde los primeros comentarios de los usuarios en WP.org, el complemento parece ser apreciado :)

Por esta razón, me gustaría presentarles a Gutenberg Manager -> https://wordpress.org/plugins/manager-for-gutenberg/

Los desarrolladores pueden utilizar el complemento en sus propios temas y complementos gracias a algunos útiles ganchos. Hay un gancho para OCULTAR el panel de opciones del complemento para que el usuario final no lo vea en el backend de WP (una gran característica para los desarrolladores que desean incluir Gutenberg Manager en sus proyectos).

También estamos haciendo arreglos con los equipos de los constructores más famosos para activar asociaciones y colaboraciones. ¡De esta manera esperamos hacer la transición a Gutenberg un poco menos traumática!

Gracias a todos por su atención,
Buen trabajo.

@unCommonsTeam ¿puedo preguntar cómo está deshabilitando el editor de Gutenberg en el complemento, cuando, por ejemplo, esas opciones están seleccionadas en la pantalla de configuración?

Seguro @wpmark ,

eche un vistazo a la fila 79 -> https://github.com/unCommonsTeam/gutenberg-manager/blob/master/inc/core.php

Mejor

@unCommonsTeam gracias por volver a mí. Probablemente me equivoque aquí, pero parece que el complemento simplemente está eliminando todas las cosas agregadas por el complemento de Gutenberg. Esto es algo que sugerí anteriormente usando:

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

Sin embargo, @pento me informó que no era una solución sólida, ya que volvió a colocar un editor en WordPress. Consulte https://github.com/WordPress/gutenberg/issues/4409#issuecomment -357912790

@wpmark sí, esa función elimina todas las cosas agregadas por el complemento de Gutenberg, pero la función solo se llama en páginas específicas de backend, no para todos los backend. Por ejemplo, si decide deshabilitar el editor de Gutenberg en las páginas pero desea usarlo en las publicaciones .. Entonces creo que es aceptable.

Mejor

@unCommonsTeam parece un gran complemento, pero creo que sufriría los mismos problemas que mi solución, ya que realmente necesita agregar un editor a WordPress.

Por lo que @pento estaba diciendo era que eliminar las adiciones de Gutenberg, solo indica que no se desea el editor de bloques, pero debe reemplazarlo con algo, que es lo que hace el complemento del editor clásico.

Como dijo @pento :

Este filtro solo significa "no cargar el editor de bloques", no significa "usar el editor clásico". Funciona por el momento, pero no se garantiza que funcione en el futuro.

Por lo tanto, creo (y debo corregirme, por supuesto) que su complemento está haciendo lo mismo (pero, por supuesto, mucho mejor y con muchas opciones interesantes de flexibilidad, etc.) que mi intento anterior.

Otra cosa en la que estaba pensando es, es el nombre Gutenberg va a estar rondando cuando el proyecto se fusiona en el núcleo, o por ejemplo, esas funciones (por ejemplo, gutenberg_init ) serán renombradas a (por ejemplo) block_editor_init .

@wpmark tienes razón. Esperamos que en WP 5 dejen ahí el editor clásico. Sin embargo, podríamos intentar agregar una opción para incluir el editor clásico a través de un complemento. Si el equipo de desarrollo de WP decide eliminar el editor clásico, creemos que nuestro complemento se volverá muy popular :)

Sobre el nombre de Gutenberg tiene razón, probablemente tendremos que arreglar nuestro complemento reemplazando los nombres de los ganchos.

Además, nuestro complemento ofrecerá otras funciones basadas en el editor Gutenberg (habilitar / deshabilitar bloques específicos, nuevos bloques, etc.). Así que creemos que también será útil para las personas que usan el editor de Gutenberg.

Salud

Esta puede ser una buena idea que resolverá casi toda la estampida y el debate:

Si Gutenberg viene deshabilitado por defecto en el núcleo, junto con el editor clásico que aún se mantiene, esto podría ahorrarle al mercado de complementos y temas de WordPress de ~ $ 1 mil millones y una gran franja de Internet muchos problemas, pérdidas monetarias, incidentes de soporte, además de ahorrar mucho WP de prestigio y pérdida de confianza como plataforma.

Gutenberg, aunque es un editor más moderno, parece estar diseñado para las necesidades de WordPress.com y medios similares que brindan servicios de blogs / alojamiento utilizando WordPress. Todo esto está muy bien. Sin embargo, no debería provocar un impacto y una patada en las pelotas al resto del ecosistema. Una amplia franja de Internet, los sitios web de las personas y su sustento se verán afectados con la dirección actual.

WordPress.com puede tener Gutenberg de forma predeterminada, mientras que WP viene con la opción predeterminada desactivada, por lo que proporciona lo mejor de los mundos a todo el ecosistema.

Tengo que estar de acuerdo con codebard, que gutenberg se deshabilitará de forma predeterminada y se mantendrá el editor clásico. Actualmente tengo las actualizaciones automáticas deshabilitadas exactamente por esta razón: no quiero que los bloggers en mi red de sitios múltiples se presenten repentinamente con este tipo de editor de "constructor de páginas", y ciertamente no quiero que el editor clásico sea reemplazado por completo con gutenberg.

Como mínimo, deberíamos poder deshabilitar gutenberg con una declaración de definición como define ('DISABLE_GUTENBERG', verdadero); Un gran problema con tener un complemento para deshabilitar gutenberg es que dependeríamos del desarrollador para mantener y actualizar el complemento, cuando sea necesario. ¿Qué haríamos durante los días o las semanas en que el complemento deja de funcionar porque el desarrollador está de vacaciones o demasiado ocupado para actualizar el complemento? También existe el problema de que las personas que usan el complemento tendrán que actualizar el complemento por su parte.

Parece que obligarnos a gutenberg y luego encontrar soluciones para desactivarlo como una ocurrencia tardía es una forma realmente atrasada de hacer las cosas. Desactive gutenberg de forma predeterminada. A muchos de nosotros que solo queremos un blog simple nos resulta cada vez más difícil usar wordpress, ya que parece estar evolucionando hacia un creador de sitios web.

Otra nota, en el caso de redes multisitio, el administrador de la red debería poder decidir si gutenberg debería estar disponible en toda la red.

@WebTrooper, el plugin Classic Editor es mantenido por el equipo de desarrolladores de WordPress (las mismas personas que mantienen Core) y Gutenberg Ramp es mantenido por Automattic, por lo que ambos deberían ser inmunes al "desarrollador de vacaciones" o los factores de "demasiado ocupado".

Tenga en cuenta que VIP tiene un compromiso con el complemento Gutenberg Ramp, que está en uso en el sitio de nuestros clientes y en nuestros propios sitios. Estar de vacaciones o demasiado ocupado si las cosas se rompen podría significar que los sitios de los clientes no funcionan, que es lo último que desea VIP.

También me gustaría señalar que estos complementos se pueden bifurcar, Automattic y los autores y el complemento del editor clásico no poseen ningún conocimiento secreto que les haya permitido crear esos complementos, ni son técnicamente grandes o complejos. Hay cientos de agencias en todo el mundo con desarrolladores capaces de mantener cualquiera de los complementos.

Aparte, mucha gente aboga por la desactivación de gutenberg de forma predeterminada, pero he notado que, independientemente de los méritos de esos argumentos, todos no dicen cuándo exactamente GB debería estar activado de forma predeterminada. La conclusión lógica es una situación de editor clásico perpetuo.

Es 2934, el imperio galáctico ha saltado al sistema, 300 cruceros de batalla. La red de noticias planetarias local ha animado al editor clásico a escribir un informe para los habitantes locales. Nadie les habló de Gutenberg antes de que comenzaran a construir el sitio.

Siempre he sugerido que esté activado de forma predeterminada para NUEVAS instalaciones.

Pero para las instalaciones existentes, sugeriría un enfoque dirigido por el usuario, que permita a las personas optar por Gutenberg, probarlo, conservarlo si les gusta y volver al editor clásico si no les gusta. WordPress podría entonces recopilar estadísticas y comentarios cuando las personas regresen para ayudar con el desarrollo y la documentación del cambio.

Cuando se alcanza algún tipo de masa crítica de sitios activos con él, puede habilitarlo de forma predeterminada. Y no, no voy a elegir un número del aire. Pero podríamos medir el uso y actuar de manera apropiada.

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

Esto está sucediendo con las versiones antiguas de PHP, ¿verdad? WordPress ha sido incansable en su compatibilidad con versiones anteriores de PHP 5.2 porque la gente todavía lo usa, en muchos casos probablemente sin saberlo o sin importarle. WordPress está analizando cuidadosamente las estadísticas; poner mucho esfuerzo en la coordinación con los anfitriones, etc. y guiar suavemente a las personas en una ruta de actualización. Y es de suponer que el proyecto, en algún momento, actuará sobre los datos de uso que tiene para tomar una decisión.

Sin embargo, con una interfaz de usuario completamente nueva para editar, ¿qué usuarios sí conocen y se preocupan por el enfoque es forzarlos?

Por mucho que empiece a abogar por Gutenberg en algunos casos, realmente espero que la propuesta de fusión tenga en cuenta las preocupaciones de personas como yo, que administran muchos sitios para usuarios finales, muchos de los cuales tienen pocas habilidades de TI. no confía en la tecnología, y Gutenberg lo confundirá y desorientará.

Creo que Gutenberg también debería estar disponible para NUEVAS instalaciones, debido a las siguientes razones importantes:

• Existe una cantidad casi infinita de tutoriales, recursos, procedimientos y todo lo que puedas imaginar, todo basado en el editor existente. Esto hace que la entrada de personas a WordPress sea MUY fácil.

• Esta facilidad de entrada es muy importante, ya que debido a que comienzan tan fácilmente así, las personas entienden que 'WordPress es fácil' y fácilmente tienen una percepción cálida de la plataforma, una actitud más receptiva y segura para aprender más.

• Todo esto se combina en la percepción de 'WordPress simplemente funciona', y lo recomiendan cómodamente a sus compañeros. Así fue como pudimos crecer para abarcar el 30% de Internet.

• La coherencia de la información es importante. Y no hay forma de que todos y cada uno de los recursos en Internet se actualicen para reflejar Gutenberg, incluso en el futuro. Creará mucha confusión. Y lo más desafortunadamente, la reacción del usuario común será 'Lo instalé, pero NO FUNCIONA', solo porque no puede encontrar cómo hacer las cosas y las cosas no se ven igual que el tutorial que usa. No se equivoque, ningún esfuerzo de actualización aclarará esta confusión con respecto a recursos, tutoriales, etc.

Por lo tanto, Gutenberg debería ser opcional y poder alternar para mantener la 'compatibilidad con versiones anteriores' no solo en términos de temas, complementos de contenido existentes creados por el creador de páginas, etc., sino también en términos de los recursos que tenemos en línea. Una plataforma no es 'tan fácil' y no se la puede recomendar a la gente que dice 'simplemente instálela y busque en Google ...' cuando Google muestra muchos recursos diferentes, obsoletos y actualizados. Y si tienes alguna experiencia seo, sabes que será ...

Con Gutenberg, podemos aprovechar el mercado supuestamente creciente de 'creadores de sitios' (wix, squarespace, etc.) y el mercado potencial de 'blogs fáciles' (a la medium, etc.). Pero, si rompemos incluso una fracción del 30% de Internet, o el mercado de temas / complementos de ~ $ 1 mil millones mientras lo hacemos, será una patada masiva y masiva de la que no nos recuperemos en una década.

No puede instalar un complemento PHP clásico, por lo que la comparación con PHP no es relevante, esos son millones de sitios que seguramente se romperán, sin una solución basada en WP que lo resuelva, de ahí el análisis cuidadoso. También tenga en cuenta que la próxima versión tiene un mensaje que instala el complemento clásico, a los usuarios no solo se les pide que instalen el complemento Gutenberg.

De cualquier manera, este tema se cerró, se tomaron decisiones. Un tema cerrado es un mal lugar para intentar cambiar un enfoque que se está planificando en otro lugar.

Pero tenga en cuenta que Gutenberg se puede alternar, hay complementos para habilitarlo y deshabilitarlo. Han pasado años desde que se inició GB, con mucho tiempo para probar hasta ahora, tiempo para capacitar a los clientes, tiempo para instalar el complemento del editor clásico, etc. Esto no es algo nuevo que se imponga a la gente de la noche a la mañana.

Me he dado cuenta de que, independientemente de los méritos de esos argumentos, todos fallan en decir cuándo exactamente GB debería estar activado de forma predeterminada.

Y, al parecer, incluso si las personas que hacen esos argumentos hubieran hecho alguna sugerencia sobre cuándo debería suceder esto, se descartaría de todos modos. Entonces, ¿por qué mencionarlo?

Sé cómo funcionan los tickets cerrados. Hiciste un comentario bastante sarcástico aquí. Así que traté de ofrecer una respuesta constructiva.

@tomjn Me haré eco de @rosswintle aquí diciendo que sí, hemos sugerido que debería estar activado solo para nuevas instalaciones de forma predeterminada: https://github.com/WordPress/gutenberg/issues/4423. Este es otro tema cerrado, cerrado sin ninguna discusión real sobre el tema.

No están dispuestos a escuchar, hay un complemento, bla, bla, bla, esto está cerrado. Avanzar sin nada que ver aquí. Se trata de .com a nadie le importa .org, no hay dinero para Automatic allí.

@ smp303 ¿podría identificar quiénes son?

@rosswintle No se pretendía sarcasmo, Gutenberg 0.1.0 se lanzó hace 14 meses, y la única forma de evitar que los sitios que se ejecutan en 5.2 se rompan es

No están dispuestos a escuchar, hay un complemento, bla, bla, bla, esto está cerrado. Avanzar sin nada que ver aquí. Se trata de .com a nadie le importa .org, no hay dinero para Automatic allí.

Tengo que estar de acuerdo. Ya sea aquí o en el foro de soporte de WordPress, parece que no les importa en absoluto a pesar de que muchas personas en la comunidad están en contra de esto. Dado que WordPress es un código abierto, me gustaría sugerirle a cualquiera que cree una petición con respecto a este asunto. Personalmente creo y sugiero que GB debería ser un complemento como Jetpack en lugar de fusionarlo en el núcleo.

En la nota al margen: @karmatosed Ya que no pudo responder y responder a mi pregunta en uno de los comentarios en el foro de WordPress sobre Gutenberg, me pregunto por qué mi comentario desaparece de repente. ¡Buen movimiento!

Este hilo ha pasado de discutir por qué no existe una opción basada en código para deshabilitar Gutenberg, a ataques personales implícitos o directos de cuentas de sockpuppet.

Aprecio que algunas personas se sientan muy apasionadas por este tema y es lamentable que este hilo haya ido por este camino, pero la decisión no va a cambiar.

El complemento Classic Editor es la opción para volver al editor clásico en todo un sitio. Se anuncia de forma destacada en la próxima versión de WordPress 4.9.8 como una opción para instalar ahora, en preparación para WordPress 5.0.

Si es un creador de sitios que desea excluir a sus clientes del editor de bloques, instalar el complemento Classic Editor (y contribuir con informes de errores o correcciones ) es la mejor solución a largo plazo para garantizar que el editor clásico continúe disponible.

Para los metaboxes, ya es posible optar por no participar en el editor de bloques , esta API se fusionará con Core. Para los CPT, el filtro gutenberg_can_edit_post_type cambiará de nombre cuando se combine (probablemente a block_editor_can_edit_post_type , o algo por el estilo), pero también estará disponible como una opción basada en código.

Para evitar que este hilo se desarrolle más, lo bloquearé.

Todos los involucrados en esta discusión son absolutamente bienvenidos a continuar participando en la preparación de Gutenberg para WordPress 5.0, pero tenga en cuenta que los ataques personales no son en absoluto bienvenidos y resultarán en el bloqueo de problemas o la prohibición de cuentas.