Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When using Simple Caching the cache IDs typically use the following format:
- panels_simple_cache:[display ID]:[pane ID]:[object ID]
When you are building the panel definition, i.e the definition is in the database, the cache ID will look like these:
- panels_simple_cache:55:123:26
- panels_simple_cache:55:124:26
- panels_simple_cache:55:125:26
If the panels definition is exported and the in-database overrides are reverted, you end up with cache IDs as follows:
- panels_simple_cache:new:new-1:26
- panels_simple_cache:new:new-2:26
- panels_simple_cache:new:new-3:26
Note one glaring problem: it doesn't reference what the entity is, so there's a strong chance of e.g. the panel for user ID 26 conflicting with node ID 26.
Comment | File | Size | Author |
---|---|---|---|
#6 | panels-n1349118-6.patch | 1.21 KB | DamienMcKenna |
#3 | panels-n1349118-3.patch | 513 bytes | DamienMcKenna |
#2 | panels-n1349118.patch | 486 bytes | DamienMcKenna |
Comments
Comment #1
DamienMcKennaI think this should be fixed by including the $context->type in the cache ID, e.g. changing panels_simple_cache_get_id() in simple.inc to include the following:
Thoughts?
Comment #2
DamienMcKennaBasically the same code as #1, just makes sure that the $context->type[0] exists first.
Comment #3
DamienMcKennaThe wrong patch was attached, try this one.
Comment #4
DamienMcKennaThis isn't sufficient, it's still possible to lead to collisions by having multiple page definitions that have the same context, e.g. user profile definitions. What really needs to happen is have the 'new' string replaced by the panel's name attribute, thus each definition would *always* be unique.
Comment #5
DamienMcKennaThe exported name of the panel isn't present in any of the data structures available in panels_simple_cache_get_id(), the closest is $display->cache_key but it is in the format "panel_context:[object_type]:[object_name]", e.g. "panel_context:node_view:node_view__blog_post" (where "node_view__blog_post" is the name of the exported panel. Of course this is only present for some objects. Gah.
Comment #6
DamienMcKennaThe specific panels that didn't have a $display->cache_key were minipanels, which *did* happen to have a $display->css_id, so this patch first uses a numeric did, then checks cache_key, then checks css_id, then fails back to just using did as-is.
Comment #7
Letharion CreditAttribution: Letharion commentedThis will require merlins opinion.
Comment #8
merlinofchaos CreditAttribution: merlinofchaos commentedMakes sense.
Mini panels probably don't have a cache_key because they don't support the IPE. Maybe someday they will, but it seems unlikely.
Committed, pushed.
Comment #10
joshuajabbour CreditAttribution: joshuajabbour commentedThe same problem exists in the D6 branch. The patch in #6 applies cleanly, and fixes the issue.
Comment #11
cedarm CreditAttribution: cedarm commentedThe patch in #6 works for 6.x. Tested with term_view system handler, custom page manager pages, mini panels, and panel nodes. Mini panels in code do end up using the display css_id.
Comment #12
Dean Reilly CreditAttribution: Dean Reilly commentedThis patch also fixes another bug where mini panels caches wern't being cleared.
Steps to recreate:
1) Create a mini panel and add a node pane to it.
2) Add the mini panel to a larger panel and view it to create a cache entry.
3) Edit the mini panel to show another node and save it.
4) View the panel again and the node won't have changed.
The problem is that when the mini panel is loaded through the parent panel $display->owner->id is set by panels_mini_panels_mini_content_type_render() in panels_mini/plugins/content_types/panels_mini.inc.
But this doesn't happen when using the mini panel else where. Hence when we generate the cache id:
We end up with different cids so the caches remain untouched.
Comment #13
DamienMcKennaRelated: #2017455: Exported panels won't clear simple cache
Comment #15
DamienMcKennaComment #16
japerryCool. Easy enough. Fixed.