Create drupal 8 version of field_group

the 8.x branch is more testing code by Hydra. It was never a working version. Changing the title of the issue.

I see zuuperman was active 6 weeks ago and pushed things forward.
Would be awesome to have some status update here. :-)

Sprinted two days together with Hydra in Berlin. The code in on github https://github.com/webflo/field_group

Lets talk in Amsterdam :)

Ok, i'll see you there :). Just pushed latest version. It completely moves formatters, formatter settings, formatter summary to the plugin system.

Wow, awesome guys! Thank you for pushing this forward!

We decided during DrupalCon to use ThirdPartySettings on Entity(View/Form)Display as storage. The following patch is a first step in this direction.

True, however, if we would need a displayComponentHandler for some other reason, then the storage would be there.
So ok, we certainly start with this and it might stay this way.

Looks good, committed it to current dev. If #1875974: Abstract 'component type' specific code out of EntityDisplay will be committed, this probably will move to there.

zuuperman, Stalski, please update the issue here once persistency is stable enough to start using field_group. Is there a timeline / roadmap for 8.x?

What is the current status of the field_group storage stability? (Any current work going on?)
Also no activity for 24 days in #1875974: Abstract 'component type' specific code out of EntityDisplay

I've wondered why field_group wasn't in D8 core ... this is a must-have for every site out there that has a front-end, or backend.

So, what can we do to help? The current state isn't even test-worthy, as it crashes everywhere and doesn't show up anywhere.

MrHaroldA: There will always be top X modules that should have been in core.
Obviously it wasn't important enough. Otherwise someone would have taken the ball...

In the current status of Drupal core, module maintainers still need to frequently update contrib code to make it work again.

If you want to help, join a sprint, provide pull requests (many change notices from core would be easy to apply) or fund developers that do the hard work for you.

Where's the latest code? Github isn't touched in over 2 months and the d.o repository has been idle for 7 weeks.

The latest code is in https://github.com/webflo/field_group/commits/8.x-1.x-drupal.org (8 days old)

The latest commits of webflo are merged in current dev. I also fixed some extra fatal errors that occurred due core changes. Seems functional again with current dev version of D8.

About the storage: There is idd not much activity in #1875974: Abstract 'component type' specific code out of EntityDisplay, and i don't take it will be finished at D8 release. So the storage will probably remain the same like on current dev version (inside ThirdPartySettings of the display object).

Extra update: Div wil probably be removed. With HTML element, you can also add divs.

I just tried the new dev version ... I'll try to debug this one first:

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 72 bytes) in /home/harold/checkout/d8/core/vendor/symfony/debug/Symfony/Component/Debug/Exception/FlattenException.php on line 228

So, we're starting to actually use this. testing it, random feedback and thoughts:

1. The edit icon is broken, I assume because of https://www.drupal.org/node/2384159 ?
2. I think we should consider switching adding groups the same way that fields now do as well, the common local action pattern. It is a click more, but it gives more options there, like being able to immediately load the plugin settings through ajax, instead of having to search for them again. I can also imagine multiple options to solve the "add something at a specific place" use case, like a parent selection on the add, and/or a "Add tab/item" link next to delete that preselects the correct type and parent already.
3. Not sure if it is supposed to work, but machine name generation does not (would be easy to fix with 2.)
4. The types should be sorted alphabetically and could really use some description/help (again 2. could help with that)
5. the default advanced group/thing is still/even more a blackbox, any idea how to improve that? At least as annoying as in 7.x that you can't put anything into the sidebar..
6. The add group form is inside/below "Disabled", another thing that would be solved by 2. :)
7. D8 supports #group to move form elements into fieldsets/details, see how NodeForm does that for example with uid/created. No idea if that works for view as well, but maybe that would be a way to simplify the whole prerender thing?

We might have someone that can work on some of those things, but I wanted to get some feedback first.

We completed our review and compared a field_group based approach versus an alter code based group approach.
We realised that the technical dept (volatility, limitations) and extra work (to make it appear similar as core) is too high with the current state.

One of the key reasons for our decision is also that site builder editability is not soo important in our current project. Also migrating away from the small code fragments is easy.
Thus, we decided for the coded approach (for now).

For other projects (soon) this might be different. So we are still eager to push this to a decent point where we can make it a default D8 recommendation.
Looking forward to further feedback.

It might be the field_group module becomes obsolete when this issue gets in Drupal 8.1.x #607396: Killer feature: Fieldable Fields in core

I'm willing to contribute to getting this ready for d8 when it's released. I just need somebody to tell me it's not a waste of time ;)

@askibinski: Relying on this issue and all the related things opens a can of worms. We try to make the loose ends work, but i'm not so sure this will happen soon, at least not in 8.0.x core.

So yes, for Drupal 8.0.x we will need a port for field_groups otherwise no grouping / hierarchy of fields is possible in the UI is possible through UI.

Do you mind clarifying this?

So yes, for Drupal 8.0.x we will need a port for field_groups otherwise no grouping / hierarchy of fields is possible in the UI is possible through UI.

There's a working version of this at https://github.com/webflo/field_group.git, which I've forked at https://github.com/jmonkfish/field_group.git (make sure to use the 8.x-1.x-drupal.org branch)

What's the state of this port?
Is it usable in beta11?

Both branches are ~9 months outdated. 99% sure they don't work with beta11 or current HEAD.

@jmonkfish 8.x-1.x-drupal.org branch is only 2/3 months old, that's why I ask ;)

@jmonkfish Thanks. I merged you changes and remove the 8.x-1.x-drupal.org branch in my repo the reduce the confusion. https://github.com/webflo/field_group is update to date and should work with beta11.

@drewbolles Thanks for the bug report. I pushed some important fixed to my github repo. Please try again ..

@webflo Thank your for the code

May somone here merge the latest code and release it here in drupal.org.. So it will be used by greater numbers of audience. The recent. Drupal8 beta version is pretty solid now.

A quick update: i just merged webflo-fg/8.x-1.x with current drupal.org 8.x-1.x. Now all the latest code of both repos are in the same branch on drupal.org. There were some commits on drupal.org that didn't exist yet on the webflo repo.

Awesome! I think we can close this issue then and switch to an issue based workflow.