TheRVgeeks

@zoonini – Correct. I’d rather not have the two spaces preserved when viewed on the front end… particularly the non-breaking space. When editing, sometimes the non-breaking space is retained when you’re moving content around or re-structuring at all… so then the text doesn’t wrap correctly on smaller screens.

Interesting that you’re seeing the behavior with just the Classic Editor activated. I’m using WP v6.1.1… but maybe something’s different about my staging environment. I’ll have to check again to see if maybe somehow I missed it happening.

Hi @zoonini – Thanks. Sorry I wasn’t more clear. These are seemingly accidental (or muscle memory) from old-school typing technique… putting the two spaces after a period. I don’t really want them to show as two spaces, but because the interface is changing two regular spaces into on regular and one non-breaking, they’re showing. Plus, the non-breaking spaces are sometimes being left behind and then mess up the flow of the text at various screen sizes.

I spooled up a staging version of my site and tried disabling all of the plugins except the Classic Editor… and that appears to have fixed it. Now, it’s just a matter of trying to identify which plugin(s) are causing the problem or the conflict.

If you have any other ideas about what I can try, that would be great. Otherwise, I’ll report back here if I can identify the source of the issue.

Thanks!

@alphawolf – Thanks for the quick response. Glad to know it’s in the pipeline at least. ??

Hi @michaelwilliamson, thanks for the reply. That’s what I thought should happen, too. But I’m not creating any bookmarks in my Google documents… all I’ve added are H1, H2, H3, etc tags for my headings. But when I save the document out as a .DOCX file and then import using Mammoth, there are anchor tags inserted before the text inside each heading tag.

Weird, right?!

Hey @sterndata – Thanks! I had done that (repeatedly) to no avail. Cleared the WP Rocket cache. Forced the OPCache clearing. Everything. NADA.

Strangely, at about 3 hours past the originally-scheduled publish time, it SEEMS like things may be working correctly. Still seems date-time related (like some kind of weirdness with DST change or something… even though the change to standard time isn’t due for about a month).

Thanks so much for the follow-up @shetheliving! Just updated the plugin and tested in Safari… <drum roll please>… AND IT’S WORKING!

Really appreciate the effort and for staying in touch to let me know how things were progressing!

Hi James,

Thanks for the update. I’d given up using Safari for the time being and switched to Firefox, since it doesn’t have the problem.

I just checked for any pending updates and didn’t see any, and I’m running Safari Version 14.1.1 (14611.2.7.1.6) on MacOS 10.14.6. I just went to a private browser window in Safari, logged in to the admin panel, and went to the Dashboard, Search Console, and Analytics tabs for Site Kit. Same issue. I’m still getting the “Failed to initialize NumberFormat…” error message.

Sorry I don’t have better news. But it IS possible this is just an issue for Safari on MacOS Mojave (I am two versions behind in Operating System).

Let me know if there’s anything else you’d like me to try. And I hope you have a great weekend (pretend this message didn’t come in, LOL)!

Hi James. Tested on my other laptop (also MacOS Mojave v10.14.6 with Safari v14.1 (14611.1.21.161.7)) and it has the exact same problem.

It works fine in Safari on iOS.

I tried disabling all Site Kit features other than Search Console and had the exact same error:

Failed to initialize NumberFormat since used feature is not supported in the linked ICU version

    in DataBlock
    in WPDashboardImpressions
    in WithWidgetComponentProps(WPDashboardImpressions)
    in div
    in WPDashboardWidgets
    in div
    in WPDashboardApp
    in RestoreSnapshots
    in ErrorHandler
    in Root

??
Thanks,
– John

Hi @jamesosborne,

Thanks so much for the continued follow-up. I do have a couple of extensions installed & active: 1Password, Grammarly for Safari, and Honey. There’s a fourth extension installed, but not active, for Parallels Desktop (it’s an “Open In I.E.” option that I don’t use).

I tried de-activating all three active extensions and testing… same issue.

I also checked my “Experimental Features” list… and couldn’t tell if I’d changed anything there, so I used the “Reset All To Defaults” option and tested again. Same issue. Get the errors when trying to view Site Kit data in the Main WP Dashboard or in Site Kit’s Dashboard.

Let me know if there’s anything more specific I can try.

Thanks!

Hi James. Just changed my system language (System Preferences / Language & Region) from “US” to “United Kingdom”. Rebooted the computer and checked the Site Kit page in Safari. Same issue, no change.

Do you think it’s a problem with ALL English language selections? Or is there somewhere else I should be changing the language selection (didn’t see one in Safari/Preferences).

Hi again, James.

Just used the Health Check & Troublshooting plugin (awesome tool, good to know about), and with JUST the Google Site Kit plugin enabled, the problem still exists when viewing in Safari 14.1

So… I’m guessing this is actually a result of that MacOS/Safari 14.1 bug and isn’t an issue with the Site Kit plugin (or conflict with any other plugin or theme).

Hope Apple releases a fix soon! ??

Thanks, James. I’ll give that a shot. But I’m wondering if it has anything to do with the bug in Safari 14.1 I just read about (https://appleinsider.com/articles/21/05/04/macos-bugs-causing-sporadic-browsing-issues-with-safari-firefox-others/)?

It’s mostly an issue with newer versions of MacOS, but apparently is still trouble for MacOS Mojave that I’m running.

Hi James,

Thanks for the follow-up.

1. I’ve submitted the form for the Site Health information.
2. No, it works in both Chrome and Firefox on MacOS
3. It happens for virtually all options for Site Kit: Dashboard, Search Console, and Analytics. Not for Adsense (not enabled) or Settings.

Let me know if there’s any other information I can provide to assist with troubleshooting.

Thanks!

Thanks @joyously! I now know the wisdom of that policy for themes in the WordPress Repository! And it hurts!!! I definitely feel like I’ve been locked into my theme, since switching from it is going to be a royal PITA! ??

I’ll take a look for a plugin that can convert the meta fields into content… but if you remember what you used, I’d appreciate a point in the right direction.

Wish I was better with SQL commands and queries… as this seems like something that could be handled that way (find posts where post-meta includes a meta_key of “_x_video_embed”… yada, yada, yada).

@noahstricker… thanks, glad it worked for you. It was most definitely NOT a user error… the plugin would NOT deactivate and would NOT delete until I deactivated EVERY plugin. But it’s gone now, so all’s well.