Closed (fixed)
Project:
Cache Audit
Version:
7.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
19 Oct 2012 at 04:06 UTC
Updated:
4 Mar 2014 at 14:00 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
erikwebb commentedComment #2
erikwebb commentedGetting a correct list of Panels implementations is horrible, but this may help us - http://drupalcode.org/project/cache_actions.git/blob/refs/heads/7.x-2.x:...
Comment #3
erikwebb commentedComment #4
erikwebb commentedRemoving some extra output
Comment #5
erikwebb commentedSupport case where a Panel does not have any displays (e.g. base Panelizer config).
Comment #6
jrbeemanVerified #5 on a local site with many Panels configs. Found and reported via IRC the issue that is resolved in #5. Seems to be working great now. I'd recommend #1863116: Support selective output per module get merged along with this, as the Panels report can be quite verbose. Additional improvements would be to support a different output format, e.g. --pipe or newline delimited as opposed to tabular. However, the patch as-is is highly useful.
Comment #7
jrbeemanComment #8
erikwebb commentedSeveral issues -
Comment #9
erikwebb commentedComment #11
erikwebb commentedComment #12
jonathan webb commentedI tried to verify using a fresh install of Panopoly 7.x-1.0-rc3 with the included Demo configuration (Panels 7.x-3.3+10-dev), but changes to cache settings weren't reflected by subsequent cacheaudits. I tried clearing Drush & Drupal caches, with no change. It seems like panels_load_display() isn't getting called.
I'll leave this in "needs review" since I wasn't testing with stable releases, and I'll see if I can track down the issue.
Comment #13
erikwebb commentedMaybe the code I'm using is just checking the Panels in code and not the overridden copies in the DB? The code is stolen entirely from Cache Actions, so it honestly hasn't been vetted much.
Comment #14
jonathan webb commentedExamining the data after enabling caching, it appears that the values I'm setting in the Panels UI show up in _cacheaudit_load_panes() in $display->cache, even though $display->content[N]->cache is empty. I might be mistaken, but I presume the display's content would inherit the display cache settings (I am not a Panels expert by any means, so please correct me if I'm wrong), so the attached patch pushes that cache value from the display to its content if it is empty. Also I changed the first column to display the title instead of machine-name.
Erik it looks like your panels patch in comment 11 snuck in with commit 1f3407f. The attached patch builds off that.
Comment #15
erikwebb commentedI believe the Panels display cache settings are independent from the pane settings. It's a container versus being inherited.
Comment #16
jonathan webb commentedAh yes, I can see now - my issue previously was that Panopoly as a CSS issue which was preventing me from seeing the full set of options on the pane settings selector (including the pane cache setting).
Should we show the display cache settings together with the pane cache settings or as a separate report section?
Comment #17
erikwebb commentedMaybe it does make sense to split Panel Pages and panes into separate tables. My original reason to not commit my first patch was because of this specific issue. I guess if they're entirely split that would work too.
Comment #18
snufkin commentedThis will fail when running on a D6 site with
Comment #19
erikwebb commentedDoes the D6 version of the Page Manager API have an equivalent function we can use? At some point we'll have to degrade these checks based on Drupal version, but we probably shouldn't resort to that here.
Comment #20
scottrouse commentedI'm seeing a similar error on a D7 site.
Comment #21
adammaloneThe issue mainly with #18 is because page_manager module is not enabled (even if panels is). There is no issue if the page_manager module is enabled and the output reports as expected.
Initially I used module_load within panels_cacheaudit() to load page_manager module, although I changed my mind and instead implemented hook_cacheaudit for page_manager module rather than panels. This means the hook will only fire when page_manager module is enabled (which is necessary for panels pages/panel nodes anyway).
I've also slightly altered functionality to clean up the output and not print the headers if there are no panels available.
Patch inclusive of patch at #14 and interdiff included.
Comment #22
adammaloneComment #23
erikwebb commentedDoes this work for Panelizer?
Comment #24
adammalonePage manager is a dep for panelizer so I don't see why it shouldn't. I installed panopoly (which uses panelizer) and ran cacheaudit on the freshly installed site. This output the following extract which appears to be what is desired.
Comment #25
erikwebb commentedWe need to get something into Cache audit for Panels and just test afterwards (esp. since it has no negative impact on a site). I've committed this and we can separately add any bugs that show up.
http://drupalcode.org/project/cacheaudit.git/commit/f515954