Allow to position the group in the advanced (sidebar) column

Started to work on in it #2652642: Allow to position the group in the advanced (sidebar) column

I'd like to help with this. @webflo where you at? Any progress? Thanks.

Here's my initial patch for this. I found that simply adding the "advanced" group wasn't working because the field groups are added to far down the process of rendering the form. So I had to change when the field groups get added from #pre_render to #process. I'm not 100% sure what kind of effect that has on other field groups but in all cases were I tested, everything continued to work properly.

+++ b/field_group.module
index 5e514f9..20b01ab 100644
--- a/src/Plugin/field_group/FieldGroupFormatter/Details.php

--- a/src/Plugin/field_group/FieldGroupFormatter/Details.php
+++ b/src/Plugin/field_group/FieldGroupFormatter/Details.php

+++ b/src/Plugin/field_group/FieldGroupFormatter/Details.php
+++ b/src/Plugin/field_group/FieldGroupFormatter/Details.php
@@ -53,6 +53,12 @@ class Details extends FieldGroupFormatterBase {

@@ -53,6 +53,12 @@ class Details extends FieldGroupFormatterBase {
         '#description' => $this->getSetting('description'),
       );
     }
+
+    if ($this->getSetting('advanced_column')) {
+      $element += array(
+        '#group' => 'advanced',
+      );
+    }

Just a general question. Could we add a new Field group formatter which extends from Details and has a slightly different title like: Details Sidebar or so? This would be one less checkbox to care about.

Less clicking would be nicer. :)

I like that idea... if i can get some free time, I'll put it together.

Here's an updated patch based on the suggestion by dawehner in #7

It creates a new field group formatter called Details SIdebar

Thanks for the patch @gclicon!

I've been testing it this morning and it's working mostly as expected.

I would have also expected to be able to order/adjust the default core groups. Right now, you can order them in the UI, place them in newly created groups, on the manage form display page, but none of that has any affect. I've created 2 groups, and they're stuck in the middle of the sidebar. ;) I'm aware that this is because of what Seven theme is doing, but I expected this patch to override that and give the control back to Field Group, while retaining Seven styling.

Is that behavior possible/desirable?

Here are some visuals in case that's useful...

This is what I configured, and expected:

This is what I got:

+++ b/field_group.module
@@ -121,7 +121,7 @@ function field_group_form_alter(array &$form, FormStateInterface $form_state) {
-    $form['#pre_render'][] = 'field_group_form_pre_render';
+    $form['#process'][] = 'field_group_form_pre_render';

By using #process instead of #pre_render we manipulate the FAPI structure, which breaks things like inline_entity_form. field_groups should/details etc. have to be applied just on the render level, IMHO.

Note: This breaks moving elements into the advanced column, but rather let's the advanced detail element stay on the left side.

Latest patch is not showing groups in the sidebar. Looks like the patch might be incomplete?

I'm back to actually rescind my support for this in Field Group, because I don't wish the pain that would come along with maintaining this on the developers who maintain this module. After working with this a little bit more in the theme layer, it's become clear to me how poorly this was implemented (in core) in the first place, and that there's really no good, and definitely no easy way solve it.

First of all, this sidebar only exists for node edit forms, while having it in Field Group, would give the impression to site builders that it would work in other entities. That is unless Field Group wanted to provide templates for the other entities which becomes more of a layout task. That's clearly out of scope of this module, and likely an issue queue support nightmare.

Second of all, there is WAY to much magic crap in core manipulating it via pre_render, and given it's prime location, it's likely to be a target for module developers to additional stuff to, which means preventing the pre rendering is too risky. Only other option there is to recreate the entire group under a different name, but I assume there are race condition risks with that too.

Overall, thanks to core's terrible implementation here, I think this feature request is going to end up as wont fix.

:(

After updating this module to the latest dev version. Patch position-group-in-advanced-column-2652642-5.patch broke. I spent some time trying to rework position-group-in-advanced-column-2652642-10.patch, but I was having issues with getting the new field group formatter to work. I essentially went back to the boolean check that was working on position-group-in-advanced-column-2652642-5.patch and updated the patch to work with the new module updates.

+1 Testing .....

Patch from #18 caused WSOD while editing Nodes with 5 field groups. Probably the error was from max_execution_time limits. I couldn't either debug it but when I removed it the form came back.

Patch #18 works well with 6 additionnal 'details' sidebars on a local dev website.
Thanks.

An additionnal feature would be to allow ordering as it seems I can't put the custom details elsewhere than bettween 'comments' and 'URL alias' tabs (anyway, ordering these core tabs seems not possible yet ;-).

Note that once #2845425: Replace hook_form_node_form_alter() implementations with configured field layouts is resolved, the "Advanced" column will be represented by a layout, and you can drag things into it via the UI.
However, that issue is a long way off still, just wanted to note for the future.

Can this be done with hook form alter and a custom theme template?

About ordering tabs, I don't know if the module Vertical Tabs Config can help or give ideas.

#18 tested successful for me.

I tested #18 and it worked well for numerous content types, but one in particular started throwing the following error when visiting the node edit page:

Full Editor

Fatal error: Maximum function nesting level of '256' reached, aborting! in /home/vagrant/docroot/web/core/lib/Drupal/Core/StringTranslation/Translator/StaticTranslation.php on line 33

Fatal error: Maximum function nesting level of '256' reached, aborting! in Unknown on line 0

Fatal error: Maximum function nesting level of '256' reached, aborting! in /home/vagrant/docroot/vendor/symfony/http-foundation/Session/Storage/Proxy/SessionHandlerProxy.php on line 75

Fatal error: Maximum function nesting level of '256' reached, aborting! in /home/vagrant/docroot/vendor/symfony/http-foundation/Session/Storage/Proxy/SessionHandlerProxy.php on line 57

I determined this is a result of having nested field groups for this content type and is in conjunction with this part of the patch:

diff --git a/field_group.module b/field_group.module
index fdf4c6d..da5b7ed 100644
--- a/field_group.module
+++ b/field_group.module
@@ -172,7 +172,7 @@ function field_group_form_alter(array &$form, FormStateInterface $form_state) {
       );
 
       field_group_attach_groups($form, $context);
-      $form['#pre_render'][] = 'field_group_form_pre_render';
+      $form['#process'][] = 'field_group_form_pre_render';
     }
   }

