Fehlermeldung "session_start(): Ignoring session_start()"

[bodil]

In der Session-Thematik stecke ich so gar nicht drinne, aber du kannst mit meinem Konstrukt ja beliebige Daten ins Errorlog schreiben. Also auch

Code: Alles auswählen

error_log(var_export( ['vorher', session_status()], true));

oder

Code: Alles auswählen

error_log(var_export( ['nachher', session_status()], true));

Statt nur den Rückgabewert deiner Funktion logst du dann jeweils ein Array, in dem der Rückgabewert aber nur eins von zwei Elementen ist.
Aber ob das alles im Zusammenhang mit deiner Fehlersuche nützlich ist, kann ich dir nicht sagen.
Sehen wir uns heutabend?
viewtopic.php?p=183709#p183709

[Bernhard_4711]

Aber ob das alles im Zusammenhang mit deiner Fehlersuche nützlich ist, kann ich dir nicht sagen.

Ich kann auch nur versuchen, den Fehler einzugrenzen...
Danke für den Tipp!

[xmurrix]

Vermutlich wird die Session irgendwo in einem Modul gestartet, folgender Eintrag in der errorlog.txt ist ein Hinweis darauf:

Code: Alles auswählen

/var/www/btmr/contenido/includes/frontend/include.front_content.php(715) : eval()'d code on line 244

Im Mandantenverzeichnis werden in cms/cache/code die zusammengebauten Quellcode-Dateien der Seiten erstellt. In einem dieser Dateien wird die Session in Zeile 244 gestartet.
Du kannst in den Dateien unter cms/cache/code nach session_start() suchen, irgendwo muss es vorkommen. Oldperl hatte auch schon darauf hingewiesen.

Wenn du magst, kannst du mir gerne die Zugangsdaten per PM schicken und ich schaue mir das an. Dafür brauche ich aber einen FTP-Zugriff. Oder du schickst mir den Inhalt des Ordners cms/cache/code als Zip-Archiv, das würde auch gehen.

[Bernhard_4711]

Ich weiß. Und ich habe auch meinen Fehler gefunden: Ich habe immer nach session_start() [in kleinbuchstaben] gesucht. Wenn ich hingegen diese Begrenzung weg lasse, finden sich prompt im cache ein Dutzend Treffer, aber alle in GROSSBUCHSTABEN...
Mein Fehler... Sorry.
Und wenn ich jetzt in meinem kompletten Verzeichnis danach suche, werde ich auch prompt in sechs php- und 57 (!) xml-Dateien fündig. Das sind alles Dinge, die ich selber erstellt habe.
Zumindest die php habe ich selber erstellt.
Die xml liegen alle in /cms/data/version/module/nn (nn für eine Zahl von 59 bis 65). Woher kommen die?

Da ich aber schon so lange da raus bin, traue ich mich an diese (php) Dateien nicht mehr ran.

Ich kann das doch auch ignorieren, es sind ja nur Warnungen, richtig?
@xmurrix: ftp-Zugang habe ich leider nicht.

[xmurrix]

...Die xml liegen alle in /cms/data/version/module/nn (nn für eine Zahl von 59 bis 65). Woher kommen die?...

Die XML-Dateien sind alte Versionen der Module. Immer, wenn man über das Backend ein Modul speichert und die Versionierung ist aktiv, wird eine Sicherung des Modulcodes gemacht. Bei Bedarf kann man somit auch zur einer vorherigen Version des Moduls wechseln. Das Ganze gilt auch für CSS-/JS-Dateien, Templates und Layouts.

...Ich kann das doch auch ignorieren, es sind ja nur Warnungen, richtig?...

Ja, momentan kannst du die Warnungen ignorieren, es kann aber sein, dass dies in zukünftigen PHP-Versionen einen Fehler wirft.
Besser wäre es, alle Vorkommen von session_start() unter cms/data/modules zu prüfen und diese ggf. auszukommentieren, da die Session schon beim Initialisieren von CONTENIDO startet, also bevor der Code der Module ausgeführt wird.

[Bernhard_4711]

Besser wäre es, alle Vorkommen von session_start() unter cms/data/modules zu prüfen und diese ggf. auszukommentieren

Das habe ich jetzt gemacht und bis jetzt funktioniert die Seite immer noch, wie sie soll.
Vielen Dank.