Die typo3 Version 4.2.17 lief und läuft hervorrgend, sehr performant mit der mysql Datenbank und "myisam" !! Tabellen, also nicht mit "innodb". Wir haben nämlich keinerlei Interaktionen, der einzige, der schreibt, bin ich. Und da ist "myisam" deutlich meßbar schneller (oder performanter) als das mit Caching und Logging Features überladene "innodb".

Auch bei der 4.5, die ja als Sprungbrett zu höhrern Versionen gebraucht wird, haben wir die 4.5.40, also auch dort die letzte verfügbare Version installiert. Die typo3 Versionen 4.3 und 4.4 und 4.6 und 4.7 haben wir bewußt übersprungen.

Weiter oben Gesagtes gilt für die typo3 Version 6.2.31 LTS, von der es aber in 2020 noch ein 6.2.40 ELTS Sicherheitsupdate gibt, wobei das doch eine Menge Geld kostet.

Ganz sicher haben wir einige der haarsträubenden Klippen übersprungen, doch die Menge der immer noch vorhandenen Probleme hat viele der alten typo3ler zum Aufgeben gebracht oder genötigt oder gar gezwungen.
.

Nach unserem Einstieg mit der typo3 Version 3.8.x (irgendwann in 2003), die bereits stabil und auch auf 486ern performant lief, sind wir mit der 4.2.17 nahezu glücklich - jedenfalls für unseren Zweck einer Museumsdatenbank.

Es kam bei uns nie vor, daß wir in einem Texteditor Bilder beschneiden und verkleinern wollten. Das ist heute noch großer überladener Unsinn. Auch müssen wir nicht rechnen. An der Gestaltung von Tabellen könnte man "nice to have" Verschönerungen vornehmen, aber auch das läuft bislang super.

Wir haben uns grundsätzlich an der Gestalltungs-Maxime der FAZ orientiert, der Content in einem CMS (darum heißt das ja auch so) ist das absolut Wichtige, nicht die Spielereien mit 30 Schriftarten und mit 256 Farben. Auch das sogenannte "Responsive Design" spielt für unser Konzept keine Rolle.
.

Die Installation der typo3 Version 4.5.40 auf opensuse 13.2 mit apache 2.4.10 und php 5.6.1 sowie mariadb 5.0.11 ging leidlich gut ab, es schien zu funktionieren. Doch dann wollte das Backend keine Seiten anlegen, es war zum ko....... .

Ein bislang unbekanter Fehler tauchte auf oben im Eingabefenster auf :

2: SQL error: 'Incorrect integer value:'' for column 'backend_layout' at row 1'

und in den typo3 Foren gab es jede Menge an gut gemeinten Hilfen, die aber nicht funtionierten.

[SYS][setDBinit] = SET SESSION sql_mode=''
'setDBinit' => 'SET SESSION sql_mode = \'NO_ENGINE_SUBSTITUTION\';',

Weder die Änderungen in my.cnf noch deren Vorschläge sonstwo halfen. Darum Finger weg von der mysql Konfiguration, auf die ja mehrere typo3 Instanzen zugreifen solln.

Erst in einem russischen !!! typo3 Forum fand ich dann die richtige (korrekte) ergänzenden Zeile für die jeweils lokale typo3 conf Datei :

$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;\' . LF . \'SET SESSION sql_mode=\'\';';

Und siehe da - typo3 4.5 40 läuft. (Das war mühsam !!)
.

Wir sichern seit ca. 25 Jahren die Verzeichnisse mit dem "tar" Befehl samt Kompression als "xxx.tar.gz". Das schien auch immer zu funktionieren, außer, wenn man nicht mehr alle Ecken und Haken und Macken von "tar" im Kopf hatte.

So ist der "tar" Befehl auf eine maximale Zeilenlänge begrenzt, die auch irgendwo spezifiziert ist.

Das ist die gesamte Anzahl aller Buchstaben aller verschachtelten Verzeichnisse bis hin zur Datei-Endung ganz am Ende dieser Zeile. Und dort stehen bei uns fast nur .jpg oder .gif oder .png  oder .pdf Dateien.

So weit so gut. Nur, bei der Überschreitung dieser maximalen Zeilenlänge durch eine zu lange Verschachtelung der Verzeichnisse wird kein Fehler ausgeworfen, auch wenn die Fehlerausgabe in den tar-Optionen enthalten ist. Der Rest der Buchstaben wird einfach abgehackt bzw. abgeschnitten.

Ganz fatal wird es, wenn man es nicht kontinuierlich überprüft.
.

Mit Hilfe dieser Symlinks kann man sich das Leben einfacher machen, wenn man 8 oder 10 Web-Domains als sogenannte vhosts im Web-Verzeichnis des Servers nebeneinander betreibt und eventuell der Reihe nach von Version zu Version "hoch fahren" möchte.

Jedenfalls ist der jeweilige typo3 source Bereich nur einmal notwendig und wird auch nur einmal gepatcht, also eine korrigierte 4.2.17 oder eine 4.5.40 oder eine 6.2.31 usw. enthält alle Änderungen für alle.

Wenn man beim Sichern nicht aufpaßt, nimmt das "tar" Programm das mit den symlinks für bare MÜnze und speichert diese Sourcen auch 8 oder 10 mal - immer und immer wieder -, "tar" hat also die symlinks als solche gar nicht erkannt bzw. ignoriert.

Damit wächst die Backup-Datei natürlich ungewöhnlich stark und auf einmal hat man 150.000 oder noch mehr Dateien, die aber real nie vorhanden sind und eben 10 x 40 MB zusätzlich.

