Me pregunto dónde aterrizará WordPress sin cabeza. Y por “sin cabeza” me refiero solo a usar el administrador de WordPress y construir el sitio de cara al usuario a través de la API REST de WordPress en lugar de la estructura tradicional de temas de WordPress.
¿Es … grande? ¿El futuro de WordPress? ¿O relativamente de nicho?
¿Dónde está la demanda?
Ciertamente, hay demanda. Conozco a mucha gente haciéndolo. Por ejemplo, Gatsby tiene un gatsby-source-wordpress complemento que le permite obtener contenido de un sitio de WordPress de una manera que consume la API REST de WordPress y la almacena en caché como GraphQL para usar en un sitio de Gatsby con tecnología React. Se ha descargado 59.000 veces este mes y 851.000 veces en total, mientras escribo. Esa es una buena parte del uso de una tecnología de construcción de sitios en particular. Literalmente, cada uso de gatsby-source-wordpress está usando WordPress sin pensar, eso es lo que es / hace. Si está interesado en esto, aquí está Ganesh Dahal cavando profundamente en él.
Y eso es solo una cosa, no tiene en cuenta empresas y productos enteros dedicados a la idea.
¿Qué es una mejora sin cabeza?
La integración de Gatsby es un caso sólido de por qué alguien consideraría un sitio de WordPress sin cabeza. Llegaré a eso.
Muchos defienden que la razón es arquitectónico. Desacopla la parte trasera de la parte delantera. Derriba el monolito. Como sistema desacoplado, los extremos delantero y trasero pueden evolucionar de forma independiente. Y, sin embargo, estoy menos entusiasmado con esa idea a medida que pasan los años. Por ejemplo, yo diría que las posibilidades de simplemente arrancar WordPress y reemplazarlo con otro CMS en una configuración sin cabeza como esta es más fácil de decir que de hacer. Además, la idea de que voy a usar la API de WordPress no solo para impulsar un sitio web, sino también una aplicación de lectura nativa, y alguna valla publicitaria digital conectada a Internet o algo así, no es un caso de uso que esté explotando en popularidad hasta Puedo decir.
La verdadera razón por la que creo que la gente busca un back-end de WordPress para un front-end impulsado por Gatsby es esencialmente esta: les gusta React. Les gusta construir cosas a partir de componentes. Les gustan las transiciones rápidas de página. Les gusta poder alojar cosas en algún lugar Jamstack-y con todas las bonitas vistas previas de los desarrolladores y demás. Les gusta la recarga del módulo en caliente. Les gusta Prettier y JSX. Simplemente les gusta y no los culpo. Cuando disfruta de ese tipo de experiencia de desarrollador, volver a crear plantillas PHP donde se necesita actualizar manualmente el navegador y mantener algún tipo de proceso de compilación manual no es exactamente atractivo.
Frontity es otro producto que busca perfeccionarse en React + WordPress. Geoff y Sarah compartieron cómo hacer todo esto el año pasado en el lado de Vue / Nuxt.
Pero, ¿WordPress sin cabeza se volverá más popular que el modelo de temas tradicional de WordPress que se basa en plantillas PHP que se alinean con una estructura explícita? Nah. Bueno, tal vez lo sería si el propio WordPress defiende la idea y ofrece orientación, capacitación y documentación que faciliten a los desarrolladores la adopción de ese enfoque. Lo compraría si WordPress dijera que una arquitectura sin cabeza es el nuevo curso de dirección. Pero ninguna de esas cosas es verdad. En consecuencia, hasta cierto punto, es una cuestión de nicho.
¿Qué tan nicho es sin cabeza?
WP Engine es un gran host de WordPress y tiene todo un sistema llamado Atlas. Y ese esfuerzo definitivamente parece que se están tomando en serio este nicho de mercado. No estoy 100% seguro de qué es Atlas, pero parece un tablero para hacer girar sitios con un código de configuración de aspecto interesante. Uno de los elefantes en la habitación con WordPress sin cabeza es que, bueno, ahora tienes dos sitios web con los que lidiar. Tiene donde sea que esté hospedando y ejecutando WordPress, y donde sea que esté hospedando y ejecutando el sitio que consume las API de WordPress. Quizás esto une esas dos cosas de alguna manera. Lo de la implementación desde Git-commits es atractivo y lo que yo consideraría un juego de mesa para el alojamiento moderno en estos días.
Otra razón por la que a la gente le gusta WordPress sin cabeza es que el resultado final puede ser estático, como en páginas HTML pregeneradas. Eso significa que el servidor de su sitio web puede tener un CDN elevado, ya que, literalmente, solo los activos estáticos están disponibles instantáneamente para descargar. No hay PHP o base de datos para las cosas de renderización del lado del servidor, lo que puede ser lento (y, para ser justos, tratarse) ya que agrega un proceso antes de la renderización.
¿Cuál es “la forma de WordPress” para ir sin cabeza?
Agruparía cualquier servicio que construya una versión estática de su sitio de WordPress en el grupo de WordPress sin cabeza. Eso se debe a que, en última instancia, esos sitios están utilizando las API de WordPress para crear esos archivos estáticos, al igual que Gatsby o cualquier otra cosa.
Eso es lo que hace Strattic. Crean un sitio de WordPress para ti que consideran organizar. Usted hace su trabajo de WordPress allí, luego usa su sistema de publicación para impulsar una versión estática de su sitio a producción. Eso es convincente porque resuelve algo que otro uso de WordPress sin cabeza no hace: simplemente hacer las cosas a la manera de WordPress.
Por ejemplo, los bloques o complementos personalizados de WordPress pueden producir resultados que no solo contengan HTML personalizado, sino también CSS y JavaScript. Imagine un bloque o complemento de “carrusel”. Ese carrusel no funcionará si todo lo que está haciendo es tomar el contenido de la publicación de una API y sumergirlo en una página. Deberá extraer el CSS y JavaScript de otro lugar e incluirlo, o simplemente saber que así no es como hace las cosas. Puede adjuntar las imágenes como metadatos de alguna manera, extraerlas del lado del cliente y hacer su propia implementación de un carrusel. Con Strattic, en teoría, funcionará ya que HTML, CSS y JavaScript todavía están presentes en el sitio estático. Pero en particular, no tiene PHP, por lo que Strattic tuvo que crear integraciones de formularios a mano, usan Algolia del lado del cliente para la búsqueda, Disqus para los comentarios, etc., porque no hay un lenguaje del lado del servidor disponible.
Shifter es otro jugador aquí. Es similar a Strattic, donde trabaja en su sitio en el administrador de WordPress y luego publica en un sitio estático. Creo que Shifter incluso hace girar su sitio de WordPress cuando no está en uso, lo cual tiene sentido ya que la salida es estática y no hay razón para que un servidor con PHP y MySQL deba estar ejecutándose. Como alternativa, Shifter tiene una configuración de WordPress solo sin cabeza que presumiblemente permanece activa todo el tiempo para el uso externo de la API.
Es divertido pensar en todas estas cosas
Pero mientras lo hago, me doy cuenta de que las ideas y discusiones en torno a WordPress sin cabeza se centran principalmente en el desarrollador. WordPress tiene este enorme mercado de personas que simplemente no son desarrolladores. Sin embargo, administran un sitio de WordPress, aprovechando el ecosistema de complementos y temas. Eso es algo genial, y es impresionante que WordPress sirva tan bien a ambos mercados. Creo que hay muchísimos más propietarios de sitios de WordPress que no son desarrolladores que los que lo son, por lo que solo eso evitará que WordPress sin cabeza sea algo más que un concepto relativamente de nicho durante algún tiempo. Pero, ya sabes, si quieren poner GraphQL en el núcleo, todavía lo tomaré kthxbye.
Artículos relacionados
Artículo
el 9 de abril de 2021
Envío de formularios sin cabeza con la API REST de WordPress
Artículo
el 4 de febrero de 2020
Cómo crear un sitio de WordPress sin cabeza en The Jamstack
Artículo
el 7 de junio de 2018
CMS sin cabeza: el mejor amigo de los desarrolladores
Artículo
el 15 de noviembre de 2021
ooooops, supongo que ahora somos * desarrolladores full-stack
Artículo
el 11 de marzo de 2016
¿Qué es un CMS sin cabeza?