Vertical tabs broken when displayed in custom block region

I have the same problem. I created a list structure with field group HTML element and tags. It works as expected. When I move it over to a block region, only the tags (with the rewritten html) are displayed, and none of the field group wrapper items. It is the same when cloning a view move that contains field-groups, although that I suppose is expected behavior.

Same here. Field groups are rendered correctly if you place them in content region but once you move them to custom block region the field group itself is not rendered at all, only the fields inside it. It doesn't matter about the format of a field group (fieldset, html element, div, etc.). It works with Field Group 7.x-1.1 but not with 1.2 or 1.3.

It works with Field Group 7.x-1.1 but not with 1.2 or 1.3.

ISn't this a fieldgroup problem than?

I can confirm that this is also the issue when using other field groups such as the simple div element. I'm attempting to nest a couple of them with a couple of fields inside the inner one to achieve a vertically aligned layout on top of a banner image using the old table > table cell display trick in CSS....

So in the block region we have:

Banner Block
Banner Image
> Table
>>Table Cell
>>>Tagline
>>>Call to action (link field)

I traced the issue to ds_extras_field_attach_view_alter(). This function is looking for fields, but the fieldgroup are added to the array differently. I will try to create a patch, but not sure yet how to fix this (maybe it's not possible at all?).

Possibly related: https://www.drupal.org/node/1334128

*edit
The fieldgroups are added to the $block_data array just fine, the only thing that is missing is that field_group_fields_nest() needs to run for each region to set up the render array.

Patch is attached!

Ignore the old patch (stupid last minute copy paste error!). Here is a new one.

Not sure if this is related to the patch? All it really does is nest some fields in fieldgroups with the function provided by the field_groups module. I didn't test this with vertical tabs but this could be a seperate issue?

Tested patch (#8) on ds_extras 7.x-2.6. This patch fails, the problem is all fieldgroups are rendered even if they are not put into the specific region (block to region). Based on the patch, I don't believe that it will make any difference if this was tested on 7.x-2.x-dev

Testing failed with module versions:
Field Group (field_group): 7.x-1.4
DS Extras (ds_extras): 7.x-2.6

I confirm that patch #8 works for "div" fieldgroups.
Thanks seanB!

Tested patch #8 and seems to work fine (tested with the "fieldset" and "div" settings)

I don't have the problem of fieldgroups always being rendered described in #11.
If the output within the fieldgroup is empty (whether placed in a regionblock or in the normal content) the label of the fieldgroup doesn't show.

Thanks for the patch!

Display Suite Extras (ds_extras) 7.x-2.6
Fieldgroup (field_group) 7.x-1.4
Drupal 7.32

Patch #8 Bug:

Finally tracked my issue (#11), I admit it was hard to reproduce. The issue is reproduced by having the following hierarchy:

- Horizontal Tab Group
-- Horizontal Tab
--- DIV Group*
---- Field

* I believe it doesn't matter if this is a DIV, Fieldset, etc. It's the fact there is a third child that exists.

I'm marking this back to Needs work:

#8 patch will serve fine for some users, although I personally don't believe the patch should be committed "as-is", 1) because known issues with nested groups, 2) because field_group_fields_nest() function that is used; this function mixes ds_extras module with field_group module, (almost) as if ds_extras module is dependent on field_group module.

1) Must be resolved, I agree!
2) We could add a module_exists check to remove the dependency?

I hope I can find some time to take another look.

2) I think that comment #3 makes a very relevant point.

It works with Field Group 7.x-1.1 but not with 1.2 or 1.3.
Isn't this a fieldgroup problem than?

I've confirmed that Display Suite (DS) does allow for module_exists('field_group'). It's actually used a couple times in the DS modules.

I have also fixed the issue related to nested field groups. I do think this is a issue related to ds_extras module (not field_group), I think it's related to the lateness that hook_field_attach_view_alter is called in ds_extras. I did a few tests, and they confirmed that Patch #8 was a solid attempt (very close).

If by chance, this new patch doesn't get committed, I have lastly created a module that solves the problem without the need for the Patch to be applied. I admit the patch is a better route than utilizing my sandbox module. I'm changing the status to "Patch (to be ported)", hopefully a Display Suite module maintainer can agree on the patch.

Sandbox Module: https://www.drupal.org/sandbox/stevesmename/2366703

I'll poke swentel for this one, it would be nice if someone else could verify this works in every case.

looks good

The other option was to create a wrapper function (much like field_group_form_pre_render). I wasn't sure if this would had been easy to understand in my initial patch.

/**
 * Pre render callback for rendering groups.
 * @see field_group_field_attach_form
 * @param $element Form that is being rendered.
 */
function field_group_form_pre_render(&$element) {
  return field_group_build_entity_groups($element, 'form');
}

So I'd maybe suggest the following, but I am not sure what the second parameter should be ('ds_extras'?).

/**
 * Pre render callback for rendering groups.
 * @see field_group_field_attach_form
 * @param $element Element that is being rendered.
 */
function ds_extras_group_pre_render(&$element) {
  return field_group_build_entity_groups($element, 'ds_extras');
}

Here is what field_group_build_entity_groups is:

/**
 * Preprocess/ Pre-render callback.
 *
 * @see field_group_form_pre_render()
 * @see field_group_theme_registry_alter
 * @see field_group_fields_nest()
 * @param $vars preprocess vars or form element
 * @param $type The type of object being rendered
 * @return $element Array with re-arranged fields in forms.
 */
