JProffitt3G

I think this is a general enough problem that there might be a way to solve it using a separate plugin. All you need to do is make an ajax backend that can render html / shortcodes securely, and a shortcode that generates calls to that backend. The main issue would be ensuring the backend was secure against malicious input and the frontend didn’t expose sensitive data. When I have time, I’ll investigate that.

Thank you wfalaa. I imagine that must have been frustrating for a while and am glad you didn’t write this off as user-error.

I am glad the team is looking into it. Ideally eventually I would like the option to whitelist parameters globally, so that in case I start using another front-end builder or Beaver Builder changes its implementation of saving modules (e.g. using different parameter names) we don’t run into this same scenario. If that would make more sense as a feature request topic, I can create one.

Using a site for temporary image storage, here is the correct link: http://www.tiikoni.com/tis/view/?id=69bcd2d

I made a sandboxed test environment that recreates this issue along with exact steps that consistently reproduce it.

I made a temp forwarder to my email, [email protected], where we can initiate private communication. Alternatively if there is a place I can safely send you credentials for the site we can do that too.

The steps to reproduce issue:

1. Go to WordFence firewall settings, delete any whitelist rules at bottom, and set firewall to Learning Mode.
2. Go to the home page / Test Page A.
3. Enter the Page Builder (in each case you enter Page Builder, select “Blank” as the layout).
4. Drop in an HTML module and paste in this embed code (same as before):
<iframe width="560" height="315" src="https://www.youtube.com/embed/YE7VzlLtp-4" frameborder="0" allowfullscreen></iframe>
5. Save
6. Publish the page
7. Go to WordFence firewall settings, check whitelist rules at bottom, and set firewall to Enabled and Protecting.
8. Go to Test Page B and repeat steps 3-5.
9. Optionally repeat steps 3-5 with Test Page C, Test Page D.

In each case on B, C, and D you should be blocked from saving the HTML module.

I understand, it is hard to justify adding complexity when the plugin already fulfills its function perfectly on a core install. However I think this is an exceptional circumstance where it is justified.

This is basically an issue of cache-invalidation, saying part of the page needs to be refreshed, and that is a very hard (if not impossible) problem to solve from the top-down. WP Super Cache does not do it to my satisfaction.

Cache-invalidation on WordPress is even harder because of its architecture. Everything on a given page is generated as part of a monolithic view, with one entry point at the very beginning and no hooks for a third party to know what rendered what on the page and what changed since last time. Therefore the only way to get a new version of part of the page is to rerender the whole page.

However lets say you could rerender just the part you needed. Then theres still the issue of how to merge that into / compose it with the existing cached page. Do you perform complex string manipulation on the server side? Do you defer it to javascript and do a jQuery(‘…’).replace()? Something else? Both of those have drawbacks and may not work in a lot of cases.

Once you solve that problem, there is still a more fundamental issue with this whole approach to caching, and thats that it requires spinning up PHP to coordinate (even if the cached page is fine as is). In my case PHP is the slowest component, adding 0.5s to 1s to page load time (its using SuPHP, and I cannot yet move to PHP-FPM). Most of the savings I get from caching come from avoiding hitting PHP in the first place.

So cache-invalidation has to happen from the bottom-up (I should say “cache-invaldation” with air-quotes because my point is basically we have no way to do it at all on WordPress). Every developer has to write their own solution to make their particular plugin display the latest information in the most seamless way possible. Your plugin would be very easy to do that for, since its views are encapsulated and parameterized, and just need to be exposed via AJAX.

Hiding it behind a feature checkbox would allow people to use it when they need it, and disable it when they don’t care about the caching and don’t want the javascript overhead.

• This reply was modified 9 years, 7 months ago by JProffitt3G.

All looking good! Thank you very much Maarten, I’m loving this plugin! 🙂

• This reply was modified 9 years, 7 months ago by JProffitt3G.

Alternatively you can create a WordPress page (no beaver builder required) with this markup:

<p>I should be the first line</p>

[mbhi]

It should exhibit the same behavior and show the shortcode does not work as intended right now.

• This reply was modified 9 years, 7 months ago by JProffitt3G.
• This reply was modified 9 years, 7 months ago by JProffitt3G.

Sure, what I noticed is it would appear on the page, but in the wrong location. Here is an example:

It should be appearing in the yellow box, but instead its the first child of the fl-post-content element. It appeared behind the map, so I lowered the opacity of the map for the purpose of the screenshot.

You should be able to recreate it with a text/html module that has a large top-margin (to leave some space at top of post) and this shortcode as the content.

This makes sense because the way Beaver Builder works is it hijacks the WordPress “the_content” filter, which expects an html string to be returned, which it’ll then echo. When Beaver Builder gets to this shortcode, the shortcode echoes html immediately to the page, and then Beaver Builder returns its html which gets echoed afterwards.