I'm seeing 2 checks occur in field_group.module that both ultimately stop a field_group from displaying if its fields are empty:

Line 910:
field_group_remove_empty_display_groups($element, $groups);

and in field_group_pre_render() on line 1759:

if ($element == array()) {
    return;
}

This is a problem for field_group formatters that would like to remain displayed, even if its fields are empty. Specifically, my use case is for a field_group formatter that displays fields using their default forms (http://drupal.org/node/1482876), but I can see other situations where you'd want a field_group to be displayed, such as if a field resulted in text like "No files uploaded yet" or "Awaiting value", i.e. if someone was setting an empty field programmatically.

Would it be within reason to allow for field_groups to have a setting "show hidden fields"? This could then be checked in field_group_field_group_build_pre_render_alter() and field_group_pre_render().

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Berdir’s picture

It also looks like field groups with no real fields (just extra fields) aren't displayed either, not sure if this is related or not.

charlie-s’s picture

My hope is that these 2 functions might be patched to check if $group->formatter_settings['instance_settings']['show_empty_fields'] != TRUE or something like that before it runs these checks.

charlie-s’s picture

Scratch #2. I'm going to now suggest that this be handled within field_group itself for every group regardless of whether or not the formatter provides this setting in it's options. This is because if you style your nodes to have a field_group present (e.g. via floats or what have you) and it's not there, everything can be thrown off. Also, if I have a field_group with a title "Listing of Widgets:" and it's empty, I may still very well want "Listing of Widgets:" to be displayed.

If I write a patch is there even a possibility of this being accepted?

trgreen17’s picture

"If I write a patch is there even a possibility of this being accepted?"

I would love to see this. My use case is slightly different than yours... I would like to use an empty fieldgroup and a text "reminder" when the fieldgroup is empty, to let members of the site that they need to upload a proposal review. I realize there are other ways to do this, but that's what my client asked for.

I can see many other use cases for it as well. Thanks for your work on this!

Tim

charlie-s’s picture

@trgreen23 I'm comforted just to hear that others want this to.

Honestly, I do so much programmatic stuff to nodes and fields via hooks and am quickly realizing that field_group with some cool display formatters (such as a editable form field_group formatter and a table field_group formatter) allow me to keep fields and node logic in the UI and my custom entity code in code.

/rant. I will get a patch together.

nils.destoop’s picture

If you provide a patch, we will be happy to review it.

charlie-s’s picture

FileSize
1.88 KB

The attached patch includes an option to 'Show Empty Fields' and the code necessary for Field Group to still display even if the contained fields are then empty.

I have run into a problem that is a bit discouraging – I see this warning when I load one of my nodes that has an empty field:

Warning: Invalid argument supplied for foreach() in file_field_widget_form() (line 483 of .../modules/file/file.field.inc).

This makes sense. file_field_widget_form() is attempting to run a foreach() on an empty array. The next step would be to add some padding data to the field so that it will be displayed without throwing errors, but this is messy. Any suggestions?

charlie-s’s picture

Status: Active » Needs work

Marking as needs work.

james.williams’s picture

I was using the above patch but ran into some PHP notices when using fieldgroups nested into forms (using the Inline Entity Form module), because the new check doesn't check the group is valid. The attached patch just updates the patch in #7 to avoid this.

I think the solution is nearing :-)

james.williams’s picture

After further testing, I've also noticed that the setting does not work at all for nested fieldgroups, and even causes more PHP notices. This is either of the patches in #7 or #9 above.

Stalski’s picture

Status: Needs work » Needs review

I can understand why this is needed, patch looks good. Other people willing to review and give feedback?

charlie-s’s picture

What version are you applying patch against? I'm going against 1.x-dev and get:

Hunk #1 succeeded at 510 with fuzz 2 (offset 18 lines).
Hunk #2 FAILED at 1010.
Hunk #3 FAILED at 1780.
2 out of 3 hunks FAILED -- saving rejects to file field_group.module.rej

james.williams’s picture

Status: Needs review » Needs work

I should have changed the issue status after my reviewing - see my comments above in #10.

cravecode’s picture

Status: Needs work » Needs review

I really needed this feature and was encouraged by the fact that there was already some contributed work. I updated the patch from comment #9 to work with the current 7.x-1.x branch.

I really hope this feature gets merged into a release soon. For now I posted my branch that includes the patch in a sandbox project at:
Field Group - Sandbox

cravecode’s picture

FileSize
2.81 KB

Sorry, forgot to also attach the fixed patch.

charlie-s’s picture

Hey cravecode, thanks for the patch. Is this working for you? I'm having a problem with the logic where you check the instance setting 'show_empty_fields'.

  // Only run the pre_render function if the group has elements or if the
  // instance settings allow it to show empty fields.
  if ($element == array() && !empty($group->format_settings['instance_settings']['show_empty_fields'])) {
     return;
  }

The "is not empty" means if the "show_empty_fields" checkbox is checked, correct? If we want to let the pre_render functions run, we shouldn't return here. Am I reading it wrong? There are 3 places where this check takes place, and after switching them all to something like if ($group->format_settings['instance_settings']['show_empty_fields']) (to return TRUE when checked) and my code that needs this functionality works as expected. Let me know if I'm just reading something wrong.

cravecode’s picture

yeah that "!empty" is definitely wrong. I'm not sure what my mindset was for that. I'll look over it when I'm back on my dev machine and post a followup.

