DE{CODE}: Gutenberg y WordPress sin cabeza

Gutenberg, también conocido como bloques de WordPress, brinda a los productores de contenido nuevas y poderosas formas de diseñar contenido en un sitio tradicional de WordPress. Pero, ¿cómo pueden los desarrolladores de WordPress sin cabeza empoderar a los equipos de marketing con esas mismas capacidades? En esta sesión de DE{CODE}, el fundador de GraphQL para WordPress (WPGraphQL), Jason Bahl, comparte nuevas capacidades y mejores prácticas para usar el editor de bloques de WordPress en un sitio sin cabeza.

Diapositivas de la sesión

Transcripción de texto completo

JASON BAHL : Hola. Bienvenidos a mi charla sobre Gutenberg y Headless WordPress. Mi nombre es Jason Bahl. Soy el creador y mantenedor de WPGraphQL. Soy ingeniero de software principal en WP Engine. Puedes encontrarme en Twitter @jasonbahl o también en Twitter @wpgraphql.

Así que hoy, quiero hablarles sobre lo que es Gutenberg, WordPress sin cabeza, cuándo y por qué es posible que desee usar WordPress sin cabeza, cómo puede usar Gutenberg, específicamente, con WordPress sin cabeza, y cuándo y por qué WordPress sin cabeza y Gutenberg. juntos pueden tener sentido para sus proyectos.

Entonces, históricamente, WordPress ha tenido un editor que se parecía un poco a este. Hemos tenido un área de texto TinyMCE, donde podemos editar nuestro contenido. Podemos insertar medios y luego publicar nuestro contenido y luego, en 2018, apareció Gutenberg, este editor basado en bloques, que nos permite insertar contenido en este lienzo en blanco e interactuar con nuestro contenido a nivel de bloque.

Así que cada párrafo tiene ajustes. Cada imagen tiene ajustes. Cada galería, encabezado, cualquier cosa que se te ocurra para el contenido es lo que se llama el bloque. Y podemos ser realmente granulares con la forma en que controlamos nuestro contenido ahora y podemos arrastrarlo y soltarlo y componer nuestro contenido. Entonces, ahora es esta experiencia de edición muy rica en WordPress y es una introducción a lo que es Gutenberg.

Entonces, ¿qué es Headless WordPress ahora? Entonces, para entender Headless, veamos el WordPress tradicional. Entonces, WordPress tradicional, iniciamos sesión en WordPress, la interfaz de usuario de administración, y publicamos nuestro contenido y luego los usuarios visitan nuestro sitio, y PHP, el lenguaje que WordPress ha incorporado, representa la página. Entonces carga CSS, HTML y JavaScript y entrega la página al usuario. Así que eso es una especie de WordPress tradicional.

Con Headless WordPress, todavía usa WordPress como CMS. Todavía publica contenido, cura contenido, administra contenido en WordPress, pero en lugar de entregar una página en HTML al navegador, WordPress entrega datos típicamente en formato JSON, y luego las aplicaciones cliente pueden consumir esos datos para que podamos tener aplicaciones nativas de iOS o Android. o incluso aplicaciones de realidad virtual.

Mi colega, Anthony, compartió contenido sobre cómo usa WordPress para potenciar las aplicaciones de realidad virtual. O trabajé en un periódico donde usábamos WordPress como punto de entrada para nuestros periódicos impresos. Entonces, si estaba leyendo una copia impresa de un periódico impreso, estaba leyendo contenido producido en WordPress.

Y, por supuesto, también podemos usar esos datos para mostrarlos en la web, pero en lugar de estar bloqueados en las plantillas de PHP, tenemos flexibilidad para elegir cualquier tecnología de interfaz de usuario que queramos. Así que Headless desvincula el back-end, la gestión del contenido y la forma en que presentamos los datos que se gestionan en WordPress.

Entonces, hay dos formas comunes en que podemos usar estos datos. Podemos obtener datos en formato JSON de la API REST de WP, que es una API integrada en WordPress y hay otra API llamada WPGraphQL. Este es un complemento de código abierto que puede instalar y obtener datos de WordPress y JSON. Y hoy hablaremos de WPGraphQL.

