Problem with AND logic using attachment custom taxonomy

[sgb02]

I am using a custom tag taxonomy for media attachments. I have also set the logic to use primary AND. When testing, I found this AND logic is not working to return the attachments that have both tag A and tag B.

I was able to confirm that the AND logic is working properly for post and page content.

Steps to reproduce:
+ search for Avis -4 results: including 1 page, 2 images returned
+ search for red – 4 results two images returned (including one of the above)
+ search for Avis red, – 1 result (page only), should also have 1 image

[Ernest Marcinko]

Hi!

The AND logic for taxonomy terms connected to post types means that ‘any of the taxonomy term names contain every search phrase’, as each taxonomy term is a separate object related to the post type.
In this case ‘Avis red’ would only match if there was a taxonomy term connected to the attachment that has both ‘Avis’ and ‘red’ in their title. To match either-or, I recommend rather using the ‘OR’ logic instead.

[sgb02]

Note in general users are searching for objects not metadata. Taxonomies are metadata about objecs such as post types. Search terms may be terms found in natural properties or metadata properties of objects. So basically you should treat taxonomy values as index terms on objects just like title, description or content, etc.

I would have thought the search process when using the index table is to find an object which is indexed by term1 AND term2 regardless of how the terms and index where sourced. In any scenario where metadata terms are used as source terms for object indexing ( e.g. tags) it is never going to be the case that one metadata terms has two values. The only possible way to use AND is to assume that term1 and term2 may both refer to the same object and the objective is to find which object(s) for which there is a term1 AND a term2 in the index table that refer to the same object.

If there was no metadata used, and you indexed the text of objects containing strings of text values (e.g. term3, term4), then a search for term3 AND term4 would return any objects where term3 AND term4 both refer to the same object. When metadata terms are used, it is a straight-forward concept to use AND in the same way. Effectively the metadata terms (e.g. tags or any other taxonomy) should act as if the metadata terms were actually contained by the object.

Suppose object1 contains text: “The happy fox”, and has metadata terms (e.g. tags): “brown”, “quick”. Indexing object1 text produces index terms “happy”,”fox”, and indexing the metadata produces additional index terms “brown”, “quick” for the same object. Thus a search for “happy” AND “fox” should produce the same result (object1) as a search for “quick” AND “brown” or “brown” and “happy”. All these should be terms in the same index table with references to the same object types.

In WordPress, the primary object types are post types (standard and custom post types). Additional object types could be comments and users. All of your sources would be simply data elements referencing obect types. So my expectation is that all terms including tags, categories, titles, descriptions, text content, dates, name, status, custom taxonomies, etc should be treated equally. Potentially your sources for post types could be derived from any column of the post, postmeta, terms, etc.

[Ernest Marcinko]

You are correct, and the index table does work this way, and is the main reason that it was created.

The issue is that the attachments search via the index table engine is not yet implemented, it is under construction though. Initially it was available, but some unexpected issues came up regarding attachments type results and we had to remove it and use the default engine instead.

Since it never came up as a request since then, the problem was marked low priority feature. I have bumped it up to a high priority issue, and will try to come up with a solution within the next 2 releases, if possible.

[sgb02]

Ok thanks. I hope this is fixed as soon as possible, as the AND search using tags is essential for my project. I found one other premium index tool that handles the AND correctly but does not have as nice UI. But better results are obviously important. So the sooner the better, please. How long do you think it will take to implement and release?

[Ernest Marcinko]

It depends on how complicated this eventually gets, I’m currently working on 4 more other bugfixes/changes as well, once those are okay, I move to this one. The next release deadline is tomorrow (+ the approval time by codecanyon, usually within 48 hours). The index table already is capable of indexing attachments as well as most of the attachment fields, so if nothing goes wrong, this will be a minor touchup only. There is a chance I will be able to get this done by the upcoming release.

[Author]

Posts