WordPress oder Laravel: Was Sie tatsächlich bauen
Das eine ist ein Inhaltsprodukt mit einer Notausstiegsluke für Anwendungen. Das andere ein Anwendungs-Framework ohne Inhaltsprodukt. Die Frage ist, welches von beidem Sie bauen.
Die Suche, die Leute auf so eine Seite bringt, ist meist kein Vergleich. Es ist jemand mitten in einem WordPress-Projekt, das sich falsch anzufühlen begonnen hat, auf der Suche nach der Erlaubnis aufzuhören.
Nützlich ist deshalb keine Funktionstabelle, sondern ein Test, den Sie auf das anwenden können, was Sie bauen, und eine ehrliche Auskunft darüber, wo die Grenze liegt.
Meistens lautet die Antwort WordPress
Wenn das Produkt Inhalt ist - Artikel, Seiten, eine Marketing-Site, eine Publikation mit Redaktion, die ohne Entwickler arbeiten muss -, dann ist WordPress die richtige Antwort und der Rest dieser Seite gilt nicht für Sie. Es hat ein Backend, das diese Leute schon kennen, ein Plugin für das meiste, was Sie brauchen werden, Hosting für fast nichts und eine Wartungsgeschichte, die keinen Retainer verlangt.
Agenturen, die Neuentwicklungen verkaufen, haben ein offensichtliches Interesse, Ihnen etwas anderes zu erzählen. Wir verkaufen Laravel-Arbeit und erzählen Ihnen trotzdem etwas anderes: eine WordPress-Seite, die ihren Job macht, durch eine Individualanwendung zu ersetzen, ist der zuverlässigste uns bekannte Weg, sechsstellig auszugeben und etwas geringfügig Schlechteres zu bekommen.
Der Test, der es entscheidet
Nehmen Sie das Backend weg. Ist das Produkt noch das Produkt?
Bei einer Publikation nicht. Das Backend ist das Produkt. Der Wert liegt darin, dass Redakteure veröffentlichen, und alles andere existiert dafür. Bei einem Buchungssystem, einem Marktplatz, einem Dashboard, einem internen Werkzeug lautet die Antwort ja. Das Backend ist, wie jemand es konfiguriert. Das Produkt ist, was passiert, wenn ein Kunde es benutzt.
Inhalt zuerst heißt WordPress. Verhalten zuerst heißt Framework. Die meisten teuren Projekte, in die wir gerufen werden, sind Verhalten-zuerst-Produkte, die als Inhalt-zuerst begonnen wurden, weil die erste Fassung wirklich eine Broschürenseite war und niemand die Frage neu gestellt hat, als sie das nicht mehr war.
Wo WordPress tatsächlich teuer wird
Nicht bei der Performance und nicht bei der Sicherheit in dem Sinn, den die Vergleichsseiten behaupten. Beides lässt sich mit Geld und Aufmerksamkeit lösen.
Teuer wird es, wenn Geschäftsregeln in Plugins wandern.
Ein Custom Post Type als Domänenmodell. Preislogik in einem Snippet-Plugin.
Ein Freigabeprozess aus drei Plugins, von denen jedes einen Teil besitzt und
keines von den anderen weiß. An dem Punkt haben Sie eine Anwendung,
geschrieben in einem System ohne Service-Schicht, ohne testbare Naht und mit
einem Datenmodell aus wp_postmeta-Zeilen ohne Constraints darauf.
Das Erkennungszeichen ist die Frage wo lebt diese Regel. Auf einer gesunden WordPress-Seite ist das eine Inhaltsfrage mit einer Inhaltsantwort. Bei denen, zu denen wir gerufen werden, geben vier Leute vier verschiedene Antworten, und eine davon lautet "ich glaube, das steckt im Theme".
WooCommerce, eine Frage für sich
WooCommerce lohnt sich getrennt zu betrachten, denn dort geht diese Entscheidung am häufigsten schief, und zwar in beide Richtungen.
Unter ein paar Tausend Artikeln, mit normaler Steuer, normalem Versand und einem Zahlungsanbieter, den es schon unterstützt, ist WooCommerce preislich schwer zu schlagen. Bauen Sie das nicht nach.
Der falsche Behälter wird es, wenn die Bestellung aufhört, einfach zu sein.
Abonnements mit anteiliger Berechnung, B2B-Preise je Kunde, ein
Fulfilment-Prozess mit Zuständen, ein ERP mit Meinungen. Das sind
transaktionale Regeln, und wp_postmeta ist ein schlechter Ort für die
Aufzeichnung dessen, was wann passiert ist.
Geldspalten und die Entscheidungen, die sich nicht zurücknehmen lassen
gilt hier in voller Schärfe, für ein Schema, das Ihnen nicht gehört.
Wie ein Umzug aussieht, falls es dazu kommt
Nicht als Neuentwicklung. Wir haben genug davon scheitern sehen, um eine Seite darüber zu haben, warum.
Die Form, die funktioniert, lässt die Inhalte, wo sie sind. WordPress bleibt Redaktionsoberfläche und Inhaltsquelle. Die Anwendung, also der Teil mit den Geschäftsregeln, entsteht daneben in Laravel und fragt WordPress nach den Inhalten, die sie braucht. Die Redaktion behält ihr Werkzeug. Nichts geht vom Netz. Und der Umzug endet Route für Route statt an einem Launch-Datum.
Die Variante, die gar kein Umzug ist
Manchmal lautet die Antwort, dass beides weiterläuft und nichts umzieht. Die Marketing-Site bleibt auf WordPress, gepflegt von denen, die sie heute pflegen. Das Produkt ist eine Laravel-Anwendung. Beide teilen sich ein Design System und sonst nichts.
Das ärgert Leute, die ein System wollen. Es ist meist die günstigste richtige Antwort, und dass es auf einem Architekturdiagramm unordentlich aussieht, ist kein technisches Argument.
Wenn Sie hier sind, weil sich ein WordPress-Projekt wie eine Anwendung anzufühlen begonnen hat: genau das zu klären, bevor jemand sich festlegt, ist die erste Phase eines Anwendungsbaus. Und wenn die ehrliche Antwort ist, dass Laravel es auch nicht ist, sagen wir das lieber.
Liegt der Shop auf Shopify statt auf WooCommerce, ändert das Argument seine Form. Dann wiegen Sie kein CMS gegen ein Framework ab, sondern ein gemietetes Produkt gegen ein System, das Ihnen gehört, und die Grenze liegt woanders.
Dieselbe Grenze liegt bei anderen Inhaltssystemen an derselben Stelle, und sie sind nicht alle gleich. Joomla bringt Rechteverwaltung und Mehrsprachigkeit mit, für die WordPress Plugins braucht, was verändert, was zu behalten und was zu bewegen ist.
