Full page cache and events3 users found helpful
I'd like to know what would be the best place in a package to add some code that should be executed on every page load, be the page cached or not? What I mean here is something that would not have any effect on the page rendered, but rather to do something only on backend for example logging something. Would it require overriding/extending some core model(s)? Theme header/element is not possible in my case.
Any ideas on this one? What do you other developers think, should there be some kind of "hook" to which events could be attached, even if the page was cached?
Just to give an example, following code in a package controller won't fire on full-page cached page:
At the moment, responses to post requests do not get cached. Personally, I would like pages that have some events to be treated in the same way.
EDIT - link to your bug report:
That way, we could have the cache with a slightly higher response time instead of needing to leave it off completely when using events.
One possible solution would be to have some spesific variable in package controller just like block controllers have the $btCacheBlockRecord that define if block output can be cached. Then at some point, for example when overrides cache is "filled up", system would check which package controllers are non-cacheable and mark them somewhere (database maybe?). This way the core would "know" which package controllers it has to execute regardless of cache settings. That however would require developers to add such rule to the existing packages.
Another option would be to check for system event functions with method_exists() on package install or update and mark the packages cacheable or not.
Someone already mentioned on the bug tracker page that this bug/feature effectively renders the Mnkras' Page Redirect attribute package unusable on fully cached pages.
I would be happy with either of your suggestions. (EDIT)- Either could remove any need for a dashboard setting - I suspect the difficult bit will be the actually moving of the cache decision to a different stage of the overall process and allowing a package to decide (given current page info) whether the cache can be used for that page.
Page redirect is I think a valid reason that this issue should be treated as a bug that needs to be fixed rather than a feature we have to learn to live with.
As for the page cache and events, the conclusion by Andrew from the leaders thread was that full page cache effectively saves a page as static html and there would not be any revision of the full page cache to support events. No one else on the thread was happy about that, but that is unfortunately the way it is.
My approach to designing event related functionality has consequently changed to do more by ajax and less by php. If an ajaxing javascipt gets cached with its page, the script still runs on the browser.