| 1 | | Milestoning for tracking. |
| | 1 | 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). |
| | 2 | |
| | 3 | 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. |
| | 4 | |
| | 5 | 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. |