How do I debug this error?
Error Message: “A Conflict on the Front End of your Site has prevented the preview from loading”
Occurs when attempting to edit Content in the editor.
Hello @Quinn288,
Thanks for writing in!
It can be caused by several reasons which you need to rule out one by one for your environment. Please kindly follow the steps mentioned in the article below:
https://theme.co/apex/forum/t/popular-questions/204
Also please please make sure you have sufficient Php memory limit that is required to run your website. If there is memory constraints please kindly read the article below to change memory limit:
https://theme.co/apex/forum/t/troubleshooting-customizer/196
Thanks.
Hi @Prasant
Thank you for the recommendations. I got in touch with my host, Siteground and we tried the following with no success:
- default .htaccess
- max memory limit 768 MB
- max_input_vars 10 000
- all plugins disabled
- PHP version down to 5.5
- max substitute lenght increased to 10
- opcache.interned_strings_buffer set to 16
- Cloudflare not enabled
What do you recommend?
What about the Mod Security rules? What do they see in the logs.
Thanks.
@xian I’ll check. Is there something in particular they should or shouldn’t see?
Note: the theme is currently on our staging server rather than our root domain.
After speaking with the Siteground support team here is what they said:
The original issue was caused due to the following error (not to mod security):
Code:
XMLHttpRequest cannot load https://www.engagefactors.com/employee-engagement/. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘https://www.staging1.engagefactors.com’ is therefore not allowed access.
I managed to resolve the error by applying:
Code:
Header add Access-Control-Allow-Origin “*”
in your .htaccess file.
However, the following error meesage:
Code:
“A conflict on the front end of your site has prevented the preview from loading.”
is still present.
After further review, I spotted:
Code:
preview-frame::update-aborted Object {error: true, message: “incomplete”, response: "<html lang=“en-US” prefix=“og: http….quicksprout.com/qs.js”); "}
The theme builder is getting incomplete response and that is why the page builder is not loading:
I tried different approaches to resolve the issue but to no avail. I have searched on the Internet for similar issues and tried several suggested fixes but that did not help either.
I have checked the server logs however, I could not find any entries related with the reported issue. The issue seem to be caused by the theme itself and not by any setting on the server.
However, I am afraid that we are not familiar with the code and the structure of your theme and it would be best to get in touch again with the theme developers for more information.
Finally, I would like to provide some clarification on the staging software.
When creating a WordPress staging copy we do not replace the Home and SiteUrl options for WordPress. They remain the same as the original website. Instead we use three additional Apache modules that allows you to actually work on the correct application:
-
mod_host – contains 1 directive – RealHostname. If defined, all the requests to the application will be processed as they have been made to the real hostname (in our case all of the requests to the stagingN.domain.com and not the URL in the WordPress configuration). This module is written by SG.
-
mod_substitute – standard Apache module – used for replacing strings in the Apache’s response. We use this to replace domain.com with stagingN.domain.com
-
mod_headers – standard Apache module – used for changing request and response headers. Used for configuring the headers according to the staging subdomain.
I see. That is most probably the issue since Siteground’s staging does not use standard WordPress functions and instead uses a different method. Your WordPress URL and Site URL must be the same as your domain so if you’re in staging, it must be the staging domain and not the live domain. Please contact Siteground if they have a workaround for that.
Thanks.
Hi Quinn,
I decided to give X a try and am also using SiteGround staging. I’ve tried a lot of thing to try to get this to work including referer based rewite on the root site to redirect any request refered by staging back to staging. However I still get the incomplete error (even thought eh error shows the html for the page and it is complete).
Did you ever find a workable solution to this?
I’ve tried a few times to talk to SiteGround about this, but didn’t get very far with them. There is a serious problem with how their staging server does provisioning. In short, they don’t update your site URL so any plugins that call the WordPress home_url function (like Cornerstone and many others) will continue to reference the live site instead of the staging site. Because Cornerstone tries to communicate with the live site, you get a cross origin error.
To fix this, go to Settings > General and set your site URL and WordPress URL to be the URLs for your staging site instead of the production site. You’ll need to do this everytime you re-provision the staging site.
Got it. That worked. Only point of note, when you click save on the general page, it will not show the urls as updated to reflect the staging URL. However, if you look in the DB they are updated, and everything works. It will probably be my practice to change them back to the production urls before I push staging to live (in case anyone finds this post in the future).
Glad to hear you have something working. We actually got an email from SiteGround this morning. We’re talking through some of the issues we’re seeing, so hopefully a more official resolution can be reached.
Hi!
I have the same issue. Until I have updated to Pro 1.2.6 I had in the staging website the following error:
A conflict on the front end of your site has prevented the preview from loading
I have updated today to the last version and right now Pro doesn’t load. I get the login panel displayed on and on. I have tried to modify the wordpress and site url but it’s grey. http://prntscr.com/hacs4b
Siteground sent me the following answer:
The issue seems to be due to the fact that the theme editor is trying to access the web page from the original URL address and not from the staging subdomain. When I try to edit a page the first HTTP request is correctly being sent to the staging subdomain, but from then on the second request and all others are being sent to the original site.
My suggestion to you would be to contact the plugin developers and ask them to modify the theme editor code just for the staging site.
Please have in mind that the siteurl and home database settings must remain pointed to the main domain to avoid any issues. Our Nginx configuration is configured to proxy/forward correctly requests to the staging subdomain, but unfortunately the server cannot forward hardcoded requests.
Hi,
For a temporary solution:
In your staging site, add the code below in your wp-config.php file located at the root directory.
define('WP_HOME','http://your-staging-url.com');
define('WP_SITEURL','http://your-staging-url.com');
Change http://your-staging-url.com with your staing site url.
You may add it before this line of code.
/* That's all, stop editing! Happy blogging. */
Don’t forget to remove it when you are ready to push to production.
Hope that helps.
Done that, but I get
This page isn’t working
www.staging1.printoteca.ro redirected you too many times.
Try clearing your cookies.
ERR_TOO_MANY_REDIRECTS
We’ve been in touch with SiteGround about the matter and we’re waiting to hear back from them. Regretfully until we work something out with them, I don’t have a solution.
Here’s the problem (quoting the SiteGround rep from above):
Please have in mind that the siteurl and home database settings must remain pointed to the main domain to avoid any issues. Our Nginx configuration is configured to proxy/forward correctly requests to the staging subdomain, but unfortunately the server cannot forward hardcoded requests.
The only way to get the content builder working right now is to change the URL to match the origin you’re visiting from (the staging URL). The rest of this post is gets more technical, and is more for explaining to anyone who is interested and for the sake of posterity.
My understanding of SiteGround’s staging system is that they create an exact replica of your production site. When you visit it, their front end proxy (nginx) automatically rewrites all the instances of the production URL and replaces it with the staging URL. The staging site itself is basically tricked into thinking it’s the production site. This covers a vast range of use cases, but as clever as it may, the implementation isn’t fully isolated. Internally, when home_url is called, or a permalink is requested, we still get the production URL. This is why Cornerstone tries to load the preview from the production URL instead of the staging URL - because SiteGround’s staging site is still using the production URL internally. In order for things to be truly isolated the URL would need to be replaced throughout the database which this isn’t possible on SiteGround’s platform.