[Resolved] Map Zoom Factor wrong everywhere after updating to Maps 1.5

[Author]

Posts

[Thomas AMX]

Hi guys,

After I updated to the latest version, I noticed that now all my maps in posts have the maximum zoom.
They are supposed to have zoom factor "7" or "10" or "14", and it has worked that way for almost a year.

I have three Content Templates for maps, depending on the zoom factor and I insert these content templates into posts.
Where I need zoom 14 I insert the content template with zoom 14, and similarly for zoom factors 10 and 7, the respective CT:

<div class="post-map">[wpv-map-render map_id="map-[wpv-post-slug]" single_zoom="10"][wpv-map-marker map_id="map-[wpv-post-slug]" marker_id="marker-[wpv-post-slug]" marker_field="wpcf-my-address"][/wpv-map-marker]</div>

It worked nicely until the update. The cached version online is still correct, but the uncached administrators view shows the maximum available zoom everywhere. After the cache expires and the cache is recreated, I assume the wrong zoom factor will be visible to everyone.

Please advise. Does "single_zoom" still work?

Kind regards,
Tom

[Beda]

Yes, "single_zoom" still works according mine and our testers tests.
I tested this as well coming from fields created with legacy versions.

Hence, this is a particular issue due to either some settings or else.

Can I suggest basic debug steps first?

1. Please backup your site or duplicate it to a staging site
2. Deactivate all non-Toolset Plugins and use a WordPress native Theme like Twenty Seventeen
3. Disable Must use, cache, etc
4. Make sure all your software remaining us up to date
5. Check the issue again
==> Try several things like reserve the post, or re-set the address, in case at this point it is not resolved.

If this helps nothing please let me have a closer look.
I would need a copy of that site I describe above.
Please see the steps on how to provide it to me here:
https://toolset.com/faq/provide-supporters-copy-site/

I will work tomorrow as well, so I can (if the issue is not solved with the steps) help you then.

[Thomas AMX]

Thanks Beda, I did all that, also re-uploaded all Toolset plugins via FTP, cleared all site caches including Cloudflare. But it didn't fix the issue.

Then I discovered by accident that in a fresh browser the zoom factor was surprisingly correct. So, I cleared cache in all my browsers and all maps are displayed correctly, as far as I can see.

Browser cache, dang... That means that all repeat visitors will see incorrect zoom factors. I doubt that many "normal" users clear browser cache regularly... I wonder if there is something that could be done so that repeat visitors get correct zooms?

Cheers
Tom

[Beda]

I found this:
hidden link
https://stackoverflow.com/questions/8347595/htaccess-how-to-force-the-clients-browser-to-clear-the-cache
hidden link

Seems it is not possible to force a browser to forget the cache, but seems there are workarounds to it.

However, what confuses me is why the cache should actually show something broken, if that is not what you set.
It should, logically, keep displaying that working version (that is the only I could cache imagine to do)
Then, slowly the caches re-update and you'd eventually see a (which we confirmed is not) broken Map.

The other way around does not make sense to me, why would the cache be showing a broken content if it worked?
However, we are as well playing with Google Maps stuff here, so I am really not sure how Cache interacts with site cache and browser caching on the server or plugin level.

Usually I do suggest to not cache Toolset things as we already include such mechanisms
Read more here:
https://toolset.com/documentation/user-guides/front-page-filters/how-to-use-views-parametric-search-on-large-sites/
https://toolset.com/forums/topic/can-toolset-can-handle-a-big-db/#post-379949
https://toolset.com/faq/working-with-caching-plugins/
https://toolset.com/documentation/user-guides/display-on-google-maps/#data-caching
https://toolset.com/documentation/user-guides/data-caching-for-google-maps-addresses/

So, it is usually not only overkill to cache a Toolset site, but moreover creates issues and I have seen several sites being less performant due to this.

I would like to - if confirmed - be sure the issue is not related to Toolset.
For this, of you can replicate this or have some steps on how to, I could try to replicate such a scenario, but it'll cost some time as it'll require remote caching I suppose, and I cannot do that locally.

Please let me know about this, I do not want to close this with a "it's fine but..." feeling

If there is an issue in Maps we want to solve that, but it is tricky to figure out from what I have and know, if this is really a Maps issue.
I suspect, not, since there are already several cache mechanisms that I would need to exclude from a debug process.

It could however as well be an incompatibility.
Please can you let me know if you hav detailed steps to replicate this or even have a copy of such a (slimmed down) site?

When we can confirm a bug we'll solve it.

[Thomas AMX]

Thanks Beda.

I suspect that perhaps some JS file that was responsible for setting the correct zoom factor was replaced by another file in the new version of Toolset Maps. Perhaps the old file still lingers in the browser's cache and creates a conflict. Or perhaps something similar happened.

I use Cloudflare and there my cache lifespan was set to 8 days. Cloudflare caches images, CSS and JS. My understanding is that after this period Cloudflare 'tells' the browser of repeat-visitors to download a new version of each file. As I re-uploaded the whole plugin via FTP, the old files don't exist anymore.

I did clear Cloudflare's cache but apparently it had no effect on browsers, so perhaps the file has a different name now and the old one can 'survive' in browser's cache and cause issues.

I haven't cleared the cache in my phone, and this is the only place where I still can see the problem. On the PC I cleared all caches and don't see it anymore.

I created a completely new post with a map, and in my phone I see the wrong zoom factor in this new post. So, it's not html caching, but probably some bad js or other file survived in the browser's cache.

Replicating this issue would be very time-consuming and probably also difficult. My hope is that after 8 days the problem will go away, as browsers are supposed to re-download the files. This would be the simplest solution. For the time-being I would like to keep this thread open, if possible.

Cheers
Tom

[Beda]

This makes sense.

I will await your confirmation.