← SEGERT BLOG

Zwei starke ExpressionEngine-Features: Relationships-Felder und der Fluid-Feldertyp

ExpressionEngine 7 beeindruckt mich weniger durch spektakuläre, sofort sichtbare „Features“, sondern vielmehr durch seine präzise und durchdachte Inhaltsarchitektur. Ein wesentlicher Kern des Systems ist das Feldsystem für Channels* – genau dort entscheidet sich, wie leistungsfähig und nachhaltig ein Projekt aufgebaut werden kann. Wer Inhalte strukturiert denkt und nicht nur visuell plant, erhält hier ein Setup, das langfristig tragfähig, wartbar und erweiterbar ist.

Ich erlebe es immer wieder, dass genau diese saubere Architektur den Unterschied macht – besonders bei wachsenden Projekten oder komplexeren Anforderungen. Statt Inhalte einfach irgendwo „hineinzuschreiben“, werden sie logisch modelliert. Und das zahlt sich aus. Strukturen bleiben verständlich. Inhalte bleiben konsistent. Erweiterungen sind möglich, ohne das System aufbauen zu müssen.

Im weiteren Verlauf gebe ich zunächst einen kompakten Überblick über die wichtigsten Feldtypen, um das Fundament klar zu machen. Danach gehe ich gezielt auf zwei Bereiche ein, die für mich zu den stärksten Werkzeugen in ExpressionEngine gehören: Relationships-Felder und der Fluid-Feldertyp. Dort zeigt sich, welches Potenzial wirklich in dieser Architektur steckt – vor allem dann, wenn man Inhalte in Beziehungen zueinander denkt und modulare Strukturen sauber aufbauen möchte. Also wenn zum Beispiel ein Mitarbeiter nicht mehrfach angelegt wird, sondern zentral existiert und an verschiedenen Stellen referenziert wird – oder wenn einzelne Inhaltsblöcke flexibel kombiniert werden, ohne die Grundstruktur der Website zu verändern..

* Channels sind in ExpressionEngine die Inhaltsbereiche. Während andere Systeme von „Beitragstypen“ oder „Content Types“ sprechen, heißen diese strukturellen Einheiten hier Channels.

Zwei starke ExpressionEngine-Features: Relationships-Felder und der Fluid-Feldertyp

Wichtige Feldtypen in ExpressionEngine 7 (Kurzüberblick)

ExpressionEngine unterscheidet zwischen einfachen, komplexen und strukturbildenden Feldern.

Einfache Felder:

  • Text Input – einzeilige Texte (z. B. Titelzusatz, SKU)
  • Textarea / RTE – Fließtext mit oder ohne Formatierung
  • Date – Datums- und Zeitwerte
  • Checkbox / Radio / Select – strukturierte Auswahlwerte
  • URL – validierte Webadressen

Struktur- und Datentypfelder:

  • Grid – tabellarische Wiederholungsstruktur
  • File – Dateiverwaltung mit Upload-Verzeichnis
  • Assets / Files (Core) – strukturierte Medienverwaltung
  • Playa / Relationship – relationale Verknüpfung von Entries
  • Fluid Field – flexible, blockbasierte Inhaltsstruktur

Diese Kombination erlaubt eine saubere Trennung von Inhalt, Struktur und Darstellung – ein klarer Vorteil gegenüber rein visuell orientierten Page-Builder-Systemen. Gerade bei WordPress sieht man häufig das Gegenmodell: Viele Projekte basieren stark auf Page-Buildern, bei denen Inhalte primär visuell zusammengesetzt werden. Das funktioniert kurzfristig bequem, führt aber oft zu aufgeblähtem Code, verschachtelten Layout-Strukturen und schwer wartbaren Templates. Inhalte sind dann nicht sauber modelliert, sondern an ein bestimmtes Layout gebunden. Änderungen oder Relaunches werden dadurch aufwendiger, weil Struktur und Darstellung nicht klar getrennt sind. Genau hier spielt eine durchdachte Feldarchitektur wie in ExpressionEngine ihre Stärke aus. 

