WordPress.org

Make WordPress Core

Opened 18 months ago

Last modified 7 months ago

#39128 assigned defect (bug)

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

Reported by: RomainVB Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.7
Component: Customize Keywords: needs-patch
Focuses: Cc:

Description (last modified by westonruter)

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.

Attachments (3)

2016 12 06 - MESSAGE ERREUR WP.JPG (55.7 KB) - added by RomainVB 18 months ago.
Copie de mon écran
versuch.wmv (58.4 KB) - added by sixsigmablackbelt 18 months ago.
log on
missing-cookie-request-header.png (676.6 KB) - added by westonruter 16 months ago.

Download all attachments as: .zip

Change History (82)

@RomainVB
18 months ago

Copie de mon écran

#1 @westonruter
18 months ago

  • Component changed from Help/About to Customize
  • Keywords reporter-feedback added

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

What theme and plugins are active on your install?

#2 @swissspidy
18 months ago

#39161 was marked as a duplicate.

#3 @sixsigmablackbelt
18 months ago

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

#4 @westonruter
18 months ago

@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?

#5 @westonruter
18 months ago

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
18 months ago

log on

#6 @sixsigmablackbelt
18 months ago

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

#7 @westonruter
18 months ago

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

#9 @westonruter
18 months ago

  • Milestone changed from Awaiting Review to 4.7.1

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?

#10 @sixsigmablackbelt
18 months ago

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

#11 @westonruter
18 months ago

@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

#12 @sixsigmablackbelt
18 months ago

@westonruter what you mean with configuration?

#13 @westonruter
18 months ago

@sixsigmablackbelt your WP Super Cache configuration/settings.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


18 months ago

#15 follow-ups: @westonruter
18 months ago

  • Keywords close added

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

#16 in reply to: ↑ 15 @celloexpressions
17 months ago

  • Milestone 4.7.1 deleted
  • Resolution set to invalid
  • Status changed from new to closed

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.

#17 @dd32
17 months ago

#39420 was marked as a duplicate.

#18 @pagelab
17 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

#19 follow-up: @westonruter
17 months ago

  • Description modified (diff)
  • Keywords close removed
  • Milestone set to 4.7.2

@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?

#20 @pavelevap
17 months ago

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.

#21 in reply to: ↑ 19 @pagelab
16 months ago

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:

http://ubr.link/uploads/PJLu7szyf1/customizer-changeset-bug.png

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

Last edited 16 months ago by pagelab (previous) (diff)

#22 follow-up: @asalce
16 months ago

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

http://i.imgur.com/9HGVgqI.png

http://i.imgur.com/EUFvc28.png

#23 in reply to: ↑ 22 @pagelab
16 months ago

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.

Last edited 16 months ago by pagelab (previous) (diff)

#24 @westonruter
16 months ago

  • Keywords needs-patch added; reporter-feedback removed

#25 follow-ups: @asalce
16 months ago

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 :)

#26 in reply to: ↑ 25 @tiella
16 months ago

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

#27 in reply to: ↑ 15 ; follow-up: @colored_rbg
16 months ago

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.

#28 in reply to: ↑ 27 ; follow-up: @westonruter
16 months ago

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

#29 in reply to: ↑ 28 @colored_rbg
16 months ago

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

#30 @abhishek97
16 months ago

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..

#31 @westonruter
16 months ago

  • Owner set to westonruter
  • Status changed from reopened to accepted

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.

#32 @westonruter
16 months ago

  • Keywords reporter-feedback added

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.

#33 @westonruter
16 months ago

  • Description modified (diff)
  • Summary changed from ERROR MESSAGE "non existing changeset UUID" to Customize: Preview fails to load when domain mapping in use (home/siteurl domain mismatch)

#34 in reply to: ↑ 25 @westonruter
16 months ago

  • Keywords needs-patch removed
  • Owner westonruter deleted
  • Status changed from accepted to assigned

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 :)

#35 @westonruter
16 months ago

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.

This ticket was mentioned in Slack in #core by westonruter. View the logs.


16 months ago

#37 follow-up: @ocean90
16 months ago

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.

Last edited 16 months ago by ocean90 (previous) (diff)

#38 in reply to: ↑ 37 @westonruter
16 months ago

  • Keywords needs-patch added; reporter-feedback removed

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.

#39 @westonruter
16 months ago

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.

#40 follow-up: @westonruter
16 months ago

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

#41 in reply to: ↑ 40 @ocean90
16 months ago

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.

#42 @flomei
16 months ago

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.

#44 in reply to: ↑ 43 @flomei
16 months ago

@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!

#45 @westonruter
16 months ago

@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).

#46 @mikewagz
16 months ago

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.

Last edited 16 months ago by mikewagz (previous) (diff)

#47 @westonruter
16 months ago

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

#48 @mikewagz
16 months ago

@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!

#49 @westonruter
16 months ago

@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?

#50 @westonruter
16 months ago

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

#51 @mikewagz
16 months ago

@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!

#52 @westonruter
16 months ago

@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?

#53 @mikewagz
16 months ago

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!

#54 @flomei
16 months ago

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.

#55 @flomei
16 months ago

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.

#56 @DamienWilson
16 months ago

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

Issue: a rouge cookie in my case.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


15 months ago

#58 @ocean90
15 months ago

#39904 was marked as a duplicate.

#59 @westonruter
15 months ago

  • Milestone changed from 4.7.3 to 4.7.4

This ticket was mentioned in Slack in #core-customize by swissspidy. View the logs.


14 months ago

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


14 months ago

#62 @genevish-graphics
14 months ago

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!

#63 @westonruter
14 months ago

@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.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


13 months ago

#65 @swissspidy
13 months ago

  • Milestone changed from 4.7.4 to 4.7.5

#66 @jordantrask
13 months ago

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.

#67 follow-up: @westonruter
13 months ago

@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.

#68 in reply to: ↑ 67 @jordantrask
13 months ago

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.

#69 follow-ups: @westonruter
13 months ago

@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.

#70 in reply to: ↑ 69 @jordantrask
13 months ago

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

#71 in reply to: ↑ 69 @jordantrask
13 months ago

@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!

This ticket was mentioned in Slack in #core by desrosj. View the logs.


13 months ago

#73 @desrosj
13 months ago

  • Milestone changed from 4.7.5 to 4.8.1

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

#74 follow-up: @westonruter
12 months ago

  • Milestone changed from 4.8.1 to 4.9

#75 in reply to: ↑ 74 @dvansoye
8 months ago

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.

#76 @westonruter
8 months ago

@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.

This ticket was mentioned in Slack in #core by melchoyce. View the logs.


7 months ago

#78 @melchoyce
7 months ago

  • Milestone changed from 4.9 to Future Release

#79 @rkennybju
7 months ago

@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!

Note: See TracTickets for help on using tickets.