V2.6 - Keine PHP-Umgebungsvariablen mehr? Was tun?

Nach der Umstellung gerade auf V2.6 musst eich leider feststellen, dass die in PHP allgemein verfügbaren Variablen wie $COMPIUTERNAME, $windir, $SystemDrive und vor allem die in der Umgebung angelegten Varaiblen nicht mehr vorhanden sind.

Wie kriege ich die wieder?

Liegt nur indirekt an IP-Symcon. Eher am Upgrade auf PHP 5.4.

http://php.net/manual/en/security.globals.php

paresy

Danke für den Hinweis. Habe ich gestern Nacht dann auch noch gefunden.

Wäre es bei solch „weitreichenden“ Dingen, auch wenn sie an PHP liegen (es ist ja Eure Entscheidung, welche Version ihr ausliefert und daher auch, wann solcherlei Dinge auftreten), nicht ein guter Dienst am Kunden, in der Migrationsberschreibung darauf hinzuweisen (und das vielleicht mit ein wenig plakativeren Worten wie: Achtung: Wegfall der Variablen $xxx…)?

Kann bitte jemand mit V2.6 folgendes verifizieren? Dauert keine 5 Minuten.

1.) In der _autoinclude.inc.php bitte folgende Zeilen ganz am Anfang einfügen
(Kommentierung in den Zeilen 5-13 zunächst lassen und auch das return - ja, dieses Script macht praktisch nix …):


echo $GLOBALS['_ENV']['TEMP'];
echo $GLOBALS['_SERVER']['argc'] . "
";

// ENTFERNEN DER KOMMENTIRUNG IN EINER (!!) DER NACHFOLGENDEN ZEILEN BEHEBT FEHLER IN ZEILE 2 !!!!!!!
//          GLEICHZEITIG TAUCHT NACH ENTFERNEN DER KOMMENTIERUNG DAS SUB-ARRAY IN print_r() AUF.
//echo $_ENV['TEMP'] . "
";
//$_ENV['mytime'] =  microtime( true );

// ENTFERNEN DER KOMMENTIRUNG IN EINER (!!) DER NACHFOLGENDEN ZEILEN BEHEBT FEHLER IN ZEILE 3 !!!!!!!
//          GLEICHZEITIG TAUCHT NACH ENTFERNEN DER KOMMENTIERUNG DAS SUB-ARRAY IN print_r() AUF.
//echo $_SERVER['argc'];
//$_SERVER['mytime'] = microtime( true );

print_r( $GLOBALS );
return;

Irgendein Script laufenlassen.

Gibt es die Fehlemeldungen

Notice: Undefined index: _ENV in C:\IPS\scripts__autoinclude.inc.php on line 2

Notice: Undefined index: _SERVER in C:\IPS\scripts__autoinclude.inc.php on line 3

(bei mir gibt es die Fehlermeldungen) ?

In der print_r() Ausgabe fehlen die Arrays?

2.) Kommentierungen (rumspielen) in Zeilen 7,8 oder 12,13 rausnehmen.

Wieder irgendein Script laufen lassen. Jetzt wird die Ausgabe jeweils für das nicht mehr kommentierte Array korrekt durchgeführt (bei mir schon)?

In den print_r() Ausgaben erscheinen die Arrays?

Falls das bei Euch auch so ist, kann jemand sagen, ob das eine IPS-Eigenheit ist oder ob das PHP ist und ob es dokumentiert ist oder ob es ein PHP Bug ist?

Hallo
Hab ich mal schnell getestet ist bei mir auch so.
Muss an RECURSION liegen.
http://stackoverflow.com/questions/5786067/what-does-recursion-in-print-r-output-mean

Erklaeren kann ich es auch nicht.

… bitte sehr!

  1. Man fuege die folgende Zeile in die __autoload.php ein:

$wow = 1234;

  1. Man rufe ein Script mit dem folgenden Inhalt auf:

print_r($GLOBALS);

Das fuehrt zum folgenden Ergebnis:


