Site Editor shall know from which ID it got invoked and initiate with that page/post content and the underlaying template

[porg]

User Story

Proposed Improvements

Site Editor shall know from where it got invoked and shall initiate accordingly.

Possible Scope

1. Full context: Invoked via admin menu from a particular page/post ID → Site Editor initiates with this.
   • ✅ Quick win! → Little implementation effort but a clear UX improvement → Should be done ASAP.
   • 👉 Devs: Please tell me whether Gutenberg already gets this info or whether we need a sister ticket in WP Core (I'd do that).
2. Some invocation context: From somewhere in the backend which can be considered page/post ID specific or template specific → Try to initiate well.
   • 💡 Worthy at all? I doubt it. Listed it for completeness only.
   • 👉 If worthy then own issue with deeper evaluation/discussion.
3. No invocation context: Called directly via address input / bookmark or from the backend in an area which is not content specific at all.
   • 💡 WordPress/SiteEditor has a usage history/stats.
   • I see this as having potential: Use the last edited template-part or template with the last chosen page/post specific sample is better than starting at Home each time.
   • 👉 If worthy we should open a standalone issue (because this needs user/usage stats to work).

Related

• Optimise the content-centric edit experience in the Site Editor #49404

[mrfoxtalbot]

Big +1, @porg! This idea has crossed my mind a number of times but I never sat down to create an issue for it.

Just the same way we have an "Edit post/page" that is aware of what post you are looking at, we need the Site Editor to open the specific template that's being used for whatever we are looking at.

Not only would this save a ton of time, but it would make it easier for users to figure out how templates work and what template they need to edit.

[mrfoxtalbot]

I would be surprised if this suggestion had not come up in the past. It might even be the case that this is our roadmap already Do you know if this has been discussed at some point @getdave?

[mrfoxtalbot]

I found an example just today of someone who was struggling with this scenario in this forums thread.

[porg]

@mrfoxtalbot Thanks for backing it up with a user testimony!

• Usability tests would certainly identify this as an issue.
• And the support forums certainly contain several variants which have the same root cause, or will so in the future (with more widespread use of the Site Editor)

Followup

1. @mrfoxtalbot, @getdave — Do we have consensus that this is a Quick Win?
   • To me as a senior UX designer, who also was Product Owner with team resources once, it is a no brainer that this is a Quick Win: Little development effort for a big usability improvement.
2. Architecture Info: The proper way for the Site Editor to get the invoking ID is
   • a) from WP core provided by the invoking admin-menu (→companion ticket in WP core)
   • b) or does the Site Editor already know that from elsewhere, e.g. referer-header, info in cookie/router, etc?

[porg]

@mrfoxtalbot Can you answer my concrete architectural questions 2ab ? If not is Dave the one to answer it? Or who in the Gutenberg team?

[porg]

I want to expedite this a bit, create the necessary WP Core sister ticket, if necessary, etc. But I need at least some minimal dev answer on this. I myself do not know it.

[porg]

CC: @mtias

[mrfoxtalbot]

Thank you for pushing for this, @porg. I don't have enough background to reply to your question, but I second your idea 💯.

How can we move this forward, and what's the best technical approach, @mtias ? Thank you!

[mrfoxtalbot]

I'm going to take the liberty to summon @annezazu to the conversation, she'll probably heave interesting insights. Thanks again!

[annezazu]

Thanks for bringing this up! This has come up with the FSE Outreach Program namely in the form of this issue over a year ago. You can see the follow up comments when this has come up in testing from yours truly: #37850 Mind closing this out and heading there with your thoughts? It'll be better for all involved to consolidate there.

[getdave]

Hi @porg 👋

Many thanks for all your efforts here. Just so you're aware Core can move a little more slowly than you might be used to so don't be disheartened if you don't receive immediate responses or PRs for your suggestions.

If you'll allow me, in my experience working on this project "Quick Wins" are rarely so, and usually require either more feedback (to ensure a wide range of views have been accounted for) or are more technically complex than they might first appear.

That's not to say your suggestion isn't a great idea, but that it may take time to come to a consensus and gather contributors to work on a solution as there are limited resources being spread over a wide set of feature requirements.

Be assured that several folks do keep an oversight on the project and help prioritise features based on several factors. I agree with @annezazu that, due to some of the reasons I listed above, it's important to centralise discussions. Therefore let's follow up there where contributors are already suggesting solutions. Feel free to reference the comments you left in this Issue.

Thanks again 🙇‍♂️

[porg]

• Closing this here.
• Followup in Admin bar: Edit site link should open the current template #37850 (comment)