main content

Drupal para webs de eventos, conferencias y gestión de inscripciones online

El día que abres inscripciones, el servidor se entera. Lo digo por experiencia: la primera web de congreso médico que monté en Drupal aguantó tres minutos antes de que un correo del comité organizador a 4.800 socios reventara la cola de PHP-FPM. Desde entonces tengo otra forma de mirar este tipo de proyectos. No es «hagamos una web con una agenda y un formulario». Es «hagamos una web que el día D abra puertas, cobre, emita entrada, escanee QR, registre asistencia y, dos semanas después, mande el certificado en PDF firmado». Esa es la pelea real.

Este artículo va de eso: cómo se monta Drupal para webs de eventos, conferencias y gestión de inscripciones online sin que el día clave te pille con la guardia bajada. Hay alternativas SaaS conocidas (Eventbrite, Hopin, Splash) y funcionan razonablemente, pero te cobran comisión por entrada (Eventbrite se mueve entre el 3,5% y el 8% según el plan) y te imponen su HTML. Para una organización que celebra dos congresos al año y media docena de jornadas, las cuentas dejan de salir bastante antes de lo que uno cree.

Antes de tocar un módulo: estructura de datos

Cada vez que veo un proyecto que empieza instalando módulos sin haber dibujado los tipos de contenido en una pizarra, sé que en la fase 3 vamos a refactorizar. Conviene empezar al revés.

Tipos de contenido mínimos

Tipo de contenido Campos principales Relaciones
Evento Título, fecha inicio/fin, ubicación, descripción, imagen, aforo máximo, precio, estado (abierto/cerrado/cancelado) Referencia a Ponentes, Categoría de evento
Ponente / Speaker Nombre, bio, foto, empresa, cargo, redes sociales Referencia desde Evento y Sesión
Sesión Título, hora inicio/fin, sala, descripción, nivel (básico/avanzado), materiales adjuntos Referencia a Evento, Ponente
Sede / Venue Nombre, dirección, coordenadas GPS, capacidad, mapa, instrucciones de acceso Referencia desde Evento

Si dudas si necesitas «Sesión» como tipo aparte, pregúntate si vas a tener tracks paralelos. Si la respuesta es sí, ahórrate el dolor y créalo ahora.

Taxonomías

  • Categoría de evento: Conferencia, Workshop, Networking, Formación, Congreso.
  • Temática: según el sector (Tecnología, Marketing, Legal, Finanzas…).
  • Formato: Presencial, Online, Híbrido.
  • Track / Línea temática: para conferencias con sesiones paralelas.

Con esta base, Views hace lo suyo: agendas filtradas por track, listados por temática, mapa de sedes. Y escala. He visto este esquema funcionando igual de bien en una asociación que monta cinco eventos al año que en otra que pasó de doce a cuarenta y siete sin tocar la arquitectura de contenido.

Los módulos que de verdad usas

No hay un «módulo de eventos» en Drupal. Hay piezas que combinas. La primera vez asusta; la quinta te das cuenta de que es la ventaja, no el problema.

Calendario y agenda

Módulo Versión estable (Drupal 10/11) Función
Calendar 1.x (Drupal 10) Vista de calendario mensual/semanal/diaria basada en Views
FullCalendar View 3.x (Drupal 10, 11) Integración con la librería JavaScript FullCalendar 6.x, con drag & drop y vistas responsivas
Smart Date 4.x (Drupal 10, 11) Campo de fecha inteligente que gestiona rangos, recurrencia y zonas horarias
Date Recur 3.x (Drupal 10, 11) Eventos recurrentes con reglas RRULE (compatible con iCal)

Mi combinación favorita: Smart Date como campo de fecha + FullCalendar View como visualización. Smart Date te resuelve el dolor de cabeza de los rangos con zona horaria (que en un congreso híbrido con asistentes desde México y Madrid no es algo cosmético). FullCalendar View renderiza en cliente y filtra por categoría o track sin recargar página, que es lo que la gente espera cuando entra a buscar «¿a qué hora habla Fulanita?».

Inscripciones: ¿formulario o tienda?

Aquí se bifurca el camino. Y la decisión cuesta dinero si la tomas mal.

Opción A: Webform (eventos gratuitos o registro simple)

