Customize: Preview fails to load when domain mapping in use (home/siteurl domain mismatch)

[RomainVB]

When the home URL and the siteurl have different domains, in 4.7 the preview shows the error message “Non-existent changeset UUID.” The reason is because the user is (probably) not authenticated on the frontend, and so the user cannot customize and since the changeset doesn't exist yet the user blocked from accessing the site. (The thought here is that the UUID serves as a unique key which would allow an unauthenticated user to access the preview if they knew it, though this wouldn't do any good for users who are previewing a theme switch since switch_themes capability is required regardless in that case). Note that the issue goes deeper when FORCE_SSL_ADMIN is enabled because the browser's cross-domain security policy blocks the preview frame altogether (in 4.7).

Nevertheless, even as far back to 4.3 (at least) when attempting to access the customizer with the frontend (home) domain mapped to another domain from the backend (siteurl), the preview loads with a login form and submitting the form just results in the form being re-displayed indefinitely. The user can never advance past it. So cross-domain customizer preview seems to be broken prior to 4.7 as well.

Note that the issue likely does not manifest in domain mapping plugins which dynamically change the home option (such as WordPress.com), as they do it conditionally based on whether or not the customizer is bootstrapped.

[RomainVB]

Copie de mon écran

[westonruter]

@RomainVB welcome. What are the steps that you took to cause this error to appear?

What theme and plugins are active on your install?

[swissspidy]

#39161 was marked as a duplicate.

[sixsigmablackbelt]

wordpress 4.7

Accelerated Mobile Pages
Advanced AMP ADS
AMP
Cookie Consent
Disable Emojis
Disable XML-RPC Pingback
Email Address Encoder
Glue for Yoast SEO & AMP
Google Analytics by MonsterInsights
Optimus
Sticky Menu (or Anything!) on Scroll
Table of Contents Plus
TablePress
TinyMCE Advanced
Umleitungen
WP Minify Fix
WP Super Cache
Yoast SEO

[westonruter]

@RomainVB @sixsigmablackbelt and this error appears in the preview immediately upon loading the customizer or does the site frontend appear momentarily and then update to show the error message? Also, are you loading the customizer initially with a changeset_uuid query parameter appearing in the URL?

[westonruter]

This error message is printed out in the WP_Customize_Manager::setup_theme() method:

<?php
/*
 * If unauthenticated then require a valid changeset UUID to load the preview.
 * In this way, the UUID serves as a secret key. If the messenger channel is present,
 * then send unauthenticated code to prompt re-auth.
 */
if ( ! current_user_can( 'customize' ) && ! $this->changeset_post_id() ) {
        $this->wp_die( $this->messenger_channel ? 0 : -1, __( 'Non-existent changeset UUID.' ) );
}

If you just authenticated, then the current_user_can( 'customize' ) check should return true, so I don't see why this condition would be entered into.

[sixsigmablackbelt]

log on

[sixsigmablackbelt]

i take this link
​http://www.sixsigmablackbelt.de/wp-admin/
then check the customizer button
after that i get the message with this url
​http://www.sixsigmablackbelt.de/wp-admin/customize.php?return=%2Fwp-admin%2F

i take the right password into the field
check the submit button
i get the message log on
after some seconds i get the message your session is time out
beetween i saw the message with the uuid on the screen

see also the versuch.wmv file

[westonruter]

@sixsigmablackbelt I'm having trouble opening that file. Would you please upload it to YouTube?

[sixsigmablackbelt]

​https://youtu.be/hz9XmYtOZFM

[westonruter]

Milestoning this to 4.7.1 so it can be on our radar to identify what the problem is.

From looking at your plugins, @sixsigmablackbelt, the best guess I have is that WP Super Cache is the culprit. Is it possible for you to deactivate the plugin temporarily to see if it is the issue? Likewise are you able to deactivate other plugins selectively to identify if one of them are causing the problem? Naturally this would be best to do on a staging environment if you have one.

@RomainVB Do you also have WP Super Cache enabled?

