Session-Variable in Plugins

Hallo zusammen,

ich hab ein Problem mit $_SESSION von PHP und Wordpress. Das Problem ist, dass ich zwar Werte in $_SESSION-Variablen schreiben kann, diesen Wert dann aber nach dem Seitenwechsel nicht mehr auslesen kann.

In wp-config.php habe ich die Session mit session_start() gestartet. Ich überprüfe davon sogar, ob es eine Session-ID gibt und setze diese (um ganz sicher zu gehen) vor session_start(). Wordpress sollte also nun auch mit Sessions umgehen können.

// enable Sessions for WP
if (isset($_GET['PHPSESSID']))
{
	session_id($_GET['PHPSESSID']);
}
	
session_start();

Dies scheint mir auch soweit ok zu sein, da dann in der URL jeweils die PHPSESSID als Argument vorhanden ist. Die Session-ID wird übergeben und beim session_start() auch verwendet (was sich ja mit einem echo-Befehl einfach nachvollziehen lässt).

Soweit so gut. Zum weiteren Verständnis: Ich versuche mich gerade an Plugins und habe ein Plugin geschrieben, das nichts anderes macht, als ein Top-Level-Menu in der Administratoransicht von WP anzulegen. Unterhalb diesem Top-Level-Menu werden zwei Sub-Menus erzeugt. Das Problem ist nun, dass ich auf der Seite des Top-Level-Menu's eine Session-Variable setzen ([FONT="Courier New"]$_SESSION['TestData'] = "HELLO WORLD";[/FONT]) und deren Wert dann auf den Seiten der Sub-Menus auslesen möchte ([FONT="Courier New"]echo "SessionData:".$_SESSION['TestData'];[/FONT]). Eigentlich ja ganz einfach.

... und hier springt der Frosch ins Wasser: Nach dem Seitenwechsel von einem Menü in das nächste gehen mir die Session-Variablen verloren.

Hat mir irgendjemand einen Tipp oder hat schon jemand ähnliche oder gleiche Erfahrungen gemacht und vielleicht sogar einen Lösungsweg?

Problem gefunden in wp-settings.php

Hallo Leute,

nachdem ich im Internet nix neues oder hilfreiches zu diesem Thema mehr gefunden habe, habe ich mich halt doch mal an den SourceCode von WordPress herangewagt. So konnte ich wenigstens herausfinden wo der Frosch ins Wasser hüpft...

Nun ... hier meine Ergebnissse:

Aus welchem Grund auch immer gibt es in der Datei wp-settings.php eine Funktion names wp_unregister_GLOBALS(). Diese Funktion soll dafür sorgen, dass globale Variablen gesäubert werden. Leider beinhaltet diese Funktion auch $_SESSION. Daher werden bei jedem Aufruf von WordPress sauber die Werte in $_SESSION aufgeräumt bzw. weggeschmissen. Sehr zu meinem Erstaunen, da daher das ganze $_SESSION-Prinzip keinen Sinn macht.

Um hier nun abhilfe zu schaffen muss man folgende Änderung (Hack) vornehmen:

Hier der originale Code aus der Version 2.6.0 von WordPress:

function wp_unregister_GLOBALS() {
	if ( !ini_get('register_globals') )
		return;


	if ( isset($_REQUEST['GLOBALS']) )
		die('GLOBALS overwrite attempt detected');


	// Variables that shouldn't be unset
	$noUnset = array('GLOBALS', '_GET', '_POST', '_COOKIE', '_REQUEST', '_SERVER', '_ENV', '_FILES', 'table_prefix');


	$input = array_merge($_GET, $_POST, $_COOKIE, $_SERVER, $_ENV, $_FILES, [B]isset($_SESSION) && is_array($_SESSION) ? $_SESSION : array()[/B]);
	foreach ( $input as $k => $v )
		if ( !in_array($k, $noUnset) && isset($GLOBALS[$k]) ) {
			$GLOBALS[$k] = NULL;
			unset($GLOBALS[$k]);
		}
}

Man beachte dabei die Zeile mit ...[FONT="Courier New"], isset($_SESSION) && is_array($_SESSION) ? $_SESSION : array()[/FONT] ... Hier werden die Werte in $_SESSION in das Array aufgenommen, das schliesslich dann durchlaufen wird, um die Werte aufzuräumen (Was in diesem Falle natürlich nicht in meinem Sinne ist).

Und hier nun die modifizierte Variante:

