[Resolved] Split: Map don't load if one of the posts is not well filed

[Author]

Posts

[romanB-3]

Update?

[Nigel]

Here is a summary of the current position for Beda.

The issue:
The Event Calendar creates a post type Venues ("Lieux"). Many, but not all, venue posts have lat/lng coordinates stored as post meta with keys _VenueLat and _VenueLng.

A View ("Tous les lieux") lists venues and shows them as markers on a map, with the marker location coming from the lat and lng post meta (Toolset address fields are not used).

This View is shown on this page: hidden link

The markers do not display. An "empty" map (lat = 0.00, lng = 0.00 ) is shown.

Roman asserts that this used to work and suggests that the problem is that not all venues have the coordinate data.

We previously solved numerous errors on the page by dequeuing the Event Calendar map assets.

I have taken an updated copy of the site (details in the private notes above).

I had to remove the security and caching plugins to be able to get the copy of the site working locally. Even then the /lieux/ page was inaccessible on my copy, I had to create a new test page and insert the same View on it for testing.

I replaced the client maps API keys with my own unrestricted key.

I found the same issue, that the map wasn't displaying correctly.

There are 300+ venue posts. I trashed them all, and began to selectively restore individual venues. Most of the most recent ones do not have venue lat and lng, and I checked in the database to find venue posts which do ("La Veranda Ouaga 2001" (id 21374) and "Vert Galant" (id 10620)) and restored those. Checking, the map then correctly displayed, showing a marker (by coincidence the posts have the exact same coordinates).

I then started restoring venues in batches of ten and was unable to break the map, it continued working.

So I restored all of the remaining venues in one go and it still worked correctly.

So, having not worked, trashing and then restoring all of the venue posts seemed to fix the issue.

So I quickly tried something similar on the live client site, but it didn't help. So I trashed all posts except the two listed above which I know have coordinates, and it still did not work, still no markers. So I swapped out the client API keys with my own unrestricted key and that also made no difference. Clearing the caches didn't help. I restored the live site back to how it was.

That is as far as I've been able to go, and I'm now handing over to Beda to see if he can provide any insight.

Once again Roman, I apologise for the delay in following this up.

[Beda]

The first problem I see here is that you set a limit to the View (limit="-1").
hidden link

I see no need for this as -1 means all posts, so you can simply omit it.

[wpv-view name="tous-les-lieux" orderby="title" order="desc"]

Then I see the View itself uses a complex markup of shortcodes not made by Toolset.
The View, if just outputting Titles, seems to produce the right results.

However, something is massively caching the content. Note when you make changes to the View, they get applied, if you change those back, they do not get reverted for until you re-save your entire page.

I duplicated that view (hidden link), removed all unnecessary HTML and ShortCodes, and it's now visible here:
hidden link

As we see, [wpv-post-field name="_VenueLat"] and [wpv-post-field name="_VenueLng"] seem to output correct data for some posts, not for others:
hidden link

As we see, it does not even display a Single Marker, if we actually pass the Lat/Long manually, as numbers:

[wpv-map-marker map_id='map-1' marker_id='marker-2' lat='12.3714277' lon='-1.5196603'][/wpv-map-marker]

So, this should either be replicable on a clean install or not.
I had no time to try this specific case (passing manual lat/long), however, I will try this first thing tomorrow in the morning on a clean install.

It is working on a single Page BTW, it is not working in the Loop of the View.
I will check tomorrow why.

Can I set up a Test Post Type or some Test Custom Fields on that Site to test with?

[romanB-3]

Thank you very much for this complete and accurate answer.
Yes you may test everything that can help identifying and solving the problem, as long the actual display is not affected (website is live).
Thank you very much.

[Beda]

I tested a fresh code on your site:

[wpv-map-render map_id="map-7"][/wpv-map-render]
[wpv-map-marker map_id='map-7' marker_id='marker-7' lat='12.3714277' lon='-1.5196603'][/wpv-map-marker]

This works, check it here:
hidden link

