WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 2 years 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 3 years ago.
Copie de mon écran
versuch.wmv (58.4 KB) - added by sixsigmablackbelt 3 years ago.
log on
missing-cookie-request-header.png (676.6 KB) - added by westonruter 3 years ago.

Download all attachments as: .zip

Change History (82)

@RomainVB
3 years ago

Copie de mon écran

#1 @westonruter
3 years 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
3 years ago

#39161 was marked as a duplicate.

#3 @sixsigmablackbelt
3 years 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
3 years 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
3 years 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
3 years ago

log on

#6 @sixsigmablackbelt
3 years 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
3 years ago

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

#9 @westonruter
3 years 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
3 years 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
3 years 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
3 years ago

@westonruter what you mean with configuration?

#13 @westonruter
3 years ago

@sixsigmablackbelt your WP Super Cache configuration/settings.

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


3 years ago

#15 follow-ups: @westonruter
3 years 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
3 years 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
3 years ago

#39420 was marked as a duplicate.

#18 @pagelab
3 years 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
3 years 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
3 years 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
3 years 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 3 years ago by pagelab (previous) (diff)

#22 follow-up: @asalce
3 years 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
3 years 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 3 years ago by pagelab (previous) (diff)

#24 @westonruter
3 years ago

  • Keywords needs-patch added; reporter-feedback removed

#25 follow-ups: @asalce
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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.


3 years ago

#37 follow-up: @ocean90
3 years 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 3 years ago by ocean90 (previous) (diff)

#38 in reply to: ↑ 37 @westonruter
3 years 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
3 years 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
3 years ago

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

#41 in reply to: ↑ 40 @ocean90
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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 3 years ago by mikewagz (previous) (diff)

#47 @westonruter
3 years ago

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

#48 @mikewagz
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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
3 years 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.


3 years ago

#58 @ocean90
3 years ago

#39904 was marked as a duplicate.

#59 @westonruter
3 years 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.


3 years ago

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


2 years ago

#62 @genevish-graphics
2 years 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
2 years 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.


2 years ago

#65 @swissspidy
2 years ago

  • Milestone changed from 4.7.4 to 4.7.5

#66 @jordantrask
2 years 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
2 years 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
2 years 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
2 years 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
2 years 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
2 years 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.


2 years ago

#73 @desrosj
2 years 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
2 years ago

  • Milestone changed from 4.8.1 to 4.9

#75 in reply to: ↑ 74 @dvansoye
2 years 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
2 years 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.


2 years ago

#78 @melchoyce
2 years ago

  • Milestone changed from 4.9 to Future Release

#79 @rkennybju
2 years 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.