Advanced search: category selection

Hello Stiofan,

Thank you for the fix, it does indeed fix the category search issue and actually solves another problem we’ve found digging that code ( if the search text was empty it would force a search WHERE post_title LIKE “” which actually may break the result set).

Sorry to be a pain but there’s something else we’ve found, with the code you provided (and even the old one) line 783~ of the code in wp-content/plugins/geodirectory/geodirectory-functions/listing_filters.php states:

function searching_filter_where( $where ) {
    [...]
    $where               = '';
    [...]
}

This actually negates all the possibile other where that any 3rd party plugin might inject in the query. I don’t really know if this was the desired results but it’s actually a little annoying. Ofc we could inject stuff with higher priority then your code but it’s not always a practical solution.

Could you fix that too someway? I noticed that doing so you actually clean some “garbage” which comes from the default search, but on the other hand you may destroy something an user might actually want to keep

Let me explain our case which we may be doing it wrong:

In the project we’re working on with GD we need to add a special tax query part during the GD search query. Now what we have is this:

add_action('pre_get_posts', 'geodir_listing_loop_filter', 1);

which later adds:

add_filter( 'posts_where', 'searching_filter_where', 1 );

which as we said clears the $where part of the query.

Now, since the part we have to add is actually a tax query part which get parsed inside WP_Query->parse_query line ~840 we added an hook to pre_get_posts in order to feed the query with the needed tax query part (i could do it in other ways too but still it would happen before the next things i guess).

Now going down the code the ->parse_query method starts firing the ‘posts_where’ filters, the bad starts here since WP actually has inside the $where the already parsed tax_query part, which the code inside ‘searching_filter_where’ actually clean and delete 🙁

Is this a bad case we just caused ourself?

Sure why not, we’re still thinking what’s the best way to achieve this using GD but what we need is to do:

Customer request:
Make categories linked to tags, so that picking up a category would search the linked tags. This should be valid in add listing + search

Consideration:
We are aware that WP doesn’t make categories and cat linked by default so we need a way to do that. We opted for making a custom tag field in add listing + search because your existing post_tag field doesn’t suite our needs

Possible solution we came up with:
1) Build a custom DB table that link cats and tags (2 cols table, id_cat,id_tag) and create the desired link. We manage the data in there by a custom wp_admin page, no issue with that, pretty straightforward
2) Hide the default GD tags field in add listing and sostitute it with a custom made which is a select that get populated in AJAX reading from point 1) table. We can’t let the user picks random tags (which then fill the db with unwanted data)
3) Make sure that when saving a new listing all the data gets correctly filled (your field in wp_geodir_gd_place_detail.post_tags + taxonomy association)
4) Add a custom field (by code) to your search widget which has the same behaviour as the select in the add listing page (so filled in ajax when selecting a category)

From now on we get to the point stated above, picking up a category + [x] number of tags would perform a query on gd_place_tags taxonomy. This is where we need to feed the global $wp_query with our custom tax query reading the custom field

Hope it’s clear 🙂

SIDENOTE: testing this out we noticed an issue with tags association in backend compared to the data in the DB, do you prefer us to open a new forum post about this issue?

It’s a kinda weird customer, let’s say we are still in stage but we fear a deadline to appear all of a sudden. Anyways going on with what we told u in the prev post we keep developing.

I guess we actually managed to achieve what we need and inject the query parts we need. You actually answered our question as well so if you want to mark this as closed feel free.

Thank you for your patience & time