search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
145 stars 40 forks source link

Field group functionality in core #647

Open sirkitree opened 9 years ago

sirkitree commented 9 years ago

Update 2023:

It has been decided that the field group module provides more options for field groups than we wish to include/support in core, so rather than move the entire module into core, we are planning to revamp the fieldgroup API and move certain types of field groups into core (groupings that already exist in core) and to leave others for the contrib module. The new fieldgroup API will become part of core's field + field_ui modules.

Group types planed for core:

Group types that should remain in contrib:

The Field Group contrib module would simultaneously release a new minor version (that depends on this version of Backdrop core) where those group types are removed from the module, and all remaining types are updated to use the core field group API (which will be similar to what's there already). The current group API will also be removed from the contrib module.

Requirements for getting new fieldgroup contrib module in core:

Original Issue: It would be pretty outstanding if we have field_group in core so that forms could be arranged a lot nicer with things like vertical tabs and such through the UI.

Requirements for getting fieldgroup contrib module in core:

User experience cleanup options:

New features (options):

Related issues:

Issue advocate: @jenlampton

quicksketch commented 9 years ago

I agree, I think this would be a useful addition. I think putting it in core is about the only way to handle it cleanly. Considering the options available today (Field Group, Field Collection, Multifield, etc.) none of them work well because they have to make core work in ways it wasn't intended. Though if we change the way core works, then it may be possible to make this work more cleanly.

This may be a 2.x issue; I'm not sure how much API change would be required (if any) to implement this. Marking 1.x until we explore the options.

klonos commented 9 years ago

Yes please!!

mikemccaffrey commented 8 years ago

Wait, field groups have not been ported yet or merged into core? We should definitely get this done asap.

@klonos Can we keep this ticket limited to the functionality provided by Field Group, which just concentrates on organizing field, unlike Field Collection and Mulitfield, which are actually a type of field with their own data architecture?

klonos commented 8 years ago

@klonos

?? I think you probably meant to mention @quicksketch but yeah, I agree. ...unless Nate wants to tackle this in a single module in a "unified" way that binds all features together.

mikemccaffrey commented 8 years ago

@klonos I was just apologizing to you, since I was undoing the change that you made in adding Field Collection and Mulitfield to the issue title! But you are right, I should have added @quicksketch too since he was the first one to mention them all.

MrHaroldA commented 8 years ago

This is a real blocker for my Backdrop installs too. Not the field collection, or multi field modules, but the possibility to add vertical tabs, horizontal tabs, fieldsets, etc through the field ui.

The Field Group module is ridden with CTools and Features specific code though.

biolithic commented 8 years ago

@MrHaroldA would you prefer a new module reusing the ideas of Field Group or just a straight port replacing Ctools with our own functions?

MrHaroldA commented 8 years ago

Field group is big. Probably way too big. Also the UI is a bit weird when creating tabs; you have to create a tab container first.

Let's start small and slim, and gradually add features if there's a reasonable demand for it.

Adding fieldset support for example will give you a lot to work with; you could even theme them as horizontal or vertical tabs.

serundeputy commented 8 years ago

moving to 1.5 feel free to move back if someone wants to tackle it.

vonnnew commented 8 years ago

Hi All, I'm attempting my first Backdrop build now. I really need the Field Collection module. It doesn't appear to have been ported yet. Is this true? If not, I will attempt it but it will be my first attempt to port a module.

herbdool commented 8 years ago

Field collection hasn't been ported. At least I don't see it in the backdrop contrib list: https://github.com/backdrop-contrib/?utf8=%E2%9C%93&query=collection

Let's keep this issue focused on field group, however, which is for different purposes. I agree with @MrHaroldA about paring down field_group but it's also useful to keep it as close as possible with the Drupal 7 version for now. As far as I can tell, ctools is only being used to provide the CRUD functionality in the UI, which presumably could be replaced with Backdrop's CMI.

jenlampton commented 8 years ago

@vonnnew Field collection is going to be a doozy for your first port. I'd personally been checking out multifield instead since Field collection has some serious performance implications. Good luck!

also, since there is no PR for this yet, and this issue was bumped from the last release, I'm pushing this to 1.x-future

laryn commented 7 years ago

Found my way here on a search. To update RE the mentioned contrib modules:

klonos commented 7 years ago

Since 2015 (when this issue was first filed), there's a new player that's been gaining momentum: https://www.drupal.org/project/paragraphs

Paragraphs is the new way of content creation! It allows you — Site Builders — to make things cleaner so that you can give more editing power to your end-users.

Instead of putting all their content in one WYSIWYG body field including images and videos, end-users can now choose on-the-fly between pre-defined Paragraph Types independent from one another. Paragraph Types can be anything you want from a simple text block or image to a complex and configurable slideshow. ...

In fact, there's a note in the https://www.drupal.org/project/field_collection project page that says:

Paragraphs is likely to replace field collection for Drupal 8. Field collection is on its way to being deprecated. It is recommended to use paragraphs instead of field collection for Drupal 8 projects.

I agree with @mikemccaffrey that we should keep this issue focused in getting the field group functionality in core (a good candidate for 1.9 perhaps?), but I think that we should seriously discuss about the concept of paragraphs and getting that into core too. It would be a killer-feature to have for 2.0 I think.

klonos commented 5 years ago

I have recently created #3766 to track progress on what's cookin' for D9 ...it seems that https://www.drupal.org/project/field_union is where things will happen.

quinnanya commented 5 years ago

Would definitely support having at least field group, and ideally something more repeatable, in core. The need for that functionality has been haunting me since Drupal 5.

ghost commented 4 years ago

I just installed the Field Group module on my dev site to see how it works and get an idea of how it'd ideally work in core. Here's how it currently looks:

Screen Shot 2020-08-16 at 13 21 50-fullpage

My thoughts:

Based on my suggestions, here's how it could look:

Screen Shot 2020-08-16 at 13 32 58-fullpage

herbdool commented 4 years ago

I've usually used the clone feature. If there's a way to preserve would be good.

jenlampton commented 4 years ago

This looks great. Can we add a clone link into operations for the field groups?

klonos commented 4 years ago

Can we add a clone link into operations for the field grpups?

Yes please! Would love that ❤️ ...although it may need to be a "clone from" and a "clone to" functionality. Could be a follow-up issue.

  • Instead of having a seperate 'Add new group' row below 'Add new field', just have 'Group' as an option under 'Select a field type', and the different group types (e.g. fieldset, vertical tab, etc.) as 'Widgets'.

I'm not opposed to this, but wanted to mention that back in 2015 @wesruv has provided some mockups in https://github.com/backdrop/backdrop-issues/issues/779#issuecomment-141707916 and https://github.com/backdrop/backdrop-issues/issues/779#issuecomment-163844301 of how things could work if we switched to an "Add field" button, same as D8/D9:

image

UX studies by our Drupal brethren have shown that it is a much better workflow, and confuses people less than the current UI (and I prefer it too TBH, because it brings consistency in our UI patterns). In D8/9 they've separated the UI that allows adding and reordering fields into a dedicated "Manage fields" and a dedicated "Manage form display" form. So the "+ Add field" and a "+ Add field group" buttons there are in separate places. We might need to move to a UI that has the 2 "+ Add field" and a "+ Add field group" buttons side-by-side at the top-left. If you put it all together, and include @jenlampton's suggestion in @BWPanda's mockups, it would like this:

Screen Shot 2020-08-18 at 10 24 11 pm

Remove the whole 'Fieldgroups' fieldset ...

👍

Make a field group look and act more like the other fields by moving all configuration to a seperate page...

Also 👍 ...UI consistency please. I would suggest that we eventually switch to using dialogs at some point, same as we've done in text formats UI in #1032, which I find to be a big UX++, as the user remains within context of the task they set off to do.

jenlampton commented 4 years ago

I don't know about this.. I find a LOT Of value in being able to see the fields that have already been added while adding a new one. I would hate to loose that behind a modal, or on a previous page. (This is particularly important on content types with lots of similar fields).

I also really like the ability to put the new field right where you want it (between other fields) when it is added, rather than needing to return at the end to order them.

I like consistency where it makes sense, but when you have different needs on different pages, the UIs should be different.

klonos commented 4 years ago

I find a LOT Of value in being able to see the fields that have already been added while adding a new one. I would hate to loose that behind a modal, or on a previous page.

Dialogs work fine that way when adding blocks to a layout. Just saying.

I also really like the ability to put the new field right where you want it (between other fields) when it is added, rather than needing to return at the end to order them.

Again, block placement works that way: new blocks are added to the bottom of any existing blocks in the same region; then the user needs to drag them to the desired place. But perhaps we could find a way that this works the same as the +/- buttons in option elements:

Screen Shot 2020-08-19 at 1 09 01 am

jenlampton commented 4 years ago

Dialogs work fine that way when adding blocks to a layout.

Sure, it's "fine". But I don't think it's as good as what we have today.

Again, block placement works that way: new blocks are added to the bottom of any existing blocks in the same region;

Yes, and this is also a pain point that we have learned to deal with. It's all "fine", but I prefer the better UI we have now and would hate to move backwards for the sake of consistency.

Can we move these thoughts to another issue? I don't want a UI rewrite to block getting Field groups in core!

klonos commented 4 years ago

Can we move these thoughts to another issue? I don't want a UI rewrite to block getting Field groups in core!

Sure can 👍

olafgrabienski commented 4 years ago

I don't want a UI rewrite to block getting Field groups in core

Agreed! So, back to @BWPanda's suggestion? Don't see it as UI rewrite but contrib integration:

Instead of having a seperate 'Add new group' row below 'Add new field', just have 'Group' as an option under 'Select a field type', and the different group types (e.g. fieldset, vertical tab, etc.) as 'Widgets'.

I like the idea to treat fields and groups in the same Ui. Unfortunately, some labels and descriptions don't cover the group use case, e.g. the following bold words:

laryn commented 4 years ago

Definitely in favor of adding this functionality in a more streamlined way. (I like "Add new element")

I will note that the Clone functionality at the bottom seems different than simply adding a clone option in the operations dropdown -- I've never used it, but it looks like it clones field groups from a different view mode into the one that you're looking at, not simply cloning a group from the current form to the current form.

philsward commented 3 years ago

FG works fine for minimal stuff. Not so great for more complex stuff. Wish FG was easier to deal with on bigger entities.

I think it might be easier if the FG containers were collapsible and you could drag one collapsed container into another collapsed container. Spit ballin.

image

klonos commented 3 years ago

Oh wow! 😅

stpaultim commented 3 years ago

We are approaching that final month before code freeze for version 1.21 and this is the issue that got the most votes in our priority survey last March that has not yet gotten into core (in fact, it was highest on the list at the time of the survey).

In our recent prioritization discussions, this issue was rated "Medium" difficulty and "Medium" impact. This could be the flagship new feature of 1.21. Maybe??

My understanding from reviewing this discussion is the following (this is my attempt to summarize the discussion so far):

  1. This issue is NOT about multi-field or field collections. It IS about the ability to organize fields into groups "so that forms could be arranged a lot nicer with things like vertical tabs and such through the UI" or " possibility to add vertical tabs, horizontal tabs, fieldsets, etc through the field ui."
  2. There seems to be a consensus (so far) that the goal would be a paired down (simplified) version of the Field Group module. It is my understanding, that we're looking to add this functionality, but do not plan to move the existing Field Group module directly into core. However, I think the goal is to try to reproduce the functionality as much as possible.
  3. @BWPanda puts forward this specific suggestion for UI in this comment: https://github.com/backdrop/backdrop-issues/issues/647#issuecomment-674474016.

Screen Shot 2020-08-16 at 13 32 58-fullpage

  1. I'm reading interest in a "clone" function - possibly in the operations button.
  2. @klonos made some suggestions that might be best treated as follow-up issues.
  3. @philsward pointed out limitations of basic field group functionality when there are LOTS of fields involved. But, it's not clear to me that this was intended nor needs to slow this issue down?

NEXT STEPS:

In my opinion, this issue needs two things:

1) An advocate

