Zum Inhalt springen
Marketing Factory Digital GmbH
Kontakt
Ein riesiger Eisberg thront auf ruhigem Wasser, umgeben von treibenden Eisscherben. Im Hintergrund sind schneebedeckte Berge zu sehen. Das Wasser reflektiert die kalte Atmosphäre der arktischen Landschaft.

Warum wir das Bootstrap Package aus Projekten entfernen

Wir haben in der Vergangenheit einige Kundenprojekte auf Basis des Bootstrap Package eingerichtet. Im Laufe der Jahre haben wir festgestellt, dass Upgrades damit einen sehr hohen Aufwand erfordern.

Daher haben wir schon Ende 2022 beschlossen, keine neuen Websites mehr mit der Extension einzurichten. In den letzten Wochen habe ich das Bootstrap Package aus zwei weiteren TYPO3-Installationen entfernt.

tl;dr

Wir halten es nicht für zweckdienlich, das Bootstrap Package als Fundament für eigene Projekte zu verwenden. Es besitzt zu viele Showcase-Funktionen, die selten gebraucht werden. Neue Versionen der Extension enthalten Neuerungen, die einem stabilen Projekt entgegenstehen. Die mehrfache Vererbung von Konfigurationen und Templates erhöht den Wartungsaufwand.
Das Bootstrap Package selbst stellen wir nicht infrage, es ist ein wichtiger Baustein im TYPO3-Ökosystem.

Inhaltsverzeichnis

Was ist das Bootstrap Package?

Das Bootstrap Package ist eine TYPO3-Extension, die ein vollständiges Frontend-Theme auf Basis des Bootstrap-Frameworks bereitstellt.

Es ist unter anderem:

  • Ein Showcase für die Möglichkeiten mit TYPO3 CMS
  • Die technische Basis für das offizielle TYPO3 Introduction Package
  • Eine gebrauchsfertige TYPO3-Website ohne große Entwicklerkenntnisse
  • Ein responsives Frontend-Theme (im Gegensatz zu Fluid Styled Content)

Oder wie es in dessen Dokumentation beschrieben wird:

The goal of this package is also to give an advanced example of how modern templating in TYPO3 CMS can be handled nicely without depending on third party extensions. Bootstrap Package comes with a fully configurable Frontend via TypoScript. This includes the TypoScript Constant Editor.

Die von mir hervorgehobenen Passagen beschreiben bereits zwei der Themen, die ich für den produktiven Einsatz in einer Website als problematisch sehe. Aber lasst uns zuerst einmal erklären, warum wir die Extension damals verwendet haben.

Warum haben wir das Bootstrap Package genutzt?

Das Bootstrap Package war die Grundlage für Kundenprojekte, weil es ganz unbestritten eine tolle Extension ist.

Es liefert:

  • Ein voll funktionstüchtiges Website-Template direkt nach Installation
  • Viele Inhaltselemente, basierend auf Bootstrap (Accordion, Slider, Card Group, …)
  • Responsives Bildrendering unter Berücksichtigung von Mehrspaltigkeit in Inhaltselementen, innerhalb von Container-Elementen sowie Seitenlayout-Spalten
  • Viele Good Practices für TYPO3-Konfigurationen

… und einiges mehr.

Jede Version des Bootstrap Package unterstützt jeweils zwei TYPO3-Versionen. Das erleichtert das TYPO3-Upgrade, weil es unabhängig vom Upgrade der Extension erfolgen kann. Aber spätestens mit dem ersten Upgrade des Bootstrap Package beginnen die Probleme.

Was spricht gegen die Verwendung des Bootstrap Package?

Zeige größere Version von: Ein Konfigurationsfenster zur Auswahl eines Icons. Oben sind Einstellungen für Position, Typ, Größe und Farbe zu sehen. Darunter befindet sich eine Symbolbibliothek namens Glyphicons. In der Rasteransicht ist das Flammensymbol blau hervorgehoben.
Die Icon-Konfiguration von "Text & Icon". Das ist maximal flexibel – aber wird es im Kundenprojekt so benötigt? In erster Linie zeigt es, dass in TYPO3 alles möglich ist.

a) Zu viele Showcase-Funktionen

Die Extension besitzt wirklich einen riesigen Funktionsumfang. Beschränken wir uns daher einfach nur auf das Thema Icons. Manche Websites verwenden Icons in ihrer Hauptnavigation. Wieder andere heben beispielsweise ihre Leistungen im Text mit Icons hervor.