If I remove the parent field groups or revert this part of the patch, the errors go away. Of course reverting the portion of the patch also results in the field groups not displaying in the sidebar.

I'm going to investigate a little more and see if I can fix this.

Is any of this still relevant in 8.4?

I'm new to Drupal and trying to achieve something similar and landed on this issue, where I need to add new group to the advanced sidebar column.
I'm using Drupal 8.3 Is this issue still relevant?
Could anyone point me to the DEV branch which has this patch? or an dev build with this fix? :)

Hi,

Fresh install on 8.4.2 and 8.x-3.0-beta1 field_group and I can confirm that this issue still applies.

Haven't tried the patch as I'm happy to live with this restraint.

Cheers

Tom

I could add my field widget to the advanced sidebar group column by doing the following:
I don't know if this is the right way or not but does the job for me

//Pseudocode

class MyWidget extends WidgetBase implements WidgetInterface
{
  //override
  public function formElement()
  {
    $element = //Create your form element
    
    //Extend it to the advanced sidebar column by extending and  assigning it to type "details" and group "advanced"
    $element += [
                '#type' => 'details',
                '#open' => FALSE,
                '#group' => 'advanced'
            ];
            
    return $element;
    
  }
}

Thanks and Cheers!

is there any update to this request?

The #10 patch not working in the latest 8.x-1.0 version of field_group module. Uploading the working patch

Confirmed patch in #33 works!

I have been testing patch #33 for a week now and it seems to work with any of the fields I have put there. Haven't been able to break it yet.

#33 patch works fine.
However, if we have conditional fields on form, then all hidden fields also start visible.

Patch in #33 works also at 8.x3.x.

I agree with Jacine that Core makes it very hard to make a nice implementation.
On the other hand, we want to make Drupal shine when we configure the admin interface for our clients.

Maybe this option should be a ("experimental") submodule of the field module so people can understand the risk that involves using this "feature" as long it is not fixed in core. It's up to the maintainers what to do with this.

Seems like #33 is RTBC now.

is there a UI patch for this? i need to be able to move existing fields and id rather not do a form alter if possible

Patch in #33 is a UI patch. You get an extra option when creating a group called "details sidebar".

As note: you have to use seven as admin theme, as sub-theme or need a sub-theme that has the same form alters present. So the form alter you need is already in "core".

ah...thats probably the difference. using a custom admin theme

That is the reason I'm proposing to extend this patch to be a sub-module. It is not only about this patch but it is also to provide the node-edit template & the form alters that are needed to successfully using this feature.
This patch is now assuming the user is using the Seven admin theme or is a dev that is implementing his own form alters like the Seven theme does.

I'm hiding the other patches for a better overview.

We need to fix the failing tests....

