Decouple Post Blocks Experiment from Site Editor Experiment #27822
Conversation
ntsekouras
added
[Feature] Full Site Editing
[Type] Experimental
ntsekouras
requested review from
ajitbohra,
spacedmonkey,
talldan and
TimothyBJacobs
as code owners
|
Size Change: -1.06 kB (0%) Total Size: 1.28 MB
ℹ️ View Unchanged
|
| @@ -77,6 +78,7 @@ function gutenberg_get_common_block_editor_settings() { | |||
| */ | |||
| function gutenberg_extend_post_editor_settings( $settings ) { | |||
| $settings['__unstableEnableFullSiteEditingBlocks'] = gutenberg_is_fse_theme(); | |||
| $settings['__unstableEnablePostBlocks'] = gutenberg_is_experiment_enabled( 'gutenberg-post-blocks' ); | |||
There was a problem hiding this comment.
Should we add || gutenberg_is_fse_theme(). It doesn't make sense for me to have an FSE theme without these blocks.
There was a problem hiding this comment.
We do add them if gutenberg_is_fse_theme... The only difference in the current status of this PR is template part, which is enabled only in FSE.
There was a problem hiding this comment.
I believe we need to start thinking about we organize our blocks a bit better. A unique block-library package is not going to scale properly. For me there are at least three kind of blocks:
- Raw blocks that work in any block editor instance (the ones used by asblocks)
- Blocks that are WP specific (widgets, latest posts...)
- FSE Blocks
That's a great thing to discuss, yes! How do you think |
No, these are WP specific but I wanted to separate them from other wp specific blocks (not sure this distinction makes sense though) |
|
I like the 3-categories of blocks
|
|
There is also the Classic block that we should move out of the block library. It doesn't make sense outside of the post edit and even there might be not necessary for new sites anymore. In fact, we could move it to the Block Directory but keep it shipped with WordPress so it's easy to activate when the site needs it. It might be an interesting experiment to automatically activate the Classic block when during the processing of the post content on the server, the need for it is detected. In other cases, it would get activated as soon as a user picks it from the inserter the same way it can be done for other blocks in the Block Directory. Going further, if it would work nicely, we could try to do the same for other blocks that aren't essential for the writing experience that you classified as: "core blocks - usable with any instance of the editor even outside WP". |
|
One thing we might want to double check are the categories these are currently assigned to. |
|
To avoid big changes in one ago maybe we can export several functions instead of one but just keep all of them in |
What do you mean? We have |
|
Something like: But maybe as experimental APIs for now, things we can use in the other I'm just tossing an idea though and would love a lot of opinions here. |
ntsekouras
requested review from
adamziel,
draganescu,
kevin940726,
noisysocks and
tellthemachines
as code owners
|
Reviewing this a bit more, I don't think we should introduce another experiment nor make all the blocks available at once. We should migrate the blocks we are comfortable being always available one by one. The groupings mentioned above also don't make a lot of sense to me and I'd rather lean on categories. |
|
Hi, Thanks for trying this; I'm looking forward to use the query block in my work without FSE. FYI, I loaded the gutenberg plugin that was built a couple hours from 468bed6 and I enabled the option in /wp-admin/admin.php?page=gutenberg-experiments |
|
Hi @skorasaurus - If you want to try it, my first commit was working properly: 7b6db89 In the second commit you mentioned, I started experimenting with splitting the registration of blocks and wasn't all ready. Other than that, by exploring this, it doesn't feel great for now TBH. I've converted it to draft for now and will catch up on it after the holidays. |
|
I'm disappointed that this proposal has gone pear-shaped. Everyone seemed to start off in agreement that the blocks should be de-coupled from FSE, and as @ntsekouras pointed out, the first commit did implement this successfully. Then came the doubts, one after the other:
All are valid points in the broader scope of the project, but unless I'm missing something, I don't see how they are specifically relevant to this patch or need to obstruct it. An "experiment" is only going to be temporary so I don't see the harm in introducing another one. The blocks could still be migrated one by one out of the experiment as they each become ready. Couldn't we just merge 7b6db89 and address those other concerns later, in new tickets? |
|
We need to rethink the way we register core blocks, as already discussed. All those blocks use
In the WordPress core and the Gutenberg plugin, we register all blocks on the server and offer ways to modify their definitions before sending them to the client. In addition to that, we let to define the list of disallowed blocks as part of block editor settings - it should be treated more as something that prevents inserting blocks from the UI. Taking all that into account makes the final proposal way more complicated. In theory, we should register on the client only those core blocks exposed from the server. In a case where there is no traditional server involved, we might want to default to the limited set of essential blocks. |
|
@carlomanf the point is the experiment is unnecessary and to decouple a block from FSE we need to just move its registration to the appropriate clause, which I imply we should do one by one as we deem them ready. |
|
Closing in favor of #31423 |
Description
Related: #26316
This PR decouples the FSE experiment from Post Blocks. If you have a FSE theme enabled, all blocks are registered as before.
If you don't have a FSE theme, with this new option enabled, you add to the block editor the following blocks:
The sole difference in the current status of this PR is the
template partblock which is enabled only with a FSE theme.How has this been tested?
Manually with combinations of FSE themes and the option enabled/disabled.