askwpgirl

[askwpgirl]

You should add these instructions to the dev.themeblvd.com articles. Some helpful FAQs on WooCommerce/TB interaction would be great! 🙂

[askwpgirl]

That was it! I inherited this site and wasn’t even thinking about what plugins they installed.

It was Popup Maker plugin. No big deal. I’ve never used that, and I have other options that work fine with JS. Sorry to bug you.

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

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

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

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

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

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

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

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

[askwpgirl]

Cool. Yes, that worked, too! I was going to try that next.

So, if one wants to keep the transitions, they can disable using CSS on things that might be adversely effected by it, like the Layer Slider.

[askwpgirl]

Okay! That was it!!!

/* Animations */
.tb-scroll-effects.desktop #custom-main .element-section > .element-content {
	-webkit-transition: all 0s ease-in-out;
	transition: all 0s ease-in-out;
	-webkit-transition-delay: 0s;
	transition-delay: 0s;
}

The transition and transition delay cause the Layer Slider to not be able to get its bearings, so to speak, on the first slide, that’s why subsequent slides work fine. So, the fix is really to the above CSS, which of course could be targeted for just that builder content element containing the Layer Slider.

[askwpgirl]

My suspicion is that it’s all related in some way to the transform/transition properties in 2.1, so I think that’s where I’ll focus next, as I think my CSS fix above is a bit kludgy.

[askwpgirl]

Here’s the page again with popout selected:

http://askwpgirl1.wpengine.com/layer-slider-full-width-on-custom-template/ – doesn’t really make a difference, so popout isn’t the issue.

The CSS I put in my last comment does solve the problem on the other test site I have and on a colleague’s site. Just curious why it’s an issue in JS 2.1 and not 2.0.

Thanks again!!! I know these things are hugely annoying.

The subsequent slides work fine, so there is some temporal thing where the slider isn’t interpreting its positioning correctly in JS 2.1 and is pushing the slider off to the right.

[askwpgirl]

Yes, of course. That is the first thing I tried, and it was still messed up, actually more so.

[Author]

Replies