Make WordPress Core

Opened 4 years ago

Last modified 3 years ago

#37887 new enhancement

Make attachments atomic until a Customizer session is published — at Version 1

Reported by: fjarrett Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.7
Component: Customize Keywords: needs-patch
Focuses: administration Cc:

Description (last modified by westonruter)

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.

Change History (1)

#1 @westonruter
4 years ago

  • Description modified (diff)
  • Milestone changed from Awaiting Review to Future Release

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

Note: See TracTickets for help on using tickets.