Ein "Content Management System" (= CMS oder auch auf Deutsch "Inhaltsverwaltung") ist eigentlich ein virtuelles Redaktionssystem im Internet, wie man es sich im Traum vorstellt. Hierbei gibt es grundsätzlich zwei "Beteiligte", die "Macher" und die "Leser" / "Besucher".

Die beiden "Beteiligten" haben gänzlich unterschiedliche Anforderungen, Ansprüche und Eigenarten. Und auf die beiden sollte das ganze Projekt zugeschnitten sein.

Der Leser oder Besucher der Web-Seiten möchte etwas über sein Thema oder seine Frage lesen und erfahren und dabei auch etwas Spaß haben, ab und zu schmunzeln und etwas gelernt oder erfahren haben.

Der oder die Macher wollen ihre Gedanken, Geschichten, Texte und Bilder so komfortabel und zügig wie möglich in ihre Webseiten einbauen und die Informationen untereinander verknüpfen (verlinken).

Daß das mit den aktuellen Blog-Systemen wie Wordpress und anderen inzwischen geht, ist unbestritten. Und daß ein Laien- oder Hobby- Redakteur damit arbeiten kann - ebenso.
.

Wächst dabei aber der Umfang (Content) bzw. die Menge oder Anzahl der eingebrachten Web-Seiten über eine gängige "Normalität" (von unter 100 bis vielleicht 500 Seiten) hinaus, ändern sich die Maßstäbe gewaltig und die Anforderungen an solch ein echtes "CMS" steigen ins Astronomische.
Viele der Leser und Besucher und auch die freundlchen Tip- und Ratgeber verkennen den Aufwand bei über 45.000 Seiten, die Übersichtlichkeit für den schreibenden und kreativen Redakteur zu erhalten. Unsere hier benutzte typo3 Version kann das.
.

Der Leser bekommt vom Webserver die sichtbaren Webseiten - das Frontend - übertragen (oder ausgeliefert / gesendet), in welchem er sich zurechtfinden können sollte. Dieses Frontend wird in einem "CMS" einmal für wirklich alle Seiten konzipiert und gestaltet und festgelegt und der Gestalter muß sich an bestimmte Erfahrungs-Kriterien und Reglen halten.

Das Design oder das Aussehen der einzelnen Webseiten (besser : aller Webseiten) muß auf allen Browsern dieser Welt nahezu gleich aussehen - ohne Ausnahme. Das gilt auch für Tablets, jedoch nicht für die kleinen Displays / Bildschirme von Smartphones.
.
Als Beispiel für Lesbarkeit und Akzeptanz dient diese uralte FAZ-Studie aus den 1950er Jahren : Maximal 3 Schrift-Größen und 3 Schrift-Arten und eine möglichst gleichbleibende Spaltenbreite mit einer recht genau definierten Zeilenlänge -

Und weiterhin : keine Farbspielereien, also schon gar keine farbigen Schriften, - und seien sie auch noch so beeindruckend bunt.
.
Der Seitenaufbau bzw. die Auslieferung muß so zügig wie möglich funktionieren, also möglichst kleine "Datenmengen" pro aufgerufener Seite. Die einzelnen Seiten müssen eindeutig mit übersichtlichen Überschriften bezeichnet sein und viele andere Kleinigkeiten mehr. Das ganze Wissen und die Realisierung sind bei uns in den letzten 15 Jahren seit 2007 kontinuierlich gewachsen.
.

Seit dem Anbeginn der Internet Entwicklung so um 1995 und den ersten Darstellungsprogrammen hatte sich die Programmiersprache (oder Scriptsprache) "php" als sehr handlich und leistungsfähig herauskristallisiert. Im Laufe der Jahre wurde "php" von vielen Mitmachern weiter entwickelt und in das CMS "typo3" wurde erst php-4 und dann php-5 als Basis aller Programme benutzt. "php" gehörte sowieso essentiell zu jedem Linux- Betriebssysten dazu bzw. war darin enthalten.

In der bei uns benutzen "typo3" Version 4.2.17 wurde php 5.3 verwendet. Mit php-5 und ab und zu etwas Javascript sind so gut wie alle benötigten Funktionen von "Frontend" und "Backend" samt der Benutzer-Oberflächen realisiert worden.

Dabei kommt eine Eigenschaft der php- Programmierung zur wichtigen Geltung, die Vererbung von Funktionen und die Objektorientierung von Programm-Moduln. Wie das genau funktioniert, ist weniger wichtig.

