Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default rendering mode for pages outside of the Site Editor #68684

Open
Mamaduka opened this issue Jan 15, 2025 · 20 comments
Open

Default rendering mode for pages outside of the Site Editor #68684

Mamaduka opened this issue Jan 15, 2025 · 20 comments
Labels
[Feature] Template Editing Mode Related to the template editor available in the Block Editor Needs Decision Needs a decision to be actionable or relevant

Comments

@Mamaduka
Copy link
Member

Mamaduka commented Jan 15, 2025

#62304/#68549 introduced a new setting to set the editor's default rendering mode for post types. It also updated this setting for Pages; now, they will render the page template + content.

Previously, this value was hardcoded in the Site Editor, but now the setting is shared across the editors.

Needs Decision

Let's decide whether the template-locked should be Pages' new default rendering mode.

Note

The decision concerns the default rendering mode that will ship with WordPress 6.8. After all UX issues have been resolved, the goal is to render pages in template-locked mode in the future.

Pros of template-locked:

  • It makes the page editing experience consistent between Site and Post editors.

Cons of template-locked:

Supported modes and what they represent:

  • post-only Renders post-content blocks, allowing content to be edited in isolation. This is the default value for all post types except pages.
  • template-locked—This mode renders both the template and post blocks, but the template blocks are locked and cannot be edited. The post blocks are editable. This is a new default for pages.

Screenshots

Posts Pages
Image Image
@Mamaduka Mamaduka added [Feature] Template Editing Mode Related to the template editor available in the Block Editor Needs Decision Needs a decision to be actionable or relevant labels Jan 15, 2025
@fabiankaegy
Copy link
Member

Just to share some perspective here, I'm already using the template-locked mode for all post types (by manually setting it like shown here: https://gist.github.com/fabiankaegy/abb054d09334b23edd3cd2ec25df7b55)

With that there is greater consistency for users so it is less confusing and the benefits of seeing the template whilst editing outweigh the downsides for me.

But I am very open to changing the default for pages back for now to have less of an impact to start with whilst we continue to improve the UX of the template locked experience

@youknowriad
Copy link
Contributor

The main thing I want to add is that we should stop considering site editor and post editor as two separate things, they are the same thing. Pages being in the "design/site editor" was just a tactical move that we did in order to iterate on a lot of things (admin design, dataviews...). So for me, there should be only one default rendering mode per post type regardless of where this post type is edited.

@audrasjb
Copy link
Contributor

audrasjb commented Jan 15, 2025

Hey there,
My main concerns about switching to template locked mode are the following:

  • When you have the block inserter + the panel on the right open, the place to display the content (+ its template) is pretty narrow. I'm afraid it would make it complex to manipulate things on "small" screens (like 13'' screens)
  • Also, if we have the full template loaded in the page editor, then we'll have to scroll down after the end of the footer/navigation before starting editing content. Not a blocker, but maybe it would be super convenient for end users.
  • We should maybe also anticipate the end users reaction: "why the hell the full site editor appears when I only want to edit my page's content"?

For now I can't see any issue with existing plugins and other extenders, but worth testing this deeply in the ecosystem, too :)

Note: I'm not specifically against this change, I'm just questioning myself :p

@audrasjb
Copy link
Contributor

Another concern: maybe add a skip link for accessibility so keyboard users can go directly to the content/page title without having to navigate through all the locked template section without understanding why it's there if they only want to edit a page content.

@marybaum
Copy link
Member

I would like to see template-locked come to the post editor, myself.

As an OG post person, it would be great to see template parts in place in posts, but get my hand slapped if I tried to edit them.

@burnuser
Copy link

Some feedback from a user:

  1. My first experience with automatic displayed template parts in regular block/post editor:
    What the hell ...
    Am I wrong here?
    I don't want the site editor to open ...

  2. After discovering, that the - very good hidden - option "Show template" could be turned off, it was a relief. And I suspected the whole thing was a simple code error.

  3. Since "Show template" OFF is not persistent, I discovered myself avoiding further tests with Gutenberg if possible, because it is so extremely annoying:
    a) Performance: loading header (and footer) each time when I only want editing content consumes a lot of additional time and is a real nightmare!
    b) Workflow: having to scroll down to content, each time when page is opened, only to be able to start with my editing is terrible.
    c) Confusion: From semi-automatic editing content before, now I'm forced to distinct visually between completely unnecessary displayed Template-parts in the viewport and the relevant content to edit.
    d) Error prone: a wrong double click on the wrong element (= template parts) leads to different workflow and maybe also unwanted changes in template.
    e) I can't remember a time when I've ever cursed so much about a new WordPress "feature".

  4. Distinction between Admins and other users does not help, because many WordPress sites around the world are operated by single persons who are - of course - admins, but works about 99% with regular page content (in a defined, unaltered template).

