Groups in the various admin / frontend forms

[jimtrue]

Discussion of handling for Forms for new 2.8+

Things to figure out / confirm we agree on

• [x] Determine Default group title for WP objects that have other fields. Previous default: "More Fields" (ex: Post Types, Taxonomies, Users, Media, Comments)
• [x] Determine Default group title for Advanced Content Types that have no other fields. Previous default: "Fields"
• [ ] Determine Default group title for Settings Pages that have no other fields. Previously not shown as a heading
• [ ] For objects with no other fields, if there's only one group, should the group title be shown at all (for frontend forms)?
• [x] Frontend forms: Backwards compatibility - if fields is set, only return those fields and not grouped
• [x] Frontend forms: If fields are not set, return all groups (with group titles) and their fields
• [ ] Frontend forms: Figure out how to send groups + fields into shortcode/widget/block/Pods::form(), should there be a group parameter? Should it take just group names? Should it take some sort of advanced / complicated format like my_group_one=field1,field2&my_group_two=field3,field4?

Items for stability / use-case coverage

• [ ] Test and support all WP object fields in frontend forms
• [ ] Test and support all Post type "associated taxonomies" in frontend forms

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label Type: Enhancement to this issue, with a confidence of 0.96. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[sc0ttkclark]

Possible default first group titles for object types that have no other fields (Settings Pages, Advanced Content Types):

• Details
• Information
• {pod singular label} Details
• {pod singular label} Information
• Fields (this is used by Advanced Content Types right now)
• General
• Untitled Group (if we detect a group with this title, we would not show the title at all)

[sc0ttkclark]

@JoryHogeveen @jimtrue @nicdford @quasel when you are able to chime in here, can you note what you agree/disagree with from the "Things to figure out / confirm we agree on" list and expand on any better approaches you can think of if you disagree?

[quasel]

Frontend Forms: as discussed make field and group names unique, then it's just a list of names name=your_field, your_group,… and a parameter like "grouped" and make grouped=true the default seems like the easiest approach? just an idea… 

Regarding "object fields" I would love to see them at the same level as just another field to be moved around… this way thew admin could be fully controlled by pods and we could make their "name" readonly but visible while editing and add this might add the option to set default values for them (hello post_title :D )

For a consistent UI/UX I would always display groups including a header because that's what we do currently anyway… a settings page has a header with the title "Fields" and ACT/CPT uses "More Fields" and Tax has nothing currently…

[nicdford]

• Fields (this is used by Advanced Content Types right now)

I would lean towards this for the group name.

For objects with no other fields, if there's only one group, should the group title be shown at all?

I wouldn't change the UI for one or many groups. This way it's always easy to add groups later without having to relearn the UI.

[JoryHogeveen]

I'd keep the default group titles unchanged for 2.8.

For new groups/Pods I'd say just use Fields like @nicdford proposed.

Determine Default group title for Settings Pages that have no other fields. Previously not shown as a heading

Proposal:

• Add Group setting to show/hide group title.
• Add Group setting to show as a metabox or just plain fields.

By default, always show the title the same as default WordPress setting pages.

For objects with no other fields, if there's only one group, should the group title be shown at all?

@nicdford I wouldn't change the UI for one or many groups. This way it's always easy to add groups later without having to relearn the UI.

Totally agree with this.

Frontend forms: Backwards compatibility - if fields is set, only return those fields and not grouped

Agreed. Current usages of PodsForm should change as minimal as possible.

Frontend forms: If fields are not set, return all groups (with group titles) and their fields

Agreed! I am thinking about omitting the default "More fields" title though (if there is only one group), this is currently also not being shown in PodsForm.

Frontend forms: Figure out how to send groups + fields into shortcode/widget/block/Pods::form(), should there be a group parameter? Should it take just group names? Should it take some sort of advanced / complicated format like my_group_one=field1,field2&my_group_two=field3,field4?

@quasel Frontend Forms: as discussed make field and group names unique, then it's just a list of names name=your_field, your_group,… and a parameter like "grouped" and make grouped=true the default seems like the easiest approach? just an idea…

IMO Frontend forms should be as dynamic as possible. There are also users that use the PHP API and pass full arrays of fields with their options into PodsForm. I also think this should accept JSON, serialized and any format that can be parsed by wp_parse_args() (uses parse_str).

I'm not sure a group parameter would be an advantage over a formatted string. Can somebody elaborate with usage examples? I do however like the idea of a grouped parameter like @quasel proposed.

[sc0ttkclark]

Punting this for further work in a future release. More to figure out and nail down.