Webform (6.2.x en Drupal 10, ya compatible con Drupal 11) es lo más cercano a una navaja suiza que tiene este CMS. Para una jornada gratuita con campos de nombre, email, empresa, cargo y «¿a qué sesiones piensas asistir?» tira de sobra.

Lo que de verdad usas de Webform en este contexto:

  • Límite de envíos para clavar el aforo.
  • Apertura y cierre programados del formulario (la inscripción abre el 1 de marzo a las 09:00 y cierra el 15 de abril a las 23:59, sin que nadie tenga que entrar a desactivarlo a mano).
  • Confirmación por email con tokens (nombre del evento, fecha, datos del inscrito).
  • Exportación a CSV cuando el equipo de patrocinios te pide la lista a las tres de la tarde.
  • Lógica condicional para mostrar campos según el tipo de entrada.
  • Borradores: el usuario empieza la inscripción, cierra la pestaña sin querer y al volver lo retoma donde lo dejó. Si no lo activas, te llegarán correos.

Opción B: Commerce + Commerce Event Registration (eventos de pago)

Cuando hay dinero de por medio, ya no vale el formulario. Necesitas carrito, pasarela, factura, devoluciones. Drupal Commerce (2.x/3.x) convierte el sitio en una tienda completa.

La arquitectura, en seco:

  1. Cada tipo de entrada (general, VIP, early bird, estudiante) es una variación de producto.
  2. El evento referencia al producto.
  3. El usuario añade al carrito, hace checkout, paga.
  4. Tras el pago, un módulo custom o ECA genera el registro de asistencia y dispara la confirmación.

Suena más complicado de lo que es. Lo complicado, en realidad, llega cuando el cliente te dice tres semanas después «¿podemos hacer un código de descuento solo para socios del Colegio Oficial?». Por eso Commerce: porque sí, puedes.

Del formulario al certificado: el flujo entero

Visitante ve el evento
        │
        ▼
Selecciona tipo de entrada
        │
        ▼
Añade al carrito (Commerce)
        │
        ▼
Checkout: datos personales + facturación
        │
        ▼
Pago (Stripe / Redsys)
        │
        ▼
Confirmación automática (email + PDF entrada)
        │
        ▼
Recordatorio previo al evento (24-48h antes)
        │
        ▼
Registro de asistencia (check-in con QR o manual)
        │
        ▼
Envío de certificado (PDF generado automáticamente)
        │
        ▼
Email post-evento (encuesta + materiales)

Cada caja de ese diagrama existe ya como módulo. No estás escribiendo un sistema desde cero, estás cableando piezas.

Pagos: la parte que más te despierta de noche

En España, dos pasarelas. Stripe, porque su API es la única que un humano puede leer sin volverse loco. Redsys, porque es la de tu banco y, cuando hablas con un cliente del sector salud o del legal, te van a pedir Redsys aunque no sepan exactamente por qué.

Stripe en Drupal Commerce

Commerce Stripe (1.x para Drupal 10) se integra dentro del checkout estándar. Lo que necesitas saber:

  • Tarjetas Visa, Mastercard, Amex.
  • Stripe Elements: el formulario va embebido pero los datos de tarjeta no tocan tu servidor. PCI DSS resuelto sin sufrir.
  • Stripe Payment Intents (la API actual, obligatoria desde 2022 para SCA/PSD2 en Europa).
  • Apple Pay y Google Pay con Stripe Payment Request Button. Esto, en eventos con público joven, sube conversión de forma evidente.
  • Webhooks para pagos asíncronos y devoluciones.

Comisión Stripe en España (2025): 1,5% + 0,25 EUR por transacción para tarjetas europeas.

Redsys en Drupal Commerce

Commerce Redsys (3.x, mantenido por la comunidad española de Drupal, gracias eternas a quien lo cuida) habla con el TPV Virtual del banco. Detalles:

  • Necesitas contrato con el banco (alta del TPV). Esto suele tardar más de lo que el cliente espera, hazlo en la semana uno.
  • SHA-256 obligatorio desde 2023.
  • El usuario sale al entorno del banco para meter la tarjeta y vuelve.
  • Notificación asíncrona: el banco llama a una URL tuya tras el pago. Si la URL falla, el pedido se queda en limbo. Monitorízala.
  • Bizum sí, si el banco lo habilita en el TPV. En un congreso médico con asistentes de cierta edad, Bizum cierra ventas.