[sixsigmablackbelt]

You are right. It is the WP Super Cache. After deactivating the plugin, everything was ok. Thanks a lot for your advice.
Roland

[westonruter]

@sixsigmablackbelt would you share the configuration you have? I was able to reproduce a problem with WP Super Cache whereby changes weren't appearing in the preview after refreshing. But I wasn't able to reproduce the problem with the error message appearing.

I've opened an initial pull request for WP Super Cache to fix the issue, though I'm not sure if it will fix the original issue reported here. PR: ​https://github.com/Automattic/wp-super-cache/pull/161

[sixsigmablackbelt]

@westonruter what you mean with configuration?

[westonruter]

@sixsigmablackbelt your WP Super Cache configuration/settings.

[westonruter]

I'm thinking this should be closed as invalid, as it is a problem with a caching plugin.

[celloexpressions]

Replying to westonruter:

I'm thinking this should be closed as invalid, as it is a problem with a caching plugin.

Agreed; caching plugins need to account for the customize preview (and changesets more broadly). If there are things that core can do to facilitate this or avoid what sounds like a potential compatibility issue with 4.7, let's work to identify those and get those into specific tickets.

[dd32]

#39420 was marked as a duplicate.

[pagelab]

This error message appeared to me when the WordPress and Site address fields in Settings > General were mistakenly set with different values.

The message disappeared when the fields were synced.

Other users out there that reported the same solution: ​https://wordpress.org/support/topic/non-existent-changeset-uuid/

Tested with WP 4.7 and Twenty Sixteen theme, no plugins active.

[westonruter]

@pagelab I'm not sure why that would be. So the issue appears if the siteurl and home options differ, even when the two domains point to the same WP install accessed via a different URL? In other words, when you say the two values were mstakenly different, did one value contain the domain with the www whereas the other did not?

[pavelevap]

Yes, I experienced the same problem, one value was with www prefix and another without it. One user wanted to change website URL to contain www, but changed it only for one value and it leads to this error.

[pagelab]

Replying to westonruter:

@pagelab (...) when you say the two values were mstakenly different, did one value contain the domain with the www whereas the other did not?

No, in my case the values were quite different, not just the www part.

The following image shows the values in both fields when the message appeared:

When the second field was set with the value of the first field, the message disappeared.

[asalce]

If you set your site url to a non-wp page, the customizer just stays in a "loading" state.

[pagelab]

Replying to asalce:

If you set your site url to a non-wp page, the customizer just stays in a "loading" state.

Yes, this happened only in this specific website and I couldn't reproduce the same issue on another WordPress install.

[asalce]

​https://codex.wordpress.org/Changing_The_Site_URL
The "Site Address (URL)" setting is the address you want people to type in their browser to reach your WordPress blog.

"Many people want WordPress to power their website's root (e.g. ​http://example.com) but they don't want all of the WordPress files cluttering up their root directory. WordPress allows you to install it into a subdirectory, but have your website served from the website root."

I think the issue was just a mis-configuration like @pagelab mentioned, and a misunderstanding of what "Site Address (URL)" means from my part. I was using "Site Address (URL)" as a URL for my website's homepage, which is not running on WordPress. WP site_url and home_url should be relatively the same, your "Site Address (URL)" should be pulling up your WP "front page" or the customizer is not going to work.

@westonruter If the above is correct, then this may be a non-issue. nothing to patch here :)

[tiella]

Thank you all!

After following numerous attempts (active e deactive plugin, back to old theme, delete .htaccss file) when I set the field "Wp url" with the same value of the "site URL" field, at the same time I solved three problems:

1. ERROR MESSAGE "non existing changeset UUID" disappeared.
2. In Language Management (qTranslate Configuration) the option "Hide URL language information for default language" worked again
3. the hamburger menu on the mobile worked again

[colored_rbg]

I was encountering this same issue and I may have found a solution for this, within WP Super Cache > Advanced, disable "Make known users anonymous so they’re served supercached static files.".

