Weird behaviour: style="…" removed within <img src="…"> in view mode only!
Quote from FTP on October 29, 2019, 7:49 pmHi @asgaros ,
After the shortcodes parsed by Elementor when it should not, the smileys parsed by WP when it should not, another weird behaviour.
I use Asgaros with TinyMCE Advanced to have a bit more options when I create posts.
So when I create a post, insert an image (with an URL), I can via the TinyMCE menus or directly in the source code add in <img src=”…”> a style=”…” attribute to add a shadow around the image (box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19);).In this case, the shadow is properly displayed in edit mode, the code is properly saved as when we edit the post the shadow and the style attribute are still there, but in view mode, the style attribute disappears!!! Removed from the code before display. It’s not in the page source code any more 🙁
Do you know what can be the cause of this?
P.S.: it works fine for blog posts or WP pages. The issue is only on the front end.
Hi @asgaros ,
After the shortcodes parsed by Elementor when it should not, the smileys parsed by WP when it should not, another weird behaviour.
I use Asgaros with TinyMCE Advanced to have a bit more options when I create posts.
So when I create a post, insert an image (with an URL), I can via the TinyMCE menus or directly in the source code add in <img src=”…”> a style=”…” attribute to add a shadow around the image (box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.19);).
In this case, the shadow is properly displayed in edit mode, the code is properly saved as when we edit the post the shadow and the style attribute are still there, but in view mode, the style attribute disappears!!! Removed from the code before display. It’s not in the page source code any more 🙁
Do you know what can be the cause of this?
P.S.: it works fine for blog posts or WP pages. The issue is only on the front end.
Quote from Asgaros on October 30, 2019, 8:45 pmHello @ftp
Asgaros Forum is using the official wp_kses-function to remove all possible dangerous code from user-input which can be used to inject scripts or add hidden custom-content to a page. In this case I assume that this function is filtering this attributes from the tags. It is working correctly for normal posts/pages because in this case the site-admin is responsible for all the things he adds to his site. Unfortunately this is a core-function so I dont really want to touch it because it can lead to problems for other plugins or functions.
https://developer.wordpress.org/reference/functions/wp_kses/
Hello @ftp
Asgaros Forum is using the official wp_kses-function to remove all possible dangerous code from user-input which can be used to inject scripts or add hidden custom-content to a page. In this case I assume that this function is filtering this attributes from the tags. It is working correctly for normal posts/pages because in this case the site-admin is responsible for all the things he adds to his site. Unfortunately this is a core-function so I dont really want to touch it because it can lead to problems for other plugins or functions.
https://developer.wordpress.org/reference/functions/wp_kses/
Quote from FTP on October 30, 2019, 10:24 pmQuote from Asgaros on October 30, 2019, 8:45 pmAsgaros Forum is using the official wp_kses-function to remove all possible dangerous code from user-input which can be used to inject scripts or add hidden custom-content to a page. In this case I assume that this function is filtering this attributes from the tags.
The “style” attribute is that dangerous?
Can you tell me where I can disable the use of this function for Asgaros, just to confirm it’s indeed the cause of the issue?It is working correctly for normal posts/pages because in this case the site-admin is responsible for all the things he adds to his site.
Well, on a WP site not only admins can create posts, also contributors, authors & editors. I’m a bit surprised it can be that easily acceptable on one side and not on the other one.
Quote from Asgaros on October 30, 2019, 8:45 pmAsgaros Forum is using the official wp_kses-function to remove all possible dangerous code from user-input which can be used to inject scripts or add hidden custom-content to a page. In this case I assume that this function is filtering this attributes from the tags.
The “style” attribute is that dangerous?
Can you tell me where I can disable the use of this function for Asgaros, just to confirm it’s indeed the cause of the issue?
It is working correctly for normal posts/pages because in this case the site-admin is responsible for all the things he adds to his site.
Well, on a WP site not only admins can create posts, also contributors, authors & editors. I’m a bit surprised it can be that easily acceptable on one side and not on the other one.
Quote from Asgaros on October 31, 2019, 5:51 pmThe “style” attribute is that dangerous?
It can be used to move special content outside of the view-range or hide it completely (display: none) which makes certain content hard to detect.
You can try to disable it by checking out the following file:
/includes/views/post-element.php
$post_content = wp_kses($post->text, $allowed_html); // change to: $post_content = $post->text;Well, on a WP site not only admins can create posts, also contributors, authors & editors. I’m a bit surprised it can be that easily acceptable on one side and not on the other one.
The point is that the admin can decide who can create this content on his website so he is responsible for it. For open discussion-platforms it is necessary to have stricter rules. Just imagine everyone at facebook could add unfiltered custom-HTML inside of their news-feed.
The “style” attribute is that dangerous?
It can be used to move special content outside of the view-range or hide it completely (display: none) which makes certain content hard to detect.
You can try to disable it by checking out the following file:
/includes/views/post-element.php
$post_content = wp_kses($post->text, $allowed_html); // change to: $post_content = $post->text;
Well, on a WP site not only admins can create posts, also contributors, authors & editors. I’m a bit surprised it can be that easily acceptable on one side and not on the other one.
The point is that the admin can decide who can create this content on his website so he is responsible for it. For open discussion-platforms it is necessary to have stricter rules. Just imagine everyone at facebook could add unfiltered custom-HTML inside of their news-feed.
Quote from FTP on November 22, 2019, 11:51 pmHi @asgaros,
Sorry for my late reply.
Thanks for your answer!
And yes, I confirm, it’s the wp_kses() function that filter this style attribute.So last thing: in case I wan to disable this function, can I put a modified file in my child theme instead of editing your code in the plugin file?
Thanks!
Hi @asgaros,
Sorry for my late reply.
Thanks for your answer!
And yes, I confirm, it’s the wp_kses() function that filter this style attribute.
So last thing: in case I wan to disable this function, can I put a modified file in my child theme instead of editing your code in the plugin file?
Thanks!
Quote from Asgaros on December 8, 2019, 6:49 pmHello @ftp
No, a modification from a child-theme is not possible. Basically I could add a filter for this behavior to make it adjustable via the functions.php file, but the wordpress.org-moderators of the plugin-repository are very sensitive when it comes to options to bypass certain security-functionalities – so I want to avoid this.
Hello @ftp
No, a modification from a child-theme is not possible. Basically I could add a filter for this behavior to make it adjustable via the functions.php file, but the wordpress.org-moderators of the plugin-repository are very sensitive when it comes to options to bypass certain security-functionalities – so I want to avoid this.
Quote from FTP on December 9, 2019, 4:27 pmOk thanks.
I found a solution using a class (it’s not filtered by wp_kses() ).
It’s not convenient as users can not add it via the pop-up to insert an image but it works if added via the code.
Ok thanks.
I found a solution using a class (it’s not filtered by wp_kses() ).
It’s not convenient as users can not add it via the pop-up to insert an image but it works if added via the code.