HTML Element and Text Widget filtering

[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]

The HTML Element is also filtering out classes on <a> tags. So, I guess I don’t think the HTML Element should be filtering the content.

[Jason Bobich]

Howdy,

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?

This is theme and plugin development security 101. There must be data sanitization, in place, when submitting forms. You cannot just allow raw user-inputted content to go into the database.

The theme framework takes the WordPress default global $allowedtags and extends it. This array is what’s passed into wp_kses when you submit that data, and you can be filter it with themeblvd_allowed_tags.

For example:

/**
 * Add allowed HTML tags.
 */
function my_allowed_tags( $tags ) {

	// Add allowed attributes to <a>
	$tags['a']['style'] = array();
	$tags['a']['class'] = array();

	// Add completely new <foo> tag and then attributes to it
	$tags['foo'] = array();
	$tags['foo']['style'] = array();
	$tags['foo']['class'] = array();

	return $tags;
}
add_filter('themeblvd_allowed_tags', 'my_allowed_tags');

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

From Text Widgets:

remove_filter( 'widget_text', 'themeblvd_footer_copyright_helpers' );
remove_filter( 'widget_text', 'themeblvd_do_fa' );

From Layout Builder content:

remove_filter( 'themeblvd_the_content', 'themeblvd_footer_copyright_helpers' );
remove_filter( 'themeblvd_the_content', 'themeblvd_do_fa' );

• This reply was modified 7 years ago by Jason Bobich. Reason: Oops! Forgot add_filter()

[askwpgirl]

Hi Jason,

That makes so much sense that you would sanitize the HTML Element. Though, I would expect it to operate like the Text Widget in WordPress. The WordPress Text Widget does some sanitization, but it doesn’t strip out HTML attributes. I wonder if we should have the HTML Element behave more like the Text Widgets? At any rate, the filters will take care of what we need! I’ll add them to my snippets.

A

[Jason Bobich]

Hm, I’m not sure what extended library of HTML tags and attributes that sanitization would be pulling from.

[Jason Bobich]

Hey can you link me to pastie code snippet that shows stuff getting stripped in layout builder but not text widget? And also, what is the result when you try and save that code to a standard WP post or page?

[askwpgirl]

Post and pages doesn’t strip out anything style or class attributes.

Text widgets don’t strip out styles or classes.

The HTML Element strips out class and style attributes, e.g. class=”btn-blue”

I had a person on my Google Group today ask about this question specifically in using HTML Element, so if we can get that fixed, that would be great.

I tried to do both inline styles (style=”font-weight:bold;”) for example and classes, and the HTML Element strips them all out.

The issue the person on the Google group asked was this:

It seems that the HTML block inside of JumpStart’s Layout Builder removes any input tags.

For example, if you enter a form like this:

<form>
<input type=“text" name="email">
</form>

You end up seeing this in the browser:

<form> </form>

Any ideas why or ways to work around it?

Basically, the stripping out of essentially everything you would use the HTML Element for makes the HTML Element not have any real purpose, imho. The WordPress Text Widget does not strip out classes, styles, or input fields.

[askwpgirl]

I think this is the Text Widget full code on the Codex:

https://developer.wordpress.org/reference/classes/wp_widget_text/

It shows how the content is filtered.

[Curtis Floth]

I can place the following form in the ‘Text’ content of a page and it works as expected:

<form>
<input type=”text” name=”email” placeholder=”Email here” />
</form>

But Layout Builder removes the input field, resulting in:

<form> </form>

This is theme and plugin development security 101. There must be data sanitization, in place, when submitting forms. You cannot just allow raw user-inputted content to go into the database.

If Layout Builder was handling content from unknown / un-trusted users, such as a membership plugin, then the extra security layer would make sense. The plugin, however, doesn’t meet that qualification. So the security argument doesn’t make sense here.

Layout Builder is for creating page content by users that have permission to add a page. The expected behavior is that the HTML element behaves the same as the ‘Text’ option for standard page content.

Not matching the HTML element’s behavior to the behavior of the ‘Text’ option causes confusion and frustration for people that adopt the framework/plugin. Especially having to add a new filter to the functions.php file to attempt to get the behavior back to matching that of the ‘Text’ option.

You can trust people creating page content, Automattic does by default.

• This reply was modified 7 years ago by Curtis Floth.
• This reply was modified 7 years ago by Curtis Floth.

[askwpgirl]

Hi Curtis,

Actually, all content in WordPress is filtered in the page and post content, text widgets, etc. The difference being that they each filter content slightly differently.

Not sanitizing content is not best practice, so no good developer will leave code un-filtered in end-user data entry fields.

However, I do think the HTML Element could be filtered using the same filters as the Text Widget, which I linked to above.

A

[Curtis Floth]

I agree that the content should be filtered and handled properly.

I also agree that the HTML Element should be filtered using the same process at the Text Widget. I think that’s how everyone who tries the HTML element expects it to work.

[Jason Bobich]

It’s funny that both of you had this same issue on the same day. But all right, I’m sold! Here’s the change I’ve made for the next update.

I also agree that the HTML Element should be filtered using the same process at the Text Widget

But let’s just clarify that currently, the “HTML” element is already setup how you’re wanting; I just double checked. You can currently put any HTML into an “HTML” element and it will not get sanitized out.

See screenshot: http://www.uploadblvd.com/uploads/image_5744ceb430486.png

[askwpgirl]

Yes, what’s weird, Jason, is that the HTML Element doesn’t actually remove anything. The code appears to be fine inside the HTML Element itself. However, the rendered HTML in the Page Source has everything stripped out.

[askwpgirl]

I tried your modified code in options-sanitize.php, and it doesn’t prevent the style attribute from being stripped from the HTML Element. It also doesn’t stop the form input fields from being stripped out.

Again, this isn’t happening in the Element itself, but when the HTML is rendered on the page.

So maybe the issue is with some other sanitization that is happening within the template builder. It doesn’t effect when “Current Page Content” element is used, but it does when Content Element or HTML Element is used.

[Jason Bobich]

Yeah, you’re definitely right. This is actually a result of that whole code audit debacle I went through with ThemeForest reviewers awhile back.

When saving, you can pass the data because you know the logged in user. But retrieving is a different story, not knowing if data in the db was compromised. I’ll do some more research about the best way to handle this.

[Jason Bobich]

Probably relevant:

Note that the kses system can be resource-intensive, and should therefore not be run as an output sanitization filter directly, but as a filter to data after it has been input and processed, before it is saved in the database. WordPress runs kses on the pre_comment_content filter, for example, to filter the HTML before saving the comment.

https://codex.wordpress.org/Data_Validation#HTML.2FXML

Framework is currently running it is output sanitization.

[Author]

Replies