PHP has been giving me the run-around. Just when you think you’ve got it all sussed out it springs another surprise. It likes to play with me that way – show me who’s boss.
This afternoon Nathan and I launched a site we have been working on for months. More accurately, we launched a site based on the content management system we’ve been working on for months. She flies! Hurrah and all that. Up until the site going live today I’d been validating pages using one or other of two methods. The first thing I tried was installing the W3C validator on my dev server. That almost worked, but no matter what input I gave it seemed to be resolving paths to the wrong site. I don’t think it liked by VirtualHosts set up. Being too pressed for time to really fiddle with it, I resorted to saving the output of a view source to disc and uploading the file to the W3C service. This worked fine.
On enlivening the site this afternoon, I took the opportunity to run the validator across the site for real. You can guess what happened. Errors galore – and all down to PHP’s automatic handling of sessions. For those not familiar with its behaviour, PHP uses cookies to store a session id on the client in the usual way. However, when cookies aren’t enabled PHP steps in and saves your bacon by automatically rewriting all the links on a page to append the session id to the query string. I’ve written similar functionality myself for ASP systems and it’s no small task, so having this feature built in is a real bonus. It’s just a shame it doesn’t encode its ampersands when it does it.
If you’ve not got access to the php.ini, whack this in your page:
ini_set("arg_separator.output", "&");
So we’re all cool now, right? Wrong – to maintain the session through HTTP POSTs, PHP also jimmies a hidden input into any forms, right after the opening form tag. This is just fine and dandy, but for the fact that XHTML 1.0 Strict requires that all input elements (including those which are not visually represented) are contained inside a block-level element.
PHP handles this by … invalidating your page. Thanks guys. I see this bug was opening in September 2001. I got the work-around from the notes on that bug, but it’s not pretty. The first thing to do, again if you don’t have access to the php.ini, is to place this on your page:
ini_set("url_rewriter.tags", "a=href,area=href,frame=src,input=src");
That’s basically just reconfiguring the URL rewriter to not attempt to fix up forms – no hidden field will be written. That means, however, that you’ve got to write the field yourself.
<input type="hidden" name="PHPSESSID" value="<?php echo session_id(); ?>" />
The above assumes you’re using the default session name of PHPSESSID, but you know the drill if you’re not. So, w00t, it validates. Crisis averted.
Oh, and the site? Introducing grownupgreen – a UK based site with news and features on environmental issues for the environmentally aware. It’s a hard working, real world XHTML and CSS site with a graphical feel. We had to be a little liberal with extra, otherwise unnecessary markup to hook the CSS to, but that’s what the design required. I think we took a good route for what we needed to achieve. Designed by Chris Ruffles and implemented by Nathan and myself. Nathan and I designed the CMS together, then he took on markup and CSS duties and started at the front end, whilst I got dirty with the database and started at the back. We met somewhere around the middle.
So there you have it.
Comments
But thanks for the headsup .. I’ll nag Nathan.
Good job on the site, other than said issue. Green seems to be prettier than blue on an LCD.
<IfModule mod_php4.c>php_value url_rewriter.tags "a=href,area=href,frame=src,input=src"</IfModule>