UDS wurde ein auf Dokumenten basierendes System geschaffen und orientiert sich bereits seit 2001 auf den W3C Standards und damit ISO-Normen für HTML, XML, XSD, XSL, XPATH sowie nicht zuletzt SVG, JSON, LD+JSON, MIME Types für Bildformate und dergleichen mehr.

Dem UDS Core HTTP Server ist es im Grunde genommen egal, auf welchem Server (Hardware) diese Dokumente liegen, so dass komplette Webseiten mit 1 bis 1.000 Einzelseiten schlichtweg bei Bedarf auf 10 Domains bei 5 Webhostern verteilt werden könnten.

Dieses Prinzip bezeichnet man als Document Driven Design. Ein Besucher vermag, wie Sie an dieser Webseite gerade sehen, nicht zu erkennen, dass wir dieses Verfahren einsetzen.

Data Driven Design bedeutet, dass in UDS flexibel neue Typen von Inhalten wie Blogs oder Pages oder How-To-Sektionen definiert werden können, auch wenn es diese vorher ggf. gar nicht gegeben haben sollte. UDS interessiert sich nur für die angefragte Adresse, sucht das passende Dokument und eine Template, welche die Struktur in eine Ansicht umrechnet.

Das technische Konzept von WordPress basiert auf PHP als Programmiersprache und MySQL mit einem klassischen, allerdings vergleichsweise einfachem, rudimentären Datenbank-Modell.

WordPress differenzierte zumindest bis Version 4.9 zuerst einmal nicht zwischen Blog-Posts und Pages, dh. WordPress war schlichtweg dafür gedacht, dass ein Redakteur einen Artikel mit Absatzen und Text und Bildern schreiben konnte, diesen mit einer Kategorie oder Stichwort verknüpfte, ein Datum angab, und den Spaß veröffentlichte.

WordPress erforderte deshalb in der Frühzeit kein Menü, weil das System nicht mehr und nicht weniger machte, also einfach die neuesten Artikel als Posts zeitlich sortiert aufzulisten. Über Kategorien und Tags wurde deren Anzahl auf die Posts reduziert, die damit markiert wurden.

TYPO3 CMS, entstanden etwa zwischen 2001 und 2004, ist tatsächlich einst als Content Management System für den Einsatz in großen Unternehmen geplant und entwickelt worden. Der Entwickler, ein Däne, und nach unserem Kenntnisstand ein Unternehmen aus Frankreich/Europa, setzten auf Open-Source-Lizenzen.

TYPO3 CMS erweiterte das Prinzip der Redaktion und Veröffentlichung von Inhalten um ein granulares Verfahren zur Zuteilung und Prüfung von Berechtigungen für Gruppen und User.

TYPO3 CMS ermöglichte von Beginn an mehrspaltige Layouts und die Option, Content Elemente als einzelne Einheiten diesen Spalten zuordnen zu können.

TYPO3 führte eine eigene Skriptsprache ein, Typoscript, sowie eine eigene Datenstruktur der sogenannten COAs, Content Object Arrays.

Die Redaktion in UDS erfolgt basierend auf Dateien in XML Syntax. XML ist ein gängiger W3C und ISO-Standard der von der Syntax faktisch jedem Entwickler, jedem Admin und auch jedem, der was mit Medien gelernt hat, bekannt sein sollte. Falls nicht: Wir haben seit 2004 wiederholt Mitarbeiterinnen und Mitarbeiter in Programmiersprachen wie JAVA, C#, PHP und auch die W3C Formate für HTML, CSS und XML eingearbeitet.

Basierend auf einer Zusammenarbeit mit /// SNEWMEDIA , einem unserer Kooperationspartner oder auch einer Einarbeitung Ihres Mitarbeiters in das Verfahren in Verbindung mit unseren Docs und Beispielen ist die Redaktion im Grunde genommen wirklich einfach weil man schlussendlich ja immer nur Beispiele kopiert und den Text darin ändert.

Der primäre Sinn und Zweck von XML und auch dem Ansatz von UDS besteht entsprechend den Empfehlungen des W3C darin, dass XML von Menschen noch verstanden, gelesen und getippt werden kann wie normaler Text, gleichzeitig aber eine Verarbeitung der XML Syntax weltweit mit faktisch allen Skript- und Programmiersprachen möglich ist.

