WebsiteBaker Community Forum
WebsiteBaker Support (2.13.x) => General Help & Support => Topic started by: gurkenhals on December 07, 2025, 01:30:09 PM
-
Moin zusammen,
danke, dass ihr mich wieder reingelassen habt! Ich war lange nicht mehr im Forum, das heißt ja eigentlich, es läuft! :-D
Jetzt bin ich allerdings auf einen neuen Hoster gewechselt und bekomme auf zwei Seiten, die über SectionPicker (unterschiedliche sid) PHP-Skripte einbinden, jeweils die gleiche Fehlermeldung. Ich vermute eher ein Rechteproblem mit dem Server, was ich erst morgen abklären kann, aber vielleicht gibt es hier im Forum schon Anregungen oder gar Lösungen zum Thema.
Auch ein Upgrade auf 2.13.9 r25 brachte keine Abhilfe.
Fehlercode: [22] fgetcsv(): Argument #1 ($stream) must be of type resource, false given
(Im Übrigen habe ich nun erst mitbekommen, dass luisehahne verstorben ist. Von daher mein herzliches Beileid allen, die ihm näher standen.)
Und allen einen schönen zweiten Advent!
-
eigentliche Ursache ist wohl, das fopen() das Ziel nicht findet bzw nicht öffnen kann oder darf
Daraus resultiert dann der Rest in deiner Fehlermeldung - fgetcsv() bekommt ein false, kann den Inhalt nicht lesen
prüfe die Pfade zu den Scripten, die du dort einbindest. Vieles klärt sich schon, wenn man den WB_PATH ausgibt und dann vergleicht mit den Angaben in deinem Script
z.b. so (vor der Definition des Pfades, den du da für fopen() festgelegt hast
var_dump(WB_PATH);
P.S.: Willkommen zurück!! :wink:
-
Ich binde üblicherweise über [[SectionPicker?sid=4]] ein, im zweiten Fall natürlich mit 'ner anderen ?sid. Die SIDs passen noch, da ist ja im Zuge des Wechsels nichts geändert worden.
Das Modul Code2 und SectionPicker wurden nach Auftreten des Fehlers neu installiert.
nicht öffnen kann oder darf
- nicht öffnen darf ... ?
Die Skripte laufen übrigens über Code2 ...
-
deine Fehlermeldung besagt, das hier eine Textdatei eingelesen werden soll, d.h. Dateiformat *.txt oder *.csv oder *.dat oder oder. Die Verwendung von fgetcsv() verweist dabei explizit auf eine Datei des Typs *.csv. Für die Adressierung ist üblicherweise der Serverpfad nötig und dieser Serverpfad lautete beim vorherigem Provider vielleicht /home/deinUsername/www/httpdocs/media/data.csv und lautet beim neuen Anbieter dann /srv/www/vhosts/deinUsername/httpdocs/media/data.csv
Darum ist der erste Test: diesen Serverpfad kontrollieren
Lege dir eine (private) Seite mit einer Code- oder Code²-Sektion an, füge diesen Code ein
echo WB_PATH;und rufe diese Seite im Frontend auf. Kopiere diesen Code, füge ihn in eine Textdatei ein und entferne diese Code-Seite wieder im Online-Projekt. Der echte Serverpfad hat niemanden zu interessieren, aber so geht halt am Einfachsten.
Dann mußt du in deine Code²-Abschnitte, die nicht funktionieren, und diesen Pfad kontrollieren. Meist wurde es so verwendet:
$handle = fopen("pfad/zur/datei.csv", "r");
if ($handle !== FALSE) {
while (($data = fgetcsv($handle, 1000, ",")) !== FALSE) {
// deine Ausgabe...
}
fclose($handle);
}
Für den Fehler interessant der Pfad in Zeile 1. Das ist halt meine Vermutung...
nun kann man den Pfad so oder so schreiben
direkt so - der komplette Serverpfad, den z.b. auch ein gutes FTP-Programm ausgibt
$handle = fopen("/srv/www/vhosts/deinUsername/httpdocs/media/data.csv", "r");
oder (besser) so - basierend auf die WB-Installation und so auch umzugssicher
$handle = fopen(WB_PATH."/media/data.csv", "r");
nicht öffnen kann oder darf
- nicht öffnen darf ... ?
Ja, natürlich gibt es auch serverseitige mögliche Beschränkungen, z.b. die Einstellung im PHP open_basedir
Liegt die Quelldatei nicht auf dem gleichen Server, käme auch CSP in Frage (Content Security Police)
Mit den Addons, die du innerhalb von WB verwendest, hat die Problematik wenig zu tun. Ob du die Daten über den SectionPicker, Code oder Code², Droplet oder direkt aus dem PHP der index.php holst, ist dabei egal
-
Danke Dir, jetzt läuft's wieder. (Y) Es war tatsächlich der Serverpfad zu bestimmten .txt-Dateien, der jetzt so völlig anders aussieht!