EditorProvider: Use an internal post content block to keep the global core/block-editor store attached to post content #56631
Conversation
This file contains 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
… core/block-editor store attached to post content
youknowriad
added
the
[Type] Technical Prototype
youknowriad
requested review from
ellatrix,
ajitbohra,
ryanwelcher,
juanmaguitar,
fabiankaegy and
ndiego
as code owners
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
Size Change: +335 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Ah, what a challenge! I see what you mean about it feeling a bit too clever, perhaps, as it'd be nice to be able to achieve it without having to add a separate internal block that won't be used anywhere else. Still, thanks for the tip to demo it via calling wp.data.select( 'core/block-editor' ).getBlocks() while editing a page in the site editor (with template preview switched off), that helps demonstrate the problem:
Trunk — returns the "fake" template of title, featured image, and content blocks:
This PR — just returns the real blocks within the page:
I don't have a good alternative suggestion, but I feel like I better understand the problem now 😀
have multiple (or two) block editors around each post block (post title, post content and post featured image)
Is that two for each post block, or one for each post block? Just trying to imagine how that might work 🙂
A third approach (might be the easiest to start with) would be to instead copy the post editor in the post-only mode of the site editor rather than doing the opposite.
What might that look like?
|
At the moment I'm thinking of dropping the "fake" template and just have post title "component" + block editor store only containing the post content blocks (just like the current post editor works). I know that you think "guessing" the blocks from the template has some value but I believe its value is small compared to the benefits of the mode and unifying post and site editors. I do think it's possible to keep this "smart" guessing behavior at some point by using multiple block editor providers but I'd like to keep that separate from the work of unification. So as a start instead of doing "post-only" mode to "post editor", I'm going to do "post editor" to "post-only" mode. |
|
closing in favor of #56671 |
I think the main value to me is in preserving some of the formatting that might be in use within a template, that's relevant to the person writing content (i.e. if the content area is much narrower for a particular template, so the person writing content has an idea of how long or short their post might look before publishing). For me it is very much a weakly held idea, though, so happy to explore your ideas! Thanks for all the explorations here across many PRs, I'll take #56671 for a spin 🙂 |
I mean aside the "layout" (which I intent to keep as does the post editor), the styling is not kept at all, only the "order" of these blocks. |
Yes, I don't think we've explored it yet, but my hope is that in the longer-term we might be able to support other kinds of styling for the particular post content block, too. So for a site with a different color scheme on the post content block of a particular template, for example, we might pull that in, or a particular background image, etc. The idea being that while we started with layout, we might roll it out to other styles in the future. In any case, it's just a weakly held idea for now, likely not something we need to worry about just yet! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Builds on top of #56542
Related to #56586
What?
While trying to unify the post and site editor code bases to both use the "post-only" mode instead of duplicating the same logic in both places, we found that it would be very hard to keep backward compatibility this way. The main reason is because "core/block-editor" store is expected to only contain the "post content blocks" in the post editor by all plugins and third-party developers.
The current PR tries to explore the idea mentioned here #56586 (comment)
which basically means we have a block editor within a block editor (instead of using the regular post content block) and the internal block editor still points to the global registry (so the global core/block-editor store).
This PR tries this in the site editor first (disable template previewing) and you can verify this by opening the browser console in that mode and typing
wp.data.select( 'core/block-editor' ).getBlocks()Note The code here is a bit "clever" and I'm not a huge fan. So while I'll keep this PR around to consider it, I'm thinking about exploring another simpler approach maybe: Instead of having two nested block editors, have multiple (or two) block editors around each post block (post title, post content and post featured image). The
BlockEditorProviderthat wraps thepost contentblocks would be the only one that hasuseSubRegistry=false. In other words, this alternative approach would be very close to the post editor, only difference is it would use blocks rather than aPostTitlecomponent to render the post title. A third approach (might be the easiest to start with) would be to instead copy the post editor in the post-only mode of the site editor rather than doing the opposite.