hand Inicio

SERVICIOS

Salir

nochedía

Desarrolla un theme en WordPress con React

2400 palabras
9 minutos
July 24, 2020

WordPress es React, pero parece que sólo lo sea para Gutenberg, y que en el frontend no tengamos posibilidad de utilizar esta librería

En absoluto, en este curso vemos cómo integrar React tanto en el backend como en el frontend

Prólogo

En su momento, WordPress se modernizó abrazando React en su desarrollo y esto abrió las puertas del ecosistema WordPress a todo un mundo de posibilidades

Sin embargo, parece que la manera de combinar React y WordPress se limita a consumir WordPress desde la REST API de manera offline desde entornos React más modernos (como Gatsby)

Es decir, utilizar WordPress como un gestos de contenidos backend y headless

Cuál es la limitación para no poder integrar React no sólo en Gutenberg sino también en el frontend de WordPress?

Ninguna

Lo vemos en este curso

Qué haremos en este curso

Desarrollaremos un theme de WordPress que será una aplicación React integrada en WordPress y que nos permitirá, por ejemplo, utilizar @emotion para gestionar nuestros estilos

Lo mejor de este desarrollo es que no estamos hablando de desarrollar un theme separado de WordPress, que aunque consumirá su contenido deberá alojarse en otro servidor

Aquí estamos hablando de un theme al uso, hospedado con WordPress, con una página (en este caso será una única página) que podremos editar, y con acceso a todos los plugins que queramos

Y esto lo podremos hacer porque nada nos impide utilizar el React que WordPress ya incluye en el backend, también en el frontend

Las ventajas de hacerlo así?

  • Programar con React es una delicia
  • Disfrutas de todas las ventajas de un desarrollo moderno
  • Y además puedes desarrollar una vez y aprovecharlo para el frontend y para Gutenberg

Vamos allá, y tienes el repositorio en github.com/kuworking/wordpress-theme-kuworking-landing-one

  1. Prólogo
  2. Qué haremos en este curso
  3. Entorno de trabajo
  4. Preparar el bloque de Gutenberg y la aplicación React
  5. Los estilos generales
  6. Quitando archivos que no necesitaríamos de WordPress y Timber
  7. index.php
  8. index.twig
  9. base.twig
  10. html-header.twig
  11. functions.php
  12. Bloque Gutenberg
  13. Aplicación React
  14. Probar el theme

Entorno de trabajo

Para la programación en React con vscode tienes la configuración del entorno de trabajo en este curso

Además, necesitarás tener una instalación WordPress

Si la quieres en local y en entorno Windows tienes este curso

Con esto, te faltaría añadir algunas extensiones para trabajar con php y twig, algo que ya me gustaría que estuviera tan estandarizado como para JavaScript (en unos momentos te explico los archivos twig)

Yo utilizo

  • Format HTML in PHP (rifi2k)

  • Twig Language 2 (mblode)

  • Phpfmt - PHP formatter (kokororin)

Y con esta última tengo añadir la localización de mi php.exe que está instalado via Laragon, esto lo hago en el archivo (que lo creo) en /.vscode/settings.json

A partir de aquí, ya casi lo tienes todo, el theme llevará de serie Timber

Qué es Timber?

Timber / Twig es un sistema que te moderniza WordPress en tanto a liberarte de las "antiguedades" de php, y que aquí utilizaremos para vehicular la transición entre WordPress y React

Es Timber absolutamente necesario?

En absoluto, podrías hacer exactamente lo mismo con php

Timber forma parte de una familia de entornos de desarrollo / starters que te permiten mejorar y mucho la experiencia de desarrollo en WordPress

Ejemplos de alternativas a Timber o soluciones que se basan o pueden basar en Timber serían estos

La mayoría de los listados arriba mejoran mucho el desarrollo en WordPress, pero al mismo tiempo generan una barrera inmensa para el usuario final que no es desarrollador, por lo que su adopción sólo parece razonable si se controla no sólo el desarrollo sino el mantenimiento del site

Ya que nuestro desarrollo se basa en Timber, para nuestro theme utilizaremos el starter de Timber

Ahora necesitaremos preparar el mismo entorno que pusimos para desarrollar un bloque Gutenberg (tienes el curso aquí)

