boxportable
Forum Replies Created
-
Posts
-
I take it no one including the developer can explain why the perfectly reasonable modification to the cores search function I made doesn’t work in practice but does in SQL workbench, starting to think you freelanced much of the plugins code out to others.
Seems fairly obvious you can’t answer basic questions about the search function in plugin you “apparently” wrote, seems I would of been far better off using my own custom post type with advanced custom fields to achieve what this over bloated plugin is doing, at least could of used WordPress’s own meta queries rather than the hotch potch way you have done the search code.
Thanks again for the practically useless but expected response Stiofan.
> I assume you are talking about the search bar widget GD > Search though
Well I modified the way that worked and I don’t think its a widget, you can see the website here: http://visitfraserburgh.com/places/ as its now gone live.
The drop down to the left of search shows a list of categories, to do this I used the following function from this thread: https://wpgeodirectory.com/support/topic/changing-post-type-dropdown-filter-to-categories-drop-down/
The search function which I mentioned in the first post in this thread is supposed to search on category, as I said in the first post I am trying to modify the search to search by category.
Testing my modified query in the likes of mysql workbench will bring back the correct results so I am curious as to why it doesn’t in wordpress.
Also I don’t understand you mentioning: sgd_placecategory as a GET var it doesn’t seem to do anything, I have used scat=’Category Slug’ as my get var and the modification in the first post of this thread to the search query will search based on this and will get post ID’s based on the terms.slug matching the term_taxamony_id.
I would not find it difficult to understand what I have explained already in this thread so I am unsure why you have asked me to “clearly” explain myself surely you must have wrote the search function and can see just by looking at what I have in the first post, what I am trying to do with it, I didn’t even write your search function and could see what the function was doing.
Anybody anything they can add to this while I wait on Stiofan to look?
Anyone any ideas on this while I wait for Stiofan?
Clients website is launching tomorrow so it would be nice to have some feedback on this within the next week or so if anyone else has any ideas about the issue.
Why is this marked as resolved though? I mean fair enough hes looking at it when he can but its not resolved as yet.
Also thanks for flagging this.
Also when logged this is whats returned from that function:
AND (t( wp_posts.post_title LIKE "%%" ) ntttttttOR ( wp_posts.post_content LIKE "%%") ntttttttOR ( wp_posts.ID IN(tntttttttttSELECT distinct(wp_term_relationships.object_id) as post_id n FROM wp_terms, wp_term_relationshipsn WHERE wp_term_relationships.term_taxonomy_id = (SELECT wp_terms.term_id FROM WHERE wp_terms.slug = "it-communication")n ) ntttttt) nttttt) nttttAND wp_posts.post_type in ('gd_place') nttttAND (wp_posts.post_status = 'publish') , referer: http://visitfraserburgh.com/?geodir_search=1&stype=gd_place&scat=it-communication&s=+&snear=&sgeo_lat=&sgeo_lon=Do the line breaks etc get stripped out before running? Don’t see why that would be an issue as the others are the same and work, just trying to find something that could be an issue.
Modified the start of that bit just now to select distinct because I don’t see the sense in selecting all as it adds a lot of ID’s to the array.
SELECT DISTINCT($wpdb->term_relationships.object_id) as post_id
Right I just double checked and the latest the bit in Admin_functions.php is actually commented out for the error I was getting so I must of had something like an auto sync of local files screwing everything up.
You can mark this topic as resolved it only took 3 hours or more of faffing 😀
sort of made progress on a fix for this but its odd because only some feilds are updating things like check boxes don’t seem to want to.
It seems that I needed to uncomment the bit in Admin_hooks_actions.php as follows:
// no need of this box as all fields moved to main informain box add_meta_box( 'geodir_post_addinfo', $post_typename. ' ' .__('Additional Information' , GEODIRECTORY_TEXTDOMAIN), 'geodir_post_addinfo_setting', $geodir_posttype,'normal', 'high' );It seems for some reason this is needed on mine not sure why though but its still not fully resolved my issue for all field types.
would edit but the link seems to have expired.
It doesn’t seem to be any conflict with plugins I just tested disabling them one by one.
the website was recently moved from a sub directory called /build/ but I don’t see why that would effect this :/
Can anyone tell me the function(s) used by the plugin which handle the saving of the geodirectory fields as this seems to be the actual issue rather than normal post fields like description.
EDIT:
Look like I got something, when logging the info of save post I got this in the log file which wasn’t appearing anywhere else:
<b>Notice</b>: Undefined index: geodir_post_addinfo_noncename in <b>/var/www/vhosts/visitfraserburgh.com/httpdocs/wp-content/plugins/geodirectory/geodirectory-admin/admin_functions.php</b> on line <b>922</b><br />
Ok disabled all the calling of that widget it made no difference to saving listings so it must be something else causing the issue.
EDIT: OK this seems to be specific to Geodirectory fields because I can update the description of a listing just none of the geodirectory fields.
Can anyone tell me what show_listing_widget_map() is supposed to do and why its called every page load and every time you update a listing?
The map within listings seems to function fine and display as normal so not sure why its always throwing these errors and why $list_map_json is always an empty variable.
Also that warning is still being thrown after setting it not to display warnings so not sure if its being overridden somewhere else now.
Didn’t fix the problem with updating listings, I also removed some recently added script were using to show hide fields depending on category and listing type (basic/enhanced) but that also made no difference so I guess I will do some more digging :S
Customizing the core plugin is a very bad idea. You will basically lock out yourself from getting any of the new things we are about to release.
Well aware of this but I needed some stuff changing with the core and having to request what hook did what each time or adding custom HTML fields in to the listing settings via a function someone provided didn’t work we wanted it to.
So we were left with no other option, and to be honest once this website is done we wont be updating geodirectory unless forced to.
Anyway I will remove those warnings but if it is just a warning I doubt its going to fix the issue were having, thanks though.