Below it I inserted the ShortCode (exact the same) as generated by your Website's Toolset GUI:

[wpv-map-render map_id="map-3"][/wpv-map-render]
[wpv-map-marker map_id='map-3' marker_id='marker-4' lat='12.3714277' lon='-1.5196603'][/wpv-map-marker]

It works as well but did NOT yesterday, and that points to the one and sole issue that can make this happen:
Google API allowance of free calls is overused.
This could be due to having deleted stored data in hidden link.
It mentions that Google only allows your site to convert 10 addresses to coordinates per second. If you delete too many addresses, the maps on your site may take several page refreshes to display correctly. Google doesn't like it when sites call the address resolution too often.
I see no addresses stored there at all, hence, it needs to generate them each time and in a view with more than 10 addresses... hopefully it loads in less than a second (otherwise Views would have a performance problem) and then, you exceed that limit and the address is not generated anymore.

The thing is, however, we do store those addresses ONLY for real Toolset Maps addresses, not for Single Lines that accidentally hold latitude or longitudes.
Those, need to be generated each time, which is the case on your site, being all addresses stored in non-address fields as lat/longs.
I tried this locally though and it works, in a view as in a single post.
I tried on your online site to limit that view to just one result, which as well does not solve this issue.

I created a complete fresh View and did not involve any of the Event Types or similar, still, this does not work.
This is a compatibility issue with either the plugins installed, theme, or server, there is no other possible issue, as I happen to replicate the issue with a minimal View on your site, whereas (you can give this a try on a new, fresh local WordPress Site) locally this will not present an issue.

Note that the issue is not the API of Google probably (even if it might be connected) but a software or any else on your site that is not present on any clean WordPress install as such and conflicts with Toolset Maps.
This may even be the dequeuing done so to avoid conflicts with the events map scripts.

The Duplicate I had in past of this site, cannot be used to debug, as each time I debugged it I solved the issue by simply removing non-Toolset code and software and solving the errors popping up (due to other software.)

I tested other address formats in your Views as well (in the Toolset Tes View) and it does not display either of those in the Views, so this really points to a conflict with another plugin and not with how the data is stored generally.

My bet is, as soon you fix the underlying errors which I had found in past during debugging, eventual other (cache or else) software things will start to display our addresses.
Of course that would be no solution but a confirmation that Toolset Address (even lat/long) works fine on a Toolset Maps but gets broken for some reason with the other plugins or errors or else.

We need to confirm this before we can do anything else, and since I confirmed this repeatedly locally already as well with the old duplicate, I have to ask to confirm this on your site.
This can be on a staging site you use to develop and test updates of the live site, or, on an internal but public and free server of ours where you could deploy the site and then make the tests.

However, it will be required in future to test updates on your live site hence I assume you have a staging site.
There, we can try to confirm the conflict same as we did locally, whereas the issue was solved repeatedly by solving the underlying errors and disabling the 3rd party software (note, not events, as back then I tested with the lat/long as stored by you in the single fields, hence I needed events to work and be there).

This is just an excerpt of the errors I got back then on this site while debugging it locally:

( ! ) Notice: /Applications/MAMP/htdocs/stable/wp-content/plugins/the-events-calendar/src/deprecated/Tribe__Events__Asset__Factory.php est obsolète depuis la version 4.6.21 ! Utilisez Deprecated class in favor of using tribe_asset registration à la place. in /Applications/MAMP/htdocs/stable/wp-includes/functions.php on line 3981

( ! ) Notice: /Applications/MAMP/htdocs/stable/wp-content/plugins/the-events-calendar/src/deprecated/Tribe__Events__Asset__Calendar_Script.php est obsolète depuis la version 4.6.21 ! Utilisez Deprecated class in favor of using tribe_asset registration à la place. in /Applications/MAMP/htdocs/stable/wp-includes/functions.php on line 3981

