Einige Jahre, bevor wir typo3 entdeckt hatten, hatten wir mit einer "Technik-Seite" über Magnetband-Laufwerke angefangen - zu zweit. Und die Strukturen der Seiten orientierten sich an Artikeln von Fachzeitschriften. Das Programm "frontpage 98" konnte das nur teilweise abbilden.Jede einzelne Seite mußte aufs neue "gestylt" werden. Das war zwar mühsam aber machbar.

Jedoch ab einer bestimmten Anzahl von Seiten wurde das Backend-System schwerfällig und unübersichtlich. Ab ca. 100 Seiten war es für den Redakteur mühsam, mal schnell etwas zu ändern oder zu ergänzen. Die Lust zum Verbessern von Texten schlief ein. Und das mit den Bildern (im Text) war auch nicht besonders handlich.
.

Vorher hatte ich keine Berührung bzw. Ahnung, was ein CMS sei. Irgendein zufälliger Bericht lobte nur die Trennung von Design und Inhalt. Das klang gut und plausibel und es war auch so. Das ist der Hauptvorteil für den Redakteur, sich nicht mehr um das Aussehen kümmern zu müssen. Bei frontpage 98 sahen viele Seiten unterschiedlich aus, je nach Lust und Laune, das zu korrigieren.

Bei Typo3 war die Lernkurve des zugehörigen Script-Codes (typoscript) sowie der typo3 eigenen Template-Technik erträglich und nach der Gestaltung der linksseitigen senkrechten Navigation - jetzt voraussschauend auf viele hundert Seiten "getuned" - konnte es losgehen.

Die Übertragung der bisherigen Seiten aus dem frontpage 98 Web ging erstaunlich schnell und half, das typo3 System zu verstehen und auszubauen.

Der nächste Umbruch war die Erweiterung auf ein 3 spaltiges Layout mit schmalerem Mittelteil - basierend auf einer FAZ Erkenntnis. Die Arbeit des Redakteurs reduzierte sich auf nur noch einen Arbeitsplatz mit 3 Bildschirmen mit 1280x 1020 Auflösung. Das typo3- Backend in der ganz normalen Standard-Form erwies sich als sehr handlich.

Nach einer erstaunlich kurzen Eingewöhnung ging das "Füttern" der Magnetbandseiten immer schneller und schneller. typo3 war inzwischen ein ganz wichtiger Gewinn für solche Technik-Seiten.
.

Der Überblick und das Wissen über die Funktionen des opensuse Betriebssystems und des typo3 CMS ergänzte sich, sodaß an die Installation von fremden typo3-Erweiterungen gedacht werden konnte. Es kamen nämlich weitere Domains dazu, aber das typo3 Grundsystem sollte für alle nur einmal vorhanden sein und gepflegt werden können. Auch wurden alle Domain-Verzeichnisse und das typo3 Grundsystem sowie die Datenbank auf eine dritte zusätzliche (eigene) "Data"-Partition verlagert. Damit sind Betriebssystem (root) und Datenbereich komplett getrennt.
.

Werden von diesem Webserver irgendwann "mehr als eine" Domain verwaltet, sprechen wir von sogenannten "vhosts". In diesen vhost- Konfig-Dateteien werden diese virtuellen Domain-Namen und die neuen Document-Root- Verzeichnisse spezifiziert und auseinander gehalten. Auch die Rechte werden dort verwaltet.

Nach wie vor sollen aber die typo3 Core- (oder Source-) Dateien nur insgesamt einmal (global) vorhanden sein. Und bei den Erweiterungen klappte das auch, die sogenannte "globale" Installation von Extensions war möglich (spätere typo3 Versionen konnten das nicht mehr).

Der Apache Webserver wird so konfiguriert, daß er beim Aufruf einer Domain im jeweiligen "Document-Root" sofort nach einer "index.php" Datei sucht und die sofort ausführt, nicht aber die index.html Datei, die er sonst ausführen würde.

Diese erste index.php Datei ruft sofort die für alle gemeinsame zweite index.php Datei im typo3-Bereich mit Übergabe der Doamin-Parameter (incl. Directory-Root) auf und von nun an wird nur noch im typo3 Core gearbeitet.

