Drupal Paragraphs Tutorial, Teil 2: Varianten, Responsive Design, Abstände und Admin-UX
Dies ist der zweite und abschließende Teil einer zweiteiligen Anleitung zum Aufbau einer komponentenbasierten Unternehmenswebsite mit Drupal Paragraphs. Am Ende der Serie haben Sie eine Bibliothek aus 10-12 universellen Paragraph-Typen mit Stilvarianten, responsiven Layouts und redakteursfreundlichen Abstandssteuerungen.
Dieses Drupal Paragraphs Tutorial, Teil 2, verwandelt die schlichten Komponenten aus Teil 1 in eine flexible, produktionsreife Bibliothek. In Teil 1 haben Sie eine wiederverwendbare Komponentenbibliothek geplant, das Paragraphs-Fundament eingerichtet und drei Kerntypen gebaut: Hero, Text + Bild und Feature Grid. Sie funktionieren - sind aber starr: ein Look, ein Layout. Hier ergänzen Sie alles, was eine Komponentenbibliothek flexibel macht und jahrelang wartbar hält: Farb- und Stilvarianten, dediziertes Responsive Design, redaktionell steuerbare Abstände, bedingte Felder, eine ausgereifte Admin-UX sowie ein Konzept für Performance und Weiterentwicklung. Anschließend wenden Sie die Muster auf den Rest der Bibliothek an.
Dies setzt weiterhin Drupal 10 oder 11 und das Setup aus Teil 1 voraus. Wenn Ihre aktuelle Paragraphs-Konfiguration Redakteure frustriert, erklärt unser Beitrag Drupal Paragraphs: von unbrauchbar zu redakteursfreundlich, was eine defekte Implementierung von einer trennt, die in der Produktion funktioniert.
In diesem Artikel:
- Was haben Sie in Teil 1 gebaut?
- Wie implementieren Sie Farb- und Stilvarianten?
- Wie bauen Sie responsive Layouts für jeden Paragraph?
- Wie fügen Sie redaktionell steuerbare Abstände hinzu?
- Wie nutzen Sie bedingte Felder und smarte Standardwerte?
- Wie bauen Sie die übrigen Paragraph-Typen?
- Wie verbessern Sie Redakteursteuerungen und Admin-UX?
- Welche Performance-Aspekte sind bei paragraph-basierten Seiten wichtig?
- Wie pflegen und weiterentwickeln Sie die Komponentenbibliothek?
Was haben Sie in Teil 1 gebaut?
In Teil 1 dieses Drupal Paragraphs Tutorials haben Sie einen Planungsansatz etabliert (Seiten auditieren, wiederverwendbare Muster finden, ein Minimum Viable Set bauen), Paragraphs installiert, ein Paragraphs-Referenzfeld zu einem Content Type hinzugefügt und eine Feldnamenskonvention übernommen, damit jeder Typ konsistent bleibt. Dann haben Sie Hero, Text + Bild und Feature Grid mit ihren Twig-Templates und Basis-CSS gebaut.
Jetzt machen Sie diese Komponenten vielseitig.
Wie implementieren Sie Farb- und Stilvarianten?
Eine Stilvariante lässt eine einzelne Komponente in mehreren visuellen Präsentationen rendern - hell, dunkel, Brand, neutral - ausgewählt vom Redakteur per Dropdown. Das ist ein kostengünstiges Feature, das die wahrgenommene Flexibilität stark erhöht, weil derselbe Paragraph je nach Kontext völlig anders wirken kann, ohne dass jemand Code anfasst.
Der Mechanismus ist ein Select-Feld, das auf eine CSS-Klasse gemappt wird. Fügen Sie jedem Paragraph-Typ ein Listenfeld field_style mit diesen Optionen hinzu:
light|Light
dark|Dark
brand|Brand
neutral|NeutralLesen Sie den Wert im Template und wenden Sie ihn als Modifier-Klasse auf den Wrapper an:
{% set style = content.field_style['#items'].value|default('light') %}
<section{{ attributes.addClass('paragraph', 'paragraph--hero', 'paragraph--style-' ~ style) }}>
{# ... component markup ... #}
</section>Strukturieren Sie das CSS als Basis-Styles plus Varianten-Overrides, mit der Palette einmal als Custom Properties definiert:
:root {
--color-light-bg: #ffffff;
--color-light-fg: #1a1a1a;
--color-dark-bg: #11151c;
--color-dark-fg: #ffffff;
--color-brand-bg: #0057ff;
--color-brand-fg: #ffffff;
--color-neutral-bg: #f4f5f7;
--color-neutral-fg: #1a1a1a;
}
.paragraph--style-light { background: var(--color-light-bg); color: var(--color-light-fg); }
.paragraph--style-dark { background: var(--color-dark-bg); color: var(--color-dark-fg); }
.paragraph--style-brand { background: var(--color-brand-bg); color: var(--color-brand-fg); }
.paragraph--style-neutral { background: var(--color-neutral-bg); color: var(--color-neutral-fg); }Weil jede Variante dieselben Custom Properties liest, wird ein Rebrand zu einer Handvoll Wertänderungen statt zu einem Durchlauf durch jede Komponente.
Bei einer Bibliothek mit zehn-plus Typen ist field_style auf jedem zu wiederholen mühsam und fehleranfällig. Die skalierbare Alternative ist ein Paragraphs Behavior Plugin, das die Stileinstellung und ihre Rendering-Logik vielen Typen auf einmal hinzufügt:
<?php
namespace Drupal\my_module\Plugin\paragraphs\Behavior;
use Drupal\paragraphs\Entity\Paragraph;
use Drupal\paragraphs\ParagraphsBehaviorBase;
use Drupal\Core\Form\FormStateInterface;
/**
* @ParagraphsBehavior(
* id = "style_variant",
* label = @Translation("Style variant"),
* description = @Translation("Adds a color/style variant selector."),
* weight = 0,
* )
*/
class StyleVariantBehavior extends ParagraphsBehaviorBase {
public function buildBehaviorForm(Paragraph $paragraph, array &$form, FormStateInterface $form_state) {
$form['style'] = [
'#type' => 'select',
'#title' => $this->t('Style'),
'#options' => [
'light' => $this->t('Light'),
'dark' => $this->t('Dark'),
'brand' => $this->t('Brand'),
'neutral' => $this->t('Neutral'),
],
'#default_value' => $paragraph->getBehaviorSetting($this->getPluginId(), 'style', 'light'),
];
return $form;
}
public function preprocess(&$variables) {
$paragraph = $variables['paragraph'];
$style = $paragraph->getBehaviorSetting($this->getPluginId(), 'style', 'light');
$variables['attributes']['class'][] = 'paragraph--style-' . $style;
}
}Aktivieren Sie das Behavior auf allen Paragraph-Typen, die Varianten anbieten sollen - der Selector erscheint dann konsistent überall. Diesen Ansatz nutzen wir bei echten Komponentenbibliotheken, weil er übergreifende Einstellungen an einem Ort hält.
Lesen Sie auch: flexible und einfache Inhaltserstellung mit dem Drupal Paragraphs Modul und Paragraph View Mode - Modul-Review für Drupal.
Wie bauen Sie responsive Layouts für jeden Paragraph?
Responsive bedeutet nicht „dasselbe, nur kleiner“. Jeder Paragraph-Typ braucht sein eigenes Mobile-Layout, in dem Inhalte für kleine Screens neu organisiert und priorisiert werden - nicht nur herunterskaliert.
Arbeiten Sie mobile-first: schreiben Sie das einspaltige Mobile-Layout als Default und fügen Sie an größeren Breakpoints Komplexität hinzu. Am Beispiel der Text + Bild-Komponente aus Teil 1:
/* Mobile-first: gestapelt, Bild zuerst. */
.paragraph--text-image {
display: grid;
gap: 1.5rem;
grid-template-columns: 1fr;
}
/* Tablet und größer: zwei Spalten. */
@media (min-width: 48rem) {
.paragraph--text-image {
grid-template-columns: 1fr 1fr;
gap: 2rem;
align-items: center;
}
.paragraph--text-image--right .paragraph--text-image__media {
order: 2;
}
}Nutzen Sie eine konsistente Breakpoint-Strategie über die ganze Bibliothek - zum Beispiel Mobile-Basis, Tablet-Breakpoint um 48rem und Desktop um 64rem - damit Komponenten vorhersehbar zusammenarbeiten.
Achten Sie besonders auf Bilder. Nutzen Sie Drupals responsive Image Styles, damit jeder Breakpoint eine passend große Datei lädt, und erwägen Sie Art Direction (anderer Crop auf Mobile) für Hero-Bilder. Das zahlt sich vor allem aus, wenn Sie bildbasierte Inhalte durch strukturierte Paragraphs ersetzen: richtig responsive Komponenten liefern sofort bessere Mobile Experience, Page Speed und SEO. Testen Sie auf echten Geräten und an jedem Breakpoint - nicht nur durch Verengen des Browserfensters.
Wie fügen Sie redaktionell steuerbare Abstände hinzu?
Abstände sind das Problem, auf das jedes paragraph-basierte System früher oder später stößt: zwei Sektionen mit gleichem Hintergrund stapeln sich zu einer riesigen Lücke, oder ein Paragraph ohne Titel hinterlässt ein leeres Band. Die Lösung: Redakteuren Margin und Padding pro Paragraph steuern lassen, weil Abstände kontextabhängig sind und nur der Redakteur den Kontext kennt.
Dieser Abschnitt liefert eine funktionierende Implementierung für Ihren Tutorial-Build. Für die vollständige Diskussion, warum komponentenbasierte Layouts Abstandsprobleme entwickeln, die Trade-offs zwischen automatischen und manuellen Abständen und die Edge Cases, siehe unseren Deep Dive zu Drupal Paragraphs Abständen und Layout-Lücken.
Fügen Sie zwei Listenfelder hinzu - oder besser ein Spacing-Behavior - mit derselben Skala für jedes:
none|None
small|Small
medium|Medium
large|LargeBieten Sie zwei getrennte Steuerungen. Margin schiebt einen Paragraph von seinen Nachbarn weg; Padding regelt den Raum innen. Beides ist nötig, und die Trennung macht das System wirklich flexibel. Lesen Sie die Werte im Template als Modifier-Klassen:
{% set margin = content.field_margin['#items'].value|default('medium') %}
{% set padding = content.field_padding['#items'].value|default('medium') %}
{%
set spacing = [
'paragraph--margin-' ~ margin,
'paragraph--padding-' ~ padding,
]
%}
<section{{ attributes.addClass('paragraph', spacing) }}>
{# ... component markup ... #}
</section>Definieren Sie die Skala einmal mit Custom Properties, damit sie überall konsistent bleibt:
:root {
--space-s: 1.5rem;
--space-m: 3rem;
--space-l: 5rem;
}
.paragraph--margin-none { margin-block: 0; }
.paragraph--margin-small { margin-block: var(--space-s); }
.paragraph--margin-medium { margin-block: var(--space-m); }
.paragraph--margin-large { margin-block: var(--space-l); }
.paragraph--padding-none { padding-block: 0; }
.paragraph--padding-small { padding-block: var(--space-s); }
.paragraph--padding-medium { padding-block: var(--space-m); }
.paragraph--padding-large { padding-block: var(--space-l); }Testen Sie die Steuerungen gegen die Szenarien, die immer auftauchen: zwei weiße Paragraphs gestapelt (Redakteur setzt den oberen Margin des zweiten auf none), ein Paragraph ohne Titel (Padding eine Stufe reduzieren) und ein Full-Bleed-Bild (Padding null). Empfehlen Sie Redakteur-Steuerungen statt automatischer CSS-Regeln - automatische Abstände ändern Dinge, die Redakteure nicht sehen oder vorhersehen können, und Vorhersehbarkeit hält ihr Vertrauen ins System.
Wie nutzen Sie bedingte Felder und smarte Standardwerte?
Ein langes Formular mit allen Feldern auf einmal überfordert Redakteure. Bedingte Felder zeigen Optionen nur, wenn sie relevant sind - progressive disclosure senkt die kognitive Last.
Drupal Cores Form API unterstützt bedingte Sichtbarkeit über #states. Zeigen Sie zum Beispiel ein Feld „Custom background color“ nur, wenn der Stil auf eine Custom-Option steht:
function my_module_form_alter(&$form, $form_state, $form_id) {
if (isset($form['field_custom_bg'])) {
$form['field_custom_bg']['#states'] = [
'visible' => [
':input[name="field_style"]' => ['value' => 'custom'],
],
];
}
}Für Nicht-Entwickler, die das über die UI konfigurieren, liefert das Contrib-Modul Conditional Fields dasselbe Verhalten ohne Code. In beiden Fällen gilt: verstecken Sie, was noch nicht gebraucht wird.
Kombinieren Sie bedingte Felder mit smarten Standardwerten. Wählen Sie den häufigsten Stil und medium für Abstände vor, damit ein Paragraph direkt nach dem Hinzufügen gut aussieht. Die meisten Redakteure akzeptieren die Defaults meistens - genau das wollen Sie, der einfache Weg soll ein gutes Ergebnis liefern.
Wie bauen Sie die übrigen Paragraph-Typen?
Mit Varianten, Responsiveness und Abständen steht der Rest der Bibliothek als Wiederholung mit Absicht an. Wenden Sie dasselbe Rezept an - minimale Felder, eine Stilvariante, Abstandssteuerungen, ein Mobile-first-Layout - auf jeden übrigen Typ: CTA Block, Cards, Testimonial, FAQ und Stats.
Zwei kurze Beispiele.
CTA Block - field_heading, field_text, field_cta, plus das Style-Behavior:
<section{{ attributes.addClass('paragraph', 'paragraph--cta') }}>
<div class="paragraph--cta__inner">
{% if content.field_heading|render|trim %}
<h2>{{ content.field_heading }}</h2>
{% endif %}
{{ content.field_text }}
{{ content.field_cta }}
</div>
</section>Stats / Numbers - ein stats-Typ, der wiederholende stat_item-Paragraphs referenziert (field_value, field_label), als responsive Zeile gerendert:
.paragraph--stats__items {
display: grid;
gap: 1rem;
grid-template-columns: 1fr;
}
@media (min-width: 48rem) {
.paragraph--stats__items {
grid-template-columns: repeat(4, 1fr);
}
}Dokumentieren Sie jeden Typ beim Bauen - Zweck, Felder und Varianten. Ein kurzes Living Document der Komponentenbibliothek verhindert, dass zwei Entwickler leicht unterschiedliche Versionen desselben Typs bauen, und ist die Referenz, zu der Redakteure und Designer immer zurückkehren. Dasselbe Komponenten-Mindset, das die Planung in Teil 1 leitete, gilt hier: jeder Typ soll universell genug sein, um auf vielen Seiten zu kombinieren, nicht maßgeschneidert für ein Layout.
Wie verbessern Sie Redakteursteuerungen und Admin-UX?
Das Admin-Formular ist das CMS für Redakteure. Wenn es verwirrend ist, wirkt das ganze System verwirrend - behandeln Sie die Bearbeitungserfahrung als Deliverable, nicht als Nachgedanke.
Beginnen Sie mit den Grundlagen auf jedem Paragraph-Typ:
- Logische Feldreihenfolge. Die am häufigsten genutzten Felder zuerst: Überschrift, dann Bild, dann Text, dann Optionen wie Stil und Abstand. Konfigurieren Sie das unter „Manage form display“ des Typs.
- Hilfetext zu jedem Feld. Eine Zeile Beschreibung nimmt Rätselraten. Sagen Sie Redakteuren, wie „Brand“-Stil aussieht oder welches Bildverhältnis am besten passt.
- Smarte Standardwerte. Den häufigsten Stil und die Spaltenanzahl vorauswählen, damit Redakteure nur ändern, was nötig ist.
- Aussagekräftige Typnamen. „Hero-Sektion mit Bild“ liest sich im Hinzufügen-Menü besser als „hero_v2“.
Installieren Sie dann ein modernes Admin-Theme - Gin transformiert die Bearbeitungserfahrung in Minuten und ist eine der höchsten ROI-Änderungen auf jeder Drupal-Site:
composer require drupal/gin
drush theme:enable gin -y
drush config:set system.theme admin gin -yGin verbessert die Paragraphs-Bearbeitung selbst - klarere Hinzufügen-Buttons, besseres Drag-and-Drop und ein aufgeräumteres Formular - und unterstützt direkt den redakteursfreundlichen Ansatz, auf dem die ganze Bibliothek basiert. Vertiefen Sie mit ein paar fortgeschrittenen Details:
- Paragraph-Typ-Icons. Ein Icon pro Typ macht das Hinzufügen-Menü auf einen Blick scannbar.
- Verfügbare Typen pro Content Type begrenzen. In der Formularanzeige des Paragraphs-Felds einschränken, welche Typen Redakteure auf einem Content Type hinzufügen können - Landingpage und News-Artikel bieten dann nur relevante Komponenten.
- Klare Hinzufügen-Erfahrung. Modal- oder Dropdown-Add-Mode nutzen, damit Redakteure genau wissen, was sie einfügen. Für Power-User ermöglichen Module wie Geysir schnellere In-Place-Bearbeitung.
- Custom Admin-Styling. Etwas CSS auf die Paragraph-Formulare - verwandte Felder gruppieren, Abstände straffen - macht lange Formulare leichter scannbar.
Das Ziel ist eine Oberfläche, intuitiv genug, dass Redakteure ohne Schulung produktiv sind. Die beste Übergabe ist eine befüllte Beispielseite auf Staging, kein Handbuch.
Welche Performance-Aspekte sind bei paragraph-basierten Seiten wichtig?
Komponentenbasierte Seiten können medienlastig werden - bauen Sie Performance von Anfang an ein, statt sie später anzubolzen.
- Medien lazy-loaden. Offscreen-Bilder verzögern, damit der erste Render schnell bleibt. Modernes Drupal setzt
loading="lazy"auf Bildfelder - prüfen Sie das aber für in Paragraphs eingebettete Medien. - Effektiv cachen. Paragraph-basierte Seiten profitieren von Drupals Render Cache; stellen Sie sicher, dass Custom Templates und Behaviors korrekte Cache Tags und Contexts deklarieren, damit Seiten gecacht bleiben und sich bei Inhaltsänderungen trotzdem aktualisieren.
- Bilder pro Variante optimieren. Eine Sektion mit dunklem Hintergrund braucht vielleicht andere Bildbehandlung als eine helle - passend große, komprimierte Dateien über responsive Image Styles ausliefern.
- Messen. Lighthouse vorher und nachher laufen lassen, Largest Contentful Paint und Cumulative Layout Shift beobachten und Regressionen als Bugs behandeln.
Bildbasierte Inhalte durch strukturierte, responsive Paragraphs zu ersetzen ist selbst ein Performance-Gewinn - echtes HTML lädt schneller und reflowt sauber, wo eine schwere Grafik es nicht könnte.
Wie pflegen und weiterentwickeln Sie die Komponentenbibliothek?
Eine Komponentenbibliothek ist ein langfristiges Asset - designen Sie sie zum Wachsen. Ein gesundes System erkennt man daran, dass ein neuer Typ oder eine neue Variante nie eine Umstrukturierung der bestehenden erfordert.
Ein paar Praktiken halten sie wartbar:
- Typen hinzufügen, ohne andere zu brechen. Weil jeder Paragraph-Typ in sich geschlossen ist, fügen sich neue sauber ein. Widerstehen Sie Shared CSS, das Wellen über Komponenten schlägt - nutzen Sie stattdessen die Custom-Property-Skalen.
- Templates versionieren. Template- und Behavior-Änderungen in Code Review und Configuration Management halten, damit Änderungen bewusst und reversibel sind.
- Die Bibliothek dokumentieren. Eine lebende Referenz jedes Typs, seiner Felder und Varianten pflegen. Das stoppt zwei Entwickler davor, fast doppelte Komponenten zu bauen.
- Wissen, wann refactoren vs. hinzufügen. Ist eine neue Anforderung eine Variante eines bestehenden Typs, erweitern Sie ihn. Ist sie wirklich anders, fügen Sie einen neuen Typ hinzu. Vermeiden Sie beide Extreme: ein Friedhof einmaliger Typen und ein überladener Mega-Paragraph, der alles tun will.
Neue Typen nach echter Nachfrage statt Spekulation hinzufügen. Wenn Redakteure Komponenten nutzen, wie Sie es nicht geplant haben - eine Produktsektion für ein Event umfunktionieren - ist das das Signal, dass Ihre Architektur funktioniert, und ein Leitfaden, was als Nächstes zu bauen ist.
Möchten Sie eine komponentenbasierte Drupal-Website mit Paragraphs bauen?
Dieses Drupal Paragraphs Tutorial basiert auf Mustern aus produktiven Unternehmens-Neuaufbauten - eine geplante Bibliothek mit Stilvarianten, responsiven Layouts, redaktionell steuerbaren Abständen und Admin-UX erweitern, die Content-Teams ohne Schulung betreiben können. Über zwei Teile sind Sie von einer leeren Drupal-Installation zu einer produktionsreifen, komponentenbasierten Unternehmenswebsite gekommen: eine Bibliothek universeller Paragraph-Typen, denen Redakteure vertrauen, und eine Codebasis, die Entwickler jahrelang warten können.
Sie bauen eine komponentenbasierte Drupal-Website und wollen erfahrene Hände an der Architektur? Unser Team designt und baut täglich redakteursfreundliche Paragraphs-Systeme - von Twig-Templates und Behavior Plugins bis zu Abstandssteuerungen und langfristiger Wartung. Besuchen Sie unsere Drupal-Agentur, um zu sehen, wie wir helfen können.