Comisión Redsys: depende del contrato con el banco, normalmente entre 0,4% y 1,2%. Para volumen alto sale mejor que Stripe.

Comparativa rápida

Característica Stripe Redsys
Integración técnica API REST moderna, documentación excelente API SOAP/REST legacy, documentación mejorable
Tiempo de integración 4-8 horas 8-16 horas
Comisión por transacción (España) 1,5% + 0,25 EUR 0,4%-1,2% (según banco)
Bizum No nativo Sí (según banco)
Apple Pay / Google Pay Sí Según configuración del banco
Devoluciones desde panel Sí (API + Dashboard) Sí (panel del banco)
PSD2/SCA Automático Automático (desde 2023)
Módulo Drupal estable Sí (Commerce Stripe) Sí (Commerce Redsys)

Regla mental rápida: público español masivo y más de 500 inscripciones de pago, Redsys. Público internacional o equipo técnico que valora vida tranquila, Stripe. En la práctica, muchos proyectos acaban con ambas activadas y dejas que el usuario elija.

Certificados en PDF sin que nadie los firme a mano

Llega siempre la misma llamada el día después del evento: «¿podemos sacar ya los certificados?». Si no lo automatizaste, son tres días de un becario pegando PDFs. Si lo automatizaste, son cinco minutos.

Lo que usas para generar el PDF

  1. Entity Print (2.x): genera PDFs a partir de cualquier entidad (nodo, usuario, registro de Commerce) con una plantilla Twig.
  2. Motor de PDF:
    • Dompdf (PHP puro, fácil, pero llora con CSS complejo).
    • wkhtmltopdf (binario, render con WebKit, mucho mejor con CSS).
    • Chrome Headless / Puppeteer (la mejor fidelidad visual, requiere Node.js en el servidor).
  3. Plantilla Twig que tú diseñas como HTML/CSS y Entity Print convierte a PDF.

Para certificados con firma escaneada, logos en alta resolución y dos cajas a derecha e izquierda, wkhtmltopdf es el punto dulce. Dompdf es para algo más sobrio.

La plantilla, en concreto

<div class="certificado">
  <img src="/themes/custom/evento_theme/images/logo-evento.png" alt="Logo" />
  <h1>Certificado de Asistencia</h1>
  <p>Se certifica que <strong>{{ nombre_asistente }}</strong>,
  con DNI/NIE {{ documento_identidad }}, ha participado en el evento
  <em>{{ titulo_evento }}</em>, celebrado en {{ sede_evento }}
  los días {{ fecha_inicio }} a {{ fecha_fin }}, con una duración
  total de {{ horas_totales }} horas.</p>
  <div class="firma">
    <img src="/themes/custom/evento_theme/images/firma-director.png" alt="Firma" />
    <p>{{ nombre_director }}<br/>{{ cargo_director }}</p>
  </div>
  <div class="codigo-verificacion">
    Código de verificación: {{ codigo_verificacion }}
  </div>
</div>

Ese código de verificación (un hash único por certificado) es la diferencia entre «aquí tienes tu diploma» y «aquí tienes un diploma que cualquier RRHH puede comprobar entrando a una URL pública». Lo resuelves con un módulo custom de menos de 100 líneas. No es trabajo de un mes, es de una mañana.

Cuándo se dispara

Dos condiciones, y las dos importan:

  1. El evento ya terminó (fecha de fin pasada).
  2. El asistente fue marcado «presente» en el check-in.

La segunda es la que evita el certificado-fantasma. Si emites diploma a todo el que se inscribió, el día que un colegio profesional pida explicaciones por horas no asistidas, te toca a ti dar la cara.

Esto se orquesta con ECA (Event-Condition-Action), el sustituto moderno de Rules en Drupal 10/11. La regla queda como:

  • Evento: el campo «check-in» del registro pasa a «Presente».
  • Condición: la fecha actual es posterior a la fecha de fin del evento.
  • Acción: generar el PDF con Entity Print y enviarlo por email al asistente.

Email marketing: los datos del evento valen más que la entrada

La lista de asistentes a una conferencia bien hecha es, en marketing, oro. Hay que integrarla con tu plataforma de email desde el primer día.

Mailchimp

