-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Editor: Fix 'slug' editing in 'template-locked' mode #69516
Conversation
Size Change: +17 B (0%) Total Size: 1.84 MB
ℹ️ View Unchanged
|
792709f
to
9607a6e
Compare
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When changing the slug, it seems that the editor is re-rendered because the defaultMode
toggles between undefined
and template-locked
. Is there a way to fix this behavior?
42b516de3932d1dd2088d8902d3456a6.mp4
Yes, I'm aware of that, but I haven't found the right solution yet. Conditionally using the The P.S. The template flash you see when changing the slug is technically the same as trying to swap the template, but it's not apparent. I'm not sure if we can communicate this from the slug popover. |
Maybe the default template needs to be stored somewhere the same way as a custom template is, if that means it does not have to resolve the template based on the slug. |
I think it still has to react to the slug change. Example: You start working on a draft page and then decide that it should use the Generally speaking, template lookup/resolution needs some improvements (related #64341 (comment)), but it's out of the scope of this PR. |
Flaky tests detected in 7f49a0c. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/13781124502
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, it seems best to ship this PR and address the other improvements in a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback, everyone! |
* Editor: Fix 'slug' editing in 'template-locked' mode * Make isRenderingModeReady condition less restrictive * Fix typo
I just cherry-picked this PR to the wp/6.8 branch to get it included in the next release: b1f984c |
What?
Fixes #69509.
PR fixes a regression in which editing a page slug causes the editor canvas to fully re-render, disrupting field editing.
Why?
The editor provider only starts rendering its contents based on two conditions:
isReady
andmode
; both need to betruthy
for the contents to render.Previously, I made
isReady
dependent on thehasTemplate
condition to avoid rendering mode flash and wait until the editor resolved the template. This introduced the problem - changing the slug also recalculates the template ID for the current page, togglingisReady
from true to false and back.How?
Rearrange conditions so that
isReady
andmode
are not recalculated when thehasTemplate
value changes.P.S. I think the content "flash" became less noticeable after #69454.
Testing Instructions
post-only
mode. Posts use this mode by default.Note: I tested with CPU throttling, and content loading differences are more noticeable.
Testing Instructions for Keyboard
Same.
Screenshots or screencast
The loading screencasts are taken with CPU throttling - 4x slowdown.
Before
slug-editing-fix-before.mp4
After
slug-editing-fix-after.mp4