Make WordPress Core

Opened 7 years ago

Last modified 7 years ago

#40403 new enhancement

Media: Allow disabling of auto-save for attachment changes in Media Library

Reported by: westonruter's profile westonruter Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: Cc:

Description (last modified by westonruter)

When in the select frame of the media library and the user has selected an attachment, the fields for that attachment including the title, caption, and description can all be modified. The user may very well be expecting that the changes they are making to be localized to the current context for which they are inserting the image. For example, a user may want to provide a unique caption for an image when selecting it into one post vs the caption for the image when it is inserted into another post. Nevertheless, when the user does make a change to the caption, it will get written into the underlying attachment post and will thus change the caption on the attachment single template and any galleries in which the image appears.

These are the fields in question:

All of this to say that the behavior to auto-save back changes to an attachment as changes are made in the media library should be able to be disabled, or should perhaps be disabled by default if not in a management context on the Media admin screen. Also, when the media library is opened in the customizer, a user should expect all changes to be previewable without impacting the site before hitting Save & Publish. The customizer is supposed to guard against the “save and surprise” experience. In the case of the Media Library, it can be even worse because it is “auto-save and surprise” and the auto-save behavior isn't even stated. So if auto-save isn't disabled by default in the media library across WordPress in a non-management context, then at least it seems it should be disabled in the context of the customizer.

The conversation for this started in the context of the image widget, and unexpected behavior for when modifying fields in the select frame versus modifying fields in the edit frame (which, as in the edit post screen, do not auto-save but are local to the post being edited). See

See also #37887, which would still allow for changes to be made in the media library, but for the changes to defer to being published until the user hits Save & Publish in the Customizer.

Attachments (2)

attachment-fields-in-media-library-select-frame.png (362.4 KB) - added by westonruter 7 years ago. (671.2 KB) - added by westonruter 7 years ago.
Auto-save indicator in edit-attachment-frame

Download all attachments as: .zip

Change History (11)

#1 @westonruter
7 years ago

  • Description modified (diff)

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.

7 years ago

#3 @adamsilverstein
7 years ago

@westonruter I'm not certain what the best approach to making this sync event optional, I'm still looking into that. Would this be something turned off for a single media modal, the entire session, or a specific image?

In the meantime, a functional approach is to replace the core object before opening the modal (then replace it when the modal is closed). For example, for the media widget you could do this like this

#4 @westonruter
7 years ago

@adamsilverstein Probably not turned off for one specific image, but I think it makes sense to turn off when in the customizer generally, and also on the edit post screen. Basically I think it should be only enabled if your on the media library in the admin, but I'm sure others will disagree. For our purposes with the media widget, the scenario would be to disable syncing for an instantiation of the media modal. So for example when selecting an image from the media library for the image widget, we would like to turn off syncing just during that lifecycle of the media modal (at least), like you implemented via that workaround there.

I guess we need more user input on whether or not editing of attachment posts via the media select frame is a key use case, or if users intending to make a permanent change to the underlying attachment will instead go to the Media Library admin screen.

7 years ago

Auto-save indicator in edit-attachment-frame

#5 follow-up: @westonruter
7 years ago

I just found that there actually is an auto-save indicator when making changes via the media frame on the Media Library screen (edit-attachment-frame). See

#6 in reply to: ↑ 5 @adamsilverstein
7 years ago

Replying to westonruter:

I just found that there actually is an auto-save indicator when making changes via the media frame on the Media Library screen (edit-attachment-frame). See

Yea, that's easy to miss, especially locally where the save happens so quickly. Ideally, these confirmations would be closer to the fields or somehow more visible.

#7 @joemcgill
7 years ago

This has always been one of the more confusing parts of the image workflows in from my point of view. Any time the Post frame uses the insert state, edits to those fields modify the underlying attachment, but if the same image is edited after being inserted, uses the image-details state, in which changes are only saved at the post level (i.e., in the image markup in the post, but not the media library).

This is super confusing UX and can easily lead to unintended consequences when someone uses an image on multiple posts and inadvertently does something like changing the caption in one post, not realizing they've just changed it on another post as well.

What makes this trickier is that you can also upload new images while in the insert state, after which you should expect to be able to edit the data associated with that image before inserting it into whatever context you're in and have those changes saved to the media library.

I have hopes that we can fix this UX issue as part of the Gutenberg project by separating the management of post-level properties from media library properties. In the mean time, I don't think we should disable this syncing behavior because I think that would lead to even greater confusion.

This ticket was mentioned in Slack in #design by westonruter. View the logs.

7 years ago

#9 @westonruter
7 years ago

In 41872:

Widgets: Update preview for Gallery widget when one of its attachments is modified in the media modal, outside the customized state.

  • Ensure that changes to captions are shown in preview when modified in media modal.
  • Also keep wp.customize.widgetsPreview.renderedWidgets updated when widgets are added or removed.

See #41914, #37887, #40403.
Fixes #41979.

Note: See TracTickets for help on using tickets.