Once I enable the authcache_panels module on admin/module I see the following:

Notice: Undefined index: did in _authcache_panels_page_manager_collect_displays_from_handlers() (line 15 of authcache/modules/authcache_panels/authcache_panels.module).
Notice: Undefined variable: fragments in authcache_panels_authcache_p13n_fragment() (line 85 of authcache/modules/authcache_panels/authcache_panels.module).

I also see the error when I enable autcache_panels in a panel?

CommentFileSizeAuthor
#4 2132239-rework-authcache-panels.diff20.88 KBznerol
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

znerol’s picture

Ok, I found the cause of the second notice (authcache_panels_authcache_p13n_fragment), however I'm not sure what is causing the first one. This one actually is harmless.

The other one though is serious. However I do not have any clue at the moment what is causing it. I think I'll have to dig a bit deeper into the panels source.

Thanks for the report.

znerol’s picture

@SocialNicheGuru: Is this a panel loaded from code? E.g. via Features or exported using ctools?

znerol’s picture

Ok, this one is sort of tricky to implement. Though there is a workaround for the moment: Just make sure that your panels are stored in the database and not in Features or a Ctools exportable.

I think it will take me some time to find a proper solution. The problem is that it is tricky to get hold of a display when it is not stored in the database. There is even code in panels itself indicating that there are some nasty problems connected to this. E.g.:

From the simple cache plugin (panels_simple_cache_get_id):

  $id = 'panels_simple_cache';

  // If the panel is stored in the database it'll have a numeric did value.
  if (is_numeric($display->did)) {
    $id .= ':' . $display->did;
  }
  // Exported panels won't have a numeric did but may have a usable cache_key.
  elseif (!empty($display->cache_key)) {
    $id .= ':' . str_replace('panel_context:', '', $display->cache_key);
  }
  // Alternatively use the css_id.
  elseif (!empty($display->css_id)) {
    $id .= ':' . $display->css_id;
  }
  // Failover to just appending the did, which may be the completely unusable
  // string 'new'.
  else {
    $id .= ':' . $display->did;
  }

  if ($pane) {
    $id .= ':' . $pane->pid;
  }

  if (user_access('view pane admin links')) {
    $id .= ':admin';
  }

Comparing this fragment to the its companion panels_simple_cache_clear_cache one can easily spot an obvious bug: The cache id is calculated in a completely different way. Its a bit surprising that this issue was only found some months ago #2017455: Exported panels won't clear simple cache . The inconsistency was introduced by #1349118: Simple Caching ID scheme will lead to conflicts with exported Panels definitions (commit diff).

Other modules implementing panels cache plugins:

All of them presumably started with copying over the simple cache plugin with either one or both of the flaws... Seems that we cannot simply steal some brilliant solution already implemented in another project :(

znerol’s picture

Ok, this is more or less a rewrite. Extracted Panels / Page Manager stuff to new module Authcache Panels by Page Manager module. Also adds a Machine Name to Panes with Authcache-Cache method to circumvent the dilemma outlined above. There is currently no upgrade-code, therefore Panes need to be configured again.

znerol’s picture

Status: Active » Needs review
SocialNicheGuru’s picture

The panels are from features.

znerol’s picture

Status: Needs review » Fixed

Ok, this is fixed in 2.x-dev now. Enable the new "Authcache Panels by Page Manager" module and it should work with panels defined in code as well as in the database.

A note on context in panel panes. If the content of a pane loaded by authcache varies according to e.g. the currently viewed node, it is necessary to turn on per-page cache granularity.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.