Relationships-Felder – Relationale Inhalte sauber modellieren

Das Relationships-Feld ermöglicht es, Einträge miteinander zu verknüpfen. Technisch handelt es sich um eine relationale Referenz auf andere Channel-Einträge.

Typische Anwendungsfälle:

  • Blogartikel ↔ verwandte Artikel
  • Produkt ↔ Zubehör
  • Event ↔ Referent
  • Projekt ↔ Kunde

Mehrsprachige Strukturen lassen sich auch ohne Add-ons wie Transcribe realisieren, indem Einträge über ein Relationship-Feld als jeweilige Sprachvariante miteinander verknüpft und im Template gezielt ausgegeben werden. Gleichzeitig ermöglicht das Feld eine redaktionelle Kuratierung: Inhalte können manuell ausgewählt und in einer definierten Reihenfolge ausgespielt werden, etwa für Bereiche wie „Empfohlene Beiträge“.

Beispiele aus meiner Praxis sind etwa, dass Bildungsprojekten gezielt Premieren oder Veranstaltungen zugeordnet werden können oder dass bestimmten Fachgebieten die jeweils zuständigen Anwälte zugewiesen sind. Die Inhalte existieren dabei jeweils nur einmal im System und werden an den passenden Stellen strukturiert ausgegeben.

relationshipsfeld-beispiel.webp

Referenten einem Event zuordnen – klassisches Relationships-Beispiel

Ein klassisches Praxisbeispiel ist auch die Zuordnung von Referenten zu einem Event, bei dem ein Veranstaltungseintrag mehrere Referenten referenziert und diese strukturiert ausgibt.

Setup:

  • Channel: events
  • Channel: referenten
  • Feld im Channel events: event_referenten (Relationships-Feld)

Im Backend wählt der Redakteur beliebige Referenten aus. Template-Ausgabe:
 

<section class="event">
  <h1>{title}</h1>
  <div class="event-content">
    {event_text}
  </div>
  {if event_referenten}
    <div class="referenten">
      <h2>Referenten</h2>
      <ul>
        {event_referenten}
          <li>
            <h3>{event_referenten:title}</h3>
            <p>{event_referenten:referent_beschreibung}</p>
          </li>
        {/event_referenten}
      </ul>
    </div>
  {/if}
</section>


  Was hier passiert:

  • {event_referenten} iteriert über die verknüpften Entries.
  • {event_referenten:title} greift auf Felder des verknüpften Entries zu.
  • Die Reihenfolge entspricht der redaktionellen Auswahl.

Vorteile des Relationship-Feldes:

  • Keine redundanten Inhalte
  • Zentrale Pflege (Änderung an einer Stelle wirkt überall)
  • Klare Datenstruktur
  • Gute SEO-Basis (keine doppelten Texte)
  • Hohe Flexibilität bei komplexen Websites

Gerade bei größeren Projekten entsteht dadurch ein sauber normalisiertes Content-Modell – ähnlich relationalen Datenbanken.

Fluid-Feld – Modulares Content-Design

Das Fluid Field gehört zu den leistungsstärksten Konzepten in ExpressionEngine 7. Es ermöglicht Redakteuren, unterschiedliche Feldtypen flexibel miteinander zu kombinieren, ohne dabei die grundlegende Struktur eines Channels aufzulösen oder technisch zu verwässern. Statt einer starren Abfolge fest definierter Felder steht ein Container-Feld zur Verfügung, das verschiedene zuvor konfigurierte Feldtypen aufnehmen kann.

fluidfeld.webp

