Emotify v2.0.5 on Vanilla v2.1: Smiley \:D/ does not show

MasterOne

The following smiley with the moving finger (it's the third from the right in the second line from the bottom) is not shown:

When I click it in the smiley-map, it enters the following into the text entry area:

When I post the comment the backslash disappears, which is the reason why the smiley is not displayed:

An issue with the backslash being interpreted as escape?

MasterOne

When I write that smiley as

\\:D/

it gets displayed as

\:D/

but the image is not shown either.

P.S. Here on Vanilla Forums the same problem exists when entering the backslash, which disappears once the comment is saved. The first smiley text in this comment is written with four backslashes, the second one with two, as you can see the first is only displayed with two backslashes, the second one with one.

vrijvlinder

Here is a list of the smileys that work

http://benalman.com/code/projects/javascript-emotify/examples/emotify/

for the ButtonBar editor use

\:D/ not the other . It ignores the first slash and posts only the second part anyway.

In any event both work for me even though one slash is removed. However it will post one slash before the icon if I use two slashes.

MasterOne

@vrijvlinder‌, that smiley is in the list that work on that web page. The code is there, the image is there, but is does not work.

Whatever I try, that smiley is not shown. The weird thing is, it's not the only one starting with a backslash but the other works:

class.emotify.plugin.php

'\\:D/' => '69', -> shown as \:D/ instead of

'\\m/' => '111', -> shown correctly as

I guess you do not use the ButtonBar Editor with Markdown if you tell it's working for you?

vrijvlinder

I am using ButtonBar with html . Try changing to html and see if then it works?

MasterOne

Indeed, it's working with SimpleHtml as input method, so the issue has something to do with Markdown.

peregrine

yes double backslashes with buttonbar don't seem to work with buttonbar - markdown - emoticon.

what you could do if your users want the gif to appear and don't manually enter :D/ or \:D/

you could modify the class.emotify.plugin.php

// '\:D/' => '69',
'DA:O'=> '69',

now clicking on the

would properly work by clicking on the dropdown emoticon

and the new combo would be DA:O (obviouly not in the emoticon parlance) but if the goal is the gif, it will then dispaly a gif in markdown

you would do something similar make up a key combo that users would be unlikely to do and use it for the 111

but you should file this on github that these two emoticons don't work with markdown.

vrijvlinder

@peregrine Check out this Dingus

http://daringfireball.net/projects/markdown/dingus

MasterOne

What puzzles me is that the logic behind analyzing which text to replace with a GIF is different between that Ben Alman shows on his site and the Vanilla plugin implementation, because the order of text definitions to GIF is in one line down from 1 to 115 + GIFs with text as name alphabetically, whereas it's disordered in class.emotify.plugin.php.

I tried to rearrange the array but that does not work, because the Emotify plugin does not seem to honor the space in front and after separation what Ben Alman mentions:

The only rule is that each smiley must be surrounded by whitespace!

When changing the order in the array, it does not work any more as supposed to because the first match. So if \:) comes before \:)) in the array, entering \:)) gets identified and replaced by the \:) smiley (tried to escape the smiley with \ so that it doesn't get replaced by the GIFs here).

I already took a look but I don't understand the logic behind public static function DoEmoticons($Text) (which is ported from the do_smilies function of punbb 1.3.5, as the comment says).

I'd prefer to have the GIFs in an ordered line down in the array with fitting alternative smiley definitions as seen in Ben Alman's script, and then would add new GIFs my forum members would like to have to the end of the list.

P.S. Some of my forum members often forget the leading space before the smiley, and it does not get recognized then. I don't know if there ever was an implementation that does not require a leading space and if that can be / should be allowed to nevertheless to work. I'll try to play around with this when I find some spare time, but not understanding how this really works I can only approach it with some trial and error. Any hints are highly appreciated.

peregrine

@MasterOne said:
When I write that smiley as

\\:D/

it gets displayed as

\:D/

but the image is not shown either.

P.S. Here on Vanilla Forums the same problem exists when entering the backslash, which disappears once the comment is saved. The first smiley text in this comment is written with four backslashes, the second one with two, as you can see the first is only displayed with two backslashes, the second one with one.

there is a bug in in class emotify.plugin.php add another line below

\:D/
:D/
/

I'd prefer to have the GIFs in an ordered line down in the array with fitting alternative smiley definitions as seen in Ben Alman's script, and then would add new GIFs my forum members would like to have to the end of the list.

my mind-reading ability of which and where and what is not in top form today.

it's quite simple to put what ever gifs you want. match the number in the css for the numbered.gifs in the desing image folder.

if you want to order array by gif number. natural sort will work best. around line 260.

ksort($Emoticons);
$Emoticons = array_flip($Emoticons);

selecting by white space is better:) consider an emoticon as a word! they should too in the english language words are separated by spaces. rationalization.

