Llevo un tiempo siguiendo de cerca las últimas versiones de WordPress, y hay un proyecto que viene creciendo lanzamiento tras lanzamiento sin hacer mucho ruido fuera del círculo de desarrolladores: la Abilities API. Al investigarla en detalle, entendí por qué es probablemente uno de los cambios más importantes que WordPress ha introducido en los últimos años, aunque a simple vista parezca solo una API técnica más.

Antes de entrar en tecnicismos, conviene explicarlo de la forma más simple posible, porque no hace falta ser programador para entender por qué esto importa.

Primero, lo básico: ¿qué problema resuelve?

Imaginemos WordPress como una casa enorme con miles de habitaciones (plugins, temas, funciones del núcleo). Cada habitación tiene su propia puerta, con su propia cerradura y su propia forma de abrirla. Cuando una persona quiere hacer algo —publicar un artículo, cambiar el rol de un usuario, revisar el estado del sitio— sabe en qué habitación entrar y cómo moverse, porque usa el panel de administración con el mouse y el teclado, como siempre.

Ahora bien, un asistente de inteligencia artificial no «ve» el panel de administración de la misma manera. No sabe de forma intuitiva qué botón presionar ni en qué pantalla está la opción que necesita. Hasta ahora, si un desarrollador quería que una IA realizara alguna acción en un sitio WordPress, tenía que construir un puente a medida para cada tarea puntual, sin ninguna regla común entre plugins.

La Abilities API viene a resolver justamente eso: es un registro central donde WordPress —y cualquier plugin o tema— puede anotar, de forma clara y estandarizada, «esto es lo que sé hacer, esto es lo que necesito que me indiquen para hacerlo, esto es lo que voy a devolver, y estos son los permisos requeridos para que se me permita ejecutarlo». A cada una de esas acciones registradas se le llama una ability (habilidad).

Es, en el fondo, como colocarle una etiqueta clara y un manual de instrucciones a cada puerta de la casa, escrito en un idioma que tanto una persona como un programa de computadora pueden leer sin confundirse.

¿Por qué esto es tan importante ahora?

Porque cada vez más personas usan asistentes de IA (como Claude, ChatGPT o Gemini) para pedirles tareas del tipo «revisa los últimos artículos que escribí este mes y arma un resumen» o «dime si tengo comentarios pendientes de moderar». Para que un asistente pueda hacer eso de forma confiable —y sobre todo, de forma segura, sin modificar cosas que no debería— necesita un mapa claro de qué puede hacer en ese sitio y bajo qué permisos. La Abilities API es exactamente ese mapa.

Línea de tiempo: cómo fue avanzando

Para que quede clara la evolución, así fue apareciendo esta pieza en los últimos lanzamientos de WordPress:

• WordPress 6.9 (diciembre de 2025). Aquí nace oficialmente la Abilities API como parte del núcleo de WordPress, en su versión de PHP. Trajo un primer conjunto reducido de habilidades básicas del propio WordPress: información del sitio, datos del entorno técnico y datos del usuario conectado en ese momento.
• WordPress 7.0 «Armstrong» (20 de mayo de 2026). Se sumó la contraparte para JavaScript y, lo más relevante, llegó el AI Client: una forma de que los plugins puedan enviar solicitudes a modelos de inteligencia artificial sin atarse a un proveedor específico. Es en este punto donde las abilities dejan de ser solo un catálogo y comienzan a ser realmente útiles: son las «herramientas» concretas que ese cliente de IA puede usar para actuar sobre el sitio.
• 2 de julio de 2026. Se presentó una propuesta para ampliar el catálogo de habilidades del núcleo, pensando en casos concretos como pedirle a un asistente que redacte un borrador con el resumen de los artículos publicados durante un mes, citando las fuentes originales.
• WordPress 7.1 (mediados de agosto de 2026). Esta versión es la que hace que la API sea, según los propios desarrolladores, «realmente construible»: llegaron ajustes al ciclo de ejecución de las habilidades y trabajo de preparación para que distintos programas externos puedan conectarse de forma más ordenada.

¿Cómo se ve esto en la práctica?

