Field Groups / Metabox Manager

[sc0ttkclark]

Context: Metaboxes are the boxes you can drag around on the Post Editor screen. They are seen in other areas of WordPress, and for objects that don't yet have that treatment, Pods will give them text headings (Users, Taxonomies).

Matt came up with this as an idea on what we can do for managing meta boxes and forms (sort of a merge of the two, but maybe the workflow can be improved.

Putting this here for internal review by @pods-framework/contributors

[sc0ttkclark]

To understand where we're at here, I think it will be good to put down my thoughts on what I initially thought meta box management would be:

• "Metaboxes" link added to Pods Admin > Setup list of Pods, next to the Edit / Delete actions
• List of metaboxes for that pod are shown on the next screen, or they are taken directly to add new (if none are set yet)
• Add/Edit form includes:
  • Metabox title
  • Drag/drop/reorder fields from the Pod to appear
  • Define conditional rules whether metabox should be shown (based on other field values, taxonomies, post formats, etc)
• Interface would mimik the Pod manager for the list of metaboxes, and the Add / Edit Pod screens for the forms / layout

Based on the direction of where @logikal16 is going, he's hitting this from the other side where not only are they able to create metaboxes, but they would also manage forms within the same interface. They use 'dividers' to separate multiple metaboxes, or choose how the fields are divided. This would also open up the pathway to multi-page forms, but I'm adamant that we try to sway away from being a full-on form processor and try to rely on integrations with existing form plugins to cover that.

Based on the wireframes @logikal16 sent, I have a few notes, but for now they aren't decisions or criticisms, just thoughts that come to mind after reviewing it.

• Step 1 lets you select the Pod, but maybe the user should also select the form type there
• Step 2 has a section for form fields, but it only includes divider, do we need that as a section? or do we merely 'Add Divider' button separate from the drag/drop interface (where they could then drag/drop the divider wherever it needs to be)
• Step 3 has some more form settings, but the workflow feels like maybe combining admin / front-facing forms could be confusing for users

[sc0ttkclark]

Depending on where this goes, it could also become a premium component, though I'd want metaboxes to at least be free.

[sc0ttkclark]

Any thoughts on this?

[sc0ttkclark]

@nienstudios is going to have a go at this too, maybe Robert can help provide some more insight on his ideas.

[sc0ttkclark]

Tabify Edit Screen has a grouping UI that looks nice, but made me get to thinking about how we could implement something similar for Pods fields. http://wordpress.org/extend/plugins/tabify-edit-screen/

Here's Tabify's editor where you setup your tabs, you drag metaboxes into tab groups, you can remove the groups and they combine with whatever group remains etc, and add new groups, edit the group name etc

I was thinking that this same treatment could be added to the Pods field editor

It would just be a matter of letting you create new table groups of fields, labeling it, and being able to edit the group's settings (either collapsable settings, or modal).

It won't look the same as Tabify, but it would make grouping fields pretty easy. Groups would translate into headings in form() on the front of the site, and metaboxes in the various admin areas.

This could either be part of the current Field editor screen, or a separate screen. I was just thinking that having it on the main field editor screen would be more natural and less bulky since when you have a lot of fields it can get tougher to administrate, and the separate metabox edit screens loses the flow of data structure that Pods focuses on.

[Pezzab]

Would this work for integrating wp content into the form work flow on custom post types too?

Sort of how I describe it here:

https://github.com/pods-framework/pods/issues/989

[sc0ttkclark]

No, this is separate, that's more of a restriction in WordPress itself, nothing can be dragged above the content editor in WordPress. Plugins can add stuff above it sure, but the draggable area doesn't extend there and would require a bit of extra JS that is bound to break every WP release.

[sc0ttkclark]

Related chat about this w/ Ben Favre, provides a little more insight on what I was saying:

[DavidCramer]

So if I understand correctly, this is an update to the edit/create pod UI and workflow?

[sc0ttkclark]

As of my most recent proposal, yes.

[DavidCramer]

Ok, great then I'm on the same page.

It's interesting that you are mentioning this now because while I have been learning the ins and outs of pods, I have found the current workflow of building a pod a little too segmented.

I fully agree with you on staying away from being a form processor, however there needs to be more flexibility in that area.

What are your reasons for wanting to rework the UI?

[sc0ttkclark]

We need grouping added to our UI for fields, it's planned either way, but exactly where it goes / how it works is the main question here. Do we enhance the field editor to include the grouping there, or do we send the user off to another screen to manage the groups and force them to only be able to edit either the groups themselves, or the fields.

[DavidCramer]

I say we work around keeping the group management on the same screen. There is already a lot of segmentation, keeping things within the same management screen will smooth out the workflow.

[sc0ttkclark]

Must've misunderstood what you just sent, did you say you were in favor of the group management being on the same field editor screen, and that it would smooth out the workflow?

[DavidCramer]

yes. having it on the same screen makes all settings configurable within the same area. No jumping back and forth.

[Pezzab]

This all makes sense to me and would be a great feature. Cheers for clearing up my query regarding the content editor for me.

[sc0ttkclark]

[sc0ttkclark]

Just posted an idea I came up with via Chrome Inspector, not fully styled etc, but just shows the concept I'm thinking of doing. It's poetic (code is poetry) that the groups themselves are metaboxes.

[smokeyfro]

Hey @sc0ttkclark, I agree with @Desertsnowman regarding keeping the grouping on the same field editor :) I do link the simplicity of the field grouping layout idea you posted. Just to confirm though - that is the field editor, right? I only ask because I don't see the field selection box.

