Drupal 11: lo que necesitás saber para 2026

Drupal 11 no es un salto traumático como fue Drupal 8, pero trae decisiones de arquitectura que vale la pena entender. Si venís de Drupal 10, la migración es suave. Si venís de Drupal 7… tenemos que hablar.

El render pipeline cambió (otra vez)

El cambio más importante en Drupal 11.4 es la consolidación del auto-placeholdering en el sistema de caché. Antes, Drupal decidía qué era cacheable dinámicamente basándose en heurísticas que a veces fallaban estrepitosamente. Ahora el sistema es más explícito:

// Drupal 10: el placeholder se generaba automágicamente
$build['#lazy_builder'] = ['mymodule.lazy', []];

// Drupal 11.4: necesitás declarar la estrategia de caché
$build['#cache']['contexts'][] = 'user.permissions';
$build['#lazy_builder'] = ['mymodule.lazy', []];
$build['#auto_placeholder_behavior'] = 'hybrid';

¿La moraleja? Si tu módulo custom usa lazy builders sin declarar contextos de caché, en Drupal 11 vas a ver comportamientos raros. Revisá tus custom modules antes de migrar.

Headless: el elefante en la habitación

Drupal sigue insistiendo en que su JSON:API es la solución headless definitiva. No lo es. Si vas a exponer Drupal como backend headless en 2026, evaluá tres opciones:

1. JSON:API — OK si tu frontend es un SPA y necesitás toda la metadata de Drupal
2. GraphQL (vía el módulo contrib) — mejor si controlás qué datos exponés exactamente
3. Decoupled Router + subrequests — mi favorito para setups híbridos Astro/Drupal

Si estás arrancando un proyecto nuevo y la respuesta automática es “Drupal headless con React”, frená un segundo. ¿De verdad necesitás un CMS enterprise para un blog con formularios? Hay un espectro entre “WordPress con ACF” y “Drupal headless con Next.js” y la mayoría de los proyectos viven en el medio.

Lo que NO cambió (y es un problema)

El sistema de configuración (config import/export) sigue siendo rígido. En Drupal 11.4 no hay mejoras significativas en el deploy de configuración entre entornos. Si trabajás con CI/CD y múltiples entornos (dev → staging → prod), seguís necesitando herramientas externas o scripts custom para manejar config splits.

Mi recomendación: config_split + config_ignore + un script de deploy que sepa cuándo forzar un drush cim --partial. No es elegante, pero funciona.

Veredicto

Drupal 11 es sólido. Si ya estás en Drupal 10, migrá sin miedo. Si estás en Drupal 7, tenés un camino más largo pero más claro que hace 3 años. La comunidad entendió que la estabilidad importa más que reescribir todo cada dos versiones.