Das Entwickler-Dilemma und die Alternative

In den letzten Lektionen haben wir gesehen, wie die Plugin-Architektur Feature für Feature blockiert. In dieser Lektion fassen wir das Muster zusammen — und schauen auf den Ausweg.

Der Teufelskreis

Es fängt harmlos an: Du installierst ein Rezept-Plugin, weil du Rezepte schön darstellen und für Google aufbereiten willst. Das Plugin funktioniert auf der Rezeptseite. Aber dann willst du mehr:

• Eine Rezeptsuche, die nach Zutaten filtert → Das Plugin kann das nicht nativ, du brauchst einen Entwickler.
• Einen Newsletter mit den neuesten Rezepten → Das Newsletter-Plugin sieht die Rezeptdaten nicht, du brauchst einen Entwickler.
• Einen Saisonkalender → Das Plugin bietet keinen an, du brauchst einen Entwickler.
• Informative Archivseiten → Das Theme kann die Plugin-Daten nicht anzeigen, du brauchst einen Entwickler.

Jede Erweiterung erfordert Custom-Entwicklung gegen die Plugin-API. Und jede Custom-Entwicklung muss bei jedem Plugin-Update geprüft und möglicherweise angepasst werden, weil sich die API ändern kann.

Die Abhängigkeit

Foodblogger werden abhängig von zwei Seiten:

Vom Plugin-Entwickler, der entscheidet, welche Features priorisiert werden. WP Recipe Maker hat andere Prioritäten als du. Wenn der Entwickler entscheidet, dass ein Feature nicht gebaut wird, hast du keine Alternative — außer Custom-Entwicklung.

Vom Webentwickler, der die Custom-Integrationen baut. Jede Integration ist ein eigenes Projekt mit eigenen Kosten. Und jedes Projekt ist an die aktuelle Plugin-Version gebunden. Ein Update, eine API-Änderung — und die Custom-Entwicklung muss angepasst werden.

Der Teufelskreis: Plugin kaufen → Entwickler für Integration bezahlen → Plugin-Update bricht die Integration → Entwickler erneut bezahlen → nächstes Feature braucht die nächste Custom-Entwicklung.

Die Alternative: Rezeptdaten als native WordPress-Inhalte

Es gibt einen anderen Weg. Statt Rezeptdaten in Plugin-eigenen Tabellen zu speichern, kann man sie als native WordPress-Inhalte behandeln:

• Rezepte als Custom Post Type — wie Beiträge und Seiten, nur für Rezepte
• Zutaten, Kochzeit, Portionen als Custom Fields — in der wp_postmeta-Tabelle, wo WordPress sie sehen kann
• Küchen, Gänge, Saisons als WordPress-Taxonomien — wie Kategorien und Tags, nur für Rezepte

Wenn Rezeptdaten im WordPress-Content-Modell liegen, funktionieren alle Standard-WordPress-Funktionen automatisch: Suche findet Zutaten, Newsletter binden Rezeptdaten ein, Archive zeigen Kochzeiten, der Saisonkalender verknüpft Rezepte mit Saisons, Hero-Images greifen auf Schwierigkeitsgrade zu.

Kein Plugin nötig. Keine Custom-Entwicklung pro Feature. Kein Teufelskreis.

Was das in der Praxis bedeutet

Das ist nicht nur Theorie. Es gibt WordPress-Umgebungen, die genau so aufgebaut sind — ohne Rezept-Plugin, mit nativen WordPress-Strukturen und deutlich besserer Performance.

Im nächsten Kurs dieser Reihe — Wie das Foodblogliebe-Theme Rezeptdaten nativ integriert — schauen wir uns an, wie das konkret umgesetzt wird und welche Features dadurch möglich werden.

Wer sich bereits für den Umstieg interessiert, findet in der Rezeptmigration-Reihe eine systematische Anleitung, wann und wie man von einem Plugin-System zu einer nativen Lösung wechselt.