Un desarrollador que quiere exponer una función de su plugin como «ability» utiliza una función del núcleo llamada wp_register_ability(), donde define un nombre único, una descripción, qué datos necesita recibir, qué va a devolver y qué permisos son necesarios para ejecutarla. Al ser parte del núcleo de WordPress escrito en PHP, es completamente inspeccionable desde herramientas de línea de comandos como WP-CLI: cualquier desarrollador puede listar, en segundos, qué habilidades están registradas en un sitio, sin necesidad de pasar por el panel de administración ni por ningún asistente de IA. Esto la vuelve muy práctica tanto para depurar errores como para construir automatizaciones que no dependan de inteligencia artificial en absoluto.

Lo que esto significa a futuro

Lo más interesante de este proyecto es hacia dónde apunta: un WordPress donde las acciones automatizadas —ya sean ejecutadas por una IA, por un script propio o por otra herramienta externa— quedan claramente declaradas, verificadas contra permisos reales, y son descubribles en el momento, en lugar de depender de integraciones improvisadas y frágiles. Es un cambio de fondo, no cosmético: WordPress se está preparando activamente para un contexto donde no solo las personas administran sitios web, sino también programas que actúan en su nombre.

Vale la pena aclarar que todavía es un proyecto en desarrollo activo, por lo que algunos detalles de implementación pueden seguir cambiando en próximos lanzamientos. Pero la dirección ya está bastante clara, y para quienes administran o desarrollan sitios en WordPress, es un tema que conviene empezar a seguir de cerca.

¡Saludos!

Llevo un tiempo mirando de cerca los starter kits de Laravel 13, y hay algo que se repite en casi todos los proyectos nuevos que arrancan con Livewire: aparece Flux UI. No es casualidad. Cuando empecé a revisar cómo está armado el kit oficial de Livewire para Laravel 13, noté que Flux ya no es un componente más de la lista de dependencias, sino la base visual completa sobre la que se construye la aplicación. Y eso, para quienes venimos peleando durante años con Blade «a mano» o con librerías de componentes pensadas para SPA, cambia bastante el punto de partida.

¿Qué es exactamente Flux UI?
Flux es la librería oficial de componentes para Livewire, construida por el mismo equipo detrás de Livewire y Alpine.js. La idea de fondo es simple: en vez de escribir un botón, un modal o una tabla desde cero cada vez, usás una sintaxis tipo HTML —algo como <flux:button> o <flux:modal>— y Flux se encarga del resto: estilos con Tailwind CSS, accesibilidad, modo oscuro y comportamiento responsive ya resueltos de fábrica.

Lo interesante es que no reemplaza a Livewire, lo complementa. Tú sigues escribiendo tu lógica en PHP como siempre, pero el «cascarón» visual —el que normalmente te toma más tiempo del que te gustaría admitir— ya viene armado, probado y pensado para funcionar bien tanto en desktop como en mobile.

Por qué aparece justo ahora en Laravel 13

Acá viene la parte que más me llamó la atención. El starter kit oficial de Livewire para Laravel 13 combina Livewire, Tailwind y Flux UI como stack por defecto, dejando toda la lógica de frontend y backend directamente dentro de tu aplicación para que puedas modificarla sin pelear contra una «caja negra». Es la misma filosofía que Laravel viene aplicando con sus otros starter kits (el de React usa Inertia 3 y shadcn/ui), pero para el mundo Livewire, Flux es la pieza que faltaba: antes tenías que salir a buscar librerías de terceros o armar tu propio sistema de diseño desde cero.

En paralelo, Flux llegó a su versión 2.0, y ahí el equipo tomó una decisión que se nota en el día a día: en lugar de integrar librerías externas de gráficos o selectores de fecha, construyeron esos componentes desde cero. El resultado son piezas más livianas —apenas unos kilobytes extra al bundle final— y, sobre todo, con menos piezas sueltas de las que depender quiero decir, menos riesgo de que una dependencia externa se rompa con una actualización.

Cómo se usa en la práctica

La instalación es la típica de Laravel: un

composer require livewire/flux

y dos directivas Blade (@fluxAppearance y @fluxScripts) en tu layout principal. A partir de ahí, empezás a escribir interfaces con una sintaxis bastante legible. Un ejemplo típico que vi replicado en varios tutoriales recientes de CRUD con Laravel 13 y Livewire 4 es algo así: un encabezado con flux:heading, un botón que abre un modal con flux:modal.trigger, y una tabla ordenable con flux:table que ya trae paginación y ordenamiento por columna resueltos. Lo que antes eran veinte líneas de Blade con clases de Tailwind repetidas por todos lados, ahora es una etiqueta con un par de atributos.