( ! ) Notice: /Applications/MAMP/htdocs/stable/wp-content/plugins/the-events-calendar/src/deprecated/Tribe__Events__Asset__Abstract_Asset.php est obsolète depuis la version 4.6.21 ! Utilisez Deprecated class in favor of using tribe_asset registration à la place. in /Applications/MAMP/htdocs/stable/wp-includes/functions.php on line 3981

and jesus, my error log grows, like animated. 10, 20 lines a second of page loading with that view.
[12-Sep-2018 07:58:00 UTC] PHP Notice: Undefined variable: post_type in /Applications/MAMP/htdocs/stable/wp-content/plugins/all-in-one-seo-pack/aioseop_class.php on line 4159
[12-Sep-2018 07:58:00 UTC] PHP Stack trace:
[12-Sep-2018 07:58:00 UTC] PHP 1. {main}() /Applications/MAMP/htdocs/stable/index.php:0
[12-Sep-2018 07:58:00 UTC] PHP 2. require() /Applications/MAMP/htdocs/stable/index.php:17
[12-Sep-2018 07:58:00 UTC] PHP 3. require_once() /Applications/MAMP/htdocs/stable/wp-blog-header.php:19
[12-Sep-2018 07:58:00 UTC] PHP 4. include() /Applications/MAMP/htdocs/stable/wp-includes/template-loader.php:74
[12-Sep-2018 07:58:00 UTC] PHP 5. get_header() /Applications/MAMP/htdocs/stable/wp-content/themes/Avada/404.php:14
[12-Sep-2018 07:58:00 UTC] PHP 6. locate_template() /Applications/MAMP/htdocs/stable/wp-includes/general-template.php:41
[12-Sep-2018 07:58:00 UTC] PHP 7. load_template() /Applications/MAMP/htdocs/stable/wp-includes/template.php:647
[12-Sep-2018 07:58:00 UTC] PHP 8. require_once() /Applications/MAMP/htdocs/stable/wp-includes/template.php:688
[12-Sep-2018 07:58:00 UTC] PHP 9. wp_head() /Applications/MAMP/htdocs/stable/wp-content/themes/Avada/header.php:21
[12-Sep-2018 07:58:00 UTC] PHP 10. do_action() /Applications/MAMP/htdocs/stable/wp-includes/general-template.php:2614
[12-Sep-2018 07:58:00 UTC] PHP 11. WP_Hook->do_action() /Applications/MAMP/htdocs/stable/wp-includes/plugin.php:453
[12-Sep-2018 07:58:00 UTC] PHP 12. WP_Hook->apply_filters() /Applications/MAMP/htdocs/stable/wp-includes/class-wp-hook.php:310
[12-Sep-2018 07:58:00 UTC] PHP 13. All_in_One_SEO_Pack->wp_head() /Applications/MAMP/htdocs/stable/wp-includes/class-wp-hook.php:286
[12-Sep-2018 07:58:00 UTC] PHP 14. All_in_One_SEO_Pack->get_robots_meta() /Applications/MAMP/htdocs/stable/wp-content/plugins/all-in-one-seo-pack/aioseop_class.php:3902

There where many (hundreds) of JS errors in the console and other issues.

Back then, thigns strated working as I feedbacked to Nigel as soon I had solved or removed those issues.
I do not see most of these problems on your live site but I am quite sure there are errors, as otherwise, the plugins would behave exactly the same as on any other clean/fresh install.

Hence, the staging site as well will bring the opportunity to find and address those.

Once we have the staging site, please deactivate all software but Toolset and test again.
If we are lucky by then it already should start to work.
We can then re-introduce plugins or code or settings until the issue happens again.
If the issue will not be solved on that stripped down test site, it will be the next step to duplicate that (slim) site which should by then be error free and only using Views and Maps and still showing the issue.
Then, that will be a replicable BUG we can solve.

That, until now, was not possible to achieve, which makes it impossible for us to fix it as we do not know how to replicate this.
Such steps will help to not only find the exact problems description and steps, but also to fix it.

Please submit me access details to the staging site where you disabled the software in the next private reply if possible, if not, as said I could request a (free) test site

[romanB-3]

