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

WordPress Trac noreply at wordpress.org
Fri Jan 13 20:39:26 UTC 2017


#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:5 azaozz]:
 > Is there any advantage in hiding uploaded files from other trusted
 users? I don't see any. Similar case is when a file is uploaded while the
 user composes a draft. We don't hide the upload until the post is
 published.

 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.

 > I'm also not sure if it is a good idea to remove or delete a file that
 was uploaded while the customizer was used. This changes the current file
 uploading behavior for no good reason: the users are still seeing the
 (familiar) media popup, but files they upload may disappear later. This
 can be taken as error and is pretty bad UX.

 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. 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. Also consider media attributes, like titles and
 descriptions: currently the media modal will write changes to these fields
 back to the database immediately. However, a user may want to preview how
 an attachment title change appears on the site and when in the customizer
 (live preview session) they should expect that any change made would not
 go live until they hit Save & Publish.

 > Also, if hiding of uploads is really really needed by somebody, it
 should be a plugin. Seems it should be implemented by adding these
 attachments to a "special" taxonomy (or similar) and excluding them from
 the Media library. The proposed solution is needlessly complex.

 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). A first step for implementing
 this was done for theme starter content in fact for 4.7 (via #38615). When
 starter content is loaded into a customization session, none of the
 changes go live until the user hits Save & Publish, and this includes any
 images uploaded to the media library for use as featured images for
 posts/pages in the starter content. The starter content
 posts/pages/attachments are inserted with `auto-draft` status so that they
 will be garbage-collected if the user never publishes the changes. When
 they do publish the changes, then this is when the status is set to
 `publish` (or `inherit`).

 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.

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


More information about the wp-trac mailing list