Sams Teach Yourself PHP, MySQL and Apache All in One (2012)

---

Once again, session_start() resumes the session on line 2. Line 12 tests for the presence of the $_SESSION['products'] variable. If it exists, the variable is unserialized and looped through on lines 14–16, printing each of the user’s chosen items to the browser. Figure 12.3 shows an example of the output.

Figure 12.3 Accessing an array of session variables.

For a real shopping cart program, of course, you would keep product details in a database and test user input, rather than blindly store and present it, but Listings 12.5 and 12.6 demonstrate the ease with which you can use session functions to access array variables set in other pages.

Destroying Sessions and Unsetting Variables

You can use session_destroy() to end a session, erasing all session variables. The session_destroy() function requires no arguments. You should have an established session for this function to work as expected. The following code fragment resumes a session and abruptly destroys it:

session_start();
session_destroy();

When you move on to other pages that work with a session, the session you have destroyed will not be available to them, forcing them to initiate new sessions of their own. Any registered variables will be lost.

The session_destroy() function does not instantly destroy registered variables, however. They remain accessible to the script in which session_destroy() is called (until it is reloaded). The following code fragment resumes or initiates a session and registers a variable called test, set to 5. Destroying the session does not destroy the registered variable:

session_start();
$_SESSION['test'] = 5;
session_destroy();
echo $_SESSION['test']; // prints 5

To remove all registered variables from a session, you simply unset the variable:

session_start();
$_SESSION['test'] = 5;
session_destroy();
unset($_SESSION['test']);
echo $_SESSION['test']; // prints nothing (or a notice about an undefined index)

Using Sessions in an Environment with Registered Users

The examples you’ve seen so far have gotten your feet wet with sessions, but perhaps additional explanation is warranted for using sessions “in the wild,” so to speak. The following two sections outline some examples of common session usage. In later chapters of this book, sessions are used in the sample applications you build.

Working with Registered Users

Suppose that you’ve created an online community, or a portal, or some other type of application that users can “join.” The process usually involves a registration form, where the user creates a username and password and completes an identification profile. From that point forward, each time a registered user logs in to the system, you can grab the user’s identification information and store it in the user’s session.

The items you decide to store in the user’s session should be those items you can imagine using quite a bit—and that would be inefficient to continually extract from the database. For example, suppose that you have created a portal in which users are assigned a certain level, such as administrator, registered user, anonymous guest, and so forth. Within your display modules, you would always want to check to verify that the user accessing the module has the proper permissions to do so. Thus, “user level” is an example of a value stored in the user’s session, so that the authentication script used in the display of the requested module only has to check a session variable—there is no need to connect to, select, and query the database.

Working with User Preferences

If you are feeling adventurous in the design phase of a user-based application, you might build a system in which registered users can set specific preferences that affect the way they view your site. For example, you might allow your users to select from a predetermined color scheme, font type and size, and so forth. Or, you might allow users to turn “off” (or “on”) the visibility of certain content groupings.

You can store each of those functional elements in a session. When the user logs in, the application loads all relevant values into the user’s session and reacts accordingly for each subsequently requested page. Should the user decide to change her preferences, she could do so while logged in—you could even prepopulate a “preferences” form based on the items stored in the session instead of going back to the database to retrieve them. If the user changes any preferences while she is logged in, simply replace the value stored in the $_SESSION superglobal with the new selection—no need to force the user to log out and then log back in again.

Summary

In this chapter, you looked at different ways of saving state in a stateless protocol, including setting a cookie and starting a session. All methods of saving state use some manner of cookies or query strings, sometimes combined with the use of files or databases. These approaches all have their benefits and problems.

You learned that a cookie alone is not intrinsically reliable and cannot store much information. However, it can persist over a long period. Approaches that write information to a file or database involve some cost to speed and might become a problem on a popular site; this is a matter to explore with your systems administrators.

About sessions themselves, you learned how to initiate or resume a session with session_start(). When in a session, you learned how to add variables to the $_SESSION superglobal, check that they exist, unset them if you want, and destroy the entire session.

Q&A

Q. What will happen to my application if users disable cookies?

A. Simply put, if your application relies heavily on cookies and users have cookies disabled, your application won’t work. However, you can do your part to warn users that cookies are coming by announcing your intention to use cookies, and also by checking that cookies are enabled before doing anything “important” with your application. The idea being, of course, that even if users ignore your note that cookies must be turned on in order to use your application, specifically disallowing users to perform an action if your cookie test fails will get their attention!

Q. Should I be aware of any pitfalls with session functions?

A. The session functions are generally reliable. However, remember that cookies cannot be read across multiple domains. So, if your project uses more than one domain name on the same server (perhaps as part of an e-commerce environment), you might need to consider disabling cookies for sessions by setting the

session.use_cookies

directive to 0 in the php.ini file.

Workshop

The workshop is designed to help you review what you’ve learned and begin putting your knowledge into practice.

Quiz

1. Which function would you use to start or resume a session within a PHP script?

2. Which function can return the current session’s ID?

3. How can you end a session and erase all traces of it for future visits?

Answers

1. You can start a session by using the session_start() function within your script.

2. You can access the session’s ID by using the session_id() function.

3. The session_destroy() function removes all traces of a session for future requests.

Activities

• Create a script that uses session functions to track which pages in your environment the user has visited.

• Create a new script that will list for the user all the pages she has visited within your environment, and when.