Jedefalls gibt es (als Beispiel) nur ein einziges php Progamm-Modul zur Datenübergabe an eine Datenbank (in beiden Richtungen), über die die Inhalte unserer Seiten abgespeichert und wieder abgerufen werden. Dieses Programm ist austauschbar konzipiert, für verschiedene gängige Datenbanken wie mysql, oracle, informix oder MS-sql usw.

Wir benutzen als Datenbank das in "typo3" präferierte freie System "mariadb" (ehemals mysql) und müssen uns um nichts spezifisches mehr kümmern.
.

In der Datenbank gibt es zwei dominierende "Tabellen", die "pages" und die "content-elements". Der Redakteur, der eine neue Seite anlegen möchte, ruft einen sogenannten "page-wizzard" auf, eine interaktive Hilfe, mit der er eine neue Seite an dei gewünschte Stelle in den vorhandenen "Seiten-Baum" positionieren und platzieren kann.

Er sieht die vorhandenen Seiten und deren Unterseiten über alle Memü-Strukturen hinweg und kann damit ganz gezielt und vor allem schnel vorgehen. Damit ist erst mal ein Eintrag in der "pages"-Tabelle erstellt.

Als nächstes erstellt er ein erstes "content-element" - das wäre der erste von den Absätzen der neuen Seite. Dieses Element wird in der Tabelle der "content-elements" angelegt und in der "pages"-Tabelle nur referenziert. In dieser pages-Tabelle sind damit nur die Referenzen der zu dieser Seite zugehörigen content-Elemente enthalten.

Wird dann eine solche Seite (eine "page") vom Leser aufgerufen, werden in der Datenbank die Referenzen aus der content-Tabelle zusammengesucht und in die Hülle des sichtbaren Teils der auszuliefernden Seite eingefügt.

Was sich so einfach anhört, ist denoch sehr komplex, weil es da einge Randbedingugen gibt, die der Programierer einbauen muß(te).
.

Eine der damals wie heute noch dominierenden herausragenden Eigenschaften war die "Bildverarbeitung" in typo3. Damit ist nicht die Bild-Gestaltung von Photoshop oder Corel-Photo-Paint gemeint, sondern das Einbinden von Bildern aller Art in die Absätze, in die content-Elemente.

Wo und wie werden Bilder in welcher Größe in den Text eingebunden. Auch hier wieder die Vorgabe - kein Schnickschnack, kein Geflacker oder Geflicker oder kleine Filmchen innerhalb des Textes. Ein oder mehrere Bilder sollen den jeweiligen Abschnitt unterstützen - aber nicht die Aufmerksamkeit vom Thema wegleiten.
.
Die Art und Weise, wie die Bilder im Text eingebunden werden, war einfach und übersichtlich und hat viele Arbeiten erheblich erleichtert. Auch hier werden die Bilder mitsamt ihren Eigenschaften im "content-Element" nur referenziert. Das Einfügen, Dimensionieren und auch das Löschen von Bildern geht vordergründig ganz einfach, ist aber im Hintergrund recht komplex programmiert.

Im Text läßt sich von jedem Bild ein sogenannter (und deutlich kleinerer) "Daumennagel" (ein Thumbnail) anzeigen, der beim Draufklicken auf dieses Bild auf die volle Größe aufgeblendet wird. Dieses große Bild verschwindet dann durch nochmaliges Klicken auf das Bild wieder. Das geht sehr komfortabel und schnell.

Diese (enlarge on click) Funktion, die seit 2010 absolut problemlos funktioniert, ist (zum Beispiel) seit Jahren das KO-Kriterium für eine Migration in irgend ein anderes CMS.
.

Es gibt zu der scheinbar simplen Technik (wie weiter oben beschrieben) eine ganze Anzahl Randbedingungen, die das typo3 Konzept abdeckt. Wenn zum Beispel bei jedem Seitenabruf jedesmal die ganzen Content-Elemente erst zusammengesucht werden müssten und die kleinen Bildchen erzeugt und eingeblendet werden müssten, hätte der Server viel Arbeit und der Server ginge in die Knie. Weiterhin würde es (zu) viel Zeit brauchen.

Darum werden die einmal abgerufenen Seiten in speziellen besonderen "Cache"-Tabellen in der mysql Datenbank "bevorratet" und auch die kleinen Bildchen werden in einem speziellen Verzeichnis aufgehoben. Dieses sogenannte "Caching" (= Zwischenspeichern) muß aber besonders effizient und idiotensicher verwaltet werden.

