Presione esto: WPGraphQL y Faust.js

Bienvenido a Press This, el podcast de la comunidad de WordPress de WMR. Cada episodio presenta invitados de toda la comunidad y discusiones sobre los problemas más importantes que enfrentan los desarrolladores de WordPress. La siguiente es una transcripción de la grabación original.

Desarrollado por RedCircle

Doc Pop : Estás escuchando Press This, un podcast de la comunidad de WordPress en WMR. Cada semana destacamos a los miembros de la comunidad de WordPress. Soy su anfitrión, Doc Pop. Apoyo a la comunidad de WordPress a través de mi función en WP Engine y mis contribuciones en TorqueMag.Io, donde puedo hacer podcasts y dibujar caricaturas y videos tutoriales. Mira eso.

Puede suscribirse a Press This en Red Circle, iTunes, Spotify, o puede descargar episodios directamente en wmr.fm.

En este episodio de Press This, estamos hablando de Headless WordPress, GraphQL y Faust.js. Cómo se pueden usar estas herramientas juntas y qué tipo de costo podría estar asociado con Headless WordPress. Vamos a tratar de profundizar en esto, y tengo dos grandes invitados que se unirán a mí hoy, tengo a Jason Bahl, un ingeniero de software principal en WP Engine con sede en Denver, Colorado, donde mantiene WPGraphQL. . Y tenemos a Chris Weigman, un gerente de ingeniería que trabaja en Faust.js. Por lo general, me gusta comenzar estos programas preguntando a los invitados sobre sus historias de origen de WordPress, pero pensé en cambiar un poco las cosas aquí.

Jason, ¿puede decirnos qué es WPgraphQL y cuál es su historia de wordPress Origin?

Jason Bahl: Ah, sí, WPGraphQL es un complemento de WordPress de código abierto gratuito que trae una API de GraphQL a su sitio de WordPress y GraphQL es un lenguaje de consulta de gráficos. Por lo tanto, permite a los desarrolladores obtener contenido dentro y fuera de WordPress utilizando el lenguaje de consulta de gráficos.

Y el complemento se originó, estaba trabajando en un periódico hace unos años y estábamos haciendo una gran cantidad de contenido sindicado. Teníamos una red de algo así como 54 sitios en todo EE. UU. y necesitábamos mover el contenido de un lado a otro. Ya sabes, cuando se publicaba una noticia, diferentes periódicos podían suscribirse al contenido de otros periódicos.

Entonces, cuando ocurrieron varios eventos, necesitábamos mover datos alrededor de esta red y estábamos usando la API REST de WordPress para hacer mucho de ese movimiento de datos. Y teníamos algunos problemas con eso técnicamente y me gustaba el rendimiento real técnicamente, pero también la experiencia del desarrollador. Descubrí GraphQL, el lenguaje de consulta de gráficos real, que fue de código abierto por Facebook en 2015.

Así que encontré esta tecnología, hice algunos prototipos, se la presenté a mis colegas y luego migramos nuestra sindicación de contactos de REST a GraphQL. Y luego continué trabajando en el proyecto como un proyecto comunitario sabiendo que los marcos de JavaScript se estaban convirtiendo en algo popular y que probablemente sería el caso de uso principal de GraphQL, como que la comunicación de servidor a servidor no es el caso de uso principal. Resolvió nuestras necesidades, pero vi una visión más amplia, así que seguí trabajando en él como un proyecto de código abierto para la comunidad.

DP: Bueno, genial. Chris, ¿puedes contarnos una historia similar sobre qué es Fausto y cómo surgió?

Chris Weigman: Sure Faust, recientemente, esta semana, se lanzó oficialmente al público, se volvió a lanzar al marco público para crear sitios de Headless WordPress usando GraphQL. Bueno, el desarrollo comenzó en 2020, y era una especie de proyecto no oficial de WP Engine, y este es el tercer gran pivote.

Comenzaron como una extensión de DevRel, comenzaron a hacerlo un poco más oficial y se convirtieron en algo llamado GQty y una mentalidad de desarrollador primero muy JavaScript. Y luego, cuando me hice cargo del equipo el 1 de diciembre del año pasado, nos dimos cuenta de que ese no era nuestro mercado objetivo.

Deberíamos haber estado desarrollando para desarrolladores de WordPress. Así que comenzamos a reconstruirlo de nuevo, y finalmente se pudo relanzar recientemente.

