Idea summary
What is the problem to solve?
(Missing functionality X, prevent Y from happening, make Z easier to do)
Who is this for?
(Evaluators, site visitors, content authors, site managers, (advanced) site builders, frontend developers, backend developers, core developers, site owners, other?)
Result: what will be the outcome?
(Describe the result: how will this improve things for the stated audience(s)?)
How can we know the desired result is achieved?
(Usability test, a metric to track, feedback)
--- Original report ---
The ability to group fields becomes an important usability factor as soon as you have more than a few fields. If we keep fieldgroup.module packaged with the CCK UI in contrib, any module wanting to group fields programmatically will have to depend on CCK contrib.
The fieldgroup.module as it is right now probably needs some additional work before it is ready for core.
Having a grouping mechanism is important to move the profile.module to use field storage (see #394720: Migrate profile module data to field API).
Comments
Comment #1
bjaspan CreditAttribution: bjaspan commentedI don't care. The "move X into core" train has to stop. I do not see why fieldgroup.module must be in core. Contrib will continue to exist!
Comment #2
webchickI tend to agree. If it turns out fieldgroup.module is the only thing left in CCK, it can always become its own project again.
Comment #3
Stefan Nagtegaal CreditAttribution: Stefan Nagtegaal commentedDoesn't that make this a Wont fixer?
Comment #4
yched CreditAttribution: yched commentedI agree that fieldgroup is not a primary need for core. Given the time constraints, this indeed translates to 'won't fix'
One remark, though: the need to support fieldgroup, even in contrib, has some structural impacts on a Field UI.
In D6, we tried and soon abandoned the idea of making content.module artificially unaware of fieldgroup.module.
If Field UI goes in core and Fieldgroup stays in contrib (both of which I +1), this means additional thinking and coding to allow the Field UI to be extensible.
Just saying before someone else raises the point: form_builder will *not* answer that, because fieldgroups also affect 'node' (object) display - even "worse": ideally, grouping should be per build-mode.
Again, crossposting to http://groups.drupal.org/node/23545 for Field UI challenges.
Comment #5
webchickOk, given this has agreement from both of the major Field API maintainers, I'm going to go ahead and mark "won't fix." This may be something we look at in a later Drupal version, but not for Drupal 7.
Comment #6
tstoecklerJust to note: Won't fixing this issue means won't fixing replacing profile module completely with the Field system.
Comment #7
yched CreditAttribution: yched commented"Won't fixing this issue means won't fixing replacing profile module completely with the Field system"
Not necessarily. It would just mean that some of the current D6 profile.module features would be provided by a contrib module.
It's very possible that "D6 profile -> D7 Fields" upgrade live in contrib too, for that matter.
Comment #9
ayang23 CreditAttribution: ayang23 commentedI think it should be. It is too unconvenient without this module only.
Comment #10
yched CreditAttribution: yched commented@ayang23 : this decision won't change. Much too late now for D7. I also don't there's any good reason to ship it in core D8. Core just cannot include all the modules that are good to have. This one lives perfectly well in contrib.
Meanwhile : http://drupal.org/project/field_group
Comment #11
klonos...as per Angie's comment back in #5. Re-opening so we can reconsider for D8.
I find myself repeatingly installing Field group in my D7 setups. It seems from the project's stats that one out of ten D7 installations use it.
Comment #12
yched CreditAttribution: yched commented"Core just cannot include all the modules that are good to have"
Still true. My .2 cents.
Comment #13
MickL CreditAttribution: MickL commentedHi,
grouping fields is very important to have in core.
Im not for integrating this module into core, but integrating the grouping functionality into the core field system!
The fieldgroup module works, but the user experience is not nice.
I created an Illustration how it could look like, at content types > manage fields tab:
Users can add/edit field groups. Fields could be attached to a group.
Groups should have the following properties:
Checkbox: "Required group"
Dropdown: "Number of values" (Maximum number of values users can add)
When creating a node (node/add/) users can add this group of fields as often as set in the group properties "number of values".
Illustration:
There is also another module (field collection) that can group fields but it is circular and the user loses the clarity.
We definitily need this in core! :)
Comment #14
tstoecklerRe #13: What you are describing is exactly the field_collection.module. I don't know what you mean by "circular", but if you think such functionality belongs in core please open a new issue for that. This one is about fieldgroup.module. The two are definitely related, but each one serves a distinct purpose, so let's not meddle the two together. :-) Thanks!
Comment #15
MickL CreditAttribution: MickL commentedi already opened an issue. it was closed because of duplicate of this one. The problem with field collection is that it is not in the manage fields tab.
Comment #16
lpalgarvio CreditAttribution: lpalgarvio commentedthe two are very very different in concept.
field collection creates an entity with fields, and couples it another entity (like node, user, taxonomy, etc)
it does not add the functionality of creating a group, with a fieldset, accordion, tabs or multipage, where fields can be moved into, which is what field group does.
perhaps both could be added yes. i thought on merging both, but then i remembered, sometimes you want a clear separation of the two functionalities, to get more flexibility, and in some cases, field collection is simply not possible to use (core node/user/taxonomy fields for example).
didn't found the issue, please reference it
Comment #17
tstoecklerRe #15: sorry that that happened, but the person who marked that issue duplicate was clearly wrong. Please re-open that issue and link it from here. Thanks!
Comment #18
MickL CreditAttribution: MickL commentedi reopened it:
#1337130: Group fields
Comment #19
mitchell CreditAttribution: mitchell commentedStatus update?
Comment #20
swentel CreditAttribution: swentel commentedAin't going to happen in D8
Comment #21
webchickComment #22
lpalgarvio CreditAttribution: lpalgarvio commentedComment #23
Dave ReidMight warrant looking if we should investigate if Multifield module is a good fit for D9 core.
Comment #24
catchCould theoretically be done in a minor release.
Comment #25
andypostComment #26
andypostIs fieldgroup stable enough to go in core?
Comment #28
jibranLet's update the issue summary and then we can ask product managers for the approval.
Comment #29
andypostComment #30
dawehner@andypost
I think it would be better to provide a proper issue summary before we get the product manager involved. IMHO we could also first talk with the field and field_ui system maintainer ...
Comment #31
webchickThere's no issue summary update on the proposed direction (there are at least 3 directions proposed in the comments), so nothing to review atm. Feel free to re-add the tag at that time, however.
Comment #33
jibranMoving this to ideas issue queue.
Comment #34
yoroy CreditAttribution: yoroy commentedComment #35
yoroy CreditAttribution: yoroy commentedAdding the "idea template" to the issue summary, it provides a simple format to outline what the actual idea is why it would be a good idea. Short answers to the 4 questions will help us compare and weigh ideas for their relative impact. Thanks!
Comment #36
Chris Matthews CreditAttribution: Chris Matthews commentedThe Field Group module has come a long way since this idea issue was opened 12 years ago. Time to reconsider adding to core ?
Comment #37
ressa CreditAttribution: ressa at Ardea commented+1 for adding Field Group to core. It's such a basic site builder tool, which the position as #10 most installed module. It is enabled on ~44% of Drupal 8/9/10/11 sites (182,000/412,000).
Comment #38
ressa CreditAttribution: ressa at Ardea commentedAlternatively, #2844302: Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase could also solve this?
Comment #39
donquixote CreditAttribution: donquixote as a volunteer commented@ressa Field layout solves a different problem.
I agree field group should be in core, where it can be done much cleaner than in contrib.