Estructuras de contenido que reflejan la organización
Modelamos la información como la entiende el equipo: qué tipos de contenido existen, cómo se relacionan entre sí y cómo se clasifican.
tipos de contenidoreferenciastaxonomíascampos
El punto de partida
Cuando una web deja de ser solo un conjunto de páginas
No es una cuestión de tamaño, sino de estructura: cuánta información distinta convive, cuántas personas la tocan y con cuántos sistemas tiene que hablar.
- El contenido tiene distintos tipos y relaciones entre sí tipos de contenido · referencias
- Diferentes equipos necesitan permisos distintos roles · permisos por operación
- El contenido pasa por revisión antes de publicarse estados editoriales · workflow
- La plataforma debe conectarse con sistemas externos APIs · servicios · sincronización
- La web tiene que seguir siendo gobernable a medida que crece modelo estable · configuración
- Hay un Drupal existente que necesita evolucionar revisión · refactor · nuevas piezas
Criterio técnico
Drupal encaja muy bien en algunos proyectos. En otros, sería añadir complejidad sin necesidad.
Elegir plataforma no es elegir la más potente, sino la que sostiene el proyecto sin sobrecargarlo. Estas son las señales que miramos antes de proponer Drupal; si la decisión está entre ambos CMS, explicamos cómo elegir entre Drupal y WordPress según las necesidades del proyecto.
Encaja bien
Cuando Drupal aporta
-
El contenido tiene estructura propia y relaciones entre sus piezas
-
Hacen falta roles y permisos detallados, no solo «editor» y «administrador»
-
La publicación necesita revisión y control editorial
-
Hay complejidad corporativa o institucional detrás del proyecto
-
Las integraciones forman parte de la plataforma, no son un añadido
-
Es una plataforma de contenido pensada para durar y crecer con orden
Sería excesivo
Cuando conviene otra opción
-
Una web corporativa sencilla → Desarrollo WordPress
-
Un site de marketing directo, con pocas plantillas y contenido plano → Desarrollo WordPress
-
Un catálogo de ecommerce sencillo → Tiendas online
-
Un proyecto que, en realidad, es una aplicación más que un gestor de contenidos → Desarrollo web a medida
Si el proyecto encaja mejor en otra opción, lo decimos antes de empezar. Drupal no es nuestra respuesta por defecto.
Qué hacemos con Drupal
Qué podemos construir o hacer evolucionar sobre Drupal
Seis áreas de trabajo que cubren lo que suele necesitar un proyecto Drupal real. Ningún proyecto necesita todas.
Roles y control editorial
Quién puede crear, revisar, publicar o solo consultar, y por qué pasos pasa un contenido antes de estar visible.
usuariospermisosworkflowsestados
Funcionalidad a medida
Lo que el proyecto necesita y no existe tal cual: procesos propios, formularios con lógica, cálculos o paneles internos. Antes de desarrollar revisamos si un módulo mantenido ya lo resuelve bien.
módulos mantenidosmódulo propiológica aislada
Implementación del diseño
Llevamos a Drupal un diseño ya aprobado —vuestro o de vuestra agencia— sin forzarlo a encajar en una plantilla genérica.
tema propioplantillascomponentes
Integraciones con el resto de sistemas
Conexiones con los sistemas donde ya vive la información de la organización, definidas antes de implementarse.
APIsservicios externossistemas internos
Proyectos Drupal ya existentes
Evolución, refactor y nuevas funcionalidades sobre plataformas que ya están en producción y no se pueden parar.
revisión previadependenciasnuevas funcionalidades
Criterio de desarrollo
Usar Drupal primero. Código propio solo donde hace falta.
Drupal ya resuelve de serie una parte importante de lo que suele pedir un proyecto de contenido. El ecosistema de módulos mantenidos cubre otra buena parte. El desarrollo propio empieza donde terminan los dos.
Cada capa que se añade hacia fuera aumenta el coste de mantener el proyecto. Por eso trabajamos de dentro hacia fuera, no al contrario.
Principio
No desarrollamos un módulo propio si Drupal o un módulo mantenido ya resuelve correctamente la necesidad.
lógica a medida
Solo lo que no existe o no encaja bien: un módulo propio, aislado del núcleo, documentado y con un límite claro de responsabilidad.
módulos mantenidos
Ecosistema contrib con soporte real y actualizaciones. Se configura y se integra; no se reescribe lo que ya funciona.
núcleo · configuración
Lo que Drupal ya sabe hacer bien, resuelto configurando en lugar de programando.
tipos de contenido campos vistas taxonomías permisos workflows
- menos coste de mantenimiento
- actualizaciones más previsibles
- menos dependencia de quien lo desarrolló
Conexiones
Cuando Drupal no trabaja solo
En muchos proyectos la web no es la única fuente de información. Antes de conectar nada, dejamos claras tres cosas: sin eso, una integración se convierte en un problema silencioso.
Qué información viaja
Qué datos concretos entran y salen, con qué frecuencia y en qué formato. No «conectar los sistemas», sino qué se mueve exactamente.
Quién es el dueño del dato
Qué sistema manda cuando hay diferencias: si el dato se edita en Drupal, en el otro sistema, o en ambos con reglas claras.
Qué pasa si la conexión falla
Qué ve el usuario, qué se reintenta, qué queda registrado y quién se entera. Una integración también tiene que fallar de forma controlada.
Con qué se suele conectar
- Sistemas internos
- CRM
- APIs de terceros
- Contenido o datos externos
- Identidad y acceso corporativo
- Servicios que ya usa la organización
Punto de partida
Si Drupal ya existe, primero entendemos lo que hay
Una plataforma en marcha lleva dentro decisiones que no están documentadas. Cambiarla sin entenderla es la forma más rápida de romper algo que funcionaba.
Hay un Drupal en marcha
plataforma existente-
Revisamos la estructura actual y el modelo de contenido real, no el previsto.
-
Identificamos módulos propios, dependencias e integraciones activas.
-
Vemos cómo están planteados usuarios, roles y permisos.
-
Marcamos qué funciona bien y conviene conservar tal cual.
-
Solo entonces proponemos cambios, y explicamos qué implica cada uno.
Es un proyecto nuevo
desde cero-
Definimos la arquitectura de contenidos antes de tocar el diseño.
-
Concretamos necesidades editoriales: quién edita, quién revisa, quién publica.
-
Acotamos funcionalidad propia e integraciones necesarias.
-
Implementamos sobre una base que el equipo pueda mantener después.
Base técnica
Drupal se apoya en Symfony, lo que permite mantener la lógica propia aislada del núcleo y del ecosistema de módulos: se entiende qué hace cada pieza y se puede sustituir sin arrastrar el resto.
Trabajamos con conciencia de dependencias y, cuando el proyecto lo justifica, en entornos controlados con Docker, pruebas y despliegue automatizado. No todos los proyectos necesitan el mismo tooling, y decirlo también forma parte del trabajo.
Experiencia Drupal
Drupal en proyectos con requisitos exigentes
Tenemos experiencia desarrollando soluciones Drupal a medida cuando el proyecto requiere algo más que una implementación estándar. Hemos trabajado con necesidades como gestión avanzada de usuarios y roles, funcionalidades propias, procesamiento de contenido multimedia e integración con servicios externos, también en entornos institucionales.
Drupal Symfony Docker CI/CD
Requisitos que hemos cubierto
- Gestión avanzada de usuarios, roles y permisos
- Módulos y funcionalidades propias
- Procesamiento de contenido multimedia
- Integración con servicios externos y APIs
- Interfaces internas y dashboards a medida
Cómo trabajamos
Revisión técnica conjunta: decisiones de arquitectura, modelado de contenido y alcance se discuten antes de escribir código.
Si el proyecto Drupal viene de una agencia
Si vuestra agencia necesita apoyo especializado en Drupal, podemos asumir la capa técnica del proyecto y trabajar en segundo plano cuando sea necesario.
Servicios relacionados
Dónde encaja este servicio
/ desarrollo-web-a-medida
Desarrollo web a medida
El servicio del que parte esta página, cuando el proyecto necesita una base propia.
/ desarrollo-wordpress
Desarrollo WordPress
La alternativa razonable cuando Drupal añadiría complejidad sin necesidad.
/ integraciones-tecnicas
Integraciones técnicas
Cuando la plataforma tiene que intercambiar información con otros sistemas.
/ apis-y-servicios-web
APIs y servicios web
Cuando hay que exponer o consumir servicios más allá del propio CMS.
Preguntas frecuentes
Dudas habituales sobre proyectos Drupal
Cuando el peso del proyecto está en la estructura del contenido y en cómo se gestiona: varios tipos de contenido relacionados entre sí, equipos con permisos distintos, revisión antes de publicar e integraciones que forman parte de la plataforma. Si la web es un site corporativo o de marketing con necesidades más directas, normalmente encaja mejor WordPress, y lo decimos así.
Sí. Empezamos entendiendo lo que hay: modelo de contenido, módulos propios, dependencias, integraciones activas y cómo están planteados usuarios y permisos. A partir de ahí conservamos lo que funciona y proponemos cambios solo donde aportan algo concreto.
Sí, cuando hace falta. Primero revisamos si la necesidad se resuelve configurando Drupal o con un módulo mantenido del ecosistema. Si no encaja, desarrollamos un módulo propio, aislado y documentado, para que el mantenimiento posterior siga siendo razonable.
Sí. Trabajamos con diseños ya aprobados —vuestros o de vuestra agencia— y los implementamos como tema y componentes de Drupal, en lugar de adaptar el diseño a lo que permita una plantilla existente.
Sí. Antes de conectar nada definimos qué información viaja, quién es el dueño del dato y qué debe pasar si la conexión falla. Después implementamos la integración con APIs, servicios externos o sistemas internos, según el caso.
Siguiente paso
Cuéntanos qué necesita hacer tu proyecto Drupal
Revisamos la plataforma actual, la estructura de contenidos, los roles y permisos, la funcionalidad necesaria, las integraciones y qué parte tiene que evolucionar. Después proponemos, no antes.
Hablar sobre mi proyecto Drupal
Sin compromiso · Respuesta en 24–48 h laborables