El módulo Mailchimp para Drupal (2.x para 10/11) hace:

  • Sincronización de suscriptores desde Webform o Commerce.
  • Tags y segmentos automáticos según el evento (asistentes a track de IA, asistentes VIP, etc.).
  • Merge fields mapeados a campos del usuario.
  • Double opt-in configurable, que en España vas a necesitar si esos datos los usas para marketing posterior (RGPD).

Mailchimp: gratis hasta 500 contactos (desde 2023); plan Standard desde 13,99 EUR/mes con automatizaciones.

Brevo (antes Sendinblue)

Brevo es la alternativa europea. Servidores en Francia. Cobran por emails enviados, no por contactos, así que para una asociación con 30.000 socios a los que escribes una vez al mes, las cuentas cambian.

El módulo Sendinblue para Drupal (2.x, parcialmente renombrado a Brevo en lo último) permite:

  • Sincronización vía API v3.
  • Transaccionales (confirmaciones, certificados) por Brevo SMTP, con mucha mejor entregabilidad que el sendmail del servidor.
  • Automatizaciones disparadas desde webhooks de Drupal.

Brevo: gratis hasta 300 emails/día; Starter desde 7 EUR/mes para 5.000 emails/mes (contactos ilimitados).

Comparativa

Característica Mailchimp Brevo (Sendinblue)
Modelo de precios Por contactos Por emails enviados
Servidores en UE No (EE.UU.) Sí (Francia)
SMTP transaccional Sí (Mandrill, add-on de pago) Sí (incluido en el plan)
Módulo Drupal mantenido Sí Sí (comunidad más reducida)
Automatizaciones Avanzadas Avanzadas
Coste para 5.000 contactos / 10.000 emails/mes ~59 EUR/mes ~15 EUR/mes
Cumplimiento RGPD Requiere cláusulas contractuales estándar (transferencia EE.UU.) Nativo (datos en UE)

Para clientes españoles con DPO (delegado de protección de datos) propio, la conversación sobre transferencia a EE.UU. es larga y suele acabar en Brevo. Si quieres una segunda opinión para tu caso concreto, en Tangram Consulting valoramos la integración contigo.

Check-in con QR: cómo evitar la cola en la puerta

El primer evento al que llegas a las ocho de la mañana y ves la cola dando la vuelta al edificio porque alguien está cruzando nombres en un Excel impreso, no se te olvida. La buena noticia: el check-in digital lo resuelve Drupal con menos de lo que crees.

  1. Generación del QR: al confirmar la inscripción, se crea un código QR único. Lo haces con QR Code Field o con la librería PHP endroid/qr-code desde un módulo custom. El QR no es la entrada; es un token vinculado al registro del asistente.

  2. App de escaneo: el equipo de acreditación usa tablet o móvil. La cámara escanea, manda al endpoint de Drupal (un controlador custom o REST API) y este:

    • Valida que el token existe y no se ha usado todavía.
    • Marca al asistente como «Presente».
    • Devuelve por pantalla nombre, empresa y tipo de entrada (importante para que el de acreditación entregue la bolsa que toca).
    • Registra hora de entrada.

  3. Dashboard en directo: una View con AJAX cada 30 segundos muestra a la organización el contador en tiempo real: inscritos, presentes, porcentaje de ocupación, últimos check-ins. Es la pantalla que ponen detrás del mostrador para que el director general vea cómo va llenándose.

Todo eso son módulos estándar más un módulo custom de menos de 300 líneas para el endpoint de validación. Lo equivalente en herramientas SaaS de acreditación cobra entre 0,50 y 2 EUR por asistente escaneado. Multiplica por 1.500 asistentes y sale solo el desarrollo.

SEO y schema.org: que Google entienda que es un evento

Google muestra rich snippets para eventos con su schema.org/Event bien puesto. Con Schema.org Metatag (3.x para Drupal 10/11) marcas cada nodo y listo.

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "Drupal Summit Madrid 2026",
  "startDate": "2026-10-15T09:00:00+02:00",
  "endDate": "2026-10-16T18:00:00+02:00",
  "location": {
    "@type": "Place",
    "name": "Palacio de Congresos de Madrid",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "Paseo de la Castellana, 99",
      "addressLocality": "Madrid",
      "postalCode": "28046",
      "addressCountry": "ES"
    }
  },
  "offers": {
    "@type": "Offer",
    "price": "149.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "validFrom": "2026-06-01"
  },
  "organizer": {
    "@type": "Organization",
    "name": "Tangram Consulting"
  },
  "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
  "eventStatus": "https://schema.org/EventScheduled",
  "image": "https://ejemplo.es/sites/default/files/drupal-summit-2026.jpg",
  "description": "Dos días de conferencias técnicas sobre Drupal 11."
}

