5 puntos por GN⁺ 2023-07-15 | 1 comentarios | Compartir por WhatsApp
  • WordPress Playground es una herramienta en línea para experimentar y aprender WordPress sin instalación, y esta página funciona como un hub de documentación oficial, no como sitio del producto
  • La documentación se divide en Documentation, Blueprints, Developers y API Reference, y cada sección guía sobre cómo comenzar, configuración basada en JSON, integración con código y referencia de API, respectivamente
  • Los usuarios pueden levantar un nuevo sitio de WordPress en 5 minutos y probar bloques, temas y plugins, o testear versiones específicas de WordPress/PHP
  • Los desarrolladores pueden elegir entre Query API, Blueprints API y JavaScript API según su objetivo, y usar Playground como un entorno local de desarrollo sin configuración
  • Funciona dentro del sandbox del navegador y depende poco de backend y autenticación, por lo que es adecuado para demos rápidas, prototipos y entornos de prueba generados con IA

Hub de documentación de WordPress Playground

  • El sitio web oficial de Playground se movió a wordpress.org/playground/, y esta página se usa como punto de entrada de la documentación
  • WordPress Playground es una herramienta en línea para experimentar y aprender WordPress
  • La documentación está compuesta por cuatro hubs
    • Documentation: introducción a WordPress Playground, guía de inicio y punto de entrada a la documentación
    • Blueprints: documentación de los archivos JSON que configuran una instancia de Playground
    • Developers: cómo usar Playground desde código
    • API Reference: referencia completa de las APIs que expone WordPress Playground

Inicio y flujo de desarrollo

  • Quienes lo usan por primera vez pueden empezar rápidamente con la Quick Start Guide para crear un nuevo sitio de WordPress, probar bloques, temas y plugins, y testear versiones específicas de WordPress/PHP
  • Playground web instance cubre la instancia de Playground disponible en https://playground.wordpress.net/
  • En About Playground se pueden revisar la seguridad de Playground, sus formas de uso y sus limitaciones actuales
    • A través de la documentación Build, Test y Launch se puede ver el flujo para usar Playground en desarrollo, validación y lanzamiento de productos
  • Guides reúne documentación paso a paso y formas de uso, mientras que Links and resources es una colección de materiales relacionados

Primeros pasos y elección de API

Contribuciones y uso con IA

  • WordPress Playground es un proyecto de código abierto y recibe contribuciones de código, diseño, documentación y triage
  • Playground está diseñado para usarse con agentes de codificación con IA y herramientas basadas en IA
    • Se ejecuta completamente del lado del cliente en WebAssembly, no requiere autenticación ni backend, y no deja efectos persistentes fuera del sandbox del navegador
    • Using Playground with AI agents: en Claude Code, Cursor, Gemini CLI, GitHub Copilot y otros, se puede instalar la habilidad wp-playground para delegar la ejecución de comandos
    • AI-readable site index: resumen legible por máquinas en llms.txt sobre funciones, APIs y documentación de Playground
    • AGENTS.md: instrucciones para agentes de codificación con IA que contribuyen a este codebase
  • WordPress Playground es software libre bajo la GNU General Public License versión 2 o posterior, y la licencia completa está en LICENSE.md