In dem jeweiligen Directory-Root und dort in /typo3conf/ stehen in der localconf .php alle relevanten Informationen und Variablen für diese lokale Domain.

Hier sind vor allem die zugehörige mysql_db und die Zugangsdaten enthalten. Somit weiß das 2. index.php Programm bereits, welche zur Domain gehörende Datenbank angesprochen wird.
.
Der Webserver bekommt damit die Startseite dieser Domain zurück und die wird an den anfragenden Browser ausgeliefert.
.

Wenn die Startseite ausgeliefert wurde, hatte typo3 bereits die page-ID der ersten Seite aufgerufen und dort die content-IDs der zugehörigen Content-Elemente abgefragt und in den vordefinierten css gesteuerten html-Design-Rahmen eingebaut. Auch Bilder sind aus dem /pic/ Verzeichnis bereits aufgerufen und als verkleinerte "thumbnails" integriert.

Welche typo3 php-Module das im Schnellstgang abarbeiten, muß ich noch zusammenstellen. Das Verkleinern der Bilder übernimmt ein Grafik-Programm des Betriebssystems (mit Hilfe von Übergabe-Parametern).
.

..... oder besser ..... aus den einzelnen "mysql-Brocken" zusammengebaut, wird diese fertige Kombination in einer eigenen Cache-Tabelle bevorratet und der Index dieser Tabelle in Zukunft immer zuerst angefragt, ehe nochmals diese einzelnen Datensätze aus der Datenbank erneut zusammengesucht werden. Das geht dann natürlich noch schneller.

Auch die kleinen Bilder (Thumbnails) im Text werden beim erstmaligen Aufrufen im Cache- Verzeichnis gehalten und somit auch extrem schnell ausgeliefert.
.

Mit der Installation der mnogosearch Suchmaschine (Search-Engine) schlagen wir 2 ganz wichtige Funktionen mit einer Klappe. Diese Suchmaschine ist eine offline Suchmaschine. Das bedeutet, die 256 mnogosearch- Indextabellen der Datenbank (pro Domain) werden (meist Nachts) offline mit einem bash-shell-Script re-indiziert.

Da bei uns aber nichts (zeitlich) irgendwie brisant ist - wie bei Tageszeitungen und Zeitschriften -, reicht ein Indexlauf nach mehreren Tagen völlig aus. Solange ist der mnogosearch- Index "nicht 100%" aktuell. Weiterhin haben wir ja noch die alte aber langsame originale Suchmaschine aus dem typo3 core, die die Content- Elemente sequentiell durchsucht. Das dauert natürlich erheblich länger, ist dann aber "absolut" aktuell.

Beim offline Reindizieren mit der mnogosearch Engine muß wirklich jede einzelne Seite zusammengebaut und geladen werden. Das bedeutet im Umkehrschluß, das typo3 Page- Caching- Modul aktualisiert automatisch alle typo3 Cache- Tabellen und die gecachten Seiten.

Dem Page-Caching- Modul von typo3 ist es nämlich egal, ob die vorhandenen Seiten "von draußen" aufgerufen werden oder "lokal" innerhalb des lokalen Servers. Sämtliche Seiten sind dann in den Chache- Tabellen lückenlos vorrätig.

Früher wuchsen diese separaten Cache- Tabellen ins uferlose. Da wir das gemerkt hatten, haben wir uns ein sogenantes bash-Scipt für diesen "Reindexer" gebaut, in welchem die Cache- Verzeichnisse (mit den zwischengespeicherten Bildern) komplett geleert werden sowie die mysql- Cache-Tabellen geleert werden (die mysql Funktion heißt "truncate") und natürlich auch die mnogosearch Index-Tabellen geleert werden (ebenfalls mysql Funktion "truncate"). Damit bekommen wir völlig irre hochoptimierte Suchzeiten und absolut phantastische Zugriffszeiten ohne weitere Tricks zustande.
.
Solch ein offline Reindexing läuft dann halt Nachts und alle 6 oder 8 Kerne schaffen mit vollen 3,6 GHz bis zum Umfallen.
.
Bei diesem "Reindexing" wird Anfangs-Zeit und Ende mitprotokolliert und auch die Anzahl der indizierten Wörter wird mit ausgegeben.
.