Make WordPress Core

Opened 7 weeks ago

Closed 3 weeks ago

Last modified 36 hours ago

#63100 closed defect (bug) (reported-upstream)

Clicking The Edit Site Link Loads The Page Editor Instead of The Site Editor

Reported by: jeffr0's profile jeffr0 Owned by: joemcgill's profile joemcgill
Milestone: Priority: high
Severity: normal Version: trunk
Component: Editor Keywords:
Focuses: Cc:

Description

In WordPress 6.8 Beta 2, the behaviour of the Edit Site link has changed. In Settings > Reading if you select a static page to represent the front page and then click on Edit Site on the frontpage, it loads the Page Editor instead of the Site Editor.

One of the reasons this is problematic is that if you want to edit the nav menu on the front page in the Site Editor, you can't. When you click Edit Site, because it loads the Page Editor, the nav menu disappears.

This behavior doesn't happen in WordPress 6.7.2.

Attachments (1)

show-template-button.png (44.5 KB) - added by wildworks 7 weeks ago.
"Show template" button

Download all attachments as: .zip

Change History (29)

#1 @audrasjb
7 weeks ago

  • Component changed from General to Editor
  • Milestone changed from Awaiting Review to 6.8

Moving for 6.8 consideration.

#2 @jeffr0
7 weeks ago

As a follow up, I was able to replicate this issue in the Twenty Twenty Five theme. I've also gotten a few other people to confirm this bug's existence.

#3 @audrasjb
7 weeks ago

I can confirm I was able to reproduce the issue as well.
Pinging @Mamaduka for information.

#4 @sainathpoojary
7 weeks ago

Hey @audrasjb @jeffr0,

During my testing, I observed this behavior:

  • When selecting a static page as the front page and clicking “Edit Page,” it opens site-editor.php but only displays the page content.
  • However, when setting “Your latest posts” as the homepage, it loads the navigation menu, footer, and latest posts as expected.

Screencast: https://rioudcpuyg.ufs.sh/f/PL8E4NiPUWyOHsxAxj2N2bxKiQ70vpC8rdRhegntWU63YfIz

If this is the issue being discussed, I investigated further and found that this commit that may be responsible. Reverting it restores the previous behavior.

Screencast: https://rioudcpuyg.ufs.sh/f/PL8E4NiPUWyOaXlv9hHJcb5UXrLqDIo97jZKdMWg8iplmysR

Let me know your thoughts!

#5 follow-up: @wildworks
7 weeks ago

I don't think the underlying issue has anything to do with the Edit Site link changing. From my understanding, the direct problem is that the Show Template setting is now persistent.

At first glance it may appear that the header and footer menus have disappeared, but you can enable the template in one of the following ways:

  • Header > View button > Show template
  • Sidebar > Page > Template > Show template

So I don't think what's reported here is strictly a bug, but maybe some improvement could be considered to avoid confusing users.

Related Gutenberg PR: https://github.com/WordPress/gutenberg/pull/69286/

Last edited 7 weeks ago by wildworks (previous) (diff)

@wildworks
7 weeks ago

"Show template" button

#6 @jeffr0
7 weeks ago

I can confirm that selecting Show Template restores the Nav Menu items to the Site Editor. So, I'm tending to agree that this is not a bug. However, this certainly feels more cumbersome than the experience is in WordPress 6.7.2.

This ticket was mentioned in Slack in #core by jeffr0. View the logs.


6 weeks ago

#8 in reply to: ↑ 5 @joemcgill
6 weeks ago

  • Owner set to joemcgill
  • Status changed from new to reviewing

Replying to wildworks:

I don't think the underlying issue has anything to do with the Edit Site link changing. From my understanding, the direct problem is that the Show Template setting is now persistent.

...

So I don't think what's reported here is strictly a bug, but maybe some improvement could be considered to avoid confusing users.

I agree that we should probably improve this. Is there a way to differentiate whether we're loading the page in the site editor vs the post editor when applying the user preference?

#9 @wildworks
6 weeks ago

Is there a way to differentiate whether we're loading the page in the site editor vs the post editor when applying the user preference?

As I understand it, the "Show Template" setting, i.e. rendering mode, is persisted per post type, and currently the setting should be shared between the site editor and the post editor.

cc @Mamaduka

#10 @Mamaduka
6 weeks ago

After "great unification", both editors are almost identical, and there's no explicit way to differentiate whether the Editor component is rendered by the post or site editor.

Using different rendering modes has already been discussed on GitHub, and @youknowriad makes a good point here: https://github.com/WordPress/gutenberg/issues/68684#issuecomment-2592785548.

Additionally, I don't see how "Show Templates" is related to the link in the admin bar. I think what @jeffr0 is reporting was changed via https://github.com/WordPress/wordpress-develop/pull/8372 and there's still open discussion for additional changes - https://github.com/WordPress/gutenberg/issues/63785#issuecomment-2688190851.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


6 weeks ago

#12 @peterwilsoncc
6 weeks ago

I understand the goal of opening the site editor to the home page's template, be that blog posts or a page. But it does seem a little odd to be getting the page toolbar on the right rather than the template toolbar.

If the page has empty content, it also triggers the pattern chooser, which increases the confusion (for me, anyway).

If the homepage is a page, would it be possible to link to /wp-admin/site-editor.php?p=%2Fwp_template%2Ftt5-child%2F%2Fpage&canvas=edit, and to the index template if it's showing blog posts?

#13 @wildworks
6 weeks ago

As I said in this comment, I don't think the issue being discussed here is directly related to the edit site link.

In the site editor root (Design screen), if the homepage is a page and there is no front page template, it will display that page instead of the template. This specification is the same in WordPress 6.7.

