Emoticons & shortcodes parsed inside the editor when opening a post!
Quote from FTP on June 20, 2019, 4:19 pmThis time I’ve even disabled all the extensions except Asgaros and it still parse 🙁
So providing your code is correct, it’s either the theme or I’ve modified some code somewhere.
I’ll check both.
This time I’ve even disabled all the extensions except Asgaros and it still parse 🙁
So providing your code is correct, it’s either the theme or I’ve modified some code somewhere.
I’ll check both.
Quote from FTP on June 20, 2019, 4:48 pmQuote from FTP on June 20, 2019, 4:19 pmSo providing your code is correct, it’s either the theme or I’ve modified some code somewhere.
I’ll check both.It’s not any modification in files. My WP files are 100% identical to a brand new archive.
There only additional files for the plugins and theme.So now maybe OceanWP…
Quote from FTP on June 20, 2019, 4:19 pmSo providing your code is correct, it’s either the theme or I’ve modified some code somewhere.
I’ll check both.
It’s not any modification in files. My WP files are 100% identical to a brand new archive.
There only additional files for the plugins and theme.
So now maybe OceanWP…
Quote from Asgaros on June 20, 2019, 4:54 pm@ftp Also test it with a new post where you add a new BBCode smiley. Otherwise it could be possible that some logic already converted the content on-the-fly during the saving-process and saved it inside the database as an image-tag instead as BBCode – in that case the provided code would have no effect anymore at all.
@ftp Also test it with a new post where you add a new BBCode smiley. Otherwise it could be possible that some logic already converted the content on-the-fly during the saving-process and saved it inside the database as an image-tag instead as BBCode – in that case the provided code would have no effect anymore at all.
Quote from FTP on June 20, 2019, 6:20 pmQuote from Asgaros on June 20, 2019, 4:54 pm@ftp Also test it with a new post where you add a new BBCode smiley. Otherwise it could be possible that some logic already converted the content on-the-fly during the saving-process and saved it inside the database as an image-tag instead as BBCode – in that case the provided code would have no effect anymore at all.
Nope it’s not that. I do test with new smilies and I even verify that in the DB I indeed only have the BBcode.
It’s definitively converted right when we click on the Edit button. We can even see it… the url is extremely quickly displayed before the post is displayed in its final state.And once again, my WP files are clean and I disabled all my extensions! 🙁
And so far I can’t find anything in the theme, but I’ll have to switch to another one to see what happen.
Quote from Asgaros on June 20, 2019, 4:54 pm@ftp Also test it with a new post where you add a new BBCode smiley. Otherwise it could be possible that some logic already converted the content on-the-fly during the saving-process and saved it inside the database as an image-tag instead as BBCode – in that case the provided code would have no effect anymore at all.
Nope it’s not that. I do test with new smilies and I even verify that in the DB I indeed only have the BBcode.
It’s definitively converted right when we click on the Edit button. We can even see it… the url is extremely quickly displayed before the post is displayed in its final state.
And once again, my WP files are clean and I disabled all my extensions! 🙁
And so far I can’t find anything in the theme, but I’ll have to switch to another one to see what happen.
Quote from FTP on June 20, 2019, 6:54 pmEven changing the theme keeps the same behaviour.
Are you sure your code is the right one? 🙁
Next step I’ll try it on a fresh install of WP and we’ll see.
Even changing the theme keeps the same behaviour.
Are you sure your code is the right one? 🙁
Next step I’ll try it on a fresh install of WP and we’ll see.
Quote from Asgaros on June 20, 2019, 7:13 pmMh, you are right. Actually the code is not working (I added the smiley at the beginning of the post, so it didnt get parsed).
I have no idea what is causing this. In the plugin I directly pass the string from the database to the wp_editor() function – nothing more. I also cant find any specific hints for this problem on the internet so I can only suggest you to ask in the official WordPress support-forums. Maybe they have an idea which internal function is causing this.
Edit: Even the Disable Emojis (GDPR friendly) plugin is not working.
Mh, you are right. Actually the code is not working (I added the smiley at the beginning of the post, so it didnt get parsed).
I have no idea what is causing this. In the plugin I directly pass the string from the database to the wp_editor() function – nothing more. I also cant find any specific hints for this problem on the internet so I can only suggest you to ask in the official WordPress support-forums. Maybe they have an idea which internal function is causing this.
Edit: Even the Disable Emojis (GDPR friendly) plugin is not working.
Quote from Asgaros on June 20, 2019, 7:20 pm@ftp Actually it seems the emojis are getting added/converted automatically by the browser. When you check out the sourcecode in Google Chrome you cant see any image-tag – but instead there is an emoticon directly inside of the sourcecode.
@ftp Actually it seems the emojis are getting added/converted automatically by the browser. When you check out the sourcecode in Google Chrome you cant see any image-tag – but instead there is an emoticon directly inside of the sourcecode.
Uploaded files:
Quote from FTP on June 20, 2019, 7:53 pmQuote from Asgaros on June 20, 2019, 7:20 pm@ftp Actually it seems the emojis are getting added/converted automatically by the browser. When you check out the sourcecode in Google Chrome you cant see any image-tag – but instead there is an emoticon directly inside of the sourcecode.
Good you reproduced the issue.
On Firefox I have the same behaviour.But…
- it’s not the same behaviour in the other editors for pages & articles
- even short codes from different extensions are parsed
It’s really a mystery so far and a real problem. The editing becomes complicated and it adds hard coded paths in the DB.
Quote from Asgaros on June 20, 2019, 7:20 pm@ftp Actually it seems the emojis are getting added/converted automatically by the browser. When you check out the sourcecode in Google Chrome you cant see any image-tag – but instead there is an emoticon directly inside of the sourcecode.
Good you reproduced the issue.
On Firefox I have the same behaviour.
But…
- it’s not the same behaviour in the other editors for pages & articles
- even short codes from different extensions are parsed
It’s really a mystery so far and a real problem. The editing becomes complicated and it adds hard coded paths in the DB.
Quote from Asgaros on June 20, 2019, 8:33 pmI cannot reproduce that hard-coded paths are saved inside the database. For me only the smiley itself – : ) – is saved or the emoji in the UTF8 format.
I cannot reproduce that hard-coded paths are saved inside the database. For me only the smiley itself – : ) – is saved or the emoji in the UTF8 format.
Quote from FTP on June 20, 2019, 9:34 pmIt’s normal, you’re not using an extension switching to smilies with GIF files.
If I disable TinyMCE Advanced I have the same behaviour as you.
Maybe we can investigate on how “Keep emoticons as text” is doing to disable everything…
https://wordpress.org/plugins/keep-emoticons-as-text/There’s no image when we view posts ok, but it stops the parsing when we edit the posts and that’s what we’re looking for.
Another proof that it’s WP related and not browser related.So the extension just run this…
add_filter( ‘option_use_smilies’, ‘__return_false’ );Now we need to look what’s behind.
It’s normal, you’re not using an extension switching to smilies with GIF files.
If I disable TinyMCE Advanced I have the same behaviour as you.
Maybe we can investigate on how “Keep emoticons as text” is doing to disable everything…
There’s no image when we view posts ok, but it stops the parsing when we edit the posts and that’s what we’re looking for.
Another proof that it’s WP related and not browser related.
So the extension just run this…
add_filter( ‘option_use_smilies’, ‘__return_false’ );
Now we need to look what’s behind.