Resumiendo se trata de un entorno React con NodeJS y Webpack para escribir en JavaScript moderno y generar una versión compatible con JavaScript no tan moderno que es la que WordPress consumirá

Necesitamos el paquete @wordpress/scripts para desarrollo y los paquetes de @emotion para producción, también añado un paquete que integra twig en prettier

Lo tienes resumido en mi package.json (lo tienes en el repositorio, aquí muestro la parte relevante):

Instalamos los paquetes bien editando el package.json y ejecutando yarn o instalándolos directamente con yarn ... y ya lo tendremos todo preparado

Asumo que NodeJS y yarn ya están instalados

Sólo nos falta asegurarnos que la carpeta que hemos clonado arriba esté en la carpeta de WordPress /wp-content/themes

O bien la clonamos directamente allí, o simplemente movemos la carpeta y después la abrimos otra vez con vscode

Y ahora sí, ya podemos activar el theme y ya podremos continuar

Bueno, casi

Para el desarrollo nos falta instalar Composer

Si has instalado WordPress localmente (antes te he referido al curso), ya tendrás php instalado y ya puedes instalar Composer siguiendo la documentación oficial

Una vez instalado, tenemos el archivo madre de composer en composer.json

Ahora sólo nos falta ejecutar composer install (si no te reconoce el comando en vscode posiblemente estés en el terminal powershell, prueba a cambiarlo con la opción "select default shell" por el cmd bash de toda la vida y ahí ya te lo debería reconocer)

Esto nos instalará Timber

Y ahora ya sí, ya lo tenemos todo preparado para continuar

Preparar el bloque de Gutenberg y la aplicación React

Antes de desarrollar los bloques, tenemos claro que necesitaremos generar dos archivos

  • El correspondiente al bloque de Gutenberg
  • El correspondiente a la aplicación React del frontend

Esto es tan sencillo como generar 2 archivos distintos y después importarlos como toque, pero aquí esos 2 archivos se compilarán con Webpack, y si no le decimos nada, por defecto nos generará sólo 1 archivo final

Para configurarlo necesitamos crear el archivo webpack.config.js en la carpeta base /

Eso lo podemos hacer porque @wordpress/scripts ya utiliza webpack con lo que sólo tenemos que modificar su configuración

Allí importaremos la configuración que WordPress utiliza, y le añadiremos dos cosas:

  • Que genere 2 archivos finales a partir de 2 archivos de inicio
  • Que genere enlaces "simbólicos" que nos vinculen el React de WordPress con el React verdadero, que tienen nombres distintos

Con esto estamos diciendo que nuestros dos archivos raiz serán el /src/index.js y el /src/gutenberg/card.js

Pronto los crearemos

Los estilos generales

Nuestro theme necesita por convenio un archivo style.css

Pero si vamos a utilizar @emotion debería estar vacío, no?

No, por dos razones

  • Aprovecharemos para definir ciertos estilos e importar fuentes ya que esta hoja de estilos se cargará más rápido que las de @emotion

  • Y lo utilizaremos también para anular ciertos estilos de Gutenberg y estilos en general que quedan fuera de la aplicación de React (fuera de lo que sería su scope), con lo que desde allí no podremos modificarlas

Y además, aquí es donde cambiamos el nombre de nuestro theme si nos apetece

Quitando archivos que no necesitaríamos de WordPress y Timber

Para el desarrollo de este theme, que será una simple página sin funcionalidad, no necesitamos nada que nos gestione el loop y compañía, por lo que he eliminado la mayoría de los archivos .php y .twig que vienen con el starter, puedes explorarlo en el repositorio

index.php

Aquí vemos que Timber se nos inicializa implementando un context y nos añade la información de los posts y nos define el orden de las templates

Esto no lo necesitaríamos puesto que

  • No tendremos posts
  • Sólo tendremos una única template

Podríamos dejarlo así

Pero por si en un futuro queremos extender nuestro theme, lo dejaremos como está y por lo tanto mantendremos la template index.twig que hará poco menos que nada (lo vemos en un momento)

En resumen, este archivo nos vehicula Timber y nos apunta a index.twig

index.twig

Este archivo nos sobra, lo dejamos por lo dicho anteriormente pero ya puedes ver que no hace nada relevante, más allá de importar (o más bien extender) base.twig