Eine Erzeugung von Dateien mit redaktionellen Inhalten ist deshalb nicht auf eine menschliche Redaktion beschränkt sondern ermöglicht die Verwendung über PHP hinaus mit Java, C#, NodeJS und anderen Programmiersprachen.

Auf dieser Grundlage lassen sich bei Bedarf für gängige redaktionelle Tätigkeiten Formulare realisieren, welche über Skripts verarbeitet werden und dann neue Dokumente erzeugen, deren Inhalte über Pre- und Post-Prozessing in das Gesamtsystem integriert werden können.

Die Redaktion in WordPress erfolgt über ein webbasiertes Backend, dh. die selbe Webseite, die der Kunde aufruft, ermöglicht über eine spezielle aber jedem Hacker bekannte Adresse den Zugriff auf die Formulare im Backend. Man meldet sich an oder hackt zuerst das Kennwort, und dann kann man loslegen.

Die redaktionellen Möglichkeiten in WordPress sind begrenzt und lassen sich nur über Plugins, Widgets oder Features eines Themes erweitern.

Dieses führt dazu, dass IT-Sicherheitsprobleme durch die zig Plugins entstehen, ohne die WordPress aber faktisch selbst von sich aus nichts kann.

Ein großes Problem bei WordPress besteht darin, dass ein Wechsel es Themes dazu führen kann, dass bisher erfasste redaktionelle Inhalte in der Datenbank beim Neuladen und Speichern verändert oder schon beim Deinstallieren des Themes gelöscht wurden.

Von über 50.000 Plugins für WordPress sind nur ein Bruchteil tatsächlich gepflegt. Hinzukommt, dass die Mehrzahl aller kostenfreien Plugins faktisch nur eine Demo ist.

WordPress erzeugte Menüs bis 4.9 nicht direkt auf den angelegten Seiten im CMS sondern über spezielle Menü-Elemente, dh. Menüs mussten manuell gepflegt werden, damit angelegte Seiten auch im Menü erscheinen.

Auch hier sind viele gute oder wichtige Features bei WordPress bis heute eigentlich nur durch Plugins von Drittanbietern zu bekommen, so dass das CMS WordPress selbst im Grunde genommen nur eine Basisversion eines CMS ist.

Die Redaktion in TYPO3 CMS ist bedeutend komplexer als die in WordPress.

Die Anzahl der redaktionellen Features lässt sich durch Extensions erweitern, also ähnlich wie bei WordPress die Plugins. Wie auch bei WordPress ist es allerdings so, dass das TYPO3 CMS selbst als Redaktionssystem zuerst einmal nur die Infrastruktur und die wichtigsten Content Elemente für Absatzformate, Überschriften, Bilder und natürlich die jeweilige Seite im CMS bietet.

Ein Reiz von TYPO3 CMS besteht darin, dass man Seitenstrukturen von Beginn an als Baumstruktur mit Kapiteln anlegen kann, so dass bei Programmierung eines Menüs hierfür auch die Menüs damit 1, 2, 3 Gliederungsebenen haben können.

UDS gilt als sicher dahingehend, dass es von außen nicht möglich ist, die Webseite über einen Hack von Kennworten direkt zu übernehmen: Das Backend und damit die Redaktionsoberfläche ist über die Webseite, welche mit einer Domain die Inhalte darstellt, gar nicht zu erreichen.

WordPress ist bekannt für die viele Hacking-Angriffe. WordPress selbst und das Unternehmen dahinter, Automattic, haben immer in IT-Sicherheit und Features investiert, aber die Abwärtskompabililität und der Wunsch, es Entwicklern und Usern möglichst einfach zu machen, führt dazu, dass zwar das CMS selbst sicher sein kann, die zig Plugins und Themes allerdings nicht.

WordPress lebt von einer Entwickler-Community auf dem ganzen Planeten, wo im Grunde genommen munter jeder irgendetwas liefert und supportet, so lange man daran etwas verdient und Lust hat; der Zeitraum aber endet schließlich, und damit kann man den Support für gefühlt 99,9% der über 50.000 Plugins im Grunde genommen vergessen. Ausnahmen bestätigen die Regel

TYPO3 gilt als Enterprise CMS und hat seinen Kurs spätestens ab 2012 stark nur noch auf größere, zahlungskräftige Firmen ausgerichtet. Die Anstrengungen für die IT-Sicherheit sind entsprechend sehr hoch, die Community hat auch einen hohen Anspruch.

