Hi,
The only way to be certain is to disable FVM and see if the chars are still there.
If they are, it’s not FVM related.
Bare in mind that while utf8 chars “may look fine” on the browser, manually setting those with utf8 might actually break them (invisible chars).
One quick way to fix those is to download a dump of your database and save it on your PC. Open it with notepad++ and note the encoding in the bottom right.
If it’s utf-8, you’re fine.
If it’s something else, open a new file and set the encoding to UTF-8 without BOM.
Then, copy paste to the new document and save (look for the funny chars just in case).
Then restore that file with phpmyadmin and the encoding errors should be gone.
Also note, some of your template files (php) may be wrongly encoded.
You can do the same with notepad++ and check for the right encoding.
Either way, make a full backup before any changes.
—
The only possible option that I can think off, would be the html minification (which you can disable on the settings) that uses PHP Minify (a third party library) to minify HTML… but I don’t think that’s it.
I think your conversion from latin1 to utf8 might have not been done properly.
Also note, there are differences between the several utf8 types on mysql…
Hey Raul
thanks for your answer and tips.
I checked the database. I even did a backup, duplicate it (with the content) and force it as utf8 (instead of utf8mb4) encodings. I checked the fields inside, they are fine the “à” character is correctly encoded a “à” (in fact this is the single character for which I have problems).
my wp-config is define(‘DB_CHARSET’, ‘utf8mb4’); define(‘DB_COLLATE’, ”);
I restored to snapshot with the version Version 2.1.7. all is fine.
once I upgrade to 2.2.0 the problems comes back the “à” is converted to “�”.
I will continue checking.
I tried this on firefox and safari, and ensured the browser agent are the default ones. I also force cleaned the caches (both browser and FVM), rebooted the apache servers. I tried on the different configs: apache 2.2, and 2.4; php 5.6 and 7.0.
I would say is not very very problematic, I keep currently keep the version 2.1.7, I would just be happy to understand why the update could cause this pb.
i will continue searching and backup, migrate to 2.2.0, deactivate the plugin.
best regards,
B
did you try to disable the html minification on v2.2.0 and see if it makes any difference?
Thanks a lot Sir 🙂
following your advice, I found where from it came 🙂
when updating to 220 I get this (for example): “faciles � installer grâce �”
I checked the conf. the following was activated:
[x] Use the alternative HTML minification [ Select this, if you have some problem with some spaces disappearing ]
I deactivated the option, and miracle 🙂 all came back to normal
“faciles à installer grâce à”
thanks again for your quick answer.
best regards,
B
Hi, somehow you were using the alternative html minification system, but if the default works fine, you should use it instead.
I pushed an update today that should fix the funny chars when using the alternative html minification. Can you please try to select that option again temporarily (no need to purge the cache) and see if it still breaks your accents?
You should deselect it back, when you tested this.
Thanks,
Raul
Hi Raul,
All seems working perfectly.
I checked 10-15 pages using both methods,
I saw (correctly displayed) the following é è à â. No ugly <?> character displayed in any of the pages checked.
Thanks a lot Sir !
best regards,
B
