Available panes list doesn't refresh until Panelizer display saved

I traced this down to the ctools object cache implementation provided by panelizer. panelizer_panels_cache_get() is called and retrieves from that cache all the available panels. In my case, it shows a deleted fieldable panel pane and none of the newly created panes. Since I'm also using a workflow module, this is particularly annoying because all the revisions load a stale cached copy until they are re-saved.

And even more annoying because the published node always gets cloned as a new revision prior to saving. So until I a new revision as published, every time I visit the published node in panelizer it will continue to serve up stale cache.

And you can't simply clear the cache as in-progress edits are also stored in this cache and clearing it would lose the user's work. The solution here would seem to be to either not cache available pane options, or at least cache them separately from where the in-progress edits are cached. I haven't dug deeply enough into ctools / panels to know the best solution at this point.

I ran into this today also. Was driving me insane trying to figure out why a new content pane view was not showing on the Add widget page, even with multiple "drush cc all".

There must be some solution for this. "drush cc all" is supposed to clear *all* caches. Surely we can add the panelizer cache to that list. Having a cache that cannot be cleared is very bad.

Thanks to this post for telling me to try saving the panelizer form first. That seems to have refreshed the cache. Just 3 hrs of painful ctools/panels/panelizer debugging time down the drain, so was frustrating.

Did this ever get fixed? I have an issue I think is related. I had tried to add a due date filter to worktracker (Open Atrium) to filter on date. It worked but caused an undefined index error on all task lists so I removed the filter. Error was still around. I cc all and tried drush rr and cc all again.

After all that I went to the pane that was causing the errors and opened and resaved. This got rid of the error on that page but every page which had the same error I had to do the same thing. Haven't gone through all those pages yet so thought Id see if there was a faster way.

See the issue I just posted regarding the cache settings forms not loading properly if using more than one type: https://www.drupal.org/project/panelizer/issues/2957261

This sounds to be the same issue. When the page has not yet been saved, the loaded cache settings form displayed is the last one edited, not the settings of the currently selected cache option. The only way to work around this is to fully save the Panelizer and re-start the editing process.

I just ran into this as well. There's unfortunately no patch to review. @DamienMcKenna do you have a sense of what would need to be done for this? Is it an upstream CTools issue? Maybe I can try to push for some time to look at this...

I resolved the issue by using the hook_views_views_save & hook_views_views_delete. This does not affect panel pages that are already being edited, as they are using a static cached version of views_content_panes. In order for them to see the updated changes, they need to reload the panels editor.

/**
 * Helper function
*/
function _MODULE_NAME_cache_clear_views_content_panes($view) {
	$called = &drupal_static(__FUNCTION__);
	if(!isset($called[$view->name])) {		
		if(isset($view->display)) {
			foreach($view->display as $key => $display) {
				if($display->display_plugin == 'panel_pane') {
					// clear content pane cache
					cache_clear_all('views_content_panes:', 'cache_views', TRUE);
					
					$called[$view->name] = TRUE;
					
					// exit foreach
					break;
				}
			}
		}
	}
}

/**
 * Implements hook_views_view_save()
 */
function MODULE_NAME_views_view_save($view) {
	_MODULE_NAME_cache_clear_views_content_panes($view);
}

/**
 * Implements hook_views_view_delete()
 */
function MODULE_NAME_views_view_delete($view) {
	_MODULE_NAME_cache_clear_views_content_panes($view);
}