Weird characters in Jetpack Stats/Search/Spell Check

Hi,

When you’re saying Jetpack is displaying, where at specifically? (The stats in /wp-admin/ or the stats page on WordPress.com; by search, the Omnisearch area?, etc).

Thanks!

Hi Brandon,

as I said, directly on WordPress.com when logging in with my WP account outside my self hosted WP site, everything is fine. Same with the WordPress app for Android devices…

But right on wp-admin/admin.php?page=stats on my self hosted WP site it shows the strange characters in the post titles on the right side as well as on the left side where the search terms of the day are displayed. And the suggestions of the spell checking function in the editor are also displayed strangely when these suggestions contain umlauts and several other special characters.

Haven’t tried Omnisearch yet because of lack of need for it ??

Thank you!

With Search, do you mean the regular WordPress search?

What’s your URL?

My initial thought is the character encoding of the new database doesn’t match what the old one was set to, though I’d expect both would have been UTF-8.

Did you see this outside of Jetpack, e.g., if you deactivate Jetpack, does it still occur (assuming the Search is outside of Jetpack).

My URL is https://www.booknerds.de

And yeah, UTF-8, both the old and the new one. But, as you just said “database”: I had to delete two lines which caused an import error as you say, it was this one:

CREATE DATABASEnameofthedatabase` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
USE nameofthedatabase;`

After removing these lines (because it already has been created as an empty one), importing was successful (and the characters haven’t been strange anywhere except of the mentioned jetpack dashboard and the spell checker suggestions)

No, with the search terms I mean those ones which are displayed on my Jetpack Dashboard INSIDE my wp-admin…

I picked a random screenshot from the web:
https://www.allstuffweb.com/wp-content/uploads/2012/07/www.remarpro.com-dashboard-JetPack-site-stats.jpg <- and “Search Engine Terms” as well as “Top Posts & Pages” are where the problem is located.

The rest runs perfectly, with and without Jetpack. All my posts etc. are completely okay as well as media descriptions and so on.

I’m a bit stumped and couldn’t duplicate it with a title of “Ellen Jahn – Herr Pess und sein B?r (Buch)”, so does seem to related to the import.

The the /wp-admin/ stats view, we download records from WordPress.com stats system (via the post ID #s), then convert that to post title straight from your database (via return '<a href="' . get_permalink( $post_id ) . '" target="_blank">' . get_the_title( $post_id ) . '</a>';), though we do pull the blog_charset option as part of the remote request.

When you visit /wp-admin/options.php (there isn’t a link directly to this page anywhere), what is the blog_charset value?

I’m not sure why this would be failing while display on the rest of your site is working as expected.

Hello Brandon,

umm… ermm… how do I find that value? What do I need to do?

Hi,

Try going to https://www.booknerds.de/wp-admin/options.php . It should be a long list of option fields. Don’t change any of them and search for “blog_charset”.

Cheers!

Ah, thanks. It says UTF-8.

I’m stumped. I’m asking the developers on our stats team for any ideas or suggestions.

Thanks for your patience!

Strange, huh? ??

I’ll be patient, and I’m really curious about what the problem could be.

Their initial response was about the same as ours :-). They have it on their list for deeper investigation.

Hey there ??

Just wanted to tell you that this problem is also there when posting a comment (using Jetpack Comments). Instead showing the “ü” in “Kommentar wird übermittelt” (which means “Submitting comment”) there’s also some strange character.

Best regards

Hey guys! I’m also having the same problem with non-Latin characters (some special Turkish letters in my case) and I already reported this to Jetpack’s support system a couple of months ago (20 Oct 2014, ticket #1975657, Adam H. was on it).

Just wanted to say that I’m happy this is not a problem specific to one user :). Hope you (we) can solve this.

PS: I didn’t move my site, I don’t think it’s a server migration related problem.

It’s still a mystery I’m afraid, since we haven’t been able to reproduce in our own test installs, whether we use WordPress in English, German, or Turkish.

We’re still looking into it, and I’ll post again here as soon as I have some news.

Hey there,

did you find a solution (or the source of this ‘error’) for that weird thing?