Rezeptdaten als native WordPress-Inhalte

Das Foodblogliebe-Theme trifft eine grundlegende Architekturentscheidung anders als Rezept-Plugins: Rezeptdaten werden nicht in eigenen Tabellen gespeichert, sondern im WordPress-Content-Modell.

Rezepte als Custom Post Type

In WordPress gibt es verschiedene Inhaltstypen: Beiträge, Seiten, Medien. Das Theme fügt einen eigenen hinzu: Rezepte. Technisch ist das ein Custom Post Type — er wird in derselben wp_posts-Tabelle gespeichert wie Beiträge und Seiten.

Das bedeutet: Jedes WordPress-Tool, das auf wp_posts zugreift, sieht automatisch auch Rezepte. Die Suche, die REST API, Newsletter-Plugins, RSS-Feeds — alles funktioniert ohne Anpassung.

Rezeptfelder als Custom Fields

Kochzeit, Portionenanzahl, Schwierigkeitsgrad, Nährwerte, Zutatenliste, Anleitungsschritte — all das sind Custom Fields, die in der wp_postmeta-Tabelle liegen. Nicht serialisiert, nicht verschlüsselt, nicht in einer eigenen Tabelle — sondern als einzelne, abfragbare Felder.

Das ist der entscheidende Unterschied zu Rezept-Plugins. Wenn die Kochzeit als eigenes Meta-Feld gespeichert ist, kann WordPress sie abfragen: „Zeige alle Rezepte unter 30 Minuten." Wenn sie in einem serialisierten Array steckt, geht das nicht.

Taxonomien für Kategorisierung

Küchen (italienisch, asiatisch, deutsch), Gänge (Vorspeise, Hauptgericht, Dessert), Saisons (Frühling, Sommer, Herbst, Winter), Schwierigkeitsgrade — all das sind WordPress-Taxonomien. Sie funktionieren wie Kategorien und Tags: Man weist sie einem Rezept zu und WordPress erstellt automatisch Archivseiten, Filtermöglichkeiten und Verknüpfungen.

Rezept-Plugins nutzen oft eigene Taxonomie-Systeme, die zwar ähnlich aussehen, aber nicht mit WordPress-Standard-Funktionen kompatibel sind. Das Theme nutzt echte WordPress-Taxonomien — deshalb funktioniert alles, was WordPress mit Taxonomien kann, auch für Rezepte.

Der Vergleich

Die folgenden Lektionen zeigen, was dieser Architekturunterschied in der Praxis bedeutet.