Das Bootstrap Package erweitert TYPO3 in den Seiteneigenschaften und stellt zudem mehrere Inhaltselemente bereit, um Icons auf der Website auszugeben:

  • Icons in den Seiteneigenschaften
    • Ziel: Die Ausgabe des Seiten-Icons ist einzeln steuerbar für Hauptnavigation, Subnavigation, Breadcrumb und Footer-Navigation
    • Optionen: Auswahl eines Icons aus den mitgelieferten Icon-Sets "Glyphicons" bzw. "Ionicons", oder alternativ ein eigenes Bild aus der Dateiliste
  • Inhaltselement “Text & Icon”
    • Ziel: Anzeigen eines einzelnen Icons neben Text
    • Optionen:
      • Icon aus den Icon-Sets oder ein eigenes Bild aus der Dateiliste
      • Icon-Ausrichtung
      • Icon-Größe
      • Optionaler Icon-Hintergrund (Quadrat oder Kreis)
      • Bei gewähltem Icon-Hintergrund: Farbwähler für Icon- und Hintergrundfarbe
  • Inhaltselement “Icon Group”
    • Ziel: Text und Icon, gruppiert in einem Raster
    • Optionen:
      • Icon aus den Icon-Sets oder ein eigenes Bild aus der Dateiliste
      • Icon-Ausrichtung
  • Menü-Inhaltselemente "Cards" und “Cards of subpages”
    • Ziel: Ausgabe des Icons aus den Seiteneigenschaften im Menü-Element

Fällt euch ein Projekt ein, wo ihr diese Vielzahl an Möglichkeiten auch nur im Ansatz benötigt? Habt ihr Fälle, wo ein Redakteur mal runde, mal quadratische Hintergründe bei Icons wählen können muss?

Wir haben sehr viel Zeit damit verbracht, nicht benötigte Elemente, Felder und Optionen für Backend-Nutzer auszublenden. Sofern man die Templates nicht anfasst, verbleiben diese Optionen aber im Code. Wir schleppen CSS, HTML und TypoScript für Funktionen mit, die nicht genutzt werden.

b) Mehrfache Vererbungen im Frontend-Bereich

Das Bootstrap Package enthält alle Konfigurationen und Frontend-Templates für die Website und deren Inhaltselemente. Wirklich alle? Nein, unser eigenes Sitepackage enthält Overrides und Ergänzungen für das Kundenprojekt.

Das wird schnell unübersichtlich. Insbesondere, wenn die TYPO3-Installation mehrere Sites mit unterschiedlichen Designs enthält.

Dann erhält man Abhängigkeiten, die so aussehen können:

Bootstrap Package → Globale Projekteinstellungen im Sitepackage → Corporate Site Base → Corporate Site DE
Bootstrap Package → Globale Projekteinstellungen im Sitepackage → Corporate Site Base → Corporate Site US
Bootstrap Package → Globale Projekteinstellungen im Sitepackage → Tochterunternehmen A
Bootstrap Package → Globale Projekteinstellungen im Sitepackage → Tochterunternehmen B

Dazu kommt: Wir haben viele Elemente des Bootstrap Package in Styling und Funktion an das Kundenprojekt angepasst. Das sorgte selbst bei Patch-Releases der Extension mehrfach für Breaking Changes in der Ausgabe (abgefangen durch unsere automatisierten Tests).

c) Das Bootstrap Framework

Mit der Nutzung des Bootstrap Package verwendest du zum Styling zwangsläufig Bootstrap. Auch das kann einschränken.

Fremdgesteuerte Upgrades: Die Komponenten unserer Kundenprojekte halten wir mit Continuous Upgrading aktuell. Das gilt für Webserver, TYPO3 und PHP-Pakete, aber auch für Frontend-Komponenten. Wenn aber das Bootstrap Package in neuer Version den Support für Bootstrap 4 entfernt, bin ich beim Upgrade gezwungen, alle Templates für Bootstrap 5 fit zu machen. Diesen Zeitpunkt möchte ich gern selbst wählen. Was halt nur geht, wenn ich die volle Kontrolle über mein Frontend besitze.

Unerwartete Anpassungen von Default-Werten und Styles: Den Wechsel auf Bootstrap 5 im Bootstrap Package haben wir damals anhand eines sehr umfangreichen Commits nachvollzogen. Dabei mussten wir feststellen, dass sich auch Default-Werte sowie die Specificity von Styles verändert haben. Einige Elemente haben zudem ein neues Design erhalten.
Wenn das Ziel in eurem Kundenprojekt ist, das bisherige Aussehen beizubehalten – viel Erfolg.

