[wp-trac] [WordPress Trac] #37887: Make attachments atomic until a Customizer session is published
noreply at wordpress.org
Fri Jan 13 23:52:18 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:9 azaozz]:
> 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.
The image would only be auto-deleted if there is no reference to the that
attachment. Since it's suggested here that uploads and attachment changes
should be encapsulated inside of a customization session (changeset), if
that changeset is abandoned/deleted then the attachment should also be
purged. As of 4.7, a user can share the URL to a customizer session (with
the `changeset_uuid` param intact) with another user so that they can see
the image applied as the site logo. A user can even share a URL to the
frontend directly with the `customize_changeset_uuid` param present and
let an unauthenticated user see how the custom logo appears.
>> 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".
There is a help (?) icon in the root customizer panel that includes text
saying, “The Customizer allows you to preview changes to your site before
publishing them.” If it is not clear to users that the changes made in the
customizer are non-destructive (and it surely can be made more clear that
all changes made are ''pending''), this means we need to make this more
clear, not be OK with some things being destructive (or rather
constructive) prior to doing Save & Publish.
> 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?
Yes. My position is that anything done during customization w/ live
preview should be non-destructive (non-mutating) until the user explicitly
wants the changes to go live. This needn't be restricted to the customize
preview. In the future if we allow entering into a customization session
from the frontend (i.e. frontend editing) the same principle should apply.
Everything done to the site should be “staged” in a draft (changeset) that
goes live once the user is happy with the changes. A missing piece in the
current customizer implementation is that there is no UI for saving a
draft of changes: the `customize_changeset` posts created during
customizer sessions are always created with the `auto-draft` status (as
well as the posts created for any page/post stubs). Allowing changesets to
be longer-lived drafts is what #31089 and the [https://github.com/xwp/wp-
customize-snapshots Customize Snapshots] feature plugin are addressing.
The customizer certainly needs UX improvements and its UI needs an
overhaul, and this will be a focus for 2017. But I hold that the more
aspects of a site to which we can add preview support the better—whether
this be options, widgets, nav menus, posts/pages, taxonomy terms, media,
and so on. If media preview support is added as proposed in this ticket,
then there would certainly need to be UX changes to the media modal.
Ticket URL: <https://core.trac.wordpress.org/ticket/37887#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac