Add ability to store fields as unserialized postmeta using their own meta keys for meta queries about wordpress-fieldmanager HOT 7 CLOSED

We discussed solving this using a dual approach:

1. Adding a key 'index' => true to a field, which will add a new post meta entry for the field. The field's data is still stored within and accessed through the group's serialized data; the index is used only for meta queries.
2. Adding a key 'use_individual_keys' => true to a group, which will set the fields within that group to solely use their own keys. Note that this approach will not work on every field type, and requires the developer to know what s/he is doing.

Considerations:

• Fieldmanager_Post stores a struct, not a single integer. Need to add an option to store a single integer.
• For the second approach, a few field types won't work here, and should throw an exception (specifically: sortable fields, repeating groups, posts not storing as integer)

from wordpress-fieldmanager.

For what it's worth, 'index' => 'indexname' is now supported. I have no problem supporting the second approach here, but probably won't build it myself.

Also, Fieldmanager_Post is about to be removed from Master.

from wordpress-fieldmanager.

I'd love the latter. Storing meta values coupled to their presentational structure doesn't make much sense, imo.

from wordpress-fieldmanager.

The latter could be added as an option, certainly. Now that Fieldmanager uses contexts (it did not at the time that this issue was opened) it would be much easier to implement an alternate storage pathway as a subclass of Fieldmanager_Context_Post, or maybe pass a flag to the context 'field_names_as_keys'.

Also, I think we could preserve total functionality and avoid crazy exception detection by only storing the root field names as separate keys. If any of the fields are groups, they get stored as arrays like normal, just up one level basically.

Come to think of it, it's probably pretty trivial to implement and test.

Although to your point about presentational vs logical structures, I think it really depends on the use case. Once you're dealing with repeatable fields, I think bulk storage makes much more sense. In the meantime, I would direct you to 'index' which will still be useful in both scenarios since it enables querying on any meta value, including those of repeatable fields. (Have I complained that postmeta allows dupe meta_keys but lacks an 'order' column before? No?)

from wordpress-fieldmanager.

I've enabled this in branch store-each-field-as-meta if you want to test.

from wordpress-fieldmanager.

Needs unit tests before PR/merge though

from wordpress-fieldmanager.

Thinking about a spec for the "store-each-field-as-meta" feature:

• Repeatable fields can be supported. To do this, we should delete_post_meta( $post_id, $this->fm->name ), then add_post_meta()
• With the above, I think we can support sortable fields as well. I don't know offhand that order is guaranteed, so we'll need to test that.
• We could hypothetically support group children. I see it being possible if we made the key representative of the hierarchy, concatenated by underscore or hyphen. This wouldn't work with children of repeatable groups, and I'm sure there will be other cases where it doesn't work, but it's worth exploring.

from wordpress-fieldmanager.