Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Support query by meta_query even if metadata is of Taxonomy type #236
Currently, when you query by items filtering by a metadata, you must know whether the metadata is of Taxonomy type or not. If it is a Taxonomy metadata, then you have to build a
This is something that adds a bit of work, but it is a good way to build a query.
To solve this, and to make life easier for those querying for items, the propose is to add a bit of intelligence to the Items Repository which will check to see if there is a
This turns out to be more complicated.
The transformation works, but in WP_Query, everytime you combine a
So if you make a search with multiple meta_queries, with
This raises some issues and ideas
Currenty, when you set up a Relationship metadata, you can choose which fields in the target collection you want to use to perform a search when editing an item and filling in the relation (let's call it "search metadata"). If you choose a Taxonomy metadata, this search is currently not working. (I will open an issue for this), because the component is performing a search using only
Even if we fix this, it would break the search because, if the user selects several metadata to search, the taxonomies would have an
To solve this we could:
Idea: modifier to WP_Query to change relation
We would have to investigate to find if this is doable, but we could add a modifier to the WP_Query arguments array to force the relation between
We could test it BUT we would have to do the same tweak in the Elastic Search integration.
Idea: Add support for LIKE operator to Tax_Query
It sounds like a good idea to add support to do a
This could be done as it is in this proof of concept here:
The advantage is that it would work fine with the elastic search integration. The disadvantage is this can create some problems for very large taxonomies...
This could also be done by filtering the SQL statement. The advantage is less use of memory (I'm not sure about how the query would perform). The disadvantage is that we would also have to tweak the elastic search integration in order to make it work.
Our decision was to limit the configuration of the Relationship metadata to restrict "search" metadata to non-taxonomy ones.
Also, we think that the kind of "magic" this issue propose can lead to a lot of confusion and decided not to implement it.
But, we do think that add support to the