Colliding cookies

cookiesFor the Alberta Greens we're setting up a swath of subdomains to use in organizing voter phonebanking and canvassing. The setup looks like this:

However we had some strange problems where after logging in to one site you couldn't log into any of the other sites. A bit of research found that the problem
was that PHP session cookies were colliding. I found a post in the Drupal issue tracker that someone else had already filed for the problem. Different people did research in different area on what was causing the problem and how to fix it.

The problem happens because by default Drupal sets the cookie domains to be:
And all session cookies are given the same name. And in theory all should work as expected because PHP should return the most specific cookie for our current session. But it doesn't.

It turns out that web browsers return all the cookies that could possibly apply, not just the most specific one. And PHP gives Drupal the last cookie it gets, which unfortunately is probably not the one we want. So this is a PHP bug. It's also a bug in the original cookie spec as there are conflicting rules about what order cookies should be sent by the browser. And thus different browsers can return the cookies in whatever order they choose. Yikes, this runs deep.

So a bug has been filed with PHP. But meanwhile a patch has been filed to make Drupal work around the issue by giving a unique name (derived from the $base_url) for the session cookie. Hopefully this patch make it into Drupal 5.2.

So this rather complicated (and hard-to follow I'm sure) story shows why Open Source is so great. If it was just me trying to figure this out on my own, I would have gotten as far as "My cookies are colliding and I'm not sure why". And I would have created an ugly workaround that would have been difficult to maintain.

But because there were about 10 people working on it, we all pitched in a bit of effort and created a sollution that actually fixed the problem for the longterm.

Yet another reason why proprietary software isn't a good solution for running a website.

fgrep search

Recently Drupal uber-guru John VanDyk wrote a blog post about searching code with grep.  He has a great tip about creating a small bash script to use as a shortcut. 

As an alternative to grep you can use fgrep.  fgrep is the same as grep except that it doesn't support regex, hence it's much faster (hence the f).  98% of the time you don't need regex.  

fgrep is noticably faster, expecially when you are searching the entire codebase of a site that has many modules with many files (like CiviCRM or TinyMCE).

So I was doing some development today for a new client's site. I was trying some new things and working with the Drupal API. Drupal has a good reference site for the API at I was working with a theme function. With the theme functions you simply copy the original function into your theme and then make whatever changes you want. It's part of what makes Drupal so easy to customize.

However when I pasted the function into my theme I started getting a bunch of errors. After a bit of hunting around I discovered that the code on was not quite current. After finding the current version of the function, everything was ok.

I'm not sure how often the code on gets updated, but apparently it's not enough. It's obvious that the main module that runs the site needs some updating as 5.0 is not even listed (You need to search under the HEAD branch). Does that mean that the code content hasn't been updated since before the last branch? That can't be right.

I wonder who to talk to about this?