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.
Si no ha visto DBZ, veala y si ya la vio, entienda que es hora de entrar a la habitación del tiempo.
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):
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!
HOLA MARCO, EXCELENTE ARTICULO, MUY A TU ESTILO, ME DEVOLVIO MAS DE DIEZ AËœNOS ATRAS EN EL TIEMPO. VI QUE VAS A DAR UNA CHARLA JUSTAMENTE SOBRE ESTE TEMA EL MIERCOLES, AHI ESTARE PARA APROVECHAR DE TU CONOCIMIENTO, SALUDOS Y MUCHOS EXITOS COMO SIEMPRE!
Marco Berrocal
Otrs Artículos Míos 7 minutos leyendoGutenberg, 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):
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!
Un Comentario
HOLA MARCO, EXCELENTE ARTICULO, MUY A TU ESTILO, ME DEVOLVIO MAS DE DIEZ AËœNOS ATRAS EN EL TIEMPO. VI QUE VAS A DAR UNA CHARLA JUSTAMENTE SOBRE ESTE TEMA EL MIERCOLES, AHI ESTARE PARA APROVECHAR DE TU CONOCIMIENTO, SALUDOS Y MUCHOS EXITOS COMO SIEMPRE!
Deje Su Respuesta