mflc

Further followup – debugging through the code I discovered /directorist/includes/classes/class-geo-query.php which I suspect is managing the query handling the radius search. A simple test of 35 miles around the zip code 45237 yields the following query (among, many, many others, but this is the only one that seems like it relates to geo data and may be related to the zip code):

wp_5_posts.ID, ( 3959 * acos( cos( radians(48.164960) ) * cos( radians( atbdp_geo_query_lat.meta_value ) ) * cos( radians( atbdp_geo_query_lng.meta_value ) – radians(21.988825) ) + sin( radians(48.164960) ) * sin( radians( atbdp_geo_query_lat.meta_value ) ) ) ) AS atbdp_geo_query_distance

(note the posts table is wp_5_posts, because this is a subsite of multisite wp install)

Note that the Lat/Long in the query is from somewhere in Hungary rather than in Ohio, USA (which is where my search zip code is located). My guess is that this is trying to take the search zip code and converting it to lat/long so it can be compared against other listings, but it is getting the wrong zip somehow? The other logical alternative is that the query is one of the listings it is trying to compare against, but that isn’t true since I have 100+ pages of listings but only one this query appears to use lat/long data.

I double checked – and the lat/long for hungary is what shows up in the hidden fields associated to the zip/radius search control. I also noticed that as I type the zipcode in, a menu appears to select from – apparently different countries that the zipcode could match on, and even though I select US, it still brings in the lat/long for hungary.

I went ahead and reset the search filter, then entered the 45237 zip again, and the lat/long showing in the hidden controls is now correct. however, searching on that zip with a radius of 28 miles returns no hits, whereas a search with a radius of 0 miles returns a single hit (the one entry is in that exact zip code). You can see an image of the developer tool data here: https://ibb.co/GTPMJzw

Not sure at this point what more info I can gather from my end.

• This reply was modified 4 months, 1 week ago by mflc.
• This reply was modified 4 months, 1 week ago by mflc.

additional follow up: after some additional testing, I can report the following:

1. After setting the radius search field to use zip instead of address, the radius search slider seems to be connected to the zip field in the search form. when somebody enters a ZIP Code in the zip field the radius search slider control appears.
   
2. When one types in a ZIP Code in the zip field, the two associated hidden fields (city latitude, city longitude) seem to respond. as long as you’re typing in a valid ZIP Code, the latitude and longitude seem to be changing dynamically.
3. when you click apply filter, the page moves to the search results page, in the query string has the latitude and longitude from the hidden fields in the search form.

despite all this seeming to work properly, nevertheless, search results page doesn’t return the correct results.

I can say further that if I have a listing in the exact ZIP Code that I enter into the zip search field, the search results will not return that listing if radius search field in the search form is set to anything other than 0. In other words, if I enter the exact matching zip for the listing, and set radius search to 0 miles, it returns the listing. If i enter the exact matching zip for the listing and set radius to anything >0, it returns no results at all.

• This reply was modified 4 months, 1 week ago by mflc.

following up – I found how to control whether the search radius filters based on address or zip. I set it to zip, but it seems to be wildly inaccurate.

I type in 90210 for search and the query string for the resultant URL the search form generates is:

directory_type=providers&zip=90210&zip_cityLat=47.68467725&zip_cityLng=17.632186276832662&minimum=60&miles=60

which is in Hungary and not Los Angeles.

• This reply was modified 4 months, 1 week ago by mflc.

Thank you for the response. I looked into this a bit. it looks like the location where I modify code to get two fields to concatenate are the functions render_loop_fields() or render_card_field() in class Directorist_Listings, in /includes/model/Listings.php, but that is core to the plugin and not an overridable template (unless I am missing something). Overridable templates like loop-list-nothumb.php seem to simply call render_loop_fields() and so don’t really allow a way to make any changes at the granular level of individual fields.

Am I missing something and can I customize class Directorist_Listings somehow like a template (so that I don’t have to worry about any changes I make being blown away with the next plugin update)?

Thanks in advance!

@dioni00 Thank you for the quick response. I cleaned up the logs as per your recommendation. I also reset all the settings but it did not improve performance.

Bizarre, deactivating WP Rocket didn’t help. But commenting out the the wp-config.php directive

define( 'WP_CACHE', true );

without deactivating the wp-rocket, or setting the value in the directive to false, again without deactivating wp-rocket, solves the problem.

Ok, I disabled BB Style Pack (but not BBPress itself). Same problem when I try to edit an Avada Layout. Disabled BBPress as well, same issue. I am thinking this is unrelated to your plugin.

A few weeks ago I was editing the Avada Layouts without any problems. Not sure what may have changed.

Update – this may not be limited to just your plugin. I noticed it happening when trying to save a new Avada Theme Layout.

The problems appears specific to the BBPress Styles plugin. You can see the issue here: https://imgur.com/a/fd5GMbN where I click on the display tab and no settings appear, click on a different tab and see the error I reported. A few tabs, like plugin information, dashboard admin, and translations do render properly (I didn’t do an exhaustive survey of the tabs, but I can if it will be helpful). Right now another plugin in masking the actual

Just to clarify, I am running/testing in a local development environment using the LocalWP development stack, which is owned and maintained by WPEngine (https://localwp.com/). Using WP Rocket for caching etc.

Thanks for jumping on this so quickly!

Awesome! Thank you!

Michael

Hi Stiofan,

Thank you for the very quick reply ??

Do you have an rough guesstimate of when you think the new release will be available?

Thanks,

Michael