Entonces, ahora que sabemos qué es WordPress, ¿por qué podría ir y crear proyectos de Headless WordPress? Como mencioné, tiene mucha flexibilidad para elegir su tecnología de front-end. Y para algunas personas, es muy importante poder elegir cómo construyen los proyectos front-end. Hay algunos marcos como Next y Gatsby y Svelte que realmente se enfocan en mejorar los elementos vitales principales de la web. Por lo tanto, es posible que pueda ir sin cabeza con WordPress y mejorar los signos vitales principales de la web.

Puede beneficiarse de cosas como la división de código en su código. Para que pueda crear componentes para su aplicación front-end. Y según el componente que se esté construyendo para la página específica, enviará menos o menos activos al cliente y acelerará sus páginas. Headless también brinda a los desarrolladores un control más preciso sobre la experiencia del usuario front-end, por lo que los complementos que se instalan en el administrador de WordPress tienen menos impacto en el front-end.

Por lo tanto, los usuarios administradores no pueden simplemente instalar complementos y agregar scripts arbitrarios o marcas arbitrarias al front-end de un sitio Headless. Es más un desarrollador define las restricciones en el front-end y WordPress recibe los datos enviados y luego una de las cosas que quiero introducir es la experiencia del desarrollador.

Con Headless WordPress, dado que tiene la flexibilidad de usar cualquier pila de tecnología que desee, existe el beneficio de una mejor experiencia de desarrollador en algunos casos. Y uno de esos casos en los que voy a entrar se llama desarrollo basado en componentes y hablaremos mucho sobre eso en un segundo.

Esas son algunas de las razones por las cuales. Entonces, ¿en qué situaciones podrías estar cuando quieras usar Headless WordPress? Bueno, si necesita crear aplicaciones no web como dispositivos móviles nativos, probablemente quiera ir a Headless. Una vez más, si sus datos vitales principales de la web son deficientes en su sitio de WordPress, su sitio de WordPress actual, o están bien, pero se está volviendo muy costoso mantenerlos en buen estado, es posible que desee considerar Headless.

Si tiene varias aplicaciones en su organización que necesitan obtener datos de WordPress, es posible que también deba usar Headless. Y si ya invirtió en una biblioteca de componentes o un sistema de diseño basado en componentes para su organización y necesita datos de WordPress, es posible que desee invertir en Headless. Si un equipo prefiere JavaScript y no le gusta construir cosas en PHP, esa también es una razón para considerar Headless.

Sin embargo, hay algunas razones por las que es posible que no desee utilizar Headless: actualmente, requiere un poco más de tiempo de desarrollo. Entonces, si tiene un presupuesto más bajo o reduce el tiempo y ya tiene soluciones en WordPress tradicional, es posible que aún no se vaya sin cabeza. Si los administradores de su sitio realmente necesitan controlar la instalación de complementos que modifican el front-end, es posible que aún no se vaya sin cabeza.

Si su equipo realmente prefiere PHP y no quiere aprender JavaScript o interfaces alternativas, también puede quedarse con WordPress tradicional. Y si no está interesado en un desarrollo basado en componentes o una biblioteca basada en componentes, si no tiene interés en eso, puede seguir con los flujos de trabajo de desarrollo tradicionales de WordPress.

Y si su web vital central en su WordPress tradicional es realmente buena, y sus costos de mantenimiento son muy bajos para que su sitio web funcione muy rápido, es posible que esté bien seguir con WordPress tradicional. Así que no tienes que ir sin cabeza. Pero voy a mostrarles por qué creo que quedarse sin cabeza puede ser bueno para algunos equipos.

Entonces, si observamos nuevamente la experiencia del desarrollador de WordPress, publicamos nuestro contenido en un campo que genera una gran parte de HTML. E incluso si usamos el editor Gutenberg, que tiene estos bloques granulares, el resultado final es una gran parte de HTML. Entonces, ya sea que publiquemos en Gutenberg o en el editor clásico tradicional, esta porción de HTML se envía a través de PHP a nuestro tema y tenemos una página global que carga nuestro HTML, nuestro CSS y nuestro JavaScript. Y estos activos se aplican a la página globalmente.

Por lo tanto, los desarrolladores de WordPress generalmente separarán nuestro desarrollo en función de los tipos de archivos, por lo que colocaremos nuestro CSS en archivos separados que se aplicarán globalmente a la página, o HTML se escribirá en PHP, y extraeremos los datos que necesitamos de WordPress y luego JavaScript. escribirse muchas veces con jQuery en archivos separados. Y entonces estas tres cosas se unirán para construir la página.