function field_group_build_entity_groups(&$vars, $type) {

  if ($type == 'form') {
    $element = &$vars;
    $nest_vars = NULL;
  }
  else {
    $element = &$vars['elements'];
    $nest_vars = &$vars;
  }

  // No groups on the entity.
  if (empty($element['#fieldgroups'])) {
    return $element;
  }

  // Nest the fields in the corresponding field groups.
  field_group_fields_nest($element, $nest_vars);

  // Allow others to alter the pre_rendered build.
  drupal_alter('field_group_build_pre_render', $element);

  // Return the element on forms.
  if ($type == 'form') {
    return $element;
  }

  // No groups on the entity. Prerender removed empty field groups.
  if (empty($element['#fieldgroups'])) {
    return $element;
  }

  // Put groups inside content if we are rendering an entity_view.
  foreach ($element['#fieldgroups'] as $group) {
    if (!empty($element[$group->group_name]) && $type != 'user_profile') {
      $vars['content'][$group->group_name] = $element[$group->group_name];
    }
    elseif (!empty($element[$group->group_name])) {
      $vars['user_profile'][$group->group_name] = $element[$group->group_name];
    }
  }

  // New css / js can be attached.
  drupal_process_attached($element);
}

Patch #18 seems to work ok for the built-in formatters, but not for additional formatters such as field_group_background_image. Does anyone have any idea why this might be, off the top of their head, before I spend ages trying to work it out myself?

And what about #23?

Re: @mangy.fox (#24),

Try this attached patch. I had been thinking that my #22 patch was wrong (removing that patch), we should be passing 'display' instead 'ds_extras' (makes a lot more sense). I personally didn't test this but will hopefully later in the day.

I took a quick look at field_group_background_image and noticed that they are using the 'display' functionality so I firmly believe this new patch should work for you (and others).

Re: @mangy.fox (#24),

Try this attached patch. I had been thinking that my #22 patch was wrong (removing that patch), we should be passing 'display' instead 'ds_extras' (makes a lot more sense). I personally didn't test this but will hopefully later in the day.

I took a quick look at field_group_background_image and noticed that they are using the 'display' functionality so I firmly believe this new patch should work for you (and others).

Similar to my experience of #23, I end up with no field group or contents rendered and the following warning

Warning: Invalid argument supplied for foreach() in element_children() (line 6465 of xxxxxx/includes/common.inc).

I'll give it another run on a clean environment later to make sure it's not just this current setup.

Can you list the verisons of the modules you are using on the current setup? (ds, ds_extras, field_group, field_group_background_image)

That environment was with...

ds 7.x-2.6
ds_extras 7.x-2.6
field_group 7.x-1.4
field_group_background_image 7.x-1.1

Also tested on an older environment with field_group 7.x-1.3, same result and warning.

Tested on simplytest.me with patch #26

ds 7.x-2.7
ds_extras 7.x-2.7
field_group 7.x-1.4

Same result and warning. It seem the field group does not even need to be in use. Even when there is one in the disabled section, the block region fails to render.

I was able reproduce the error. Very strange that I didn't have problems initially, I am leaving #18 patch for the time being. I will attempt to work on this issue later tonight.

#18 helped me on a project. Is it save to commit that as is? Even if it doesn't fix *all* the issues.

@aspilicious, let's mark it "Needs review" and let's see. I am personally not sure because additional formmatters such as #24 hasn't been tested enough on my end.

Just wanted to chime in/thank @stevesmename: #18 saved my bacon.

Ditto the above comment.

I confirm patch in #18 does not fix the issue with Field Group Background Image module.

I would be happy to address the issue in that module if I had to, but as far as I can see it's OK there: the render array of the field group is build in a hook_field_group_pre_render() implementation.

I have confirmed that the Field Group Background Image module is a separate issue, likely related to module weight. It's important to also understand that the Field Group Background Image module is not dependent on Display Suite or Display Suite Extras modules, it's dependent on field_group module. Field Group (field_group) module is not dependent on Display Suite either.

We are sort of asking for a favor from the maintainers of Display Suite to add patch #18 - it will help address other issues related to field_group, its dependent modules, and display suite regarding the #pre_render issues we are seeing.

Let's push this!

This patch is not working in combination with the Display Suite Region Blocks. We should be checking if the $field (from the foreach above) value is present in the #fieldgroups as a key.
I will return with a patch later.

Patch from #26 is not rendering all fields in Block regions correctly. It assumes in the if statement all "groups of fields" are fieldgroups, but this is not always the case. I altered the patch, adding an extra check before adding the #pre_render function. If a field is not in the "#fieldgroups", it's not a fieldgroup.

I created a new patch but it should be tested by others on different set-ups/use-cases so it can be fine-tuned to work well in all cases.
Created the patch on the latest dev and tested it on the latest stable.

#18 works for me

Can confirm that #18 fixed the issue, and also confirming that patch #26 gave me the same issues as mangy.fox (all my fields within that group disappeared and it threw an error). It would be great to get the fix from #18 committed.

#18 helped me on a project.

#18 worked for me as well.

+1 for #18

Another +1 for #18.

Patch in #18 worked for me too. Can we get this committed please?

Thanks!

+1 for #18

+1 for #18

Can we have this committed please? Tnx.

Just chiming in that #18 was the fix I needed.

The patch from #18 still applies to version 7.x-2.15

I think the assigned "stevesmename" isn't active anymore, and nothing will happen with this ticket unless we change the maintainer. Little bit busy now, but i'll try to fix this tomorrow.

Can we get this committed?

Committed 18 to dev. Sorry for the delay.