To replicate:

1. Go to a "Content page" node
3. Click the cog in order to add some content
4. Click the 'Page content' category and the 'Rendered Content' widget (not the "Add" button but the name)
5. Get an ajax error

The weird thing is that this seems to only affect the preview in the "Add content" dialog, not the live preview when editing the widget settings. Maybe a required context isn't being passed?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mglaman’s picture

Status: Active » Postponed (maintainer needs more info)

Andrew Edwards,

Can you provide more information - such as other modules you're using? I can't reproduce. Also that line of code only changes the readable text, nothing more (our project customizes it even more.) We also utilize mini panels on our product with Panopoly on quite a few sites without reported issues.

After the AJAX error can you check your recent log messages to see if there is a PHP notice/error?

Andrew Edwards’s picture

Status: Postponed (maintainer needs more info) » Active

Hello,

Thanks for looking into this.

I've just tested with the latest version of Panopoly dev (no other modules) and still get the same error.

I followed the steps above with one additional one - step 2 (that I forgot to add before):

1. Create a new mini panel
2. Add required context 'Node'
3. Go to the 'content page' for the mini panel
4. Click the cog in order to add some content
5. Click 'Page content' to try and add some node field stuff
6. Get an ajax error

The ajax error:

EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7734 of /Websites/panopolydev/includes/common.inc).

And error that occurs just before:

Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 173 of /Websites/panopolydev/includes/entity.inc).

If I comment out that line:

$subtype['category'] = t('Page Content');

All works fine. Commenting out that line also changes the URL.

Hope that helps!

Cheers,

Andrew

mglaman’s picture

That is odd. Thanks for reply! I'll give it another run now that I have an idea of what to look for (hopefully!)

mglaman’s picture

So this is verified, however commenting out that line doesn't fix it for me. I believe this issue is actually a bug within Panels. The ctools context is requiring the node context but isn't sending a properly formatted node object (as far as I can tell.)

I haven't run through with xdebug to see what is exactly happening... but it's definitely between Mini Panels + Node context.

Andrew Edwards’s picture

Mm strange that commenting the line doesn't fix it for you. Does the text on that link change to 'Node' and does the URL change? I get 'Node' and the URL /panels/ajax/editor/select-content/panels_mini%3Atest/center/node ... which works for me.

Andrew Edwards’s picture

If the link says 'Page content' then the url is /panels/ajax/editor/select-content/panels_mini%3Atest/center/page-content which makes me think that the url is being created by sticking the link title on the end. If that's the case then yes... maybe that's a panels bug.

mglaman’s picture

Component: Widgets » Magic

Thought I updated this earlier...but...

The issue is Panopoly Magic and when it tries to render the preview. When you select Page Content it attempts to build previews of the pane items. However this invokes panels_create_pane (don't shoot me, guessing func name atm). This gets passed an invalid node object, causing the error.

So what we need to do is check $context is its empty. If its not empty do a foreach($contexts as $context => $info) and check to see if the $info['data'] is null. If its null we have a required context which is missing (since we're editing from a non-node.)

Andrew Edwards’s picture

Hmn I'm not sure about this. Isn't the problem that the URL has changed to /panels/ajax/editor/select-content/panels_mini%3Atest/center/page-content from /panels/ajax/editor/select-content/panels_mini%3Atest/center/node? With the /node URL panopoly magic works fine.

Andrew Edwards’s picture

Apologies... I just removed panopoly magic as a test. Doing that fixes the problem.

Andrew Edwards’s picture

OK. This is where Panopoly Magic breaks:

if ($content = ctools_content_render($pane->type, $pane->subtype, $pane->configuration, $keywords, $args, $context, $incoming_content)) {

line: 1239

minneapolisdan’s picture

Looks like this is still an issue? I have to disable Panopoly Magic to add Page Content fields to a minipanel.

Andrew Edwards’s picture

Yes it is still a problem.

I've attached a patch that I use to fix it. However it could do with some work as all it does is:

- Comments out the code where panopoly_widgets changes $subtype['category'] = 'Node' to $subtype['category'] = t('Page Content').

All the change made by panopoly_widgets should do is change the label, but for some reason (something in panopoly_magic probably, see comments above) it breaks the url as well.

So, after applying the patch the link will read 'Node' instead of 'Page Content', which is less user friendly, but at least you can add node stuff to mini panels!

Really, there should be a fix to panopoly_magic.

dsnopek’s picture

Title: Panopoly Widgets breaks Mini Panels (selecting node fields) » Can't render preview in "Add content" dialog for "Rendered Content" widget
Issue summary: View changes

I did a little more testing on this. It appears it's the "Rendered Content" (type: entity_view, subtype: node) widget that is causing the error. When you have "Enable previews when adding panes" set to "Automatic" it attempts to render every pane in the category - it's less of a problem when it's set to any of the other values because you have to first select that widget to get the error.

I tried using the patch here, and it doesn't solve the problem for me. If I go to the "Entity" category (where "Rendered Content" is) I still see the error. So, I don't think it has anything to do with the URL.

This also appears not to be specific to mini-Panels - I can get the error to happen even in the IPE when trying to use the "Rendered Content" widget. So, I'm going to update the issue summary.

The weird thing is that this seems to only affect the preview in the "Add content" dialog, not the live preview when editing the widget settings. Maybe a required context isn't being passed?

dsnopek’s picture

So, it appears this is failing because the "Rendered Content" widget (from the 'entity' module) has a required context that it's trying to access but it's value is NULL so it fails to load the entity with the error we're getting.

Here's the code:

function entity_entity_view_content_type_render($entity_type, $conf, $panel_args, $context) {
  if ($context->empty) {
    return;
  }
  $block = new stdClass();
  $block->module = 'entity';
  $block->delta = $entity_type . '-' . str_replace('-', '_', $conf['view_mode']);

  $entity_id = $context->argument;
  $entity = entity_load_single($entity_type, $entity_id);
  $block->content = entity_view($entity_type, array($entity_id => $entity), $conf['view_mode']);
  return $block;
}

Stepping through the code, the $context is a valid ctools_context object, with 'empty' set to FALSE and 'argument' set to NULL. It's the entity_load_single() that leads to the error.

So, the preview code in panopoly_magic should be able to determine if there is a required context and if it's unfulfilled, however, I would have thought there would have been something in CTools that would have taken care of that for us! We're calling ctools_content_render() to render the widget.

dsnopek’s picture

Status: Active » Needs review
FileSize
1.54 KB

Here's a patch that fixes the bug when following the exact steps to trigger it. I don't really know if it's correct, though - it could cause other unexpected problems.

dsnopek’s picture

Ok, looking over my patch, I'm starting to think it isn't correct. First of all empty($single_context->data) could be incorrect if a context has a false-y value like '0' or FALSE or empty array. Second of all, we don't check if the context is actually required. And third of all, setting $context->empty won't necessarily do it for all CTools content types - this specific one has code to check for that case, but I could imagine some just assuming they're not going to be rendered at all if a required context is missing.

If we can somehow check if all required contexts are satisfied and then refuse to render the widget if any are missing, that seems like it would be the correct solution.

dsnopek’s picture

The ctools_content_select_context() function might be able to help!

dsnopek’s picture

FileSize
2.94 KB

Ok, here's an alternate patch. However, I'm even less sure about this one because it's so complicated and I'm just not sure all cases are covered. The main thing I'd be worked about is false negatives from my new _panopoly_magic_check_required_contexts(), where the required contexts are satisfied, but it thinks they aren't, so it doesn't render a preview.

But it feels closer to addressing the problem in a general way than the previous patch.

EDIT: Here's a travis build for this patch: https://travis-ci.org/panopoly/panopoly/builds/168704699