Transformaciones de bloques de WordPress

Este ha sido el año de Gutenberg para nosotros aquí en CSS-Tricks. De hecho, ese es un objetivo que nos fijamos a finales del año pasado. Estamos mucho más avanzados de lo que pensaba, creando todo el contenido nuevo en el editor de bloques ¹, habilitando el editor de bloques para todo el contenido ahora. Eso significa que cuando abrimos la mayoría de las publicaciones antiguas, vemos todo el contenido en el bloque “Clásico”. Se parece a esto:

Todo el contenido de la publicación está en un solo bloque, por lo que no se utiliza exactamente el editor de bloques. Sigue siendo “visual”, como el editor de bloques, pero se parece más al antiguo editor visual que usaba TinyMCE. Nunca usé eso porque destrozaba HTML con fuerza de una manera que no me gustaba.

Esto es lo número uno que me preocupaba.

Transformar un bloque clásico en bloques nuevos es tan trivial como seleccionar el bloque clásico y seleccionar la opción “Convertir en bloques”.

¿Cómo maneja el editor de bloques el contenido antiguo que se bloquea cuando le indicamos que lo haga desde la opción “Convertir en bloques”? ¿Qué pasa si arruina totalmente el contenido durante la conversión? ¿Podremos alguna vez cambiar?

La respuesta: hace un trabajo bastante bueno. Pero… todavía hay problemas. No “errores”, sino situaciones en las que tenemos HTML personalizado en nuestro contenido antiguo y no sabemos qué hacer con él, y mucho menos cómo convertirlo exactamente en los bloques que deseamos. ¡Hay una manera!

Transformaciones de bloques básicos

Ahí es donde entra en juego esta idea de “Transformaciones de bloque”. Todos (bueno, ¿la mayoría?) los bloques nativos tienen transformaciones “hacia” y “desde”. Probablemente ya estés familiarizado con cómo se manifiesta en la interfaz de usuario. Como un párrafo se puede transformar “en” una cita y viceversa. Aquí hay una súper meta captura de pantalla de este mismo párrafo:

Esas transformaciones no son mágicas; están codificados de forma muy clara. Cuando registras un bloque, especificas las transformaciones. Digamos que estaba registrando su propio bloque de código personalizado. Querrás asegurarte de poder transformarlo…

• Desde y hacia el bloque de código integrado predeterminado, y probablemente algunos otros que podrían ser útiles.
• Volver al bloque de código incorporado.

Que podría verse así:

