Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.OK, that's quite the title - here is what I mean:
* Create a panel with a node context for (e.g.) story.
* Put some panes on the display for the default and story contexts.
* Export the panel, and place it in an active module somewhere.
* Go to the panels listing and reset the panel (i.e. use the code version)
* Edit the panel and move/add some panes on the default context display. Save, and note how the changes are saved.
* Edit the panel and move/add some panes on the story context display. Save, and note how the changes are not saved, but revert back to whatever is in code.
After some debugging, I narrowed this down to a caching bug. Removing the panels_cache_set() call fixes the observed behavior.
I am not sure if that is the best fix or not, however the code does look a little odd to me - as far as I can see (although I barely understand the whole panels display saving workflow!) it looks like it is saving the _old_ display to the cache, before the form has been applied. If this is the case then the fix is reasonable because the cache will need to be recreated on the next page load anyway. What this doesn't explain however is how this issue does not manifest with the default display - perhaps there is a bug in the cache code that is breaking caching for the default display anyway?
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 345995.patch | 1.66 KB | owen barton |
| cache_onsave.patch | 672 bytes | owen barton |
Comments
Comment #1
Anonymous (not verified) commentedI have this problem too, and this patch doesn't fix it.
I can come back with concrete information from the database, but from memory the problem is that the panel's layout_settings still refer to display ID (did) 'new' rather than the new row in the panels_display table. You can observe panels will keep inserting a new row in the panels_display table with the correct settings for your content on the non-default context, but the panel object itself never gets the new display ID and instead keeps the 'new' from the default panel stored in the module.
Comment #2
owen barton commentedOK, I think bangpounds deduction is basically correct. When we edit a new panel that was previously in code we go though _panels_page_insert(), and this only saves the primary display, which means all the other displays don't get dids, and so get disconnected from the saved panel which causes a duplicate display to be saved on subsequent edits. In other words _panels_page_insert() is assuming that it is saving a brand new panel, but actually it needs to do an import.
The attached patch attempts to fix this, but moving the display saving code from panels_page_save_import(), which just loops through all the displays and saves each of them, updating the dids on the panels page.
This basically works, however there is some caching wierdness going on, because the save doesn't take on the initial save when the panel was previously only in code. However, it does now work on subsequent saves, which was not the case previously - so this is an improvement at least :)
Comment #3
Anonymous (not verified) commentedThe patch works as described, which is to say not a solution but it's enough to get me back to working when I'm trying to edit my default panels.
Comment #4
esmerel commentedNo fixes will be added to the 2.x line.