DP: Jason, tuiteaste recientemente que habías lanzado el nuevo wpgraphql.com en Faust.js. El sitio anterior, creo que era WordPress sin cabeza. ¿Puedes simplemente contarnos sobre este cambio que hiciste y sabes, qué mejoras estás diciendo?

JB: Sí. Entonces, wpgraphql.com ha sido un sitio sin cabeza durante muchos años. Así que estoy usando múltiples fuentes de datos. Así que tengo mucho contenido en WordPress, como que las publicaciones del blog están todas en WordPress.

Parte de la documentación también existe en WordPress. Y luego existe cierta documentación en los archivos de rebajas en el repositorio de GitHub. Durante mucho tiempo estuve usando Gatsby, tal vez durante unos tres años, estuve usando Gatsby, que es un marco de JavaScript que, en esencia, tiene su capa de datos donde puede extraer datos de múltiples fuentes.

Así que estaba usando eso, obtendría datos de GitHub, también extraería datos de WordPress usando WPGraphQL y me permitiría usar esos datos para crear mis plantillas. Así que estuve usando eso durante unos años. Hay muchos puntos débiles con la capa de datos de los que quería salir.

Así que quería usar Next, que es en lo que se basa Faust. Es otro marco de JavaScript, pero supongo que faltaban muchas piezas. A continuación, muchos de estos marcos de JavaScript tienen la idea de que sus marcos de front-end deberían definir todo el enrutamiento, ¿verdad? Pero si está utilizando un CMS, su CMS define el enrutamiento.

Entonces, hay muchos problemas técnicos para hacer que esas cosas funcionen bien, como que tu front-end tiene una opinión sobre algo y tu back-end tiene una opinión diferente. Entonces, como uno de los problemas que estaba tratando de resolver, era lograr que mi interfaz reconociera que una URL específica era un tipo específico de cosa y luego generar una plantilla que representaba esa cosa.

Como una publicación de blog tiene una plantilla diferente a un documento o un archivo de usuario o lo que sea. Así que quería que mi interfaz tuviera la capacidad de enviar una URL al CMS, recuperar datos, pero entender qué plantilla devolver. En WordPress se llama jerarquía de plantillas. Entonces, cuando el equipo de Faust pudo resolver ese problema, pensé, diablos, sí, me voy a pasar a Faust.

Entonces, sí, puedo tomar algunos de los conceptos que existen en el núcleo de WordPress, como la temática de PHP, y usarlos sin cabeza para poder usar los beneficios de React y cualquier JavaScript que quiera usar en la interfaz para crear mi plantilla. sitio, pero todavía conceptos familiares del mundo de WordPress.

DP: Chris, estabas mencionando que Fausto sufrió algunos cambios. ¿Cuáles fueron esos cambios? Sabes, Jason los estaba mencionando. ¿Cuáles fueron algunos de esos cambios que han hecho posible esta mejora?

CW: Siempre se centra en WPGraphQL. Era todo lo demás lo que realmente era el problema. Por ejemplo, la última versión principal de Faust usó una biblioteca debajo para interactuar con GraphQL llamada GQty, que en el papel sonaba realmente genial. La idea del equipo de Faust en ese momento era que, resumiendo, las personas no deberían necesitar saber cómo crear estas consultas complejas.

Este marco debería abstraer eso para usted. Sobre el papel se veía muy bien, en la práctica debido a todas las complejidades de los datos de WordPress. Incluso un solo tipo de publicación puede tener tantas variaciones. Tal vez estás mezclando eso con categoría, tal vez todas las cosas diferentes. GQty simplemente no pudo encenderlo.

Además de eso, cuando se construyó con la versión GQty, realmente no se prestó atención al problema de enrutamiento del que habló Jason. ¿Quién maneja el enrutamiento? WordPress quiere manejar su enrutamiento según el contenido, es un sistema de administración de contenido, por lo que todo el enrutamiento y WordPress se basan en gran medida en el contenido.

Next.js es un marco de front-end, por lo que todo el enrutamiento se basa en un paradigma completamente diferente de cómo se basa el enrutamiento. Lo que podría ser /Blog on Next puede no tener nada que ver con el contenido de un blog. Va a un conjunto de plantillas. Va a la parte de la aplicación que puede construir un blog.

Mientras que /Blog en WordPress bien podría significar, estas son todas las publicaciones del blog. Y ese paradigma al construir, si quieres hacer de WordPress una interfaz muy sólida o un CMS con capacidad autónoma, tuvimos que lidiar con ese enrutamiento. Otro cambio cuando hicimos esto, como dije con la versión GQty, nuestro objetivo eran los desarrolladores de JavaScript que tenían que usar WordPress, lo que parece noble hasta que te das cuenta de que esto es WP Engine.

