Very strange smiley performance following upgrade

[Dave J]

Go to Admin>Forum>Smileys and Message Icons

If not done already go to Settings and tick the box for 'Enable customized smileys' click on 'Save'

Now you will see that there are new options in the heading. Click on 'Edit Smileys' then scroll down to the 'cry'  smiley and click on 'Modify' on the right hand side.

In the box that opens change the code to  :c( click on 'Save Changes'and see if that works OK. Check to see you don't have any other smileys with that code.

Is this the proposed work-around? If so it leaves me behind big time 
 Is the real fix included in here or is this forum somehow immune?

The post I made was to help out Wellwisher who only quoted one smiley not working.

It's also worth noting that this forum uses SMF2.1 and therefore might have some coding that's different to what you're using in 2.0.19.

[weus]

Yep, perfect.  And yep, it's a bug.

Appears to only impact smilies, and specifically smilies that use apostrophies in the code.  For most of us, that's just the cry smiley.

Logged internally, #254

To add to this issue, on our forum, it also happens when using code formatting like

Code (foo) Select Expand

'some quoted text'

it gets rendered like:

'some quoted text'

[Dave J]

Yep, perfect.  And yep, it's a bug.

Appears to only impact smilies, and specifically smilies that use apostrophies in the code.  For most of us, that's just the cry smiley.

Logged internally, #254

To add to this issue, on our forum, it also happens when using code formatting like

Code (foo) Select Expand

'some quoted text'

it gets rendered like:

'some quoted text'

The code 39 is ASCII for the apostrohphe but instead of being rendered as ' it's give the code for it.

[Arantor]

This would imply that there is a second layer of encoding going on - one layer is normal, two is not.

This is also why I asked about quick reply vs normal reply because there's definitely been issues historically about full reply and quick reply handling such things differently.

[weus]

The code 39 is ASCII for the apostrohphe but instead of being rendered as ' it's give the code for it.

I know. Our forum is about software development, so the code formatting tags are used a lot in code samples.
Strings are delimited by an apostrohphe and are rendered useless this way

Marc

[shawnb61]

I know. Our forum is about software development, so the code formatting tags are used a lot in code samples.
Strings are delimited by an apostrohphe and are rendered useless this way

Marc

Marc - I cannot reproduce this.  (Though I can reproduce the cry smiley issue.)

Php version? Is the forum utf8? Are other bbc codes impacted, or only the code bbc?

[weus]

We were running 2.0.18 without problems. On Dec 24 I updated the forum to 2.0.19 and last week I got user reports that the code formatting was broken. Older posts are not affected.
It only happens when using code=you_name_it tags are used (any value triggers it). A plain code tag renders ok.
php version is 5.6.40
to render different code languages we use cb|GeSHi-mod 1.2
site: hxxp:forum.lazarus.freepascal.org [nonactive]
example: hxxp:forum.lazarus.freepascal.org/index.php/topic,57672.0.html [nonactive]

Thanks Marc

[weus]

From a little analyze I did before I came here:

The only relevant change of the update seems to be in Load.php.

The update replaces

Code Select Expand

  $string = preg_replace_callback('~(&#(\d{1,7}|x[0-9a-fA-F]{1,6});)~', 'entity_fix__callback', $string);
with

Code Select Expand

  $string = preg_replace_callback('~(&' . (!empty($double) ? '(?:amp;)?' : '') . '#(\d{1,7}|x[0-9a-fA-F]{1,6});)~', 'entity_fix__callback', $string);

in the new case, depending on the value of $double, the expression is either

Code Select Expand

  $string = preg_replace_callback('~(&(?:amp;)?#(\d{1,7}|x[0-9a-fA-F]{1,6});)~', 'entity_fix__callback', $string);
or

Code Select Expand

  $string = preg_replace_callback('~(&#(\d{1,7}|x[0-9a-fA-F]{1,6});)~', 'entity_fix__callback', $string);

Now I'm not a regex king, so I don't know if the true part is the same as the old code, but textual they differ.

Marc
 

[shawnb61]

I am not seeing that behavior anywhere.  I've tried php 8, php 7 & php 5.6.  All under 2.0.19.  Screenshot below.

The root of the cry smiley issue is that the entities are being stored slightly differently - ' vs '.  Outside of smileys, we aren't seeing issues, as both versions are valid.

But anywhere you have code that parses this byte-by-byte, such as the smiley code, must now account for either ' or '.

Are you sure the issue isn't your mod?  Can you try it without your mod?

Do your code=you_name_it tags identify the language?

[shawnb61]

The code= issue is definitely related to the mod. 

It completely rewrote the code= logic being invoked here.  I suspect the fix will be simple, but should likely be discussed here, so other folks who use the mod can benefit:
https://www.simplemachines.org/community/index.php?topic=440609.0

Note this mod hasn't been able to install clean for a while.

[Wellwisher]

I don't know if this helps but a month ago I had to run "Convert HTML-entities to UTF-8 characters". As my members complained that they could no longer "copy & paste" large texts from random webpages on the internet into a post. They said, once they pasted the large snippet of text and clicked on post, only the first sentence would show in the post. However if the members typed the full texted in, the forum would save it.

That's when I did a bit of googling and found running the following SMF task: "Convert HTML-entities to UTF-8 characters" solved the issue.
Once this was done, members were able to copy and paste texts from other websites into the forum. However some of the words in the titles and body which were already posted were changed/ converted into the weird symbols.

[Roger2]

It's also worth noting that this forum uses SMF2.1 and therefore might have some coding that's different to what you're using in 2.0.19.

That explains a lot.

How easy would it be for me to import lock stock and barrel my whole forum into a vanilla 2.1? Or would that create more problems than it would solve? I hasten to add I'd be on my own as the GoDaddy Control Panel easy-install is at v2.0.18

[weus]

The code= issue is definitely related to the mod. 

It completely rewrote the code= logic being invoked here.  I suspect the fix will be simple, but should likely be discussed here, so other folks who use the mod can benefit:
https://www.simplemachines.org/community/index.php?topic=440609.0

Note this mod hasn't been able to install clean for a while.

We've been using this mod since the early days of our forum (smf 1.0 or something like that). So we didn't need to install it for a while.

Anyway I'll continue on the other topic (or we'll switch to another highlighter)

Thanks Marc

[Turrican3]

I'm experiencing the exact same issue after upgrading to 2.0.19 (was on 2.0.18 until yesterday), the "cry" emoticon doesn't get parsed in posts, but it does when quoted.

The aforementioned mod though is NOT installed on my forum... any suggestions/fix? If possible, I'd happily keep the emoticon code so that existing post won't break, but if it's too complex I suppose I'll just accept it.

[Turrican3]

Ok just upgraded to SMF 2.1.1 and the smiley is working again as intended.