El problema es que estos no están aislados, se aplican a toda la página. Así que a veces puedes hacer un cambio. Como esto me pasó a mí. Una vez hice un cambio en un estilo en el pie de página de un sitio según lo solicitado por mi gerente y tres días después, se informó que el estilo en otra parte del sitio había cambiado debido a la revisión del código de acceso. Lo pasamos.

De repente, algo más en el sitio se rompió y esto se debe a que el CSS se aplica globalmente y puede afectar cosas de las que no te das cuenta. Sin embargo, hay una nueva tendencia en el pasado, no sé, siete u ocho años tal vez llamada arquitectura basada en componentes. Esto nos permite construir piezas específicas de nuestra aplicación en lo que se llama componentes.

Y podemos acoplar nuestro JavaScript, nuestro HTML, nuestro CSS en pequeños bits que podemos probar de forma aislada y así podemos construir partes de nuestra aplicación. Un par de preocupaciones, el marcado, los JavaScripts, los estilos, y podemos componer estos componentes juntos para construir aplicaciones más complejas.

Entonces, el desarrollo basado en componentes nos permite dividir funciones complejas en piezas aisladas más pequeñas y podemos probarlas de forma aislada, asegurarnos de que funcionen y luego podemos acoplar nuestras preocupaciones que deberían acoplarse. Cada segmento de la interfaz de usuario tiene una responsabilidad específica. Si es una tarjeta de imagen, podría ser responsable de representar la imagen en un tamaño determinado con una URL específica.

Por lo tanto, tiene dependencias de marcado. Tiene dependencias de estilo. Puede tener interacciones con estado. Todos estos están relacionados con ese componente específico. Entonces podemos acoplar nuestro marcado, nuestro JavaScript y nuestro CSS en un solo lugar, probarlo y asegurarnos de que funcione bien. Y debido a esto, podemos reutilizar estos componentes en toda nuestra aplicación, o incluso podemos reutilizar nuestros componentes en todos los proyectos.

Así que hay una tendencia llamada bibliotecas de componentes. Hay proyectos como Material UI, o componentes de diseño final, o Chakra UI también es popular. Y podemos usar estos componentes en todos los proyectos. Y podemos resolver preocupaciones centrales como el marcado accesible. Y podemos actualizarlos y aplicarlos en múltiples proyectos en nuestra organización a la vez y debido a esto, debido a estas razones, podemos iterar y enviar más rápido a menudo con mucha más confianza.

Entonces, ¿cómo podemos usar Headless WordPress entonces? Como mencioné antes, hay dos formas de obtener datos de WordPress y colocarlos en componentes. Una sería la API REST. Uno sería WPGraphQL. Mi amigo, Drake, ha estado construyendo sitios Headless por un tiempo, así que le pregunté y esto fue lo que dijo...

Prefiere WPGraphQL. Así que de eso vamos a hablar hoy. Entonces, ¿qué es WPGraphQL? Podrías preguntar. Bueno, es un complemento gratuito de WordPress de código abierto que proporciona un esquema GraphQL extensible y una API para cualquier sitio de WordPress. ¿Qué es GraphQL entonces? Bueno, es un lenguaje de consulta de gráficos.

Muy bien, Jasón. Todavía no entiendo lo que estás diciendo. Muy bien, entonces déjame mostrarte. Entonces, GraphQL, la forma en que funciona es que las aplicaciones cliente envían una solicitud especificando lo que quieren del servidor. Y una solicitud se parece a esto. Parece claves JSON sin valores. Entonces, en este caso, la solicitud solicita el visor y, en un visor, queremos que se devuelva el campo "nombre".

Y una respuesta del servidor GraphQL podría verse así. Sus datos, claves y valores JSON reales y coincide con la forma de la solicitud. Entonces, en este caso, obtenemos el nombre, o obtenemos al espectador con el nombre de Jason Bahl. Entonces, GraphQL, vamos a que las aplicaciones cliente eliminen los árboles del gráfico de datos de la aplicación.

Y lo que parece visualmente es algo como esto. Podemos ingresar al gráfico, digamos, agregar un visor o un campo de usuario o un nodo. Y ese nodo podría tener una propiedad como el nombre Jason. Y ese nodo podría tener conexiones con otros nodos en el gráfico como un avatar, que podría tener una propiedad como una URL de imagen.

