WebsiteBaker Support (2.12.x) > Hilfe & Support (deutsch)
WB 2.12 r81 - Fehler in framework\class.wb.php ODER modules\wysiwyg\save.php
kuerbis42:
@jacobi22
--- Quote ---Das System setzt voraus, das die Pfade, die dort z.b. als Bilderpfade oder interne Links eingefügt wurden, durch Plugins des Editors eingefügt wurden. Für diesen Fall ist abgesichert, das diese Pfade auch korrekt sind und der WB_URL bzw der WB_URL + Media-Verzeichnis entsprechen.
Ein interner Filter, der immer im Hintergrund läuft, sorgt dafür, das alle Platzhalter aus der Datenbank mit dem Muster SYSVAR:AppUrl.MediaDir automatisch ersetzt werden, so das im Quelltext einer Wysiwyg-Section der richtige Pfad steht, z.b. eben http://www.meine_seite.de/media/bild1.jpg
wobei das blau markierte die WB_URL aus der config.php ist, das grün markierte das Media-Verzeichnis.
--- End quote ---
Ja, ich verstehe was Du meinst, aber ich habe "nichts" gemacht - wie der Anwender jetzt sagen würde.
Also, was ich gemacht habe ist eigentlich nichts ungewöhnliches:
-> Neue Seite mit Std. WYSIWYG.
-> Überschrift.
-> Link-Text >> Link-Text markiert >> WSB-Mützen-Link-Symbol >> aus dem Medien-Verzeichnis das Bild ausgewählt >> [OK]
Seite speichern.
Seite testweise aufgerufen um den Link zu prüfen: BUMMS-> https://meineseite.de/{SYSVAR:AppUrl.MediaDir}media/bild.jpg >> Link existiert nicht.
Also kein Gefummel in den HTML-Sourcen o.ä.
Weil ich die Seite aber schnell benötigt habe, das Ganze einfach mal mit HTTP:// (anstatt HTTPS://) und dann funktionierte der Link (der dann ja auch lautete: http://meineseite.de/media/bild.jpg
Gut, dann habe ich mir mal die Sourcen angesehen - und bin auf die oben benannten Dinge gestossen.
Um es aber nochmal für mich (und vllt. andere) klar zu stellen.
Die vorgehensweise von WSB ist also:
WYSIWYG - Seite erstellen.
-> Seite speichern -> das Backend übersetzt alle URL und Pfadangaben in Variable der Form: {SYSVAR:AppUrl} und {SYSVAR:AppUrl.MediaDir}
In der DB -> Table Wysiwyg steht dann nicht "<img src='http:/www.domain.tld/mediapfad/datei.jpg'>", sondern "<img src="{SYSVAR:AppUrl}{SYSVAR:AppUrl.MediaDir}/datei.jpg">
Wenn WYSIWYG den Inhalt zum Bearbeiten der Seite wieder "abholt", dann ersetzt WSB im Hintergrund {SYSVAR:AppUrl}{SYSVAR:AppUrl.MediaDir} wieder in die (derzeit aktruelle) URL und Pfad und man editiert wieder.
So weit, so richtig?
PS: ich wollte zu Testzwecken gerade eine ganz neue WSB Installation durch führen, leider bekomme ich sofort folgende Fehler:
Error: [450] unable to write 'install presets' into table 'settings'
und unter Step 1 Please check the following requirements are met before continuing...
Please note: PHP Session Support may appear disabled if your browser does not support cookies.
Hier wundert mit "... table 'settings'" - müsste ja nach Standarteinstellung en "... table 'wb_settings'" heissen
und der 2. Punkt ist eine irreführende Fehlermeldung. Cookies sind an und es handelt sich um FireFox....
kuerbis42:
--- Quote from: kuerbis42 on August 26, 2018, 01:12:35 PM ---PS: ich wollte zu Testzwecken gerade eine ganz neue WSB Installation durch führen, leider bekomme ich sofort folgende Fehler:
Error: [450] unable to write 'install presets' into table 'settings'
und unter Step 1 Please check the following requirements are met before continuing...
Please note: PHP Session Support may appear disabled if your browser does not support cookies.
Hier wundert mit "... table 'settings'" - müsste ja nach Standarteinstellung en "... table 'wb_settings'" heissen
und der 2. Punkt ist eine irreführende Fehlermeldung. Cookies sind an und es handelt sich um FireFox....
--- End quote ---
OK, gefunden: Ich habe unter "Seitentitel" ein ' eingegeben, das wird nicht abgefangen und verursacht den Fehler.
Also müsste bei der Installation noch auf "verbotene" Zeichen untersucht oder escaped werden.
kuerbis42:
So, auch das noch.
Nachdem ich die Testseite installiert habe und es ausprobiert habe, funktionierte es wie gewollt: in der DB stehen die relativen Variablen:
<p>bilder <a href="{SYSVAR:AppUrl.MediaDir}datei.jpg">hier</a> link</p>
Beim Wiederöffenen mit dem WYSIWYG-Modul wurde es korrekt wieder in die URL zurückverwandelt - also ein Verhalten wie beschreiben, bestellt und alles schick.
ABER - und gleich zweifel ich an mir selbst - auf meiner Hauptseite das Ganze auch nochmal ausprobiert - weil ich wissen wollte, was in der DB steht. Und nun geht's auch dort.
Das muß ich doch nicht mehr verstehen, oder?
Auf jeden Fall scheint es ziemlich filigran zu sein.
Ich weiß nicht, ob wir diesen Thread jetzt schliessen, weil es geht, oder ob hier noch diskutiert wird, wie man dieses Verhalten überprüfen kann.
Trotzdem: Dank an alle für die Unterstützung.
jacobi22:
--- Quote ---Wenn WYSIWYG den Inhalt zum Bearbeiten der Seite wieder "abholt", dann ersetzt WSB im Hintergrund {SYSVAR:AppUrl}{SYSVAR:AppUrl.MediaDir} wieder in die (derzeit aktruelle) URL und Pfad und man editiert wieder.
So weit, so richtig?
--- End quote ---
nicht ganz
{SYSVAR:AppUrl.MediaDir} ist bereits der komplette Pfad, es wird also nicht "doppelt ersetzt ->
{SYSVAR:AppUrl}{SYSVAR:AppUrl.MediaDir}, sondern nur einmal :wink:
Zum Fehler bei der Installation:
--- Quote ---OK, gefunden: Ich habe unter "Seitentitel" ein ' eingegeben, das wird nicht abgefangen und verursacht den Fehler.
Also müsste bei der Installation noch auf "verbotene" Zeichen untersucht oder escaped werden.
--- End quote ---
Sicherlich eine wichtige Information für Tester und Entwickler (Y)
DarkViper:
--- Quote from: kuerbis42 on August 26, 2018, 01:32:54 PM ---Error: [450] unable to write 'install presets' into table 'settings'
und unter Step 1 Please check the following requirements are met before continuing...
Please note: PHP Session Support may appear disabled if your browser does not support cookies.
Hier wundert mit "... table 'settings'" - müsste ja nach Standarteinstellung en "... table 'wb_settings'" heissen
--- End quote ---
zu 1.: ist noch ein kleiner Bug im Installer. Es fehlen noch die escapeString() Funktionen beim Schreiben der Tabellen. Dadurch führt das ' zu Fehlern in den SQL-Statements.
zu 2.: die Fehlermeldung bedeutet, dass eine oder mehrere der Möglichkeiten bestehen: a. der Browser hat Probleme mit den Cookies; b. in der Serverseitigen php.ini ist der SessionSupport deaktiviert oder aber c. PHP kann die Session nicht auf die Festplatte schreiben (Schreibrechte, volle Platte etc..).
zu 3.: Intern wird oft nur der eigentliche Tabellenname ohne den individuellen Präfix benutzt. Gelegentlich wird das halt auch nach außen sichtbar.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version