WebsiteBaker Community Forum
WebsiteBaker Support (2.13.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: sabo-! on November 24, 2022, 02:20:44 PM
-
Hallo,
ich habe bei einer Website ein Update von 2.8.3+SP4 (r1641) auf die aktuelle Version gemacht. Lokal auf dem Testserver läuft alles. Nachdem die Website live (Server von Host Europe) gestellt wurde, kommt es zu folgendem Fehler: Alle eingefügten Bilder haben folgende URL: src="{SYSVAR:AppUrl.MediaDir}foto.jpg". Ändere ich im Quellcode die URL auf src="http://www.meine-website/media/foto.jpg" und klicke auf Speichern, ändert das System die URL wieder zurück auf {SYSVAR:AppUrl.MediaDir}
Wie kann ich das lösen?
Danke schon mal.
Sabo
-
Gibt es ein Problem mit dem Anzeigen der Bilder?
-
Was meinst du mit Quellcode? Meinst du den Quellcode im WYSIWYG-Editor oder in der Datenbank?
-
Die Bilder werden dadurch auch nicht angezeigt. Mit Quellcode meinte ich den im WYSIWYG-Editor.
-
{SYSVAR:AppUrl.MediaDir} ist ein Platzhalter, der normalerweise im Front- und Backend durch den Outputfilter ersetzt wird. Das funktioniert allerdings eher unsichtbar durch zwei Funktionen einmal beim Speichern einer Wysiwyg-Sektion und einmal beim Einlesen aus der Datenbank für die Bearbeitung im Backend oder für die Ausgabe im Frontend. (Front- und Backendausgabe verwenden hier den gleichen Filter. Wird der Platzhalter im Frontend nicht umgewandelt, im Backend aber schon, liegt ein PHP-Fehler im Frontend-Template oder bei einem der auszugebenen Module vor. (view.php der eingesetzten Module). Ist es umgekehrt, Frontend wird der Platzhalter ersetzt, im Backend nicht, liegt der Fehler eher in den modify.php der dort für diese Seite eingesetzten Module)
Sinn dieser Funktionen ist es, das bei einem Serverumzug keine Ersetzungen der Webadressen im Backupf-File mehr nötig ist.
Die Funktion ReplaceAbsoluteMediaUrl() ist dabei für das Umwandeln der aktuellen URL in den Platzhalter zuständig und wird im WB-Paket in den Modulen News und Wysiwyg eingesetzt. In meinen Modulen wäre diese Funktion überall drin, ob es noch für andere Autoren gilt, weiß ich nicht, wäre aber gut möglich, da es diese Funktionen auch schon 7 Jahre oder so gibt. Im Grunde also immer da, wo der Wysiwyg-Editor im Einsatz ist.
Beim Einlesen der Inhalte aus der Datenbank wird für Front- und Backend die Funktion ReplaceSysvar() verwendet. Sie wandelt den Platzhalter wieder zurück in die Kombination aus WB_URL und Name des Media-Verzeichnisses
Das Ganze funktioniert allerdings nur unter zwei Bedingungen:
a: bei Einlesen der Daten für's Front- oder Backend gibt es keinen PHP-Error, der die Ausführung des Scriptes unterbricht. Das wäre z.b. erkennbar, wenn nach dieser WYSIWYG-Sektion später zu ladene Dinge nicht erscheinen, z.b. im Frontend die Footerleiste des Templates oder im Backend weitere Abschnitte nach dieser Wysiwyg-Sektion.
b: die URL, die das System ermittelt, muß identisch sein mit der URL, die in der config.php eingetragen wurde. Zum Ersetzen muß dieser Pfad gültig sein.
Die von dir erwähnte Alt-Version hatte diese Filterfunktionen noch nicht, das macht es notwendig, jede Wysiwyg-Section im Backend einmal zu öffnen und dann zu speichern oder einmal das große UpgradeScript laufen zu lassen (WB-Info-Fenster).
Was kannst du tun?
- kontrolliere zuerst in den erweiterten WB-Optionen und Block "Servereinstellungen" die dort festgelegten Ordner für das Seiten- und Mediaverzeichnis. Standard wäre /pages bzw /media
- im gleichen Block "Servereinstellungen" der WB-Optionen / erweitert stehen oben die Einstellungen für PHP-Fehlerberichte. Stelle diese bitte auf "Development". Achte in der Folge stets auf das X im oberen Haptmenü des Backends. Ändert sich die Farbe von grün auf gelb oder gar Rot, gibt es PHP-Fehlermeldungen in der error.log (https://i.gyazo.com/32ed8b6c6bf394a60d5bc2310e88f0d8.png)
- zuerst lege dir eine Testseite mit einer Wysiwyg-Sektion an und füge dieser Wysiwyg-Sektion über den Wysiwyg-Editor ein Bild aus deiner Media-Verwaltung zu, idealerweise eines, das direkt im media/Ordner liegt. Kopiere den vom Wysiwyg-Editor ermittelten Bilderpfad in eine einfache Textdatei, die du als Notizzettel benutzt.
Man könnte dazu auch eine existierende Seite aus der WB-Seitenübersicht verwenden, die Verwendung einer neuen Seite mit Wysiwyg-Editor schließt aber aus, das hier ggf noch PHP-Fehler aus anderen Sectionen mit einfließen.
Nun speichere diesen Wysiwyg-Abschnitt und kontrolliere, ob der Pfad umgewandelt wurde in den Platzhalter. Das geht entweder direkt in der Datenbank oder über den Umweg Backup-Modul (https://addon.WebsiteBaker.org/pages/en/browse-add-ons.php?id=0EE27675) (aus dem Addonbereich) und das Erstellen eines Datenbank-Backups, das man dann vom Server herunterläd und in einem Editor wie Notepad++ öffnet.
Zu kontrollieren wäre auch, ob die Schreibweise des Platzhalters korrekt ist. Richtig wäre:{SYSVAR:AppUrl.MediaDir}
Als diese Funktion damals eingeführt wurde, gab es auch andere Varianten, z.b. {SYSVAR:MEDIA_REL} oder {SYSVAR::MEDIA_REL}
Seit WB 2.10 sucht der Outputfilter beim Einlesen des Contents nach genau diesem Schnipsel {SYSVAR:AppUrl.MediaDir} und würde ihn nicht finden, wenn er manipuliert worden wäre.
Nun öffne die Datei config.php im Hauptverzeichnis des (Online-)Servers und kopiere die dort eingetragene WB_URL, füge sie in deine Notizdatei als neue Zeile direkt unter dem Pfad des Bildes ein. Vergleiche dann Zeichen für Zeichen der Bilder-Adresse mit der WB_URL aus der config.php
Achte auch darauf, das die WB_URL in der config.php keinen Slash am Ende hat. Die Bildadresse muß das in den erweiterten WB_Optionen eingetragene Media-Verzeichnis haben, welches ebenfalls keinen Slash am Ende haben darf.
Ursache für das Nichtfunktionieren sind oft Diskrepanzen zwischen der definierten WB_URL und dem vom System ermittelten Pfad, z.b. wenn sich das WB-System in einem Unterverzeichnis befindet, dieses Unterverzeichnis aber durch den Domainzeiger "versteckt" wird.
Beispiel: WB ist installiert im Unterordner /test der Domain abc.test, dann wäre der Bilderpfad vom System ermittelt etwa abc.test/test/media/bild.jpg
Über den Domainzeiger oder auch über Domain-Umschreibungen läßt sich dieser Pfad so verändern, das er nun lautet abc.test/media/bild.jpg
In den allermeisten Fällen tritt ein Problem mit diesen zwei Funktionen eher beim Schreiben der Daten auf, also beim Speichern der Wysiwyg-Sektion.
Ein Fehler beim Einlesen, also der Ausgabe im Front- oder Backend ist zu 99% immer Folge eines PHP-Fehlers, da solch Fehler den Outputfilter stoppt und dieser dann den Content nicht mehr durcharbeiten kann.
Das letzte Prozent sind dann falsche Bildadressen, z.b. ein http vs https, ein doppelter Slash, die erwähnte "falsche" URL in der WB_URL. In diesem Fall muß aber die Umwandlung im Backend, z.b. im Wysiwyg-Editor-Quelltext erfolgen
-
@sternchen8875
Ich liebe deine Erklärungen :-). Besser kann mans nicht machen.
-
Danke für die Blumen...
Ist aber nur okay, wenn es auch das Problem löst
-
Vielen Dank für die nützlichen Hinweise. Leider bin ich nicht weiter gekommen.
In den erweiterten Optionen bei Servereinstellungen stimmen die Einträge /pages und /media.
Ich habe eine Testseite angelegt und ein bereits hochgeladenes Bild aus dem Mediaverzeichnis eingefügt. Solange ich nicht auf Speichern klicke, wird das Bild angezeigt und der Pfad ist richtig, wenn im Editor auf "Quellcode" klicke. Der Pfad lautet: http://www.meine-website.de/media/foto.jpg
Nach dem Klick auf "Speichern", wir das Bild nicht mehr angezeigt und der Pfad ist geändert in: {SYSVAR:AppUrl.MediaDir}foto.jpg
PHP-Fehlerberichte habe ich auf "Development" gestellt.
Das X im oberen Hauptmenü des Backends ist grün.
Die WB_URL in der config.php ist richtig und ohne Slash am Ende eingefügt.
Bzgl. des vom System ermittelten Pfads: Die Website liegt im Root-Verzeichnis des Servers, also kein Unterverzeichnis.
-
Du sagst, es war ein Update von WB 2.8.3 SP4 auf die aktuell Version WB 2.13.2 R133?
Kontrolliere bitte mal den im Bild gezeigten Ordner /modules/output_filter/Filters. Es geht im Speziellen um die Anzahl dieser Dateien und deren Namen und vorallem um Groß- und Kleinschreibung der Ordnernamen, hier z.b. der Ordnername /Filters, der früher klein geschrieben wurde.
P.S.: für ein lokales Testsystem unter Windows spielt Groß- und Kleinschreibung keine Rolle, wenn man diese Dateien dann aber auf einen Linux-Server verschiebt, bekommt man Probleme, weil dort zwischen Groß- und Kleinschreibung unterschieden wird.
Sollten dir beim Vergleich der Datei- und Verzeichnisnamen Unterschiede auffallen, würde ich dazu raten, die Dateien des WB-Paketes auf dem Server zu löschen und dann das neu heruntergeladene ZIP-Paket von WB (https://addon.WebsiteBaker.org/pages/en/browse-add-ons.php?id=0C4CF2A5) als ZIP auf den Server zu laden und mittels der Datei unzip.php (https://addon.WebsiteBaker.org/pages/en/browse-add-ons.php?id=04D6D0F4) zu entpacken
(https://i.gyazo.com/e20977b6e24afb4f769cae523d79c719.png)
Bringt das auch noch keine Besserung, sollte vielleicht mal jemand direkt draufschauen. Dann müßte man aber über echte Pfade sprechen, nicht mehr über Aliase. Von daher wäre eine PN vielleicht der bessere Weg.
-
Jetzt hat es geklappt. Super! (Y)
Der Ordner hieß bei mir "filters". Ich habe ihn in "Filters" umbekannt.
Die Groß- und Kleinschreibung innerhalb des Ordners entsprach Deinem Screenshot.
Aber es befand sich eine Datei "filterRelUrl.php" darin, die in Deinem Screenshot nicht vorhanden war. Ich habe sie testweise umbenannt in "filterRelUrl.php_".
Und dann: Taadaaaa wurden alle Bilder angezeigt, sogar ohne, dass der Pfad angepasst werden musste.
Vielen Dank :wink:
-
Aber es befand sich eine Datei "filterRelUrl.php" darin, die in Deinem Screenshot nicht vorhanden war. Ich habe sie testweise umbenannt in "filterRelUrl.php_".
Diese Datei kannst du löschen. Dessen Aufgabe übernimmt jetzt der Ordner RelUrl innerhalb des Filters-Ordners