Sessions in Datenbank -> bootstrap best-practices? Ideen?

[TorbenS]

Hallo Andreas,

ich glaube, wir beide sagen eigentlich das selbe: die Session-Klasse tut eigentlich nix, ausser den Zugriff auf die $_SESSION zu kapseln, und wie Du richtig sagst, unter Berücksichtigung der FE/BE keys.

Und leider, wie Du richtig sagst, hat diese Klasse keinen tatsächlichen Einfluss auf das tatsächliche Session-Handling - das heisst, zumindest nicht auf die Persistenz der Sessiondaten.

Durch ihre bloße Existenz gibt diese Klasse jedoch für uns Entwickler die Konvention vor, diese Klasse für Zugriffe auf die Sitzungsdaten zu verwenden.

Ich hatte gehofft, dass dieses Session-Klasse ggf. statt direkt auf die $_SESSION globale zuzugreifen dies vielleicht über eine Interface-Implementierung tut, welche man für seinen eigenen Zweck (Persistenz über Datenbank) verwenden könnte.

Ist aber nicht, und so muss man nun die PHP-native Methode zum Einziehen einer eigenen Persistenzschicht verwenden (session_set_save_handler), was, wenn man das machen möchte, vor dem Aufruf der Funktion session_start geschehen muss.

Um dies zu tun, war ich auf der Suche nach einem geeigneten Hook oder config-file include, der vor dem session_start-Aufruf ausgeführt wird, in welchem ich meinen session_set_save_handler einfügen kann, statt im core code rumzufuhrwerken.

