Main Content

PHP sessions - a best practice teaching example

Archive - Originally posted on "The Horse's Mouth" - 2012-07-27 22:45:46 - Graham Ellis

Whether you're selling airline tickets, updating financial records, or running a forum, you'll need software on your web server that maintains state. In other words, software which remembers who you are from page to page, remembers what you've been doing, and doesn't insist on you logging in each time.

If you want to write code at a low level, using cookies, you can do so ... but most modern languages or frameworks have a tool of some sort that bolts together your series of steps into a session at a higher level (i.e. withoout requiring you to write the low level stuff!). I was writing such an example in PHP earlier this week - on our PHP Techniques course.

It works like this:

a) you do a session_start at the beginning of each page. This will read back a cookie (if one exists) from any previous page, and if there is one it will read a disc file associated with that cookie into the $_SESSION superglobal array.

b) you then place anything you want to save for future pages into the $_SESSION superglobal.

Simple as that ... your $_SESSION is automatically saved at the end of your PHP page, and your cookie will be automatically (re)set as necessary.

Taking it a stage further, you'll typically write all the steps of an application that maintains state into a single script, and use a variable in $_SESSION to remember where abouts in the process the particular current user has got, as well as all of his settings. That way, whenever a page is submitted you'll be able to follow the same pattern which is
  • Read the cookie / session so far
  • Check the user inputs, save them as needed, work out which page is next
  • Prepare for that following page
  • Save the session / send the cookie back out
  • Send the response page
I've put a complete source code example showing the principles of that [here].


You'll also need to plan the various states / steps through your process - here's an example of a state diagram (UML) to show the flow through in the example used in this post.


This is good ... as far as it goes, but by the HTML (the look and feel) of the page as well as the PHP (how it acts) all in the one file, we've made it harder to look after. In real life, you're likely to have a graphic artist looking after how the screens look, and a programmer looking after how they run. My second example - [here] - splits the code out from the look and feel into two separate files; the look and feel is [here].

As a further stage, you'll want to have uniform error message handling, protection against injection attacks, sticky fields, and much more common logic that will be shared between multiple applications, and between all the various input boxes within each page of the same application. This extra logic will be separated out into separate functions (and indeed probably into separate files). I finished my demonstration the other day with a third example to show this - source code [here]. It uses the same template as the previous example, and is now robust enough for me to provide you with a copy on my server that you can run - see [here].