@sixsigmablackbelt you may want to try this as well if you're still having issues.

Disabling that option and then re-enabling caching worked to bring back my preview. On one site that I had this issue with I also needed to dump the cache, but this wasn't the case with another site. Not 100% sure why this causes an issue with the preview for the current user session but worth sharing.

Hope this helps someone!

Replying to westonruter:

I'm thinking this should be closed as invalid, as it is a problem with a caching plugin.

[westonruter]

Replying to colored_rbg:

I was encountering this same issue and I may have found a solution for this, within WP Super Cache > Advanced, disable "Make known users anonymous so they’re served supercached static files.".

Thanks a lot for sharing that. I expect the next version of WP Super Cache to have this fixed: ​https://github.com/Automattic/wp-super-cache/pull/161

[colored_rbg]

Another thing to mention that I noticed when testing, was that this also causes the WP admin bar to disappear on the front-end of a site. So whenever they do an update, hopefully it will resolve multiple issues.

Replying to westonruter:

Replying to colored_rbg:

I was encountering this same issue and I may have found a solution for this, within WP Super Cache > Advanced, disable "Make known users anonymous so they’re served supercached static files.".

Thanks a lot for sharing that. I expect the next version of WP Super Cache to have this fixed: ​https://github.com/Automattic/wp-super-cache/pull/161

[abhishek97]

In my case it was issue with www
as soon as I removed www, it started working...

Although I also WP Super Cache, But WP Super was not culprit in my case..

[westonruter]

I think I know what the problem is: authentication cookies. When the domain doesn't match, the auth cookies may not be set, and if the changeset doesn't exist a non-authenticated user is presented with this message.

[westonruter]

Can anyone confirm whether this is a new issue in 4.7 or not? I'm attempting in 4.6 and I'm getting an endless loop of asking me to login in the preview. I have set up my test site with:

• home: http://www.src.wordpress-develop.dev
• siteurl: http://admin.src.wordpress-develop.dev

So I'm also unable to see the preview in 4.6, although a different symptom surfaces in 4.7, in both cases its due to cross-domain authentication.

[westonruter]

So in the end, it seems that in lieu of having a domain mapping plugin, it seems that core just doesn't work properly when the domain differs between the siteurl and home (a difference of http: vs https: is accomodated), and this appears to have been the case in customizer's inception.

If anyone can determine if this is a regression in any way in 4.7 that would be helpful. If the issue happened in 4.6 as well, as I found, then this issue may indeed be wontfix.

Replying to asalce:

​https://codex.wordpress.org/Changing_The_Site_URL
The "Site Address (URL)" setting is the address you want people to type in their browser to reach your WordPress blog.

"Many people want WordPress to power their website's root (e.g. ​http://example.com) but they don't want all of the WordPress files cluttering up their root directory. WordPress allows you to install it into a subdirectory, but have your website served from the website root."

I think the issue was just a mis-configuration like @pagelab mentioned, and a misunderstanding of what "Site Address (URL)" means from my part. I was using "Site Address (URL)" as a URL for my website's homepage, which is not running on WordPress. WP site_url and home_url should be relatively the same, your "Site Address (URL)" should be pulling up your WP "front page" or the customizer is not going to work.

@westonruter If the above is correct, then this may be a non-issue. nothing to patch here :)

[westonruter]

That being said, I'm confused then as to why there is code in the customizer for is_cross_domain() at all, if a cross-domain iframe has never worked.

[ocean90]

I just stumbled upon this. From first looking I disagree with wontfix. I remember that we put a lot of work into this to make it working properly, related tickets are #20582 and #20507.

@westonruter Could it be because https://core.trac.wordpress.org/browser/tags/4.6.2/src/wp-admin/js/customize-controls.js?marks=2990#L2986 no longer exists since 4.7? Also, the position of the send_origin_headers() call looks odd, I think it should be at the same position as before.

Edit: I just downgraded an affected site to 4.6.3 and it's still kind of broken. Instead of the "non existing changeset UUID" error I get the login form.

[westonruter]