Estamos tratando con agencias que se han basado en WordPress durante años, que ahora, por varias razones que podemos abordar más adelante, se están moviendo hacia una cosa sin cabeza. Saben cómo hacer el desarrollo de WordPress. Entienden cómo funcionan las plantillas de enrutamiento de WordPress y cómo funcionan las plantillas, cosas así.

Necesitamos mejorar esas funciones para que los desarrolladores de WordPress puedan usar GraphQL más fácilmente. Y ese es el objetivo de Fausto aquí. La jerarquía de plantillas simplemente reconstruye lo que hizo WordPress. Ahora, si desea utilizar el enrutamiento de Next, hay formas de anularlo en la aplicación para que no pierda nada.

Pero para las personas que usan WordPress como un verdadero sistema de administración de contenido, capaz de enrutar contenido por administración de contenido, ¿Faust lo manejará mucho mejor para usted? ¿Tiene sentido?

DP : Sí. Absolutamente. Sabes, creo que es un buen lugar para tomar un breve descanso aquí. Estás escuchando Press This, un podcast de la comunidad de WordPress con Chris Weigman y Jason Bahl. Volveremos para hablar de WordPress y headless. Manténganse al tanto.

DP: Volvemos con Press This. Y sabes, Chris, justo antes de esa pausa, mencionaste algo, mencionaste que más y más empresas se están metiendo en headless, y sé que WP Engine ha investigado mucho para demostrar que ese es el caso. Me pregunto, sin cabeza definitivamente tiene una reputación como algo, creo que empresa, cuando pienso sin cabeza estoy pensando correctamente. ¿Eso es lo que es sin cabeza? ¿Es solo una herramienta para empresas o es una herramienta que usarán más sitios?

CW: Sí y no. En gran parte sin cabeza, especialmente con WordPress en este momento, la complejidad involucrada significa que probablemente tengas un equipo completo construyendo lo que necesitas.

No se trata de alguien que solo usa WordPress listo para usar, que solo quiere su blog personal. Puede hacer eso, pero es un trabajo mucho más pesado hasta ahora para poder hacerlo. Lo mismo con Contentful, lo mismo con todos estos otros CMS. Si solo querías algo simple, algo que, ya sabes, el tipo de contenido que ha estado en la web durante años, sin cabeza es probablemente más trabajo del que quieres lidiar hasta ahora.

¿Es estrictamente empresarial? Mira, no. Gatsby ha estado trabajando en este problema durante años. Tienes otro podcast más tarde, Doc con Mastodon. Es una comunidad con la que he estado involucrado durante varios años. La mayoría de la gente en eso está usando variaciones de CMS sin cabeza, especialmente Gatsby, pero está Hugo. Hay todo tipo de diferentes, ese tipo de tecnología en un nivel muy básico.

Entonces terminas con los usuarios de base y terminas con usuarios empresariales para sitios pesados, mientras que WordPress tradicionalmente parece caer con todos los demás en el medio. Es la persona que no quiere lidiar con archivos de descuento y código como lo haría un usuario de Gatsby, o ya sabes, simplemente Gatsby de todos modos.

Pero tampoco es alguien que tiene un equipo completo de 10 personas construyendo su marca personal o blog personal. Esto saca a WordPress de ese medio y lo expande a ambos extremos muy fácilmente. Ahora puede construir fácilmente entre GraphQL, tiene todos los datos y tiene un conjunto cada vez mayor de formas de manejar esos datos.

Y Faust hace que sea mucho más fácil utilizar eso y algo que puedes construir en un día en lugar de un mes.

DP: Jason, Chris mencionó algo sobre lo que me gustaría escuchar sus pensamientos, escuché que esto quizás no sea bueno para equipos pequeños, pequeños bloggers como yo, lo que obviamente tiene sentido, no necesito un WordPress sin cabeza, pero como , Supongo que lo que me pregunto es si WordPress sin cabeza me costará más porque tendré que tener un desarrollador de iOS y un desarrollador de WordPress. ¿Es más caro o es de alguna manera más rentable?

JB: Probablemente depende de lo que estés produciendo, supongo. Si está haciendo, como mencionó iOS, si está haciendo una aplicación móvil nativa, quiero decir que obviamente habrá costos asociados con eso independientemente, y no hay realmente una buena manera de hacerlo si está usando datos de WordPress, otros que hacerlo sin cabeza, porque ya sabes, una aplicación nativa no procesa php, por lo que tendrías que hacerlo sin cabeza.