Man muß also den Backup-bash-script so intelligent gestalten, daß man die symlinks nur einmal erwischt.

Dennoch müssen die symlinks (es sind ja spezielle Datei-Einträge) mit gespeichert/gesichert werden, weil die bei der Rücksicherung sonst fehlen und dann unerwartet viel Arbeit machen.
.

Sehr bequem ist das Rücksichern eines solchen Archivs mit dem "midnight commander" (kurz "mc"). Er entpackt das Archiv mit einem Klick ins RAM und man kann komfortabel Verzeichnis für Verzeichnis kopieren. Doch auch da ist Vorsicht wichtig. Wenn zum 3. Male eine Datei angeblich doppelt vorkommt, hat die Sicherung nicht funktioniert - also höchste Aufmerksamkeit - siehe weiter oben. Auch kann der "mc" die Symlinks nicht entpacken.

tyopo3 V6.2.31 kann erst mal (auch) keine Seiten (pages) anlegen. Da auch dort geraten wird, nicht die mysql Konfiguration zu "entsichern" (strict mode = off), wurde im Installtoool unter "All configuration" ein freies Eingabefeld für solche Gegebenheien eingefügt unter "$TYPO3_CONF_VARS['SYS']". Ziemlich weit unten findet man die Kopfzeile :

[SYS][setDBinit] = SET SESSION sql_mode=''

und muß die nun nochmal ein das Feld eintragen ???? merkwürdig !!!

Der Import unserer Muster-Seite schlägt aber fehlt. Die 6.2.31 kann offensichtlich die .t3d aus 4.2.17 exportierte Datei nicht (mehr) importieren.
.
Oops, an error occurred!

uid of file usage (sys_file_reference) has to be numeric.

Daraufhin habe ich alle Testseiten wieder gelöscht, die Verzeichnisse template, css, logos (das war eines von mir) aus der 4.2.17 rüber kopiert und in dem Template der test-root Seite die mastertamplates alle 3 eingebunden. Danach habe  ich eine Test-Export- Seite mit Bildern direkt aus der 4.2.17 (also ohne den Update-Schritt über die 4.5.40) importiert und die Texte ware alle da, sogar in der Formatierung wie im Original. Die gesamten Bilder und vor allem alle Links haben aber gefehlt. Dazu gibt es aber - zwar etwas versteckt - umfangreiche Patch-Informationen. Ob die wirklich in meinen Umgebungen funktionieren, werde ich nicht mehr probieren.

Das war ja überhaupt erst mal ein Versuch, geht die Version 6.2.31 im Prinzip oder geht sie nicht.
.

Mit opensuse 42.3 und den dort installierten Modulen apache 2.4, PHP 5.5 und mariadb 10.0.xx bekommt man die typo3 6.2.31 "irgendwie" zum Laufen,

Die Performance selbst kleiner Musterseiten im Vergleich zur Version 4.2.17 ist eine reine Katastrophe. In de EDV ist ein Unterschied (also ein Rückschritt) von Faktor 3 ein Grund für einen sofortigen Rausschmiss. Nach 6 Wochen Kampf mit der Konzeption eines Upgrades auf eine aktuelle typo3 Version muß ich feststellen:

"Finger weg von allen typo3 6.2.xx Ergüssen, ein absolut unglückliche und untaugliche Ausgabe."

Auf der aktuellen opensuse 15.1 Platform mit dem PHP Downgrade von PHP 7.2 auf PHP 5.6.xx und mariadb 10.2.xx läuft man in weitere Probleme rein. Die PHP 5.6 Version wird zwar von typo3 6.2.31 noch unterstützt, jedoch die mariadb 10.2 hat mit dem PHP 5.6 Probleme und möchte PHP 7.

Im typo3 Forum wird dann gemeldet, daß es dafür auch keine Lösung mehr geben wird. Es ginge halt nicht. Doctrine unterstützt nur PHP 7.x Man solle also auf PHP7 umsteigen. Doch in anderen typo3 Publikatioen sieht man an den Grafiken, es gibt zur Zei 4 verschieden PHP 7.x Versionen, die alle untereinander nicht kompatibel sind und jede der neueren Typo3 Version benötigt eine dieser speziellen PHP Varianten und dann nur diese.
.

Das hatte ich schon mal erlebt, wie ein geniales Produkt abgestürzt war, es hatte den Namen DATALFLEX.

Ob sich ein Versuch mit der typo3 Version 7 oder 8 oder 9 oder 10 überhaupt noch lohnt ????

Wenn die Mitnahme der vorhandenen Inhalte nicht irgendwie auf die Reihe gebracht wird, ist es hoffnungslos. Wenn außerdem die Verquickung mit einer ganz speziellen PHP 7 Version und einer ganz speziellen mariadb oder mysql Version nicht aufgebrochen wird, ist auch dieses Produkt namnes typo3 tot.

In einigen Magazine am EDV-Markt wird die Glocke bereits geläutet.
.

Wenn man ausgiebig lange googelt, meist nach typo3 6.2 Fehlern, findet man immer mehr tote oder verhungerte Webseiten, die alle so um 2016 herum "abgestorben" bzw. verwaist sind.

Die ehemals glühenden Verfechter (auf den Seiten immer noch zu lesen) von typo3 haben sich im Frust über die Zukunftsstrategie und  die sichtbaren Inkompatibilitäten aus dem typo3 Bereich lautlos verabschiedet.
.