Mayo de 2026: Umbraco 18 pasó de beta1 a release candidate en quince días

· JD + AI · Umbraco

Mayo de 2026: Umbraco 18 pasó de beta1 a release candidate en quince días

Umbraco 18 beta1 salió el 13 de mayo, beta2 al día siguiente y la release candidate el 28 de mayo. Quince días de la primera beta a la RC. Las notas de beta1 traen treinta y cinco entradas bajo el título "Breaking Changes", y si mantiene un paquete, una extensión o una solución con algo custom atornillado al backoffice, esa lista es su mayo.

Lo que conviene leer es la cadencia, no una funcionalidad puntual. Un fabricante que comprime beta a RC en dos semanas está diciendo que la forma de la release ya está decidida y que la ventana para encontrar problemas en el código propio es corta.

Quince días, y dónde están realmente los cambios rompientes

Umbraco 18.0.0-beta1 — lauraneto, releases de Umbraco CMS Umbraco 18.0.0-beta2 — AndyButland, releases de Umbraco CMS Son las notas de release de Umbraco en el repositorio de Umbraco, así que hay que leerlas como el fabricante hablando de su propio producto. beta2 cambió dos cosas respecto de beta1, un arreglo del tag de prerelease en el backoffice y el registro de un handler de SignalR, y por lo demás repite la misma lista acumulada. Las treinta y cinco entradas rompientes son casi todas de dos tipos: código obsoleto que por fin se elimina en el corte de v18, o nulabilidad ajustada para que coincida con el comportamiento real.

Cuatro son las que revisaríamos primero en una solución real. Los webhooks ahora usan por defecto el payload "minimal", lo que cambia en silencio lo que reciben sus suscriptores. Desaparecieron MigrationBase y todas las migraciones entre v13 y v17, algo que importa si su camino de actualización suponía saltar desde un LTS viejo de una sola vez. "Master Template" pasa a llamarse "Layout Template", cosmético hasta que aparece en su documentación y en su material de onboarding. Y el nombre pasa a ser no nulable en los constructores de content, element, media y member, que es el tipo de cambio que compila bien salvo en el único lugar donde no.

Elements, esquemas tipados y el final de Swashbuckle

La release candidate de Umbraco 18 — Andy Butland, blog oficial de Umbraco Butland escribe para el fabricante, así que esto es un anuncio de lanzamiento y no un análisis, pero es detallado y es honesto sobre el alcance. Tres cosas llegan en 18.

Elements es el titular, y es explícitamente fase uno: una sección Library en el backoffice para contenido reutilizable fuera del árbol de documentos, con seguimiento de referencias, publicación programada, rollback, permisos y un picker de elementos configurable. Lo que la mayoría realmente quiere, mezclar elements con bloques sueltos en el Block Editor y convertir un bloque en un element de la biblioteca, está apuntado a Umbraco 19 más adelante en 2026 según el mismo post. Si viene modelando settings del sitio y datos del footer como páginas no ruteables, 18 les da un lugar mejor y 19 le da el resto.

Los esquemas OpenAPI tipados para la Delivery API son opt-in y cambian solamente el documento OpenAPI; las respuestas no cambian. Esa distinción decide si le sirve o no. Si consume la Delivery API directamente, no gana nada. Si genera clientes a partir de la especificación, gana modelos tipados de verdad por cada tipo de documento. El propio Butland marca la salvedad: los esquemas usan oneOf con discriminadores de OpenAPI 3.1, el soporte de los generadores es desparejo, así que verifique la salida contra su herramienta antes de depender de eso.

Swashbuckle queda reemplazado por Microsoft.AspNetCore.OpenApi. Este es el que rompe a los autores de paquetes. Cualquier extensión que armaba su propio documento OpenAPI en 17 no compila en 18, porque los tipos de Swashbuckle ya no están. Hay un helper nuevo, AddBackOfficeOpenApiDocument(), que cubre casi toda la migración en una llamada, y el endpoint de OpenAPI se muda. Presupueste una tarde por paquete, no un sprint, pero presupuéstela ahora: el post de la RC pide pruebas contra proyectos reales entre el 28 de mayo y el 25 de junio.

