WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 3 years ago

#39128 assigned defect (bug)

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

Reported by: RomainVB Owned by: westonruter
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.

Change History (35)

@RomainVB
4 years ago

Copie de mon écran

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

#39161 was marked as a duplicate.

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

log on

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

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

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

@westonruter what you mean with configuration?

#13 @westonruter
4 years ago

@sixsigmablackbelt your WP Super Cache configuration/settings.

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


4 years ago

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

#39420 was marked as a duplicate.

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

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

#24 @westonruter
4 years ago

  • Keywords needs-patch added; reporter-feedback removed

#25 follow-up: @asalce
4 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
4 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
4 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
4 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
4 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
4 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
4 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
4 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
4 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)
Note: See TracTickets for help on using tickets.