Stehe wohl schon auf der Liste der Geächteten, weil ich immer nur meckern muß....
@hgs: das Ganze ist abhängig von den einzelnen Dateien, die gerade auf dem Server sind. Beim Einfügeproblem mit dem Bildern ist es so, das der Pfad zur config.php des CKEditors nicht mehr stimmt, weil auch da diverse Backslashes drin sind. Zum besserem Verständnis nimm dir mal die Zeit, entpacke die letzten 3 oder 4 Hauptversionen (WB 2.11, WB 2.12 usw) in jeweils einen separaten Ordner und suche dann ordnerweise nach 2 Backslashes, also \\ oder auch nach dreien solcher Backslashes und du wirst erschrocken sein, wie sich das Problem über die Hauptversionen aufgebaut hat. Und so findet der CKEditor seine config.php nicht und das Accordion-Modul (bzw. jedes andere Addon, das auch die Translate-class nutzt), eben den modul-internen Pfad nicht mehr, der zu den languages-Dateien führt.
Ergebnis sind dann Pfade, die auf dem Server nicht mehr gefunden werden. Der Patch korrigiert einige davon, die Wichtigsten.
Zum Mail-Adress-Problem: innerhalb von WB wird jeder POST-Auftrag, also das Senden von Daten zum z.b. Speichern durch eine Funktion abgesichert, die diese Daten vor dem Abspeichern in die DB entsprechend behandelt. Der spezielle Link
Quote<a href='mailto:info@meine-domain.de'>info@meine-domain.de</a>
enthält Hochkommas, rot markiert. Diese müssen für die Nutzung in der Datenbank "maskiert" werden, sehen in MySQL dann also so aus
Quote<a href=\'mailto:info@meine-domain.de\'>info@meine-domain.de</a>
Nun hat sich mit PHP8 der Fehler eingeschlichen, das diese Daten zweimal maskiert werden, was zur Folge hat, das nun auch der in der DB vorhandene Backslash vor dem Hochkomma mit zwei weiteren Backslashes "maskiert" wird. Und mit jedem Mal Speichern, werden es immer mehr und schaut nach 7 x Speichern dann so aus
Betroffen sind alle Textfelder, die zum Speichern wb-interne Funktionen benutzen, z.b. $database->escapeString
Nicht betroffen sind die Textfelder des CKEditors, weil der eine eigene Routine zur Maskierung der Texte hat
Für die Ausgabe im Frontend gilt: alles, was ausgegeben wird, läuft durch den Output-Filter. Dieser ersetzt dann z.b. die {SYSVAR:AppUrl.MediaDir} oder verschlüsselt die EMail-Adressen im Text. Für letzteres sucht der Filter nach Buchstaben- bzw Zeichen-Kombinationen, hier im Speziellen nach
href und
mailto. Kann der Filter das dann nicht sauber erkennen und trennen, kommt genau solch Ergebnis raus wie vom User sabo-! beschrieben, also ein
https://www.meine-domain.de/"mailto:info@meine-domain.de/"Unser Hauptproblem ist, das wir mit diesem Fehler unsere ganzen Datenbanken vollschreiben mit solchen mehrfachen Backslashes, egal, ob das nun Droplets sind oder Form-Einstellungen, News oder Gästebücher. Mit der aktuellsten Testversion R213 wird wohl intern viel korrigiert und das, was man gerade behandelt, z.b. WB-Optionen) wird dann sauber gespeichert, aber es ist unklar und serverabhängig, wieviele Droplets z.b. solch Eingaben kompensieren. Solch Code
$oLang->enableAddon(\'templates\\\\\'.TEMPLATE);\nfunktioniert dann eben nicht mehr bei jedem
You can donate by clicking on the button below.
Hilfe & Support (deutsch)