 Bart Dabek
Post count: 24
|
Hi there, in order for your plugin to be compatible with as many others as possible (which is should at this level) how were you planning on handling support with other plugins who new WP Query to search for tagged content?
For example we have a post which was tagged with a couple checkmarks… ie
feature.feature in postmeta = json:[“Feature Homepage”,”Feature Learning Center”]
in using WP Query how would you filter posts that are tagged with just Feature Homepage?
Since you’re not storing each field separately… what’s the recommended approach for this?
Thanks
|
|
Bart Dabek
Post count: 24
|
I’m reading more about your API and things are looking good, however I find that storing of the metadata in json format is still quite an issue… it will introduce problems when trying to use other plugins based on your framework…
would be nice to have an option for fields to be split up into separate rows so we can use the normal WP Query to look them up…
saying all that how would I only retrive specific post types if they have a checkbox field checked? I really hope we’re not supposed to be looping over a huge array of data and check each row for that value…
cars(“orderby=post_date&order=desc&posts_per_page=5”) as $car) : ?>
link ?>
how would I make the above example query only data that has a checkbox value assigned?
Thanks
|
|
Bart Dabek
Post count: 24
|
The above example didn’t paste properly it’s
example 5 from https://www.masterpressplugin.com/docs/developer/recipes/multiple-post-queries
|
 traversal
Post count: 207
|
Hey Bart.
There are big challenges around storing the data as flattened for those particular fields, largely because it becomes very difficult to query them to build the field set structures for the API. MasterPress uses JUST the post meta table when storing data against posts, and it’s already quite a task to work out the correct structure for field sets that allow multiple items – it’s already tricky to understand where the boundaries between field set items are when the data is flattened out. If we were to store multi-item fields like that as flat data too, it makes that problem even more difficult to solve (perhaps impossible using only a postmeta table).
There are ways to run MySQL queries on that kind of JSON data – they’re not particularly easy but it can be done.
Suppose you were looking for posts with the checkbox value “Feature Homepage”. Then you could use something like this:
http://pastebin.com/wExPk3Zn
Also, just to clarify, are you using a checkbox list field type to store those values?
If you do need to run queries on the posts that are checked that way, you would be better off creating a custom taxonomy, and linking your posts to terms within that taxonomy. The intention with a checkbox list field type like that was really more for inspecting those values as you’re looping over a set of posts, as you’ve mentioned.
Sorry about this, I understand the need, but I do feel that custom taxonomies are a better fit if you’re trying to run queries, as those get stored in such a way that queries are easily supported. And it’s unfortunately not trivial to modify the way multiple value fields are stored, as this could very easily break so many other things.
I will make note of this use-case though – there is some potential to add a friendly wrapper around querying for specific values inside multi-value JSON strings.
|
|
Bart Dabek
Post count: 24
|
I hear you, and after thinking about this some more it makes sense… I guess I just came from the world where every other plugin I’ve used allowed for this… it’s a different way of thinking when designing the architecture but once you accept it, it’s not a problem.
|
|
traversal
Post count: 207
|
Yeah, while post meta can be used in that way, any type of categorisation that you potentially need to query is really better off as a taxonomy. And one of the neat things about MasterPress is that you can create new taxonomies pretty easily.
As I mentioned though, I do like the idea of a more friendly way to run a query like this too. Storing them as JSON is actually not too bad as at least there are definitive delimiters on strings that you can take advantage of when building a meta query.
Thanks for the tough questions 🙂
|
.