WebsiteBaker Support (2.13.x) > Hilfe & Support (deutsch)
Problem Bild einfügen und Link in Fußzeile
sabo-!:
Hallo,
nach dem letzten Update lassen sich keine Bilder mehr einfügen. Im Bereich Medien lässt sich das Bild zunächst erfolgreich hochladen und wird auch in der Vorschau angezeigt. Will man es dann in der Seite über das Bild-Einfügen-Icon einfügen, ist die Vorschau des Bildes leer und bei Einfügen erscheint stattdessen ein X mit einem WebsiteBaker-Infotext.
Im Bereich Optionen war immer schon ein mailto-Link eingefügt. Im Backend fügt das System jetzt nach dem Update vor und nach den Anführungszeichen drei Backlash ein.
<a href=\\\'mailto:info@meine-domain.de\\\'>info@meine-domain.de</a> im Frontend ist statt dem Mail-Link folgendes verlinkt: https://www.meine-domain.de/"mailto:info@meine-domain.de/" Es wird also vor dem mailto-Link die URL der Website hinzu gesetzt.
WB-Version 2.13.4 r199, PHP 8.2, Ausreichende Schreib- und Leserechte in den Ordnern media und pages sind gesetzt.
Für Hilfe wäre ich dankbar.
Grüße
Sabo
dbs:
Hallo, das Problem mit Slashes ist bekannt und gefixt, nur leider noch nicht veröffentlicht.
Im Anhang findest du den Fix. Den Inhalt des Zips in dein Hauptverzeichnis kopieren.
Rückmeldung wäre gut.
hgs:
Ich kann das Problem mit den Bildern nicht bestätigen. Zu den sich vermehrenden ///// hat dbs ja schon das Patch gepostet.
Ist eine WB 2.13.4 r199 mit PHP 8.2.9 als Neuinstall.
Es wird alles sauber im BE und FE angezeigt.
Bei dir wird es wahrscheinlich ein upgrade gewesen sein.
Wie hast du es gemacht?
Wir empfehlen die Methode mit unzip.php wie sie im DUKU Ordner beschrieben ist.
Siehe diese kleine Video
https://r199.wb.umojasingers.de/
Das 1. Bild habe ich gerade eingefügt.
https://gyazo.com/e794c49c08a06154c500dc13f22f1ed8
sternchen8875:
Stehe wohl schon auf der Liste der Geächteten, weil ich immer nur meckern muß.... :cry:
@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>
--- End quote ---
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>
--- End quote ---
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
--- Code: ---$oLang->enableAddon(\'templates\\\\\'.TEMPLATE);\n
--- End code ---
funktioniert dann eben nicht mehr bei jedem
hgs:
Jetzt wird einiges klar, und da ich bei einer Neuinstall getestet habe, kommt das Problem nicht auf.
Danke für die Aufklärung.
Navigation
[0] Message Index
[#] Next page
Go to full version