Filter für Contao 5 mit Rocksolid Custom Elements

Referenzen nach Branche, Team nach Standort, Downloads nach Thema – sobald eine Übersicht wächst, wünscht sich die Redaktion Filterbuttons. Der Reflex führt oft zu einer JavaScript-Bibliothek wie Filterizr; nötig ist die nicht: Contao 5 und die Rocksolid Custom Elements reichen völlig aus.

Der Ansatz kombiniert drei Zutaten: ein zusätzliches Feld im DCA, in dem Redakteure Kategorien vergeben, Sprachdateien für die Labels und einen RSCE-Wrapper, dessen Skript die Filterbuttons automatisch erzeugt. Schritt für Schritt sieht das so aus – und wer ganz ohne Erweiterung arbeiten will, findet im Update am Ende zwei Bordmittel-Varianten.

Zuerst wird im DCA der Inhaltselemente ein Feld data_category definiert. Dieses Feld dient als Datenattribut, mit dem später die Filterung funktioniert.

Damit wird das Eingabefeld Daten-Kategorie automatisch allen Inhaltselementen hinzugefügt.

Das Label für das Feld wird über die Sprachdateien definiert:

Dadurch erscheint das Feld mit einer passenden Beschreibung im Backend.

Nun wird ein RSCE-Wrapper angelegt, der als Container für alle zu filternden Inhalte dient.

• Backend: Redakteure können jedem Inhaltselement eine oder mehrere Kategorien (kommasepariert) zuweisen.
• Frontend: Die JavaScript-Routine liest diese Kategorien aus, generiert automatisch die Filterbuttons und blendet Inhalte dynamisch ein oder aus.
• Vorteil: Keine zusätzliche Erweiterung (außer RSCE) notwendig, einfache Integration in bestehende Contao-Projekte.

Kurz gesagt: Statt eines RSCE-Wrappers dienen zwei einfache Contao-Inhaltselemente als Klammer – oder, noch schlanker, ein eigener Elementtyp. Das Datenfeld data_category aus dem ersten Teil bleibt unverändert; nur der Container wird ausgetauscht.

Variante A: Bordmittel – zwei eigene Elementtypen

// contao/dca/tl_content.php
$GLOBALS['TL_DCA']['tl_content']['palettes']['filter_start'] =
    '{type_legend},type;{filter_legend},filterCategories;{invisible_legend:hide},invisible';
$GLOBALS['TL_DCA']['tl_content']['palettes']['filter_stop'] =
    '{type_legend},type;{invisible_legend:hide},invisible';

$GLOBALS['TL_DCA']['tl_content']['fields']['filterCategories'] = [
    'inputType' => 'text',
    'eval'      => ['tl_class' => 'w50', 'maxlength' => 255],
    'sql'       => "varchar(255) NOT NULL default ''",
];

// config/config.yaml – Elementtypen registrieren
contao:
  content_elements:
    filter_start: { category: filter }
    filter_stop:  { category: filter }

{# templates/content_element/filter_start.html.twig #}
<div class="filter" data-filter>
  <div class="filter__buttons">
    {% for kategorie in content.filterCategories|split(',') %}
      <button type="button" data-filter-btn="{{ kategorie|trim }}">
        {{ kategorie|trim }}
      </button>
    {% endfor %}
    <button type="button" data-filter-btn="*" aria-pressed="true">Alle</button>
  </div>
  <div class="filter__items">

{# templates/content_element/filter_stop.html.twig #}
  </div>
</div>

Das Filter-Skript – ohne Bibliothek

document.querySelectorAll("[data-filter]").forEach((box) => {
  const items   = box.querySelectorAll("[data-category]");
  const buttons = box.querySelectorAll("[data-filter-btn]");

  buttons.forEach((btn) => {
    btn.addEventListener("click", () => {
      const wahl = btn.dataset.filterBtn;

      buttons.forEach((b) => b.setAttribute("aria-pressed", b === btn));

      items.forEach((el) => {
        const kategorien = (el.dataset.category || "")
          .split(",").map((s) => s.trim());
        const sichtbar = wahl === "*" || kategorien.includes(wahl);
        el.hidden = !sichtbar;   // hidden statt display:none – Screenreader folgen
      });
    });
  });
});

Variante B: ganz ohne JavaScript

Für einfache Fälle genügt sogar reines CSS: Die Kategorien werden zu Ankern, die Auswahl steuert ein :target-Selektor oder ein verstecktes Radio-Element. Vorteil: funktioniert auch ohne JavaScript und ist barrierefrei per Tastatur bedienbar. Nachteil: keine Mehrfachauswahl.

/* Radio-basierte Filterung, komplett ohne Skript */
.filter input[type="radio"] { position: absolute; opacity: 0; }
.filter__item { display: none; }

#f-alle:checked    ~ .filter__items .filter__item,
#f-webdesign:checked ~ .filter__items [data-category~="webdesign"],
#f-seo:checked     ~ .filter__items [data-category~="seo"] {
  display: block;
}

Welche Variante wann?

• RSCE-Wrapper: sinnvoll, wenn die Erweiterung ohnehin im Projekt steckt und die Redaktion sie kennt.
• Eigene Elementtypen (Variante A): die beste Wahl für langlebige Projekte – keine zusätzliche Abhängigkeit, volle Kontrolle über das Template, updatesicher über LTS-Sprünge hinweg.
• CSS-Lösung (Variante B): ideal für kleine Übersichten mit wenigen Kategorien, etwa Referenzen oder Teamseiten.

Und ein Hinweis, der in keiner der Varianten fehlen darf: Elemente per hidden oder display: none auszublenden, entfernt sie auch für Screenreader – das ist beim Filtern gewollt. Nicht gewollt ist es, wenn die aktive Auswahl nirgends angesagt wird. Ein aria-live="polite"-Bereich mit „12 Einträge angezeigt" löst das Problem in einer Zeile.

Ein Filter ist am Ende ein Datenattribut und eine Handvoll Zeilen Skript – keine Aufgabe, für die es eine externe Bibliothek braucht. Die RSCE-Variante ist schnell eingerichtet und für Redaktionen angenehm, die eigenen Elementtypen aus dem Update sind die langlebigere Wahl ohne zusätzliche Abhängigkeit, und für kleine Übersichten genügt sogar reines CSS.

Welcher Weg auch gewählt wird: Das Prinzip bleibt gleich, der Austausch fällt später leicht. Wie sich das Ergebnis anfühlt, zeigt die Referenzen-Übersicht auf der Beispiel-Website des Theme Ultimate – dort läuft genau dieser Filter im Alltag.