function wp_unregister_GLOBALS() {
	if ( !ini_get('register_globals') )
		return;


	if ( isset($_REQUEST['GLOBALS']) )
		die('GLOBALS overwrite attempt detected');


	// Variables that shouldn't be unset
	$noUnset = array('GLOBALS', '_GET', '_POST', '_COOKIE', '_REQUEST', '_SERVER', '_ENV', '_FILES', 'table_prefix');


	$input = array_merge($_GET, $_POST, $_COOKIE, $_SERVER, $_ENV, $_FILES); [B]// , isset($_SESSION) && is_array($_SESSION) ? $_SESSION : array()[/B]
	foreach ( $input as $k => $v )
		if ( !in_array($k, $noUnset) && isset($GLOBALS[$k]) ) {
			$GLOBALS[$k] = NULL;
			unset($GLOBALS[$k]);
		}
}

Nach dieser Modifikation läuft das ganze wie gewünscht. Es lassen sich ohne weitere Probleme Werte in $_SESSION schreiben und lesen.

Vielen Dank für die Aufmerksamkeit und vielleicht hilfts ja auch jemand anderem weiter.

Cheers,
Bernd

... so nicht ganz richtig ...

Hallo codestyling,

dass man session_start() nur im Theme jedoch nie vor der Initialisierung von WP aufrufen sollte ist so nicht richtig, da es unter Umständen sein kann, dass man die Session auf dem Server starten muss bevor irgendetwas zum Client geschickt worden ist. Anderfalls bekommt man einen Fehler, dass die Session nicht gestartet werden kann, da schon mit dem Output begonnen wurde. Dies gilt besonders dann, wenn man Session-Cookies verwenden möchte.

Unabhängig davon wurde in anderen Foren diese Vorgehensweise vorgeschlagen ... und ausserdem gibt es immer mehrere Wege nach Rom.:-D

Im Hinblick auf Deine Ergänzung: Wie Du aus meinen vorangegangenen Ausführungen entnehmen kannst ist der Umgang mit Session-Variablen ja auch nicht das Problem. Das Problem liegt eher darin, dass die Session von WordPress bei jedem Aufruf gesäubert wird. Zumindest in der Version 2.6.0. Kannst es ja mal ausprobieren und mir dann mal Bescheid geben, ob Du andere Ergebnisse erzielst. Es sollte ja detailiert genug beschrieben sein, was gewünscht war und welchen Weg ich dazu beschritten habe. Wenn Du noch Fragen zu meiner Vorgehensweise haben solltest, dann kannst Du Dich gerne an mich wenden.:-D

Andernfalls, wenn Du eine bessere Vorgehensweise (ohne Hack) oder sogar eine gängige Lösung zu diesem Problem bieten kannst, dann wäre ich Dir um so dankbarer.

Hier ein paar Links für diejenigen, die weitere Informationen brauchen:
Search › session id
WordPress › Support » Custom Session Variables Unset immediately?
WordPress MU › setting a session variable « WordPress MU Forums
http://forum.wordpress-deutschland.org/design/22863-s…uebergeben.html

... ?

Hallo Marx,

wie Du meinst ... wäre nur schön gewesen, wenn an der Aussage von CodeStyle so ausgeführt gewesen wäre, dass man es als kleiner dummer Anfänger auch verstanden hätte, was damit gemeint war. Denn vielleicht sollte man auch die Hintergründe mitgeteilt bekommen, um es verstehen zu können. Daher danke für Deine Ausführungen, die mir den Hintergrund liefern, warum der Vorschlag von CodeStyle besser ist. Das Problem ist halt, dass man von einen Problem mit PHP-Session nicht unbedingt auf den init-Hook kommt, da die Dokumentation über die Verwendung von PHP-Session im Allgemeinen nur dünn gesäht ist ... ausser ich bin in meiner Unwissenheit über die Antwort gestolpert und habe sie als solche nicht erkannt, weil mir die allmächtige Weissheit eines "erfahrenen WordPressers" fehlt.

Entschuldigt meine Beschränktheit und Ignoranz. Ich werde versuchen mich zu bessern ...

... weitergehend

wunderbar ... mir ist eine Lösung ohne Hack auch lieber ... gibt weniger Probleme beim nächsten Update.

Nur stellt sich mir immernoch eine Frage (wenn Ihr euch hier schon als die Helden von WordPress geoutet habt): Zwar hab ich nun die SessionID von PHP für alle Links in der administrativen Ansicht, jedoch in der "normalen" Ansicht ist die SessionID nicht angehängt. Bedeutet das, dass in der "normalen" Ansicht Sessions nicht aktiv sind? Was muss man machen, dass diese in der normalen Ansicht auch angehängt werden?

SourceCode vom PlugIn

[FONT=Arial]Es ist nicht viel, aber hier das PlugIn, wie ich es auf die Schnelle mal zusammengezimmert hab.[/FONT]

