small supplemental: Not even a container (“section”) element is generated for the map content.
Ok, I think I got it. The code for google maps seems to be outdated. Dirty fix:
- Create a child theme for now.
- Create a child plugin for now.
- Edit theme file ‘listing-location.php’ around line 45:
//$lat = get_post_meta( get_the_id(), '_geolocation_lat', true );
//$long = get_post_meta( get_the_id(), '_geolocation_long', true );
//if( $lat && $long ) {
if( get_post_meta( get_the_id(), '_map_geolocation', true ) ) {
- Edit plugin file ‘listing-single-location.php’ around top:
global $listing;
$location_array = get_post_meta( $listing->ID, '_map_geolocation', true );
$lat = (get_post_meta( $listing->ID, '_geolocation_lat', true )?get_post_meta( $listing->ID, '_geolocation_lat', true ):$location_array["lat"]);
$long = (get_post_meta( $listing->ID, '_geolocation_long', true )?get_post_meta( $listing->ID, '_geolocation_long', true ):$location_array["long"]);
-
This reply was modified 9 years, 3 months ago by
marksu2017.
Hi Mark,
thanks for getting in touch.
We actually have no reports from our users that the Google Maps aren’t working, thus I’m not sure why the Google Maps code should be outdated. However, your initial request was very good and you already tested and confirmed a few things. But it is also important to know what theme you’re using and if there is might be an incompatibility.
Feel free to leave that for now, but if you prefer to let me have a closer look on it just let me know.
All the best
Hi,
Theme is Elvira, and both the plugin and the theme seem updated to the latest version.
I’d ask you to do so. Please check on a working instance if there is both “_geolocation_[lat|long]” meta data in the database for a particular listing. In my instance, those were missing for all listings with an address set in the location box in post editing. I only have the _map_geolocation meta with a JSON containing lat, long and alt.
I assume it’s not the widget code that misbehaves (see above) but the admin interface code that somehow misses putting these meta tags into the DB in the first place and only puts the JSON stuff in there.
In any case, the fix above does not harm current behaviour and extends protection against cases where lat/long is available via JSON only; perhaps put it in an upcoming release…
Cheers, Mark