Saisonkalender, Rezept-Heroes und Archivseiten, die es nicht gibt
Bisher haben wir uns angeschaut, welche bestehenden WordPress-Funktionen durch die Plugin-Architektur eingeschränkt werden: Suche, Newsletter, Vorschauen, Schema...
Bisher haben wir uns angeschaut, welche bestehenden WordPress-Funktionen durch die Plugin-Architektur eingeschränkt werden: Suche, Newsletter, Vorschauen, Schema. In dieser Lektion geht es um Features, die es schlicht nicht gibt — weil sie technisch nicht umsetzbar sind, wenn Rezeptdaten in Plugin-Tabellen stecken.
Warum es keinen funktionierenden Saisonkalender gibt
Ein Saisonkalender für einen Foodblog würde zeigen, welche Rezepte zur aktuellen Jahreszeit passen — Spargelrezepte im Frühling, Kürbisrezepte im Herbst, Plätzchenrezepte im Dezember. Dafür braucht der Kalender Zugriff auf die Zutaten oder die Saison-Zuordnung der Rezepte.
Rezept-Plugins speichern Saison-Informationen — wenn überhaupt — in eigenen Taxonomien oder Tabellen. WordPress-Archive und Template-Funktionen können auf diese Daten nicht zugreifen. Ein automatischer Saisonkalender, der zur richtigen Jahreszeit die passenden Rezepte anzeigt, ist mit Plugin-Daten nicht realisierbar.
Kein einziges gängiges Rezept-Plugin bietet einen Saisonkalender als Feature an. Der Grund ist nicht fehlendes Interesse der Entwickler, sondern die Architektur: Ein Saisonkalender müsste Rezeptdaten mit WordPress-Template-Funktionen verknüpfen — und genau das verhindert die Plugin-Architektur.
Wie ein Saisonkalender auf Basis nativer WordPress-Daten funktionieren kann, zeigt der Kurs Saisonkalender im Foodblogliebe Theme.
Warum es keine Rezept-Heroes gibt
Hero-Images sind die großen Bilder, die auf Übersichtsseiten, in der Startseite oder in Social-Media-Posts die Aufmerksamkeit auf sich ziehen. Ein gutes Rezept-Hero zeigt nicht nur ein Foto, sondern auch Informationen: Kochzeit, Schwierigkeitsgrad, Portionenanzahl, Zutatenanzahl.
Um solche Heroes zu generieren, braucht das System Zugriff auf die Rezeptdaten. Wenn die Kochzeit in einer Plugin-Tabelle steckt und die Portionenanzahl in einer anderen, kann kein Theme und kein Page Builder diese Informationen automatisch in ein Hero-Image einfügen.
Das Ergebnis: Hero-Images auf Plugin-basierten Blogs zeigen nur das Rezeptfoto — ohne die Zusatzinformationen, die Leser auf den ersten Blick erwarten. Oder man baut jedes Hero von Hand, was bei 200 oder 500 Rezepten nicht tragbar ist.
Warum Archivseiten nur den Blogtext zeigen
WordPress-Archivseiten (z.B. „Alle Rezepte in der Kategorie Pasta") zeigen standardmäßig den Beitragstitel, den Excerpt und das Beitragsbild. Das sind die Daten aus wp_posts.
Was sie nicht zeigen können: Kochzeit, Schwierigkeitsgrad, Portionenanzahl, Zutatenliste — weil diese Informationen in den Plugin-Tabellen liegen. Eine Archivseite, die auf einen Blick zeigt „25 Minuten, einfach, 4 Portionen", ist mit Plugin-Daten nicht automatisch generierbar.
Manche Plugins bieten eigene Archivseiten an, aber diese sind in der Regel separate Systeme mit eigenem Design, das nicht zum Theme passt. Eine nahtlose Integration in die bestehende Seitenstruktur ist nicht vorgesehen.
Das Muster
Saisonkalender, Rezept-Heroes, informative Archivseiten — all das sind Features, die Rezeptdaten außerhalb der einzelnen Rezeptseite benötigen. Und genau das ist die Schwachstelle der Plugin-Architektur. Solange Rezeptdaten in eigenen Tabellen liegen, kann jedes neue Feature nur über Custom-Entwicklung gegen die Plugin-API entstehen.
Das ist kein theoretisches Problem. Es ist der Grund, warum die meisten Foodblogs trotz hunderten veröffentlichter Rezepte keine vernünftige Rezeptübersicht, keinen Saisonkalender und keine informativen Archivseiten haben.
Wenn du diese Lektion gelesen hast, markiere sie als abgeschlossen.
