WebP Problems

100% correct. The WordPress install is in the /brighton_/ sub-directory, with index.php pointing to ./brighton_/wp-blog-header.php as per WordPress instructions.

luckily, I have my dev site setup in a subdirectory, so it took all of 30 seconds to replicate your situation. And behold, webp breaks, something must be mismatched with the urls/paths. Off to find a fix…

Oh, now that’s just mean…

The get_home_url() function retrieves the setting that is labeled “Site Address (URL)”, and the get_site_url() function retrieves the one labeled “WordPress Address (URL)”. What?!?!?!

Well, at least I know what the fix is now…

In common.php, do a search for get_home_url, and replace it with get_site_url.

Back to the special characters issue. I want to make sure we have a good solid fix that isn’t going to break it for anyone else. Sooooo, to that end, can you add the slashes back in for the mb_convert_encoding() line, and remove them for the utf8_decode() line instead, and see if there is any difference? You mentioned something with linebreaks, so I’m particularly interested to see which function handles those better.

ALL FIXED!!! ??

Replaced the 3 occurrences of get_home_url with get_site_url, and my WebP’s are now all working (and jpegs being served to non-webp browsers).

Also swapped to the utf8_decode() but no difference on that – either/or has fixed the character issue and I think the line break problem is theme related, as it only occurs after a specific icon [shortcode].

Thank you for all your help getting this working 100% and hopefully it helps others down the line.

Would you mind helping me to track down the “Why” of the character encoding issue. I’d prefer it if we could auto-detect whatever situation causes the problem, instead of requiring the user to check yet another option to make it work. I don’t want to turn it on for all users either, as it converts special characters to html entities, which isn’t always desired.

Couple things come to mind to check for starters. First, there is a DB_CHARSET setting in your wp-config.php and a DB_COLLATE setting (usually utf8 and blank).
Second, I’d be curious if you can check and see what collation your actual database is using. If you have access to phpmyadmin or something of that nature, just a screenshot of the top level of your WP database should show the collation for all the tables.
Third, there are some php settings for encoding (mine are mostly blank) that you can display with the phpinfo() function. To view these settings, you can create a new file named test.php in either your web root, or your wordpress root, and put this in it:

<?php phpinfo(); ?>

Some folks are not comfortable having that much info about php posted to the world, so you can send me the link to the file you create with the phpinfo() function via https://ewww.io/contact-us/

Thanks!

Sent ??

Ok, so all that stuff looks fine, the only other thing I can think of is if your theme or another plugin is running some interference with the encoding. Would you be able to temporarily disable all plugins except EWWW, disable the mb_convert_encoding() and utf8_decode() lines (put slashes back in front of both of them), and see if the characters still get messed up?

If the characters are still corrupted, then the last resort is to change to one of the default themes like twenty fifteen, and see if that takes care of it.

Woah! That was a bit scary on a live site! Had to disable all and go back to the Twenty Fifteen site with EWWW disabled to get rid of character issue – Twenty Fifteen with EWWW enabled showed the odd characters again (this is with the common.php lines 182 and 184 commented out).

Also discovered commenting out 184 and un-commenting 182, STILL leaves a few character problems (for me, in the UK an apostrophe becomes a question mark).

If I comment out $buffer = utf8_decode( $buffer ); (currently line 182) and remove // from 184 ($buffer = mb_convert_encoding( $buffer, ‘HTML-ENTITIES’, ‘UTF-8’ );)… all character issues seem resolved.

:/

Ok, just to confirm that I’m reading you right: with all other plugins disabled, and using the default theme, you still had character issues if you did not use mb_convert_encoding()?

If that is the case, then it points us back to something on the backend causing issues. I don’t think it is PHP or MySQL, I’m curious if it could possibly be the locale setting of the server itself. Do you have shell access (ssh/console/command line) to the server?

Yes as best as I could tell that’s the case (re default theme and disabling plugins) – un-commenting (line 182) mb_convert_encoding() solved all character issues for us.

Here’s the locale response…

-bash-4.1$ locale
LANG=en_GB.UTF-8
LC_CTYPE=”en_GB.UTF-8″
LC_NUMERIC=”en_GB.UTF-8″
LC_TIME=”en_GB.UTF-8″
LC_COLLATE=”en_GB.UTF-8″
LC_MONETARY=”en_GB.UTF-8″
LC_MESSAGES=”en_GB.UTF-8″
LC_PAPER=”en_GB.UTF-8″
LC_NAME=”en_GB.UTF-8″
LC_ADDRESS=”en_GB.UTF-8″
LC_TELEPHONE=”en_GB.UTF-8″
LC_MEASUREMENT=”en_GB.UTF-8″
LC_IDENTIFICATION=”en_GB.UTF-8″
LC_ALL=

??

[still have the xml sitemap problem sadly – regular error logs showed nothing as far as I could see – so currently still Alt WebP disabled]

Changing my locale did nothing, I thought that might have been it, but since your locale is already utf-8 compatible, that makes sense. I’m going to do some more reading up on this issue and see if I can come up with any other ideas. At any rate, leaving that mb_convert_encoding() function enabled doesn’t seem to cause problems on my site, so I think we might be in the clear on this one.

Aha, stumbled across the culprit: https://www.glenscott.co.uk/blog/html5-character-encodings-and-domdocument-loadhtml-and-loadhtmlfile/. There are two factors in play.

1. For the loadHTML() function to properly find the encoding of your page, it needs one of two <meta> tags:

<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″>
OR
<meta charset=”utf-8″>

Newer themes that are HTML5 use the latter, whilst HTML 4.x themes use the longer declaration. Both the default theme, and the theme you use for your site are HTML5 and use the latter of the two.

2. There is a bug in libxml that only recognizes the first of those <meta> tags. It was fixed in libxml 2.8.0. My dev site happens to be running 2.8.0, whereas your site is running 2.7.6.

So, since you use the newer <meta> tag AND are running an “unfixed” version of libxml, the encoding is not detected properly, and it defaults to Latin1 or some such nonsense. Off to fix it in dev…

Ok, the encoding fix, and the xml fix are now both in dev for testing: https://downloads.www.ads-software.com/plugin/ewww-image-optimizer.zip

I’m on the cloud version – can I still use that zip or not? ??

Oh yeah, sorry about that: https://downloads.www.ads-software.com/plugin/ewww-image-optimizer-cloud.zip