corpusctl vs. WordPress: Was Sie gewinnen und was Sie aufgeben
Headless-WordPress schraubt eine API an einen Seiten-Renderer. Hier steht das ehrliche Argument für einen Wechsel, die tatsächlichen Kosten und drei gute Gründe, auf WordPress zu bleiben.
Die meisten WordPress-Seiten sollten auf WordPress bleiben.
Das ist kein rhetorischer Auftakt. WordPress betreibt einen enormen Anteil des Webs, weil es kostenlos, erweiterbar und von einem Talentpool getragen wird, den kein Konkurrent erreicht. Wenn ein Team eine Seite bearbeitet, das Theme das tut, was Sie brauchen, und der Traffic stabil ist — kostet Sie eine Migration Monate und bringt Ihnen sehr wenig.
In diesem Artikel geht es um die Fälle, in denen das aufhört, wahr zu sein.
#Headless-WordPress ist eine Nachrüstung, und man merkt es
WordPress kann Inhalte über die REST-API oder WPGraphQL offenlegen, und viele Teams liefern das erfolgreich aus. Aber es lohnt sich, präzise zu sein, was Sie da betreiben.
WordPress' Kernaufgabe ist es, eine Seite zu rendern: die Datenbank abfragen, das Theme ausführen, die Hooks feuern, HTML zurückgeben. Headless zu gehen bedeutet, diese Maschinerie zu behalten, sie bei jeder Anfrage hochzufahren und dann ihre Ausgabe zugunsten einer JSON-Antwort wegzuwerfen, die Sie separat zusammensetzen.
Sie betreiben am Ende zwei Systeme in einem Prozess. Der Admin ist ein Seiten-Renderer. Die API ist eine Schicht auf einem Seiten-Renderer. Plugins — die der Grund sind, warum Sie WordPress gewählt haben — wurden für den Seiten-Renderer geschrieben, und ein Plugin, das dem Editor ein Feld hinzufügt, fügt es nicht unbedingt der API hinzu.
corpusctl rendert niemals eine Seite. Es gibt keine Theme-Ebene, keine Template-Hierarchie, keine Hook-Reihenfolge, über die man nachdenken müsste. Der Read-Client ist die primäre Schnittstelle, kein Anhängsel.
#Was tatsächlich passiert, wenn jemand Ihren Beitrag liest
WordPress: Die Anfrage erreicht PHP, PHP fragt MySQL ab, Plugins laufen, das Theme rendert. Sie stellen dann ein Caching-Plugin davor, dann vielleicht ein CDN davor, und Sie verbringen echte Zeit mit Cache-Invalidierung — weil die Seite berechnet wird und der Cache eine Kopie einer Berechnung ist, die sich jederzeit ändern könnte.
corpusctl: Das Veröffentlichen führt die Build-Pipeline aus. Der Inhalt wird validiert, gerendert und in eine unveränderliche, hash-adressierte Datei im Objektspeicher geschrieben; das Manifest wird aktualisiert. Der Client eines Besuchers löst den Slug lokal zu einem Manifest-Shard auf und ruft dann diese Adresse aus dem nginx-Edge-Cache ab.
Weil die Adresse ein Content-Hash ist, kann dieselbe Adresse niemals andere Inhalte zurückgeben — sie ist also dreißig Tage lang ohne Invalidierungsstrategie cachebar. Das Veröffentlichen schreibt eine neue Adresse. Es gibt nichts zu leeren.
Zwei HTTP-Anfragen, beide aus dem Cache. Keine erreicht die API. Keine erreicht PostgreSQL.
Die Zahl, die daraus folgt: Besucher-Traffic belastet Ihren Schreibpfad überhaupt nicht. Ein Redakteur, der während einer Traffic-Spitze einen Entwurf speichert, konkurriert nicht mit der Spitze.
Das Plugin-Ökosystem ist WordPress' größte Stärke, und es ist derselbe Satz wie sein größtes Betriebsrisiko. Jedes Plugin ist Drittanbieter-Code, der in Ihrem Prozess mit Datenbankzugriff läuft. Eine Seite mit dreißig Plugins hat dreißig Update-Ströme und dreißig potenzielle CVEs, und das Plugin, das kaputtgeht, ist meist das, an dessen Installation sich niemand erinnert.
corpusctl hat keinen Plugin-Marktplatz — was ein echter Verlust ist, unten ehrlich aufgeführt. Was es stattdessen hat, ist ein Modul-System mit einer von der CI durchgesetzten Regel:
Jede Funktion ist ein Modul: Medien, Suche, Webhooks, SEO, GraphQL, Import, Analytics.
Module dürfen einander nicht importieren. Ein Service-Register und ein Event-Bus sind die einzigen Kanäle zwischen ihnen, und pnpm check:isolation lässt den Build fehlschlagen, wenn diese Regel verletzt wird.
Das Entfernen eines Moduls kann den Build nicht kaputt machen. Das ist der ganze Sinn der Regel.
Und eine Funktion abzuschalten zerstört nichts: disabled bewahrt die Daten und macht beim Wiederaktivieren weiter, uninstalled löscht sie mit einer doppelten Bestätigung, und ein Tarif-Downgrade setzt Module immer nur auf disabled.
WordPress Multisite existiert und funktioniert, mit den Einschränkungen, die Betreiber kennen: Plugins, die sich netzwerkweit fehlverhalten, eine gemeinsame Datenbank, ein Upgrade, das auf allen Seiten gleichzeitig landet, und ein Berechtigungsmodell, das nicht für „dieser Redakteur arbeitet an Marke eins und drei, darf aber Marke zwei nicht sehen“ entworfen wurde.
corpusctl ist mandantenfähig im Kern, neben Auth und dem Modul-Register:
Ein Panel, unbegrenzte Spaces.
Ein Nutzer trägt eine separate Rolle pro Space.
Isolation erzwungen durch PostgreSQL Row-Level Security — in der Datenbank, unterhalb der Anwendungsebene, in der ein vergessener Filter lebt.
Das Argument für RLS ist eng: Isolation auf Anwendungsebene hält bis zu der einen Abfrage, die den Filter übersprungen hat, und diese Abfrage wird irgendwann geschrieben, von jemandem in Eile, in einem Modul, das niemand genau prüft. RLS macht das Leck unterhalb des Fehlers unmöglich.
WordPress-Inhalt ist ein Beitrag oder eine Seite, erweitert mit benutzerdefinierten Feldern und einem Plugin, um sie zu verwalten. Es funktioniert, und das Modell zeigt seine Ursprünge.
In corpusctl gibt es keine eingebauten Inhaltstypen. Sie definieren sie vom Panel oder der API aus, und Felder tragen Rollen — title, slug, body —, sodass das System weiß, welches Feld die Überschrift ist, ohne davon abzuhängen, wie Sie es benannt haben. Lokalisierung erfolgt pro Feld. Jeder Datensatz ist versioniert, ältere Versionen sind wiederherstellbar, und die Veröffentlichung kann geplant werden.
Im Frontend kommen Block-Renderer mit null Standard-Styling. Keine einzige Zeile CSS. Jeder Blocktyp ist überschreibbar, und ein unbekannter Blocktyp wird elegant übersprungen, statt einen Fehler zu werfen. Der Kern-Renderbaum ist framework-agnostisch; React-, Vue- und Next.js-Adapter sitzen als dünne Schichten obendrauf.
Vergleichen Sie das mit einem WordPress-Theme, das eine Designentscheidung ist, die Sie erben und dann überschreiben.
Personalgewinnung. Sie finden jemanden, der WordPress kennt, in jeder Stadt, zu jedem Budget, nächste Woche. Das können Sie für corpusctl nicht, und etwas anderes zu behaupten wäre albern.
Das Ökosystem. Formulare, Buchungen, Mitgliedschaften, E-Commerce, SEO-Tooling, Migrations-Utilities — ein Plugin existiert, ist praxiserprobt und kostet 59 $. Das Äquivalent gegen eine API zu bauen ist ein Projekt.
Es ist kostenlos. WordPress-Core kostet nichts und hat es immer getan. Wenn das Budget die bindende Einschränkung ist, beendet das die Diskussion.
Fügen Sie einen vierten, weniger bequemen hinzu: corpusctl ist jung. SSO und ein vertragliches SLA stehen auf der Roadmap, was die höfliche Art ist zu sagen, dass es sie noch nicht gibt. Es gibt keinen Marktplatz und kein globales CDN — der Edge-Cache ist Single-Region. Wenn Ihre Beschaffungs-Checkliste eines davon enthält, endet dieser Vergleich hier.
Bleiben Sie auf WordPress, wenn ein Team eine Seite bearbeitet, das Ökosystem echte Arbeit für Sie leistet oder das Budget entscheidet.
Wechseln Sie zu corpusctl, wenn Sie mehrere Projekte, mehrere Frontends oder eine Plugin-Fläche betreiben, die Sie nicht mehr auditieren können — und Sie möchten, dass der Lesepfad aufhört, ein Caching-Problem zu sein.
Migrieren? Das Import-Modul liest einen WordPress-WXR-Export: Beiträge, Seiten, Tags und Medien. Feldrollen werden zugeordnet, und der Textkörper wird in das Blockmodell konvertiert. Planen Sie echte Zeit für alles ein, was ein Plugin tat — diese Logik lässt sich nicht exportieren.
corpusctl vs. Directus: eine Content-Plattform gegenüber einem Datenbank-Wrapper
Directus umhüllt Ihre SQL-Datenbank und sperrt SSO hinter einen 499-$-Tarif. corpusctl liefert den gesamten Content-Pfad — Build, Edge-Cache, Module. Verglichen.