[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 azaozz):

 Replying to [comment:6 westonruter]:
 > Yes, though it's not about trust. If the files were uploaded as part of
 a live preview session, one which may be thrown away without ever wanting
 them to go live, then the uploaded file shouldn't appear when outside of
 that customization session. Consider a user who wants to see how a new
 radical design to their company logo appears on the site. They go into the
 customizer, go to change the custom logo and upload the new one. They then
 see how it appears on the site and decide it looks horrible and they want
 to abandon the changes. Currently in the customizer, this bad uploaded
 image would persist in the media library. But I think, as this ticket
 proposes, that the bad logo image should be eliminated when customized
 changes are abandoned.

 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.

 Also, what if an existing file is used in the same session? Don't think we
 would want to delete it. Why should the behavior be any different?

 There is a well established workflow when uploading files. Changing it
 just because a file is uploaded from another place is not good UX imho.
 Having "auto-disappearing" images in the media popup/library is bad UX.

 I agree that there are user cases when auto-deleting/removing an upload
 makes sense, logically. But there are cases when it doesn't. The more
 important (UX) part of it is that the users will not expect uploads to
 disappear from the media library on their own.

 > 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".

 > I think that users wouldn't necessarily expect that uploading an image
 via the media modal inside the customizer should result in that upload
 persisting.

 Don't think so. There is nothing to suggest to the users that the
 (familiar) media modal will work differently. Changing the way it works at
 different places in wp-admin is pretty tough. Not telling the users that
 it works differently is unacceptable.

 > So it's not just hiding uploads that's in scope here. It's that any
 change made (including uploads) via the media modal should be encapsulated
 in a customization session (customize changeset).

 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?

 > I think think this should be part of core because it's bringing live
 preview to another area of WordPress and further minimizing the poor “save
 & surprise” user experience.

 Don't think changing how the media modal works, and/or auto-deleting
 attachments has anything to do with "live" or "non-live" previews. I think
 it will bring even more unexpected/bad UX to the customizer.

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