Yet another day at Srijan with yet another challenge presenting itself and yet another developer has saved the day with an amazing solution.
Not really a common problem but i am sure many have faced the problem of Drupal caching being a hindrance when on some pages it is just NOT required!
I mean, what would you do if the client DOES not want to turn off the caching (Well in a way they are right and pretty muche sensible!) and yet the caching does not allow context module to fire contexts separately to separate users?
For everyone who are not familiar with Drupal cache and context module;
Cache is that magical bunny that sits ready and when you ask for a certain page on my website it not just produces that page from the system but also keeps a copy with itself just in case someone else wants it too. So whenever a new user asks for the same page, it doesnt have to go to the server again making requests but reproduces the copy that it already had!!! Neat!!
But why would it pose a problem when it only keeps a copy? Well, let me put it this way, a page when cached is irrespective of whether some content is changing dynamically or not (expiry dates can be set but till that time page will remain cached). Which means that till the time the cached page exists, every user sees the same page! Even when, lets say, one block of content has to change based on WHO exactly the user is!
We at Srijan had developed the Demandbase module and based on the conversations from one of the users of the module quickly realized that the cache wont let the context fire in time and many users with separate IPs will see same page even when they shouldnt (For more on Demandbase module and services).
The solution came from Chandraji and Mahesh when they pointed out that the best way was to tweak the drupal cache mechanism itself.
In more technical terms, cache is just a page with a unique id and path of the page. So when a page with a certain path is requested again, the cached page with its associated unique ID is served from the cache table. Combining the two logics the developers figured out the cache table and inserted the incoming IP of the user with unique ID. Ofcourse the cobination is now a unique ID.
Now whenever a path is requested by a new user, he will first be served the page from the server and a copy of the page will be kept with cache indexed by his/her IP. If another user from the same IP(Office/Firewalled/Proxy IPs) looks for the page he can be served the cached page whereas another user with a new IP inspite of still being an anonymous(or what we call is the "anon") user will be served a new page with different content, from the server.
Here are the screens for two different IPs with two different cached pages being served. Note at the bottom, of both the screens the "Drupal-Cache HIT" sign which validates that the method worked perfectly fine!
Please note that this solution works only for Normal Drupal cache and not for other caching mechanisms such as Memcache, Varnish etc. We seek soultions for the same hope to get those out of the way too!! Till then, stay tuned!!