Habe aber keinen gefunden. Und deswegen bin ich hier. Und mein Lösungsvorschlag ist im Feature-Request Ticket (und im laufenden code auf'm Server). )

Macht das Sinn, was ich schreibe? Für mich ja... hoffe, es ist mir gelungen, das halbwegs verständlich zusammenzufassen.

Liebe Grüsse und sorry, wenn's etwas wirr war,

Torben

[FloB]

Ich denke, dass wir die inticonfig.php dort einbinden können, wo die Systemstandards festgelegt werden. Das wäre dann ca. Zeile 62 der intialize.php (direkt vor session_start()). Hier ständen Standardfunktionen (wie Error Handling) und Konstanten zur Verfügung, aber es wäre noch nicht wirklich etwas "passiert". Einen früheren Zeitpunkt halte ich für nicht sinnvoll (Funkionen und Konstanten kann man nicht überschreiben, jedoch die Handler-Einstellungen, wenn jemand z. B. die Fehlerbehandlung ändern möchte), ein späterer, in Hinsicht auf die Problematik in diesem Thread, auch nicht.

Anstelle der aktuellen Position der initconfig.php könnte ein Hook ähnlich dem Vorschlag von Xtra eingesetzt werden. Oder man verzichtet ganz auf diese Einstiegsmöglichkeit, denn in den config.php wäre ja theoretisch eine Eingriffsmöglichkeit gegeben – jedoch, wie Xtra schon sagte, im Scope der Config-Klasse.

Was meint ihr?

[xtra]

[...] denn in den config.php wäre ja theoretisch eine Eingriffsmöglichkeit gegeben – jedoch, wie Xtra schon sagte, im Scope der Config-Klasse.
Was meint ihr?

Und genau da sehe ich eben wieder das Problem mit dem Singleton Stack.
Man darf aus dieser Position keine DB Abfragen fahren, nicht das User object abfragen usw. da ansonsten der Singleton stack durcheinander kommt.
Einen expliziten HOOK hierzu einzufyhren waere IMO das richtige. Siehe Ticket.

[leo]

Wie steht es nun eigentlich mit den diversen Tickets zu diesem Thema (speziell #1650) aus? Das Umschalten des Backend-Theme im Benutzerprofil wird ja sowieso umgesetzt, daher geht es vor allem um die Frage aus #1882 bezüglich der Position der Einbindung der initconfig.php. Außerdem waren zusätzliche Hooks - leider ohne Code-Beispiel - im Gespräch und alternativ die Einführung eines init.d-Ordners. Was davon macht Sinn und wird tatsächlich benötigt? Oder kann ich diese Tickets schließen?

[xtra]

Also das verschieben der initconfig.php nach oben ist prinzipiell moeglich, beraubt dann jedoch alle Extensions der Moeglichkeit, die Klassen Environment, Config oder Input zu verwenden.
Ich denke hierzu(#1882) sollte man lieber eine neue Datei bootconfig nehmen.
Ich stimme dir jedoch generell zu, dass das Session handling auf Serverebene abgehandelt werden sollte und nicht im application level und somit diese bootconfig auf "wackeligen Fuessen" steht.

In Ticket #1650 ging es jedoch konkret um das Problem, dass wir die config Dateien nicht verwenden koennen, da diese aus dem Scope von Config heraus aufgerufen werden. Zu diesem Zeitpunkt ist jedoch Environment noch nicht vorhanden und obendrein auch die Input Klasse nicht.
Wenn nun ein Programmierer aus einer config.php heraus Environment oder die Datenbank instantiert (via getInstance()), so kommt der PHP stack mit den singletons durcheinander und erzeugt unschoene Exceptions welche in Datei "" auf Zeile 0 aufgetreten seien (leo.unglaub und ich haben etliche Stunden damit verbracht dies herauszufinden).

dies bringt mich nun zum naechsten Thema, der conf.d Ordner.
Wenn wir dies nun mal von Anfang an durchgehen und annehmen, wir haben einen system/config/conf.d Ordner, so stellt sich hier die Frage, wie sollen sich die Extensions dort eintragen.
Ebenfalls alphabethisch?
Dann haben wir wieder dasselbe Problem wie bei den Extensions an sich, dass wir mit endlosen zzz_blafasel.php zu tun haben werden.
Selbiges gilt auch, wenn wir pro extension neben den "normalen" config Ordnern noch einen conf.d Ordner erlauben, in welchen zusaetzliche Dateien abgelegt werden.
Bei dieser Herangehensweise denke ich an gleichlautende Namen, wie z.B. initconfig.php oder die generelle config.php.
Diese Dateien muessten dann direkt vor der jeweiligen Benutzerdefinierten-Konfiguration geladen werden.
Mockup-Code Bsp. fyr conf.d/initconfig.php:

/**
 * Include the module initialization files for init tasks.
 */
foreach (Config->getInstance()->getActiveModules() as $strModule)
{
	$strFile = sprintf('%s/system/modules/%s/conf.d/initconfig.php', TL_ROOT, $strModule);
	@include($strFile);
}
/**
 * Include the custom initialization file for additional init tasks.
 */
include('system/config/initconfig.php');

Sinn macht diese herangehensweise bislang jedoch meiner Meinung nach nur bei initconfig (lasse mich da aber gerne yberstimmen, mir faellt nur gerade kein konkretes Beispiel ein wo man andere yberschreiben wollen wyrde).

Nachteil dieser Methode ist jedoch, dass wir nochmalig durch alle aktiven extension folder gehen myssen, egal ob darin nun eine conf.d enthalten ist oder nicht.
Sollten wir obendrein noch eine bootconfig.php einfyhren wollen, so haben wir obendrein das Problem, dass zu diesem Zeitpunkt nicht bestimmt werden kann, ob eine Extension aktiv ist oder nicht (activeModules ist erst spaeter verfygbar wenn Config auch instantiiert ist, dies steht jedoch der bootconfig im Gegensatz, da selbige "vor allem" kommen soll).
Dies fyhrt dann dazu, dass wir optimistisch alle boot configs einlesen myssen.

Meine Gedanken zu diesem Thema, Diskussion willkommen.

Gruss
Chris

[TorbenS]

Hallo Allerseits,

ich bin auch nach wie vor der Meinung, dass es besser ist, wenn möglich das Session-Handling nicht in der Anwendung abzufrühstücken. Ist jedoch nicht in allen Systemen / Hostingumgebungen möglich.

Ich kann alle Einwände von xtra zu allen themen gut nachvollziehen, insbesondere das zzz_blafasel.php-Thema und die nicht besonders sparsame herangehensweise, nochmals durch alle Module zu loopen, etc.

Für mein konkretes Problem (die Sache mit den Sessions in der Datenbank) behelfe ich mir aktuell mit einem händischen reingeschebbel von

if(file_exists(TL_ROOT . '/system/localinit.php'))
{
    include_once(TL_ROOT . '/system/localinit.php');
} 

so wie ich das im Ticket als einen möglichen Weg vorgeschlagen hatte, und das funktioniert ganz gut.
Wobei ich sagen muss, dass ich den Namen "bootconfig.php" besser finde, aber das ist nur Kosmetik.

Zur Frage von Leo, ob das Ticket #1882 geschlossen werden kann: tja, weiss auch nicht. Wenn's sonst niemand ausser mir braucht/will, dann kann ich kaum mit gutem Gewissen auf "aufbleiben" plädieren und werde mir erstmal mit meinem reingehacke weiterbehelfen.

So'n Ticket lässt sich ja zur Not auch wieder öffnen, sollte irgendwann mal mehr Bedarf entstehen.

Vielen Dank euch allen für alle Beiträge zu diesem Thema!

Torben

[backbone]

Meiner Meinung nach gibt es schon sehr viele "globale" Config Files, so dass man leicht die Übersicht verliert. Wie außerdem hier schon angemerkt wurde sind die für installationsabhängige Einstellungen ziemlich gut, aber wenn man von einer Erweiterung heraus etwas machen möchte sehr "Quer-Feld-Ein"-mäßig.

Ich finde die schönste Lösung für Erweiterungen ist es, alles über verschiedene Config Files innerhalb des config-Ordners abzuhandeln. Um den Performance-Problem entgegen zu wirken, könnte man eine Art "Compiler" schreiben, der dann von allen "aktiven" Modulen alle Konfigurationen in 2-3 Bootstrap-Skripte schreibt, die an den entsprechenden Stellen ausgeführt werden. Dieser Compiler müsste dann lediglich im Installtool, beim Installieren über das Repo und beim (de)aktivieren von Modulen automatisch ausgeführt werden. Beim manuellen Installieren von Erweiterungen könnte es in der Systemwartung eine "regenerate"-Funktion geben und für Entwickler eine "regenerate per request"-Option.

[xtra]

Dieser Compiler ist ja im Endeffekt das, was ich in change-6984 fyr Version 3 gemeint habe.
Momentan steht eine Umstellung auf dieses System jedoch, meiner Meinung nach, nicht zur Debatte, da es einschneidende Veraenderungen sind, die wir in diesem merge window (Angepeiltes Release 2.9 ist der 4. Juli) defintiv nicht mehr sauber unterbringen koennen und obendrein die Betaphase bereits begonnen hat.

Eine ad-hoc Loesung per bootconfig a.ae. waere jedoch mit marginaler Gefahr verbunden dass das System ungewynschte Nebeneffekte mit sich bringt (solange keiner in diesen files Schindluder treibt).
Einfach weil es ryckwaertskompatibel ist.
Die Frage die sich nun stellt ist, jedoch, bauen wir das nun ein und schmeissen es mit Version 3 wieder raus, wo sich sowieso etliches aendern wird, oder nicht.