Solved iframe disappearing from page when saved

[humptydumpty]

Does Cloudron have some kind of setting that wipes out an iframe from a wordpress page?

I was able to embed iframes just fine on my old server but now I can't get it to save. I can see the iframe content load up but then the entire iframe link gets deleted after I save the page. I disabled the cache plugin and Wordfence but that didn't help. I tested adding an iframe on another WP site (also on the same Cloudron server) and it didn't work there either. I installed a plugin called Classic Editor and tried that too with no luck. I tried without a page builder (visual composer) and no dice either.

Suggestions? Thanks!

[girish]

@humptydumpty The site you are trying to embed needs to "allow" embedding. These days many sites prevent embedding by setting X-Frame-Options or CSP headers. The browser reads these headers and will blocked the embedding. Did you see the browser console? Usually, it will say that frame loading got blocked.

[humptydumpty]

@girish Thanks. I'll check the console for any errors but it's my supplier's website and I had it working before I migrated the site over to the new server. I got it to save the iframe code but I have to do it from the "frontend editor". Any other way and it'll erase the code.

[girish]

@humptydumpty it smells like a CSP issue. Let me know what you find.

[humptydumpty]

@girish so I saved all the pages with the iframe codes as I mentioned earlier by using the frontend editor. I opened up console and these are some of the errors that I spotted. The iframe is loading fine and the content like the buttons and dropdowns are clickable and operate as intended so I have nothing to complain about anymore.

HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

[Violation] Added non-passive event listener to a scroll-blocking 'wheel' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://ct.pinterest.com/user/?tid=2613951492436&pd=%7B%22em%22%3A%2224aba99b2defbb47ee981b4200313f61f3ae31541d8717bdac1e463c838939b0%22%2C%22pin_unauth%22%3A%22dWlkPU5UUTJOVGhsTVRBdFptRXpOeTAwTkRRM0xXRTRNV1F0TXpBNE1XVTRNMll3TkRJMyZycD1kSEoxWlE%22%7D&cb=1607138247974. (Reason: CORS request did not succeed)

Uncaught ReferenceError: liveagent is not defined

Uncaught TypeError: rocketDeleteCPCSSbtn is null

[p44]

@humptydumpty Please try to open wp-config.php and change define( 'DISALLOW_UNFILTERED_HTML', true ); from true to false.

Let me know,
Thank's a lot

[humptydumpty]

@p44 DUDE!!! That worked like a charm!

[p44]

@humptydumpty You cannot imagine how many hours I lost to fix that problem. I was embedding an iframe from Calendly and I discovered issue.

But solution... no solution on the web, only with variuos workarounds, jumps, plugins, fixes on functions.php, and so on...

Casually, the same day I had another issue to solve: Wordpress "file editor" was disappeared from admin menu. I googled how to put editor back again. Solution was to change some value in wp-config.php (define( 'DISALLOW_FILE_EDIT', true ) to false).

When I put hands in wp-config.php changing that value to enable again file editor, just a row after my eyes fell on define( 'DISALLOW_UNFILTERED_HTML', true );... and there I understood that it could be the reason for the "cleaning" of the code.

Like you, at beginning I could not explain this problem, I thought it was due to the latest Wordpress release and instead it was due to that value define( 'DISALLOW_UNFILTERED_HTML', true );.

Just a note: they were all fresh Wordpress install from Cloudron. I think the script adds that new rows to wp-config.php that before it does not add.

[robi]

@p44 should this be fixed in the WP App package for all new installs?

[girish]

This change was added as part of https://forum.cloudron.io/topic/3520/disallow-unfiltered-html-in-wp-config-php . Currently, it's present only in the unmanaged WP as the default. Like many other things, it seems more security === breaks something.

@p44 thanks for the solution!

[humptydumpty]

@girish I think it's fine to keep it as it is. I only embed iframes on 1 out of 4 WP installs that I have running so I can see the benefit of having it set like that by default.

I've never went through this before and had no idea what to look for after I ruled out any plugins/themes as being the culprit. It just left me scratching my head. It would be nice if you could add a mention of it in the docs though https://docs.cloudron.io/apps/wordpress-unmanaged/

[girish]

@humptydumpty Done

[humptydumpty]

@girish The changes aren't showing up for me in a new private window. I'm guessing you need to clear the cache on your end?

https://docs.cloudron.io/apps/wordpress-unmanaged/

Unless I'm looking at the wrong page

[girish]

@humptydumpty https://docs.cloudron.io/apps/wordpress-developer/ is the correct page

[humptydumpty]

@girish On the WP (managed) doc page --> Database Access --> ARI Adminer - if you follow the link it'll show that it has been closed for security issue. https://wordpress.org/plugins/ari-adminer/

As an alternative, if someone needs a GUI, I've used Adminer before and it works well but requires manual upload of the file as it's not a plugin and isn't specific to Wordpress. https://www.adminer.org/

[humptydumpty]

@girish Cool, thanks. It loads the "unmanaged" version in the left sub-menu if I browse to the link directly even though it's opened in a private window so if I'm not mistaken, it shouldn't be a browser cache issue on my end.

[girish]

@humptydumpty Yes, I noticed that as well. I think this is some surfer quirk . @nebulon will know.

[nebulon]

Hm surfer will send cache-control: public, max-age=0 so I am not sure why it would cache as such, the etag also should have changed if the source content was updated.