Beim Aufruf einer Seite "schaut" typo3 erstmal, "Habe ich die Seite schonmal aufgerufen ?" und wenn ja, wird diese bereits fertig zusammengesuchte Seite ausgeliefert. Da hinein hatte der damalige Entwickler von typo3 eine Menge Grips eingebracht.

Weiterhin gibt es auch für die php- Programmiersprache sogenannte Beschleuniger, "Caching"- Zusätze, die das Ausliefern der abgerufenen Seiten nochmals beschleunigen.

Auch das Betriebssystem Linux hat ein drittes Caching System und speichert im RAM sowohl die letzten Daten als auch Programme wie auch bereits abgerufene Web-Seiten. Diese Konzepte dürfen nicht kollidieren und müssen gemeinsam die letzten aktuellen Seiten finden und ausliefern.
.

Bezüglich des typo3- Cachings gibt es noch ein paar intelligente Besonderheiten, die aber ganz schön irritieren können. In (auf) jeder Seite kann vom Redakteur festgelegt werden, wie lange das bereits einmal abgerufene Abbild im "Cache"-Speicher gültig sein soll und ab wann (z.B. 4 Stunden) typo3 alles nochmal zuammensammeln muß.

Will aber der Redakteur jetzt sofort sehen, ob seine Änderungen angekommen sind, muß er eingreifen und diese eine Seite im Cache löschen. Er kann auch den gesamten Cache Speicher löschen. Dann würde typo3 etwas langsamer, bis die abgerufenen Seiten wieder aktualisiert wurden. Auch hier muß der php-/mysql- Programierer alle Tricks kennen, um die Stufen des Lösch-Programms handhabbar zu machen.
.

Hochseilartisten im Zirkus oder im Varietee arbeiten allermeist mit einem Sicherheits- oder Fangnetz, wenn ein Schritt auf dem Seil doch mal daneben geht.

Auch bei den Redakteuren läßt die Aufmerksamkeit nach mehreren Stunden (oder des Nachts) nach und dann ist ein Artikel oder eine wichtige Änderung auf einmal wieder weg - weil das Speichern übergangen oder vergessen wurde oder ein unüberlegter Klick irrtümlich auf den Löschknopf -das kommt vor.

Bei typo3 gibt es für die Editoren der Texte / content-Elemente eine zeitlich chronologische Änderungs-Historie, mit der man alle !!! früheren Versionen des Textes zurück holen kann. Wer mal mit einem älteren Redaktionssystem gearbeitet hatte und dann ist sein mühsam über mehere Minuten formulierter Text bzw. die Korrektur (wieder) weg, der weiß das sehr zu schätzen.
.

Wenn der Redakteur seinen Text mit Bildern ergänzt hat und dann abspeichert, erzeugt typo3 die kleinen Bildchen automatisch. Dazu braucht es ein im Hintergrund wartendes (unsichtbares) Grafik-Programm, das diese Bildchen im Hintergrund automatisch (und effizient) verkleinert und als "Daumennagel" auf der Festplatte ablegt. Hier wird vom Server-Administrator im Linux-System sowohl "GraficsMagic" wie auch "ImageMagic" installiert und in typo3 eingebunden. Diese beiden Programme warten einfach bis der nächste Aufruf kommt.
.

Das "Suchen" wird von vielen Hobby- Redakteuren und Blog-Gestaltern unterschätzt. Steigt nämlich die Anzahl der Seiten und Inhalte ins nahezu Uferlose an, bekommt diese Funktion eine überragende Bedeutung.

In typo3 sind mehrere Such-Systeme integriert. Die ursprüngliche (wir nennen sie die sequentielle Suche) Suchtechnik war einfach und simpel - dafür aber recht langsam bzw. sie wurde immer langsamer. Mit einer in php programmierten Technik wurden in den beiden Datenbank-Tabellen "pages" und "elements" die Texte sequentiell (also schön der Reihe nach) abgegrast und die übereinstimmenden Fundstellen aufgelistet.

Als diese Such-Methode deutlich länger als 1 Minute gebraucht hatte, mußten die in php sicherheitshalber eingebauten (Ablauf-) Zeitsperren (für die php-Funktionen) auf 3 oder 5 Minuten ausgeweitet werden. Am Ende war das bei zigtausend Seiten zwar technisch ok aber für den Leser von der Zeit her inakzeptabel.

