Posted by catch on September 2, 2010 at 3:45pm
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
drupal_page_is_cacheable() (or $GLOBALS['conf']['cache'] = FALSE in D6 and earlier) allowed you to disable the page cache for a request if you were doing something tricky. With the render cache, we have a similar caching pattern for smaller areas of the page, but no way to prevent that from being set. For our use case, it's stopping nodes from getting in the render cache when they have a 'waiting for
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| drupal_render_is_cacheable.patch | 2.34 KB | Idle | PASSED: [[SimpleTest]]: [MySQL] 23,311 pass(es). | View details | Re-test |
Comments
#1
Didn't finish that sentence...
the use case for us is to disable a node render from being cached when a video thumbnail is 'waiting for encoding' - once it's encoded we'd have the proper thumbnail and allow it to go into the cache.
#2
And that applies to the whole request, even unrelated parts of $page? This seems rough to me.
Perhaps we would be better off recognizing a #nocache property on elements. If thats set on any of the child elements, then we ignore #cache on any parent. That would require us to keep track of #nocache as we recurse up the tree but we really should be doing that for other properties like #attached. See #859602: #cache does not record the #attached declared in child elements.
I know I made this more complex, but the solution proposed here is only a little better than our current "figure it out yourself". i would think that a custom solution means adding a very early #pre_render on any elements which might be invalidated and in the pre_render function you check if they are cacheable. if not, remove #cache on the element.