Disabling "Advanced Panel Plugins" breaks some Panes (ex. Panels Everywhere)

I'm able to recreate #1 - I also see the weird "Panopoly null" field. However, the pages actually work fine (point #2), until I save that Pane - then I see the correct title, but the node path rather than the actual content:

I think this is probably an issue with Panopoly Magic - since it's the module that messes with the Pane settings.

Actually, it turns out that it's Panopoly Admin that's causing the problems! Disabling it will allow you to edit the settings and then after saving and a couple cache clears the pages will start working. Still trying to narrow it down and come up with a patch.

Here's the code in question:

  // If we are not using advanced plugins and this is an advanced plugin then disable the pane
  if (!variable_get('panopoly_admin_advanced_plugins', FALSE) && panopoly_admin_is_advanced_plugin($pane_label, $category_label)) {
    $subtype['required context'] = new ctools_context_required(t('Panopoly Null'), 'string');
    $plugin['all contexts'] = FALSE;
  }

I'm not entirely sure what the purpose of this is... It seems like it's trying to disable advanced panes? @populist: Can you shed some light on this? I think if nothing else, we should improve the UI of this and make it clear that this pane is disabled...

@lsolesen: Anyway, you should be able to fix this by going to Admin -> Panopoly -> Panopoly settings -> Panopoly Admin and changing "Use Advanced Panel Plugins" and setting it to "Enabled".

Same issue. #3 fixed it for me. Thanks.

Updated the title and issue summary for my plan to fix this in Panopoly.

Here's an initial patch that fixes this for me! It still needs automated tests (and some more manual testing) before it'll be ready to commit.

Oh, and another note before I forget: the current patch will cause our preprocess function to run twice - it should only run once.

Ok! Here's some new patches that fix any known problems and add tests. I'm posting them here so I can pull them into Travis-CI to test there before committing.

It is still just the strange Panopoly Null when putting the Page Element - Content

Hrm. That's really strange, because the patch removes the code that does that entirely. :-/ Can you try clearing the cache? Or maybe removing the Page Element - Content and then adding it again?

Is it safe to use Panopoly with Panels everywhere while I will enable Advanced panels plugins?
I never use Panopoly and I would like to try it (I heard so much positives about that! :)), and to use it with Panels everywhere.

So far I understand this issue - the problem is only when Advanced panels plugins are disabled? Except it, is Panopoly theme fully worked with Panels everywhere?

Thank you
Igor

Is it safe to use Panopoly with Panels everywhere while I will enable Advanced panels plugins?

Yes, we officially support using Panels Everywhere with Panopoly, so if something doesn't work - it's a bug! That said, not that many people use Panels Everywhere, so it doesn't get as much testing as other ways of laying out the page. But I believe that @lsolesen is successfully using Panels Everywhere and Panopoly.

Except it, is Panopoly theme fully worked with Panels everywhere?

So, the default theme with Panopoly is Responsive Bartik, but you usually need to use a more "cut down" theme with Panels Everywhere. If you look at the project page, there's a number of themes suggested:

https://www.drupal.org/project/panels_everywhere

I hope that helps!

@lsolesen: That is really weird! Like I said, this patch literally removes the code that does the "Panopoly Null" thing, so I don't see how it's still present when you test it:

+++ b/panopoly_admin.module
@@ -97,20 +97,44 @@ function panopoly_admin_panels_pane_content_alter($content, $pane, $args, $conte
-  // If we are not using advanced plugins and this is an advanced plugin then disable the pane
-  if (!variable_get('panopoly_admin_advanced_plugins', FALSE) && panopoly_admin_is_advanced_plugin($pane_label, $category_label)) {
-    $subtype['required context'] = new ctools_context_required(t('Panopoly Null'), 'string');
-    $plugin['all contexts'] = FALSE;
-  }

I'm going to try and find some other people to test it and see what they say. But if I can't recreate this, we might have to get on a Google Hangout or something so you can walk me through it...

I can't replicate anything, can I get more steps?

• Fresh installation of Panopoly (RWD Bartik)
• Enable Panopoly Demo
• Enable Panels Everywhere
• Panopoly Admin Settings -> Enable advanced plugins
• Customize homepage -> place "Page header" pane in main content
• Panopoly Admin Settings -> Disable advanced plugins
• View page fine, when I click customize the "Configure" link is now gone (but can move, pane style changes.)

+++ b/panopoly_admin.module
@@ -97,20 +97,44 @@ function panopoly_admin_panels_pane_content_alter($content, $pane, $args, $conte
+    $index = array_search('template_preprocess_panels_add_content_modal', $registry['panels_add_content_modal']['preprocess functions']);
+    if ($index !== FALSE) {
+      array_splice($registry['panels_add_content_modal']['preprocess functions'], $index, 0, 'panopoly_admin_prepreprocess_panels_add_content_modal');
+    }

Why not do in_array() and use array_unshift()? I also haven't done some digging, but can't you disable a plugin through pre_render so there is no need to preprocess?

@mglaman: Thanks for giving it a try! I tried to improve the steps to reproduce under "Original summary" in the issue summary (now in a new "Steps to reproduce" section) while still maintaining the references to #1 and #2 in the comments. I hope this makes more sense!

Why not do in_array() and use array_unshift()? I also haven't done some digging, but can't you disable a plugin through pre_render so there is no need to preprocess?

So, I wrote this so long ago, I don't really remember if there is a reason it couldn't use in_array() and array_unshift(). :-) I just remember it has to be before template_preprocess_panels_add_content_modal() because it manipulates the $vars['categories']. In any case, I kinda like the way it's done in the patch because then it's clear exactly what we want our preprocess function to be before, rather than just putting it before everything.

I don't think we can use #pre_render because this isn't a form.

Thanks dsnopek! I was able to reproduce, and the patch in #10 resolved it.

Here's a note on Page Manager + Panels + Ctools content types: The configuration once saved is cached until the content pane is edited and re-saved. There's a discussion on that issue in #2246893: Does not properly set pane subtype on content edit form submit. for fixing FPP UUIDs post-patch.

@lsolesen: can you try to edit the page, the content pane, save everything and refresh the page? I got this working without needing to adjust the Panopoly settings.

diff --git a/CHANGELOG.txt b/CHANGELOG.txt
index 91d4314..ff6402d 100644
--- a/CHANGELOG.txt
+++ b/CHANGELOG.txt
@@ -1,7 +1,3 @@
-Panopoly Admin 7.x-1.10, 2014-08-06
-----------------------------
-- No changes since last release.
-
 Panopoly Admin 7.x-1.9, 2014-07-31

Er, accidentally set to Needs Work due to this, however I'm sure dsnopek wouldn't commit the hunk that jacked the changelog :)

@mglaman: Thanks! Ah, yeah, the changelog cruft was probably a "needs reroll" that I missed along the line. Just in case, I'm going to update the patch.

@lsolesen: Awesome, I'm glad it's working!

@mglaman: Thanks again for testing!

I've just committed it. :-)