[sc0ttkclark]

What field selection box are you referring to? The last screen I sent was a browser inspector based mockup that was changed from the current field editor as is. I modified the DOM to place the field table into the metabox based grouping and changed the buttons/links around a little. The intention is for this to be the new field editor screen, with grouping added to the UI so it improves organization and workflow when dealing with the new grouping feature. People add a lot of fields and this can improve a number of things on the technical and UX side.

[smokeyfro]

My bad, I was getting mixed up with Gravity forms, where the fields selection box is on the right. Makes more sense now. Gets my vote!

[sc0ttkclark]

Don't think there's enough time to rework the field manager for Pods 2.3, pushing to 2.4

[chidev]

So creating an admin screen would kind of be like making a layout with Headway (drag/drop theme editor), where you define the layout (2col, 3col), drag your containers (meta boxes) into your layout, than add fields, drag/drop and organize them into the meta boxes you've organized.

This, I like...

I also think tighter integration and better user experience would come through being able to define a field that's related to another field as being inline editable, as that's happening more and more these days.

So, for example I have 3 meta boxes in my left main column, and 2 in the right (like default WP style). The right columns first widget is the publish settings for my pod, and below it I have a rel to another custom content type with the only required field being 'name'.

I like that all this is on one screen, it makes a lot of sense.

In my crystal ball I can see a few tabs on the pod create/edit screen for backend layout, front end templates, url settings, etc... I have a lot of ideas for code generation and dev tooling that hook into Pods, if only I had the time or more skills.

I am +1 for keeping this all on the same screen, and following that direction of inline/all-in-one editing. Check out the Headway theme editor, I see Pods going into something like that but I hope it stays much more minimal and focused (Headway is kind of nuts but powerful and annoying at the same time).

[tomherold]

Well, there is not that much missing to have complete settings pages with different sections and headings. I am looking forward to see this feature in pods 2.4. Right now I am using a separate plugin (KC Settings) which does a great job create complete settings pages. See screen-shot below.

[AndyGalaxy]

Scott - that "Add Group" on the field editor screen is perfect! How far away is this? Love your work dude.

[sc0ttkclark]

I'll likely be implementing this when implementing Loop fields from #109, so as scheduled that's the next major Pods release 2.4

[sc0ttkclark]

Posting an update for this, there are a few things I want to be sure this accomplishes so as to fix quite a few issues there are with the current field management process. It breaks down when there are a ton of fields, and once we add grouping, things will only get worse for those users and the amount of form data may hit the limit again (we've hit the limit in PHP for most form fields submitted before).

• Separate Field Group management from Fields
• Separate form for Field Group edit
  • Tabs: Manage Fields | Visibility Settings | Back to Edit Pod
  • Manage Fields editor would be like it is now, but revamped for further performance improvements
  • Visibility rules cover #773 and more

Screenshot of what I was feeling for the field group management, simply just looks like the field editor rows but clicking edit will take you to the other editor for that field group.

[sc0ttkclark]

Moving forward with metabox manager in Pods 2.4, but new direction for the 'fields' editor, which will utilize the Loop Field UI from #109 for the field rows / edit forms. For Loop Field types, a "Sub fields" loop field UI will be shown to add additional fields into them.

[mattbanks]

Great to hear this is still on schedule for 2.4! Is the conditional display still targeted for this release (ie field groups for certain pages only, similar to how CFS works)?

[sc0ttkclark]

Per metabox, yes.

[mattbanks]

Awesome! Starting a new big site now that's launching end of October and want to use the new 2.4 loop fields and metabox manager for all of it :)

[Shelob9]

It would be great if as part of the creation of the metabox manager additional fields added to user profiles could be grouped into various metaboxes with different titles. For example, I could add fields called "Twitter," "Facebook," and "LinkedIn" and put them in one box called "Social" and create some other fields called "Phone Number (mobile)" and "Phone Number (work)" and put them in a metabox called "Phone Numbers." Right now all new fields added to users show up at the bottom of the user profile page under the "More Fields:" heading.

[sc0ttkclark]

That's part of the genesis of this ticket, metaboxes are actually field groups in our API. Our API already supports multiple groups, it's just we haven't exposed this in our Admin UI yet. Field Groups are available for Post Types, Taxonomies, Media, Users, and Comments. We're building grouping into Advanced Content Types as part of this ticket as well. Groups appear as native UI for the form they are in, so in the Post Editor it's a metabox, but in the Taxonomy and User forms, they appear as headings.

[sc0ttkclark]

As of https://github.com/pods-framework/pods/commit/08a421944e1af2f27474240013fd9faa2841b414, this should now be functional. The only thing left is implementing the metabox visibility rules from #773, the options are in place, they just need to be validated against during groups setup in PodsMeta.

[manishie]

Hey Scott, is grouping now supposed to work for Advanced Content Types? Maybe I'm doing something wrong, but it doesn't seem to be working for me. Thanks.

[sc0ttkclark]

This is for Pods 3.0 which is still in progress.

[manishie]

Ok, thanks.

[GitHubGreg]

I need to put custom meta boxes inside a Custom Post Type edit screen. I am trying to use pods_group_add as per http://pods.io/docs/code/general-functions/pods-group-add/

So far no luck. Will this be part of the things only available in 3.0?

[sc0ttkclark]

Also requires PodsObject()

[DOBss]

+1

[sc0ttkclark]

Closing this as complete now that we just hit feature complete. The only caveat is that we can't support more field types and that will get covered by the DFV React work.