Silvia Frati
Forum Replies Created
-
Posts
-
Ok, thank you. We will look forward for the next release. You can close this 🙂
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
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 + searchConsideration:
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 needsPossible 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?
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?
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
I had the same problem with permalink but using standard WP menù pointing to GD category taxonomy. I really don’t understand the reason of doing that on permalinks (appending locations from previously visited places) since it gets pretty weird results and break some pages.
Anyways my solution was this:
remove_filter(‘term_link’, ‘geodir_get_term_link’);
Searching the code there’s one more hook that seems to be doing something with menù permalink, for me the first one was enought tho.
remove_filter( ‘term_link’, ‘geodir_cpt_term_link’, 9999);I don’t knkow yet if this brings any other problem behind but ATM everything looks working great. I have the nice SEO friendly URL when clicking on place detail and i have the normal-looking URL when clicking back on another category from the main menù
@alex sorry but i don’t understand what that would mean practically speaking.
@Dirk I’m not good with that concept of country – region – city, this is because what i would need is instead: country – region – GroupOfTown – city.
A multi-select for the city would be the “horrible” way to make it, because for example selecting 10 cities could be the same as select 1 GroupOfTown (which is obviously more user friendly).
The number of “GroupOfTown” is 110 based on what Wikipedia says of my country, the number of city instead is absurd, no way i could fit it all in a standard multi-select, it would take ages to load. Would require at least AJAX search.
What i was going to do if i cannot make it with GD directly is to hook into GD new gd_place listing form, add a custom select that reads from a custom DB table (GroupOfTowns), so that the user can first of all select one while inserting the new place, and then just search over this custom field in Advanced search giving again a select to the user to search for GroupOfTown
Hmmm… what do you mean with “subsite for each GroupOfLocations”?
@alex To make it short the functional difference is that searching ‘nearby’ would be like searching in a radius starting from the center, while searching the group would only take the group. Searching in a radius might give as result town of another group, which my customer does not want
@alex the search result page is completely fine for me. I just need to change the search form + query.
By default search form is:
------------------------------------------------------------ | category | |search term| |nearby| ------------------------------------------------------------I managed to hide nearby using some hooks since it’s no use for my customer and just confusing. I need to replace it with a <select> whose options are those “GroupsOfTown” i was speaking of. So:
------------------------------------------------------------ | category | |search term| |groupOfTown ↓| |group1| |group2| |group3| |more..| ------------------------------------------------------------Those “GroupOfTown” should be selectable when inserting a new “gd_place”
@alex:
Yes, i did try near search. The problem is that near search allows a radius search, but for my customer i need something slightly different. My final search should be like searching on a list of towns, but i can’t really place it there in this way, that’s why i need those “Groups”.Google Maps Javascript API (since i could test it on their website) was calling these entities, that I’m trying to obtain here, “Administrative Area”. Or at least it was so for my country.
I have some dummy data, and i can tell that indeed the near search isn’t good for my use-case
@alex What’s the database behind that? Simply using the string “OurGroupOfTown” (of using my real data) wouldn’t still present me the correct result because i have no way to map those “OurGroupOfTown”. That is why i was thinking of using a new CPT in the first place, to store the “OurGroupOfTown”.
Ofc my plan is NOT to edit the real GD core, but instead using its filter/action to hook something custom, editing core is my real last hope. Building it all from 0 would be a pain, and the customer (as always) stress 😀
@stiofan One last question: would it be possibile doing something with a brand new CPT created by GD and add that as a search parameter on the default “place” CPT advanced search form?
Thank you for the quick answers,
@stiofan: looking into the db i think it could be as simple as adding to $wpdb-prefix.’_geodir_gd_place_detail’ (Using the std “place” CPT) inside the post_locations column, one more [] value, ATM i have in order: [town],[region],[country] inside there. If only i could make GD add there a new value, say “OurGroupOfTown” i would only miss later to be able, using a <select> to pick up one of those values in the advanced search form.
I cannot use the NEAR function because it is not so accurate according to my customer request, additionally the NEAR functions starts from the GoogleMaps center of a given town/region and goes in a radius, my group of town can be distrubed in such a way that conflict with the radius thing
Should i give up hoping it could be done w/o hacking into the GD code?