but change this line in the look behind.

"#(?<=[<\s])".preg_quote($Key, '#')."(?=\W)#m",

to

"#(?<=[<\s\w])".preg_quote($Key, '#')."(?=\W)#m",

if you want to ignore white space.

MasterOne

@peregrine, the problem is that Markdown does something with the backslash, whatever I try with \\:D/ or \\\:D/ that smiley is just not shown, whereas \\m/ (which gets inserted as \m/ shows without modification of class.emotify.plugin.php.

When I click the appropriate smileys from the drop down for \\:D/ or \\m/ they get inserted as \:D/ and \m/. The \m/ works even with only having \\m/ in the array, whereas \:D/ doesn't (nor does \\:D/, \\\:D/, \\\\:D/ and so on).

I didn't mean to sort the output of $Emoticons but the order in the array definition of public static function GetEmoticons(), which I tried but didn't work because there seems to be a bug in the function that identifies the smileys. The author of that plugin did not fix that bug but changed the order in the array instead, which is why they are not in line 1, 2, 3, 4, 5, ... but

    public static function GetEmoticons() {
        return array(
            ':)]' => '100',
            ';))' => '71',
            ':)>-' => '67',
            ':)>-' => '67',
            ':))' => '21',
            ':)' => '1',
            and so on

If you change the order like this:

    public static function GetEmoticons() {
        return array(
            ':)' => '1',
            ':)]' => '100',
            ';))' => '71',
            ':)>-' => '67',
            ':)>-' => '67',
            ':))' => '21',
            and so on

it does not work, because if you enter any smiley that begins with : ) (like : )], : )>- or : ))) it gets matched and identified as : ) smiley (I had to put a space after the colon to not show the smiley here instead).

peregrine

don't sort the order in the array. and if you add the fixes I suggested the two emoticons will work.

as well as something like thiswithnospace:)

I stand by what I said for the fixes.- leave the order as it came in the plugin, just add the two lines.

    '\\:D/' => '69',
    '\\\:D/' => '69', // add this line
    after line 111 or so
    '\\m/' => '111',
    '\\\m/' => '111',// add this line

if you want to ignore white space. likethis:) the smiley will show up in both places with change.

"#(?<=[<\s])".preg_quote($Key, '#')."(?=\W)#m",

to

"#(?<=[<\s\w])".preg_quote($Key, '#')."(?=\W)#m",

if you want to ignore white space.

MasterOne

@peregrine said:
don't sort the order in the array. and if you add the fixes I suggested the two emoticons will work.

I tried that:

'\\:D/' => '69',
'\\\:D/' => '69', // add this line

and it does not work.

The other:

'\\m/' => '111',
'\\\m/' => '111',// add this line

is not necessary, because although clicking on the appropriate icon in the drop-down enters \m/ instead of \\m/ it nevertheless just works, which is what made me curious. There is definitely something about the leading backslash and Markdown, as well as the function that handles the smiley placement, which is what I tried to explain with my last comment.

It really is not that big of an issue, the problem with \\:D/ can be solved by replacing it with something else (DA:O), smiley 111 hasn't been an issue anyway, and adding custom smileys is just about adding new definitions to the end of the array.