WordPress selbst ist nicht das Problem.
Die Installation auf einem frischen Debian-Server läuft in unter zwanzig Minuten durch. WooCommerce ist drei Klicks. Lulu — für den direkten Buchverkauf — verbunden, erstes Produkt sichtbar. InvoiceNinja verbunden. Sprachplugin installiert. Alles technisch einwandfrei, alles in kurzer Zeit erledigt.
Und dann fangen die eigentlichen Fragen an.
Jede Anforderung, ein Plugin. Jedes Plugin, ein Kompromiss.
WooCommerce beherrscht Mehrsprachigkeit nicht von Haus aus. Dafür gibt es ein Plugin — das aber seinerseits WooCommerce nicht vollständig abdeckt. Ein weiteres Plugin löst diese Lücke, gegen Aufpreis.
Mehrere Währungen? WooCommerce zeigt genau zwei Preise an. Wer mehr braucht, erwirbt eine Erweiterung. Die installierte Lösung bringt ein vollständiges Ökosystem mit: automatische Wechselkursabfragen, Konverter, Anzeigeoptionen. Für einfache Preisangaben in drei Währungen ist das erheblicher Overhead.
Lulu zeigt das Buchcover in der Shop-Übersicht quadratisch beschnitten — aus der Mitte des Bildes. Buchcover sind im Hochformat. Das Ergebnis ist ein unbrauchbarer Ausschnitt. Lösbar, aber eine weitere Baustelle.
InvoiceNinja lässt sich verbinden — technisch korrekt. Was diese Verbindung leistet, ist ein Codeschnipsel zum Einbetten, keine echte Rechnungsintegration zwischen den beiden Systemen. Wer WooCommerce-Bestellungen direkt in InvoiceNinja als Rechnung haben möchte, löst das anders, oder mit einem weiteren Plugin.
Nach der Installation des Sprachplugins war die Shop-Seite leer. Produkte nicht sichtbar. Irgendwo hatte ein Plugin ein anderes Plugin überschrieben. Welches, in welcher Reihenfolge, warum — nicht sofort erkennbar.
Das eigentliche Problem
WordPress ist für Inhalte gebaut, nicht für präzise Kontrolle. Das Plugin-Ökosystem folgt dieser Logik: Jedes Plugin löst ein Problem vollständig — mit allem was dazugehört, ob man es braucht oder nicht.
Wer ein einziges Feature braucht, bekommt ein Produkt. Wer drei Features braucht, bekommt drei Produkte, die gelegentlich nicht wissen, dass die anderen beiden existieren. Das Theme, das diesen Stapel visuell zusammenhält, würde nach vier Stunden Arbeit immer noch angepasst werden müssen.
Der Zeitaufwand für eine sinnvolle Einrichtung wäre beherrschbar gewesen. Die Frage ist, ob das Ergebnis kontrollierbar bleibt — oder ob man ein System betreibt, das man nur teilweise versteht.
Was stattdessen funktioniert
Dieselben Anforderungen — Buchverkauf, mehrere Sprachen, mehrere Währungen, Rechnungsstellung — lassen sich mit kleinen Werkzeugen abbilden, die genau das tun was nötig ist. Kein Plugin-Ökosystem, keine unsichtbaren Abhängigkeiten, keine leere Shop-Seite nach einem Update.
Das ist kein Argument gegen WordPress. Für Inhaltswebsites mit Standardanforderungen ist es eine pragmatische Wahl. Für Anwendungen die Kontrolle und Nachvollziehbarkeit brauchen, ist das Plugin-Modell strukturell das falsche Werkzeug.