Replying to ocean90:

I just stumbled upon this. From first looking I disagree with wontfix. I remember that we put a lot of work into this to make it working properly, related tickets are #20582 and #20507.

OK, thanks a lot for your input here!

@westonruter Could it be because https://core.trac.wordpress.org/browser/tags/4.6.2/src/wp-admin/js/customize-controls.js?marks=2990#L2986 no longer exists since 4.7?

The content for the customizer preview is no longer being fetched via Ajax, that's right. Instead the preview URL is being loaded directly into the iframe via its src or via a form POST into the iframe window. In both of these cases, credentials should be getting sent if the user has a cookie set on the frontend, right? However, if I try accessing the wp-admin on the siteurl domain and log-in, no cookie gets set on the home domain, so I don't see how credentials would be getting passed even over Ajax withCredentials. See missing-cookie-request-header.png​.

Also, the position of the send_origin_headers() call looks odd, I think it should be at the same position as before.

Yeah, you're probably right. Nevertheless, I think that only matters for Ajax requests since only XHR requests include the Origin: header AFAIK. Non-XHR requests do not include Origin though they may include Referer.

Edit: I just downgraded an affected site to 4.6.3 and it's still kind of broken. Instead of the "non existing changeset UUID" error I get the login form.

This is what I see as well. Going back even to 4.3. It seems cross-domain support has been broken for some time.

It seems that in both the case of XHR (using withCredentials) and non-XHR (regular browser GET and POST requests) there needs to ensure that the user has also authenticated on the home domain to ensure auth cookies are present. This is probably much more secure than my original suggestion to add some auth token to the query params that get added to customizer preview URLs, since they would then be able to be read by any script on the page and could potentially be used by a 3rd party to gain access. Better to ensure that HttpOnly cookies are used.

[westonruter]

One possible solution is to take the approach by post previews in #16776 which is to just force the customizer to always use the siteurl for loading the site in the customizer preview. This would, however, invalidate the need for any cross-domain logic in the customizer.

[westonruter]

@ocean90 oh, check out #20926, it is exactly describing the issue we're facing again.

[ocean90]

Replying to westonruter:

@ocean90 oh, check out #20926, it is exactly describing the issue we're facing again.

Yeah, that's the one I was looking for.

[flomei]

Is there any way to fix this until a patch will be applied to the Core? This is currently breaking some client sites, so even a temporary patch would be welcome.

[westonruter]

@flomei give this a try: ​https://gist.github.com/westonruter/a9c6841ba7f28192e3eb7d90c9316e75

[flomei]

@westonruter This does (not yet) work for me. I am using a multisite environment, so probably DOMAIN_CURRENT_SITE from the wp-config.php should be added to the allowed URLs, too, as my backend is reachable from that URL and not the one of the single site.

Would fix it myself but I don´t get it to work, could you have another look at it? Thanks!

[westonruter]

@flomei Sorry, I don't see why it being multisite would impact the solution. It works for me locally when I have set the home and siteurl do different domains (on a single site).

[mikewagz]