Y ese usuario podría tener conexiones con otros nodos, como una publicación que haya creado ese usuario. Y esas publicaciones pueden tener propiedades como un título, hola mundo o adiós Marte. Y estas publicaciones pueden tener conexiones con otros nodos en el gráfico, como categorías con sus propios títulos, como noticias o deportes. Y esas categorías pueden tener conexiones con otros nodos y más publicaciones. Y esas publicaciones podrían haber presentado imágenes, etc., etc. Así que tenemos este gran gráfico de datos que podemos pedir con GraphQL.

Y entonces podemos usar herramientas en el administrador de GraphQL o en el administrador de WordPress. Hay una herramienta llamada GraphiQL, donde puedo redactar una consulta. Y aquí estoy seleccionando el campo Visor con subselecciones, nombre, avatar, la URL y cuando lo ejecutamos, obtenemos los campos que solicitamos y visualmente esa consulta se parece un poco a esto.

Entramos en la gráfica y preguntamos por un usuario. Pedimos el nombre del usuario, el avatar conectado en la URL del avatar. Tenemos todo este gráfico de datos disponible para nosotros, pero solo solicitamos un conjunto específico de datos y, en respuesta, obtuvimos ese conjunto específico. Entonces podemos tomar, ahora podemos usar componentes.

Así que hablé sobre los beneficios del desarrollo basado en componentes y quiero mostrarles esto en acción. Y esto es lo que yo llamaría un componente de presentación. Así que este es un componente de la tarjeta que es responsable. Tiene una responsabilidad de representar esta tarjeta con una imagen y un título.

Y podemos mirar el código y vemos que tenemos cierto control de estilo. Podemos establecer el ancho, podemos pasarle la imagen que queremos y podemos pasarle el título. Entonces podemos reutilizar este componente a lo largo de nuestro proyecto. Y este componente tiene todas las dependencias que necesitamos. Tiene el HTML para renderizar. Tiene los estilos. Tenemos algo de control de estilo aquí. Tiene algunos componentes con estado como el estado de desplazamiento y otras cosas.

Entonces, este es un componente aislado que podemos reutilizar y con GraphQL ahora, podemos tomar la consulta que acabamos de redactar en el administrador de WordPress usando GraphQL y podemos traer eso y tener un componente de tarjeta de visor ahora. Entonces podemos escribir nuestra consulta, acoplarla con nuestro componente de tarjeta y ahora completa el componente.

Tenemos nuestro HTML, CSS nuestro JavaScript. Y gracias a los datos, ahora tenemos algo que representar con los datos que solicitamos. Así que ahora podemos usar esto en toda nuestra aplicación y hay una característica de GraphQL llamada fragmentos y esto nos permite tomar nuestras consultas de GraphQL y dividirlas en piezas reutilizables.

Entonces, en este caso, estoy creando un fragmento de tarjeta de perfil de usuario y estoy especificando el nombre, el avatar y la URL y luego estoy usando ese fragmento en una consulta más grande. Cuando ejecutamos, obtenemos los resultados que esperamos. Ahora podemos tomar ese fragmento, ponerlo en un componente. Ahora tenemos un componente diferente llamado Tarjeta de perfil de usuario.

Esta tarjeta de perfil de usuario especifica que cada vez que consultamos a un usuario, debemos obtener el nombre, el avatar y la URL del avatar para usar en el componente. Entonces, ahora tenemos este componente reutilizable que en cualquier lugar de nuestra aplicación que solicitemos un usuario, podemos obtener los datos necesarios para generar esta tarjeta reutilizable con el avatar y el nombre del usuario.

Y entonces esto ahora puede incorporarse y usarse en partes más grandes de nuestra aplicación. Esta es la consulta que teníamos antes de que el espectador consultara usando el fragmento que estamos importando desde un componente de tarjeta de perfil de usuario reutilizable. Y luego lo enviamos a un componente de tarjeta de visor y ahora podemos reutilizarlo en nuestra aplicación.

Podemos hacer partes más grandes de nuestra aplicación que dependan de esta tarjeta de usuario o la tarjeta de autor. Así que ahora podemos tener múltiples componentes como el componente del título del blog que es responsable del título. Podemos tener una tarjeta de perfil de usuario que acabamos de crear que represente el perfil del usuario. Podemos tener un componente de contenido o extracto que sea responsable del marcado y los datos de esta parte de nuestra aplicación.

