Emoticons & shortcodes parsed inside the editor when opening a post!
Quote from FTP on June 20, 2019, 11:08 amHi Thomas,
Is there a way to keep the emoticon BBcodes instead of the <img> url when a post is edited (I have to control)?
Because when we use personalized smilies and change from one plugin to another, or change the smiley files, all urls, so all emoticons saved this way are instantly broken 🙁
In my case, I’ve replaced TinyMCE Smiley Button+Classic smilies by TinyMCE Advanced.
All smilies saved as BBcodes are still properly displayed, but all the ones saved via <img> url are broken as the directory where the smilies are has changed.
Thanks!
Hi Thomas,
Is there a way to keep the emoticon BBcodes instead of the <img> url when a post is edited (I have to control)?
Because when we use personalized smilies and change from one plugin to another, or change the smiley files, all urls, so all emoticons saved this way are instantly broken 🙁
In my case, I’ve replaced TinyMCE Smiley Button+Classic smilies by TinyMCE Advanced.
All smilies saved as BBcodes are still properly displayed, but all the ones saved via <img> url are broken as the directory where the smilies are has changed.
Thanks!
Quote from Asgaros on June 20, 2019, 11:24 amHello @ftp
Asgaros Forum is not doing any parsing of smileys during post-processing. So I guess that the before-used extension automatically converted some of the BBcodes to images. In my plugin I dont have any control over what other extensions are doing in the editor, which means that I cant change anything on it. 🙁
Hello @ftp
Asgaros Forum is not doing any parsing of smileys during post-processing. So I guess that the before-used extension automatically converted some of the BBcodes to images. In my plugin I dont have any control over what other extensions are doing in the editor, which means that I cant change anything on it. 🙁
Quote from FTP on June 20, 2019, 11:52 amQuote from Asgaros on June 20, 2019, 11:24 amHello @ftp
Asgaros Forum is not doing any parsing of smileys during post-processing. So I guess that the before-used extension automatically converted some of the BBcodes to images.
No posts are first saved with the BBcodes. They are parsed and replaced by <img> when we edit a post. And of course if we save, the BBcodes are gone.
I’ll try to disable TinyMCE Advanced but it’s not linked to “the before-used extension” as those extensions have been deleted and this behavior continues with brand new posts. And the weird thing is when you edit Pages or Articles BBcodes are not replaced by <img>. Only in the forums.
Quote from Asgaros on June 20, 2019, 11:24 amHello @ftp
Asgaros Forum is not doing any parsing of smileys during post-processing. So I guess that the before-used extension automatically converted some of the BBcodes to images.
No posts are first saved with the BBcodes. They are parsed and replaced by <img> when we edit a post. And of course if we save, the BBcodes are gone.
I’ll try to disable TinyMCE Advanced but it’s not linked to “the before-used extension” as those extensions have been deleted and this behavior continues with brand new posts. And the weird thing is when you edit Pages or Articles BBcodes are not replaced by <img>. Only in the forums.
Quote from FTP on June 20, 2019, 12:04 pmQuote from FTP on June 20, 2019, 11:52 amI’ll try to disable TinyMCE Advanced but it’s not linked to “the before-used extension” as those extensions have been deleted and this behavior continues with brand new posts. And the weird thing is when you edit Pages or Articles BBcodes are not replaced by <img>. Only in the forums.
Yup, I confirm, there’s something specific with the forum.
Without any specific extension, if you add emoticons on a WP Page or Article, save and edit the Page or Article, you will see the emoticon BBcode, not its image.
But do the same on the forum, including this support forum, save and edit a post, you will see the emoticon image this time, not the BBcode :-/
Quote from FTP on June 20, 2019, 11:52 amI’ll try to disable TinyMCE Advanced but it’s not linked to “the before-used extension” as those extensions have been deleted and this behavior continues with brand new posts. And the weird thing is when you edit Pages or Articles BBcodes are not replaced by <img>. Only in the forums.
Yup, I confirm, there’s something specific with the forum.
Without any specific extension, if you add emoticons on a WP Page or Article, save and edit the Page or Article, you will see the emoticon BBcode, not its image.
But do the same on the forum, including this support forum, save and edit a post, you will see the emoticon image this time, not the BBcode :-/
Quote from Asgaros on June 20, 2019, 12:52 pmHello again @ftp
It seems the conversion is done automatically by WordPress, see the following article:
https://wordpress.org/support/article/using-smilies/#how-does-wordpress-handle-smileys
They also mention that this functionality can be disabled by using the following plugin:
Hello again @ftp
It seems the conversion is done automatically by WordPress, see the following article:
https://wordpress.org/support/article/using-smilies/#how-does-wordpress-handle-smileys
They also mention that this functionality can be disabled by using the following plugin:
Quote from FTP on June 20, 2019, 1:04 pmQuote from Asgaros on June 20, 2019, 12:52 pmIt seems the conversion is done automatically by WordPress, see the following article:
https://wordpress.org/support/article/using-smilies/#how-does-wordpress-handle-smileys
Parsing to display the post is one thing.
Parsing to edit the post is another thing.Currently:
WP Page/Articles… Parse to view: Yes – Parse to edit: No
Asgaros… Parse to view: Yes – Parse to edit: Yes -> conséquence: BBcode lost and hard coded img path saved in the DB
Quote from Asgaros on June 20, 2019, 12:52 pm
They also mention that this functionality can be disabled by using the following plugin:
That’s not what I would like. This extension disable all smiley parsing. They are not visible as image in post any more.
On my side, I would just like the BBcodes to stay BBcodes when we edit posts, so the img path in never hard coded in the DB. In fact, that Asgaros editing behave like WP editing.As there’s one question: why is the behavior different for the Asgaros/Front-end editor than the admin editor (Page/Articles)?
Quote from Asgaros on June 20, 2019, 12:52 pmIt seems the conversion is done automatically by WordPress, see the following article:
https://wordpress.org/support/article/using-smilies/#how-does-wordpress-handle-smileys
Parsing to display the post is one thing.
Parsing to edit the post is another thing.
Currently:
WP Page/Articles… Parse to view: Yes – Parse to edit: No
Asgaros… Parse to view: Yes – Parse to edit: Yes -> conséquence: BBcode lost and hard coded img path saved in the DB
Quote from Asgaros on June 20, 2019, 12:52 pm
They also mention that this functionality can be disabled by using the following plugin:
That’s not what I would like. This extension disable all smiley parsing. They are not visible as image in post any more.
On my side, I would just like the BBcodes to stay BBcodes when we edit posts, so the img path in never hard coded in the DB. In fact, that Asgaros editing behave like WP editing.
As there’s one question: why is the behavior different for the Asgaros/Front-end editor than the admin editor (Page/Articles)?
Quote from Asgaros on June 20, 2019, 1:34 pmQuote from FTP on June 20, 2019, 1:04 pmAs there’s one question: why is the behavior different for the Asgaros/Front-end editor than the admin editor (Page/Articles)?
@ftp Because in the frontend the wpemoji-plugin is loaded automatically by WordPress for the TinyMCE-editor. You can prevent this by adding the following code to your themes functions.php file:
function disable_emojis_tinymce($plugins) { if (is_array($plugins)) { return array_diff($plugins, array('wpemoji')); } else { return array(); } } add_filter('tiny_mce_plugins', 'disable_emojis_tinymce');
Quote from FTP on June 20, 2019, 1:04 pmAs there’s one question: why is the behavior different for the Asgaros/Front-end editor than the admin editor (Page/Articles)?
@ftp Because in the frontend the wpemoji-plugin is loaded automatically by WordPress for the TinyMCE-editor. You can prevent this by adding the following code to your themes functions.php file:
function disable_emojis_tinymce($plugins) {
if (is_array($plugins)) {
return array_diff($plugins, array('wpemoji'));
} else {
return array();
}
}
add_filter('tiny_mce_plugins', 'disable_emojis_tinymce');
Quote from FTP on June 20, 2019, 2:06 pmHum… doesn’t work.
Still saved in the DB as BBcode but it’s the image that’s displayed when editing.
So the parsing is still active. Even TinyMCE Advanced disabled.
Hum… doesn’t work.
Still saved in the DB as BBcode but it’s the image that’s displayed when editing.
So the parsing is still active. Even TinyMCE Advanced disabled.
Quote from Asgaros on June 20, 2019, 2:23 pmHave you tried to clear the browser-cache afterwards? If its still converted back to an image, then some other plugin or your theme is adding some additional parsing-logic for smileys.
Have you tried to clear the browser-cache afterwards? If its still converted back to an image, then some other plugin or your theme is adding some additional parsing-logic for smileys.
Quote from FTP on June 20, 2019, 3:49 pmHave you tried to clear the browser-cache afterwards?
Yes I did.
And I even have more reasons to get rid of this parsing now because I realised it parses everything!
Smilies, but also short-codes (like font Better Font Awesome or User Shortcodes) 🙁
https://asgaros.com/support/topic/how-to-set-in-a-post-an-hyperlink-using-the-current-user-id/#postid-8396I already noticed this issue for Better Font Awesome short codes a long time ago but did not understood what was happening at that time.
Have you tried to clear the browser-cache afterwards?
Yes I did.
And I even have more reasons to get rid of this parsing now because I realised it parses everything!
Smilies, but also short-codes (like font Better Font Awesome or User Shortcodes) 🙁
https://asgaros.com/support/topic/how-to-set-in-a-post-an-hyperlink-using-the-current-user-id/#postid-8396
I already noticed this issue for Better Font Awesome short codes a long time ago but did not understood what was happening at that time.