In der Praxis sieht das allerdings so aus, dass man Patches und Updates zeitnah einspielen sollte, denn auch wenn TYPO3 CMS viel seltener als WordPress im Einsatz ist, so sind die damit betriebenen Webseiten vom redaktionellen Umfang und der Bedeutung für die Betreiber bei weitem größer als vieles, was KMUs, Vereine oder Handwerker sich mit WordPress zaubern lassen oder bei einem Webhosting auf Knopfdruck installieren lassen.

UDS von /// SNEWMEDIA wird bislang von uns und Kooperationspartnern ohne Zusatzkosten und ohne Lizenzkosten für Projekte verwendet. Es handelt sich zuerst einmal um ein Werkzeug für damit die Agentur, die Ihnen auf diesem Wege die Infrastruktur für Datenmodell, Inhalte, Informationen, Bilder und deren Verarbeitung und Rendering ermöglicht.

Verrechnet wird über Zeitaufwand und/oder Pauschalen basierend auf Einheitspreisverfahren, sofern es sich nicht um Entwurfsleistungen handelt.

Was also verrechnet werden kann, wie auch bei einem Handwerker, ist also nicht der Hammer, den er nutzt, sondern spezielles Material oder spezielle Komponenten welche für Sie angefertigt oder bezogen werden müssen.

UDS wurde explizit basierend auf XML Standards geschaffen, weil es die Planungs- und Entwicklungkosten neuer Layout- und Inhaltskomponenten für Präsentationen gegenüber der Entwicklung von Plugins und Extensions für WordPress oder TYPO3 stark verringert.

Das UDS kein Backend erfordert, weil Daten bereits in XML erstellt werden können, können viele Komponenten oftmals schlichtweg durch das Kopieren einer HTML-Vorlage aus einem Demo-Entwurf integriert werden.

Updates werden als Service-Leistung verrechnet. IT-Sicherheitsrelevante Gründe für zeitkritische Updates sind aber äußerst selten.

Das CMS WordPress kostenfrei. Das gilt auch für viele Plugins und Themes, doch in der Praxis können Sie mit den kostenfreien Varianten nicht viel anfangen. Plugins und Themes werden bei WordPress üblicherweise mit grob 10 bis 50 USD pro Jahr verrechnet, dh. über diesen Zeitraum haben Sie das Recht und die Option, Updates zu bekommnen.

Ist man sich bewusst, dass man schnell auf einige Dutzend Plugins kommen kann, die ein jedes für sich separate aktualisiert und von einem anderen Anbieter angeboten wird, können hier durchaus Beträge pro Jahr zusammenkommen die viele Webseitenbetreiber vorher nicht auf dem Schirm hatten.

Nun muss man nicht updaten, kann also auch nach 1 Jahr auf weitere Kosten verzichten und das System weiterlaufen lassen. Zumindest theoretisch.

In der Praxis kann ein Update von WordPress CMS selbst unabhängig von Plugins dazuführen, dass die Webseite nicht mehr funktioniert, weil ein einziges Plugin das Rendering zerschießen bzw. verhindern kann.

Ein Support für Plugins, die der Original-Entwickler nicht mehr pflegen will, ist zwar technisch möglich, erfordert aber einen Entwickler mit PHP/JS/WP Kenntnis, der das auch machen will.

Man kann zusammengefasst mit WordPress also sehr günstig fahren und noch günstiger, wenn man die IT-Sicherheit ignoriert und mit Hacks leben kann. Wenn einem aber ein einziges Plugin ohne Updates die Seite zerschießen kann, sollte man wissen, dass eine manuelle Korrektur durch einen anderen Entwickler schnell 1/2 bis 5 Tagessätze kosten kann. Nach oben, wie immer, sind die Grenzen offen. Manche Plugins sind komplette Softwarelösungen innerhalb von WordPress.

Auch TYPO3 CMS ist zuerst einmal kostenfrei und Open-Source. Ab 2012 wurden einst eine automatische Aktualisierung ermöglicht, doch diese führt immer wieder dazu, dass ein Admin oder Entwickler hier nacharbeiten muss.

Dieses macht TYPO3 CMS als Enterprise CMS zuerst einmal recht sicher, darüber hinaus auch deshalb teuer, weil die Vergütung für TYPO3 Admins und Entwickler schlichtweg höher als die von WordPress-Bastlern ist. TYPO3 CMS ist komplex. Das ist auch gut und richtig so.

