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ß....   

@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

<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

<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

Code: [Select]

$oLang->enableAddon(\'templates\\\\\'.TEMPLATE);\nfunktioniert 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.

[hgs]

Rückmeldung wäre gut.

@Sabo
Hast du schon ein Feedback für uns?

[sabo-!]

Hallo,

ich habe das in meinem Post falsch beschrieben. Sorry. Es war kein Update, sondern ein Umzug der Website zu einem anderen Provider. Ich bin dabei so vorgegangen, wie in dieser Beschreibung: https://help.WebsiteBaker.org/en/knowledge-base/moving-from-server-a-to-b.php

Das Problem mit den Backslashes im Footer konnte durch den Fix behoben werden. Vielen Dank.

Das Problem mit den Bildern existiert jedoch weiterhin. Ich konnte herausfinden, dass alte Bilder, die bereits (vor dem Umzug) hochgeladen wurden, eingefügt werden können, jedoch keine neu hochgeladenen Bilder, die nach dem Umzug hochgeladen wurden. Da erscheint dann das beschriebene Problem.

Neu hochgeladene Bilder sind zwar im Bereich "Medien" sichtbar, lassen sich aber nicht einfügen.

Es klappt auch nicht, wenn ich Quellcode anpasse. Ich habe also das neue Bild hochgeladen und versuche alternativ in der Ansicht "Quellcode" einfach in der Bild-URL den Namen des Bildes zu ändern. Wenn ich dann wieder zurück auf den normalen Editor schalte, erscheint statt dem Bild ein "Broken-Image", also das was erscheint, wenn die Bilder-URL nicht stimmt.

Ich habe dann das Bild per FTP in das Root-Verzeichnis der Website hochgeladen und den nochmal in der Ansicht Quellcode die Bilder-URL angepasst. Das hat funktioniert. Das Bild wird angezeigt. Also img src="https://www.meine-domain.de/media/bild1.jpg  ging nicht, aber img src="https://www.meine-domain.de/bild1.jpg ging.

Dann habe ich noch folgenden Test gemacht und das neue Bild per FTP in das Medienverzeichnis hochgeladen und konnte es dann erfolgreich ganz normal über das Bild-Einfügen-Icon in die Seite einfügen.

Es muss also mit dem Hochladen der Bilder in der Medien Verwaltung zu tun haben.

[sternchen8875]

Also img src="https://www.meine-domain.de/media/bild1.jpg  ging nicht, aber img src="https://www.meine-domain.de/bild1.jpg ging.

Bitte in Schritt 1 die WB_URL in der config.php dieser Installation kontrollieren. Hat sie ggf ein Slash am Ende? Wenn JA, unbedingt entfernen

In Schritt 2 bitte in die erweiterten WB-Optionen und dort in den Abschnitt SERVER. Ist dort das /media-Verzeichnis eingetragen und grau hinterlegt, also nicht beschreibbar?

Diese Einstellung würde ich auch direkt in der Datenbank gegenchecken, Tabelle settings, Feld: media_directory

Schritt 3: Ist eine .htaccess im Einsatz? Falls JA, bitte mal durch Umbenennen oder Verschieben in einen neu angelegten Ordner deaktivieren.

Schritt 4: Füge bitte mal nach beiden von dir beschriebenen Methoden (mein Zitat oben) je ein Bild ein. Lt deiner Beschreibung hast du dann ein nicht funktionierendes Bild und eines, das du sehen kannst. Speichere diese Section und kontrolliere im Anschluß direkt in der Datenbank in Tabelle mod_wysiwyg den dort gespeicherten Quellcode für diese Section. Mindestens ein Eintrag sollte so aussehen

img src="{SYSVAR:AppUrl.MediaDir}bild1.jpg

Bitte mal beschreiben, was da exakt für beide Bilder gespeichert wird

Es klappt auch nicht, wenn ich Quellcode anpasse. Ich habe also das neue Bild hochgeladen und versuche alternativ in der Ansicht "Quellcode" einfach in der Bild-URL den Namen des Bildes zu ändern. Wenn ich dann wieder zurück auf den normalen Editor schalte, erscheint statt dem Bild ein "Broken-Image", also das was erscheint, wenn die Bilder-URL nicht stimmt.

Interessant wäre, zu wissen, was denn als URL im Quellcode angezeigt wird, wenn du nach dem Erscheinen des Broken Image im Editor erneut auf Quellcode umschaltest.

Aktuell bin ich eher bei einer serverseitigen Problematik, z.b. einer server-interne Umleitung, wie man sie bei Subdomains findet. Eventuell auch bei einer "falschen" WB_URL, einem URL-Rewrite auf Grund von Servereinstellungen und/oder einer .htaccess

Beschränkt sich das Problem ausschließlich auf den CKEditor, könnte man zur Prüfung mal ein paar der dort verarbeiteten URL's ausgeben lassen. Aber schauen wir erstmal, was hier rauskommt.

[sabo-!]

Bitte in Schritt 1 die WB_URL in der config.php dieser Installation kontrollieren. Hat sie ggf ein Slash am Ende?
-> Kein Backslash

In Schritt 2 bitte in die erweiterten WB-Optionen und dort in den Abschnitt SERVER. Ist dort das /media-Verzeichnis eingetragen und grau hinterlegt, also nicht beschreibbar?
-> /media-Verzeichnis ist eingetragen und grau hinterlegt

Schritt 3: Ist eine .htaccess im Einsatz? Falls JA, bitte mal durch Umbenennen oder Verschieben in einen neu angelegten Ordner deaktivieren.
-> keine .htaccess vorhanden

Schritt 4: Füge bitte mal nach beiden von dir beschriebenen Methoden (mein Zitat oben) je ein Bild ein. Lt deiner Beschreibung hast du dann ein nicht funktionierendes Bild und eines, das du sehen kannst. Speichere diese Section und kontrolliere im Anschluß direkt in der Datenbank in Tabelle mod_wysiwyg den dort gespeicherten Quellcode für diese Section.
-> Im Editor und Seitenquellcode ist die Bild-URL: src="https://www.meine-domain.de/media/bild1.jpg"
In der Datenbank so: src="{SYSVAR:AppUrl.MediaDir}bild1.jpg"


Interessant wäre, zu wissen, was denn als URL im Quellcode angezeigt wird, wenn du nach dem Erscheinen des Broken Image im Editor erneut auf Quellcode umschaltest.
-> Da ändert sich nichts. Die Bild-URL meine-domain.de/media/bild... bleibt unverändert.

[sternchen8875]

Vielen Dank für deine Geduld und Mitarbeit 

Interessant wäre, zu wissen, was denn als URL im Quellcode angezeigt wird, wenn du nach dem Erscheinen des Broken Image im Editor erneut auf Quellcode umschaltest.
-> Da ändert sich nichts. Die Bild-URL meine-domain.de/media/bild... bleibt unverändert.

Das Problem ist wohl, das es derzeit niemand nachstellen kann, von daher ist das eher ein Ratespiel 

Mal zur Technik: das Bild noimage.png (rotes Viereck mit grauem Kreuz / dein Eingangs-Post) im Bilderdialog des CKEditors erscheint, wenn die im Feld "textInput" angezeigte URL zu einem Bild nicht valide ist, das dort angezeigte Bild also nicht geöffnet werden kann.

Der CKEditor-interne Filebrowser, der ja bei dir funktioniert, nutzt die WB_URL plus den Eintrag aus der settings-Tabelle zu media_dir (also media) als Startverzeichnis und hängt da noch einen Slash heran. An diese Kombination wird dann der angewählte Bildname angehängt und so entsteht die Bild-URL im Bilder-Dialog-Fenster. Ist sie einmal drin und das Bild wurde angezeigt, ist sie also valide und der Filebrowser hatte auch die Berechtigung zum lesen des Bildes.
Nun kommt ein weiteres Script und liest die URL erneut und bekommt einen Fehler

Ich les nochmal nach:

Das Problem mit den Bildern existiert jedoch weiterhin. Ich konnte herausfinden, dass alte Bilder, die bereits (vor dem Umzug) hochgeladen wurden, eingefügt werden können, jedoch keine neu hochgeladenen Bilder, die nach dem Umzug hochgeladen wurden. Da erscheint dann das beschriebene Problem.

Neu hochgeladene Bilder sind zwar im Bereich "Medien" sichtbar, lassen sich aber nicht einfügen.

Kann es sein, das deine Dateirechte nicht passen? Und war da nicht schon etwas an anderer Stelle?

Bitte mal kontrollieren im FTP-Programm im Ordner /media und bei einem Bild, das vorher schon da war und im CKEditor funktioniert und eines, das neu hochgeladen wurde und nicht funktioniert.
Bei mir in WIN_SCP mit rechter Maustaste auf ein Bild, dann Eigenschaften. Wichtig sind Eigentümer, Gruppe und der Oktalwert

[sabo-!]

Das Bild noimage.png (rotes Viereck mit grauem Kreuz) im Bilderdialog des CKEditors erscheint.

Die Rechte der Dateien im Ordner /media sind alle: rwxrwxr-x

Das Bild, das per FTP hochgeladen wurde hat: rw-r--r--

Das Bild, das über die Upload-Funktion im Bereich "Medien" hochgeladen wurde und nicht angezeigt wird, hat: rw-r-----

[sternchen8875]

Das Bild, das über die Upload-Funktion im Bereich "Medien" hochgeladen wurde und nicht angezeigt wird, hat: rw-r-----

*autsch

Wie schaut es denn in den erweiterten WB-Optionen aus bei den Rechten? Und dann dazu die Rechte, wie sie das FTP-Programm anzeigt.



Hab so den Verdacht, das du nicht unbedingt der User mit den vollen Rechten bist auf deinem Server, die Meldung der Datenbank aus dem anderen Thread würde dazu passen

[sabo-!]

In den WB-Optionen ist bei mir im Bereich "Dateien": 0640 rw-r-----
Und im Bereich "Verzeichnisse": 0750 rwxr-x---

Mit FTP kann ich sehen, dass der Ordner /media diese Rechte hat: rwxrwxr-x

[sabo-!]

Habt Ihr noch Tipps, wie ich in der Sache mit den Bild-Problemen zu einer Lösung kommen kann?

[hgs]

Wenn ich mich nicht irre, sollten
Dateien mit dem Recht 0644 (rw-r--r--)
und Verzeichnisse mit dem Recht 0755 (rwxr-xr-x)
funktionieren,

ist das so bei dir eingestellt?
Alternativ kannst du einem von uns die BE Zugangsdaten vom SuperAdmin und die FTP-Zugangsdaten per pm zukommen lassen, dann würden wir mal drüberschauen

[sabo-!]

Ich habe die Rechte des Verzeichnisses angepasst. Wenn ich danach ein Bild neu hochlade, setzt das System die Rechte dieses Bildes auf rw-r-----

Lässt sich daraus eine mögliche Lösung einschätzen?

[hgs]

Das kann ich gar nicht sagen, dass hört sich so an, als wenn der Server eine "falsche Grundeinstellung" hat.
Mittlerweile gibt es die nächste Version von WebsiteBaker, siehe oben rechts "Neuigkeiten"
Published WebsiteBaker 2.13.5 R220
2023-12-21 : download on wiki…
 Das behebt die Probleme mit den wachsenden \\\\\ und im Bereich Footer und Header ist der Button "Server durchsuchen" zum Bilder einfügen jetzt vorhanden.
Das wäre mal ein nächster Versuch.  Die zu vielen \\\\\ werden nach "speichern" automatisch entfern

[sabo-!]

Ich habe herausgefunden, dass das Problem mit den hochgeladenen Bildern bei ALLEN Websites besteht, die kürzlich von mir auf Eurer Anraten hin umgezogen sind, weil WebsiteBaker künftig Host Europe als Provider nicht supporten wird.
Ich werde das mit dem neuen Update in den nächsten Tagen bei einer dieser Website testen.

[hgs]

Welchen neuen Provider hast du jetzt?

[sabo-!]

Alle betroffenen Seiten sind bei all-inkl.com.

[sabo-!]

Ich habe jetzt auf einer der Seiten das Update installiert. Das Problem besteht immer noch. Im Quellcode ist das Bild in der Seite drin, wird aber nicht angezeigt. Alle Bilder, die über den Upload-Button hochgeladen werden, erhalten vom System die Rechte rw-r----- (0640).

[hgs]

Alle betroffenen Seiten sind bei all-inkl.com.

Da habe ich auch alle meine Domänen und den Testbereich für WebsiteBaker. Das ist sehr komisch.

[hgs]

Das Bild, das über die Upload-Funktion im Bereich "Medien" hochgeladen wurde und nicht angezeigt wird, hat: rw-r-----

*autsch

Wie schaut es denn in den erweiterten WB-Optionen aus bei den Rechten? Und dann dazu die Rechte, wie sie das FTP-Programm anzeigt.



Hab so den Verdacht, das du nicht unbedingt der User mit den vollen Rechten bist auf deinem Server, die Meldung der Datenbank aus dem anderen Thread würde dazu passen

Wie sieht diese Einstellung bei dir aus?

[sabo-!]

Wie schon oben geschrieben steht bei mir an dieser Stelle:

Dateien: 0640 / rw-r-----
Verzeichnisse: 0750 / rwxr-x---

[ruebenwurzel]

Hallo,

da scheint wohl beim Umzug was schiefgelaufen zu sein. Die Dateirechte sollten bei 644 die Verzeichnisrechte bei 755 sein. Allinkl hat einen sehr guten Support. Ruf bei denen an und schildere dein Problem. Bitte sie die Datei- und Verzeichnisrechte (chmod) entsprechend einzustellen (rekursiv, so dass auch alle Unterordner eingeschlossen sind). Lass in dem Zusammenhang auch gleich überprüfen, ob du als Dateieigentümer (chown) eingetragen bist. Wenn ich dich richtig verstanden habe, kannst du die Einstellungen für "alte" Dateien ändern, bez. sind dies richtig, nur neu hochgeladene (über php scripte vom WB Backend) bekommen falsche Rechte. Scheint für mich drauf hinzudeuten, dass es sich um eine Problem der Serverkonfiguration zu handeln. Da hast du eh keinen Zugriff drauf. Das muss sich der Support von Allinkl anschauen.

Frohe Weihnachten