@leaferdesign Thanks for letting me know about this.
It is very likely to be an issue with the database collation you’re using or the character set that’s used in WordPress. The plugin uses the native WordPress functionality to store, load and display data in the options table that’s utilized extensively in the plugin.
- Are the reviews containing the error character only from using the HTML Import, the automated API collection or both?
- Do you see this in the Dashboard or just the front-end?
Thanks!
Noah
Hi Noah,
Thanks for the response.
1. I believe nearly all are from HTML import?
2. I only see the “� �” problem in the front-end, there’s no problem in the Dashboard/settings area. It also displays fine when viewing from phpmyadmin.
However, I think you might be right about the database collation? I checked one of the reviews in the database and found that the “� �” character was a “<br>”. There was also a warning:
Warning: #1977 Cannot convert ‘utf8mb4’ character 0xF09F92B2 to ‘utf8’
Still, the table’s collation is set to utf8mb4_unicode_ci, and haven’t had any problems elsewhere so I’m not quite sure what to do…
What would you advise?
On a sidenote, I would like to point out that it’s really hard to select/see that language shortcodes in the plugin dashboard! (screenshot).
I’m not sure if it’s relevant to the problem, but there’s also the discrepancy between the Google review importer showing “zh-Hant” and the WordPress locale code of “zh-tw”
-
This reply was modified 2 years, 9 months ago by
Leafer Design.
-
This reply was modified 2 years, 9 months ago by Leafer Design.
-
This reply was modified 2 years, 9 months ago by Leafer Design. Reason: Add info about the problem
@leaferdesign I received a notification email of your reply, but the reply here has disappeared…
I have the message, so let me know if this is still relevant or perhaps you’ve resolved this issue?
@designextreme I think the moderation bot may have flagged it? I’ll repost:
1. I believe nearly all are from HTML import?
2. I only see the “� �” problem in the front-end, there’s no problem in the Dashboard/settings area. It also displays fine when viewing from phpmyadmin.
However, I think you might be right about the database collation? I checked one of the reviews in the database and found that the “� �” character was a “<br>”. There was also a warning:
Warning: #1977 Cannot convert ‘utf8mb4’ character 0xF09F92B2 to ‘utf8’.
Still, the table’s collation is set to utf8mb4_unicode_ci, and haven’t had any problems elsewhere so I’m not quite sure what to do…
What would you advise?
On a sidenote, I would like to point out that it’s really hard to select/see that language shortcodes in the plugin dashboard! (screenshot).
I’m not sure if it’s relevant to the problem, but there’s also the discrepancy between the Google review importer showing “zh-Hant” and the WordPress locale code of “zh-tw”`
@leaferdesign Strangely, it reappeared once I replied…
I think this is something that I can test for and replicate on my development server. So, if you have it available, please drop me an email to wordpress dash plugins at designextreme dot com with the HTML used in the HTML Import (place within a text file with UTF-8 encoding).
It’s easier to receive your version and I can see where the error is introduced within the import process. The collation is the standard one used by WordPress, so it should at least work in your case. I cannot be sure about other collations.
Thanks for the screenshot of the languages dropdown – I think you’re experiencing this because of the window size – and it should be OK when you’re viewing the dropdown options (rather than the preview). Places API will summarize the language as “EN” rather than a specific sub set – the lack of consistency doesn’t help keep the data pristine. I recommend manually setting this yourself once the Places API has collected its data.
Anyway, that’s about all for now. I’ll post a follow up when I have something to report.
@leaferdesign I have used your Place ID and set the language to Chinese (Traditional) – zh-TW throughout and I can replicate the issue you’ve described. Now, I need to figure out where this encoding error is introduced into the front-end (not Dashboard)…
And, I figured it out… this is only occurring in the break between “Read more” and the full text – so the substring command is splitting up the characters that make up the word: 西 (and others). I’ll find a fix for this and create a fix in the next version of the plugin.
If I am wrong about this assertion, please correct me.
Thank you so much @leaferdesign for the details here and by email. It is so much easier to see this when I can replicate this myself.
@leaferdesign Please download the latest version! 🙂
@designextreme I didn’t get a notification that you replied in this thread, but noticed you’ve fixed the output with the latest plugin updates – brilliant!
Thank you so much!