<?php
/*
Plugin Name: Test Plugin
Plugin URI: http://wordpress.org/#
Description: Dies ist ein Test-Plugin
Author: 
Version: 1.0
Author URI: 
*/
function Initialize()
{
// enable Sessions for WP
if (isset($_GET['PHPSESSID']))
{
session_id($_GET['PHPSESSID']);
}
 
ini_set('session.use_trans_sid', 1);
ini_set('session.use_cookies', 0);
ini_set('session.name', 'PHPSESSID');
 
session_start();
}
function InitAdmin()
{
add_menu_page('Test', 'Test', 10, 'vhPlugInTest/admin_main.php');
add_submenu_page('vhPlugInTest/admin_main.php', 'SubA', 'SubA', 10, 'vhPlugInTest/admin_subA.php');
add_submenu_page('vhPlugInTest/admin_main.php', 'SubB', 'SubB', 10, 'vhPlugInTest/admin_subB.php');
}
// Now we set that function up to execute when the admin_footer action is called
add_action('init', 'Initialize');
add_action('admin_menu', 'InitAdmin');
?>

Denke mal, dass ich da noch was vergessen oder übersehen hab.

Cookies ...

Hmm ... für das Admin-Interface verwendet WordPress Cookies... Allerdings soll der Standarduser nicht auf das Admin-Interface zugreifen und soll nur mit dem Frontend arbeiten ... und wenn der Standarduser auf seinem Rechner Cookies nicht zulässt, dann wäre die Prozesssicherheit der Anwendung gefährdet. Die Benutzer, die auf das Admin-Interface zugreifen dürfen, denen kann ich auch vorschreiben, dass Sie gefälligst Cookies zulassen zu haben.

Natürlich stellen Cookies grundsätzlich eine Alternative dar, wenn man einfach voraussetzt, dass der Client Cookies akzeptiert. Allerdings finde ich den Cookie-Mechanismus persönlich auch etwas unschön (Daten auf dem Client-Rechner zu speichern)... und natürlich gibt es auch Vorteile von Cookies ... z.B. dass Daten Session-übergreifend gespeichert werden können. Aber das möchte ich in diesem Fall gerade nicht.

Deshalb sehe ich als einzige Variante, dass man mit einer Session via SessionID arbeitet, um Session-relevante Daten für die Dauer der Verwendung zu speichern (anmelden - abmelden eines Standardusers).

Irgendwelche Ideen?

... zum Anwendungsfall und besseren Verständnis ...

... also, um den Hintergrund meines Bedürfnisses klar zu machen:

Es gibt eine Entwicklung, die ich von einiger Zeit gemacht habe. Dabei handelt es sich um eine Arbeitsgruppenverwaltung für das Inter- bzw. Internet. Die Idee ist nun, dass ich die GUI-Verwaltung von WordPress nutzen möchte. Ebenso die Blogging- und ContentManagement - Funktionalität, um eine z.B. andere Daten und Informationen hinterlegen zu können, die nur indirekt was mit der Arbeitsgruppenverwaltung zu tun hat, aber dennoch von Interesse sein könnte. Die Arbeitsgruppenverwaltung verwendet Sessions ohne Cookies. Dabei melden sich Benutzer nicht bei WordPress an sondern bei der Arbeitsgruppenverwaltung direkt. Und das will ich eigentlich auch so belassen, aus schon vorher genannten Gründen.

Deswegen war die Idee für ein PlugIn für WordPress, das die Arbeitsgruppenverwaltung in die Umgebung von WordPress implementiert. Auf der administrativen Ebene können generelle Zugriffsdaten hinterlegt werden, z.B. Datenbankserver etc. Die soll der "normale" Benutzer auch nicht ändern können. Ein Administrator sehr wohl. Wie das alles genau funktionieren soll... das weiss ich auch noch nicht. Bin ja gerade deshalb am Testen und Ausprobieren, ob ich überhaupt die notwendigen Rahmenbedingungen für mein Vorhaben geschaffen werden können.

Aber unabhängig von meinem Bedürfnis oder meinen schrägen Ideen sollte es doch möglich sein mit WordPress und PHP-Sessions ohne Cookies arbeiten können, oder? ... oder etwa doch nicht?

... weitere Informationen ...

Hab heute Abend nochmals ein wenig Zeit investiert und versucht mehr über das Thema im Internet zu finden. Leider war ich nicht erfolgreich. Dennoch hab ich versucht noch ein bischen Licht ins Dunkel zu bringen...

Ich hab versucht mal sicher zu stellen, dass das PlugIn auch ausgeführt wird, wenn nur das FrontEnd aufgebaut wird, nicht die administrative Seite von WordPress. Dies hab ich versucht indem ich einfach die SessionID in eine Datei schreibe.

... und wie es zu erwarten war wird die Session auch brav gestartet. Aber warum (zum Teufel) wird dann im FrontEnd nicht die SessionID den Links hinzugefügt, wie es auf der administrativen Seite ja auch funktioniert? ...

