Cómo crear tipos de contenido y campos personalizados en Drupal sin escribir una línea de código

Hay una pregunta que hacemos siempre en la primera reunión de un proyecto Drupal, antes de hablar de diseño, de colores o de tecnología: ¿qué tipos de información va a manejar tu web? Noticias, eventos, fichas de producto, casos de éxito, miembros del equipo, recetas, propiedades inmobiliarias... La respuesta a esa pregunta es lo que en Drupal llamamos modelado de contenido, y, lo digo sin dramatismo, es la decisión más importante de todo el proyecto.

Lo bueno es que Drupal te deja construir ese modelo sin programar nada, desde la propia interfaz de administración, usando lo que se conoce como Field UI. En este artículo te explico cómo crear tipos de contenido y campos personalizados en Drupal 10/11 paso a paso, con criterio y con algún que otro tropiezo real de los que enseñan más que cualquier manual.

Qué es un tipo de contenido (y por qué el modelado lo decide todo)

Un tipo de contenido (en inglés content type, y técnicamente un bundle de la entidad node) es una plantilla que define qué piezas de información componen un determinado contenido. Si tienes un blog, tu tipo de contenido "Artículo" tendrá un título, un cuerpo, una imagen destacada, un autor y unas categorías. Si gestionas una agenda cultural, tu tipo "Evento" tendrá fecha de inicio, fecha de fin, lugar y precio.

Drupal viene de fábrica con dos tipos de contenido: Artículo y Página básica. Sirven para empezar, pero rara vez encajan al cien por cien con lo que necesita un proyecto serio. Por eso casi siempre acabas creando los tuyos propios.

Conviene entender por qué esto importa tanto. Cuando defines bien tus tipos de contenido y tus campos:

• El editor rellena formularios claros, con cada dato en su sitio, sin pelearse con un único campo de texto gigante donde mezclar todo.
• El diseño puede tratar cada dato de forma independiente: la fecha como una fecha, el precio como un número, la imagen como una imagen.
• La API (REST o JSON:API, que Drupal ya trae incorporada) expone cada campo de manera estructurada, lo que te abre la puerta a aplicaciones móviles, frontends desacoplados o integraciones con otros sistemas.

Y al revés: un mal modelado se paga. Lo hemos visto. Llegan proyectos donde alguien metió la fecha del evento dentro del cuerpo del texto, como una frase más. Cuando el cliente pidió "ordenar los eventos por fecha" o "mostrar solo los próximos", no había forma limpia de hacerlo sin migrar miles de nodos a mano. Planificar diez minutos al principio ahorra semanas al final.

Crear un tipo de contenido desde la interfaz

Vamos a la práctica. Para crear un tipo de contenido nuevo, entra como administrador y ve a Administración > Estructura > Tipos de contenido (la ruta es /admin/structure/types). Pulsa en Añadir tipo de contenido.

Te aparecerá un formulario con varias secciones. Las más relevantes:

• Nombre: el nombre humano, por ejemplo "Evento". A partir de él, Drupal genera automáticamente un nombre de máquina como evento. Ese nombre de máquina es el identificador interno y conviene dejarlo limpio y en singular.
• Descripción: un texto de ayuda que verán los editores al elegir qué crear. Parece menor, pero en una redacción con varias personas se agradece muchísimo.
• Ajustes del formulario de envío: aquí defines la etiqueta del campo título (por defecto "Título", pero puedes llamarlo "Nombre del evento" si queda más natural) y la ayuda que aparece bajo el formulario.
• Opciones de publicación: decides si el contenido se publica automáticamente, si aparece destacado en portada, o si se crea una nueva revisión cada vez que se edita. Para contenido editorial, activar las revisiones es casi siempre buena idea: te permite volver atrás si alguien la lía.
• Configuración de visualización: si quieres mostrar u ocultar el autor y la fecha de publicación.
• Configuración del menú: qué menús pueden enlazar directamente a este tipo de contenido.

Un detalle que casi nadie configura al principio y luego agradece: las rutas y alias. Por defecto, un nodo vive en una URL fea del tipo /node/123. Si instalas el módulo Pathauto (prácticamente obligatorio en cualquier proyecto), puedes definir patrones de alias automáticos, por ejemplo /eventos/[node:title], y Drupal generará URLs limpias y orientadas a SEO sin que el editor tenga que pensar en ello. Lo configuras en Configuración > Búsqueda y metadatos > Alias de URL > Patrones.

