I was having one of those insanly frustrating problems with PHP scripts, my new Shopping Cart, and sessions the other day. I finally figured it out with the help of new favorite php function.

Turns out it was kind of a weird problem, so I wrote it up for the collective learning of the world.

Already got my good deed out of the way for today! ..did you?

Prepare yourselves…serious web-geekiness ahead

The Setup

Yesterday I was putting some finishing touches on my new Shopping Cart web-app for Artfinale.com, and I ran into a weird problem with the sessions that use to run the cart. When I user would go to the site and click “Buy Now” on something, it would take them to the cart and the cart script would then hand the user a session with the cart’s ID number and then place the items they added into the database using the cart ID number as a key. If the user would then click “Secure Checkout”, it would move them to the secure: https://www.artfinale.com/atlas/checkout.php, then that script would check to see if they were logged in (more sessions), and if they were it would then check to see if they
1. Had a cart, by checking if the user had the cart ID session.
2. Had something in there cart to actually buy.
If both were true, it pushed them on their way, and everything was gravy.

The Problem

Nice setup huh? Here’s the problem:
If the user started out by going to www.artfinale.com and went through the process. They were moved to the secure site and everything worked as it should. But if the user started out going to artfinale.com (minus the “www.”) then when they were pushed to the secure page, which added the www. they were denied access to move farther and were taken back to a now empty cart and handed a new cart ID. Why? For some reason, when the user started out on artfinale.com and was pushed to www.artfinale.com, the server lost their stored sessions. And yes…both www.artfinale.com and artfinale.com are on the same server. You think it sounds like a frustrating problem? Try living it.

The solution

First, lets start at basic sessions. For those that don’t know sessions are PHP’s way of taking a new look at the classic “cookies“. Basically sessions track data, like in this case my Cart ID Number, but instead of housing that information on your computer, it houses it on the web server.

The problem here was that when the user switched from artfinale.com to www.artfinale.com the server thought it was a new person and gave them an all new Cart ID Number. After much searching on the net and in my books, I couldn’t find a solid reason why this happens, but I did find a fix. The trick is to change a line in your PHP.ini file (the configuration file for the PHP installation on your server).
session.cookie_domain is the line that needs to be changed. By default, its left blank, but if you are having this problem you need to change it to let the installation know that the domain you are on is not just static. After changing your line should look like this:

Notice the period before the domain name, that little bastard is the difference maker.

Now this is all fine and good if
1. You can get to your php.ini file.
2. You just have the one domain name for this php installation.

In my case I can get to the php.ini just fine, but we have many domains on this server, so changing the php.ini file to work for artfinale.com isn’t exactly an ideal solution. If you are in either one of these situations, then you need to know one of my new favorite php function calls: ini_set().

For those too lazy, here is the definition:

This little piece of greatness allows the user to change a line of the php.ini on the fly for this script. When the script finishes, it goes back to what it was before.

Wrap It Up

To fix the problem, I just placed this line at the top of my php scripts that were having problems finding the sessions:

Works like a charm.

Did you think this was helpful? Do you wish I would just stick to articles about Lindsay Lohan? Let me know what you think.