Cómo Configurar Drupal como Portal de Noticias o Medio Digital de Alto Tráfico
Si pasas por cualquier DrupalCamp europeo y preguntas qué CMS mueve The Economist o Al Jazeera, la respuesta es siempre la misma: Drupal. Hay una razón por la que aguanta lo que aguanta en medios grandes, y no es marketing. Es que la arquitectura encaja con el ritmo de una redacción: tipos de contenido que se modelan al detalle, un sistema de caché que se invalida quirúrgicamente y un core que asume desde el principio que vas a tener picos de tráfico salvajes cuando reviente una noticia.
Te cuento cómo montar Drupal para un medio que necesita aguantar todo eso. Desde el modelado de contenidos hasta la última capa de CDN, pasando por las decisiones aburridas pero importantes (las de OPcache, las de purgado selectivo) que marcan la diferencia entre servir una portada en 200 ms o caerse cuando entra un titular fuerte a las nueve de la noche.
Modelar el contenido como lo entiende la redacción
El error clásico es montar todo sobre un único content type "Article" y meter en él lo que sea. Funciona el primer mes. Luego un editor te pide diferenciar reportajes de noticias breves y empiezas a parchear con campos opcionales. Mejor pensar los formatos como los piensan los periodistas.
Noticia
El tipo más ligero. Titular, subtítulo, cuerpo en CKEditor con embeds (vídeo, tuits, lo habitual), imagen destacada con su campo de crédito fotográfico —que parece tontería hasta que el departamento legal te lo reclama—, taxonomía de sección, etiquetas, autor referenciado a una entidad Autor y un booleano "Urgente" que dispara estilos diferenciados en portada. Añade un campo de fecha de publicación separado del created: los editores necesitan ajustar la hora visible sin alterar el orden interno, y vas a agradecer no tocar el timestamp del nodo.
Artículo de Fondo
Piezas largas. Hereda los campos de Noticia y suma un "Tiempo de lectura" calculado por un hook presave (cuenta palabras y divide entre 200, no te compliques), una galería con Media Library y carrusel, y un campo de contenido relacionado curado a mano. El editor sabe mejor que cualquier algoritmo qué artículo encaja al final de un reportaje sobre la cumbre del clima.
Reportaje
Aquí es donde Drupal se luce. Paragraphs con tipos específicos —parrafo_texto, parrafo_imagen, parrafo_video, parrafo_cita, parrafo_mapa— o Layout Builder si tu equipo se siente cómodo con la interfaz de bloques. Permite construir narrativas largas con pull quotes, imágenes a sangre y vídeos intercalados sin tocar HTML. El periodista monta el reportaje como si fuera una maqueta de revista y el resultado queda decente sin necesidad de un maquetador.
Columna de Opinión
Más simple, pero con sus matices: foto y bio del firmante prominentes, un campo "Disclaimer" opcional para declarar conflictos de interés (cada vez más necesario) y un vocabulario dedicado de "Columnistas" que genera páginas de archivo por firma automáticamente.
Configura como mínimo tres modos de visualización por tipo: teaser para listados, full para detalle y rss para feeds. Es trabajo de quince minutos al principio del proyecto que te ahorra refactors enteros más adelante.
Taxonomías: el sistema nervioso
Secciones va como vocabulario jerárquico —Política > Nacional > Congreso— y cada término lleva sus propios campos: imagen de cabecera, color identificativo, editor responsable y meta tags SEO específicos. Sí, el término de taxonomía como entidad fielded; es de las cosas que más rentabilidad dan en un medio.
Tags plano y con autocompletado para evitar duplicados (que si no, acabas con "Elecciones 2026", "elecciones-2026" y "Elecciones2026" coexistiendo). Conecta contenido transversal: el tag "Elecciones 2026" cruza Política, Economía y Sociedad sin forzar la jerarquía.
Autores mejor como entidad propia con perfil completo. Un vocabulario auxiliar de "Firmas" ayuda a clasificar en Views sin liarte con relaciones de entidad referenciada cuando el filtro tiene que ser rápido.
Views: el motor de los listados
Views es lo que convierte la base de datos en portal. Las vistas que no te puede faltar:
Portada: la más crítica y la más sensible al rendimiento. Combina un bloque de Apertura (noticia destacada con imagen grande), bloques de últimas por sección, "Lo más leído" basado en Statistics o, mejor, una integración con Google Analytics Data API, y un bloque de opinión. Cada uno como display independiente, lo que te permite asignar TTLs distintos y purgar de forma quirúrgica.
Páginas de sección: vistas con argumento contextual del término de taxonomía, paginación y orden descendente por fecha de publicación.
Feeds RSS/Atom: displays de tipo Feed sobre las mismas vistas. URLs limpias como /seccion/politica/rss.xml que alimentan agregadores, Feedly y, lo más importante hoy, Google News.
Búsqueda: el Search API por defecto se queda corto a la primera. Solr o Elasticsearch con búsqueda facetada por sección, autor, rango de fechas y formato. Con varios millones de nodos, Solr responde por debajo de los 100 ms si lo configuras decentemente; el Search API de Drupal no va a hacerlo nunca.
Workflow editorial: estados que reflejan la sala
Content Moderation está en core desde Drupal 8 y reemplaza con ventaja todos los contribs antiguos de workflow. Define estados —Borrador, En revisión, Aprobado, Publicado y Archivado— y transiciones por rol.
El Periodista crea borradores y los manda a revisión, pero no publica. El Editor de sección revisa, devuelve a borrador con comentarios (Revision Log para que quede trazado) o aprueba. El Director publica, despublica y archiva lo que haga falta. Y, ojo a esto: define una transición directa de Borrador a Publicado restringida al rol de Editor senior. Cuando entra una alerta a las once de la noche no puedes tener al periodista de guardia esperando aprobación de tres niveles. Scheduler complementa programando publicaciones y despublicaciones —embargos, contenido patrocinado con ventana de exposición, lo que sea.
Varnish: la primera línea
Cuando el portal recibe miles de peticiones por segundo, Drupal no genera cada página. Para eso está Varnish delante: sirve desde RAM sin que la petición llegue siquiera al PHP-FPM.
El VCL personalizado define reglas por ruta: páginas de sección con TTL de 60 segundos, artículos individuales con 300 o más, portada con 15 a 30 segundos compensados con grace para servir contenido stale mientras se regenera en background. Esa directiva grace es la que evita el típico thundering herd cuando expira la portada y llegan diez mil peticiones simultáneas a Drupal.
El purgado selectivo es donde Drupal brilla de verdad. El módulo Purge con Varnish Purger envía invalidaciones automáticas al publicar o actualizar contenido: se invalida la portada, la página de sección y los listados afectados sin esperar al TTL. Y todo orquestado por las cache tags, que Drupal incluye nativamente en la cabecera X-Drupal-Cache-Tags de cada respuesta. Cuando una entidad cambia, Drupal manda invalidación por tag y Varnish purga todas las páginas que lo contenían. Es de esas cosas que cuando vienes de WordPress te parecen magia.
CDN: edge global
Por encima de Varnish, una CDN —Cloudflare o Fastly— acerca el contenido a los lectores distantes del origen.
Cloudflare se monta rápido: DNS apuntando al proxy, reglas de caché por ruta y Argo Smart Routing activado si tu tráfico lo justifica. Las Page Rules definen TTLs agresivos para assets estáticos y el HTML se invalida vía API desde el propio módulo Purge.
Fastly es más fino para un medio serio. El soporte nativo de Surrogate Keys se mapea uno a uno con las cache tags de Drupal y el módulo Fastly lo gestiona sin que tengas que pensar en ello. Cada invalidación se propaga al edge en milisegundos. Para un medio con tráfico internacional sostenido, la diferencia frente a Cloudflare se nota: pagas más, pero compras un control mucho más quirúrgico.
Más allá del caché
La caché resuelve las lecturas. Pero un portal también escribe, reindexa y procesa cosas pesadas en segundo plano.
PHP y OPcache: Drupal 10 pide PHP 8.1 mínimo. OPcache con 256 MB o más y opcache.validate_timestamps=0 en producción. Cada deploy hace opcache_reset() o reinicio de PHP-FPM y listo. Te ahorras la sobrecarga de recompilar en cada petición.
Base de datos: MariaDB o PostgreSQL con un pool de conexiones gestionado por ProxySQL. Cuando entra un pico de escritura —una noticia que está siendo editada por tres personas a la vez en directo, comentarios, métricas— el pool evita que se saturen las conexiones. Y revisa los índices compuestos en los campos de taxonomía y fecha de publicación de tus tablas field_data_*; las Views complejas se notan.
Cron y colas: nunca uses el cron de Drupal para tareas pesadas. La generación de sitemaps, el reindexado de Search API, la importación de feeds externos van a Queue API con un worker dedicado (Drush queue:run o un daemon supervisord). El cron estándar bloquea el proceso web y eso es lo que provoca esos 502 inexplicables a las 3 de la madrugada.
BigPipe y Dynamic Page Cache: ambos en core. Sirven la mayor parte de la página desde caché y cargan los bloques personalizados de forma asíncrona. El TTFB percibido mejora una barbaridad y para un lector logueado —suscriptor con paywall, por ejemplo— la diferencia es brutal.
Si tu redacción necesita una infraestructura Drupal que aguante el día que se viralice un reportaje, con un workflow editorial cosido a tu forma real de trabajar y una capa de caché que no te haga sudar cuando llegue el pico, en Tangram Consulting montamos la arquitectura desde cero o auditamos lo que ya tienes para encontrar dónde está sangrando.
Escalado horizontal: el día del pico
Las noticias gordas multiplican el tráfico por diez en cuestión de minutos. La arquitectura tiene que estar lista antes, no improvisada en mitad del incendio.
Separa los servidores web de la base de datos y del servidor de caché. Detrás de un balanceador (HAProxy, ALB, lo que tengas) puedes añadir instancias web bajo demanda. Las sesiones, fuera del filesystem local: a Redis o Memcache para que cualquier instancia atienda cualquier petición sin estado pegajoso. Los archivos subidos, a S3 vía el módulo S3 File System —olvídate del NFS compartido, que es la receta para el desastre cuando escalas.
Y haz pruebas de carga antes. k6 o Locust simulando el pico esperado —x10 sobre el tráfico medio es un buen punto de partida— y métete el resultado en el pipeline de despliegue. Encontrar el cuello de botella en staging cuesta una tarde. Encontrarlo en producción mientras estás en portada de Menéame cuesta lectores que no vuelven.