Eine zweite innerhalb von typo3 angebotene Such-Methode war die Indexierung aller Wörter in Übeschriften, Texten und Bildunterschriften in einer separaten Riesen-Tabelle. Dazu brauchte diese Technik aber eine sehr große "Java"-Engine (auf dem Server) und die (also Java) kommt mir aus Sicherheitsgründen nicht ins Haus.
.

Ürsprünglich in USA enwickelt, dann in Russland (vor dem Putin-Krieg) weiter gepflegt und inzwischen verwaist, ist das ein geniales Konzept - jedenfalls für unserer Belange. Auf Betriebssystem-Ebene "rennt" solch eine Technik viel viel schneller als in irgendwelchen Anwendungsprogrammen.

Ein weiterer Russe (auch lange vor Putins Krieg) hat für typo3 eine sogenannte mnogosearch- Such-"Extension" programmiert (auch in php), die - für unsere Zwecke - hervorragend funktioniert.

Der mnogosearch "Indexer" wird unter Linux von Hand gestartet und durchsucht dann (wie ein Crawler von Google) die spezifizierte "Website" von vorne bis hinten und indiziert alle Wörter in 256 Index-Dateien - alles des Nachts.

In typo3 ist dann in der entsprechenden Such-Seite eine Abfrage-Zeile eingebaut, in der man (auch) mehrere Such-Wörter eintragen kann und dann in 10tel Sekunden hunderte oder gar tausende von Fundstellen - samt der Links auf die Seiten - sauber und übersichtlich aufgelistet bekommt.

Wird dieser (offline-) Indexer täglich (nachts) angestoßen, wobei diese 256 Indextabellen zuerst geleert werden, ist der Index tagesaktuell - und das ist für uns absolut ausreichend. - Diese offline-Suchgeschwindigkeit der mnogosearch Engine ist phänomenal.
Sie können das selbst probieren - hier einfach nach "GRUNDIG" suchen.
.

Unsere Museenseiten leben von der sogenannten "Verlinkung" (auch "Verknüpfungen" genannt) einzelner Wörter oder halber Sätze auf erklärende bzw. weiterführende Informationen auf bereits vorhandene andere Seiten oder sogar auf fremde Inhalte. In allen Museenseiten sind es über 40.000 solcher Links in unseren Content-Elementen. So etwas kann man nicht mehr "von Hand" kontrollieren bzw. pflegen.

Solch ein Link kann auf eine unserer Domains mit angehängter Record-Nummer verweisen oder auf eine "sprechende Adresse" einer unserer Seiten oder direkt auf eines unserer content-Elementes. Auch bei akribischster Arbeit gehen ab und zu diese "Ziele" kaputt oder verloren oder werden umbenannt und der Link hängt dann in der Luft - "Webseite nicht gefunden".

Ein seit langem enthaltenes Prüfprogramm ("Verknüpfungen" überprüfen) geht sämtliche Inhalte durch und prüft, ob das Ziel noch erreichbar, also aktiv ist und erzeugt ausführliche Listen, wo etwas defekt ist. Das Programm läuft zwar mehrere 10 Minuten, die Liste ist aber dann aber vollständig.
.
Auch der "Recycler" ist hilfreich. Denn gelöschte Datensätze in den Datenbank-Tabellen werden dort nur markiert und nicht entfernt. Das würde diese Tabellen aufblähen - wie zum Beispiel in den Cachig-Tabellen - und immer langsamer machen. Der Recycler repariert das automatisch.
.

typo3 hat eine perfektionierte Rechte-Verwaltung. Darin kann genau festgelegt werden, welche Benutzergruppe (bei mehreren Redakteuren) welche Seiten oder ganze Themen-Bereiche (Seiten mit Subseiten) ändern oder gar löschen oder veschieben darf - und noch viel mehr.

Weiterhin hat typo3 eine Mehrsprachen- Verwaltung, die wir auch nicht mehr benutzen, weil wir uns (aus Effizienzgründen) ausschließlcih auf Deutsch als zentrale Sprache konzentriert haben.
.
Die Erweiterung mit Namen "Realurl" ersetzt die von der mysql-Datenbank verwalteten "page"-Nummern automatisch mit (sprechenden) Namen. Der Aufruf einer bestimmten Seite über die Webadresse mit dieser angehängten "Record-Nummer" funktioniert zwar auch, wird aber von den Suchmaschinen nicht gemocht und ignoriert bzw. abgelehnt. Ein "sprechender Name" ist sowieso sinnvoller. Doch das "realurl"- Konzept hat Schwächen, die wir nicht mögen. Wir nutzen es deshalb nicht und verpassen allen neuen Seiten eigene Ersatznamen.
.