base.twig

En este archivo pasa parte importante de la acción, pero como aquí lo delegamos todo a React en realidad pasa poca cosa

Poca cosa pero importante

En resumen, este archivo nos define el documento html, y por el camino

  • Nos llama a la función que nos insertará React
  • Nos llama a html-header.twig y nos incluye su bloque head, que ahora veremos

  • Nos define el ancla desde donde insertaremos nuestra aplicación React

  • Y nos expone datos que nos serán de utilidad

Esto de exponer los datos es lo que nos permite relacionar nuestra aplicación React con los datos que WordPress gestiona

Cómo lo estamos haciendo?

Con php escribimos un JavaScript que nos escribe una variable global

Y luego desde React leeremos esos datos a través de esa variable global

Es decir, queda clarísimo que aquí estamos uniendo dos entornos de trabajo completamente separados, y de aquí que tengamos que utilizar este tipo de intermediario

Esto en realidad no es tan distinto de lo que hace Gatsby, puesto que NodeJS se comunica con el site estático a través de datos JSON, NodeJS los escribe, el sitio web estático luego los leerá

De este modo tenemos el control absoluto sobre lo que exponemos y lo que no exponemos, y eso es importante

Para exponer nuestra información a JavaScript podríamos utilizar wp_add_inline_script, pero al final termina haciendo exactamente lo mismo que hemos hecho arriba, con lo que es mucho más cómodo hacerlo directamente en la template

Dicho esto, una pregunta razonable sería por qué en lugar de exponer estos datos de php a JavaScript no nos limitamos a llamar a los datos sólo con JavaScript y la REST API, que para algo la crearon

El problema de utilizar la REST API online (y no consumirla offline como hace Gatsby y compañía) es que el coste de hacer peticiones http es alto (puedes buscar en google para ver si el tema ha mejorado, y explorar un hack aquí)

html-header.twig

En este archivo nos limitamos a añadir los datos convencionales de un documento html al uso

Aquí también es donde jugaríamos con el SEO directamente o mediante plugin

functions.php

Este es el archivo madre de todos los archivos, el que gestiona nuestro website, y el que presenta una estructura caótica y que va muy bien separar en archivos individuales

Comparado con Gatsby, sería el gatsby-node.js de allí, y que también conviene separarlo en archivos distintos

Aquí no lo he hecho porque creo que aún no ha llegado a esa longitud crítica donde no se entiende nada, pero está en la TODO list

Vamos a verlo

En este archivo hay mucha chicha, vamos a ver las partes relevantes en detalle

Básicamente, si nadie utiliza JQuery, pues lo quitamos

Registramos un bloque con enqueue_block_editor_assets donde apuntamos al archivo card.js que webpack nos habrá compilado dentro de la carpeta build (lo hemos visto antes)

Y utilizamos las ayudas que nos da @wordpress/scripts que en este caso es darnos el archivo card.asset.php con las dependencias que necesitamos y un número de versión para evitar que tengamos efectos de caché no deseados

Aquí añado una nueva categoría dentro de los bloques de Gutenberg, luego utilizaré esta categoría cuando genere el bloque en el mismo archivo card.js

Y aquí genero una página que será la página principal

En lugar de hacerlo podría generar instrucciones diciendo que se generase una página, que se configurase como página princpal, y que se añadiese el bloque definido en card.js

Pero es mejor generar ya la página y que las instrucciones se limiten a editar esa página y listos

Para hacerlo utilizo esta función donde busco si esa página ya existe (si está en la papelera, cuenta) y si no existe la genero con wp_insert_post()

Y para añadirle el bloque por defecto simplemente le añado el código html correspondiente a mi bloque, que es el que ves en la variable $new_page_content (aquí tienes la documentación)

Aquí añado la página de estilo que me afectará al editor Gutenberg, y lo necesito para anular ciertos estilos que destruyen la estética del bloque en sí

Esto ocurre porque mi bloque no es un bloque como tal sino que es la página principal en forma de bloque, y necesito salir de las constricciones que Gutenberg impone a todos los bloques por defecto

En concreto, en styles.css tengo el código

Y este selector apunta al bloque dentro de Gutenberg