Pero en lo que respecta a si está creando para la web en este momento en WordPress tradicional, puede encontrar un tema, ya sea un tema gratuito o encontrar un tema en un mercado, descargarlo, instalarlo y listo. a las carreras. La mayoría de la gente lo va a personalizar de una forma u otra.

Por lo general, tendrá un costo de desarrollador, ya sea que lo haga usted mismo o alguien más. Una de las cosas con WordPress sin cabeza que difiere de la temática tradicional de PHP es que, por ejemplo, cuando lancé el nuevo wpgraphql.com, pude usar la misma instancia de WordPress que estaba impulsando mi sitio de Gatsby.

Estoy obteniendo los datos, los datos salían y entraban en el sitio de Gatsby, pude continuar publicando contenido en el CMS mientras desarrollaba mi próxima interfaz al mismo tiempo. En el desarrollo tradicional de WordPress, generalmente debe migrar su sitio a un entorno de prueba.

Active un nuevo tema en ese entorno, construya su tema allí, lidie con algún tipo de período de congelación de contenido en el que le diga a sus creadores de contenido: "Oigan, hoy no pueden publicar contenido porque vamos a migrar y luego ' vamos a configurar la nueva instancia de WordPress, la instancia en vivo”. Y luego tienes que iniciar sesión allí y comenzar a hacer tu contenido correctamente.

WordPress sin cabeza, pude reconstruir mi sitio en una pila de interfaz completamente diferente sin interrumpir nada en mi instancia real de WordPress, es una separación de datos y presentación, ¿verdad? Entonces podría ir, si quisiera explorar la próxima tecnología de moda mañana, como si pudiera poner mi vista en Svelte en lugar de Next, y no tendría que cambiar nada en WordPress.

Entonces, en algunos casos, en realidad puede ser más barato porque todo el proceso de hacer girar otro servidor, hacer que su equipo deje de escribir contenido y luego se mueva a una instancia diferente de WordPress, y luego comience a publicar allí, hacer migraciones Delta, cosas así, eso también tiene un costo.

Otra cosa que también es interesante es que el ecosistema de JavaScript realmente se está distribuyendo. El impulso común, en mi opinión, uno de los motivadores comunes para moverse sin cabeza son las arquitecturas basadas en componentes. Y hay todo tipo de bibliotecas de componentes en el ecosistema React y VUE, que le permiten reutilizar componentes en todos los proyectos.

Y así, las agencias pueden construir componentes comunes que usan en proyectos y pueden actualizarlos en un lugar central, pero luego instalarlos en múltiples proyectos. Con WordPress, eso no es tan fácil porque las partes de su plantilla de PHP y WordPress generalmente están estrechamente relacionadas con el proyecto al que pertenecen.

Donde con headless puede tener un paquete MPM que tiene esos componentes y múltiples proyectos pueden actualizar ese paquete y beneficiarse todo al mismo tiempo con menos esfuerzo. Así que creo que en este momento, diría que probablemente es más costoso y requiere más trabajo, pero creo que herramientas como Faust, que no existían hasta hace poco, están reduciendo el esfuerzo general requerido para construir sin cabeza.

Y creo que en un futuro no muy lejano, podría ser más barato construir sin cabeza que sin cabeza.

DP: Chris, ¿tienes algo que quisieras agregar a lo que las agencias podrían tener que pensar en términos de costos de WordPress sin cabeza?

CW: Creo que Jason realmente dio en el clavo.

Y eso es algo que me gusta de WPGraphQL: mi equipo está trabajando para extender WordPress en esa dirección con lo que llamamos, nuestro título provisional es React Gutenberg Bridge, pero también es un problema en WordPress. ¿Cómo se reutilizan estos componentes? No quiero usar la palabra solo componente, porque no se aplica en el lado de WordPress de la misma manera que se aplica en el lado de JavaScript, ¿verdad?

Pero, ¿cómo reutilizamos el código en proyectos, sin cabeza o de otro modo con WordPress y sin cabeza lo permite? Pero creo que es seguro decir que el bloguero promedio solo intenta sacar sus blogs de amantes de la comida, probablemente no se ocupe de eso por sí mismo. Eso es en gran medida un problema de agencia. eso es mas costo?

