[WIP] Blocks: Make the block registration filterable on the server by gziolo · Pull Request #5802 · WordPress/gutenberg

gziolo · 2018-03-26T14:34:23Z

[UPDATE: moved to #6733]

Description

Implements: #2751, #4116.
Replaces: #5652.

The updated plan is as follows (originally shared in #5652):

register_block_type is going to be the only way to register dynamic block and it needs to happen on the server
attributes, supports, category, title?, description? will have to be registered on the server. It will be possible to update them only with the PHP hook.
All other properties will be provided on the client using extendBlockType with the new corresponding JS hook.
registerBlockType will remain with deprecation message for the next 2-3 releases to make sure developers have time to refactor their plugins.

Screenshots (jpeg or gifs if applicable):

There should be no visual changes.

Types of changes

Breaking change with the deprecation strategy to be proposed.

Checklist:

My code is tested.
My code follows the WordPress code style.
My code has proper inline documentation.

youknowriad · 2018-03-26T15:05:45Z

blocks/library/block/index.js

-		customClassName: false,
-		html: false,
-	},
+	isPrivate: true,


Why is this on the client?

I don't like this property at all :) I will move it to the server, too 👍

To make things easier, I moved isPrivate to supports property and renamed to insertable.

youknowriad

Any reason this is limited to dynamic blocs?

youknowriad · 2018-03-26T15:08:37Z

blocks/library/block/index.js

@@ -172,20 +172,10 @@ export const name = 'core/block';

 export const settings = {
 	title: __( 'Shared Block' ),


What about the title and description? It seems to me that blocks discovery would benefit from these properties being declared on the server as well

I'm going back and forth with those two. After another round of musings, I think it makes sense to move them to the server. In addition, we should move non-SVG version of the icon. This might allow lazy loading of blocks on the client because we would have something to display in the inserters.

Everything JS-based becomes a progressive enhancement loaded on the client when requested.

I moved title, description, icon and keywords to the server, too.

gziolo · 2018-03-27T07:47:15Z

Any reason this is limited to dynamic blocs?

Just to keep the scope of the PR smaller. I would like to divide the efforts into 2 chunks. First, I'd like to refactor all dynamic blocks and provide deprecation strategy to that area. In the long run it should be enforced to declare all the properties listed in this PR on the server.

Next step would be to convert all static blocks to be server-side rendered and promote such usage.

@mtias suggested keeping the client-side registration for very simple blocks forever. We will need to come up with a set of rules when that would be possible. The biggest issue we discovered so far is when hooks updates attributes schema. My personal preference would be to have it possible only on the server to make sure that it happens in one place and it ensures that dynamic blocks have always the same schema on the server and the client.

nb · 2018-04-03T16:50:35Z

How is this related to #4841?

aduth · 2018-04-03T19:38:18Z

registerBlockType will remain with deprecation message for the next 2-3 releases to make sure developers have time to refactor their plugins.

If someone wanted to implement a Gutenberg editor outside a WordPress context, how would they do so without being able to register a block? We're limiting capabilities of the client, when we should continue to treat it as first-class, even if data is being pre-loaded by the server. The benefits of registering blocks on the server should be obvious enough to entice plugin authors into doing so.

mcsf · 2018-04-10T14:28:09Z

suggested keeping the client-side registration for very simple blocks forever. We will need to come up with a set of rules when that would be possible

This is tricky. On one hand, I was going to comment that we can keep the client-side interface with no restrictions if we make it clear — through naming, foremost — that it's meant for debugging and quick prototyping, thus making it acceptable for the very smallest plugins to use it if they so choose. On the other hand, it's hard to reconcile with:

If someone wanted to implement a Gutenberg editor outside a WordPress context, how would they do so without being able to register a block? We're limiting capabilities of the client, when we should continue to treat it as first-class

I mean, we could say that the server-side method is the canonical one and, as an encouragement, only offer filters for it and not for the client-side method. However, on a technical level, there isn't a strong argument for not opening this up to client-side filtering (except, perhaps, for a concern of consistency), what with hooks readily available.

Trying to think more broadly about Gutenberg as the first-class editor and its role within WordPress, maybe it makes sense — borrowing terminology from React — to think of WordPress as a provider for the editor. Under that light, it would make sense to:

make the server-side method filterable, as WordPress's canonical registration method;
make the client-side method non-filterable, as a low-level interface for debugging/prototyping;
make a very thin "standalone provider" for Gutenberg, independent of WordPress and other backends, to be loaded with Gutenberg if one wishes to use the latter as a standalone editor;
within that standalone provider, leveraging hooks or something equivalent, implement a filterable block-registration interface with ultimately calls the low-level interface cited in (2).

gziolo · 2018-05-16T07:55:27Z

This one is stale and @youknowriad is working on a different set of changes in #6733. Let's close it and continue there.

gziolo self-assigned this Mar 26, 2018

gziolo force-pushed the update/block-server-side-settings branch from 06953cf to 5ddf413 Compare March 26, 2018 14:45

youknowriad reviewed Mar 26, 2018

View reviewed changes

gziolo mentioned this pull request Mar 27, 2018

Port the core/code block to be used by the ReactNative mobile GB app #5816

Merged

6 tasks

gziolo added this to the 2.6 milestone Mar 29, 2018

gziolo force-pushed the update/block-server-side-settings branch 2 times, most recently from 539ec1b to 271404c Compare March 29, 2018 14:41

gziolo mentioned this pull request Mar 30, 2018

wp.blocks.getBlockTypes() does not return core blocks making it impossible to create a whitelist of blocks #5895

Closed

gziolo added 3 commits March 30, 2018 11:59

Blocks: Make the block registration filterable on the server

7b4a4ad

Tests: Regenerate fixtures after moving some settings server-side

3602525

Blocks: Move more properties to the server for dynamic blocks

c226868

gziolo force-pushed the update/block-server-side-settings branch from 271404c to c226868 Compare March 30, 2018 09:59

gziolo mentioned this pull request Apr 3, 2018

Provide an API to validate block input, either client-side or server-side #4063

Closed

gziolo modified the milestones: 2.6, 2.7 Apr 5, 2018

gziolo requested a review from mcsf April 10, 2018 12:18

gziolo removed this from the 2.7 milestone Apr 13, 2018

jasonbahl mentioned this pull request Apr 19, 2018

Consider real-world usage of WordPress to quantify assumptions made across the Gutenberg project #6228

Closed

gziolo closed this May 16, 2018

gziolo deleted the update/block-server-side-settings branch May 16, 2018 07:55

gziolo mentioned this pull request May 16, 2018

Block API: Introduce block definitions and implementations #6733

Closed

designsimply added [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed. and removed [Status] In Progress Tracking issues with work in progress labels Aug 16, 2018

gziolo mentioned this pull request Nov 2, 2018

Expose available blocks via an API #4116

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] Blocks: Make the block registration filterable on the server#5802

[WIP] Blocks: Make the block registration filterable on the server#5802
gziolo wants to merge 3 commits intomasterfrom
update/block-server-side-settings

gziolo commented Mar 26, 2018 •

edited by designsimply

Loading

Uh oh!

youknowriad Mar 26, 2018

Uh oh!

gziolo Mar 27, 2018

Uh oh!

gziolo Mar 29, 2018

Uh oh!

youknowriad left a comment

Uh oh!

youknowriad Mar 26, 2018

Uh oh!

gziolo Mar 27, 2018 •

edited

Loading

Uh oh!

gziolo Mar 29, 2018

Uh oh!

gziolo commented Mar 27, 2018

Uh oh!

nb commented Apr 3, 2018

Uh oh!

aduth commented Apr 3, 2018

Uh oh!

mcsf commented Apr 10, 2018

Uh oh!

gziolo commented May 16, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

		@@ -172,20 +172,10 @@ export const name = 'core/block';

		export const settings = {
		title: __( 'Shared Block' ),

Conversation

gziolo commented Mar 26, 2018 • edited by designsimply Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Screenshots (jpeg or gifs if applicable):

Types of changes

Checklist:

Uh oh!

youknowriad Mar 26, 2018

Choose a reason for hiding this comment

Uh oh!

gziolo Mar 27, 2018

Choose a reason for hiding this comment

Uh oh!

gziolo Mar 29, 2018

Choose a reason for hiding this comment

Uh oh!

youknowriad left a comment

Choose a reason for hiding this comment

Uh oh!

youknowriad Mar 26, 2018

Choose a reason for hiding this comment

Uh oh!

gziolo Mar 27, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gziolo Mar 29, 2018

Choose a reason for hiding this comment

Uh oh!

gziolo commented Mar 27, 2018

Uh oh!

nb commented Apr 3, 2018

Uh oh!

aduth commented Apr 3, 2018

Uh oh!

mcsf commented Apr 10, 2018

Uh oh!

gziolo commented May 16, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

gziolo commented Mar 26, 2018 •

edited by designsimply

Loading

gziolo Mar 27, 2018 •

edited

Loading