Aquí añado el otro script, el index.js, que a diferencia de antes que iba para bloque de Gutenberg, aquí va para el frontend y utilizo wp_register_script

Aquí también podría utilizar el assets como antes, aunque en este caso he optado por mantenerlo más manual, algo que tengo que reflexionar

Y si antes añadía la aplicación React, aquí añado el bloque de Gutenberg, es decir sus atributos, separados con la función parse_blocks() para asignarlo a la variable global de JavaScript

Es decir, aquí expongo datos de WordPress en JavaScript, y así podría exponer los datos de los posts, de un menú, de un único post, etc etc

Luego estos datos los leeré desde la aplicación React

Bloque Gutenberg

Si nos vamos a /src/card.js tenemos el bloque de Gutenberg como tal

No me entretendré, simplemente remarcaré lo más relevante

  • Importo React de @wordpress/element
  • Utilizo @emotion
  • Importo el componente HallGutenberg que al final me definirá la aplicación React

El funcionamiento lo puedes ver en el curso que antes mencionaba sobre bloques Gutenberg y React

Básicamente defino unos atributos, con un valor default vacío

Este valor vacío de default me permitirá luego en el useEffect asignar los valores por defecto a cada atributo

Por qué no hacerlo directamente en el default? Porque entonces no se guardan, y te encuentras en la situación de que cualquier valor que el usuario no edite quedará vacío

Esto es malo, pero lo podemos solucionar de esta manera

Por lo demás hay cierta lógica JavaScript para posicionar los elementos a una altura coherente con el renderizado de la aplicación y nada que no viéramos en el curso anterior, incluyendo el registerBlockType donde le especifico la categoría que antes he creado

Aplicación React

Y con esto ya llegamos a la aplicación React que nace en index.js

Allí hacemos dos cosas importantes

  • Renderizamos <Hall/> en el ancla que antes habíamos puesto en la template de twig, y lo hacemos utilizando JavaScript "clásico" con un EventListener

  • Y definimos la variable global con la que expondremos todo lo que nos interese de WordPress - php

Si ahora nos vamos a hall.js, allí vemos la diferencia entre <HallGutenberg> y <Hall>

Pero lo más importante:

  • Importo React desde wp.element
  • Utilizo @emotion en el frontend

Es decir, estoy utilizando React integrado en WordPress de forma que casi parece un ciudadano de primera clase

El primero aplica los estilos globales que están guardados arriba en la variable globalStyles en un <div> que hará de padre y servirá para representar ese componente

El segundo aplica esos mismos estilos globales pero de verdad, en el elemento html con el componente <Global> de @emotion

La otra gran diferencia es que <HallGutenberg> tiene a los atributos definidos allí mismo, mientras que <Hall> los recibe expuestos en JavaScript, con lo cual incluye la rutina de volcar esos datos en un useState

El resto del código es React puro, una aplicación que consta de dos páginas que se extienden a todo el ancho disponible

Lo más interesante de esto es que la aplicación en realidad vive en <Components>, y este componente sólo lo definimos una vez y nos sirve tanto para el editor como para el frontend

Esto, que quizá parezca poca cosa, acelera en mucho el desarrollo de themes ya que transformar tu aplicación React a un bloque Gutenberg pasa a ser algo muy directo

Probar el theme

Una vez terminado el theme, lo encapsulamos en un zip (puedes explorar el archivo zip.js que hace precisamente eso) y ya lo podemos subir a nuestro WordPress para probarlo

Puedes descargártelo del repositorio aquí

[ El repositorio lo tienes en github.com/kuworking/wordpress-theme-kuworking-landing-one ]

Listos!

🙋‍♂️

Qué tal el curso?
👌 Bien 🙌🙌
👍 Bien, pero algunas cosas podrían explicarse mejor 😬
🤷‍♂️ Da por sentadas demasiadas cosas 😒
🤷‍♂️ A ver, hay poca chicha 😬
🤷‍♂️ Los ejemplos no son muy claros 🙇‍♂️
🤷‍♂️ No se entiende, está mal escrito 👎
✍️ Hay errores, revísalo en cuanto puedas 🙏

Quizá te interese

Privacidad
by kuworking.com
[ 2020 >> kuworking ]