Vererbungen (schon wieder): Das Bootstrap Package liefert einen Parser mit, um SCSS-Variablen von Bootstrap per TypoScript Constants (oder neuer: Site Settings) anpassen zu können. Als Agentur setzen wir lieber auf einen eigenen Build-Prozess und laden nur die Komponenten, die benötigt werden.

Da wir in jedem Fall eigenes (S)CSS benötigen, um die Website zu individualisieren, erhalten wir auch hier mehrere Abhängigkeiten:

Bootstrap-SCSS → Bootstrap Package-SCSS → projektspezifische Styles

Bootstrap besitzt eine lange Liste von SCSS-Variablen. Das Bootstrap Package überschreibt einen Teil davon und bringt wieder eigene mit. Wir individualisieren beides erneut und ergänzen unsere eigenen. Dasselbe gilt natürlich auch für die eigentlichen CSS-Regeln. Klingt kompliziert? Das ist es auch.

In vielen Projekten haben wir die Stylesheets inzwischen komplett auf Custom Code umgestellt. Bei unserer eigenen Website konnten wir die Stylesheet-Dateigröße dadurch von 351 KB auf 108 KB reduzieren. Durch den Wegfall der Vererbungen und Overrides hat sich die Wartbarkeit deutlich verbessert.

Zeige größere Version von: Dies zeigt das Einstellungsfenster für "Content Element Layout". Der Bereich "Frame Options" ist lila umrandet und enthält Checkboxen für "Ruler before", "Ruler after", "Indent left" und "Indent right". Links sind Dropdown-Menüs für Layout und Frame zu sehen.
Eine Checkbox-Liste für sich ergänzende Styling-Optionen ist eine gute Idee. Allerdings wird sie für die alten "Frame"-Standardwerte aus dem TYPO3-Core genutzt. Diese Optionen waren immer nur Beispiele, die bei der Ersteinrichtung üblicherweise entfernt wurden.

d) Neue Features durch Upgrades sind schon im Projekt vorhanden (oder werden nicht benötigt)

Mit jeder neuen Version des Bootstrap Package kommen neue Funktionen hinzu. Oder Optionen des TYPO3 Core werden durch eigene Lösungen ersetzt.

Die Frame classes "Ruler before", "Ruler after", "Indent left" etc. können im TYPO3 Core nur in einem Auswahlfeld gewählt werden – sie schließen sich gegenseitig aus. Das Bootstrap Package ersetzt und migriert diese zu einer Checkbox-Liste "Frame options", mit der sich die Optionen miteinander kombinieren lassen.

Klingt sinnvoll, oder? Allerdings gehören genau diese Optionen zu den ersten Dingen, die ich in einer neuen TYPO3-Installation ausblende: In einer responsiven Website müssen Elemente selten eingerückt werden. Trennlinien werden nicht immer benötigt und können auf anderem Weg erzielt werden.
Wir stellen stattdessen Optionen bereit, um ein Inhaltselement wahlweise im Seitenlayout oder auf voller Breite ausgeben zu lassen.

Dann habe ich gleich zwei Beispiele, bei denen die Ausgabe von Überschriften im Bootstrap Package verbessert wurde:

  1. Ein neues Auswahlfeld in Inhaltselementen bietet die Möglichkeit, eine H2-Überschrift beispielsweise wie eine H3-Überschrift aussehen zu lassen. Damit bleibt die wichtige Semantik der Überschrift erhalten, der Redakteur kann davon unabhängig das Aussehen anpassen.
  2. Wählbare Überschriften für Kindelemente. Lange Zeit hatten die einzelnen Elemente einer Card Group oder eines Accordions eine fest definierte Überschrift (H3 oder H4) im Template. In den meisten Fällen sollte dies aber abhängig von der vorherigen Überschrift sein: Auf eine H2 sollten die Kindelemente jeweils mit einer H3 folgen. Jetzt gibt es das Auswahlfeld "Items Header Type", mit dem der Redakteur das Level der Überschrift selbst auswählen kann.