charlie-s’s picture

Sounds good. If you post a new patch I will review it on my install and any others can as well – maybe we can get this committed.

cravecode’s picture

I removed the bang from the empty check and tested it on my local dev setup. Seems to work fine.

I'm using "empty" instead of using a normal truthiness check because I don't know if there are possible scenarios where the logic will be evaluated and the show_empty_fields is not in the array. One example I can think of is existing field_group configurations that haven't used the config form with the new "show empty" option. There would be missing index notices thrown/logged.

charlie-s’s picture

Great point and I agree. Patch is good for me. Thanks!

james.williams’s picture

Does this latest patch work with nested field groups? This was the problem with the original patches in comments 7 & 9 above.

charlie-s’s picture

Yes, works for me with nested field groups. The recursive field_group_remove_empty_display_groups call is doing this, I think.

JThan’s picture

Issue summary: View changes

Thank you for the patch.

I have testet it: The tabs are now all shown (That is what I need, so I am happy).

But: All Tabs were shown right after I included the patch. This made me curios and I tested the settings. They dont seem to have any effect. It does not matter if I check that the Tabs should be shown or not, they are always there.

iMiksu’s picture

I tested this in edit view and the patch seems to work from there, but when using field groups in display/view mode, I get same affect as @JThan reports in #23.

iMiksu’s picture

Status: Needs review » Needs work
iMiksu’s picture

Status: Needs work » Needs review
FileSize
3.05 KB

Maybe this covers #23 issue? It should work with nested groups, but I didn't tested it, could someone have a look/try?

iMiksu’s picture

New release has come and given an notice about invalid variable type for foreach to this feature/patch. Hopefully this fixes it.

  • New function _field_group_is_empty_element() meeds to prepare for calls having $element[$childname] as NULL (due to intentional empty rendering)
  • Removed trailing empty whitespace

Status: Needs review » Needs work

The last submitted patch, 27: empty-config-1482958-27.patch, failed testing.

iMiksu’s picture

I tested manually creating a new group without problems (as described in the automatic test), is it a random fail?

iMiksu’s picture

Status: Needs work » Needs review

The last submitted patch, 9: field-group-show-empty-1482958-9.patch, failed testing.

The last submitted patch, 15: 7.x-1.x-empty-config.patch, failed testing.

The last submitted patch, 19: 7.x-1.x-empty-config-2.patch, failed testing.

iMiksu’s picture

I don't understand why the tests are failing. Anyone knows?

jantoine’s picture

Version: 7.x-1.x-dev » 8.x-3.x-dev
FileSize
3.2 KB

Created a patch for the 8.x-3.x branch.

Status: Needs review » Needs work

The last submitted patch, 35: empty-config-1482958-35.patch, failed testing. View results

Stockticker’s picture

FileSize
3.23 KB

Added additional checking on $element[$name]['#show_empty_fields'] existence since it gave me some errors on my website (sometimes element[$name] is just an empty array)

Stockticker’s picture

FileSize
3.25 KB
406 bytes

Actually, I've created patch for wrong branch (dev-branch where array notations have been changed), so no interdiff could be created.
Fixed that, so this one should be applied.

Vidushi Mehta’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 38: empty-config-1482958-38.patch, failed testing. View results

Anybody’s picture

nikita_tt’s picture

FileSize
3.59 KB

The same patch as #38 but with support for groups inside a form but not only inside the display.
For 8.x-1.x version.

W01F’s picture

Trying to apply either the 38 or 39 patches to the new 3.0 or 3.x-dev versions without any luck

prinds’s picture

Patch in #27 works for drupal 7.67 and field_groups 7.x-1.6.

This option is very useful, now that field groups without visible fields are automatically hidden (which is also useful in many cases).

I hope this feature will be added in a future release..

marc.groth’s picture

Status: Needs work » Needs review
FileSize
4.46 KB

Thank you so much for the patch in #42 @nikita_tt. I had to refactor it slightly because it wasn't quite working for me (updated patch attached). In particular I altered the following:

  1. field_group.module (line 513) - I added a check for an empty 'show_empty_fields' value. Without this the code in hook alter never ran
  2. field_group.module (line 742) - I added a check for an empty 'show_empty_fields' value. Without this the following code was always executed which meant the group was not displayed

This is working for me with the following setup:

Drupal core: 8.7.5
field_group: 8.x-3.x-dev
simple_multistep: 8.x-1.0-alpha4

It even works for nested groups

adinac’s picture

A new version of the patch that works for 8.x-3.x

rutel95’s picture

@marc.growth thanks for the patch(#45). I adapted your patch for 8.x-3.x

This is working for me with the following setup:

  • Drupal core: 8.8.6
  • field_group: 8.x-3.1
Peter Majmesku’s picture

Status: Needs review » Reviewed & tested by the community

I can confirm that the patch from #47 is working. It is very useful. Thank you! Please commit this patch to the main field_group module!

Tested with

  • drupal/field_group - 3.0.0
  • drupal/core - 8.8.10
pp.panatom’s picture

i used rutel95s patch (#47)

show_empty_fields is missing in field formatter for details

Tested with

- drupal/field_group - 3.1
- drupal/core - 8.9.14

new patch attached

nils.destoop’s picture

Status: Reviewed & tested by the community » Fixed

Thx for the patch. I changed the label a bit and committed it to dev.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.