Therefore, even if we revert the edit site link to its previous state (link to the template), I think that this may not be a fundamental solution.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


5 weeks ago

This ticket was mentioned in Slack in #core-editor by joemcgill. View the logs.


5 weeks ago

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


5 weeks ago

#17 @audrasjb
5 weeks ago

  • Priority changed from normal to high

Increasing priority level as we need decision/action right after RC1.

#18 @joemcgill
5 weeks ago

After some testing and further discussion in Slack there are a few separate changes that have contributed to the friction in this experience.

First, there is the change introduced in [59910], which modifies the "Edit Site" link to open directly to the site editor root, /wp-admin/site-editor.php, rather that the previous behavior that deep linked directly to the template editor for the current active template, /wp-admin/site-editor.php?postType=wp_template&postId=twentytwentyfive%2F%2Fpage&canvas=edit.

That change was the result of an intentional forward design iteration to make the experience for that link consistent. I don't think we should revert this change to the previous behavior.

However, there is an existing point of friction for editing the home page whenever the site has set a static page as the homepage of the site. Unlike when the homepage is set to show 'latest posts', the canvas will render the static page rather than the relevant template for that page (e.g., front-page.html, index.html, etc.), which means that clicking into the canvas results in you being in the page editor where the template cannot be directly edited.

This existing behavior is further complicated by the experiment in #61811 to default page post types into always showing the template, and persisting user preferences when someone chaged the "show template" setting. Now, if someone had selected to turn off "show template" for page post types, the canvas will no longer include the template in the preview, nor in the editor when the canvas is expanded. Setting that default has been reverted in [60076], which will be included in RC 1, and hopefully lead to less people experiencing this friction.

Still, I think it would be worth investigating whether the root canvas could be updated to load the related template, rather than the page when a site is set with a static page on front.

@wildworks and @Mamaduka, I assume this would strictly be an update to the related editor package, and not something that would need to change in the wordpress-develop repo, correct? If so, is there an existing issue where this discussion can be tracked in order to close this issue out?

This ticket was mentioned in Slack in #core-editor by joemcgill. View the logs.


5 weeks ago

#20 @wildworks
5 weeks ago

I assume this would strictly be an update to the related editor package, and not something that would need to change in the wordpress-develop repo, correct? If so, is there an existing issue where this discussion can be tracked in order to close this issue out?

Yes, that update would need to be done in Gutenberg, but I don’t think there is an existing issue about that.

We may be able to submit a sub-issue of this issue: Homepage: Posts page & static home page in the Site Editor #63783

#21 @devsahadat
5 weeks ago

I’ve reviewed the issue and the proposed solution. The problem seems to stem from the persistent ‘Show Template’ setting, which hides the template when editing a page. This isn’t strictly a bug, but more of an unexpected user experience in WordPress 6.8 Beta 2. The suggested solution—making it clearer when the Site Editor or Page Editor is in use—sounds like a valid approach. After testing, I confirm that enabling ‘Show Template’ restores the navigation menu in the Site Editor.

While this resolves the immediate confusion, I recommend further refining the experience, particularly when a static page is set as the homepage. Ensuring the correct template loads by default in the Site Editor could eliminate the need for users to toggle the template visibility manually.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


5 weeks ago

#23 @Mamaduka
5 weeks ago

I think it's better to punt this to the next major release. As far as I can tell from code history, the current behavior is intentional. When a site doesn't have a front-page template, the static homepage is treated as just another page.

The behavior difference became more noticeable after we had to revert the new default rendering mode - https://github.com/WordPress/wordpress-develop/pull/8557. As I noted in that PR, we don't want to reintroduce a special case for the rendering mode in the site editor because the whole point of the default rendering mode setting is consistency.

Consumers/developers can opt in to the previous behavior by changing the default rendering mode for Pages:

<?php
// Set default mode to template-locked. Use this for testing.
add_action( 'init', function() {
        add_post_type_support( 'page', 'editor', array(
                'default-mode' => 'post-only',
        ) );
} );

The bigger question here is whether the Site Editor should treat a static Homepage differently. We can continue that discussion in this GitHub issue: https://github.com/WordPress/gutenberg/issues/63783.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


4 weeks ago

#25 @joemcgill
4 weeks ago

  • Milestone changed from 6.8 to 6.8.1

I think moving this off the 6.8 milestone makes sense, given the time needed to refine the handling of static home pages in the main site-editor canvas preview. Given that potential impact of this issue is fairly large, I'm going to move this to the 6.8.1 milestone to keep visibility on any improvements that could be made in time for an early minor release.

Currently, I think the likely next step here is to address how to improve the editing flow from the site editor root, when the canvas is showing a homepage that is a static page, but agree that convo should continue in https://github.com/WordPress/gutenberg/issues/63783.

@Mamaduka One thing that I'd like to clarify is your comment about how folks can opt in to the previous behavior. Even if someone uses the code snippet that you provided, I believe that once a user has changed their "show template" preference, that preference will override any default that has been set for the post type. Correct?

#26 @Mamaduka
4 weeks ago

that preference will override any default that has been set for the post type. Correct?

That's correct. Folks can still use user preference for "Show Template"; user settings always take precedence over global settings.

#27 @Mamaduka
3 weeks ago

  • Milestone 6.8.1 deleted
  • Resolution set to reported-upstream
  • Status changed from reviewing to closed

The same issue is being discussed in the Gutenberg repo - https://github.com/WordPress/gutenberg/issues/69848.

I'm going to close this as "reported-upstream".

#28 @sabernhardt
36 hours ago

I removed my comment, which had changed the resolution from reported-upstream. #63358 is related, but maybe not a duplicate.

Note: See TracTickets for help on using tickets.