• Resolved Bob Easton

    (@bobeaston)


    Black diamond with white question mark inside. {Sorry, I don’t know the precise code, and it would be nice to attach a screenshot.}

    This unusual character shows up after a site uses FVP HTML minification. I haven’t yet narrowed it down precisely, but it looks like it occurs when the HTML has a string that includes 2 successive space characters followed by the STRONG element.

    Example at: https://www.bob-easton.com/images/diamonds.png
    HTML for that example:

    <p style="text-align: center;"><span style="color: #000080;">At?<strong>Dunkin' Donuts,</strong> you see a new spelling: ?<strong>donut</strong>.</span>
    <span style="color: #000080;">The standard spelling, however, is still <strong>doughnut</strong>.</span></p>

    Thanks for any suggestions. For now, I won’t use HTML minification.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Raul P.

    (@alignak)

    Hi,

    That usually only ever happens if you have mixed encoding’s on your html, for example, the page could be declared as UTF-8 but you saved some data as latin1. It could also be that you changed the encoding on the database sometime in the pass, from latin1 to utf8.

    The 2 spaces are not actual spaces. One of them is an invisible character that it’s not being detected by PHP when doing the minification, so the server marks it with a black diamond and a question mark (unknown character).

    It will show up as a white space without minification, because the browser can read each letter separately and apply different encoding to different sections.

    This used to happen a lot a few years ago, when people copy paste (or scrape) content from other documents or websites. Now it doesn’t usually happen, because more sites use utf8 encoding.

    The solution would be to edit the post, copy paste the content to a txt file, and copy paste it back to the editor. That would ensure the correct encoding, as the browser will do that conversion as you copy paste.

    Please try it on one of the posts having that issue and it should be gone, hopefully.

    Thread Starter Bob Easton

    (@bobeaston)

    THANKS Raul!
    What an excellent response! Makes sense.

    Ironically, in an effort to further diagnose, I made a new local test copy of the site this morning and could not recreate the problem. All the troublesome pages are clean now. ?? …and you have given me great advice on how to clear any remnants.

    BTW, MEGA-Kudos for how well FVP recognizes when to purge a cached element.

    Thanks again!
    P.S. With many years of WordPress experience and very infrequent needs to post support questions, I have never experienced a plug-in developer so quick to respond. Impressive!

    Plugin Author Raul P.

    (@alignak)

    I made a new local test copy of the site this morning and could not recreate the problem.

    That could happen for a number of reasons, for example if the server you installed the staging runs more up to date php and mysql.

    You could try to export the database from the staging and import it again on the live site (or push live from staging, etc). It’s likely database related, but maybe importing/exporting drops those invisible chars somehow.

    Hope it helps.
    Thanks

    Thread Starter Bob Easton

    (@bobeaston)

    Yes, there are diffs between the server levels.

    Thanks again. You’ve certainly been a big help.
    Wherever you are in this pandemic stricken world, stay well.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Unusual characters after HTML minify’ is closed to new replies.