Posts: consider support for "Quick Edit" functionality to match wp-admin

[jblz]

The core list allows the ability to quickly edit lots of things without opening the full editor:

The Quick Edit link is revealed on mouseover

Clicking it expands the post listing to allow the ability to edit a slew of meta-data:

---

There's currently no apparent equivalent in the posts lists (https://wordpress.com/posts/:slug):

Clicking the More button doesn't show it:

[mcsf]

Or... we strive to make the editor so fast that any edit is a quick edit. 🤔 If that can be achieved, then the remaining problem that Quick Edit addresses — and that we'd want parity for — is batch editing.

[lancewillett]

I agree with Miguel here. The idea is the editor is fast to load and easy to use such that quick edit isn't needed. It was important in wp-admin's full-page PHP load context, but not so in the React JS model of Calypso.

[jblz]

I agree that an instantly-loading editor is a noble goal, but in practice, I'm not convinced it's going to be the case in the near term.

Some composition of the Editor sidebar could be rendered instantly & provide readwrite access to many pieces of meta data that don't necessitate loading & rendering the content-related portions & supporting code.

The use case I'm thinking of is needing to successively edit a series of posts with some manual process (i.e. one where bulk editing won't be useful)

[lancewillett]

Pinging @lsinger and @shaunandrews for a Link opinion on this flow.

[lsinger]

I tend to agree with @jblz here. The editor will always need to load more than just meta data — images, text, widgets, etc. — so it will always be slower when compared to a "quick edit"-style mini editor that doesn't leave the post list.

Sure, we could cache / pre-load things, but already the changing around of UI components takes time and, maybe even more importantly, requires people to adjust to a completely new screen (the editor). The editor isn't only computationally more expensive, but also cognitively.

I'm sure that regardless of the computational efficiency of the editor, a "quick edit" editor that doesn't leave the post list can make sense.

[alisterscott]

Keeping this open as we still don't have this functionality

[alisterscott]

This is related to bulk editing and deleting raised in #10742

[shaunandrews]

Or... we strive to make the editor so fast that any edit is a quick edit.

Its this. This is the answer.

[alisterscott]

Its this. This is the answer.

That doesn't address bulk editing though which is another benefit of quick edits

[shaunandrews]

I'm not sure how this is related to bulk editing — which is coming.

[mattsherman]

Agreed. Bulk editing is a separate concern. I'm not convinced that we also need quick edit. What are some specific use cases where this would be used?

[jblz]

I'm not sure how this is related to bulk editing — which is coming.

Isn't bulk editing just quick editing of greater than one post? What am I missing?

[shaunandrews]

Isn't bulk editing just quick editing of greater than one post? What am I missing?

Or, you could say quick editing is just bulk editing of one post.

I think the point here is that we don't have plans to offer a "quick edit" experience for a single post.

[github-actions]

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

[worldomonation]

Hi! I'm performing triage on older bugs as part of Quality Squad's efforts to cut down on backlog issue counts.

As there has been no recent activity on this issue it is being closed with the label Closed - Won't Fix.
If this issue should remain open, please feel free to re-open this bug.