Hi Michael
I’ve now spent a considerable amount of time on this and actually getting nowhere – in all my test setups, different themes/plugin configurations I cannot replicate your issue.
I would likely say that the problem lies in this listing plugin you have…. However saying that, I had a look at the sample query generated that you pasted in an earlier post – and I cannot fathom how that could possibly produce duplicate posts – there is an inner join on the table – with it being an inner join (and the only join in this query), this means you do not get duplicates.
I have a few notes/suggestions as I’ve noticed some other things which may or may not cause you problems…
1) you are using a customised version of the template – in there I see a couple of queries which may interfere with the main loop (I doubt it but looking at everything here) – I would suggest removing or renaming the templates within your themes and letting S&F use its default one just to make sure.
2) Searching meta data can be inherently problematic.
From what I can tell, your _content_field_6 is multiple choice (in the admin) – so users can select multiple options for this field
Option 1 Value 1 => 1
Option 1 Value 2 => 2
Option 1 Value 3 => 3
Option 1 Value 4 => 4
Option 1 Value 5 => 5
The problem here is, these options, internally, (say a you chose the first three options) are stored as 1, 2, 3 etc…
Now, to have a single meta field, contain multiple values you must serialise the data
So if the first 3 options were ticked you would imagine it is stored something like:
_content_field_6 => 1,2,3
However when WP, or SQL in general is storing serialised data it is being stored like:
_content_field_6 => "a:3:{i:0;i:1;i:1;i:2;i:2;i:3;}"
Now, searching serialised data is nearly impossible – so all we can do is a wildcard search…
Now lets get on to the search form – if a user selects option “1” or “2” in the search form, then a LIKE comparison is performed, however a LIKE comparison against _content_field_6 for the number 1, will match almost any post that has serialised data in this field… So your results will be wildly inaccurate…
…I’m hoping the above makes sense so far…!
So.. if you want to get this to work, then saved values must be unique – instead of just numbers, so something like (purely as an example) would work…
Option 1 Value 1 => one
Option 1 Value 2 => two
Option 1 Value 3 => three
Option 1 Value 4 => four
Option 1 Value 5 => five
So if you as an admin, selected the first three options again against an ad, the serialised data would look like:
_content_field_6 => 'a:3:{i:0;s:3:"one";i:1;s:3:"two";i:2;s:5:"three";}'
And again if we take the example above, if someone was using the search form to look for the “option 1 value 1”, then a like comparison would be make against this field, but for a string “one” – which would then return this example ad and perform reasonably accurately!
So to summarise, serialised data is bad for searching (but it sometime data must be saved this way), however if your serialised data is an array of numbers, representation options like “Option 1 Value 2”, then its going to be nearly impossible to search this accurately. This is just the nature of searching serialised data (its basically impossible to do accurately and crude at best).
Hope that makes sense!!