Dos posiciones sobre IA, y ninguna se entrega como un botón

IA en sus términos: cómo Umbraco replantea la IA — Jeppe Birkebæk Truelsen, Technical Enablement Specialist en Umbraco, en el blog de Umbraco Umbraco escribiendo sobre la estrategia de IA de Umbraco, así que léalo como posicionamiento. La posición en sí es lo bastante inusual como para tenerla presente: el núcleo del CMS se mantiene deliberadamente sin funcionalidades de IA, y la IA llega por una capa aparte con el cliente eligiendo el modelo. Truelsen lo plantea como introducir IA "without forcing organizations to surrender control in exchange for convenience". Si los productos cumplen eso es una pregunta de 2026, pero como postura declarada es lo contrario de lo que este mercado publicó el año pasado.

Diseñar una skill de agente de IA para agregar un page type a Umbraco — Paul Seal, Codeshare La versión comunitaria de la misma pregunta, y el documento más útil. Seal, junto con Andy Eva-Dale y Callum Whyte, pasó dos reuniones del equipo comunitario de IA de Umbraco discutiendo convenciones de nombres, tabs, composiciones y qué significa siquiera "agregar una página" antes de escribir una sola skill. Esa discusión es el artefacto. Cualquiera que esté estandarizando scaffolding asistido por agentes en su equipo va a tener la misma discusión, y esto es ventaja inicial.

Cómo dejé que Cursor construyera un proveedor de Azure Search para Umbraco Search — la página no acredita a nadie Nuestra cosecha no registra autor para este post; corre en jeroenbreuer.nl, cuya descripción de sitio menciona a Jeroen Breuer, pero el artículo en sí no acredita a nadie y no vamos a suponer. Tampoco tenemos declarado el interés comercial de la fuente, así que léalo como el escrito de un practicante de afiliación desconocida. Lo transferible es el método: antes de pedirle al agente que construyera nada, se lo apuntó a cuatro bases de código (los proveedores de Elasticsearch y Typesense, un playground de Azure Search, el proyecto demo) con la misma instrucción cada vez, y se lo obligó a producir una estrategia antes de una línea de código del proveedor. Primero la fase de investigación, después la generación.

Las notas de campo que valen una tarde

Lo que un trace lento de Chrome nos dijo sobre una página de catálogo de 2.000 productos — Josh Wood, TSD Digital La mejor escritura técnica en la órbita Umbraco de este mes, y no es sobre Umbraco. Una página de categoría con 1.948 listados tenía una tarea bloqueante peor de 14.117 ms, una segunda de 10.471 ms y 318 recálculos de estilo dentro de una sola tarea. Los arreglos no tienen glamour: throttlear el handler de scroll de la barra de filtros fija y agrupar sus lecturas antes de sus escrituras, y aplicar un debounce de 250 ms al callback del IntersectionObserver para que pasar scrolleando frente a 200 tarjetas deje de disparar 200 requests. La conclusión que generaliza: que una pestaña móvil se muera es una historia de memoria del renderer, no del heap de JavaScript, y content-visibility: auto con contain-intrinsic-size es la palanca más grande en cualquier listado largo. TSD Digital implementa comercialmente, y este es además el segundo ítem del mes salido de su blog, así que pese la función de marketing en consecuencia. Los números siguen siendo números.

Armar un roadmap de personalización con un presupuesto realista — Tim Gaunt, TSD Digital El otro post de TSD, y Gaunt vende trabajo de personalización, cosa que dice abiertamente: la pieza arranca con una objeción de llamada de ventas. Descuente el encuadre y el argumento se sostiene: los proyectos de personalización fracasan por secuenciación y no por presupuesto, y un plan de doce meses en tres fases que empieza por una auditoría de analítica no cuesta nada en la fase uno. Útil la próxima vez que un cliente pida personalización y quiera decir "cómprennos una plataforma".

