[Resolved] Page won't render if I add a Map

[Author]

Posts

[Mario Hernandez]

As you can see, Toolset Maps has stored in our dev site the cached address information with decimal comma instead of decimal period.

I think this will solve the issue.

I went to the clone site that CORRECTLY renders the map, and found that the cached addres latitudes and longitudes are stored with decimal period.

So the problem seems to be in the incorrect parsing of latitudes and longitudes from Google when wordpress language is in french.

I do attach two images. The one with decimal comma is the one that does not show the markers, in the DEV server. the one with decimal periods is the one that correctly shows the markers, in the CLONE server.

Since the CLONED database should have been the same one as the original website, we therefore suppose that Toolset maps has refreshed the markers cache in the cloned database, obtaining the latitudes and longitudes again from google, but this time with point separator.

Your team has any clue on this?

Maybe in a future update the cached addresses will be obtained correctly from Google in non-english sites?

Thank you Christian,

Mario

[Christian Cox]

Yeah, re: comma vs. dot, see my previous comments:
https://toolset.com/forums/topic/page-wont-render-if-i-add-a-map/#post-1154923
https://toolset.com/forums/topic/page-wont-render-if-i-add-a-map/#post-1158000
The real question is why is it sporadic on the dev environment? I have no idea. If the files and database are identical, I'm not sure how to replicate the problem.

[Mario Hernandez]

Its very strange. My supposition is that the clone server has redownloaded correctly with periods the latitudes and longitudes from the Geocoding API, and instead our dev server has downloaded the latitudes and longitudes with commas.

I don't know why the Google Geocoding API would have returned the information with a comma separated response.

Please, if you don't find a clue and can ask the rest of Toolset Maps plugin developers for this, to get more light for this issue I would be very grateful,

thank you Christian,

Mario

[Christian Cox]

I'll see what 2nd tier support says, maybe they can recreate the issue from your database dump file where I could not.

[Christian Cox]

My 2nd tier has had problems importing the database. The problem is not replicable on a clean site installation, so my 2nd tier needs to follow up with you directly here. I'm assigning this ticket to Beda, who can continue assisting you with this issue. Thanks for your patience while we work this out.

[Beda]

Hello Mario, I had a deeper look at this issue.

1. Right now, both seem to work:
hidden link
hidden link

Do you have any new example that does not work, and/or do you know why above work now? Did you eventually purge cache?

2. As far I understand, neither you nor Christian (nor me, I can confirm that) were able to replicate this issue not even with the Duplicate or Database dump on ANY other server/site but the affected (one) develop site.
Is this accurate?

In this case, it is an exception, possibly due to an issue that is replicable only following a possibly long chain of steps, and additionally could be connected to
- Database connection failure,
- ISP failures
- up to even Google API failure (they are not bug-free either)

This means the issue would probably not be replicable anymore at all if the staging/test site affected would be reset, and overwritten with a copy from the original.
I could not see if this was tried, and that is what I would suggest in this case, since it is not the Live site presenting the issue, right?
Only the DEV site presents this issue?
Please correct me if wrong.

3. I see you mention, that you see the reason is French as a language and that makes sense, especially also reading that ticket you shared about Drupal.
In fact in French and many other languages interpunctuation is different and gets translated from dots to commas for certain things, let's say, price or date or time
BUT, this should not (and does not, on a clean install) affect Google's delivered Lat and Long values, I tried to replicate such a case and could not (unless of course, I would miss some step, but I think I covered all possible cases)