Man sollte bei TYPO3 CMS basierten Webseiten also sich bewusst sein, dass allein die Arbeitszeit für Updates und Patches des Systems pro Jahr mehr kosten wird und sollte, als manche kleine Unternehmen überhaupt für den Relaunch Ihrer Webseite investieren möchten.

UDS: Das System basiert im Schwerpunkt auf Pipelines von XML DOM Document verbeitenden Prozessen. XML ist ein W3C- und ISO-Standard als Dateiformat für objektorientierte Datenstrukturen, ermöglicht eine Validierung im Falle von ergänzenden XSD Schemata und unterstützt darüberhinaus auch die Referenzierung von Dokumenten über relative und absolute Adressierung, dh. Dokumente könnten Teile Ihrer Inhalte auch über Elemente in Dokumenten auf anderen Servern und von anderen Domains laden.

Im Gegensatz zu Open-Source-CMS ist es hier so, dass UDS XML Dokumente nicht vom Prinzip mit beliebigen Skript- und Programmiersprachen gelesen und verarbeiten werden können.

Erweiterungen sind an dem Punkt möglich, wo in die Pipeline der Verarbeitung weitere Verarbeitungsprozesse integriert werden, indem diese für den Verarbeitungsprozess registriert werden.

Schwerpunkt von Erweiterungen, welche vom UDS Core und Standard abweichen, betreffen im Grunde genommen zuerst einmal User-Templates mit denen im PostProcessing Design-Aspekte und damit die Ansicht verändert werden kann.

UDS: Das System verarbeitet Anfragen an eine Webseite über den UDS Core HTTP Server, welche die vom Nutzer oder über die API von einem anderen Programm beim Zugriff auf die Homepage übertragenden, über den UDS Core. Basierend auf der Anfrage ordnet der Server dieses Request einen Realm (Bereich eines Kunden) zu, sucht/findet das zu ladende und darzustellende Hauptdokument für die angefragte Adresse und beginnt die Verarbeitung.

Die Verarbeitung in UDS basiert im Kern auf drei Phasen: Pre-Processing, Processing und Post-Processing. Das Pre-Processing dient dazu, basierend auf Pre-Processing-Elemente in Dokumenten vor dem eigentlichen Processing des Dokuments weitere Daten aus Dokumenten auch von anderen Servern beschaffen zu können und diese hierbei vorab in das Dokument-Format zu übertragen.

Im Processing werden damit vom Mensch, von Programmen, von der KI und über Pre-Processing erzeugte Dokumente verarbeitet und eine Ansicht für das gewünschte Medium wie Web oder Print umgerechnet. Das Post-Processing übernimmt nachträgliche Ergänzungen, Korrekturen, Kompression und anderes mehr.

Erweiterungen werden von /// SNEWMEDIA oder Kooperationspartnern entwickelt und von /// SNEWMEDIA in das System integriert.

Das Primärziel besteht hierbei darin, die Anzahl von Erweiterungen bewusst auf das zu limitieren, was wir und unsere Kunden im der Summe als kleinsten gemeinsamen Nenner benötigen. Dieses Verfahren dient dazu, die Kompatibilität zwischen den verschiedenen Modulen und Komponenten sicherstellen zu können.

Die Entwicklung des UDS Core sowie auch der Erweiterungen folgen einem zentralen Release-Cylce von /// SNEWMEDIA , um auf diesem Weg sicherzustellen, alle die Kernbestandteile und die Erweiterungen für die neue Version funktionieren.

Ein Primärziel besteht darin, dass alle Erweiterungen, welche nicht der Gestaltung im Post-Processing dienen, nach einer Evalutationsphase in den eigentlichen UDS Core und damit den Kern-Templates hinzugefügt werden.

WordPress: Erweiterungen bei WordPress entstehen über Themes, Plugins und Widgets. Alle diese Erweiterungen müssen sich über Hooks im Verarbeitungsprozess von Anfragen registrieren. Dieses Prinzip entspricht an dem Punkt zuerst einmal dem Ansatz wie in UDS, wobei bei WordPress Erweiterungen sich allerdings zuweilen automatisch registrieren können während diese in UDS zumeist über Include-Anweisungen programmiertechnisch hinzugefügt werden müssen.

