global variables

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I dont think I understand them. I've read the section on scope in the
manual inside out.

 I'm running PHP 5.2.0 Here is the code I'm working on:
$MYVAR = array();
global $MYVAR, $a;


global $MYVAR, $a;

$sname = 'user';
$email = '';
$GLOBALS['a'] = 'here';

$MYVAR['sname'] = $sname;
$MYVAR['email'] = $email;
$MYVAR['age'] = 34;

print "SNAME: <br>";
print "EMAIL: <br>";
print "AGE: <br>";
print "A: $a <br>";

print '<a href="./array2.php">Next</a>';



global $MYVAR, $a;

$sname = $MYVAR['sname'];
$email = $MYVAR['email'];

print "SNAME: $sname <br>";
print "EMAIL: <br>";
print "AGE: <br>";
print "A: $a <br>";


When I load array1.php, I see:
SNAME: user
AGE: 34
A: here

Click on Next, and I see:

Can I preserve the changes across page loads with globals?


Re: global variables

Sandman wrote:
Quoted text here. Click to load it

No. The global keyword is used to import variables into a function's  

$a = 1;

function foo() {
    global $a;
    print $a;


What you are looking for are sessions or cookies:


Re: global variables

Sandman schrieb:
Quoted text here. Click to load it
Global variables are pretty much the variables you shouldn't use at all  
if you plan on writing PHP applications that are stored in more than  
like three files. Global variables make all kinds of problems:

- They are shared across all files of your program. If you decide to  
reuse parts of your program in another project you have to make a list  
of all global variables so you dont' run into collisions with the  
variables of your new project.

- If you use external packages then you don't know which global  
variables this package might use. Common variables like $name are easily  
overwritten and hell breaks loose. This problem is known as "pollution  
of the global namespace".

- Depending on the server config (register_globals) the visitor can send  
you global variables. This makes them insecure because you can't trust  
the contents of global variables. An important rule in web programming  
before using them. Or... don't use them.

- Global variables in PHP are not as global as they are in other  
languages where you can sometimes always see the global variables. Some  
languages even have the keyword "local" to prohibit a variable from  
becoming global. PHP instead has the "global" keyword to define a  
variable as global. But better forget this keyword for larger projects!

The best alternative to global variables are static class variables:

class MyVars
   static $var1='value1';
MyVars::$var1 = 'huba';

Side note: And using a rare (best: unique) prefix for all classnames  
ensures that you can share the code with other projects without  
problems. Prefixes are PHPs poor excuse for namespaces until they  
hopefully become available at some point. Those ugly reverse domain  
based namespaces in Java have a purpose: They ensure uniqueness.

Quoted text here. Click to load it

Nope. Basic rule: PHP is stateless. You lose everything after the  
request is served. Every PHP script on a webserver is started after a  
request is made. The script can receive input in the form of four  
different concepts:

G - GET data, this is the URL, variables are transferred in the  
?var=value&var2=value2. This data has "view persistence", it is tied to  
the browser window. Hit F5 and the same data is submitted again. All is  
stored in the URL. You can even bookmark the data. GET data is limited  
in its length, it may not exceed a few kilobytes, depending on browser  

P - POST data, this is normally generated when you submit a form. The  
variables are transferred in a similar format to GET, but this time in  
the body of the request and not in the URL. This data has "limited view  
persistence". The browser may ask you if you want to resubmit the form  
data if you hit F5 but normally the data is lost once the form has been  
processed. POST data may be huge, in case of file uploads it can be  
several megabytes big.

C - COOKIE data, this is stored in the visitor's browser if the browser  
accepts cookies. Cookies data has "session persistence" or even  
"multi-visit persistence", depending on the settings in the visitor's  
browser and the expiration time you set for the cookie. This data is  
shared across all windows or tabs a visitor opens when browsing your  
site because it is bound to the domain. DO NOT RELY ON COOKIES because  
visitors may choose not to accept any cookies.

S - SESSION data, this is stored on your server, by default in a simple  
file in a temp directory. From the persistence point of view it is much  
like cookie data, but you can't normally define how long the data will  
survive. Don't expect the session data to last longer than, well a  
visitor's session when browsing your site. The problem with sessions is  
that you have to know which session data belongs to which visitor  
because they are not implictly connected. This connection is established  
with the session ID. This is a variable that has to be transfered from  
request to request via the G, P or C method. The PHP session functions  
are good at automatically transferring the session ID from request to  

This GPCS scheme is accompanied by E, the environment information about  
the server on which your PHP is running. The combination EGPCS is the  
default value for the configuration directive varaibles_order (see ). This  
directive defines a) which of the data sources as input for your script  
are used and b) which data comes through if there are variables with the  
same name. P comes after G, so a POST variable overwrites the GET  
variable of the same name.

REMEMBER: Session data is usually shared among all open windows of a  
visitor just like the cookies! To store values of a multipage-form in  
the session you cannot simply write the data into the session. What if  
the visitor opens the same form twice? You have to work with an array  
and a unique form instance identifier as key in the array. Or you use  
hidden fields or store the data in the database page by page but that's  
another story.

Other ways to store data permanently include all sorts of files and  
databases. And if you avoid doing full page request at all by using hip  
and cool Ajax technology then you can store data in javascript variables  
across "background requests".

Re: global variables

Oliver Grätz wrote:

Quoted text here. Click to load it

In PHP the global keyword basically pulls a variable from the global
namespace into the local namespace.

What most other languages refer to as "globals" PHP calls "superglobals".
There's no way to define superglobals though -- PHP defines a few on its
own (depends on your version, but in recent ones, $_POST, $_GET, $SERVER,
$_SESSIOM, $_ENV, $_FILES and $GLOBALS) and you're stuck with them.

Although I steer away from globals (in my current project, over 4000 lines
of PHP so far, and not a single global!), sometimes I really would
appreciate having a method of defining superglobals. Not going to happen
though. :-(

Toby A Inkster BSc (Hons) ARCS
Contact Me ~
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

Re: global variables

Awesome discussion and explanation folks.

Yes, I was thinking a global was like a superglobal, but its not.

I ended up imploding my array and sending it to the next page via
POST. Ez-peazy.


Quoted text here. Click to load it

Re: global variables

Toby A Inkster schrieb:
Quoted text here. Click to load it

I intentionally left out elaborating about the nature of the globals vs  
superglobals because use of global variables is somewaht discouraged.  
Even Zend tells developers to use static class variables instead. And by  
the way, Defining your own superglobals is NOT impossible. You CAN use  
the runkit extension ( ) to define variables as  
superglobals. But the nature of this extension as "sandbox" should tell  
developers not to do so ;-) But if you find _good_ reasons to use your  
own superglobals, you are free to do so.


Site Timeline