Gutenberg, nuestras impresiones desarrollando

Al menos de que Ud haya estado viviendo en la parte más baja del Gran Cañón en los últimos 12-18 meses (sin acceso a Wifi), cualquier otra persona que se dedique a desarrollar sitios Web en WordPress ha escuchado el término Gutenberg en WordPress,  la nueva experiencia de escribir contenido en WordPress. Está ya casi por salir y estamos ante los últimos momentos del editor normalón de WP, que nos ha acompañado ya por mucho tiempo.

Nuestras impresiones como desarrolladores ha de ser de ambos lados, y es por eso que nos pagan el billete para resolver (en dólares ojalá por aquello de las crisis fiscales). Del lado como usuarios de la plataforma y del lado como desarrolladores. Trataré de citar ambas cosas brevemente.

Gutenberg como usuario

No hay ninguna duda, la mayoría de personas que usan sitios Web en WordPress no tienen la más mínima idea de cómo funciona WordPress, la Web, o inserte cualquier terminología Web que se le ocurra, de esas que la gente se le queda viendo a uno con cara de WTF cuando las dice.  La gente sólo quiere logearse a WordPress, escribir y ver las varas allí en la Web en dos toques, aunque sea para poner citas de Paulo Coelho.

Habiendo dicho semejante obviedad, Gutenberg  del lado del usuario es algo precioso. El editor enriquece la experiencia de usuario como tal (UX) y el que me dice que no, comente abajo para iniciar una ciberguerra de geeks. WordPress no es el único CMS  en el mercado, y con plataformas como Wix, Medium, etc, es deber de WordPress como comunidad de mantenerse vigente y el editor es algo muy pero muy tuanis de usar. Yo al menos, considero esto un paso hacia dicha dirección.

La adición de bloques de contenido le permite al usuario final agregar varas que antes en WordPress eran engorrosas de implementar desde un punto de vista de desarrollo. Hablo de galerías, de botones, de tablas, de links, etc mediante el editor. Había que recurrir a shortcodes, siendo estos un DOLOR DE YA SABE QUE dentro del editor de implementar por que tenían que seguir una sintáxis muy específica que para un usuario normalón, era difícil de recordar-ejecutar. Pero uno no se quejaba. Nada más implementaba y rezaba a que el cliente escribiese el shortcode TAL CUAL.

El editor es muy rico en cuanto a lo reactivo que es, fruto de lo que la Web hoy es. Queremos cosas reactivas, queremos que los likes se vean en tiempo real, que cuando le doy insertar un botón en el editor de WordPress, me inserte el mae sin tener que «esperar» para verlo, y asi sucesivamente. La mayoría de personas que tienen sitios Web en WordPress son usuarios que están usando la Web de esta manera y es nuestro trabajo como desarrolladores procurar que así sea.

El editor también es fantástico en cuanto a opciones; galerías, botones, citar, insertar imagen y tener control sobre ellas, en tiempo real. El editor clásico es muy a lo Word, y está bien, pero eso ya pertenece a otra era. Qué viejo me estoy poniendo.

Gutenberg como desarrollador

Pero suficiente sobre lo que ya sabemos, es hora de hablar de lo jarcor. El código/desarrollo como tal. Como todo el mundo y su mamá ya sabe, Gutenberg está montado sobre una capa de abstracción que está por encima de React y React DOM, por aquello de que a Zuckerberg se le vuelquen las tuercas y diga no más React o yo qué sé. La cuestión es que es hora de hacer las de Vegeta en Dragon Ball Z y meterse a la habitación del tiempo y entrenar, por que toca aprender un poco acerca de nuevas tecnologías que quizás no estábamos al tanto.

Al menos yo, que vengo de un backgroud más de PHP y lenguajes orientados a objetos, así ha sido y me he tenido que incursiornar más a Javascript, «si, si, esa vara que sirve para hacer popups» dijo un profesor de la Universidad Nacional de la carrera de Ingeniería en Informática hace poco menos de 3 años. Este cambio ha sido duro, pero bonito. Lo he disfrutado. Pero hablaremos más sobre eso en un futuro, hasta el momento, los issues que he tenido que ver, debajo de la capa han sido los siguientes:

Custom Post Types

Yo utilizo Custom Post Types más veces de las que Albino Vargas dice la palabra huelga. Mi sorpresa enorme fue darme cuenta que Gutenberg no viene habilitado para Custom Post Types ya hechos. Antes de ponerme como legítimo bistec de Palí (solo nervios) y temiendo lo peor, indagando un poco me dí cuenta que para habilitar la opción dos cosas deben de suceder. La primera, que el argumento show_in_rest debe de ser TRUE a la hora de declarar el Custom Post Type y la segunda, que dentro del array de supports, debe de estar el editor. En código esto sería (ojo a los comentarios):

 $args = array(
        'labels' => $labels,  
        'public' => true, 
        'publicly_queryable' => true,
        'show_ui' => true,
        'query_var' => true,
        'menu_icon' => 'dashicons-image-flip-horizontal',
        'rewrite' => true,
        'capability_type' => 'post',
        'show_in_rest' => true, // este mae
        'hierarchical' => false,
        'menu_position' => 25,
        'has_archive' => true,
        'rewrite' => array('slug' => 'my-slug/my-name', 'with_front' => false ),
        'supports' => array('title', 'editor', 'thumbnail') // y este mae
    );

Haga eso, y le aparecerá el editor Gutenberg para el post type. Para más información sobre los argumentos a la hora de declarar un Custom Post Type, el Codex, el Codex, el Codex!

Deshabilitar algunos bloques

Amamos a nuestros  clientes. Tanto así que les tenemos que quitar opciones para que no se caguen en el sitio a la hora de entregarles el sitio final en WordPress. Con Gutenberg huelo peligros en ese aspecto. Veo botones, opciones para colorearlos, veo tablas, opciones para elegir bordes, insertar comentarios de un solo leñazo, insertar categorías, etc. Estas cosas desde un punto de vista de usuario de WordPress que usa una plantilla, genial, pero para nosotros nos pagan el dólar todo-poderoso para diseñar sitios Web personalizados e implementarlos en WordPress, nos huele a danger. Darles estas opciones al cliente puede ser peligroso por que no son elementos que hayamos estilizado según el diseño final que hayamos implementado y eso puede terminar por romper el sitio y que se vea horroroso. Por lo tanto, hay que deshabilitar a HUEVO ciertos bloques a futuro, para que el cliente pues, di, no sea cliente y la cague. En el editor antiguo hacíamos precisamente eso. Deshabilitar las opciones de formatear el texto para que el cliente no haga textos de color naranja, verde, rosado e inserte todos los colores del arcoiris acá. Por que, son clientes, y eso es lo que los clientes hacen!

Indagando un poco, hemos averiguado que si se puede hacer mediante hooks que están disponibles para las versiones de WordPress que soportan Gutenberg, para así deshabilitarlas por defacto. Más sobre esto en un futuro.

Lo que retorna el bloque

Hemos usado únicamente los bloques que vienen en Gutenberg por defecto. Genial, pero como desarrolladores jarcor y fieles amantes de WordPress que somos, vamos a necesitar ya sea mayor control sobre lo que el bloque en específico retorna, o sino crear nuestros propios bloques para tener dicho control. Esto lo decimos por una cuestión de layout en el front-end para así poder estilizar posteriormente. Esto aún no lo hemos tocado debido aún por que vamos a hacerlo por las buenas. Osea, editando el CSS para que que entre si o si.

Y por el momento, eso sería. Espero que tengan conocimiento que decirnos en los comentarios y con todo el gusto despejamos dudas en caso de que las haya. Happy coding!