← WISSENS-BLOG
Praxisbericht: Eine flexible und pflegeleichte Startseite mit ExpressionEngine
Für ein aktuelles Kundenprojekt sollte eine bereits gestaltete und in HTML und CSS umgesetzte Startseite in ExpressionEngine integriert werden. Im Mittelpunkt stand dabei die Frage, wie sich unterschiedliche Inhaltsbereiche mit möglichst wenig Feldern und ohne zusätzliche Entscheidungen für die Redaktion abbilden lassen. Der Artikel zeigt, warum ich mich für feste Bereiche, Grid-Felder und eine einfache CMS-Struktur entschieden habe und welche Alternativen dabei verworfen wurden. Der Praxisbericht verdeutlicht außerdem, warum weniger Felder und klare Strukturen oft sinnvoller sind als zusätzliche Steuerungsmöglichkeiten für die Redaktion.
Bildnachweis: iStockphoto / Thomas Bethge
Der Aufbau der Startseite
Die Startseite besteht aus vier Bereichen. Ganz oben steht ein großer Bildbereich mit mehreren Bildern, einer Überschrift und einem Call-to-Action-Button. Dieser Bereich soll auf wichtige Themen aufmerksam machen und kann später flexibel angepasst werden.
Darunter folgen die wichtigsten Informationen. Kleine Teaser verweisen auf häufig gesuchte Inhalte. Anschließend kommen die Hauptbereiche der Website. Hier führen größere Bildteaser zu den wichtigsten Seiten. Den Abschluss bilden zwei Videos.
Für Besucher wirkt dieser Aufbau selbstverständlich. Hinter den Kulissen musste dafür jedoch eine Struktur entstehen, die unterschiedliche Layouts unterstützt und gleichzeitig einfach zu pflegen bleibt.
Die erste Idee: Alles über Grid-Felder
Grid-Felder nutze ich in ExpressionEngine sehr häufig. Sie eignen sich gut für Inhalte, die immer dieselbe Struktur besitzen.In diesem Projekt bestand ein typisches Element aus:
- Bild
- Überschrift
- Link
- Alternativtext
Für den oberen Bildbereich und die Informationskacheln war das eine gute Lösung. Neue Inhalte lassen sich hinzufügen, bearbeiten oder in der Reihenfolge verändern, ohne dass dafür das Template angepasst werden muss. Schnell zeigte sich jedoch, dass Grid-Felder allein nicht ausreichen. Die eigentliche Frage war eine andere:
Wie lassen sich unterschiedliche Layouts innerhalb eines einzigen Channels abbilden, ohne dass der Kunde zusätzliche Einstellungen vornehmen muss?
Denn die Anforderungen waren sehr unterschiedlich. Der Bildbereich benötigt mehrere Bilder und einen Button. Die Informationskacheln verwenden ein anderes Layout als die Hauptbereiche der Website. Die Videos benötigen wiederum eine eigene Ausgabe. Die Inhalte ähneln sich teilweise. Die Darstellung unterscheidet sich jedoch deutlich.
Alle Bereiche der Startseite sollten aus demselben Channel stammen. Die Inhalte sollten dort als einzelne Einträge angelegt werden. Gleichzeitig musste die Pflege für den Kunden möglichst einfach bleiben. Damit stellte sich eine zentrale Frage: Wie lässt sich die Seitenstruktur steuern, ohne zusätzliche Komplexität ins CMS zu bringen?
Kategorien oder zusätzliche Steuerfelder?
Eine Möglichkeit war, die unterschiedlichen Bereiche über Kategorien zu steuern. Kategorien wie „Slider“, „Informationen“, „Hauptbereiche“ oder „Videos“ hätten dem Template sagen können, welcher Bereich gerade ausgegeben wird. Technisch wäre das möglich gewesen. Für mich fühlte es sich aber nicht richtig an. Kategorien hätten hier nicht Inhalte sortiert, sondern das Layout gesteuert.
Eine weitere Möglichkeit wäre ein zusätzliches Auswahlfeld gewesen:
Layouttyp ○ Slider ○ Informationskachel ○ Hauptbereich ○ Video
Auch das wäre technisch sauber gewesen. Für den Kunden wäre es aber eine weitere Entscheidung im CMS. Und genau solche zusätzlichen Entscheidungen wollte ich vermeiden. Je weniger der Kunde konfigurieren muss, desto besser.
Die einfache Lösung – wie so oft über Umwege
Deshalb entschied ich mich für einen pragmatischen Ansatz. Die Struktur der Startseite wird über feste Einträge innerhalb desselben Channels definiert. Jeder Bereich besitzt seinen eigenen Eintrag: Slider, wichtige Informationen, Hauptbereiche und Videos. Im Template erfolgt die Zuordnung anschließend über den URL-Title. Interessanterweise war das am Ende sogar die einfachste Lösung. Der Kunde muss keine Kategorien auswählen, keine Layouttypen verstehen und keine technischen Entscheidungen treffen. Die Inhalte landen automatisch an der richtigen Stelle.
Die Grid-Felder bleiben trotzdem erhalten. Sie übernehmen genau dort ihre Aufgabe, wo sie ihre Stärke ausspielen können: innerhalb der einzelnen Bereiche. Dadurch entsteht eine klare Trennung. Die Seitenstruktur ist fest definiert. Die Inhalte innerhalb der Bereiche bleiben flexibel. Während der Umsetzung ließ sich sogar noch ein Feld einsparen. Die Überschrift eines Bereichs ist bereits der Beitragstitel. Warum also dieselbe Information zweimal speichern? Für Bereiche wie „Die wichtigsten Informationen“, „Hauptbereiche“ oder „Videos“ reicht der Titel des jeweiligen Eintrags vollkommen aus.
Eine Kleinigkeit vielleicht. Bei komplexeren Inhaltsstrukturen sind es aber oft genau solche Überlegungen, die am Ende den Unterschied machen. Wo kann ein Feld entfallen? Welche Information existiert bereits? Und wie lässt sich die Pflege vereinfachen, ohne die Möglichkeiten für den Kunden einzuschränken?
Und ich muss zugeben: Je länger ich mich mit den verschiedenen Möglichkeiten beschäftigt habe, desto besser gefiel mir dieser Ansatz. Weniger Felder. Weniger Möglichkeiten für Fehler. Weniger Erklärungsbedarf.
Wie so oft führte der Weg über mehrere Überlegungen und verworfene Ansätze. Am Ende blieb die einfachste Lösung übrig.
Template-Code: Ein bewusster Kompromiss
Natürlich hatte diese Lösung auch einen kleinen Nachteil. Im Template entsteht dadurch etwas mehr Code, als mir normalerweise lieb ist. Einige Strukturen wiederholen sich und auch die einzelnen Bereichsausgaben ähneln sich teilweise. Wer streng nach dem DRY-Prinzip („Don't Repeat Yourself“) arbeitet, würde hier versuchen, weitere Abstraktionen einzubauen.
{exp:channel:entries channel="startseite" url_title="slider" limit="1"}
<section class="buehne">
<div class="buehnenbilder">
{slider}
<img{if slider:count == 1} class="aktiv"{/if}
src="{slider:file}"
alt="{slider:alttext}">
{/slider}
</div>
<div class="buehnetext">
<h1>{title}</h1>
<a class="bewerben" href="#">Jetzt bewerben</a>
</div>
</section>
{/exp:channel:entries}
{exp:channel:entries channel="startseite" url_title="wichtige-informationen" limit="1"}
<section class="bereich">
<h2>{title}</h2>
<div class="kacheln">
{cards}
<a class="kachelklein" href="{cards:link}">
<img src="{cards:file}{path}_bildklein/{filename}.{extension}{/cards:file}"
alt="{cards:alttext}">
<h3>{cards:thema}</h3>
</a>
{/cards}
</div>
</section>
{/exp:channel:entries}
{exp:channel:entries channel="startseite" url_title="hauptbereiche" limit="1"}
<section class="bereich">
<h2>{title}</h2>
<div class="kacheln">
{cards}
<a class="kachelgross" href="{cards:link}">
<img src="{cards:file}{path}_bildteaser/{filename}.{extension}{/cards:file}"
alt="{cards:alttext}">
<span>{cards:thema}</span>
</a>
{/cards}
</div>
</section>
{/exp:channel:entries}
{exp:channel:entries channel="startseite" url_title="videos" limit="1"}
<section class="bereich">
<h2>{title}</h2>
<div class="videos">
{cards}
<div class="video">
<video controls>
<source src="{cards:file}" type="video/mp4">
</video>
</div>
{/cards}
</div>
</section>
{/exp:channel:entries}
Wie bereits erläutert, haben die Bereiche aber unterschiedliche Layouts. Das lässt sich nicht wegdiskutieren und auch nicht einfach wegcoden. Der obere Bildbereich, die kleinen Informationskacheln, die großen Hauptbereiche und die Videos brauchen jeweils eine eigene Ausgabe.
Natürlich könnte man versuchen, diese Unterschiede über Bedingungen im Template abzufangen. Dann würde weniger Code doppelt erscheinen. Dafür entstünde an anderer Stelle mehr Logik. Die Alternative wären zusätzliche Steuerfelder, Kategorien oder verschachtelte Conditions gewesen. Das Template wäre vielleicht etwas kompakter geworden. Gleichzeitig hätte die Komplexität in der Template-Logik zugenommen.
Da das gesamte Template doch recht schlank geblieben ist, erschien mir dieser Kompromiss sinnvoll. In diesem Fall war mir eine einfache Pflege wichtiger als ein theoretisch perfektes Template.
Eine Struktur, die nachvollziehbar bleibt
Gerade der Bereich „Hauptbereiche der Website“ zeigt den Vorteil gut. Auf der Website erscheinen mehrere große Teaser. Im CMS ist es ein einziger Startseiten-Eintrag mit einem Grid-Feld.
Der Kunde kann Teaser ergänzen, Texte ändern oder Links austauschen, ohne die Grundstruktur der Seite zu berühren. Für Entwickler bleibt die Lösung ebenfalls gut nachvollziehbar. Die Startseite besteht aus festen Bereichen. Wiederkehrende Inhalte liegen in Grid-Feldern.
Die Lösung ist vielleicht nicht in jedem Detail perfekt nach dem DRY-Prinzip aufgebaut. Dafür lässt sie sich schnell erfassen und verstehen. Und genau das ist bei Projekten, die über Jahre gepflegt und weiterentwickelt werden, oft wichtiger als einige eingesparten Zeilen Code.
Einen Nachteil möchte ich nicht verschweigen
So zufrieden ich mit der Lösung bin, einen kleinen Nachteil bringt sie mit sich. Die ersten Bereiche der Startseite sind fest im Template definiert. Wenn später ein weiterer Bereich hinzukommen soll, stellt sich also sofort die Frage: Wo soll er erscheinen und welches Layout soll er bekommen?
Genau das lässt sich nicht allein technisch entscheiden. Soll der neue Bereich oberhalb der Videos stehen? Unterhalb der Videos? Soll er kleine Kacheln verwenden oder große Teaser wie die Hauptbereiche? Solche Fragen gehören zur Seitenstruktur und sollten mit dem Kunden abgestimmt werden.
Trotzdem lässt sich das Template gut vorbereiten. Eine elegante Möglichkeit ist ein zusätzlicher channel:entries-Tag, der alle Einträge aus dem Startseiten-Channel ausgibt, aber die festen Systembereiche über den URL-Title ausschließt. Der Kunde könnte dann später einen weiteren Bereich mit Cards anlegen. Dieser Bereich würde automatisch ausgegeben, ohne dass die bestehenden Bereiche verändert werden müssen.
{exp:channel:entries channel="startseite" url_title="not slider|wichtige-informationen|hauptbereiche|videos"}
<section class="bereich">
<h2>{title}</h2>
<div class="kacheln">
{cards}
<a class="kachelgross" href="{cards:link}">
<img src="{cards:file}{path}_bildteaser/{filename}.{extension}{/cards:file}"
alt="{cards:alttext}">
<span>{cards:thema}</span>
</a>
{/cards}
</div>
</section>
{/exp:channel:entries}
In diesem Beispiel würde der zusätzliche Bereich dasselbe Layout wie die großen Hauptbereiche verwenden. Das wäre für weitere Teaser naheliegend und hält die Gestaltung ruhig. Wo dieser Template-Block steht, entscheidet dann die Position auf der Startseite. Ich würde ihn wahrscheinlich oberhalb der Videos einfügen. Genau das wäre aber eine Frage, die man im konkreten Fall mit dem Kunden bespricht.
Eine weitere Frage wäre die Sortierung. Die vier festen Bereiche sind im Template bewusst fest angeordnet. Ihre Reihenfolge wird also nicht über das CMS gesteuert, sondern über das Template. Für zusätzliche Bereiche könnte man mit Veröffentlichungsdatum, Entry-Reihenfolge oder einer anderen Steuerung arbeiten.
Noch flexibler wäre eine Lösung über ein Relationships-Feld. Dann könnten Bereiche gezielt ausgewählt und per Drag-and-Drop sortiert werden. Das klingt komfortabel, bringt aber wieder mehr Struktur, mehr Felder und mehr Aufwand mit sich. An einem bestimmten Punkt wird eine Lösung für den Kunden nur scheinbar einfacher. Technisch wächst im Hintergrund die Komplexität.
Für dieses Projekt erschien mir der vorbereitete Zusatzbereich als sinnvoller Kompromiss. Die feste Struktur bleibt erhalten. Der Kunde bekommt trotzdem eine Erweiterungsmöglichkeit.
Fazit
Bei solchen Projekten setze ich die Prioritäten nicht erst während der Entwicklung, sondern bereits davor. Eine dieser Prioritäten ist die spätere Pflege. Der Kunde soll Inhalte möglichst einfach ändern können. Er soll verstehen, was er tut. Und er soll nicht für jede Kleinigkeit den Entwickler anrufen müssen.
Das bedeutet nicht, dass jede technische Möglichkeit ausgeschöpft werden muss. Es bedeutet auch nicht, dass jede denkbare Funktion ihren Weg ins CMS finden sollte. Entscheidend ist, ob sie dem Kunden tatsächlich einen Mehrwert bietet. Genau das gehört zu meinem Selbstverständnis als Entwickler.
Der eine oder andere würde darüber vermutlich den Kopf schütteln (ich habe das auch schon erlebt). Schließlich macht man sich damit ein Stück weit selbst überflüssig. Ich sehe das anders. Wenn ein Kunde seine Website möglichst selbstständig pflegen kann und die Struktur auch Jahre später noch verständlich bleibt, dann ist das für mich ein gutes Ergebnis – und Ausdruck von Fairness gegenüber dem Kunden.
Weiterführende Artikel
- 10 Vorteile des CMS ExpressionEngine für Kunden, Designer und Webentwickler
- Zwei starke ExpressionEngine-Features: Relationships-Felder und der Fluid-Feldertyp
- Interview: Zwischen ExpressionEngine, KI und E-Commerce
Blog-Startseite /// Rubrik ExpressionEngine