[wp-trac] [WordPress Trac] #37887: Make attachments atomic until a Customizer session is published

[WordPress Trac]

#37887: Make attachments atomic until a Customizer session is published
-------------------------+-----------------------------
 Reporter:  fjarrett     |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Customize    |     Version:  4.7
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  administration
-------------------------+-----------------------------

Comment (by westonruter):

 Replying to [comment:9 azaozz]:
 > Still don't think auto-deleting the image is right. It is very easy for
 the user to delete it if they want, or to keep it for later. There is even
 the user case where the user may want to let somebody else see what it
 looks like before setting it as logo.

 The image would only be auto-deleted if there is no reference to the that
 attachment. Since it's suggested here that uploads and attachment changes
 should be encapsulated inside of a customization session (changeset), if
 that changeset is abandoned/deleted then the attachment should also be
 purged. As of 4.7, a user can share the URL to a customizer session (with
 the `changeset_uuid` param intact) with another user so that they can see
 the image applied as the site logo. A user can even share a URL to the
 frontend directly with the `customize_changeset_uuid` param present and
 let an unauthenticated user see how the custom logo appears.

 >> Everything done in the customizer should be understood to be done in a
 preview context. Users should expect that nothing goes live until they hit
 Save & Publish.
 >
 > Yeah, I understand. However imho this is one of the weak points of the
 customizer UI: there is nothing to suggest this behavior. Even the
 opposite, new users often assume that their site *is* the preview and all
 is already "live".

 There is a help (?) icon in the root customizer panel that includes text
 saying, “The Customizer allows you to preview changes to your site before
 publishing them.” If it is not clear to users that the changes made in the
 customizer are non-destructive (and it surely can be made more clear that
 all changes made are ''pending''), this means we need to make this more
 clear, not be OK with some things being destructive (or rather
 constructive) prior to doing Save & Publish.

 > Not sure about that either. What will happen if we add inline
 writing/editing of posts in the customizer "preview"? Are we going to
 change the current publishing workflow just because the post is being
 edited from the customizer iframe? Are we going to delete the post if the
 user doesn't click "Save & Publish"? What about drafts and autosave? How
 are we going to explain that to the users? And most importantly: why?

 Yes. My position is that anything done during customization w/ live
 preview should be non-destructive (non-mutating) until the user explicitly
 wants the changes to go live. This needn't be restricted to the customize
 preview. In the future if we allow entering into a customization session
 from the frontend (i.e. frontend editing) the same principle should apply.
 Everything done to the site should be “staged” in a draft (changeset) that
 goes live once the user is happy with the changes. A missing piece in the
 current customizer implementation is that there is no UI for saving a
 draft of changes: the `customize_changeset` posts created during
 customizer sessions are always created with the `auto-draft` status (as
 well as the posts created for any page/post stubs). Allowing changesets to
 be longer-lived drafts is what #31089 and the [https://github.com/xwp/wp-
 customize-snapshots Customize Snapshots] feature plugin are addressing.

 The customizer certainly needs UX improvements and its UI needs an
 overhaul, and this will be a focus for 2017. But I hold that the more
 aspects of a site to which we can add preview support the better—whether
 this be options, widgets, nav menus, posts/pages, taxonomy terms, media,
 and so on. If media preview support is added as proposed in this ticket,
 then there would certainly need to be UX changes to the media modal.

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