If you haven’t had a chance to play around with CodeIgniter I highly recommend it. In case you don’t know, CodeIgniter is a pretty awesome PHP framework that’s really great for anyone new to object oriented PHP and/or frameworks in general. I’m building an app at work right now using CodeIgniter that’ll basically replace me completely and put me out of a job. It’s a web page generator that takes some graphics and text as input and spits out some files for you to serve based on a bunch of different templates. In it I’m using CodeIgniter’s Session class to manage the flow of information as some data needs to pass between several different pages before the process is finished. Sessions are the right choice for this particular application’s problem but CodeIgniter’s internal Session handling library is giving me lots of trouble and it isn’t the first time either. So if you’re having trouble with CI’s session class, have no fear, I’ve put together a list of solutions to CI’s most common session problems.
Disappearing session data
The problem in almost all cases is that session data gets stored initially but isn’t held over when switching pages which totally defeats the purpose of even having a session to begin with! It took me a few days but I finally managed to fix the problem.
Who’s your browser?
The first thing you need to do before looking into any other solution is to check to see if your sessions hold in other browsers. I found that on Windows, Firefox held on to sessions just fine while Chrome didn’t like them. If this happens to you then you can be reasonably confident that the problem lies not in your controller but in your config file.
- Give your
$config['base_url']setting a value
- Remove any underscores from your
- Make sure
cookie_domainis properly set. This may mean removing it altogether
The relevant config values would end up looking like this:
1 2 3 4 5 6 7 8
Localhost is your enemy
I’ve noticed that sessions are far more reliable in a production environment than on a local dev machine. This goes double if your dev machine is running Windows. Using XAMPP I’ve gotten 400 Bad Request (cookie too large) errors that forced me to clear all my browsing data every other minute. Get your application in a state where you think it should work then put it on a server identical to your production environment. See if it works. If so, you need to work backwards from there. MAMP on a Mac has choked on CI sessions on me before but it’s never complained to me about cookies or given me a 400 error like XAMPP on Windows does.
Get your code on a production server.
Use the database
When I first started developing Write.app I had a problem where sessions just weren’t being set at all. I tried a ton of different solutions (not including those above but including those below) and none worked. In the end I found that if I used the database everything just worked. In the end I needed this feature for technical reasons so it wasn’t for nothing.
Abandon CI sessions
You could just abandon CodeIgniter’s sessions altogether and just use PHP’s native sessions. You really don’t gain all that much from CI sessions anyway. There’s also CodeIgniter’s own Native Session library which you can find on the Wiki. It’s pretty old now and was released around version 1.5 but I think it’s still relevant and worth checking out. It’s on their Wiki on GitHub.
Other than that you’ll need to find a solution I haven’t mentioned here or find some other library that handles sessions.