If I may make some suggestions:
A) Make "Show template" OFF the one and only default for all users and all post types.
B) Make this option and default persistent => If somebody wants to see the template in regular post editor, it can be activated case by case individually (and - in my opinion - not persistent)
C) There may be good intentions and arguments for remove any difference between post-editor and site-editor in a holistic perspective. But in regular workflow, what concerns millions of WordPress users worldwide, there is a really big difference!
So, please, add additional options, if you want, but don't change a for decades well working workflow and force us all to use a not fitting interface in post editor.

@Mamaduka Mamaduka moved this to 🗣️ In Discussion / Needs Decision in WordPress 6.8 Editor Tasks Jan 16, 2025
@ktmn
Copy link

ktmn commented Jan 20, 2025

List view -> Outline doesn't detect the Heading structure in template-locked mode.

@carolinan
Copy link
Contributor

I would like to see the results from more user testing before deciding which mode should be the default.
Is that something that the 6.8 release squad could arrange with the testing team?

I understand that the goal is to unify the editors, but I am not sure that users are aware of and expects this. How about making the switch easier by first sharing the intent, and letting them try the new mode?

In 6.8:
The default mode is post-only.
When the user first edits a page or creates a new page, display a prompt that presents the new mode, with the intent that this WILL be the new default, and ask them if they want to try it.
In 6.9: make the new mode the default.

@audrasjb
Copy link
Contributor

I'm personally not super fond of deploying something optionally available to everyone, because we don't really have any tool to measure the average end-user satisfaction from that experiment and we don't have so much experience doing so (for example via a poll, a link to forums). Historically, the WP project is rather to take the decision beforehand, after discussion about the pros and the cons of the resulting user experience (Decision not option). It has its negative aspects, but also positive ones :)

@afercia
Copy link
Contributor

afercia commented Jan 21, 2025

I have concerns about this change and basically I agree with #62304 (comment)

I'd liek to add:

  • Why it's only for pages? Other custom post types may be hierarchical like pages but overall to me it feels an assumption that some post types need a different user experience only becaue the Site editor provides this experience for pages.
  • As an user, after I click 'Create new pate' I land in the editor and I see too many things 'moving' outside of my control. The inserter opens automatically, the 'Patterns' tab is selected, the editor canvas zooms out. That's too much for me.
  • As an user, I still want to start by creating the page content.
  • From an accessibility perspective, setting initial focus on the 'Patterns' tab of the Inserter would be totally confusing.
  • For all users: the UI doesn't really explain what the current editing mode is and why.

@carolinan
Copy link
Contributor

carolinan commented Jan 22, 2025

I think I am misunderstanding because pretty much everything in the editor is optional to everyone.
I still think the editors should be unified, that having one editor is the long term goal. I think WP could try to ease it in.

@carolinan
Copy link
Contributor

At the very least, if it is not reverted, there should be a new guide (like the welcome guide) to explain what on earth is going on.

@Mamaduka
Copy link
Member Author

Just saw this report on the plugin forums - https://wordpress.org/support/topic/create-edit-page-loads-template/.

At the very least, if it is not reverted, there should be a new guide (like the welcome guide) to explain what on earth is going on

I think the internet ruined popups for everyone, and the Welcome Guide modal is becoming another user annoyance.

@carolinan
Copy link
Contributor

So even if the default mode is reverted, the problem remains that it is difficult to

  • Know which mode you are in
  • How to turn it off

@Mamaduka
Copy link
Member Author

Everything will be the same if we decide not to ship the new default mode. The "Show template" functionality has been in the core for several releases.

@carolinan
Copy link
Contributor

If it is reverted it is only temporary though? Until there is a way to improve the UX and make the feature and its purpose easy to understand.
Because the end goal is still to have one editor.

@Mamaduka
Copy link
Member Author

Current. This issue aims to decide whether WordPress 6.8 will ship with template-locked as the default mode for pages. I added a note to the issue description. Feel free to edit or add to it if it's still unclear.

@getsource
Copy link
Member

Read through to catch up on this.

Given user feedback, I agree that it seems like a good idea to revert the default for pages for 6.8, with the intent for it to return when testing results from the plugin are more positive.

@youknowriad
Copy link
Contributor

I saw a lot of positive feedback for the change personally on X for instance. Reactions like: "finally, we've been asking for this forever". So I think this is one of the things that there's no clear winner. I would say in this situations, the folks that end up showing are potentially on the vocal minority.

@carolinan
Copy link
Contributor

That is the difficulty. Experienced users and developers in the community that tweet are also the vocal minority. (And I noted that some did not even know the feature existed until it was the default, it can be introduced better so that people find the setting.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Template Editing Mode Related to the template editor available in the Block Editor Needs Decision Needs a decision to be actionable or relevant
Projects
Status: 🗣️ In Discussion / Needs Decision
Development

No branches or pull requests

10 participants