Kennt einer eine Antwort zu dieser Frage?

... die Lösung?

Also ... ich hab jetzt glaube ich einen gangbaren Weg gefunden, wie ich das FrontEnd von WordPress zwingen kann Session-IDs in den Links zu übergeben. Hier ist wie ich es gemacht hab:

Es gibt die Möglichkeit mittels der Filter-Funktionalität bei der Erstellung der Links Einfluss auf die verwendete Adresse zu nehmen. So ist es ein einfaches der Adresse eine Session-ID anzuhängen. Die Filter werden direkt in der PHP-Datei des jeweiligen PlugIns gesetzt. Nachfolgend den SourceCode meines Test-PlugIns:

<?php
/*
Plugin Name: Test Plugin
Plugin URI: http://wordpress.org/#
Description: Dies ist ein Test-Plugin von VisualHome
Author: Bernd G. Scheu
Version: 1.0
Author URI: http://www.visualhome.de/
*/
// General initialization 
function Initialize()
{
 // enable Sessions for WP
 ini_set('session.use_trans_sid', 1);
 ini_set('session.use_cookies', 0);
 ini_set('session.name', 'SID');
 
 if (isset($_GET['SID']))
 {
  session_id($_GET['SID']);
 }
 
 session_start();
}
// Initialize Administration Menus
function InitAdmin()
{
 add_menu_page('Test', 'Test', 10, 'vhPlugInTest/admin_main.php');
 add_submenu_page('vhPlugInTest/admin_main.php', 'SubA', 'SubA', 10, 'vhPlugInTest/admin_subA.php');
 add_submenu_page('vhPlugInTest/admin_main.php', 'SubB', 'SubB', 10, 'vhPlugInTest/admin_subB.php');
}
add_action('init', 'Initialize');
add_action('admin_menu', 'InitAdmin');
 
// Modify any link passed to this function
function CheckLink($link)
{
 return $link.="&".ini_get('session.name')."=".session_id();
}
function CheckAttachmentLink($link)
{
 return CheckLink($link);
}
function CheckAuthorFeedLink($link)
{
 return CheckLink($link);
}
function CheckAuthorLink($link)
{
 return CheckLink($link);
}
function CheckDayLink($link)
{
 return CheckLink($link);
}
function CheckFeedLink($link)
{
 return CheckLink($link);
}
function CheckGetCommentAuthorLink($link)
{
 return CheckLink($link);
}
function CheckGetCommentAuthorUrlLink($link)
{
 return CheckLink($link);
}
function CheckMonthLink($link)
{
 return CheckLink($link);
}
function CheckPageLink($link)
{
 return CheckLink($link);
}
function CheckPostLink($link)
{
 return CheckLink($link);
}
function CheckPermaLink($link)
{
 return CheckLink($link);
}
function CheckYearLink($link)
{
 return CheckLink($link);
}
function CheckCategoryLink($link)
{
 return CheckLink($link);
}
add_filter('attachment_link',    'CheckAttachmentLink');
add_filter('author_feed_link',    'CheckAuthorFeedLink');
add_filter('author_link',    'CheckAuthorLink');
add_filter('day_link',     'CheckDayLink');
add_filter('feed_link',    'CheckFeedLink');
add_filter('get_comment_author_link',   'CheckGetCommentAuthorLink');
add_filter('get_comment_author_url_link',  'CheckGetCommentAuthorUrlLink');
add_filter('month_link',    'CheckMonthLink');
add_filter('page_link',    'CheckPageLink');
add_filter('post_link',    'CheckPostLink');
add_filter('the_permalink',    'CheckPermaLink');
add_filter('year_link',    'CheckYearLink');
add_filter('category_link',    'CheckCategoryLink');
?>

Eine Liste der verfügbaren Filter von WordPress findet man hier:
Plugin API/Filter Reference « WordPress Codex

Kommentare? Anregungen? Verbesserungsvorschläge? ... oder ist mein Vorgehen hier eventuell wieder nicht Regelkonform? ... wie auch immer ... Danke für eure bisherigen Mühen und Kommentare.:)

Danke für die weiteren Tipps

Hallo Codestyling,

danke für die weiteren Tipps. Entsprechende Überlegungen machen natürlich Sinn. Natürlich zeigt sich hier auch der Weitblick. Soweit hatte ich gar nicht gedacht, dass diese Fälle auch eintreten könnten. Naja ... man buddelt halt schon zu lange alleine in seinem eigenen Sandkasten. :-D ... Aber das ist natürlich richtig, dass solche Überlegungen immer auch in die Entwicklung mit einfliessen müssen, um eventuelle unliebsame Nebeneffekte zu vermeiden.

Also nochmals Danke für die Unterstützung und viele Grüsse an die WordPress-Gemeinde.