[wp-trac] [WordPress Trac] #30937: Add Customizer state persistence in changesets (formerly “transactions”)

[WordPress Trac]

#30937: Add Customizer state persistence in changesets (formerly “transactions”)
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
     Type:  feature request                      |  westonruter
 Priority:  high                                 |      Status:  assigned
Component:  Customize                            |   Milestone:  4.7
 Severity:  normal                               |     Version:
 Keywords:  has-patch needs-testing needs-unit-  |  Resolution:
  tests                                          |     Focuses:
-------------------------------------------------+-------------------------

Comment (by westonruter):

 @celloexpressions thanks for reviewing. I'm not able, however, to
 reproduce these issues you reported:

 > - Persistent preview refreshes when adding a widget.
 > - Changing a menu location (via the select input) cause the customizer
 to close at one point, prompting the AYS, which I declined. On the plus
 side, the settings were still there when I navigated back, but they had
 not been published.
 > - I got stuck in another set of persistent preview refreshes when
 removing menu items.
 > - Across a theme switch, the settings from the previous theme seem to be
 applied to the new theme (header image, menus, etc.). A theme switch
 should start a fresh changeset unless the theme in question had previous
 unpublished changes that should be restored, with the previous changeset
 being saved as a draft that could be restored later. There would need to
 be a distinction between `option`s and `theme_mod`s here too.

 I think we'll need to do a screenshare so I can see what is going on.

 I did however fix this issue:

 > - Trying to navigate to an external link causes the preview to refresh
 persistently (in one test) or navigates to the external site momentarily
 before redirecting back, or another time it just reloaded the current
 page.

 Now when you hover over a link (or form) in the preview that is not
 previewable, the link will get a `cursor: not-allowed` and
 `event.preventDefault()`. Also, in regards to accessibility, the
 `wp.a11y.speak()` will be invoked to inform the user why clicking the link
 or submitting the form is not having an effect. This will finally mean
 that the edit post links, admin links, and external links will provide
 some hints to the user as to why clicking on them does nothing.

 Here's a full list of the new changes pushed up to the feature branch:

 * Add Previewer.ready method to replace anonymous closures
 * Use explicit previewer variable instead of this or self
 * Use links for URL parsing instead of regular expressions
 * Make sure links in preview use HTTPS if parent frame uses HTTPS
 * Normalize nav_menu_item URL scheme when parent frame is HTTPS to prevent
 selective refresh upon initial page load
 * Ensure frontend can only be loaded into iframe for customizer preview
 * Show expected error message or re-auth when accessing customize.php as
 unauth'ed user
 * Add is_cross_domain and get_allowed_urls methods; export both into
 preview as well as pane
 * Disallow users from clicking non-previewable links or submitting non-
 previewable forms
 * Fix existing phpunit tests

 See https://github.com/xwp/wordpress-develop/pull/61

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30937#comment:61>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform