Support for fences to render a field in a panel pane

Views/Panels has its own "view field" rendering which is separate from core's field rendering. It doesn't use theme_field() which fences requires.

I believe there is an option (per field) to tell Panels to use core's field.tpl, but I can't remember where it is or what the exact wording of the option is.

I haven't been able to find a setting in Views or Panels that alters the HTML when Fences is used. Views does have the (per field) settings altering HTML (and CSS classes) output (see attached screenshot), but they don't alter the output of Panels (see the 2 other screenshots). Panels easily adds another 6 layers of div's without any real use.

Thanks for (yet another) great contrib!

You are correct about Panels. I can't find a setting for "use field template" in the field pane settings.

However, Views does have this setting. When configuring each field, under “Style settings”, make sure the “Use field template” checkbox is checked.

Guess that makes it a feature request. Though it probably should be a feature request for Panels.

this works with panels_extra_styles

Here we go.
The attached patch hijacks the ctools content type Entity Field which is responsible to output fields in Panels / Mini-Panels / Panelizer etc.
It adds a new setting in the pane settings to select the fences wrapper.
The same field can be rendered with different wrappers on the same page / panel too.

This is actually a new feature and it has a patch.

Sometimes it seems like the include file isn't properly included - mostly when dealing with ajax. Adjusted the form to use form_load_include().

Fixed!!!!

Amazing how long these things last, but get solved in the end.

Update to Drupal 8? :-)

Unfortunately, this patch is causing a fatal PHP error now. I'm going to have to revert it.

:-(

Original post from rei in #2491279: Fatal error: Call to undefined function fences_ctools_entity_field_content_type_render() in ctools node_body.inc:

The latest dev (7.x-1.0+7-dev) produce fatal error when use with panels
the version 7.x-1.0+6-dev doesn't have this error.

Fatal error: Call to undefined function fences_ctools_entity_field_content_type_render() in .../ctools/plugins/content_types/node_context/node_body.inc on line 24

step to reproduce:
1. enable fences,ctools,panels,page manager
2. create basic page (i.e about-us)
3. create custom page using page manager (i.e /home)
4. in panels custom page, Add Node Context for about-us node above.
5. Goto Content,
6. Add Content -> Node -> Node body (Not Field: body)
7. Save
8. go to custom page about (/home)
9. Fatal Error

So in ctools/plugins/content_types/node_context/node_body.inc:

function ctools_node_body_content_type_render($subtype, $conf, $panel_args, $context) {
  $plugin = ctools_get_content_type('entity_field');
  $conf['formatter'] = 'text_default';
  $conf['formatter_settings'] = array();
  return $plugin['render callback']('node:body', $conf, $panel_args, $context);
}

It's grabbing the entity_field's render callback and calling it directly without checking if its loaded. Presumably, ctools_get_content_type() loads the .inc files needed, but for some reason the fences .inc is not being loaded.

This is possibly a bug in ctools related to #1019350: node_body.inc should be removed., but I'm not proficient in ctools API to be able to tell if its a bug or not.

Reverted. :(

Here's the patch that would add the feature back. But it needs work as it still causes a fatal PHP error.

I'll give this a try - was my patch I'll try to take care of it.

How about this:
In fences_ctools_plugin_post_alter() we overwrite the plugin definition of node_body as well.
Also register our own render callback. This is the only way I can think of because the quirky plugin handling of ctools.
We can't just randomly include plugin files because ctools uses require_once() to load those files and then checks if the $plugin variable was defined by the included code. This only works if the files wasn't included before. So including the files before ctools_get_content_type('entity_field'); was triggered would lead to missing plugin information.
The reason for the strange handling is documented in the code.

The patch in #20 is the same hacky way I could have fixed this bug. I don't feel confident in the patch at all. Partially overriding the entire plugin just to add a field to the form seems crazy.

Unfortunately I don't have any other idea on how to solve this without adjusting ctools itself. :| I'll see if I can come up with something else but am afraid that this won't be easy.

I looked at this again and realized we only need to override the renderer of the entity_field content type.

So I've simplified the implementation a bit: https://www.drupal.org/commitlog/commit/27502/4b22e4df64c5f3e5910b3d07fa...

and pushed the change to 7.x-2.x-dev.

Awesome, thanks a lot!!

Looking at the commit history of this issue I am wondering if it is save to upgrade from version 7.x-1.0 to 7.x-1.2 or should I better upgrade to the 7.x-2.0 branch (7.x-2.0-beta1) ?