Con esto, Google enseña fecha, lugar, precio y disponibilidad directamente en resultados. El CTR sube entre un 20% y un 35% según mediciones de Search Engine Journal (2024). En un evento con público generalista que llega por búsqueda, ese delta paga la consultoría.

Rendimiento: el día D no es un día normal

Vuelvo al principio. El día que abres inscripciones, el servidor se entera. Los picos de tráfico de eventos son predecibles, lo que es una suerte: cuando se publica el programa, cuando se abre la inscripción, cuando arranca el early bird. Pueden multiplicar por 10 o por 20 el tráfico medio del sitio. Hay que ir preparados.

Lo que pones para aguantar

  • Caché de página completa: Varnish o Fastly delante. Las páginas de programa, ponentes y sede son estáticas casi por definición, cacheas con TTL de 5-10 minutos y los hilos PHP respiran.
  • Caché parcial con BigPipe: el formulario de inscripción no se cachea, pero la página que lo contiene sí. BigPipe (core de Drupal) sirve lo cacheable y carga el formulario después.
  • Cola de procesamiento: a partir de 500 inscripciones simultáneas previstas, mueve confirmaciones y generación de PDFs a AdvancedQueue o Queue UI. Si lo dejas síncrono en el checkout, el día clave los tiempos de respuesta se disparan y empiezan los abandonos.
  • Réplicas de lectura: para eventos con más de 10.000 inscripciones, separa la BD de Commerce (escritura) de la de contenido (lectura). Drupal lo soporta nativamente.

Números reales

Datos de un congreso técnico (hipotético, pero muy parecido a uno que tuve entre manos) con 3.200 inscripciones y 45 sesiones, sobre Drupal 10 + Varnish + MySQL 8.0 en servidor dedicado de 4 vCPU y 8 GB de RAM:

Métrica Valor
Tiempo de carga de página del evento (con caché) 180 ms
Tiempo de procesamiento de inscripción completa (con pago Stripe) 2.800 ms
Pico de inscripciones simultáneas soportado 120/minuto
Emails de confirmación enviados sin cola (síncrono) 8/segundo
Emails de confirmación con AdvancedQueue (asíncrono) 45/segundo

La diferencia entre 8 y 45 emails por segundo es la diferencia entre que el asistente número 600 reciba su confirmación inmediata o veinte minutos tarde con cinco recordatorios pidiéndola por Twitter.

Cómo se planifica esto sin morir en el intento

No construyas todo el primer mes. He visto proyectos hundirse por intentarlo. El orden que funciona:

Fase 1 (2-3 semanas): tipos de contenido, taxonomías, Views de listado, calendario con FullCalendar. Formulario de inscripción básico con Webform. Confirmación por email. Aquí ya tienes algo en producción.

Fase 2 (2-3 semanas): pagos con Commerce + Stripe o Redsys. Tipos de entrada como variaciones de producto. Checkout adaptado.

Fase 3 (1-2 semanas): certificados con Entity Print. Check-in con QR. Dashboard en tiempo real.

Fase 4 (1-2 semanas): Mailchimp o Brevo. Automatizaciones pre y post evento. Schema.org.

Asumiendo 1 o 2 desarrolladores Drupal senior, el coste de implementación completo (diseño del tema e infraestructura incluidos) sale habitualmente entre 15.000 y 35.000 EUR para una primera versión funcional, con mantenimiento anual de 3.000 a 6.000 EUR.

¿Para un evento puntual de 50 asistentes? Drupal es matar moscas a cañonazos, te lo digo yo. Abre Eventbrite, paga la comisión y a otra cosa. ¿Para una asociación, fundación, colegio profesional o empresa que celebra tres o más eventos al año, que necesita los datos en su CRM, que quiere su marca controlada y que se cansa de pelearse con la pantalla de plantillas de cada plataforma SaaS? Drupal para webs de eventos, conferencias y gestión de inscripciones online es la jugada que paga, y a partir del tercer evento ya estás amortizando.

¿Tienes un proyecto en mente?

Agendar consultoría gratuita