Introducing PHP Superglobals

Tweet

Superglobals are specially-defined array variables in PHP that make it easy for you to get information about a request or its context. They are called superglobal because they are always accessible, regardless of the scope — that is, you can access them from any function, class or file without having to do anything special. The superglobal variables are: $GLOBALS, $_SERVER, $_GET, $_POST, $_FILES, $_COOKIE, $_SESSION, $_REQUEST and $_ENV. And while you can learn more about each by reading the PHP documentation, I’d like to show you the ones I think you’re likely use the most.

$_GET and $_POST

$_GET and $_POST are used to get information sent in the page request. Parameters sent in the URL are made available by $_GET. For example, this URL:

http://example.com/profile.php?uid=12345

… will send the parameter uid to profile.php, which you can then access the value in profile.php as $_GET["uid"].

When you have a form submission that is sent using method="get", the values are appended to the URL so they are available using $_GET as well. Forms submitted using method="post" send their values in the body of the HTTP request; posted data is available in your script by using $_POST. Here’s a sample web form which posts a username and password to a login script:

<form action="login.php" method="post">
Username: <input type="text" name="uname"><br>
Password: <input type="password" name="pass"><br>
<input type="submit" value="Login">
</form>

The uname value and pass value will be available as $_POST["uname"] and $_POST["pass"] respectively in login.php.

The $_REQUEST superglobal is an amalgam of $_POST and $_GET data. It’s offered as a convenience, but as a general rule I advice people to avoid it. It creates some of the same security risks that registered globals did years ago if you’re not careful. (If you don’t know what I mean by registered globals, consider yourself lucky. Just forget about $_REQUEST and you’ll be fine.)

$_SESSION

The HTTP protocol, the mechanism by which browsers request pages and receive them, was originally designed so that each request was independent from all the others made to the server. This isn’t how we use the web today, though. Now people expect each page they visit in a site to “remember” what happened previously, whether it’s logging in or adding a new video game to their online shopping cart. This logical link between pages is called a session.

To enable sessions, the session_start() function must be called at the top of any PHP script using sessions before output is sent to the browser. Once the session is active, you can store and retrieve data using $_SESSION. Here’s an example…

page1.php starts the session, stores a value in the $_SESSION array and then provides a link to page2.php:

<?php
session_start();
$_SESSION["videogame"] = "Battletoads";
?>
<a href="page2.php">Go to page 2</a>

When the user clicks on the link to page2.php, it calls session_start() to resume the session, retrieves the value from $_SESSION["videogame"] and displays it:

<?php
session_start();
echo $_SESSION["videogame"];

$_SERVER

The $_SERVER superglobal array stores information about both the web server and the request made to it. Some of the more useful $_SERVER values are:

  • $_SERVER["PHP_SELF"] – the name of the currently running PHP script
  • $_SERVER["REQUEST_METHOD"] – which HTTP method was used to request the page (GET, POST, etc)
  • $_SERVER["REQUEST_TIME"] – the time the page request was received, represented as an integer known as a unix timestamp
  • $_SERVER["HTTP_REFERER"] – the address of the previously visited page, if available

A list of all the available keys can be found in the online documentation. Keep in mind that not every one of them listed is guaranteed to be in $_SERVER; it depends on your server configuration and the request sent by the user.

Summary

As I said, these are just a few of the superglobals available in PHP which I think you’ll use the most. $_GET and $_POST allow your script to take in information from the outside world. $_SESSION lets you remember data between page requests during a visitor’s browsing session. $_SERVER holds information about the web server and the page request. Understanding these and learning to use them effectively will no doubt help you write great, interactive websites using PHP with relative ease.

Image via Tom Wang / Shutterstock

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.logic52.com Shane

    Nice article, I’m a front-end guy but I know PHP. Its amazing how quickly I forget all this stuff when I don’t practice it.
    Use it or lose it.

  • http://www.get2know.me Anthony Wlodarski

    I think that it would be useful to tell everyone why using $_REQUEST is a bad idea. Officially here is what the PHP manual says: “The variables in $_REQUEST are provided to the script via the GET, POST, and COOKIE input mechanisms and therefore could be modified by the remote user and cannot be trusted.” However $_GET and $_POST are also modified by the remote user sometimes as well so it is more of a choice of the lesser of two evils. Additionally if you have php.ini set up to not use $_REQUEST then you can make your own such as doing

    • http://zaemis.blogspot.com Timothy Boronczyk

      Indeed anything that holds user input should never be implicitly trusted. Using $_GET, $_POST, $_COOKIE, and even some $_SERVER values without filtering and validation opens the door for many different types of malicious attacks. But that’s not what why I recommend avoiding $_REQUEST.

      $_REQUEST combines $_GET, $_POST, and $_COOKIE values, but the order in which they populate $_REQUEST is important. Besides, I think it’s good form to know exactly where your input is coming from. It’s bad enough we can’t trust the input; let’s not be in the dark about how it got to us too.

      There’s a lot of information on the Internet about why “registered globals” was so bad, and why that’s deprecated. $_REQUEST is only slightly safer, but still dangerous. I’d love to see it deprecated as well.

      • http://timwahrendorff.de Tim

        Totally agree.
        Check input, control the user.
        I avoid 99% of spam in my Blog comments with $_SERVER['HTTP_REFERER'], $_SERVER['REQUEST_TIME'] a $_SESSION Variable and the time() command.
        You would be stunnished how many comments are send (by bots), not even visiting the site before and completing the task in human impossible 0.5 seconds of time.

        Looking forward to more “pro” articles. If you are interested in an article about strategies on preventing Spam and other automated user input without Captchas. I could translate and expand my blog article about it and give it to you for a bigger audience…

  • http://web-development-newz.blogspot.com/ wilbert santos

    nice.. it made the programmers easy to get the data