1 comentarios

 
GN⁺ 2023-07-15
Opiniones de Hacker News
  • Lo probé en Firefox en una tablet Android de gama baja y, aunque la respuesta no es inmediata, no se siente muy distinto a correr todo el stack LAMP en una instancia cloud decente o en un VPS, lo cual me sorprendió bastante.
    Aquí está incluido el intérprete completo de PHP, miles de líneas del codebase de WordPress e incluso SQLite. Aun así, que sea lo bastante usable es impresionante.

    • Siempre sentí que el rendimiento de WordPress no cambia mucho entre hardware de gama baja y de gama alta. Al final parece que WordPress en sí es el cuello de botella.
  • La forma en que hicieron que esto funcione es muy moderna: PHP se ejecuta como binario WebAssembly, MySQL se reemplaza por SQLite mediante un plugin de WordPress, y el servidor web está implementado como un Service Worker de JavaScript.

  • En la frase “Playground soporta desde apps de notas para dispositivos móviles hasta entornos de pruebas automatizadas y demos de WooCommerce que corren dentro de un sitio”, las dos últimas cosas me cierran por completo, pero la idea de crear una app móvil basada en WordPress que corre PHP con WebAssembly dentro del navegador me deja la cabeza dando vueltas.

  • WordPress divide mucho a la gente de HN. Un lado ve WordPress como una herramienta que amplifica valor, permitiendo que quienes no son desarrolladores no se preocupen por programar y se concentren en su trabajo principal; el otro lo odia por su codebase desordenado y se aferra a código perfectamente formateado y ultraescalable que, en la práctica, casi nadie usará.
    WordPress impulsa más de la mitad de la web. Puede que no sea la mejor tecnología, o incluso que sea la peor, pero la lección que muchos programadores siguen sin captar es que a nadie le importa cómo se hacen las salchichas.

    • Estoy totalmente de acuerdo con eso cuando se trata de armar un sitio utilitario chico, como el de una banda. Basta con subirlo más o menos a un hosting barato y esperar que la banda se separe antes de que se rompa la integración con Google Calendar.
      Pero, como estoy posponiendo mover el SSO de terceros de un sitio WordPress viejo y hecho un desastre a otro sitio WordPress nuevo y también hecho un desastre, déjenme desahogarme un poco: existe de verdad un tercer grupo que hace mantenimiento para que el primer grupo no tenga que preocuparse por cómo se hacen las salchichas.
      Llevo unos 14 años haciendo esto; alojé alrededor de 300 sitios WordPress de una universidad mediana; también construí y mantuve sitios .gov; y por la dirección del equipo de Gutenberg terminé creando varios bloques basados en React repartidos en tres patrones muy distintos. Hice de todo: deployments de servidor, arreglos de CSS para IE6, migraciones a WordPress raspando miles de páginas y decenas de miles de imágenes desde CMS inexistentes, comandos WP-CLI y hasta código para forzar la propagación de eventos de calendario en multisitio.
      Alguien tiene que saber cómo se hacen las salchichas, y yo lo sé. Por eso también sé lo precaria que es la pila de basura que es WordPress. He trabajado con codebases realmente útiles, con mejores herramientas y bases de datos entendibles, y sé que otras plataformas también tienen problemas, pero WordPress es realmente malo.
      Por eso no tengo reparos en criticarlo. Estoy completamente quemado; a veces pienso en dejar todo, vivir en un camión y dedicarme a hacer música. Es una plataforma pésima, y la gente ni siquiera paga bien por mantenerla funcionando. Al final hay personas que, por las circunstancias, siguen volviendo a WordPress como a un edificio en llamas, y el odio colectivo hacia esta plataforma está más que justificado.
    • WordPress es excelente para el primer grupo mencionado. Lo veo parecido a herramientas como Excel, FileMaker o Visual Basic, que democratizaron el software y lo hicieron accesible para todos.
      Por supuesto, estas herramientas tienen límites y problemas de calidad, y algunos usuarios terminan chocando con ellos. Eso, en sí, está bien. El problema aparece cuando se espera que profesionales integren cosas encima de ellas o construyan sobre ellas. La gente que acude a desarrolladores web llega con expectativas de calidad, problemas propios y requisitos específicos, pero el legado de WordPress pone tantas trampas y obstáculos frente a esos objetivos que muchas veces se termina intentando meter una clavija cuadrada en un agujero redondo. Algo similar podría decirse de muchos CRM o plataformas de comercio electrónico comunes.
    • Me considero un ingeniero de software serio, pero para el sitio web de la empresa uso WordPress.
    • Más que irse por “código perfectamente formateado y ultraescalable”, puede que se trate de dejar de trabajar en el codebase imperfecto actual y empezar un proyecto nuevo que sí será perfecto.
    • Esta división parece más bien la diferencia entre la nueva generación de desarrolladores full-stack JavaScript y quienes aprendieron con PHP + MySQL.
  • En la keynote de State of the Word de diciembre de 2022 se pensaba cubrir esto con bastante énfasis: https://wordpress.tv/2023/01/04/matt-mullenweg-state-of-the-...
    Como ingeniero, fue bastante impactante verlo funcionando de verdad y pensar en todas las capas con las que hay que interactuar para lograrlo. Me resulta divertido verlo convertirse en tema en HN seis meses después.

    • Me interesa mucho ejecutar dentro del navegador cosas que hasta ahora se consideraban aplicaciones “del lado del servidor”, así que esto me parece muy interesante. En particular, parece ser uno de los primeros casos de SQLite corriendo en un producto real, lo cual lo hace aún más interesante; antes solo había visto demos de juguete.
      Al revisar un poco el código, también me di cuenta de que hoy sé muy poco de PHP, y no parece que esto use el enfoque “tradicional” de SQLite sobre OPFS para la persistencia. Leyendo más, tampoco queda claro si el almacenamiento persistente mediante Emscripten sigue siendo posible. Al final encontré https://github.com/WordPress/wordpress-playground/issues/19, y parece indicar que en WordPress dentro del navegador todavía no es posible la persistencia, lo cual es una lástima.
    • La presentación estuvo buena. Para quien tenga curiosidad, Wordpress Playground se presenta a partir de 48:33.
  • Pregunto por pura curiosidad: si dejamos de lado la base de datos por el momento, ¿esto significa que se podría ejecutar WordPress en un Cloudflare Worker? https://developers.cloudflare.com/workers/runtime-apis/webas...

  • Uso WordPress con frecuencia para varios sitios casi estáticos. Es bueno para dejar que personas no técnicas sigan agregando contenido, y para ese propósito no hay una alternativa cercana a WordPress.
    Eso sí, hay que elegir con cuidado los plugins que se usan, configurar un front-end adecuado con Cloudflare y evitar que los usuarios hagan cosas que por fuera parecen simples pero son peligrosas. Siento que buena parte del odio a WordPress viene de gente que lo usó hace mucho tiempo, o que tenía requisitos que WordPress no podía satisfacer, o que lo heredó como legado.

    • Para mí fue una combinación del segundo y el tercer caso, además de clientes que insistieron en usar WordPress para proyectos en los que un CMS headless + código personalizado habría sido mucho mejor.
      En realidad no es culpa de WordPress, pero eso no cambia que con solo oír el nombre me dé un poco de miedo.
  • Este Playground que ejecuta PHP en WASM es mucho más responsivo que el 95% de los sitios web normales.

    • Lo más genial aquí es que reduce muchísimo los viajes de ida y vuelta al servidor. Todas las llamadas a la base de datos y las solicitudes de recursos ocurren en el cliente. Claro, hay que aceptar unos segundos de tiempo de carga.
      WordPress probablemente sea la solución de aplicación multipágina más usada, y esto básicamente lo convierte en una aplicación de una sola página. Además, como no necesita enviar continuamente solicitudes de API al servidor, también rinde mejor que la mayoría de las aplicaciones de una sola página.
      Las partes que son aplicaciones de una sola página, como el editor de entradas/páginas y el editor del sitio, son apps complejas en React, pero en esta demo se sienten más ágiles que en un entorno de desarrollo local. Muestra muy bien cuánto pueden mejorar las aplicaciones de una sola página cuando se eliminan los viajes de ida y vuelta al servidor. Como referencia, trabajo en Automattic, y fue realmente genial ver de cerca este experimento.
  • No hace falta desprestigiar a WordPress, pero tiene una historia larga y también muchos problemas. Estaría bueno contar con una alternativa moderna de autohosting que se pueda usar sin generación de sitios estáticos ni hosting complejo.

    • Cualquier competidor tiene que superar un problema del huevo y la gallina durísimo. WordPress tiene plugins que hacen casi cualquier cosa y, por lo general, también hay soporte pago disponible, así que es difícil evitarlo.
      La base de código no es buena, desarrollar encima de ella es un suplicio, y su forma de diseño y la administración de la tienda oficial tampoco evitan el caos y los riesgos del lado de la base de datos. Aun así, una propuesta de configurarlo en dos días y gastar 80 dólares al mes en plugins/temas es mucho más fácil de vender que “perfecto, primero necesitamos al menos dos meses de desarrollo”.
      Incluso cuando hace falta trabajo de desarrollo, es fácil encontrar gente con experiencia desarrollando para WordPress, y si no quieres contratar directamente, hay muchas agencias especializadas en WordPress. Un competidor emergente no tiene esas ventajas de escala. Diseñar un sistema extensible con estructura de plugins y temas que sea mucho mejor que WordPress no es poca cosa, pero tampoco es imposible ni requiere un equipo de genios. Sin embargo, en el camino real para desplazar a WordPress del mercado, esa es la etapa más fácil.
    • Hay muchos sustitutos funcionalmente perfectos, pero la propuesta de valor real de WordPress es su ecosistema de plugins, base de desarrolladores y comunidad de usuarios.
      Cualquiera se ha topado con clientes que solo quieren WordPress y no aceptan otra cosa. Incluso si despliegas una solución nueva y limpia, muchas veces el cliente termina volviendo a WordPress. Sí vi valor en un enfoque híbrido, donde los requisitos complejos los maneja una app personalizada hecha con otro framework, y el contenido se gestiona con una instancia de WordPress y conectores.
    • La razón por la que WordPress tuvo éxito hasta hoy es que, durante años, mientras otros CMS seguían rompiendo sus API, WordPress mantuvo en general la estabilidad, y gracias a eso creció un enorme ecosistema de plugins.
      Además, la API PHP de WordPress casi no usa orientación a objetos y se basa mayormente en funciones y arreglos, así que incluso alguien con conocimientos muy básicos de programación podía crear sus propios plugins o temas.
    • El CMS con el que los desarrolladores quieren trabajar y el CMS que las empresas quieren usar son cosas distintas. Para entrar en este último grupo, hay que tomar muchas decisiones pragmáticas que te alejan del primero.
      A las empresas les gustan las cosas que sobreviven mucho tiempo, y esas cosas, por definición, a menudo son anticuadas.
    • Aquí está: https://github.com/Qbix/Platform
  • La tecnología detrás de esta demo es realmente genial. Sería bueno poder ver logs en tiempo real de errores/advertencias de PHP, y en especial comprobar qué tan completo es este simulador, incluso con la reescritura de la base de datos SQLite.
    Probar plugins o temas también es muy fácil. Solo hay que agregar &plugin=plugin-slug-from-dir, y si el slug coincide con el slug del plugin en la URL de WordPress.org, se descarga automáticamente y se agrega al sandbox. La documentación completa de la API de consultas que configura el sandbox está aquí: https://wordpress.github.io/wordpress-playground/query-api/
    Estoy seguro de que debe haber alguna forma de abrir o mostrar los logs de depuración. Si no existiera algo así, no habrían podido desarrollar esto.