Unify the preferences modal UI between post and site editor#57639
Merged
youknowriad merged 4 commits intotrunkfrom Jan 12, 2024
Merged
Unify the preferences modal UI between post and site editor#57639youknowriad merged 4 commits intotrunkfrom
youknowriad merged 4 commits intotrunkfrom
Conversation
youknowriad
added
[Type] Enhancement
youknowriad
requested review from
a team,
draganescu,
glendaviesnz and
talldan
youknowriad
force-pushed
the
unify/preferences-modal
branch
from
98cf2da to
4df2961
Compare
|
This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress. If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged. If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack. Thank you! ❤️ View changed files❔ lib/client-assets.php |
youknowriad
force-pushed
the
unify/preferences-modal
branch
3 times, most recently
from
697aa18 to
368b459
Compare
youknowriad
commented
Jan 8, 2024
Contributor
Author
There was a problem hiding this comment.
I'm guessing these components were only here because we wanted them private. I've moved them to the preferences package as private APIs instead.
youknowriad
force-pushed
the
unify/preferences-modal
branch
from
368b459 to
388fa1f
Compare
24 tasks
|
Size Change: -3.18 kB (0%) Total Size: 1.69 MB
ℹ️ View Unchanged
|
t-hamano
reviewed
Jan 8, 2024
ntsekouras
approved these changes
Jan 8, 2024
Contributor
ntsekouras
left a comment
ntsekouras
left a comment
There was a problem hiding this comment.
I'd appreciate some more testing here, but this LGTM, thanks!
|
|
||
| // Keep a reference of the `allowedBlockTypes` from the server to handle use cases | ||
| // where we need to differentiate if a block is disabled by the user or some plugin. | ||
| defaultAllowedBlockTypes: settings.allowedBlockTypes, |
Contributor
There was a problem hiding this comment.
It's nice we don't need this anymore.
Member
|
The PR's pretty big, so I've gone through and manually tested preferences between post and site editors. ✅ All preferences have effect and persist between editors 🎉 |
draganescu
reviewed
Jan 9, 2024
Contributor
draganescu
left a comment
draganescu
left a comment
There was a problem hiding this comment.
The code looks good to me and ran great in my manual testing. Since this overhauls quite a lot of lines 🤞🏻 for automated tests to cover what we miss reading.
One thing that the PR description was not clear for me is that this PR makes the prefference settings apply universally across editors. Maybe this is worth a 👍🏻 from @WordPress/gutenberg-design ?
Contributor
Author
This was actually done in previous PRs iteratively, this PR is the "final" step making the UI common. |
Contributor
|
I don't mind that chagne. I see arguments for both cases, but especially with some of the unification done for page editing, I do eventually see these growing towards something we think of more as a single editor, rather than two. That said, things like top toolbar and similarly are intentionally put as top items in the options menu, to make it easy to flow in and out of those. |
youknowriad
force-pushed
the
unify/preferences-modal
branch
from
83f5009 to
ed02581
Compare
youknowriad
force-pushed
the
unify/preferences-modal
branch
from
ed02581 to
0bfca08
Compare
This was referenced Jan 17, 2024
Member
|
I just ran into this problem tonight and came here to make an issue. Now I don't need to. Y'all rock! Thanks for your work in resolving this. |
Contributor
|
@youknowriad the only change to PHP files here is in gutenberg/lib/client-assets.php Lines 3 to 4 in 1ea6c22 If you can confirm I will update the docs and the PHP Sync Tracking Issue. |
Contributor
Author
|
@getdave that's not entirely true. client-assets.php do in general require changes to WP Core. In this particular instance we need to define a new preferences styles handle in the script loader (which I'll be doing as part of the package update PR) |
Contributor
|
I was in two minds about it and then I read
...in the file comment. Maybe we should reword to
|
youknowriad
added
Backported to WP Core
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related #52632
What?
This PR continues the work on the great unification between post and site editors. This PR brings the "blocks manager" to the site editor as well, allowing hiding/showing blocks in the site editor as well similar to the post editor.
In addition to that, this PR unifies the "preferences modal" UI and just uses the same component for both. There are still some extra preferences that are specific to the post editor but these are injected using a special
extraSectionsprop.Testing instructions