Hallo zusammen,
@Faar:
In der Tat hatte ich hier doppelt Glück. Die 2008er Installation von contenido war schon immer auf UTF-8 und als Backend mysqli eingestellt.
> Was passiert, wenn z.B. kein Wert übermittelt wird, eine Variable also "leer" ist?
Das ist in der Tat scheinbar eine prinzipielle Contenido Kinderkrankheit und in der Tat gut, dass mySQL 5.7 hier etwas strikter ist.
Ich hab das zuerst ganz stumpf im FrontEnd-Code so gefixt:
Dann hab ich gesehen, dass php ternäre Operatoren kann (Juhu!) und ferner andere Personen auch ähnliche Strukturen eingebaut haben.
Bessere Version also:
Dann ist mir gestern beim Fahrrad-Fahren eingefallen, dass ja sowiese Backend-Code zum escapen der DB-Strings vorhanden ist
und sinnvollerweise erweitert man hier auf die Wandlung '' -> '0' (leerer Wert aus HTML nach 0 für die DB).
Also in der Funktion Contenido_Security::escapeDB diesen Operator einbauen und dann findet man auch automatisch
alle weiteren Stellen im Projekt die nicht konsequent bei DB-Calls escapen.
Das wäre der eine Punkt, der andere ist der dämliche Timestamp. Ich find timestamps mit dem Wert: 000 eigentlich
zweckfrei, es sieht danach aus, dass Contenido diese Zeit als inaktiv oder aktuell ungültig oder in diese Richtung interpretiert.
Auch hier sehe eine Code-Verbesserung wenn man sich konzeptionell dazu entschliesst Timestamp mit dem Wert 0 als irrelevant
für die Programm-Logik anzusehen.
Bspw. für die Gültigkeit des User-Logins:
Die Abfrage
Code: Alles auswählen
AND ( valid_from <= NOW() OR valid_from = '0000-00-00')
AND ( valid_to >= NOW() OR valid_to = '0000-00-00' )";
Verliert nichts an Aussagekraft, wenn ich die so formuliere und wird gleichzeitig klarer lesbar:
Damit wären beide symptomatischen mySQL-Fehler behoben und die Programmlogik / Lesbarkeit (Abfangen von Fehleingaben) verbessert.
Konsequenterweise müssen dann auch alle Contenido-DB-Timestamps nicht mehr mit 000 vorbelegt sein, sondern mit CURRENT_TIMESTAMP.
Ich hatte soetwas in den Upgrade-Skripten für die 4.9 erwartet, aber nicht gefunden (?) oder es ist nicht angedacht (Feedback hierzu erwünscht)
@Oldperl
In der Tat, die Warnungen der php7er Version zu ersetzen sprengt den Rahmen meiner Möglichkeiten, da müsste mehr und noch konsequenter
umgeschrieben werden.
Ferner waren es auch mehr als die eine Tabelle, ich hab jetzt ca. 8 Tabellen angefasst. Folgende Pfade sind im Backend damit möglich:
- Artikel anlegen löschen
Artikel duplizieren
Kategorie anlegen löschen
Baumstruktur navigieren
Dateien hochladen (FileSystem)
Artikel Eigenschaften und Konfiguration ändern
Artikel ediiteren
Offen wären dann noch dbfs-Filesystem. Newsletter. ModRewrite.
Andere Plugins oder Module sind nicht im Einsatz, bzw. die hab ich selber im Griff.
Ich häng noch meinen schlampigen diff an, der die wenigen Änderungen im Backend beschreibt, dass ist mehr informativ als alles andere.
Ich hätte eigentlich viel lieber ein Upgrade auf die 4.9 gemacht und die DB-Änderungen dann direkt in einem ordentliche DB-Upgrade-Skript
wieder dem Projekt zu Verfügung gestellt.
Wie gesagt, ich war zu blöd oder zu ungeduldig diese Skripte in der aktuellen 4.9.9 zu finden.
Ansonsten, super, dass es Faar inspiriert hat, dass mal selber durchzuführen.