Y sí, podemos construir estos pequeños componentes que son responsables del marcado, el CSS y los datos necesarios para construir esta aplicación. Y podemos componerlos juntos. Podemos probarlos de forma aislada, también probarlos como unidades más grandes. Entonces podemos usar esto en varias plantillas también.

Podemos usar estos componentes reutilizables para una publicación de blog o nuestro rol de blog donde tenemos diferentes autores, pero podemos usar el mismo componente para representarlos. Podemos usarlo para la otra página de archivo. Muy similar a las partes de la plantilla de WordPress, podemos dividir nuestras aplicaciones Headless en partes pequeñas, pero obtenemos el beneficio de unir nuestra tecnología.

Así que eso es un poco sobre el desarrollador de Headless WordPress que experimenta el diseño basado en componentes y los beneficios de eso. Entonces, cuando se trata de Gutenberg, específicamente, ¿por qué considerarías Headless WordPress con Gutenberg específicamente? Bueno, si su equipo ya está usando Headless WordPress, posiblemente con Advanced Custom Fields y flexfields, y desea actualizar la experiencia del editor para usar Gutenberg, esa es obviamente una de las razones por las que podría usar Headless con Gutenberg.

Si desea beneficiarse de la creación de componentes que se usan en la administración y los componentes que se usan en el front-end, es una buena razón para considerar usar Headless con Gutenberg porque el editor de back-end de Gutenberg del editor de bloques está basado en componentes. Es posible que desee aprovechar la entrada estructurada. cada bloque en el administrador tiene campos que están estructurados.

Tiene atributos específicos que puede controlar en el nivel de campo. Y es posible que desee beneficiarse de que esa salida estructurada también llegue a sus componentes. Y como mencioné, es posible que desee reutilizar componentes y bloques en todos los proyectos. Por ejemplo, es posible que desee tener una biblioteca de bloques que su agencia haya creado y que resuelva problemas como la accesibilidad y las preocupaciones específicas de marcado que desea usar en todos los proyectos. Y luego puede actualizarlos en todos sus proyectos, no solo dentro de un proyecto individual.

Entonces, esta es una parte en la que los temas secundarios en WordPress pueden ser difíciles de escalar porque tiene que ir a cada sitio y actualizar el marcado y todo eso en cada sitio. Bueno, aquí puede usar bibliotecas de bloques como dependencias de NPM y actualizarlas en toda su organización.

Entonces, actualmente, el estado del desarrollo de WordPress con Gutenberg es que tenemos bloques en el backend, que están basados ​​en componentes. Podemos construir nuestros propios bloques personalizados o usar bloques básicos de WordPress. Pero la salida en PHP es, como mencioné, esa gran parte de HTML y, entonces, ¿cómo podemos pasar de obtener este bloque de HTML a tener componentes en el backend que también se transfieren a componentes en nuestro front-end?

Así que vamos a ver algunas opciones para sacar los datos de Gutenberg de WordPress y ponerlos en componentes. Entonces, una opción es obtener contenido como HTML. Entonces podemos consultar nuestro contenido de WordPress como HTML y luego analizar ese HTML en componentes. O podemos consultar bloques como tipos de GraphQL. Entonces podemos, eso nos permite consultar una lista de bloques, cada bloque sería un tipo de GraphQL que podemos asignar a un componente.

Así que el contenido es HTML. Esto es algo que podemos hacer en el núcleo de WPGraphQL hoy. Si desea consultar bloques como tipos de GraphQL individuales, hay dos opciones en este momento. Tenemos GraphQL para la extensión Gutenberg, que es una extensión comunitaria y luego tenemos WPGraphQL Block Editor, que es un complemento beta en el que estoy trabajando personalmente.

Así que veamos estas opciones. En el núcleo de WPGraphQL, podemos consultar el contenido como HTML y analizar los componentes. Lo que parece es que consultamos algo como una publicación, y podemos solicitar campos como ID y título o contenido. Y el contenido devolverá una gran cadena, una gran parte de HTML y luego podemos analizar ese HTML y asignar diferentes nodos DOM a diferentes componentes.

