Field Groups (meta-only) separate from Pods themselves (ACF / CFS style)

[JoryHogeveen]

Hi, I wanted to check something :)

The current Pods 3.0 version has Field Groups. but currently, these groups are still linked to one pod/posttype.
Will it be possible in the first 3.0 release to manage these groups separately from pods/posttypes and assign them to multiple pods/posttypes?
It's the same as custom fields plugins like ACF and Types.

Please let me know!

Also, when will the first 3.0 release be ready?

[quasel]

well not sure if i get your question right but for my point of view this can be done wit the current release too - just add a realtion to a pod containing your fields .... just needs some UI love ^^
currently there is work on implementing CMB2 - first pass

http://f.cl.ly/items/1D1A2C0o280y100g1u0D/discog-nested-01.png

[JoryHogeveen]

@quasel Thanks for the reply, but this is not what I mean.
What I ment is the ability to add a group of fields to multiple posts (depending on post-type, taxonomy, etc.)

Correct me of I'm wrong but at this point, fields (and even field groups in 3.0) are added within a Pod, not separately.

[quasel]

well all a question of a point of view -> xy http://meta.stackoverflow.com/questions/66377/what-is-the-xy-problem

Becaus a group of fields can be stored as a diffrent pod - add a relation - and you can add it to any other pod e.g. think of an pod that stores an Address ( Street, City, .. ) you can then add a relation to pod of address to another pod e.g supplier, user, ... for me it's like database normalization i think of each pod as a sepearat table ....

because that what i think you expect doesn't exists - if i get it right you just want a "configuration" Template that can be added to diffrent pods but stored with the Pod ...

[JoryHogeveen]

@quasel
As of the xy thing, correct, I saw a solution that would work for me. So let me give the actual problem.

What I would like to do is actually two things.

• Keep editing posts as simple as possible for my clients
• Keep maintenance as quick and easy as possible for me

For example, I've extended the post type "Page" with some fields to create a image slider on that page, but I want this to be available on 4 other post types aswell.
At this point I will need to add the same fields to each post type manually. Also, when a setting changes, I'll need to change this on each post type again.

I don't want to create a new Pod just for the gallery and link it with relationship fields because the maintenance will be killing on larges websites. NextGen and MetaSlider do something similar and I don't realy like it (and my clients dislike it even more).
I want these fields to edited directly in the post-edit page and stored in in the post-meta table.

Your solution would work perfectly on fieldgroup data that will be re-used (like venues on events). But in this case each post has its own metadata entries and I would like to manage this within the post, not on an other post with a relationship.

Again, this can be achieved by adding the fields for each Pod, but when you have a network with 50+ sites, all with the same fields but on different post types, and you want to change an option to (for example) the "gallery view options"... you get the point I guess.

Also, I'm not demanding anything, I realy like Pods :-)!
I was just checking if this is on the table or not. (Or maybe even possible without me knowing)

[quasel]

Currently i'am not aware of an solution for you - but once 3.0 hits the road you will be able to edit or add related "pods" (or repeating fiedls stored as serialized data) in place ( at least this is the plan ) which would lead to seperated CPT/POD but the editing can happen within the "main" Page/Post - and this i guess is the best of both world's - your user's can edit their stuff in on place but you can additonally see a list of e.g. all sliders and reuse them or just keep adding new ones :P.

I really hope we get the UI right for this stuff becaus i think this will be a really awesome feature !!!

[quasel]

related to #109

[jimtrue]

ACF sounds like it handles what you're looking for. To me, it seems more work to do it the way you're referencing, but then it doesn't appear you're contextually linking your field groups with anything else.

Personally, I would define the 'gallery' or 'slider' pods they way you want them to be and then just Extend Posts or Pages to have a relationship to that 'slider group' or 'gallery group'. Keep the configuration (the actual database configuration) within Pods on the back-end and the only thing you're giving the user is the configuration ability to add those related galleries and sliders to the pages and posts. They're still within Posts Meta and you can still get to them by going to the Galleries and Sliders Pods (ie, seeing the full list and their related pages and posts), but you've got a cleaner configuration.

If you subsequently need to add a field to Galleries or Sliders, you add it to the base Pod and (if it's a field the end user needs to configure), you add it to the field group with Extended Pages or Posts. Two changes. Not a load of work there.

[JoryHogeveen]

Allright, ACF will be the solution for now. The situation you are scetching would be good awell I think, probably even more flexibility. Though I do wonder what this will do to the number of database calls..

[pglewis]

Not seeing an issue here, unless there was a feature request to be extracted.

[JoryHogeveen]

Err, okay, this was indeed a feature/sollution request. But it's clear to me that this will not be implemented the way I had in mind (like ACF and other metabox plugins).
For me it's an issue but I think this will not be resolved anytime soon within Pods.

[sc0ttkclark]

I still see this as a feature request, and I still see this being possible once we implement the groups interface. Groups are their own objects, and can theoretically be setup to appear underneath multiple post types / taxonomies / etc, as long as they are restricted to meta only. They will also require the wp_podsrel migration to keys instead of pod/field IDs to function in a feasible way for relationship fields.