Ein typisches Szenario sind modulare Inhaltsblöcke: Ein Channel seiten besitzt beispielsweise ein Fluid-Feld seiten_inhalt, innerhalb dessen unterschiedliche Inhaltselemente – etwa Text, Bild, Zitat oder Call-to-Action – frei zusammengestellt und in variabler Reihenfolge angeordnet werden können. Die Struktur bleibt dabei klar definiert, während die redaktionelle Flexibilität deutlich erhöht wird.

Darin können enthalten sein:

  • Textblock
  • Audiofile
  • Zitat
  • Call-to-Action
  • Diashow-Slider
  • Grid-Feld
  • Relationship-Feld

Warum das Fluid-Feld so stark ist:

  • Redaktionsfreundlich – keine starre Feldreihenfolge
  • Entwicklerkontrolle – keine unkontrollierten Layout-Zerstörungen wie bei Page Buildern
  • Kombinierbar – Relationship-Felder innerhalb eines Fluid-Feldes sind möglich
  • Strukturiert statt visuell manipulativ – Inhalt bleibt semantisch sauber
  • Skalierbar – neue Blocktypen lassen sich jederzeit ergänzen

Zusammenspiel: Relationsship + Fluid

Richtig spannend wird ExpressionEngine immer dann, wenn man Relationship-Felder und das Fluid-Feld miteinander kombiniert. Damit kann spielt man die Stärke von ExpressioEngine wirklich aus. Das Fluid-Feld sorgt für eine flexible, modulare Seitenstruktur. Relationships-Felder bilden dagegen saubere, relationale Verbindungen zwischen Inhalten ab. Ergänzt man das noch um Grid-Felder für strukturierte Datensätze und Datei-Felder für Medien, entsteht ein System, das zugleich flexibel und strukturell klar bleibt.

Ich bin selbst immer wieder begeistert, wie komplexe Inhaltsstrukturen sich damit abbilden lassen – ohne chaotisch zu werden. Man kann sehr differenzierte Seitenmodelle entwickeln, ohne Redundanz zu erzeugen. Inhalte müssen nicht mehrfach gepflegt werden, sondern existieren genau einmal und werden dort referenziert, wo sie gebraucht werden. Das spart Zeit. Und es verhindert Fehler.

Ein einfaches Beispiel noch: Ein Redakteur fügt in einem Fluid-Feld einen Block „Teammitglieder“ ein. Dieser Block enthält intern ein Relationship-Feld, über das bestimmte Mitarbeiter ausgewählt werden. Die Teamseite entsteht dynamisch. Ändert sich die Beschreibung eines Mitarbeiters, wirkt sich das automatisch überall aus, wo diese Person referenziert ist. Keine doppelte Pflege. Keine inkonsistenten Daten. Genau so sollte relationale Inhaltsverwaltung funktionieren.

Gerade Kunden profitieren davon enorm. Sie erhalten keine starre Struktur, aber auch kein unkontrollierbares Baukastensystem. Stattdessen bekommen sie eine klar definierte, relationelle Architektur, die ihnen die Pflege erleichtert. Inhalte lassen sich logisch denken. Und logisch verwalten.

Fazit

ExpressionEngine 7 überzeugt mich vor allem durch seine datenbanknahe Inhaltsmodellierung. Relationen sind sauber abbildbar. Strukturen bleiben klar. Gleichzeitig bleibt das System flexibel, aber eben kontrolliert. Die Trennung von Struktur und Darstellung ist konsequent durchgezogen – und das merkt man in der Wartbarkeit.

Viele Systeme setzen zuerst auf visuelle Freiheit und kümmern sich später um Struktur. ExpressionEngine geht den umgekehrten Weg: erst die Architektur, dann das Layout. Gerade bei komplexen, mehrsprachigen, relationalen oder langfristig angelegten Projekten zeigt sich, wie tragfähig dieser Ansatz ist. Und genau deshalb arbeite ich so gern damit.

\\\ Update: 27.02.2026   Angelegt: 27.02.2026   Rubrik: ExpressionEngine   Views: 21   

Blog-Startseite /// Rubrik ExpressionEngine