For what it's worth, I am also experiencing this "Non-existent changeset UUID" error in a fresh multisite install, but only on the primary domain. All sub-sites are able to access the Customize interface normally. Note that with multisite installs, there is not the option to change the primary domain's home/siteurl to be different from one another (I don't think), as the Site Address setting is locked in Sites->Edit.

@westonruter - where would I add this workaround code?

Thanks for looking into this guys.

[westonruter]

@mikewagz the workaround code is just a plugin. You can drop it into mu-plugins.

[mikewagz]

@westonruter - Thanks for the quick response! However it appears the workaround did not solve it in my case. If it helps, the JS console call to

http://www.mydomain.com/?customize_changeset_uuid=<uuid>

returns a 500 with the "Non-existent changeset UUID." error message.

Let me know if I can provide any more info to help debug!

[westonruter]

@mikewagz can you share the details on your multisite setup? What are the URLs you have assigned to the primary site vs the sub-sites? Is it a subdomain installation or subdirectory installation? Is the home URL for the primary site the same as the admin URL for the primary site?

[westonruter]

I was able to access the customizer as expected on the primary site and a sub-site.

I enabled subdomain multisite and created a subsite via:

wp core multisite-convert --subdomains
wp site create --slug=subsite

[mikewagz]

@westonruter - Here's some details:

• Our multisite install is at hosting.mydomain.com, using subdomains. I dropped the latest unzipped Wordpress version in and did this in wp-config:

/* Multisite */
define('WP_ALLOW_MULTISITE', true);
// Multisite config
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'hosting.mydomain.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

• The admin is accessed at hosting.mydomain.com/wp-admin

• Sub-sites are accessible (and the customizer functions as expected) via demo.hosting.mydomain.com. We are not yet mapping other domains to our sub-sites.

If it matters, we have a couple DNS records at play here to act as catch-alls for our unassigned subdomains:

          A     hosting      <IP ADDRESS OF OUR HOST>
CNAME     *.hosting    hosting.mydomain.com
CNAME     *                 hosting.mydomain.com
CNAME     www          <Heroku DNS URL>

We have a Rails app running on our www subdomain and will be using a couple other subdomains (ie dev.mydomain.com) for some sub-sites.

Hopefully that helps, let me know if I can get you anything else. Thank you!

[westonruter]

@mikewagz I'm not able to reproduce the issue on my local multisite setup. Are you saying your primary site has its home set to www.mydomain.com whereas its siteurl is hosting.mydomain.com? If so, how do you have this mapping applied?

My wp-config.php is similarly configured as you:

<?php
define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'src.wordpress-develop.dev' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

My primary site's frontend is accessed via ​http://src.wordpress-develop.dev
My sub-site's frontend is accessed via ​http://a.src.wordpress-develop.dev
(Note the a subdomain for the sub-site.)

I am able to access the customizer preview on my primary site: ​http://src.wordpress-develop.dev/wp-admin/customize.php
As well as via a subsite: ​http://a.src.wordpress-develop.dev/wp-admin/customize.php

This is even without the ​workaround plugin.

Do you have any other plugins involved active?

[mikewagz]

You're absolutely right @westonruter, I did a fresh install on another domain with an identical setup, everything worked fine.

After digging more, I tried clearing cookies on my browser and it fixed the problem. Apparently some of the back-and-forth configuration options I played with during initial setup (subfolder vs subdomain, adding domain mapping, etc) left a bad cookie in place, which caused the UUID issue.

All is well now. Thanks for the time you spent looking into this!

[flomei]

I am back on this. I cleared cookies but that did not change anything. My multisite is running in subfolder mode and I am using this plugin for Domain Mapping: ​https://de.wordpress.org/plugins/wordpress-mu-domain-mapping/

Maybe that is part of the problem? Will give it a try later.

[flomei]

Ok, I did some testing.

Subfolder sites work fine with the Customizer, once I have a domain mapped to them it won´t work anymore.

This is okay for testing or building pages, but not for maintaining them in live mode.

[DamienWilson]

Just to say that I had this issue too. Thanks for submitting the workaround plugin.

Issue: a rouge cookie in my case.

[ocean90]

#39904 was marked as a duplicate.

[genevish-graphics]

Hi All! Just found this thread after having the issue with the customizer not loading. My clients URLs are set differently. If I install the workaround plugin, will it do anything to the site? Just install it as a reg plugin and the customizer will load? Have never installed a workaround plugin and just want to be sure I can safely install this on my clients website. Thank you!

[westonruter]

@genevish-graphics the ​workaround plugin is designed to only rewrite the site's URL to match the admin URL only in the context of the customizer. If the user is not in the customizer, it should have no effect and it shouldn't make any permanent changes. As always, the code is licensed GPL v2, so there is no warranty or guarantee. It is always best to test out new plugins on a staging environment and not on your live production environment.

[anonymized_6666466]

Hello, the plugin seems to be working, however I'm getting some CSP issues.

about:blank:1 Refused to display 'customize_changeset_uuid=6d87ad07-d7a0-40e9-a313-a633e95a3800&customize_theme=Divi&customize_messenger_channel=preview-0' in a frame because an ancestor violates the following Content Security Policy directive: "frame-ancestors ​https://domain.com".

Trying to set the frame-ancestors via NGiNX add-header, but it seems like something else maybe wordpress is defining "content-security-policy:frame-ancestors ​https://domain.com"

Just wondering if anyone else is having the issue.

[westonruter]

@jordantrask WordPress adds the CSP header itself in WP_Customize_Manager:: filter_iframe_security_headers (): ​https://github.com/xwp/wordpress-develop/blob/4.7.3/src/wp-includes/class-wp-customize-manager.php#L1609

Is the ancestor frame not <​https://domain.com>? What is the src of the iframe that is being loaded? The workaround plugin is designed to make the home URL and siteurl be the same.

[anonymized_6666466]

I think I had something weird going on with my testing to the point I was not getting consistent results.

Right now I have domain.com as the primary domain with a subdomain site1.domain.com and a mapped domain domain2.com

I'd like to keep site1.domain.com as the administrative URL so that remote login works (no need to login to each site). Changing the values of home or siteurl doesn't change the outcome of which is "Non-existent changeset UUID."

The only way to get rid of "Non-existent changeset UUID." is to set the mapped domain as the home and siteurl.

Replying to westonruter:

@jordantrask WordPress adds the CSP header itself in WP_Customize_Manager:: filter_iframe_security_headers (): ​https://github.com/xwp/wordpress-develop/blob/4.7.3/src/wp-includes/class-wp-customize-manager.php#L1609

Is the ancestor frame not <​https://domain.com>? What is the src of the iframe that is being loaded? The workaround plugin is designed to make the home URL and siteurl be the same.

[westonruter]

@jordantrask the workaround plugin is supposed to make sure that when you are in the customizer, it will force the preview to load the frontend of the site in the preview loads from the same domain as the as the admin where customize.php is served from. Note that I recall someone had to clear their cookies after activating the plugin.

[anonymized_6666466]

@westonruter yea, that's not happening right now, instead it's serving from the mapped domain, not the subdomain of the site.

[anonymized_6666466]

@westonruter actually, I have this somewhat working. So the main domain is domain.com and the new site is site1.domain.com and the domain for the site is domain2.com

If I remove the domain mapping plugin, and Sites->Edit (site1.domain.com)->Settings and set home to domain2.com the customizer works!

[desrosj]

Punting because no patch has been written yet. Can be pulled in if someone is able to provide one.

[dvansoye]

Replying to westonruter:
Hi. I'm not as technical and have had a little trouble following this thread.

I was getting the error "Non-existent changeset UUID".
I'm not using multisite.
My home and siteurl are the same.
I am using WP Super Cache.

I was able to use the customizer to work after deactivating the WP Super Cache plugin.

Questions:

1. Will the fix be made to Core or another plugin/component?
2. I see that the milestone is set to 4.9. Is that right around the corner or will I have to

TL;DR: I'm fine with the workaround (deactivating WP Super Cache). But, I would like the problem to be fixed eventually in core. Just want to know if I got it all wrong and should be opening a ticket with the WP Super Cache folks.

[westonruter]

@dvansoye hi, I do suggest you open an issue with ​WP Super Cache.

I had submitted a ​fix which was merged in 1.4.9, but it may not have gone far enough if you're using 1.4.9 or later.

[rkennybju]

@westonruter, thank you for the patch, however we just tried applying it in our environment and cleared our cookies, but the problem persists. We have a multisite environment running in Word press 4.7.2. We are NOT running WP Super Cache. The plugins we have active are:

• Akismet
• Google Analytics by Yoast
• iThemes Security
• MCE Table Buttons
• Shortn.It
• User Switching
• WordPress MU Domain Mapping

Please let me know if there is any other information I can provide to help work toward a resolution. Thank you!