This is not going to be a tutorial on how to install and configure boost on a Drupal installation. No, I'm here to tell you a funny story and to remind myself a frustrating debugging session we had this friday trying to install the module. For those who don't know boost yet: when enabled, the module will create html files for every page on your site and with a little help of some htaccess rules, you can bypass a complete Drupal bootstrap for anonymous users. So far, so good. We really needed to speed up a project, so we told a client to test this on an acceptance version of their site and after the green light, we enabled it too on the production site. Few minutes later, the phone rang, nobody was able to edit the site anymore, boost was serving cached pages to authenticated users, panic all over the place. It took us a few hours to realize we were so stupid not seeing a very obvious and logical boost behavior, so for myself and every one else, remember this:
- A cookie called DRUPAL_UID is set or deleted whenever a user is authenticating or logging out from the site.
- If this cookie ain't found, the access rule will try to match a cached version of the incoming page request.
- After enabling boost and turning on static page caching on the performance page, there is no check to see if current users are authenticated, so DRUPAL_UID does not exist for their session.
- Therefore, the htaccess rules will serve up any existing cached pages to everyone, authenticated or not.
This is all very logical, but on a friday morning and with a fairly upset client, trying to find a fast solution for a very strange problem can be mindboggling. After skimming the access and the boost code, we finally understood what was happening so we simply truncated the session table and told the client they should go to the login page and everything would be solved. You can even tell your client to go to /logout and /user.
So if you ever experience this too: Don't panic, truncate session table, sit back and relax :)