Ärgerlich dabei: genau diese beiden Features hatten wir in Kundenprojekten schon selbst ergänzt. Und aus unserer Sicht noch etwas besser umgesetzt:

  1. Das Überschrift-Styling haben wir so erweitert, dass als Header-Typ auch ein Absatz wählbar ist. So kann der Redakteur eine Textzeile wie eine Überschrift aussehen lassen. Die Heading-Struktur der Seite bleibt damit sauber.
  2. Das Auswahlfeld des Bootstrap Package besitzt immer eine Option zwischen H2 und H5, die der Redakteur korrekt wählen muss. Wir ermitteln stattdessen einen sinnvollen Defaultwert abhängig vom Header-Typ des Elternelements. Der Redakteur kann bei Bedarf einen individuellen Wert wählen. Über einen ViewHelper lesen wir beide Überschrift-Felder (Elternelement und Kindelemente) aus und ermitteln den finalen Wert. Auch für die Überschriften der Kindelemente ist ein Absatz wählbar für den Fall, dass etwa Cards keine echte HTML-Überschrift besitzen sollen.

Durch das Upgrade hatten wir plötzlich je zwei Lösungen für dieselbe Funktion. Und mussten die Doppelgänger aus dem Bootstrap Package wieder heraus konfigurieren.

Ein Softwareprojekt wie das Bootstrap Package muss sich weiterentwickeln können. Dem gegenüber steht das Kundenprojekt: Bei einem Upgrade von Softwarekomponenten sollten sich Ausgabe und Verhalten nicht deutlich ändern. Neue Features ergänzen wir dann in der Website, wenn der Kunde diese benötigt.

e) Unsere Erwartungen haben sich nicht erfüllt

“Wir erhalten mit wenig Aufwand eine fertige Website!”
In der Praxis werden von uns viele Elemente der Website an die Bedürfnisse des Kunden angepasst. Gerade die Hauptnavigation, ein zentrales Element jeder Website, wird fast immer auf die individuellen Projektanforderungen maßgeschneidert.
Am Ende bleibt vom ursprünglichen Seiten-Template des Bootstrap Package nicht viel mehr als das Grundgerüst.

“Wir erhalten mit wenig Aufwand fertige Inhaltselemente!”
Das Bootstrap Package bringt 24 Inhaltselemente mit – die wenigsten können dem Kunden ohne Individualisierung bereitgestellt werden. Sie benötigen CI-konformes Styling, zusätzliche Felder und Funktionen. Davon abgesehen verwendet kein Kunde jemals die gesamte Palette an Inhaltselementen.

“Wir profitieren von Neuerungen im Bootstrap Package!”
Bessere Barrierefreiheit? Haben wir schon implementiert.
Variable Überschriften? Dito, siehe Punkt d).
Neue Felder und Optionen für noch variableres Rendering von Elementen? Erzeugen in bestehenden Projekten eher Mehraufwand, um den gewünschten Status Quo beizubehalten.

“Eine neue Website ist schneller einsatzbereit!”
Würde ich so auch nicht unterschreiben. Unter gewissen Umständen.
Die genannten mittel- bis langfristigen Probleme stehen der initialen Einrichtung gegenüber.

Ersetzen des Bootstrap Package

Wir haben also genug Gründe, auf das Bootstrap Package als Gesamtpaket zu verzichten. Die aktiv genutzten Komponenten sind aber gut und praktisch.
Diese migrieren wir daher in unser Sitepackage.

In dem Zuge bereinigen wir sowohl die Konfigurationen als auch die Templates. Denn viele Einstellungen und Partials werden im Projekt schlicht nicht benötigt.
Bestehende TSconfig-Overrides können teils ins TCA verschoben werden, ungenutzte Felder und Optionen werden von dort entfernt.

Im Anschluss können wir die migrierten Komponenten auf die aktuelle TYPO3 API anpassen. Denn obwohl im Bootstrap Package viele Good Practices vereint sind – durch den gleichzeitigen Support von zwei TYPO3-Versionen können Neuerungen dort nur verzögert angewendet werden. Das gilt für Site Sets oder das PAGEVIEW-Objekt ebenso wie die Registrierung von Inhaltselementen im TCA.

Vorteile durch die Migration

  • Reduktion auf benötigte Funktionen
  • Weniger Overrides
  • Verschlankter Code
  • Bessere Wartbarkeit
  • Weniger Dependencies
  • Früher Wechsel auf aktuelle API

Schlusswort

Das Bootstrap Package ist und bleibt relevant – für uns und das TYPO3-Projekt sowieso. Als Showcase und Proof of Concept, was (wie) möglich ist. Als Vorlage, bei der man sich vieles abschauen kann. Und als gebrauchsfertige Lösung für Projekte, die keinen hohen Grad an Individualisierung benötigen.

Bei der Einrichtung unserer Websites setzen wir aber zukünftig auf unser Sitepackage als Single Source of Truth.

Wir freuen uns, wenn Ihr diesen Beitrag teilt.

Kommentare

Keine Kommentare gefunden.