Was unterscheidet OrgaPress von TYPO3, Drupal, Joomla, Wix, Webflow & Co?
TYPO3, Drupal, Joomla, Wix und Webflow können sehr gute Websites hervorbringen. Trotzdem verfolgen sie grundverschiedene Architektur- und Betriebsmodelle. Genau darin liegt der entscheidende Unterschied zu OrgaPress. Nach mehr als 20 Jahren Arbeit mit unterschiedlichen Content-Management-Systemen interessiert uns weniger, welches CMS auf dem Papier die längste Feature-Liste besitzt. Entscheidend ist, welche Architektur über viele Jahre hinweg schnell publizieren, sicher aktualisiert und trotzdem individuell erweitert werden kann – ohne dass aus jedem größeren Versionssprung ein neues Entwicklungsprojekt wird.
TYPO3 war im deutschsprachigen Raum lange besonders attraktiv, weil eine starke Community, professionelle Agenturen und eine breite Akzeptanz bei Institutionen, Verbänden und öffentlichen Einrichtungen vorhanden waren. Drupal und Joomla verfolgen ebenfalls leistungsfähige Open-Source-Ansätze. Wix und Webflow lösen ein anderes Problem: Sie bringen visuelles Bauen und Publishing in eine integrierte Plattform. OrgaPress kombiniert bewusst Elemente aus beiden Welten: die offene und über Jahrzehnte gewachsene WordPress-Basis mit einem kontrollierten Plattformstack aus eigener Entwicklung und einem visuellen Frontend-Workflow.
Der Unterschied beginnt nicht beim Editor, sondern bei der Architektur
Warum wir bei TYPO3 irgendwann an eine Grenze kamen
TYPO3 hat im deutschen Enterprise- und Institutionsumfeld zweifellos Geschichte geschrieben. Das System ist leistungsfähig, granular konfigurierbar und besitzt professionelle Release- und Supportstrukturen. Genau diese Stärke hat jedoch eine Kehrseite: Eine TYPO3-Installation ist häufig nicht einfach nur ein CMS, sondern eine individuell integrierte Softwarelandschaft aus Core, Site Package, Extensions, TypoScript, Templates und projektspezifischem Code. Je älter und individueller eine Instanz wird, desto relevanter werden Upgradeplanung und Extension-Kompatibilität.
Das ist im System selbst sichtbar. TYPO3 stellt einen Extension Scanner bereit, der Extension-Code auf entfernte oder veraltete Core-APIs untersucht. Die Dokumentation unterscheidet ausdrücklich zwischen Deprecations und Breaking Changes und beschreibt Migrationspfade für Entwickler. Das ist professionelles Lifecycle-Management – bedeutet aber eben auch, dass ein Major-Upgrade Anpassungen an eigenem oder fremdem Extension-Code auslösen kann.
Jede zusätzliche Abhängigkeit ist eine weitere Variable im Lebenszyklus
Drupal und Joomla sind moderner geworden – der Lifecycle bleibt
Drupal ist technisch modern und für komplexe Datenmodelle, Integrationen und strukturierte Inhalte hervorragend geeignet. Gleichzeitig zeigt der offizielle Upgrade-Status-Prozess, wie ernst das Projekt Major-Kompatibilität nimmt: Contrib- und Custom-Code werden auf APIs geprüft, die in der nächsten Major-Version nicht mehr vorhanden sind. Für aktuelle Major-Upgrades sollen Module und eigener Code deshalb vorab auf Kompatibilität und Deprecations untersucht werden.
Bei Joomla ist das Muster ähnlich. Die offiziellen Upgrade-Leitfäden sehen ausdrücklich die Prüfung von Drittanbieter-Erweiterungen vor. Andere Systeme versuchen historische Architekturprobleme durch Modernisierung zu lösen. Ein anschauliches Beispiel ist PrestaShop: Die aktuelle Entwicklerdokumentation beschreibt parallel Legacy-, Adapter-, Core- und Symfony-Schichten. Eine solche Modernisierung kann technisch sinnvoll sein, zeigt aber auch das Grundproblem etablierter Systeme: Alte Komplexität verschwindet nicht automatisch, nur weil eine moderne Engine darunter oder daneben eingeführt wird.
Warum WordPress für uns gerade wegen seiner Rückwärtskompatibilität interessant wurde
WordPress verändert sich durchaus. Neue Editoren, APIs, Security-Fixes und Funktionen kommen kontinuierlich hinzu. Der entscheidende Unterschied ist die Entwicklungskultur des Cores. Im WordPress-Core-Handbook wird Backward Compatibility ausdrücklich als treibende Philosophie beschrieben. Öffentliche APIs sollen nach Möglichkeit über Releases hinweg erhalten bleiben, damit Plugins und Themes nicht bei jedem Versionssprung neu gebaut werden müssen. Für uns war genau diese Beharrlichkeit ein strategischer Vorteil.
Hinzu kommt die Größe des Ökosystems. Das offizielle WordPress Plugin Directory listet heute mehr als 70.000 kostenlose Plugins. Eine solche Verbreitung erhöht den Druck, bestehende Schnittstellen nicht leichtfertig zu brechen. WordPress ist damit ebenfalls an seine Architektur gebunden – aber genau das wollten wir: eine bekannte, rückwärtskompatible Basis, auf der wir einen eigenen, ähnlich kontrollierten Stack entwickeln konnten. Dieser Stack ist OrgaPress.
Nicht weniger Technik – mehr Technik unter eigener Kontrolle
Wix und Webflow lösen das Redaktionsproblem überzeugend – aber mit einem anderen Plattformmodell
Wix und Webflow zeigen sehr deutlich, warum visuelles Arbeiten so attraktiv ist. Der Wix Editor erlaubt Drag-and-Drop direkt auf der Seite. Webflow verfolgt ebenfalls einen visual-first Ansatz, bei dem Teams Inhalte im visuellen Canvas bearbeiten können. Diese Grundidee teilen wir: Redakteure sollten eine Seite nicht ausschließlich über abstrakte Backend-Felder zusammensetzen müssen.
Der Unterschied liegt beim Eigentums- und Betriebsmodell. Wix erklärt selbst, dass klassische Wix-Websites auf Wix-Infrastruktur betrieben werden und Templates nicht als unabhängige Website exportiert werden können. Webflow bietet auf bestimmten Plänen einen Code-Export, weist jedoch darauf hin, dass unter anderem CMS-Funktionalität, User Accounts und Ecommerce nicht vollständig Bestandteil dieses Exports sind. OrgaPress verfolgt deshalb einen anderen Ansatz: die Bedienlogik eines visuellen Baukastens, aber auf einer WordPress-basierten Plattform, deren technische Basis kontrolliert betrieben und erweitert werden kann.
Wix / Webflow
Der visuelle Editor ist Teil einer eng integrierten Plattform. Infrastruktur, Publishing und Plattformfunktionen werden weitgehend vom Anbieter abstrahiert. Das ist bequem, bedeutet aber auch eine stärkere Bindung an dessen Betriebsmodell.
OrgaPress
Der visuelle Editor sitzt auf einer WordPress-basierten Publishing-Plattform. Ziel ist ein ähnlich direkter Redaktionsworkflow bei gleichzeitig kontrollierbaren Templates, Modulen, Schnittstellen und kundenspezifischem Code.
Der redaktionelle Bruch: vom Backend-CMS zur Publishing Engine
Gerade unsere TYPO3-Erfahrung hat gezeigt, wie unterschiedlich ein CMS aus Entwickler- und Redaktionssicht wirken kann. TYPO3 besitzt heute Frontend-Editing-Lösungen, diese werden jedoch als Erweiterungen realisiert und verbinden sichtbare Seitenelemente technisch mit Backend-Records und Berechtigungen. Ein mit Wix oder Webflow vergleichbarer visueller Seitenbaukasten ist damit nicht das grundlegende Bedienmodell des TYPO3-Cores.
Mit OrgaPress haben wir diesen Bruch bewusst aufgelöst. Seiten lassen sich über das Frontend aus wiederverwendbaren Elementen zusammensetzen, verschieben und als Templates nutzen. Standardisierte Komponenten verhindern, dass jede Landingpage zu einem Entwicklungsprojekt wird. Gleichzeitig bleibt die Plattform programmierbar. Darin liegt für uns die entscheidende Effizienz: visueller NoCode-Workflow für wiederkehrende Aufgaben und eine saubere Entwicklungs-Pipeline für echte Sonderanforderungen.
Standardanforderungen laufen durch einen wiederholbaren Publishing-Pfad
Extensions sind nicht das Problem – unkontrollierte Abhängigkeiten sind es
Ein Plugin- oder Extension-System ist grundsätzlich eine Stärke. Das Problem entsteht, wenn für zentrale Standardfunktionen zahlreiche Hersteller verantwortlich sind und jede Komponente eigene Lizenz-, Update- und Supportbedingungen mitbringt. Wir haben selbst erlebt, wie ein größerer Plugin-Anbieter übernommen wurde und anschließend sein Lizenzmodell kurzfristig grundlegend änderte. Aus einer technischen Abhängigkeit wurde plötzlich eine kaufmännische Abhängigkeit – und mehrere Kunden mussten auf eine Entscheidung reagieren, auf die sie keinen Einfluss hatten.
Aus solchen Erfahrungen entstand unsere Strategie, zentrale Anforderungen in wenigen miteinander abgestimmten OrgaPress-Komponenten abzubilden. Third-Party-Plugins sind weiterhin möglich und für bestimmte Spezialfälle sinnvoll. Wir verifizieren sie jedoch und beobachten sie langfristig, um Veränderungen bei Wartung, Security und Supply Chain früh zu erkennen. Laut aktueller OrgaPress-Unternehmensdarstellung läuft die Lösung inzwischen auf mehr als 50 Kundeninstanzen. Für uns ist genau dieser reale Langzeitbetrieb der wichtigere Test als eine theoretische Feature-Matrix.
Unkontrollierter Plugin-Stack
Viele Hersteller, unterschiedliche Verträge, separate Release-Zyklen und schwer vorhersehbare Änderungen bei Eigentümer, Lizenz oder Produktstrategie.
Kuratierter Plattformstack
Wenige Standardkomponenten aus eigener Verantwortung; Third Parties nur dort, wo sie fachlich sinnvoll sind und langfristig überwacht werden können.
Standardisierung, wo sie sich lohnt
Consent, Security, SEO-Grundlagen, Frontend-Komponenten oder Publishing-Workflows sind keine exotischen Anforderungen. Wenn dieselben Probleme in vielen Projekten auftreten, lohnt sich eine gemeinsame Produktlösung. Verbesserungen können einmal entwickelt und anschließend kontrolliert auf viele Instanzen übertragen werden.
Individualität, wo sie Wert schafft
CRM-Anbindungen, Ausgabe-Schnittstellen, besondere Frontend-Module und fachliche Prozesse gehören nicht zwangsläufig in einen allgemeinen Core. Solche Anforderungen entwickeln wir in gesonderten Kunden-Pipelines. So bleibt Individualität möglich, ohne den wiederverwendbaren Standardstack für alle Kunden aufzublähen.
Was ändert agentische KI an diesem Vergleich?
KI-Website-Builder verschieben die Messlatte erneut. Eine einzelne Landingpage aus einem Prompt zu erzeugen, ist heute kein außergewöhnliches Problem mehr. Die schwierigere Frage beginnt dort, wo aus zehn Seiten mehrere hundert oder tausend werden: Wie bleiben Templates, Navigation, Metadaten, interne Verlinkung, Mehrsprachigkeit und Markenlogik konsistent? Wie verhindert man automatisierten Content-Müll, doppelte Inhalte oder skalierenden SEO-Missbrauch?
Deshalb behandeln wir KI in OrgaPress als zusätzliche Publishing-Schicht und nicht als Ersatz für das CMS. Auf Basis bestehender Templates können komplette Seitenstrukturen aus Inhalten oder Spracheingaben erzeugt werden. In Enterprise-Szenarien lässt sich dieser Ablauf agentisch automatisieren, während Governance, SEO und Freigaben weiterhin den Rahmen bilden. Die Erfahrungen, die zu diesem Ansatz geführt haben, beschreiben wir ausführlicher im Beitrag WordPress für den Einsatz im Unternehmen – So entstand OrgaPress.
Wo die Systeme unterschiedliche Prioritäten setzen
Fazit: OrgaPress versucht nicht, jedes CMS nachzubauen
TYPO3, Drupal und Joomla sind leistungsfähige Open-Source-Systeme. Ihr Architekturmodell gibt Entwicklern viel Kontrolle, bringt bei langfristig gewachsenen Installationen aber einen Lifecycle rund um Extensions, Deprecations und Major-Upgrades mit sich. Wix und Webflow gehen in die andere Richtung: Sie abstrahieren viel Technik und liefern eine hervorragende visuelle Arbeitsweise, binden zentrale Funktionen dafür enger an ihre Plattformmodelle. Beide Ansätze sind für bestimmte Projekte sinnvoll.
OrgaPress ist aus unserer Projektpraxis zwischen diesen Polen entstanden. Wir wollten die Rückwärtskompatibilität, Verbreitung und Erweiterbarkeit von WordPress als Fundament behalten. Darum herum haben wir einen kontrollierten Stack aufgebaut, der wiederkehrende Enterprise-Anforderungen vereinheitlicht. Redaktionell soll das System so direkt funktionieren wie ein moderner Website-Baukasten; technisch sollen Daten, Templates, Plugins und individuelle Erweiterungen trotzdem in einer kontrollierbaren Plattform verbleiben.
Aus einem klassischen CMS wird damit für uns eine Publishing Engine: Standardanforderungen sind hochgradig wiederholbar, Spezialanforderungen bleiben programmierbar und KI kann auf denselben stabilen Strukturen aufsetzen. Nach mehr als 20 Jahren mit unterschiedlichen CMS-Generationen ist genau diese Kombination der Grund, warum wir OrgaPress entwickelt haben und bis heute selbst einsetzen. Mehr über den technologischen Hintergrund und das Team finden Sie unter Über uns.