Como en este caso en wpgraphql.com, el enlace de la izquierda es para el código donde esto realmente sucede. Tomo el marcado que se devuelve de WPGraphQL y lo analizo, busco nodos HTML específicos y los convierto en componentes React. Entonces puedo tener cosas interactivas como este bloque de código, que resalta la sintaxis y permite a los usuarios hacer clic en Copiar y luego también puedo analizar y crear una tabla de contenido, por ejemplo. Así que ese es un enfoque. Y lo estoy usando en wpgraphql.com en producción hoy.

Algunas cosas que quizás desee considerar si sigue esta ruta, las cargas HTML pueden ser impredecibles. Los cambios en el servidor, como la instalación de una nueva biblioteca de bloques o varios HTML que los editores pueden incluir en el contenido, son impredecibles. Así que podría ser muy difícil de analizar. No se pueden interrogar los cambios. Como desarrollador de clientes, no puede ver qué cambió, así que es algo a tener en cuenta.

Diría que este enfoque funciona mejor para los equipos que tienen un control muy estricto sobre el administrador de WordPress y el front-end. Entonces, si eres una sola persona o un pequeño equipo que está trabajando en el backend y el front-end de WordPress, podría funcionar bien para ti porque puedes controlar la entrada y la salida un poco mejor.

Una de las otras opciones, WPGraphQL para Gutenberg, este es un complemento mantenido por la comunidad. Y esto le permitirá consultar bloques de contenido, cada bloque como su propio tipo de GraphQL. La forma en que esto funciona es una página de configuración, debe ingresar solo los bloques como el esquema, por lo que esto abre Gutenberg en un iframe invisible, obtiene el registro de bloques del cliente JavaScript y lo envía al servidor.

Y luego podemos usar GraphQL para consultar nuestros bloques como tipos específicos, y podemos usar fragmentos como mostré anteriormente y podemos usar estos fragmentos para mapear componentes en nuestro front-end. Así que esta es una opción. Algunas consideraciones con este complemento, los cambios en el registro de bloques son introspectables, por lo que es algo bueno.

Los equipos que trabajan en la aplicación front-end pueden usar la introspección de GraphQL para ver cómo cambia el esquema con el tiempo y pueden saber si hay cambios importantes o nuevos campos que pueden consumir. Diría que este enfoque funciona un poco mejor para proyectos de varias personas o de varios equipos. Si tiene un equipo que trabaja en el administrador de WordPress y un equipo diferente que trabaja en el front-end, este enfoque podría funcionar mejor. Pueden usar el esquema GraphQL como un contrato entre los bloques que se usan en ambos lados.

Una cosa que es un poco interesante es que carga bloques en el iframe como mencioné. Y debido a esto, no siempre se adapta a todas las situaciones. Entonces, si registra bloques en una página específica o una plantilla específica o un tipo de publicación específico, este método de obtener el mapa de registro de bloques en el esquema podría perder algunos bloques. Por lo tanto, es posible que no se adapte a todos los proyectos.

Entonces, el próximo proyecto, WPGraphQL Block Editor, este es un complemento beta en el que estoy trabajando actualmente. Y esto también le permite consultar bloques de contenido como su propio tipo GraphQL y, de manera muy similar a WPGraphQL para Gutenberg, podemos escribir fragmentos que devuelven los datos que especificamos. Y luego podemos usar esos fragmentos con nuestros componentes en el front-end.

Algunas consideraciones con esto, es un complemento beta, así que eso es todo. Se beneficia de la entrada estructurada y la salida estructurada. Entonces, como desarrollador front-end, eso es una victoria segura. Funciona con bloques que están registrados con el archivo block.json. Entonces, los bloques principales de WordPress Gutenberg tienen este archivo y funcionará con ese enfoque. Muchos terceros no registran sus bloques de esta manera, por lo que tendría que mapear manualmente esos bloques.

Los bloques no se tratan como nodos individuales. Me gustaría tratar los bloques como nodos individuales, pero no hay una identificación global, por lo que debe acceder a esos bloques como partes de objetos más grandes, como una página de póster.

Así que espero que hayas aprendido algo sobre Headless WordPress, los beneficios de Headless WordPress y el uso de Headless WordPress con Gutenberg. Te invito a probar WPGraphQL hoy. Puede registrarse para obtener una cuenta gratuita de Atlas Sandbox en wpengine.com/atlas. Y gracias por unirse a mi presentación. De nuevo, puedes encontrarme en Twitter, jasonbahl, o también en Twitter @wpgraphql. Gracias.