invalid byte sequence in UTF-8 while exporting DB after update to GMapsPro 7

[Perry]

Hi Luc

Can you please check your ad blocker isn’t treating the export as a popup and blocking it?

I downloaded your CSV from Google Drive and then uploaded the CSV to the new v7 importer, the import was successful and no data was corrupted.

Can you please try that?

Kind regards
– Perry

[arthos]

AdBlock checked, I even tried with a pristine browser.

I’ll try to add these in my local site and see if that’s ok.

[Perry]

Hi there,

I see, thanks.

If this is specific to the one site then I will need access to said site and step by step instructions on how to reproduce the problem.

I look forward to your reply, good luck with the testing!

Kind regards
– Perry

[Perry]

Hi there,

I see, thanks.

If this is specific to the one site then I will need access to said site and step by step instructions on how to reproduce the problem.

I look forward to your reply, good luck with the testing!

Kind regards
– Perry

[arthos]

Ok, that’s weirder and weirder.

I emptied the ‘latlng’ table field in MySQL CLI : UPDATE table_prefix_wpgmza SET latlng = ''
SELECT id, latlng from table_prefix_wpgmza gave me a clean id:{empty} list. On the map, the marker listing is still there, but markers disappeared from the map.

I reuploaded the marker data, checking the automatic Geocoding option (and entering the API key). It went well: ‘your csv file was correctly imported’. Markers are back on the map, but when I do SELECT id, latlng from table_prefix_wpgmaza I get again a list with the id and some uncipherable gibberish…

After emptying the table fields, I reimported the CSV export file, without checking the Geocoding option, and the latlng field remains empty, this time. I’m able again to synchronize my databases…

So I guess it comes from Google API. Not UTF8 data ?

[Perry]

Hi Luc

If you’ve set the latlng field to blank, I would expect the markers to disappear.

Can you please set them to NULL then de-activate and re-activate the plugin, this will cause the latlng field to be repopulated.

latlng is of type POINT and uses MySQLs spatial types, which give a significant improvement in terms of bandwidth and performance over storing these values as text. The undecipherable gibberish is the spatial data in it’s raw form – if you want to view that in a query you need to SELECT id, AsText(latlng) FROM wp_wpgmza to view it in a readable format.

I’d be very interested to take a look at the CSV and get FTP credentials for this site to test this out if that’s permissible? We’re trying to iron out issues with the recently integrated spatial types, so any sites suffering issues that I can get a look at, I would be genuinely grateful to see. Would that be possible?

Kind regards
– Perry

[arthos]

This reply has been marked as private.

[Perry]

Hi Luc

Thank you for that, I can confirm I’m able to access the site. Please rest assured all credentials are handled strictly in confidence and will be destroyed after we’re finished.

I did some basic tests and didn’t spot any error messages or anything indicating what the issue is, I’ve asked the developer who wrote this module to investigate as he’ll likely be able to assist you with this more promptly than I can.

By the way, the error log is enabled on that site and your log is approaching 200mb in size – I’ve cleared that for you. If you need that log please let me know, I have a backup.

Please bear with us on this issue, my colleague is in the EST timezone, he will be looking into this shortly.

Kind regards
– Perry

[Author]

Posts