Tal vez, tal vez no, pero ahí es donde se complica cuando hablamos de cuál es el costo de esto. Porque hay diferentes tipos de cómo desea utilizar los datos.

DP: Sí, absolutamente. Sabes, viniendo de un entorno periodístico, trabajando en Weeklys en Twin Cities y en Nashville, Jason, puedo imaginar cómo hubiera sido decirle a tus 56 periódicos que no publicaran por un día.

No hay noticias hoy, porque estamos actualizando el sitio.

JB: Sí. Y quiero decir, pasamos por esos períodos, ¿verdad? Como cuando me contrataron allí, no estaban en WordPress y parte de mi trabajo era llevarlos desde otro sistema a WordPress. Así que definitivamente hubo días en los que fue como, está bien, se lanzará el día de WordPress. Deja de hacer lo que estás haciendo. Derecho.

Así que definitivamente hubo períodos como ese o también tuvimos que lidiar con ese problema de, bueno, estaban publicando en el sistema anterior hasta la medianoche de anoche, pero teníamos el WordPress listo dos días antes de eso. Así que ahora tenemos que hacer como una migración Delta y asegurarnos de que todos los datos aún estén sincronizados para que, ya sabes, definitivamente haya un costo técnico y humano para esos procesos con seguridad.

DP: Sí. Y creo que también hay mucho, cuando todavía usas WordPress, aún obtienes ese ecosistema en el que puedes obtener este ahorro de costos. No tienes que construir las herramientas de SEO.

Puedes usar el complemento Yoast SEO o lo que sea. A pesar de que es un sitio sin cabeza, asumo que la mayoría de los complementos seguirán funcionando siempre que no estén orientados hacia el frente.

JB: Sí. Eso es realmente algo interesante. Entonces, el nuevo Faust está construido con una arquitectura de complemento en sí. Así que, listo para usar, vendrá con un cliente, está usando el cliente Apollo para que pueda obtener datos de WPGraphQL, puede obtener sus datos de WordPress, pero puede crear complementos para que, digamos que lo hizo, como usted mencionado, instale Yoast SEO en su sitio de WordPress.

Puede agregar un complemento de Yoast. Todavía no existe, pero pronto podrá hacerlo. Podría agregar un complemento de Yoast para Faust en la interfaz que sepa qué hacer con esos datos, ¿verdad? Así que habrá la capacidad para la gente, algunos podríamos producirlos y admitirlos, pero algunos, la comunidad también puede producir y admitir complementos para el lado Faust de las cosas, de modo que con solo una línea de código, agregue este complemento puede obtenga funcionalidades como Yoast para su front-end sin cabeza.

Es algo que no creo que ninguna otra interfaz sin cabeza tenga realmente el concepto de la misma manera que lo está abordando Faust. Así que creo que el complemento, creo que es otra cosa familiar para los desarrolladores de WordPress. Está trayendo conceptos familiares de WordPress, pero uniéndolos con la moderna pila de interfaz de JavaScript.

DP: ese es un buen lugar para una pausa final aquí en Press This, y cuando regresemos, terminaremos nuestra conversación con Chris Weigman y Jason Bahl. Manténganse al tanto.

DP: Estás escuchando Press This, un podcast de la comunidad de WordPress. Soy su anfitrión, Doc Pop. Hoy estamos hablando de WPGraphQL, Faust y cómo puede potenciar su sitio de WordPress sin cabeza. Justo antes de la pausa, estuvimos hablando sobre Faust y los complementos y les voy a lanzar algunas preguntas al azar y ver si hay alguna buena respuesta aquí que surja.

Pero Chris, me pregunto con, con Faust, si hay algún potencial, sé que es una plataforma sin cabeza, pero ¿hay algún potencial para un tema de Faust de WordPress que al menos te haga configurar algo como, aquí están los complementos que necesita y aquí está todo listo para usar.

CW: Absolutamente. De hecho, ya lo tenemos. Nos referimos a él como Blueprints porque funciona mucho con Local. La mayoría de la gente hará algún tipo de ajuste en este material antes de lanzarlo en una plataforma como WP Engine. Así que tomamos prestado el nombre de Blueprints de Local.

Para el nuevo Faust tenemos uno llamado Portafolio, que es básicamente un tema de portafolio completo y estamos trabajando en un andamio muy en blanco que las agencias pueden usar. Una vez que domines las cosas, probablemente querrás personalizar todo tú mismo. Entonces, un andamio sería las mejores prácticas del proyecto, utilízalo y luego puedes hacer todas tus propias cosas con él.