Der Texteditor für die Content-Elemente tut zu 99% alles, das (bei uns) ein Redakteur wirklich braucht. Viele Funktionen dieses Texteditors sind bei uns ausgeblendet, wie zum Beispiel die Auswahl von diversen Schriftarten (wir erlaubennur Arial) und die Farben von Texten. Auch das Einfügen von Bildern direkt in den Text ist gesperrt, wir wollen das wegen der Einheitlichkeit nicht. Auch ist bei uns der Artikeltext in jedem Content-Element immer linksbündig. Bei Überschriften ist auch "mittig" erlaubt.

Ab und zu verschluckt sich dieser Editor und der Cursor plaziert einzelne Buchstaben an ganz anderer Stelle. Doch damit kann ich seit 10 Jahren leben.

Unter ganz bestimmten Bedingungen wird der Seitenbaum unsichtbar. "Warum" müsste man noch mal suchen.

Und beim Verlinken ist die angezeigte Auswahl der Ziele etwas zu kurz geraten, auch das müste man mal suchen. Auch damit kann man leben. Bei dem geplanten Upgrade auf eine höhere php 7.4 Version sollen diese kleinen Macken repariert werden.
.

Die Technik macht gewaltige Fortschritte, die Hardware auch und die Software wird fortlaufend angepaßt. Auch, weil unsere asiatischen "Freunde" alles daran setzen, unsere Server zu knacken und zu übernehmen. Im Laufe der Jahre taten und tun sich immer wieder Lücken oder Löcher in den Betriebssystemen auf, die zwar repariert werden - aber ein Update oder gar Upgrade erfordern.

Und so ganz nebenbei werden auch die Programmiersprachen und Anwenderprogramme repriert und verbessert. Das ist aber nicht immer erfreulich, wenn zum Beispiel Funktionen auf einmal weggelassen wurden oder umbenannt wurden. Beim Update von php 5.3 auf 5.6 laufen die alten typo3 Programme nicht mehr, weil schwerwiegende Änderungen implememtiert sind. Die Datenbank- Connectivität ist jetzt anders.

Das alles trifft uns erstmal nicht so heftig, weil wir keine interaktiven Seiten haben (zum Beispiel einen Shop) außer unseren Kritik- und Kommentar-Formularen. Doch die sind so geschickt programmiert, daß alle Mißbräuche auf unserem Mailserver landen und bislang kein Unheil anrichten konnten und können. Die Frage ist nur - wie lange noch.
.
Doch bei unserem letzten GAU kam raus, das alte opensuse Betriebssystem war nicht mehr wie damals zu installieren. Den ziemlich blöden Trick hatte ich erst nach 7 Wochen gefunden, aber durch Zufall. Im Dezember 2023 hatte es plötzlich in der aktuellen Version 15.6 wieder funktioniert. Doch die Nerven, die das gekostet hatte, die sind weg, für immer.
.

In unserem virtualisierten Server (mit einem opensuse 15.6 Host) bei uns im Haus ist eine virtuelle Maschine mit opensuse version 12.3 installiert und läuft.

Die Webseiten sind unglaublich schnell, sogar schneller als auf den leistungsfähigeren Servern in Düsseldorf. Dadurch, daß diese VM wie der ganze Server hinter der Fritzbox wohnt, werden alle gefährlichen Ports (Einfallstore) abgeschottet und die Chinesen und all die anderen bösen "Freunde" laufen an die Wand, vorerst.

Wie lange noch, steht auf einem anderen Blatt.
.

Für unsere Zwecke einer Museen-Datenbank ist der Funktions- und Leistungsumfang dieser relativ alten typo3 Version absolut ausreichend. Den ganzen Schnickschnack der neueren Versionen einschließlich der Handy-Versionen mit dem sogenannten "responsive webdesign" brauchen wir nicht und diese geknautschte Art der Darstellung wollen wir auch nicht.

Unsere Museen-Seiten sind auf einen vernünftig großen Monitor hin optimiert und auf jedem Tablet- Computer super anzusehen. Die Seiten werden periodisch mit einem relativ neuen Macbook und einem älteren Motrola Zoom Tablet überprüft. Und das sieht sehr gut aus.
.

.