Wie Rezept-Plugins Daten speichern

WordPress speichert Inhalte in zwei zentralen Tabellen: wp_posts für den Inhalt und wp_postmeta für zusätzliche Felder. Jedes Plugin, jedes Theme und jede WordPress-Funktion — von der Suche über Archive bis zu Newsletter-Systemen — greift auf diese Tabellen zu. Das ist das WordPress-Content-Modell.

Rezept-Plugins umgehen dieses Modell. Jedes auf seine eigene Art, aber das Ergebnis ist immer dasselbe: Die Rezeptdaten landen an einem Ort, den WordPress nicht kennt.

WP Recipe Maker

WP Recipe Maker ist das umfangreichste Rezept-Plugin am Markt. Es legt eigene Datenbanktabellen an: wprm_ingredients für Zutaten, wprm_instructions für Anleitungsschritte. Zusätzlich speichert es Rezepte als eigenen Custom Post Type wprm_recipe, der zwar technisch in wp_posts liegt, aber nicht wie ein normaler Beitrag behandelt wird — er ist an den übergeordneten Blogbeitrag geknüpft und taucht in keiner Standard-WordPress-Abfrage auf.

Das bedeutet: Die Zutaten eines Rezepts liegen in einer Tabelle, die WordPress nicht durchsuchen kann. Die Anleitungsschritte liegen in einer anderen. Der Rezeptname liegt wieder woanders. Für WP Recipe Maker kein Problem — das Plugin hat seine eigene Logik. Für alles andere in WordPress ein großes Problem.

Recipe Card Blocks

Recipe Card Blocks gehört zur neueren Generation und speichert Rezeptdaten direkt im Gutenberg-Block als JSON-Attribute. Das klingt modern, hat aber denselben Effekt: Die Daten stecken serialisiert im Block-Content des Beitrags. WordPress sieht einen Textblock mit JSON — nicht einzelne, durchsuchbare Felder für Zutaten, Kochzeit oder Portionen.

WP Tasty (Tasty Recipes)

WP Tasty legt Rezeptdaten als serialisiertes Array in der wp_postmeta-Tabelle ab. Technisch liegen die Daten damit in WordPress — aber serialisiert. Das heißt: Zutatenliste, Anleitungsschritte, Kochzeit und Portionen sind in einem einzigen, verschlüsselten Textblock zusammengefasst. WordPress kann diesen Block nicht aufschlüsseln. Eine Abfrage wie „Zeige alle Rezepte mit weniger als 30 Minuten Kochzeit" ist unmöglich.

Cooked Pro

Cooked Pro nutzt Shortcodes in Kombination mit eigenen Custom Post Types. Die Rezeptdaten liegen in einem eigenen cp_recipe Post Type und werden über Shortcodes in den Blogbeitrag eingebettet. Auch hier: Die Daten sind für WordPress-Standardfunktionen unsichtbar.

WP Delicious

WP Delicious speichert Rezeptdaten als eigenen Custom Post Type mit einer Mischung aus Post-Meta und eigenen Tabellen. Optisch eines der schönsten Plugins — aber unter der Haube eine Kombination verschiedener Technologien, die von außen schwer zugänglich sind.

Das gemeinsame Muster

Unabhängig vom konkreten Plugin: Rezeptdaten landen immer außerhalb des Standard-WordPress-Content-Modells. Das ist keine Nachlässigkeit der Plugin-Entwickler — es ist eine bewusste Architekturentscheidung. Eigene Tabellen bieten Flexibilität und Unabhängigkeit vom Theme. Aber sie brechen die Integration mit WordPress.

Die Konsequenz: Alles, was in WordPress auf wp_posts und wp_postmeta zugreift — Suche, Newsletter, Archive, REST API, Vorschauen — sieht die Rezeptdaten nicht. Und das betrifft praktisch jede Funktion, die über die einzelne Rezeptseite hinausgeht.

In den folgenden Lektionen schauen wir uns an, was das konkret bedeutet.

Wer sich für die Preise, Performance-Scores und Feature-Vergleiche der einzelnen Plugins interessiert, findet eine aktuelle Übersicht im Blogpost Alle wichtigen Fragen und Antworten rund um Rezept-Plugins für WordPress.