Guardas, y ya tienes tu tipo de contenido. De momento solo tiene el campo título. Ahora viene lo interesante: los campos.

Añadir campos personalizados con Field UI

Desde la lista de tipos de contenido, pulsa en Gestionar campos junto a tu tipo recién creado, y después en Añadir campo. Aquí es donde Drupal brilla, porque te ofrece un catálogo enorme de tipos de campo nativos que cubren la inmensa mayoría de necesidades sin instalar nada extra:

• Texto (sin formato): cadenas cortas como un nombre, un código o un subtítulo. Tiene un límite de caracteres.
• Texto (formateado, largo): el típico cuerpo de un artículo, con editor enriquecido (CKEditor) para poner negritas, listas, enlaces, etc.
• Número (entero, decimal, flotante): para precios, cantidades, valoraciones. Que sea un número de verdad te permite ordenar y filtrar por él.
• Fecha: con o sin hora, e incluso rangos de fecha si instalas el módulo correspondiente. Imprescindible para eventos.
• Booleano: un sí/no, una casilla. "¿Es gratuito?", "¿Destacado?".
• Correo electrónico y enlace: validan el formato automáticamente, así evitas que un editor escriba un email mal formado.
• Lista (texto o entero): un desplegable de opciones cerradas que tú defines. "Online / Presencial / Híbrido".
• Imagen, archivo y media: para subir ficheros. En Drupal moderno lo recomendable es usar el sistema Media, que gestiona una biblioteca reutilizable de imágenes, vídeos y documentos en lugar de subir el mismo archivo una y otra vez.
• Referencia a entidad: el campo más potente, del que hablo en detalle más abajo. Permite apuntar a otros nodos, a usuarios o a términos de taxonomía.

Al crear cada campo, Drupal te pide configurar tres cosas que merece la pena entender bien:

• Cardinalidad: cuántos valores admite el campo. Uno solo (un único precio), un número fijo (exactamente tres imágenes) o ilimitado (todas las etiquetas que quieras). Cambiar la cardinalidad de ilimitado a uno más tarde puede dar problemas si ya hay datos, así que piénsalo antes.
• Requerido u opcional: si el editor está obligado a rellenarlo para poder guardar.
• Valor por defecto: lo que aparece precargado. Útil, por ejemplo, para que el campo "País" venga ya con "España".

El nombre de máquina importa más de lo que parece

Cuando creas un campo, Drupal genera un nombre de máquina con el prefijo field_. Si llamas a tu campo "Fecha de inicio", te propondrá field_fecha_inicio. Tómate ese nombre en serio. Es lo que verás en plantillas, en la API JSON:API, en exportaciones de configuración y en cualquier desarrollo futuro.

Un consejo que damos siempre: nombra los campos pensando en su significado, no en su apariencia. Un campo field_fecha_inicio envejece bien; un campo field_texto_azul_derecha es una bomba de relojería en cuanto cambie el diseño. Nombres en singular, descriptivos y consistentes en todo el proyecto. Tu yo del futuro te lo agradecerá.

Formularios y visualización: dos caras de la misma moneda

Aquí hay un concepto que confunde a mucha gente al principio, así que vamos despacio. Un campo en Drupal tiene dos lados:

• Cómo se introduce el dato (el widget del formulario), que configuras en Gestionar campos / Gestionar formulario.
• Cómo se muestra el dato al visitante (el formateador), que configuras en Gestionar visualización.

Por ejemplo, un campo de lista puede introducirse como un desplegable, como botones de radio o como casillas, sin tocar nada del dato en sí: solo cambias el widget. Y un campo de fecha puede mostrarse como "9 de junio de 2026", como "09/06/26" o como "hace 3 días", solo cambiando el formateador. El dato guardado es el mismo; lo que cambia es la presentación.

En Gestionar visualización también te encontrarás con los modos de visualización. Los dos más habituales:

• Teaser (resumen): la versión corta que aparece en listados, con título, imagen y poco más.
• Completo (full): la ficha entera del contenido cuando entras en su página.

Para cada modo decides qué campos se muestran, en qué orden y con qué formateador. Así, en el listado de eventos enseñas solo título, fecha e imagen, y en la página completa muestras absolutamente todo. Puedes incluso crear modos de visualización propios para casos especiales, como un widget de "evento destacado" en portada.

Reutilizar campos entre tipos de contenido