Array
(

... 

    [val] => 18
    [key] => THREAD
    [IPS_SENDER] => Execute
    [IPS_SELF] => 28881
    [IPS_THREAD] => 18
    [wow] => 1234
    [GLOBALS] => Array
 *RECURSION*
)

Unschwer zu beobachten, dass $GLOBALS[‚wow‘] mit 1234 belegt ist.

Ich dachte immer, dass der Inhalt der __autoload.php vor dem Script einfach ausgefuehrt wird, wie / warum landen meine Variablen in den $GLOBALS?

Viele Gruesse

Adrian

Ich zitiere mal die Doku:

http://www.php.net/manual/de/reserved.variables.globals.php

$GLOBALS — Referenziert alle Variablen, die im globalen Gültigkeitsbereich vorhanden sind

Ein assoziatives Array, das Referenzen auf alle Variablen enthält, die derzeit im globalen Gültigkeitsbereich (Scope) des Skripts bekannt sind. Die Namen der jeweiligen Variablen sind die Schlüsselwerte, um auf den Inhalt der jeweils referenzierten Variablen zuzugreifen.

@axbigo

es werden dort also einfach automatisch alle verwendeten Variablen registriert (von PHP selbst).

@1007

RECURSION ist einfach nur ein Feature von print_r. Die Funktion erkennt, dass es sich um eine Rekursion handelt und bricht die Ausgabe von $GLOBALS im Array von $GLOBALS ab!

@jwka

bei Deinem geschilderten Problem könnte es sich um eine Optimierung von PHP handeln (siehe auch obiger Link). Die entsprechenden Variablen in $GLOBALS werden also erst befüllt, wenn man auf die jeweiligen Array’s das erste mal zugreift.


echo $_ENV['TEMP'];
echo $GLOBALS['_ENV']['TEMP'];
print_r( $GLOBALS );
return;

Das Ganze hat auch nichts mit der Autoload.inc.php zu tun, tritt in jedem anderen Script auch auf.

–> $_ENV, $_SERVER usw. direkt verwenden oder in die „Autoload“ Funktion einfach einen Zugriff auf diese Variablen einbauen, dann sind sie in $GLOABLS auch immer vorhanden.

@Andreas:
Ja, natürlich tritt das Problem in jedem Script auf. Völlig korrekt.

Ich hatte nur angeregt, das in der autoload zu machen, um Nebeneffekte anderer Scriptteile von Usern auszuschliessen. Denn wenn jemand irgendwo in einem Script auf $_ENV zugreift und ausgerechnet dieses Script zum probieren nimmt, hätte es evtl. Verwirrung gegeben. Deshalb auch mein return im Beispiel.

Da ich keine Doku über das Thema (ab wann ist $_ENV in $GLOBALS verfügbar?) gefunden habe, wollte ich mal Feedback von Usern hier haben.

Bei mir ging halt nach Update gar nichts mehr, weil mein Framework im autoload als eine der ersten Zeilen Umgebungsinformationen ausliest und daraus abgeleitet Basisteile lädt.

Wenn dann halt

$_AIF[‚dir.env‘] = $IPS_GetKernelDir() . $GLOBALS[’_ENV’][‚COMPUTERNAME‘];

versagt, hagelt es nur noch Fehlermeldungen und nix geht mehr, weil natürlich alle abgeleiteten Pfade nicht (mehr) stimmen und Basisklassen, Funktionen, Arrays etc. nicht geladen werden.

Wer denkt schon dass ein Zugriff auf $GLOBALS[’_ENV’][‚COMPUTERNAME‘] jemals nicht funktionieren könnte? Das ist ja als „unterste Basis“ in PHP bei den Superglobals beschrieben.

Und dass dann $_ENV[‚COMPUTERNAME‘] funktioniert, darauf muss man auch erstmal kommen …

Vielleicht wäre es ja eine Idee, in die _autoinclude.inc.php einen Zugriff auf $_ENV & Co. einzubauen? Würde vielleicht anderen Usern irgendwann das Stolpern ersparen.