4. The most important here is:
- does this issue happen, when you add a new address in the affected site, to a post?
- does this issue repeat for already stored addresses, if you remove those from that cache list?
- if so, does it repeat consistently or only sporadically (which means it's due to the ISP or Google API online state)
- does it happen if you take the original, life site and redeploy it over the staging site?

I apologise if some of the questions I ask above are answered already, then I missed the detail, reading thru this ticket, i could however not find precise detail about those points.

The point I want to be most careful about is:
- if this is ONLY affecting one, and the one site is a development site, then the issue should be solved by simply re-deploying that development site from a copy of the live site.
- if the issue then repeats, it should be replicable anywhere, and hence, we could/should see the issue using the very copy of that site, which until now was not possible.

From our developers, I do not know anything that would create such an issue, especially because we do not yet have any steps that show how to produce such issue.

My suggestion is to overwrite the DEV site, if this is possible, with the working copy.
If then the issue happens again it must be due to the server configuration, since if the exact copy A works on server B it has to work on Sever C as well, otherwise there is a issue with that server (which we cannot help with)

Let me know if this is a possiblity, if not, please let me know the details I need above to proceed further.
Thank you!

[Mario Hernandez]

Thank you Beda for your detailed investigation and response.

I will answer you point by point:

1. Right now, both seem to work because we replaced manually the commas for dots inside phpmyadmin. We have the fear that new address conversion tasks would generate decimal comma coordinates and the map will fall again.

2. You are true, as in the clone server, all worked seamlessly. Your hypothesis are all possible. The dev server is not live, and we have not live server currently working. This is the first release. We are working in AZURE with an Linux UBUNTU nginx server. We want to fix this by continuing the investigation

3. This is our doubt. We don't know why, but the generated coordinates are with decimal comma instead of decimal dots. Our suspect is that the language could have to do with this, regarding that drupal issue post.

4. This issue does not happen when I add a new address in the affected site! Is curious. It works. Also, when I remove an address from the cache, it generates it correctly.

We have so not managed to know why happened the conversion to decimal comma... still

Thanks,

Mario

[Beda]

1. OK, hence the issue is not replicable anymore if I am understanding this correctly.
2. It is also not possible to restore a backup with the issue, as the one provided earlier is not deployable.
3. Since this happens only if you (If I understand it right) port the site, from server A to B, but not after porting if you add new addresses or remove them from the cache and regenerate them, then the only way for me to replicate this is by porting the site from A to B and see if that happens.

It does not when I follow this doc to port a website:
https://toolset.com/faq/how-do-i-migrate-a-wordpress-site-from-one-domain-to-the-other/

However, note that I do not use any cache mechanisms or any other plugin for that is.

To help solve this we will need:
- the exact steps to replicate it (we have them, it seems, we need your copy of the original site, deploy that, and see the issue)
==> If there are any addon points I need to follow please let me know.
- I need a copy of the live site that is deployable.

The copies received until now are corrupt, the databases throw errors on import, speaking for problems not related to Toolset on the main site.
If I could get a copy of the site you use to duplicate (hence, your original) and the steps you use to duplicate, I can try locally and see what happens

If then the issue does not happen it would be a server problem that we cannot solve from our end, as we would not assist server issues.
If I could see and replicate the issue, I could report it to the developers, but without knowing how to reach or replicate (see) the issue, this is difficult.

Note that staging sites always require new API keys unless you have your API key configured to work with that site as well.
So that might as well be a cache issue of Maps itself, but It is to soon say that because I can actually not replicate any such problem with a clean install and a clean migration.

Can you help me with the data I need?
I added a private reply.

[Beda]

This resulted in a "Your file exceeds the maximum upload size for this site: 32 MB".
I increased and increased, and it did not help.

I can not deploy that package it seems, what settings do you use in PHP Ini to upload this package with the Importer?
Or, do you have an URL I can use instead of the file?
(It seems this needs an extension)

[Mario Hernandez]

Hi Beda,

Thanks for your support, detail and attention.

I changed the way to offer you a backup: I have installed Duplicator, and have not been able to create a full backup of the site due to server limitations, but I let you access the website with the credentials shared before, and invite you to get a copy of the site for your investigation purposes in this issue. Maybe you can filter the wp-uploads folder to economise the backup and allow the creation of the backup.

NOTE: we are now LIVE, that means that the URL is now hidden link

The access page is hidden link.

We have a strong protection against bad access inputs, so try to type the correct credentials given before (user toolset)

Thank you Beda,

any question please don't hesitate in asking me,

Best,

Mario

[Beda]

If the server is not allowing the Duplicator Plugin to grab a copy successfully this, unfortunately, will be the same if I try.
In fact, even if I exclude all possible (unneeded) parts I still receive "Host Build Interrupt".
I was, however, able to get a Database Copy, now, I would need to know where the issue was/is visible on this new site because the old Links do redirect to other pages, where no map is included.

Then I can deploy the database locally on a simple FTP with Toolset and see if the addresses are stored correctly in the cache and database and the maps show fine.

[Mario Hernandez]

Thank you Beda, the issue was found in the new url hidden link

Please let me know any more need,

Best,

Mario

[Nigel]

Hi there

Beda is on vacation until next week, I'm looking into this thread.

It appears that the issue is with markers being displayed on a map, but not with newly added addresses, nor after clearing the map address cache, and only when the site is migrated to a new URL, is that correct?

I logged into your site and used the All in One WP Migration plugin to create a backup archive (3Gb). I downloaded and installed that locally.

I had some problems doing so because of the various security/optimisation plugins you have active.

After installing the site I was unable to log in, and the debug.log contained a number of errors (from cerber and from WooCommerce).

To be able to access the site I needed to rename the plugins directory (so that it wasn't found by WordPress), log-in, visit the plugins page (to clear the list of active plugins), then rename the plugin folder back to /plugins/.

I then activated the Toolset plugins, and visited the page /annuaire-map/, where the map loaded with over 900 markers (see screenshot).

So, I could not reproduce the problem described where migrating the site means the markers are not shown.

Perhaps the issue relates to one of the security or optimisation plugins you are using.

To be able to debug the issue we will need the exact steps to be able to reproduce it, and if that includes migrating the site, that will require being able to migrate the site without workarounds to bypass the security, and the process should result in a working version of the site which does not generate PHP errors in the debug logs.

In the meantime, it sounds like it should be possible to fix the issue on any existing migrated site that has the issue by deleting the address cache from the page Toolset > Settings > Maps. That involves deleting the addresses one-by-one. You may find it easier to simply delete the option with key 'toolset_maps_address_coordinates' from the wp_options table.

[Mario Hernandez]

Thank you Nigel, Beda and Christian. Your support was deep and serious.

We will try this solution if we find further issues.

Have a great day,

Best,

Mario