HTML Element and Text Widget filtering (Page 2)

[askwpgirl]

Hi Jason,

I have a client who is creating HTML and scripts from Lead Pages to create conversion buttons on her site. Lead Pages creates these awful inline styles for their buttons.

When placed in a Text Widget, the % symbol in the background property in the inline style is turned into a Font Awesome font (or at least tries to be) and thus breaks the code in the text widget.

In the HTML Element in the Template Builder, the styles attribute is removed altogether.

I assumed that the HTML Element in the Template Builder wouldn’t be filtered at all, but it is. How can we remove filtering of that, so the styles attribute on <a> tags isn’t removed?

Also, how can we stop the % symbol in HTML in Text Widgets from being rendered into Font Awesome icons?

I imagine you know more quickly where all these filters are. Thanks! I am trying to get the client to not use any of the inline styles and instead to use a class instead, but she really would like to copy and paste the buttons from Lead Pages and just run with them and not do anything with the HTML. Here’s an example style:

http://postimg.org/image/bren7peuz/

Angela

Topic

[askwpgirl]

Good note. Well, it seems the issue isn’t the HTML Element itself anyway, since it’s saving to the database just fine, but the page rendering is stripping the styles and other things from it.

[Jason Bobich]

All right, so I’m going through and looking at all the places I incorporated this extra security in outputting content last year (talking about only output here, not input from options). It looks like I actually did a very thorough job of doing this. Basically I went through and made sure everything that comes from the database is sanitized before being outputted to your site. Admittedly, this is an extra layer of security you probably won’t find in most themes, but having a night to ponder about it, I do think it’s important.

BUT looking closer, it appears I had the foresight to one day see these complaints arising with my bold security decisions, and I had decided to pass everything through a single, filterable function. So today, if you want to disable all instances of kses filtering (i.e. filtering out HTML tags), you can add this one line to your child theme:

add_filter('themeblvd_disable_kses', '__return_true');

… And I’m thinking that while this warrants an article for developers and can be confusing, I’d like to keep things operating like this in the framework.

Note: As of today with Jump Start 2.0.0, this will seemingly not make all that much difference, because you still have input TO the database being sanitized. But, the “HTML” element will currently allow unfiltered content for the input and output now with the code above. And after the next update and the change I made combined with code above, you’ll have more freedom through just about every textarea that exists in the layout builder.

If you either of you have any thoughts on this, by all means, feel free to share.

• This reply was modified 7 years ago by Jason Bobich. Reason: Oops, code should be __return_true ! not __return_false obviously

[Author]

Replies