Un fin de semana sin acceso a internet — Owain Williams, Owain Codes Una cabaña sin wifi se convirtió en el hallazgo operativo más filoso del mes: no se puede entrar al backoffice local de un sitio en Umbraco Cloud sin llegar a la autenticación de Umbraco Cloud, y no se puede crear una cuenta de usuario local hasta haber entrado una vez por la nube, haber salido y haber vuelto a entrar. Hágalo mientras todavía tiene señal. Cualquiera que trabaje en un tren entiende por qué importa.

Por qué la accesibilidad en la web es crítica — Dave Jonker, Dynamic Dave El argumento para tratar la accesibilidad como modelado de contenido y no como una auditoría previa al lanzamiento, escrito contra Umbraco 17. Nada acá va a sorprender a quien ya lo crea, y justamente por eso es la pieza para reenviar a quienes no.

Debajo, y alrededor

uSync v17.3.2 "SingleBlock" — Kevin Jump Un parche chico con un motivo concreto para prestarle atención: corrige el doble encodeo de valores JSON no string dentro de bloques anidados y agrega un mapper de SingleBlock. Si sus diffs de uSync en v17 vienen ruidosos alrededor de valores de bloques, ahí está la explicación. El arreglo llegó de un colaborador primerizo.

.NET 11 Preview 4 (EF Core) — rbhanda, releases de Entity Framework Core Casi todo son bumps de dependencias y commits de bots, más binding de propiedades complejas en Cosmos. Aparece acá solo porque la capa de datos de Umbraco se apoya en EF Core y la cadencia de previews conviene seguirla, no porque la preview de mayo le cambie algo. Es flaca, y preferimos decirlo antes que inflarla.

La gente, breve

uProfile de mayo de 2026 — Bernadet Goey — Bernadet Goey, en el blog de Umbraco Goey escribe su propio perfil para la serie comunitaria del fabricante: una década como especialista en PHP, tres años en Umbraco, hoy software engineer en ilionx, en Países Bajos. La parte honesta es la del medio: pasar a .NET hizo que una desarrolladora senior se sintiera junior de nuevo. Vale pasárselo a quien en su equipo esté hoy en ese hueco.

Codegarden 2026, ya falta poco — Owain Williams, Owain Codes Codegarden se muda de Odense de vuelta a Copenhague, con el MVP Summit el lunes y el martes previos. Williams habla veinte minutos sobre la Management API, que según él está subutilizada. En eso tiene razón.

Qué haríamos con este mes

Quince días de beta1 a RC no es una release apurada; es una release cuyo riesgo se movió hacia usted. La ventana comprimida funciona porque los cambios rompientes se concentran en la eliminación de código marcado como obsoleto varias releases atrás, lo que es justo, y porque Umbraco apuesta a que el ecosistema pruebe durante la RC y no después. Esa apuesta solo paga si los autores de paquetes y las agencias efectivamente corren su código contra la RC antes del 25 de junio.

Entonces baje la RC a una rama esta semana, compile sus paquetes y mire con lupa cualquier cosa que registrara su propio documento OpenAPI o consumiera un payload de webhook. El renombre y el ajuste de nulabilidad aparecen en tiempo de compilación. El default del webhook no. Aparece en producción, un martes, en el sistema de otro.

La lectura más amplia de mayo: lo interesante que se escribió sobre Umbraco no era sobre Umbraco. Un trace de Chrome, un argumento de secuenciación y una cabaña sin wifi produjeron más ingeniería transferible que la lista de funcionalidades. No es una crítica a la release. Es un recordatorio de que un roundup de CMS que solo cubre el CMS se pierde adónde va el trabajo de verdad.

Fuentes

Los títulos se conservan en su idioma original: así es como se cita un documento y así es como lo vas a encontrar.

umbraco · sitecore-search · umbraco-cms · umbraco-backoffice · umbraco-apis · content-modelling · product · community

2026 © Umbracolombia - Todos los derechos reservados.