Die automatische Registrierung in WordPress ist sehr praktisch, zugleich aber auch ein Grund für viele Hacks und damit Risiken.

Da Entwicklungen bei WordPress aus der Open-Source-Community und nicht aus einem Entwickler-Team kommen, gibt es einerseits sehr viele Erweiterungen, andererseits aber keine Standards oder Abstimmung unter den jeweiligen Entwicklern der Erweiterungen. Dieses führt zu Kompatibilitätsproblemen.

Das Kernproblem bei WordPress mit Blick auf eine Langzeitnutzung einer Webseite besteht darin, dass man ständig Sicherheitsupgrades und Veränderungen des CMS selbst mittragen muss, was dazuführt, dass auch alle Erweiterungen ständig Aktualisierungen erfordern. Bei der Vielzahl von Plugins, welche manche Anbieter für WordPress-Webseiten zusammenklicken, ist die Wahrscheinlichkeit hoch, dass manche Plugins keinen Support mehr haben. Bei kostenpflichtigen Plugins sind die Chancen für Updates höher, aber die ganzen Lizenzen wollen dann auch organisiert, bezahlt und beschafft werden.

TYPO3 CMS: Erweiterunge bei TYPO3 CMS bezeichnet man als Extensions. Die Entwicklung von Erweiterungen bei TYPO3 CMS erfordert eine intensive Einarbeitung in TYPO3 CMS sowie die Programmierung von Erweiterungen für TYPO3 CMS im Umfang von Wochen oder ein paar Monaten, bis man den Bogen wirklich raus hat.

Der Reiz an TYPO3 CMS Erweiterungen besteht mitunter darin, dass Erweiterungen sich auch in die Struktur von Rechten und Berechtigungen in TYPO3 CMS integrieren, welche weit über das hinausgehen, was bei WordPress CMS möglich ist.

Das Kernproblem bei TYPO3 CMS mit Blick auf eine Langzeitnutzung einer Webseite besteht darin, dass man ständig Sicherheitsupgrades und Veränderungen des CMS selbst mittragen muss, was dazuführt, dass auch alle Erweiterungen ständig Aktualisierungen erfordern.

UDS: Wir haben seit 2004 bis heute mehr als 20 Jahre mit allen 3 Verfahren gearbeitet.

Das zentrale Kriterium für uns und manche unserer Kunden ist die IT-Sicherheit mit dem Wunsch, eine Webseite auch ohne zeitkritisch Patches einfach das nächste Jahr mal durchlaufen lassen zu können.

Auch UDS erfordert Updates und Upgrades, weil wir immer Features hinzufügen oder auch mal was ändern. Wir können diese Zeiten aber auf den Tag legen, wo wir für Sie ohnehin im Content Management gerade redaktionelle Änderungen übernehmen.

WordPress: Eine Diskussion mit vielen Unternehmen pro/kontra WordPress ist müßig. Diejenigen, die es haben wollen, bringen auch wir davon nicht ab. Wollen wir auch gar nicht.

WordPress hat, wenn man schlanke Lösungen installiert, gerade für Auftraggeber, die selbst ständig etwas selbst schreiben und veröffentlichen, ergänzen, löschen, umtexten wollten, den Vorteil

TYPO3 CMS ist ein prima CMS. Wir hatten es über 10 Jahre bewusst für Webseiten unserer Auftraggeber im Marktsegment der kleinen mittelständischen Unternehmen, Vereine, Initiativen und Selbständigen wegen seiner Features, der Genauigkeit, der gegenüber WordPress höheren Sicherheit und vielen anderen Aspekten mehr empfohlen.

TYPO3 CMS hat bis heute Features, die in WordPress so gar nicht oder nur mit einer Bandbreite an Plugins möglich sein wird. Nun gilt das für viele Features bei TYPO3 auch, nur dass man von Extensions spricht.

Der Grund, weshalb /// SNEWMEDIA für unsere eigenen Webseiten von TYPO3 CMS auf UDS umgestellt hat, hat im Schwerpunkt damit zu tun, dass UDS bezogen auf die Veröffentlichung von Informationen auf Webseiten 95% der von TYPO3 von uns genutzten Features bieten kann. Es ist also von Besuchern unserer Webseite nicht mehr zu erkennen, ob diese wie früher mit TYPO3 CMS oder inzwischen mit UDS realisiert wurde.