Uncheck the DM setting for running the dashboard in the original domain.
So the expectation is that if you use that setting, the Customizer is broken? We’ve been running this plugin for a long time, and this issue only recently came up. This really should be resolved.
+ 1 on finding a solution
Since I do not frequently use the customizer it took me a while to find out. Initially I searched for the error- Non-existent changeset UUID which also affects people that do not have the same setting for site and home url https://wordpress.org/support/topic/non-existent-changeset-uuid/
More testing shows that on MU sites all mapped domains are unable to use the customizer preview.
As this is a new issue there must be something changed in the customizer (lots have changed) – and just unchecking “Redirect administration pages to site’s original domain” is a solution. Not that it solves anything but circumvent the bug…
Changing that setting takes away a lot of the comfort of work with MU, so I really hope someone can look int this.
-
This reply was modified 8 years, 5 months ago by
Webtaurus.
So the expectation is that if you use that setting, the Customizer is broken?
The customizer worked until it was moved to a dashboard URL a few versions ago. If the dashboard is running in the unmapped URL and the front end is running the mapped domain then browser XSS security blocks the customizer scripts.
If you use the core URL editing feature in network admin instead of domain mapping then the customizer works.
Hi Ron, Thanks for you input! Does that mean that the plugin has become superfluous? Or can some of the options only be achieved with the plugin?
@and_or The only thing this plugin does that the core feature does not is redirect the unmapped URLs to the mapped URLs (which only matters if you are mapping a well established site). You can achieve that with a rewrite rule in your .htaccess / web server config.
Something did change. Like @joshftribus mentioned $_POST[‘customize’] is no longer set. I think this has changed a number of times over the years, may have been in $_GET in the past. (Don’t quote me because I’m writing this away from my machine but I have hit this XSS issue a few times and I know I’ve had to change my own is_customizer logic a number of times)
It would be ideal if this plugin accounted for this and used the function (again as @joshftribus mentioned). I have personally overwritten the redirect_mapped_domain function as I need to do a few other things during remapping, this is just one of them.
I do have a rule of not changing plugins, but this one changes rarely and plays such a critical role in my set up that I feel I need to be more hands on.
Something did change. Like @joshftribus mentioned $_POST[‘customize’] is no longer set.
Yes, that changed several versions before the customizer was moved to the dashboard. The development version of this plugin did correct the ‘customize’ variable name but correcting the variable doesn’t eliminate the XSS blocking in the browser.