A largo plazo, hemos hablado mucho sobre una tienda de temas sin cabeza, ala Blueprints. No tenemos la mano de obra, así que eso está un poco lejos, pero es absolutamente algo que estamos, estamos considerando y nos gustaría que sucediera.

DP: Sí, es genial pensar en eso. Ese es un tipo completamente diferente de ecosistema en el que entrar.

Y sabes, Jason, te he entrevistado antes, y estoy seguro de que esta pregunta surge todo el tiempo, pero cada vez que escucho sobre WPGraphQL, pienso que se parece mucho a lo que hace REST API. En realidad, eso suena mucho más poderoso que lo que hace REST API y REST API es parte del núcleo y me pregunto, ¿sientes que WPGraphQL debería ser parte de WordPress Core?

JB: Tal vez algún día. No creo que estemos allí todavía. Cuando las cosas se fusionan en WordPress Core, probablemente con la excepción de Gutenberg, la innovación se detiene. La API REST, por ejemplo, todavía hay un error que señalo a las personas que todavía existe desde 2016. Entonces, cuando las cosas entran en el núcleo, agrega un conjunto de funciones al 40 por ciento de la web y por lo tanto, hacer cambios debe hacerse a un ritmo mucho más lento, donde si es un complemento, puede permitir que las personas opten por la versión que desean y puede iterar mucho más rápido porque pueden elegir qué versión funciona mejor para su proyecto.

En el núcleo, si actualiza el núcleo e incluye cambios importantes, es posible que haya roto el 40 por ciento de la web. Así que GraphQL es una especificación, tampoco tiene nada que ver con WordPress.

Derecho. Y así, la especificación GraphQL todavía está evolucionando. Y a medida que continúa evolucionando, queremos mantenernos al día con lo último y lo mejor de la especificación GraphQL. Si fuéramos a fusionar, digamos, WPGraphQL en Core hoy, y GraphQL sigue evolucionando, WordPress estaría atascado en la edición 2022 de GraphQL donde el resto del mundo está en la versión 2030 o lo que sea. Para mí, creo que podría tener sentido en algún momento que se reconozca que WPCLI es la forma oficial de hacer X cosas.

Por ejemplo, puede crear su propio cliente CLI para WordPress, pero la comunidad reconoce que WPCLI es lo oficial. No es parte de WordPress Core, pero la Fundación WordPress y la mayoría de la comunidad de WordPress lo reconocen como algo oficial. Por lo tanto, podría ser bueno en algún momento que se reconozca un WPGraphQL de esa manera, por ejemplo, si va a hacer un WordPress sin cabeza, hágalo de esta manera.

Seguirá siendo un complemento. Ese es mi pensamiento. Puede haber un momento en el que GraphQL se sienta perfecto y no se esté iterando realmente y tal vez en ese momento lo consideremos. Pero en este momento hay cosas que vienen a la especificación de GraphQL que harán que la API tenga cambios importantes.

Entonces, hacerlo como un complemento para mí todavía tiene sentido.

DP: Justo en. Y sí, mencionaste WPCLI y sigo olvidándolos, como si simplemente se sintieran como parte del núcleo. Lo que sea que se sienta, es como oficial. Así que sí, es como, oh sí, eso es algo independiente, tal como lo es WPGraphQL en este momento.

Esa es una buena analogía. Así que voy a terminar aquí. Ha sido realmente genial charlar con los dos. Si los oyentes están interesados ​​en seguirlos, pueden seguir a @JasonBahl y @ChrisWeigman. Pondremos los identificadores de Twitter en la descripción del programa si podemos. Ha estado escuchando Press This, un podcast de la comunidad de WordPress en WMR.

En el episodio de la próxima semana, tendremos a Anne McCarthy, enlace de productos en Automatic, hablando sobre los cambios en la edición del sitio y 6.1 y lo que viene con 6.2. Gracias de nuevo por escuchar Press This.

Puedes seguir mis aventuras con la revista Torque en Twitter @thetorquemag o puedes ir a torquemag.io donde contribuimos con tutoriales, videos y entrevistas como esta todos los días. Así que echa un vistazo a torquemag.io o síguenos en Twitter. Puede suscribirse a Press This en Red Circle, iTunes, Spotify, o puede descargarlo directamente en wmr.fm cada semana. Soy su anfitrión, Doctor Popular. Apoyo a la comunidad de WordPress a través de mi rol en WP Engine. Y me encanta destacar a los miembros de la comunidad cada semana en Press This.