[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:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  administration
-------------------------+-----------------------------
Changes (by westonruter):

 * milestone:  Awaiting Review => Future Release


Old description:

> == Current behavior ==
>
> When you upload attachments via a Customizer session they are:
>
> 1. Added to the filesystem.
> 2. Saved to the database as a new post.
> 3. Immediately visible in the Media Library to all other logged in users.
>
> == Desired behavior ==
>
> Attachments that are uploaded during a Customizer session should not be
> published, or even visible by other logged in users, until the user
> decides to publish the changes.
>
> == Possible idea
>
> Until Customizer changed are published, all `attachment` posts that have
> been uploaded inside the Customizer could have their post status set to
> `auto-draft` rather than `inherit`. This will make them invisible inside
> the Media Library from other logged in users.
>
> All `attachment` posts uploaded during the Customizer session could be
> stored inside the new Customizer transaction, and the Media Library query
> could be made to only show those uploads during the current unpublished
> session.
>
> == Publish or Discard
>
> If a transaction is '''published''', then the post status on these
> `attachment` IDs can be set to `inherit`, making them visible inside in
> the Media Library like normal.
>
> If a transaction is '''discarded''', then the `attachment` IDs can be
> force deleted via `wp_delete_attachment( $ID, true )` which will not only
> delete them from the database, but also from the filesystem.

New description:

 == Current behavior ==

 When you upload attachments via a Customizer session they are:

 1. Added to the filesystem.
 2. Saved to the database as a new post.
 3. Immediately visible in the Media Library to all other logged in users.

 == Desired behavior ==

 Attachments that are uploaded during a Customizer session should not be
 published, or even visible by other logged in users, until the user
 decides to publish the changes.

 == Possible idea

 Until Customizer changed are published, all `attachment` posts that have
 been uploaded inside the Customizer could have their post status set to
 `auto-draft` rather than `inherit`. This will make them invisible inside
 the Media Library from other logged in users.

 All `attachment` posts uploaded during the Customizer session could be
 stored inside the new Customizer transaction, and the Media Library query
 could be made to only show those uploads during the current unpublished
 session.

 == Publish or Discard

 If a transaction (customizer changes) is '''published''', then the post
 status on these `attachment` IDs can be set to `inherit`, making them
 visible inside in the Media Library like normal.

 If a transaction (the customizer changes) is '''discarded''', then the
 `attachment` IDs can be force deleted via `wp_delete_attachment( $ID, true
 )` which will not only delete them from the database, but also from the
 filesystem.

--

Comment:

 This is indeed an issue ever since the Media Library modal was introduced
 in the customizer. The Media Library JS is not Customizer-aware. Beyond
 uploading new attachments, there is also the issue whereby if you edit an
 attachment's fields (e.g. title or caption) then these changes get saved
 immediately as soon as you blur the field. All of these changes need to be
 added to the Customizer state to then be persisted if the user hits Save &
 Publish.

 As for deleting attachments that are never published, what could done is
 to upload them with an `auto-draft` status (as opposed to `inherit`) and
 then only transition them to `auto-draft` once the customizer changes are
 saved. This would be taking the same approach as [https://github.com/xwp
 /wp-customize-posts Customize Posts] and the newly-committed #34923 which
 uses `auto-draft` posts as placeholders. Posts with `auto-draft` status
 are automatically garbage-collected after 7 days, though I'm not sure if
 an `attachment` post with an `auto-draft` status will get its associated
 uploaded file also deleted.

 Custom fields in the media modal seem to be the most challenging to me.
 Plugins will have to take care to support the customizer usage. In
 particular, custom fields added to the media modal normally get saved by
 plugins via the `attachment_fields_to_save` action. Plugins would need to
 not do that in a customizer context, but instead add it to the customizer
 state and defer the save until the customizer state is published.

 Queries for attachments in the media library would also need to include
 all existing `attachment` posts that have `inherit` status ''OR'' which
 are `auto-draft` and which have an `ID` that was created in the current
 customizer session. So that `attachment` SQL query would need to be
 updated to account for that.

 All in all, I think it's doable, but it will take some serious R&D.

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