Creating a MySQL powered websites, applications or content management systems often involves dealing with unpleasant character encoding related issues that are hard (and so not fun) to diagnose. In the worst case the behavior may even vary between your development and production environment.
I’ve never been digging deep enough into character encoding (since it’s not fun), but I plan to reading this promising blog post recommended somewhere at stackoverflow: Getting out of MySQL Character Set Hell
Before I get around to doing it (it’s quite long and detailed), here is a quick list of rules to follow I’ve came up with after a lot of trial and error. I might update it after I read the article.
Recently I was working on a custom CMS, and I started by creating a simple login page and a restricted area, accessible only to the admins. The login page used PHP sessions to let an authenticated user in. It was nothing fancy, just basic stuff you find in any sessions tutorial.
- after successful login, call session_start() & save a session variable (like the admin’s user ID)
- redirect the user to some restricted page, like admin_home.php
- on every restricted page, call session_start() and check if the session variable is set
- die; if the variable isn’t set
Simple enough that nothing can go wrong, you might think. Well after uploading, I found out that the sessions were simply not working on the live production server. To be more precise, they were not persistent across pages. The session was created when the user logged in, but didn’t exist as soon as they navigated to any other restricted page.