Frage ist schon mal, ob man das mit Variablen oder so lösen kann, damit das bei jedem "automatisch" funktioniert. Aber da bin ich schon mal überfragt. Ich kann aber gerne was bei mir austesten, ob ich am Pfad was drehen kann oder so...
robert wrote: ↑Sun May 03, 2020 4:53 pm
Angeblich ein Sicherheitsmerkmal. Ich verstehe leider gar nicht, ob und wie diese openbasedir sinnvoll ist oder nicht.
Es kann sinnvoll sein, siehe Doku verlinkt in dem erwähnten Posting. Es ist jedoch nicht sinnvoll, das vom Provider vorgesetzt zu bekommen ohne das ändern (lassen) zu können. Ich sehe auch keinen Sinn darin, /usr/share/php (oder ähnliches) nicht im open_basedir aufzunehmen falls z.B. PEAR dort installiert ist.
Was könnte ich diesbezüglich meinen Provider fragen (außer das er mir ev. antwortet, die S9y-Entwickler mögen das anders gestalten)?
Er soll dafür sorgen, dass entweder PEAR für PHP Server-seitig installiert und mit open_basedir und include_path erreichbar ist, oder die lokale s9y-Variante.
onli wrote: ↑Sun May 03, 2020 7:09 pm
Das ist grundsätzlich blöd, weil anstatt jetzt einfach eine zusätzliche Datei anzulegen patchen wir die HTTP/Request2.
global $serendipity;
require_once "{$serendipity['serendipityPath']}/bundled_libs/HTTP/Request2/PEAR/Exception.php";
1. Gleicher Effekt wie ohne Workaround, meine Seite wird vollkommen leer angezeigt. Im Backend (das funktioniert) findet sich dann auch der Warnhinweis:
Die Javascript-Bibliothek von Serendipity konnte nicht geladen werden. Das kann aufgrund von PHP- oder Pluginfehlern, eventuell auch aufgrund eines zerstörten Browsercaches vorkommen. Um die genaue Fehlermeldung zu sehen, öffnen Sie bitte https://www.robertlender.info/blog/inde ... _editor.js von Hand im Browser und suchen nach Fehlermeldungen.
2.
Edit: Wobei mir gerade auffällt: Wir haben die Datei doch sowieso schon in bundled_libs, oder fehlt bei dir bundled_libs/PEAR/Exception.php?
Nein, die ist da. Es braucht aber anscheinend auch die Daten unter /bundled-libs/HTTP/Request2/PEAR/Exception.php. Mein Bekannter der den Workaround gebastelt hat ist aber kein S9y Kenner sondern Wordpress Entwickler. Kann daher sein, dass es auch eleganter ginge.
erAck wrote: ↑Sun May 03, 2020 7:15 pm
Er soll dafür sorgen, dass entweder PEAR für PHP Server-seitig installiert und mit open_basedir und include_path erreichbar ist, oder die lokale s9y-Variante.
Danke!! Ich schreibe mal alles zusammen und werde mit meinem Bekannten gemeinsam da mal nachfragen. Vielleicht findet sich eine Lösung. Ich werde hier berichten.
onli wrote: ↑Sun May 03, 2020 7:09 pm
Das ist grundsätzlich blöd, weil anstatt jetzt einfach eine zusätzliche Datei anzulegen patchen wir die HTTP/Request2.
global $serendipity;
require_once "{$serendipity['serendipityPath']}/bundled_libs/HTTP/Request2/PEAR/Exception.php";
1. Gleicher Effekt wie ohne Workaround, meine Seite wird vollkommen leer angezeigt. Im Backend (das funktioniert) findet sich dann auch der Warnhinweis:
Dann stimmte das nicht. Oder es ist gar die falsche Version. Was gibt
onli wrote: ↑Sun May 03, 2020 7:09 pm
Das ist grundsätzlich blöd, weil anstatt jetzt einfach eine zusätzliche Datei anzulegen patchen wir die HTTP/Request2.
global $serendipity;
require_once "{$serendipity['serendipityPath']}/bundled_libs/HTTP/Request2/PEAR/Exception.php";
1. Gleicher Effekt wie ohne Workaround, meine Seite wird vollkommen leer angezeigt. Im Backend (das funktioniert) findet sich dann auch der Warnhinweis:
Dann stimmte das nicht. Oder es ist gar die falsche Version. Was gibt
global $serendipity;
echo "{$serendipity['serendipityPath']}/bundled_libs/HTTP/Request2/PEAR/Exception.php";
require_once "{$serendipity['serendipityPath']}/bundled_libs/HTTP/Request2/PEAR/Exception.php";
aus?
Ich habe in /blog/bundled-libs/HTTP/Request2/Exception.php die Zeile 24 durch den von dir genannten Code ausgetauscht. Rufe ich mein Blog auf erscheint eine weiße Seite mit nur einer Zeile Ausgabe:
onli wrote: ↑Mon May 04, 2020 10:35 pm
Hm, sieht das nicht wie der Pfad aus, den du da selbst eingesetzt hattest? Fehlt eventuell nur der Punkt am Anfang?
Sorry, ich stehe auf der Leitung. Das bedeutet jetzt was?
Blog wird nach Aufruf vollkommen leer angezeigt. Es gibt auch keinerlei Quelltext - zumindest lt. Firefox. Auch mal die Templates_c geleert. Weiterhin erbrachte jeder reload (in zwei unterschiedlichen Browsern) eine rein leere Seite.
Okay. Ich habe da ja versucht, den String den du sonst manuell eingebaut hast, nachzubilden. Aber eben so, dass es in jedem Blog funktionieren würde. Was mein Code erstellt ist doch jetzt identisch zu dem, was du manuell einbaust, oder was verpasse ich da?
Wenn der Blog vollkommen leer ist warf PHP einen 500-Fehler und der Server ist angehalten, den zu verstecken. Das würde dann im Serverlog stehen. Normalerweise interessant da nachzuforschen, aber hier ist ja im Grunde klar wo der Fehler ist - das require_once scheint noch nicht zu stimmen.
onli wrote: ↑Tue May 05, 2020 9:09 am
Okay. Ich habe da ja versucht, den String den du sonst manuell eingebaut hast, nachzubilden. Aber eben so, dass es in jedem Blog funktionieren würde. Was mein Code erstellt ist doch jetzt identisch zu dem, was du manuell einbaust, oder was verpasse ich da?
Wenn der Blog vollkommen leer ist warf PHP einen 500-Fehler und der Server ist angehalten, den zu verstecken. Das würde dann im Serverlog stehen. Normalerweise interessant da nachzuforschen, aber hier ist ja im Grunde klar wo der Fehler ist - das require_once scheint noch nicht zu stimmen.
Danke für deine Bemühungen. Ich schau mal, ob mir vielleicht was auffällt.
Ich finde es ehrlich gesagt wenig sinnvoll, irgendwelche Dateien irgendwo hin zu kopieren, damit es zufällig bei irgendeinem Hoster funktioniert. Wir liefern das Modul bereits in bundled-libs/PEAR mit, wie Du ja später schon schriebst, und wir sollten es m.E. nicht einfach nochmal irgendwohin kopieren. Das ist - nachdem es allgemein funktioniert - ein Problem des spezifischen Hosters und/oder der spezifischen Installation.