Changesets : opening a link from the preview as a new browser tab can be confusing

[nikeo]

I've discussed about the customize changeset feature with another user, and it appeared that we've had the same doubts about one thing : opening a link from the preview in another tab can lead to several confusions.

A very common workflow when working in the customizer is to makes changes, and then open a link from the preview in another browser tab.
There can be various reasons to do that, but I usually do it to either see the site without the panel ( it could be hidden with hide control but I don't use this button ), compare my current customizations with the published design, access to other admin menus from the admin bar.
I'm opening this ticket because my guess is that I'm not an isolated case, and that many users are following the same workflow when customizing.

With the changeset introduction, opening a page in a new tab from the previewer does the following :

1. there's no admin bar despite the fact that I'm logged in, and I'm not sure why it's been removed. Chances are that some users will report it as a bug.
2. the page displays un-published changes. But since there's no information stating that's it's unsaved, I can totally forget to save my customizations and then lose them after a week of no modifications.
3. all links of this page are disabled. This can be frustrating and not understood when we're out of the customizer context. Chances are that some users will report it as a bug as well.

I understand of course that one of the possibilities offered by the changeset is to share a customized design for unauthenticated users, when a UUID is included in the url. One possible solution to do that might be to provide some sort of "cutomized-share-link" button icon in the panel to copy the current changeset url.

I don't want to sound too negative there. Let's be clear about all features and opportunities brought by the changeset : this is really smart and GREAT to use !

Do other developers and users have the same feeling about the described problem ?

[nikeo]

Typo :

A very common workflow when working in the customizer is to make changes, and then open a link from the preview in another browser tab.

[westonruter]

@nikeo That's interesting as I've never heard of or seen someone open a link in the preview in a new tab as part of their workflow. I can see how that would be a useful, but it does seem like a hack. For a permanent solution in the future I'll note that that Customize Snapshots plugin (currently being refactored for 4.7-compat) has a dedicated link to open the current preview into a new window without the iframe. See also ​https://github.com/xwp/wp-customize-snapshots/issues/101

For the time being I think what we could do is simply omit the customize_messenger_channel from being injected into the URL query params for the links in the preview. It is this query parameter that signals that the preview is “passive” to the control of the pane, and thus the admin bar is hidden and any clicks on links will send a url message to the parent window to let it instantiate a new PreviewFrame to load the new URL. The customize_messenger_channel query parameter is already being forcibly added to the URL in wp.customize.Previewer.prototype.run, so it's not necessary to also have it in the query params in the preview.

[westonruter]

@nikeo the difference here in ≥4.7, of course, would be that opening the link in a new window would result in any customized state being applied whereas in your workflow in ≤4.6 the new window would be devoid of any customized state applied.

[westonruter]

@nikeo give 38867.0.diff​ a try. This is approach is probably the safest. I realized that we the customize_messenger_channel query param shouldn't be omitted from links in the preview in the case that JS is used to navigate to the URL directly without the click handler intercepting the click to send the url to the parent frame.

[nikeo]

Back. I was busy with my little family.

@westonruter I've tested the latest patch. It solves the problems 1 (no admin bar) and 3 (links disabled).

About item 2 ( unpublished changes ), IMHO users should be better informed that they're navigating in a temporary design, not yet published. They currently can only know it by inspecting the urls.

A possible way to solve this, now that the admin bar is back, would be to replace the 'Customize' button on top by 2 buttons :

1. 'Save and Publish' => shouldn't be a problem since we have a $manager instance
2. 'Continue Customizing' => would open the customizer. There could even be a (n days left) next to this text, but it's not very friendly...

Given the risk of losing the customizations already done after 7 days, those buttons should reflect the idea of urgence, why not with a "warning" type color like orange.

Another thought about this : the 7 days delay before trash seems very short. Would it be a problem to extend this delay, before the changeset revision is implemented ?

For a permanent solution in the future I'll note that that Customize Snapshots plugin (currently being refactored for 4.7-compat) has a dedicated link to open the current preview into a new window without the iframe. See also ​https://github.com/xwp/wp-customize-snapshots/issues/101

This feature plugin looks very promising !

[westonruter]

@nikeo yeah, improving the experience for saving persistent drafts that last longer than 7 days would be good, as well as indicating in the admin bar that a changeset is being previewed (both of which are touched on by the Customize Snapshots plugin). However, I think that for 4.7 that the changes in the patch are sufficient for the release. In the next release we can start to incorporate some of the customize changeset features into the frontend, including the admin bar and frontend editing. Agreed? So does the patch get your +1 to close this ticket?

[nikeo]

Replying to westonruter:

@nikeo yeah, improving the experience for saving persistent drafts that last longer than 7 days would be good, as well as indicating in the admin bar that a changeset is being previewed (both of which are touched on by the Customize Snapshots plugin). However, I think that for 4.7 that the changes in the patch are sufficient for the release. In the next release we can start to incorporate some of the customize changeset features into the frontend, including the admin bar and frontend editing. Agreed? So does the patch get your +1 to close this ticket?

OK cool if it's part of Customize Snapshots. Yep fine +1 to close.

[nikeo]

oops did I change the closed status when posting my latest reply ?

[nikeo]

@westonruter wait, the admin bar links are not working

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/203

[westonruter]

@nikeo good catch. Please give 38867.3.diff​ a try. See ​new changes.

[nikeo]

Replying to westonruter:

@nikeo good catch. Please give 38867.3.diff​ a try. See ​new changes.

Works now. I've added the close tag.

[nikeo]

@dd32 Replying to dd32: I should definetely learn how to better use the tags and status of the tickets... :) Thanks for the correction

[westonruter]

In 39332:

Customize: Remove iframe-specific behaviors from customize preview when previewing on frontend and not contained inside iframe.

• Strip out customize_messenger_channel from preview window URL when not contained in iframe.
• Allow interacting with unpreviewable links and forms when previewing customized state on frontend.

See #30937.
Fixes #38867.