Gutenberg

Ha pasado más de un año desde el gran lanzamiento de Gutenberg , el nuevo editor en WordPress. Me parece que la mayor parte de la controversia en torno a este tema se ha calmado. Ha pasado suficiente tiempo para que la UX y la accesibilidad hayan mejorado, y la gente está viendo el potencial con mucha más claridad. No hay vuelta atrás.

Me encuentro con artículos como Haris Zulfiqar que dice que está apostando por ello y Nick Hamze que dice que los bloques son para la próxima generación .

Si bien creo que todavía hay aspectos difíciles (como, por ejemplo, ¿por qué no puedo poner una lista en una cita en bloque? ¿Por qué no puedo agregar una clase a un enlace? ¿Por qué no puedo usar las teclas de flecha en el selector de bloques?), Soy un gran admirador en general. Y ya no sólo conceptualmente. Uno de mis objetivos para 2020 fue incorporar CSS-Tricks a Gutenberg, por lo que lo hice de inmediato en enero.

Ya teníamos un pie en la puerta

Teníamos una pizca de experiencia en Gutenberg porque ya habíamos convertido la experiencia de creación de boletines al nuevo editor. Nuestros boletines son un tipo de publicación personalizada aquí en CSS-Tricks, que se publican aquí en URL públicas, tienen una fuente RSS personalizada y se envían mediante MailChimp, que recupera y lee esa fuente RSS.

Pudimos activar Gutenberg para recibir boletines mediante el complemento Gutenberg Ramp . Eso funciona muy bien para tipos de publicaciones personalizadas y publicaciones con ID individuales, pero quería activar Gutenberg solo para contenido nuevo . Terminé parcheando el complemento. Aquí hay una solicitud de extracción en caso de que alguien piense que es una buena idea.

Esto fue importante para mí, ya que tenemos decenas de miles de publicaciones antiguas creadas con el editor anterior, y aunque Gutenberg no las estropea si las abrimos para editarlas, la experiencia de edición que les brinda no es tan buena. como el editor “clásico” (por ejemplo, tenemos botones especiales para nuestros bloques de código especiales y cosas así).

Tratar con contenido antiguo

Lo que realmente sería genial es que Gutenberg convirtiera las publicaciones antiguas en bloques adecuados al abrirlas, pero eso parece un sueño en este momento. Por ejemplo, tendría que analizar el HTML, identificar qué fragmentos parecen bloques, identificar qué bloque tiene más sentido, incluidos nuestros bloques personalizados , que son los más importantes, y ser realmente correcto al respecto de una manera no frágil.

Por ahora, el contenido antiguo sólo utiliza el editor antiguo. Ni siquiera existe una manera fácil de activar a Gutenberg para una publicación individual del editor. (Podría codificar valores en el uso de la rampa de Gutenberg, pero eso es un poco tedioso).

Me preocupa un poco que el antiguo editor realmente se deteriore. Por ejemplo, una de las principales razones por las que comencé con esto es porque, en este sitio, el editor anterior simplemente se desplazaba aleatoriamente hasta la parte inferior de la página. Ni por mi vida puedo entender por qué, pero hace que la autoría sea desagradable para mí. Solo un pequeño error en el corte de papel que me hizo querer disfrutar de la experiencia del editor que se está desarrollando activamente.

Pero incluso si el antiguo editor realmente se pone malo, simplemente culpar a Gutenberg por todo no es tan malo. Todo el contenido antiguo estará en un gran bloque “clásico” y estará bien.

De todos modos, ¡está funcionando!

Activar Gutenberg para nuevas publicaciones fue un pequeño desafío, pero está activado para nosotros y estamos creando contenido nuevo en él. Sólo hablo por mí, pero Dios mío, me encanta. Es una mejora tan enorme para escribir contenido que estoy un poco obsesionado con ella. El equipo también está contento.

Creando bloques personalizados

Mira este elegante bloque de texto que tenemos:

Podrías pensar, genial, una oportunidad para un bloque personalizado. Diablos, incluso cubrimos el aprendizaje y la fabricación de bloques de Gutenberg en una gran serie . Pero esto trae a colación una situación bastante relevante: cuándo no construir un bloque . Lo único único de este bloque es que tiene un nombre de clase especial que nuestro CSS usa para darle estilo a ese bloque. Eso es todo. Agregar un nombre de clase es una característica incorporada de cada bloque, por lo que un bloque personalizado aquí realmente no es necesario.

De hecho, podemos ir un paso más allá y convertir un bloque de texto con esta clase exacta en un “bloque reutilizable” para que ni siquiera tengamos que recordar o escribir el nombre de esa clase. Después de crear un bloque de texto con esta clase, selecciono “Convertir en bloque reutilizable” en el menú de kebab y ahora se guarda para siempre como un bloque reutilizable.

Ya lo estamos usando para algunas otras cosas, como nuestro bloque “Serie de artículos” (un h4y olcon un divenvoltorio especial con una clase) y bloques de notas al pie y demás.

Pero en realidad también necesitamos algunos bloques personalizados, y para eso usé create-guten-block para crear un complemento especial¹ para crearlos. Veo que uno que es muy importante para nosotros son los bloques de código. Ya existe un bloque nativo para bloques de código. Básicamente, coloca el código en una preetiqueta y el contenido de Gutenberg ya está escapado de forma predeterminada.

Nuestro elegante bloque de código nos permite elegir el idioma, resaltar ciertas líneas y proporcionar etiquetas personalizadas. Todo esto era posible en nuestro antiguo editor a través de atributos HTML, por lo que este bloque es una interfaz de usuario agradable además de todo eso.

That block is so specific to CSS-Tricks it doesn’t make much sense to open source it. But there is another block I created that is open source, and that’s the CodePen Embed Block. I wrote about it over on the CodePen blog.

It allows you to paste in a CodePen URL and it transforms into a CodePen Embed. oEmbed already does that by default, but with this plugin, you can control everything like the height, theme, and default tabs.

It’s pretty awesome to actually see the embedded Pens while authoring!

Unfaced challenges

The biggest challenge right now is handling images. In the old editor, we have integrated a very very fancy setup with Cloudinary. The images are automatically uploaded to Cloudinary, breakpoints are programmatically decided on, multiple sizes are created, a responsive images syntax is created, and what ends up in the HTML is a perfect responsive images syntax with the images hosted by Cloudinary. This has the provided us with the benefit of being on a CDN and serving the images in the best possible format as well.

None of that is happening on posts created with Gutenberg.

I need to find or develop a new system that does a great job with images everywhere on the site and ideally with a less bespoke system that is easier to maintain. It’s possible I figure that out with Cloudinary, I might try some other service, I might let WordPress deal with it directly backed by the Jetpack Site Accelerator. Not sure yet. Always something to do.

1. I see WordPress themselves is getting in on the block scaffolding game. Their “create-wordpress-block” concept has made its way into the Gutenberg repo itself, which you kick off with npm init @wordpress/block [options] [slug]