mehblog

So the hottest topic in the rails community is seems is Derek Sivers’ blog post on why he switched from trying to reimplement his site in rails to php.

As someone who writes both rails and php for a living I feel that I have a good perspective on the rails vs php thing.

I’m sure the arguments will continue for some time, but all I know is that I write much better php since working with rails.

Right tool for the job and all that.

While working on a site last night I got this error when I uploaded the latest version of my code to the live server: Warning: session_start(): Cannot send session cookie – headers already sent …

Now, my first reaction was WTF! as I wasn’t seeing this on my development box. I was using the Apache Friends XAMPP product to run a WAMP install on my local windows XP machine so I guess there are some differences in the way apache works on win32 and linux.

Anyway, the Cannot send session cookie error is usually caused by outputting something to the client and then trying to send a cookie/write to the headers. So I start looking through my included files, trying to find a stray debug line or something like that. Nothing. Ok, go through it again, grepping for any kind of output. Nothing. Oh crap. I can’t find the problem and the live site is busted right now.

Ok, its late and no one will probably notice, but I have to find the problem.

Bang head on table a few times.

Ok, start again.

And then I see it. I had tabbed all of the source in one of my include files. Including the opening  < ?php  line! So, I was effectively sending a tab to output then processing my php.

More head slapping. General relief etc.

So there you go. If you ever have that problem and can’t see where its coming from, save yourself some wear and tear on the ole forehead and check for whitespace at the beginning of your source files.

We deployed a new site last week. Over the weekend I got a bug report from the site owner. Within the administration section of the site a certain session variable was getting reset causing a certain operation to fail.

Initially I was stumped. It worked fine on the dev server...  So I made sure that we had deployed the code to the live server correctly. Yup, all fine.

Versions of php were the same.

Well, to cut a long story short, register globals had been turned on in an apache config file for the previous version of the site and hadn't been removed when the new site was deployed.

This was causing a variable initialisation in one part of the code to overwrite an object in $_SESSION elsewhere.

Weird. Lesson learned...