The preview could not load due to iframe response

Hi @Harmon,

Before jumping into the main issue here, I looked into the 404 issue you had on another thread as well and that seems to be a problem with your web server configuration. Everything but /wp-admin and the home page is showing a 404. This happens when your webserver doesn’t have the right configuration to for send incoming requests to the WordPress index.php file. You will want to check your htaccess rules to make sure they are correct on that server: https://wordpress.org/support/article/htaccess/


Now for the live preview error message. I’ve checked your site and it’s the exact issue I’m seeing on @al2code’s site as well (The preview could not open due to iframe response being incomplete)

Something changed on your server that is causing the HTML to change. On both sites, I’m seeing this output in the iframe response:

CORNERSTONE_FRAME<script type='text/javascript' style='display:none;' async>
</script>

<script type="text/javascript" data-cfasync="false"></script></body></html>

@al2code and @Harmon maybe we can work together to see if there are any similarities.

Are you aware of anything running outside of WordPress that could be rewriting HTML? If I do “view source” on both of your sites I see a similar code that starts like this: <script data-ezscrex='false' I don’t recognize it and I’m not sure where it’s coming from. Do you know what this might be? Let me know, thanks!

Edit: to confirm regarding a question in your first post: Cornerstone is not required if you are using Pro.

I have had my site behind the Ezoic Site Speed accelerator that is part of my ad network (Ezoic) which certainly is capable of altering the HTML, CSS, and JS in order to minify things. I have disabled all of those features as part of testing this.

I edited this page on 3/15/2021 with no issue with that in place, including the minifying of those resources to increase the speed to clients.

Thanks! That helps. It looks like it might not be fully disabled since if you use “view source” it is still there. Or it could be that the ad network itself is breaking things - not even the accelerator. It’s likely that something changed recently in how they process HTML which is adding that extra useless code (and breaking the live preview).

I’ve been looking into it more and we might be able to compensate for this in Pro. I just can’t make any promises since we can’t guarantee compatibility with third party systems like this.

I have opened a ticket with Ezoic asking for help with this. Another bit of information, I fixed my htaccess file for my staging site and everything is working there. My staging site DNS is defined in Ezoic, but it is not behind their Cloudflare CDN nor does it have any possibility of their Site Speed Accelerator being enabled for the site.

I think I agree that there is something that has changed with Ezoic that has introduced this issue. Hopefully the ticket I have opened up there will lead to a solution as I really need both of these things to work together.

Sounds good! Thanks for reaching out to them about it. As I mentioned before that code doesn’t appear to do anything. Perhaps it was introduced mistakenly. Regardless, I’ll keep looking into potential options from our end and advise if anything materializes.

@alexander can you help me with a description of what it is the Pro editor is trying to do in the iframe that isn’t working? Something that the technical folks at Ezoic should be able to make sense of since they aren’t likely to be familiar with the error message I am getting.

Sure! A very direct approach would be asking them if they can stop this code from being added to the end of every single page load. It doesn’t appear to have any purpose. Because it is introduced outside of WordPress, Pro can’t anticipate it and thinks the page didn’t render properly.

<script type='text/javascript' style='display:none;' async>
</script>

<script type="text/javascript" data-cfasync="false"></script></body></html>

I know at this point that at a minimum, I will be able to address this in Pro by adding an option to disable the integrity check. The error you’re seeing is a way for Pro to stop trying to preview when it suspects the output has been altered by a caching system or plugin in ways that would stop Pro from working. Instead of the preview frame being unstable and unpredictable, it just doesn’t output. If we add an option to disable the integrity check I expect the builder would continue working in your case, but in the event that something was actually wrong you might see other issues like not being able to interact with elements.

That being said, sometime over the next few days I think I can have a solution on our end.

Not sure if it is helpful, but I do see this in the debug logs:

[06-Apr-2021 22:40:32 UTC] PHP Notice: Undefined variable: label_prefix in /home/…/wp-content/themes/pro/cornerstone/includes/elements/control-partials/modal.php on line 81
[06-Apr-2021 22:40:32 UTC] PHP Notice: Undefined variable: label_prefix in /home/…/wp-content/themes/pro/cornerstone/includes/elements/control-partials/off-canvas.php on line 86
[06-Apr-2021 22:40:32 UTC] PHP Notice: Undefined variable: control_off_canvas_close_location in /home/…/wp-content/themes/pro/cornerstone/includes/elements/control-partials/off-canvas.php on line 267

Ezoic has raised this concern with the SiteSpeed team for review - they’re going to take a look at the setup and see if we can find a workaround for the time being.

They will reach out with updates as soon as they become available!

I have found a temporary workaround that allowed me to get my page edit done. I added an entry to my local hosts file to override the DNS for the website to be the IP of the virtual server where my content is hosted. This bypasses Ezoic entirely and allowed me to get things to work for now.

This won’t work as a long term solution, but thought I would let you know that it worked so that it could aide in the troubleshooting.

Ezoic is also asking why it is you think the script tags you have identified here are causing the issue. They would like to understand a little more what the integrity check is doing.

If you do that, does Ezoic ads still show?

@Harmon,

Thanks for sharing the log info. We’ll clean those up. It’s just some leftover unused variables. That wouldn’t cause any of the issues you’re seeing here.

Nice job on that DNS workaround! Glad you at least have something for the time being.

I believe it’s like they are bypassing Ezoic entirely, but only for specific computer they are using to work on the site.

Pro offers a way to edit pages live in real time. Caching systems often break this functionality and make the live preview non responsive. To avoid this we do an integrity check to make sure the page hasn’t been tampered with outside of the normal WordPress lifecycle. Those empty tags are probably just a false positive - no caching is taking place, but it’s still tripping how Pro tries to detect the presence of external caching.

In Pro 4.3.1 I ended up retooling how the detection on our end works. It account specifically for the use case here where Ezoic makes unexpected adjustments outside of WordPress. It still does some other integrity checks but is more lax about the final tags of the page being reordered. It will be going live in the next few hours on automatic updates so when you see it give it a try.

Using the local hosts entry means bypassing Ezoic entirely, so no ads, but it is only for the computer I am using. It is a workable solution for getting a few updates done but not a long term solution as you can’t use tools like the ad placement plugin this way.

Excellent. Looking forward to it. So you know, Ezoic gave me this:

I don’t believe this is specific to sitespeed accelerator, I think this is being caused by general Ezoic optimizations.

I’ve suggested to another publisher experiencing the same issue that theme.co should be able to use a subdomain to pull through a completely untouched version of your site for your integrity check.

This would mean they need to alter how the integrity check works to utilize a subdomain to pull the same resources through. You could suggest this to them yourself and see whether they’d be willing to do that.

Setting up a subdomain to make a page editor work feels like a lot to me. Hopefully the changes to the integrity check will solve the problem.

Hi @Harmon,

I think they’re right about it not being the accelerator considering you mentioned having that disabled. I don’t think a subdomain would actually work though. Pro needs the URL you are editing to be the actual URL otherwise it will show a cross origin error and not be able to render elements. Keep an eye out for the point release and fingers crossed that will get things working again.

Success! With 4.3.1 I can edit pages with Pro. Whew. Thanks for the work on that!

I am going to share some information no how to work through this. Is this also fixed in a version of X?

Hi @Harmon,

That’s great to hear! Thank you for confirming with us. The same changes were made in Cornerstone so as long as X users are on the latest version this will be resolved.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.