Una de las gracias menos conocidas de Drupal: los campos se pueden reutilizar. Si ya tienes field_imagen_destacada en tu tipo "Artículo" y creas un tipo "Caso de éxito", al añadir un campo Drupal te ofrece reutilizar un campo existente. Si eliges el mismo, ambos tipos comparten la misma definición de campo (aunque cada uno puede tener su propia etiqueta y su propio "requerido/opcional").

Esto mantiene el modelo coherente y limpio. Pero ojo, también es fuente de un error clásico: crear campos duplicados. Acabas con field_imagen, field_imagen_principal y field_foto repartidos por el sitio haciendo casi lo mismo. Antes de crear un campo nuevo, comprueba siempre si ya existe uno equivalente. Un modelo con veinte campos bien pensados es infinitamente más mantenible que uno con sesenta improvisados.

Relacionar contenidos: referencias y taxonomía

Las webs reales no son islas de contenido aislado: las cosas se relacionan entre sí. Para eso están las referencias a entidad.

La taxonomía es el sistema de clasificación de Drupal. Creas un vocabulario (por ejemplo "Categorías" o "Temáticas"), defines sus términos, y luego añades a tu tipo de contenido un campo de referencia a término de taxonomía. Así clasificas artículos por tema, productos por familia o eventos por tipo, y puedes construir listados filtrados automáticamente.

Las referencias a otros nodos te permiten conectar contenidos: un "Caso de éxito" que referencia al "Servicio" relacionado, un "Evento" que referencia a su "Ponente" (que podría ser otro tipo de contenido "Persona"). Esto evita duplicar información: defines a cada ponente una sola vez y lo referencias desde todos los eventos en los que participe.

Para contenido más flexible y modular, Drupal cuenta con herramientas como Paragraphs (bloques reutilizables que el editor combina libremente) y Layout Builder (maquetación visual por arrastre). No me extiendo aquí porque los tratamos a fondo en otros artículos, pero quédate con la idea: cuando un tipo de contenido empieza a necesitar "secciones variables", esos son los caminos a explorar antes de llenarlo de campos sueltos.

Si en algún momento dudas sobre cómo estructurar todo esto para tu caso concreto, en Tangram lo vemos a diario y estaremos encantados de ayudarte: puedes contarnos tu proyecto sin compromiso y lo analizamos juntos.

Buenas prácticas de modelado (lo que de verdad marca la diferencia)

Después de muchos proyectos, estas son las pautas que repetimos una y otra vez:

• No lo metas todo en un solo tipo de contenido. Si te ves añadiendo campos del tipo "esto solo aplica si es noticia" y "esto solo si es evento", es señal de que necesitas tipos separados. Cada tipo, su propósito.
• Piensa en la reutilización desde el principio. Antes de crear, pregúntate si ese campo va a hacer falta en otros sitios y nómbralo en consecuencia.
• Diseña pensando en la API. Aunque hoy tu web sea un Drupal "clásico", un buen modelo estructurado vía JSON:API te deja la puerta abierta a un frontend desacoplado, una app o integraciones futuras sin rehacer nada.
• Exporta la configuración. Drupal guarda todo el modelo (tipos, campos, modos de visualización) como configuración exportable. Usa config sync (drush config:export o la interfaz en /admin/config/development/configuration) para versionar tu modelo en Git. Así pasas cambios de desarrollo a producción de forma controlada y no pierdes el trabajo si hay que reconstruir el entorno.

Y los errores típicos que conviene esquivar:

• Abusar del texto sin formato. Meter datos estructurados (fechas, precios, ubicaciones) como simple texto. Pierdes la capacidad de ordenar, filtrar y validar.
• Campos duplicados por no comprobar lo que ya existe.
• No planificar y acabar migrando datos a mano cuando el modelo se queda corto. Esto es lo más caro de todo y casi siempre evitable con una pizarra y media hora de conversación al inicio.

En resumen

Crear tipos de contenido y campos personalizados en Drupal 10/11 es, en lo mecánico, sencillo: la Field UI te lo da prácticamente todo sin escribir código. Lo difícil, y lo valioso, es modelar con criterio: nombrar bien, no duplicar, distinguir el formulario de la visualización, relacionar contenidos con referencias y exportar la configuración para no perderla.

Un modelo de contenido bien pensado es invisible cuando funciona y carísimo cuando falla. Si vas a empezar un proyecto en Drupal, dedícale a esta fase el tiempo que merece. Tu equipo editorial, tu desarrollador de plantillas y tu yo de dentro de dos años te lo agradecerán.