Posting articles from Chromebook doesn't work as intended

I’ve published a couple of articles on a website that is currently protected with a login page (.htaccess + .htpasswd), and they all work wonderful. On the frontpage it shows the short version of the article, an image with around 25 words, and in the article itself it shows nice blocks of text.

And today I’ve received my Chromebook and published the first article on it. And then I noticed something weird. On that same frontpage where other articles have images + around 25 words, the article that I’ve published from the Chromebook shows 40 words on the frontpage, which looks a bit silly next to others with less words. Also in the articles themselves, lines just break off when there is still enough space for other words.

I’ve checked the text-version of the article and it doesn’t show any HTML-code that might be responsible, nor does it show any break-offs. It’s just the visual designer and the frontpage that show discrepancies.

To make it even more weird, I went as far as to check the ‘published’ (so not the ‘inherit’) article under de ‘wp_posts’ table in the database to see if there’s anything spooky going on that WordPress doesn’t show. You guessed it, nothing to find there either. I think that it’s meta-posts information, but I can’t be sure. Weird thing is that articles published on a Windows 10 article work just fine.

What am I missing here?

The ‘Block 6’ is being used on the frontpage with Visual Composer. Four articles are shown in here. After I’ve published one article on my Chromebook, three of them had 25 words and one of them 40. In the article published on the Chromebook, sentences also break off like described in my previous message, without any code in de text editor to make sense out of it. The frontpage setup is fully setup according to your documentation and based on one of the installed demo’s.

Hey Catalin,

Thank you for your response. I’ve currently republished the article from another computer so I can’t make any screenshots. I will publish a new one this evening from the Chromebook and will make screenshots of it if the problem comes back. I will then send you an e-mail with them.

Have a great day!

I’ve found the cause of the issue. It happens whenever you use Word Online (Office 365) to write articles and then copy that into the WordPress writing area. Even though no additional code can be found in the text-editor (in which all the HTML-code can be found), it still messes up the article. Somehow it also bypasses the 25-word rule. Don’t ask me how that’s possible, but it apparently is. Anyway, from now on I’m using Google Docs on Chrombook, because that one doesn’t seem to have the issue. Word on Windows 10 (the application, not the online version) works perfect though.

Anyway, this topic can be closed. Thanks anyway for your quick answer and hopefully you can do something with the information provided above for other customers.

Enjoy your evening.

Dunno if this helps, but with Word Online and WP, I found you would need to first do a ‘save as’ to UTF-8 with character substitution as a .txt file; then copy THAT file text into WP editor in the text mode.

That’s an interesting piece of information. I suppose Word Online uses character encoding that gives weird results once entered directly into WordPress. It seems like a bit of hassle to get Word Online to save it into a TXT-file with UTF-8 first, before putting it in an article, but it’s nice to know there is a workaround just in case.

Thanks and have a great day.

Yeah. Microsoft XML encoding for web version appears different than the home perpetual version so it seems the content box built-in to WP can’t “convert” properly using the visual editor.

Likely worth posting a note to github repo for WP development, as issue with the TinyMCE editor, and not any theme element.