This one should probably be postponed, too. If #2916809-12: Add fieldset/vertical tab for URL alias field get’s committed, we would face a different situation here.

@Pancho I don't see why that issue should brake this functionality. If they implement this the right way, is should not affect this issue / patch.
The issue you are referring is about the taxonomy and and media entity page. Those edit pages don't have the fancy right side bar as the node edit form.

So far I´m happy with #33.
I´m having an image-insert-field for the bodytext - now besides the body-field.
Drupal 8.5.1
No conditional field so far ;-) (...#37).

Thanks!

I'm on 8.x-3.0-beta1 and when I apply patch, I don't get the Details Sidebar field group. Is it not suppose to work on that version?

Yeah, this is what I am looking for.
Patch 33 working for me (PHP 7.1, lastest Thunder).

Hi @4kant can be extend this for conditional fields as well?

Patch 33 causes an infinite recursion for me when I have a horizontal tabs field group in my form. I'm guessing other combinations also lead to this problem?

The error:
Error: Maximum function nesting level of '1000' reached, aborting! in is_int() (line 176 of drupal/core/lib/Drupal/Core/Render/Element.php

It even crashes db_log when I try to view the log entry because the log entry is too long. :p

I'm guessing it's due to the first change:

-      $form['#pre_render'][] = 'field_group_form_pre_render';
+      $form['#process'][] = 'field_group_form_pre_render';

Everything works as it should without the patch, but with the patch I'm unable to view the entity form.

Would also like to use this feature to help tidy up the admin interface. I'm getting a memory timeout, with Patch #33 applied, when accessing the node edit page of content type using the field group.

Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 20480 bytes) /web/core/lib/Drupal/Core/Render/Element/RenderElement.php on line 174

which version of Field group are you using? I'm using 8.x-3.0-beta1 with the patch, no memory timeouts...

Re-rolling patch from #33 to apply against latest 3.x-dev

Patch #54 does not work for me.

Yep, I meant to respond back to the thread that even after rerolling, the patch on #54 no longer fixes the issue. We haven't been able to determine a new fix yet.

It was not working for me, so I had to go back in time.
Using process instead of pre_render and the "advanced" assignation wasn't set properly.

Hope this works to everybody!
Cheers

Included "weight" option so you can arrange it the way you want.

Can confirm patch #57 works for me on field_group:3.x-dev. Only problem is moving core components like URL Alias into a new group doesn't remove the default URL Path Settings group when it's empty; that would be nice to have. @logickal we may need to update field_group to 3.x and apply patch #57 (or maybe #59).

Will RBTC with a bit more testing.

I use the patch in #59 with Drupal 8.5.6 and Field Groups 8.x-3.0-beta1. My admin theme is "Seven" and I also use this theme when creating new content.
I can select the "details sidebar" option when creating a new group on the node edit form administration page. However, the new group with this option is still displayed in the normal content section and not in the advanced (sidebar) column on the right hand side of a node edit form. I wonder what I am doing wrong.

The patch in #53 works for me too (against 3.x-dev). @Publishing Future, the patch didn't do anything for me when applied to 3.0-beta1 either.

Patch in #59 works perfectly, well done!

#59 works. Just cache rebuild is needed.

Missing an entry in the schema file for this plugin, adding that

here tis 🇦🇺🦘

I might be missing something, but the patch doesn't work for me.

Tested on 8.6.13, the patch applies correctly, the "Details Sidebar" group type appears, but it seems to be rendered as a standard "Details", never going to the sidebar. Tested with Seven and Adminimal themes.

Which patch are you using @esolitos?

I only tried #71.

Ok, I would say try using #59
We are using that one too and is working great.

Seems that #71 needs some extra love, tests are failing too.

Hem... include facepalm emoji here
Nevermind my derp moment: I realised I was using field_group at version 1.x, I can confirm that #71 works as expected with field_group:dev-3.x#f6d05aaf.

The change from #59 vs #71 shouldn't really matter for the functionality itself, the test failure seems unrelated to the change to me, let's set to "needs review" to re-trigger the test.

Fixed coding standards, no time at this moment to look further into the failed test.

New patch because of little mistake in code of me

The patch looks to work as advertised but the settingsSummary() output has weight listed twice. I've attached that removes this.

I confirm this works as expected. Thanks :D

#81 tested successful for me.

Also works for me.

Patch #81 works fine for me using Field Group 8.x-3.0-rc1 and Drupal 8.7.6
Thanks

My god, this is awesome. Committed and pushed, thanks all!

comment removed, my mistake