registerBlockType("my/code-block", {  title: __("My Code Block"),  ...  transforms: {    from: [      {        type: "block",        priority: 7,        blocks: ["core/code", "core/paragraph", "core/preformatted"],        transform: function (attributes) {          return createBlock("my/code-block", {            content: attributes.content,          });        },      },    ],    to: [      {        type: "block",        blocks: ["core/code"],        transform: ({ content }) = createBlock("core/code", { content }),      },    ],      ...

Esas son transformaciones hacia y desde otros bloques . Afortunadamente, este es un bloque bastante simple en el que simplemente estamos barajando content. Es posible que los bloques más complejos necesiten transmitir más datos, pero aún no he tenido que lidiar con eso.

Lo más mágico: transformaciones en bloque a partir de código sin formato

Aquí está el momento de la verdad para el contenido antiguo:

En esta situación, los bloques no se crean a partir de otros bloques, sino a partir de código sin formato. Literalmente, se analiza el HTML y se toman decisiones sobre qué bloques crear a partir de fragmentos de ese HTML. Aquí es donde es sorprendente que el editor de bloques haga un buen trabajo con las opciones, y también donde las cosas pueden salir mal y fallar, tomar decisiones de bloque incorrectas o alterar el contenido.

En nuestro contenido anterior, un bloque de código (algo muy importante) en una publicación se vería así:

pre rel="JavaScript"code markup="tt"  let html = `divcool/div`;/code/pre

A veces, la conversión de bloques funcionaría bien en ellos, convirtiéndolos en un bloque de código nativo. Pero hubo una serie de problemas:

1. No quiero un bloque de código nativo. Quiero que eso se transforme en nuestro propio bloque de código nuevo (escribí sobre eso aquí).
2. Necesito parte de la información en esos atributos para informar la configuración del nuevo bloque, como qué tipo de código es.
3. El HTML de nuestros bloques de código antiguos no se escapó y necesito que no se ahogue con eso.

No tengo todas las respuestas aquí, ya que este es un proceso en evolución, pero ahora tengo algunas transformaciones de bloques implementadas que están funcionando bastante bien. Así es como se ve una transformación "sin procesar" (a diferencia de una transformación de "bloque"):

registerBlockType("my/code-block", {  title: __("My Code Block"),  // ...  transforms: {    from: [      {        type: "block",        priority: 7,        // ...      },      {        type: "raw",        priority: 8,        isMatch: (node) =          node.nodeName === "PRE"           node.children.length === 1           node.firstChild.nodeName === "CODE",        transform: function (node) {          let pre = node;          let code = node.querySelector("code");          let codeType = "html";          if (pre.classList.contains("language-css")) {            codeType = "css";          }          if (pre.getAttribute("rel") === "CSS") {            codeType = "css";          }          if (pre.classList.contains("language-javascript")) {            codeType = "javascript";          }          if (code.classList.contains("language-javascript")) {            codeType = "javascript";          }          // ... other data wrangling...          return createBlock("csstricks/code-block", {            content: code.innerHTML,            codeType: codeType,          });        },      },    ],    to: [      // ...     ],      // ...} 

Esa isMatchfunción se ejecuta en cada nodo del HTML que encuentra, por lo que esta es la gran oportunidad de regresar truede ella en las situaciones especiales que necesite. Tenga en cuenta en el código anterior que estoy buscando específicamente HTML que se parezca a pre ...code .... Cuando eso coincide, se ejecuta la transformación y puedo devolver una createBlockllamada que pasa los datos y el contenido que extraigo del nodo con JavaScript.

Otro ejemplo: pegar una URL

Las transformaciones "sin procesar" no solo ocurren cuando se "convierte en bloques". También ocurren cuando pegas contenido en el editor de bloques. Probablemente hayas experimentado esto antes. Digamos que has copiado algunas marcas de tabla de algún lugar y las pegas en el editor de bloques; probablemente se pegará como una tabla. Es posible que una URL de YouTube se pegue en una inserción. Este tipo de cosas es la razón por la que copiar y pegar documentos de Word y similares tienden a funcionar tan bien con el editor de bloques.

Supongamos que desea un comportamiento especial cuando se pega un determinado tipo de URL en el editor. Esta era la situación en la que me encontraba con nuestro bloque CodePen Embed personalizado. Lo quería para que, si pegabas una URL de codepen.io, usara este bloque personalizado, en lugar de la inserción predeterminada.

Esta es una transformación "de" que se ve así:

{  type: "raw",  priority: 8, // higher number to beat out default  isMatch: (node) =    node.nodeName === "P"     node.innerText.startsWith("https://codepen.io/"),  transform: function (node) {    return createBlock("cp/codepen-gutenberg-embed-block", {      penURL: node.innerText,      penID: getPenID(node.innerText), // helper function    });  },}

Entonces…

¿Está desordenado? Un poco. Pero es tan poderoso como necesitas. Si tiene un sitio antiguo con mucho HTML personalizado, códigos cortos y demás, entonces entrar en transformaciones de bloques es la única salida.

Me alegro de haber ido a WPBlockTalk y haber visto la charla de K. Adam White sobre códigos cortos porque solo hubo una diapositiva que me indicó que esto era posible. Hay un poco de documentación al respecto.

Una cosa que me gustaría saber es si es posible ejecutar estas transformaciones en todo el contenido antiguo de la base de datos. Parece un poco aterrador, pero también podría ser una buena idea en algunas situaciones. Una vez que tenga mis transformaciones realmente sólidas, podré ver cómo hacerlo para que cualquier contenido antiguo esté listo para usar en el editor de bloques al abrirlo. Simplemente no tengo idea de cómo hacerlo.

Sin embargo, me alegro de estar al tanto de esto, ya que me encanta el editor de bloques en este momento. Es un placer escribir y crear contenido con él. Me gusta lo que dijo Justin Tadlock:

El sistema de bloques no va a ninguna parte. WordPress ha ido más allá del punto en el que deberíamos considerar el editor de bloques como una entidad separada. Es una parte integral de WordPress y eventualmente tocará cada vez más áreas fuera de la pantalla de edición.

Llegó para quedarse. Adoptar el editor de bloques y adaptarlo a nuestra voluntad es clave.

1. ¿Cómo lo llamamos de todos modos? “Gutenberg” ya no parece correcto. Parece que eso se desvanecerá, aunque su desarrollo todavía ocurre en el complemento Gutenberg. Creo que lo llamaré simplemente "el editor de bloques" a menos que me refiera específicamente a ese complemento.