AND/OR

2) Someone with the technical skills to create a first draft PR (to generate momentum).

QUESTIONS FOR DISCUSSION:

Would it be realistic to get this committed before feature freeze? Is anyone interested in taking some leadership on this issue?

philsward commented 3 years ago

To clarify my position re: @stpaultim

I don't think my concerns need to hinder any core inclusion.

Most use cases won't ever run into the bad UX of 30+ fields on an entity. Having a way to group is the first step to a better overall UX and eventually a better UI.

klonos commented 3 years ago

Thanks @stpaultim for taking the time to summarize this 🙏🏼

Someone with the technical skills to create a first draft PR (to generate momentum).

I definitely think that most if not all suggestions here can be follow-ups (we can add them to #779) - what we need is indeed something to start iterating on. Baby steps.

We already have a separate issue for moving the 'Add new/existing field' functionality to a new form via an action link: #4898. We can take discussions re that there.

Can someone please create follow-ups for:

stpaultim commented 3 years ago

@herbdool - I've noticed quite a bit of activity on Field Group module the last week and a new release. Does that impact this issue at all?

It was my understanding that the plan was to recreate Field Group functionality in core, not necessarily include the field group module in core. Has or should that plan change? Is it possible?

herbdool commented 3 years ago

@stpaultim not sure. Depends on how Field Group gets put into core.

I personally think it's best to make some of the UI improvements suggested above in the contrib module so they can be confirmed how they work. Such as change the operations to drop down on Form (though on Display the default is not a drop-down operations so it needs a different solution). Some of the ideas above need more thinking through so why not create a PR for contrib and see how it sticks.

I don't find Field Group difficult to use. Some of the types I haven't used before but I just tested them and found them straightfoward: vertical tabs, horizontal tabs, etc. I've used the cloning quite a bit: clone all field groups from form to display and vice-versa.

Trying to recreate Field Group is the most difficult path to take. Plus there's no good reason to do it in isolation. Even if the functionality is recreated, Field Group in contrib should end up using core's API and be redirected to provide the extras. Field Group right now has a robust enough hook system that that can be done.

If someone wants to step forward to work on this, I recommend first creating PRs for contrib to improve the UI there. And that can shifted to core later.

ericfoy commented 2 years ago

As pretty much a late-comer and very much an outsider to this discussion, I thought I might offer y'all my input as "a guy who's been using Drupal (and now a die-hard Backdrop enthusiast) for a couple decades (since D5)"... Sometimes a clear voice from outside can bring the detached objectivity that helps find clarity.

One thing I had to "figure out" along the way was that there's a distinction between the Field Definition UI and the Node Display UI — and that the Field Definition UI is apparently also the Edit Form UI at the same time; whereas the Node Display UI was something different.

From a historical standpoint, this makes perfect sense, since we were originally dealing with a primarily hard-coded data structure and fieldset (until the CCK came on the scene). In the beginning, the Edit Form was roughly analogous to the Display of every node. Then through theming, etc., the actual Display (the Presentation) could be altered. This was nice.

Now we have very clearly delineated and differentiated Display Modes, which is awesome. But the same "Presentation" differentiation has not developed on the Edit Form side of the equation. We are instead still (IMHO) plagued with the direct association of the data structure with the Edit Form Presentation. This, I believe, is what leads to discussions about whether the fieldgroup should be added inside the same UI steps as the field (to which I would mildly object, because they're not the same).

With the utmost respect to those who have actually done the work, and contributed to the development of this fine product, I offer my "outsider's opinion" on the issue (this is obviously a long-term discussion, and points to BD2 or beyond):

The UI that I envision at admin/structure/types/manage/[content-type] would have the Tabs:

Fieldgroups therefore clearly would belong not under the "Manage Fields" tab, but under the "Manage Forms" tab. Furthermore, it is quickly seen that the various widgets would no longer (necessarily) be owned by the fields themselves, but rather by the "Form Mode" as defined under the "Manage Forms" tab. Perhaps the widgets should still be defined for the "Default Form" via the Add Field dialogs as they now are, and then alternatively be overridden for any additional Form Modes under the Manage Forms tab. This would rightly include Fieldgroups.

I am especially addressing the clear difference between Field Groups and Field Collections/Multifield, which I am sure everyone already recognizes, but if I may, I will stress this point, which I have not heard explicitly expressed: "Field Groups" is a Presentation thing, whereas "Field Collections/Multifield" are a data structure thing. And it is for this reason that I would humbly object to the further entrenchment of the melding of these two functions.

Realizing that this idea represents a significant departure from how it's always been done, and that a lot of significant recoding would be required, I nonetheless offer the following "really cool" results that might follow:

Being an outsider, It's really easy for me to just MAKE THIS STUFF UP, like it's no big deal, right? Nonetheless, being a bit of an OCD data and presentation idealist, I felt the need to put these ideas forth for your consideration. Put them on the back burner if you will.

Sincerely, —Eric

P.S: My background: (edit:—moved to my bio)

MrHaroldA commented 2 years ago

Fieldgroups therefore clearly would belong not under the "Manage Fields" tab, but under the "Manage Forms" tab.

I'd say they should be on the "Manage Displays" tab as well ...

bugfolder commented 2 years ago

I very much agree with ^^^. (It took me an embarassingly long time in Drupal to discover that rearranging the data structure was also rearranging the edit form.) And the ability to create multiple versions of the edit form would be GREAT. I've got a use case now where ordinary people edit a subset of node fields on a bespoke edit form, while admin users can access more of the fields on a different edit form; being able to set up something like that from the UI (rather than hacking it in code, as now) would be great.

laryn commented 2 years ago

These issues may be related (at least tangentially):

stpaultim commented 2 years ago

We talked about this a bit in the dev meeting yesterday - https://youtu.be/KLihQQK7f-M?t=1355 (links directly to conversation).

There was some discussion about whether or not this might be possible for next release. My sense is that we don't have enough consensus of which direction this is going for anything to happen quickly. There were some hints that folks are skeptical of putting the field group module directly into core, for these reasons:

1) It doesn't seem like the kind of functionality that you need to or want to turn off or disable. 2) It might be better to include this functionality in a general reworking of the field ui.

I don't know that anyone was firmly behind or against any particular approach yet, which is another reason that it might be a while before we are ready to tackle this. I believe that for this issue to progress, we need an advocate for this issue with a better understanding of the technical implications, a willingness to push a specific solution, and the ability to work on a PR. I'm not that person.

herbdool commented 2 years ago

@ericfoy sounds like how Drupal 8/9 divides the functionality. Or is because of the experimental module for form layout in Drupal. I can't recall but that's what comes to mind.

herbdool commented 2 years ago

@stpaultim the reworking of the UI might be good idea, though I wonder if there's an MVP that could be done in stages.

Field Group wouldn't need to be a separate module but could still copy code out of the module much like was done with Token. However, it would still need to be a way to transition from the contrib module and also have plugins for expanding the group types. So those not included in core can still be used.

jenlampton commented 2 years ago

I'd like to advocate for this issue in Backdrop 1.23.0.

jenlampton commented 2 years ago

Okay, I've posted a first draft PR that accomplishes a few of the recommended changes for field group, there's plenty of room for more improvement, but I think this is a good start!

laryn commented 2 years ago

@jenlampton Did I understand correctly that you addressed all of @herbdool feedback in the PR? If so let's remove "Needs work" here so it's clear it just needs testing.

herbdool commented 2 years ago

I don't think it's there yet. There's leftovers from the previous way of configuring and I don't think it's quite working yet.

I also wonder if it might be easier to merge in this module if we first make some of the changes in the contrib module and then merge. As with entityreference it is a big thing to review. Separating out merging the contrib module from improvements required before it can be merged would make it much easier. I think converting the links to dropbuttons, and adding a clone option to the dropbuttons could be done in contrib first. (And leave other changes, such as removing the fieldset at the bottom, to core.)

Update: like this https://github.com/backdrop-contrib/field_group/pull/31 (Note that this PR also needs some tweaking but it works well enough.)

herbdool commented 2 years ago

Pretty clear this won't be ready in time for 1.23.0 so bumping.

jenlampton commented 2 years ago

I also wonder if it might be easier to merge in this module if we first make some of the changes in the contrib module and then merge.

We'd need to remove the "clone" feature from the contrib module in order to do that (which, I expect might upset some people).

That said, I'd be happy to re-purpose some of this PR to apply it directly to the contrib module first if that's valuable.

Update: it looks like you beat me to it @herbdool :) I'll go have a look at your PR.

herbdool commented 2 years ago

We can remove that one bit in the pr to core and leave it in contrib. Though eventually if it's included in core and force people to disable it in contrib then it won't make any difference.

My pr already copied your PR plus made a few more fixes.

There's still some funny UI stuff that needs to be fixed.

stpaultim commented 2 years ago

@herbdool - It's my understanding that this issue has an advocate and is therefor automatically eligible for the next minor milestone. @jenlampton are you still advocating for this issue? https://docs.backdropcms.org/documentation/adding-milestones-to-issues

stpaultim commented 1 year ago

There was discussion during the last DEV meeting about seeing if we can make progress on this. This could be the highlight of the next minor release. If I understood correctly, it primarily needs a little testing and review. Anyone?

olafgrabienski commented 1 year ago

If I understood correctly, it primarily needs a little testing and review. Anyone?

I'd love to test the PR, but don't know what exactly to look at. @jenlampton and/or @herbdool can you give a summary of the current state and indications for testing? The Tugboat sandbox is expired, btw.