Flux tiene un nivel gratuito bastante generoso, pensado para cubrir lo esencial: botones, dropdowns, modales, inputs, checkboxes, radios y selects. Ahí es donde vive la mayoría de las pantallas de un CRM interno o un panel de administración estándar. Cuando el proyecto necesita algo más ambicioso, entra en juego Flux Pro, con componentes como calendarios, selectores de fecha, editores de texto enriquecido, paletas de comandos y gráficos, todos construidos siguiendo la misma lógica de accesibilidad y soporte para modo oscuro.

Lo que me parece más valioso (y lo que hay que tener en cuenta)

Lo que más rescato de Flux es que resuelve un problema real: la brecha entre «developer backend que sabe Livewire» y «developer que además tiene que diseñar interfaces prolijas». Con componentes pensados para teclado y lectores de pantalla desde el diseño, te ahorrás una capa entera de trabajo de accesibilidad que, seamos honestos, muchas veces queda para «después» y nunca llega.

Ahora bien, hay un matiz importante: los componentes más avanzados están detrás de una licencia Pro, así que si tu proyecto necesita gráficos, editor de texto enriquecido o un calendario completo, ese costo entra en la ecuación desde el día uno. También vale la pena mencionar que ya empezó a moverse un ecosistema alrededor de Flux —herramientas como constructores visuales de páginas tipo drag-and-drop que se apoyan en Flux UI Pro para armar módulos completos sin escribir código—, lo cual es una buena señal de adopción, pero también implica que el ecosistema todavía se está asentando.

Conclusión

Si estás por arrancar un proyecto nuevo con Laravel 13 y piensas usar Livewire, probar el starter kit oficial con Flux UI de entrada me parece el camino más razonable hoy. No solo por ahorrar tiempo de maquetado, sino porque te deja una base consistente de diseño desde el primer commit, algo que en proyectos que crecen con el tiempo termina siendo más valioso de lo que parece al principio. Todavía me falta llevarlo a un proyecto de producción más grande para sacar conclusiones sobre cómo escala en equipos, pero como primera impresión, Flux se siente como una herramienta hecha por gente que usa Livewire todos los días y sabe exactamente dónde duele.

Enlaces:

• Flux 2: https://laravel-news.com/flux-2-livewire-ui-kit
• Starter Kits: https://laravel.com/starter-kits
• Instalación: https://fluxui.dev/docs/installation

¡Saludos!

¿Qué es, en el fondo?

ngrok es una herramienta que crea un túnel seguro entre internet y un servidor que corre en tu máquina local. En términos simples: agarra lo que tienes corriendo en localhost:3000 (o el puerto que sea) y le pone una puerta de entrada pública, una URL real de internet, que redirige todo el tráfico hacia tu máquina. Técnicamente funciona como un proxy inverso: crea un túnel seguro entre un endpoint público y un servicio que corre localmente, y además captura y analiza todo el tráfico que pasa por el túnel para poder inspeccionarlo o reenviarlo después.

Para que se entienda con una analogía: imagina que tu computadora es una casa sin dirección postal. ngrok le da una dirección temporal y le pone un cartero que reenvía cada carta (cada petición HTTP) directo a tu puerta, sin que tengas que mudarte ni construir nada nuevo.

Lo que empezó como una utilidad de tunneling relativamente simple se fue convirtiendo, con los años, en algo más ambicioso. Con el tiempo la plataforma amplió sus capacidades más allá del tunneling básico, sumando inspección y reenvío de tráfico, control de accesos y dominios estáticos, posicionándose como una herramienta más amplia de acceso para desarrollo y DevOps. Y no es un dato menor: la empresa detrás del proyecto atrajo inversión de capital de riesgo significativa, incluida una ronda de 50 millones de dólares liderada por Lightspeed Venture Partners, lo que da una idea de cuánta demanda real hay por resolver este problema tan puntual.

El uso básico: exponer tu localhost en tres pasos

Aquí es donde ngrok brilla de verdad, y es lo que probablemente te trajo a leer esto. El flujo típico es así:

1. Instalas el cliente de ngrok en tu máquina (hay versiones para Mac, Windows y Linux, y también se puede correr como binario suelto sin instalación compleja).
2. Levantas tu servidor local como siempre lo harías (tu API en Express, tu app en Django, lo que sea) corriendo en, digamos, el puerto 3000.
3. Ejecutas un comando parecido a ngrok http 3000.

Y eso es todo. En cuestión de segundos, ngrok te devuelve una URL pública (algo como https://a1b2c3d4.ngrok-free.app) que cualquiera en internet puede visitar, y que reenvía cada petición hasta tu servidor local como si nunca hubiera salido de tu máquina. Mientras el túnel está abierto, tienes además una interfaz local de inspección donde puedes ver, en tiempo real, cada petición que llega: headers, body, código de respuesta, todo. Y lo mejor es que puedes reenviar esas peticiones sin tener que provocar el evento original de nuevo, algo que se agradece muchísimo cuando estás depurando.

Dónde se usa esto en el día a día

Probar webhooks es, sin duda, el caso de uso número uno. Servicios como Stripe, Twilio o Shopify no te avisan de un evento (un pago, un mensaje, una compra) llamando a tu localhost; necesitan una URL pública real a la que enviarle esa notificación. Poder reenviar esas peticiones sin disparar de nuevo el evento original es especialmente valioso cuando se están probando manejadores de webhooks para servicios como Stripe o Shopify. Antes de ngrok, para probar esto en serio tenías que desplegar tu código a un servidor real cada vez que querías validar un cambio. Ahora simplemente corres el túnel y listo.

Otros usos que probablemente te van a sonar familiares:

• Mostrar una demo en vivo. ¿Tu app todavía no está desplegada pero tu jefe o un cliente quiere verla ya? Compartes el link de ngrok y listo, sin pasar por un proceso de deploy.
• Probar en el celular u otro dispositivo. Ideal para revisar cómo se ve tu web en un teléfono real, no en el simulador del navegador.
• Integraciones entre servicios en desarrollo. Cuando dos equipos están construyendo partes distintas de un sistema y necesitan que sus entornos locales se hablen entre sí.
• Trabajo remoto o colaborativo puntual. Compartir acceso temporal a algo que corre en tu máquina sin montar infraestructura.

Lo que hay que tener claro antes de usarlo

Acá viene la parte donde conviene ser honesto, porque ngrok no es magia gratuita ni una solución de producción. El plan gratuito ha cambiado bastante con el tiempo y hoy trae más límites que antes: sesiones con tiempo máximo, ancho de banda limitado, y una página intersticial de advertencia que ven los visitantes antes de llegar a tu contenido. Si necesitas un dominio propio fijo, más ancho de banda o funciones de seguridad como restricciones por IP, autenticación OAuth o políticas de tráfico personalizadas, eso ya entra en los planes pagos.

Y aquí va el matiz más importante: ngrok es una herramienta de desarrollo y pruebas, no de hosting. No está pensada para que tu aplicación viva ahí de forma permanente ni para tráfico de producción real. Es, literalmente, un puente temporal entre tu máquina y el mundo. Para producción existen otras soluciones (VPS, servicios cloud, plataformas de despliegue) que están diseñadas para eso.

Tampoco es la única opción del mercado (existen alternativas como Packetriot, Cloudflare Tunnel o localtunnel), pero ngrok sigue siendo, con diferencia, la más popular y la que casi todo tutorial o documentación de webhooks menciona primero.

Lo que más me gusta de ngrok es justamente su simplicidad: resuelve un problema muy concreto «necesito que internet vea lo que tengo en mi máquina, ya, sin desplegar nada» con un solo comando. No es la herramienta que vas a usar todos los días si trabajas en producción, pero es de esas utilidades que, una vez las conoces, te preguntas cómo hacías antes para probar un webhook o mostrar una demo a último momento. Si todavía no la has probado, instalarla y correr tu primer túnel te toma literalmente cinco minutos.

¿La usas para webhooks, para demos, o le has encontrado otro uso interesante? Me encantaría leer en qué la aplicas tú.

Instalación:

Pueden encontrar el instalador en la Microsoft Store

ngrok --version

Fuentes

• Wikipedia, «Ngrok»
• StackShare, comparación ngrok vs. Packetriot
• Pangea, glosario: qué es ngrok