Hello and thank you very much,
The site is very heavy so I'm trying to find a way to duplicate it. Duplicator doesn't work... Nor does All Ine One WP Migration...
In the meanwhile, it seems you made the whole backend in English, which is very annoying for my other users and me. Could you please :
- restore the French ;
- telle me how to restore the French when someone moves it in English, since the Toolset support makes this every time and I would need to correct this when you forget.
Thank you.
Please activate private fields for my next answer.

[Beda]

I did not touch the admin language.
I saw that the user language is English, you can simply reset that to whatever else it was before (I encountered it English)
hidden link

The site language is hidden link french.

I made no such changes, however, it may be Nigel did?
However, you would just have to change the language of the user, it seems.

Note that it is NOT the expected behaviour of our Support to make changes of any kind on your site without clarifying or reverting them.
Please report us such issues, as you did now.

This is a small issue luckily, not a big change and it should be possible to set french for the user in his/her profile

The next answer is private

As a hint to deploy the site on a testing site, you can export a ZIP of the DDBB (Database) and the SFTP as well zipped.
Then, upload that to the new server/site and alter the site and page URL in the Database options table to the new site.
That will not work with Images and alike but it will be enough for these tests needed.

if you want to fully migrate the site to a testing site (I recommend this, it's a one time task and will help you forever later) you can also consult this instruction:
https://toolset.com/faq/how-do-i-migrate-a-wordpress-site-from-one-domain-to-the-other/

[Beda]

Great!
This is a test site now, which I can use and mess as I want, correct?

As first, the step is to remove any plugin but Toolset and make a simple test:
- display a Map, with a marker, the address is a simple lat/long:
lat='12.3714277' lon='-1.5196603'

If that works, re-enable the theme, and successively the plugins.

Since we know that right now this does NOT work on the site, but works locally and on other sites, we can get to the source of the issue as soon we know the plugin or code or theme that is causing this.

Do you confirm that I can do these (massive) changes?
(Or, if you go ahead and perform them, please let me know which plugin brings back this issue)

BTW I see on your live site it works:
hidden link
As well on the test site you need to update the Google API key as it is invalid for this site:
hidden link

What changes did you do on the live site to make it work?
I assume cache was blocking it, making it a pure server(cache) issue, you would have to clean/purge the cache more often or apply less strong rules.

[romanB-3]

Hello and thank you,
Yes in deed the toolset.* is a test site where you may do any changes you may need, thank you.
I'm not quite sure about the changes I did except maybe updates.
Still this page doesn't work hidden link
Thank you.

[Beda]

As suspected the issue is with a Plugin or the Theme.

See it working on the very page here:
hidden link

This View is practically the same as the live one, a bit simplified.
I disabled all Plugins but Toolset and events plugins.

You can turn them back on one by one to find the culprit, I suspect, it's All in One SEO Pack.
Just a Guess, but try to activate that one first, I have a feeling the view will immediately brake after.
If not, also activate the WP Rocket.
I am quite sure, by then the view is/will not work anymore.

If you can confirm this, it would be the immediate solution on the live site and we could open a compatibility process.

[romanB-3]

Hello and thank you,
In deed the AIOSEOPack is causing the trouble. This plugin has caused me a lot of issues so I will change it for another.
Thank you very much.

[Beda]

I understand.

Seems the Plugin is a source of issues as you mention.
In these cases, Developers appreciate when they know of those issues, so they can fix them.

I would suggest, that you gather the issues that plugin made you and try to prepare small example cases to replicate those issues easy and quickly.
Then, report those the related Developers.

It could be that they either already know or maybe have a solution for it.

In this case here, I am concerned that the plugin blocks address from showing on our map.
That should not happen.

Do you have a simple step by step issue where I could eventually even contact those authors myself, and start a collaboration?
If so, can you submit me the steps (minimal) that one needs to take to see this issue?
The thing is, I am not sure if some specific settings make this broken, so it would help to know if you are able to replicate this as well on a fresh install, or only there on the given site.

Please let me know if you have particular steps so I can even start contacting the author as well myself.