Se publicó el 17 de marzo del 2026. Laravel 14 aún no tiene fecha de salida pero se espera que sea lanzado el Q1 del 2027. En este caso la versión minima de PHP será PHP 8.4+ por que Symfony 8 asi lo requiere.

¿Y que novedades trae PHP 8.5?

Fue lanzado el 20 de noviembre del 2025. Tiene soporte activo.

Principales novedades:

• Extensión de URI nativa
• Operador pipe |>
• Clone with
• Atributo #[\NoDiscard]
• Closures y first-class callables en expresiones y constantes.
• Handles persistentes en cURL.
• Nuevas funciones:
  • array_first(), array_last(), backtraces en los errores fatales y nuevas APIs para el DOM, grafemas y cookies. tambien get_error_handler() y get_exception_handler().
• Deprecaciones:
  • El operador backtick como alias de shell_exec()
  • Los nombres de Cast no canonicos y el uso de null como offset de array.

Fuentes:

• https://benjamincrozat.com/laravel-13
• https://laravel-news.com/laravel-14
• https://www.zend.com/blog/php-8-5-features
• https://www.thedroptimes.com/56163/php-85-released-with-major-new-features-developers (Novedades de PHP 8.5)
• https://endoflife.date/php
• https://www.php.net/supported-versions.php

Saludos

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!

Para instalar Herd Laravel en Windows tienes que ir al enlace: herd.laravel.com/windows

¿Qué es Herd Laravel?

Es un entorno de desarrollo en PHP y Laravel nativo, que esta disponible para Windows y MAC, es rapido e incluye todo lo que se necesita para empezar con el desarrollo en Laravel, con herramientas como PHP, Nginx, vendria a ser un reemplazo moderno del XAMPP, aunque diseñado especificamente para Laravel.

Permite habilitar los dominios .test de forma automatica y se puede acceder desde el dominio .test usando el nombre del directorio. Sin configuraciones extrañas en Apache, hosts, puertos o cualquier otra configuración.

Ejemplo: C:\Users\Jeff\Herd\jeffsantillan
Navegador: www.jeffsantillan.test

¿Cómo funciona?

Herd maneja todo automaticamente, asi que no necesitas tener instalaciones separadas para PHP, Nginx, Node.js Composer por separado y la gestión de los archivos de configuración. Herd utiliza binarios nativos de PHP y lo convierte en una alternativa rapida de ejecución para entornos de PHP. Sin contenedores, sin virtual machines, ni metodos de virtualización. Solo binarios directos.

La instalación es necesario que se incluya los permisos de administrador para proceder, dar click derecho ejecutar como administrador.

Luego de la instalación puedes crear un proyecto en Laravel con Livewire con interfaz gráfica por Sites.

¡Saludos!