Skip to content
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

Replace unstable__bootstrapServerSideBlockDefinitions with call to block type REST API #22812

Open
spacedmonkey opened this issue Jun 1, 2020 · 3 comments
Labels
[Feature] Block API API that allows to express the block paradigm. Needs Dev Ready for, and needs developer efforts REST API Interaction Related to REST API [Type] Task Issues or PRs that have been broken down into an individual action to take

Comments

@spacedmonkey
Copy link
Member

spacedmonkey commented Jun 1, 2020

Part of #41236.

Currently in WordPress core the follow lines appear.

// Preload server-registered block schemas.
wp_add_inline_script(
	'wp-blocks',
	'wp.blocks.unstable__bootstrapServerSideBlockDefinitions(' . wp_json_encode( get_block_editor_server_block_settings() ) . ');'
);

This was a workaround added in WordPress 5.0. Now that the block types endpoint was added in #21065 , this should be used as the "point of truth" for block definitions.

Describe the solution you'd like
The block types api should be preloaded on the page by adding it to this array.

@aduth aduth added [Feature] Block API API that allows to express the block paradigm. REST API Interaction Related to REST API labels Jun 1, 2020
@aduth
Copy link
Member

aduth commented Jun 1, 2020

This would be a good application of the new block types endpoint. 👍

As far as implementation, it's unclear to me in how @wordpress/blocks remains rather agnostic to the source of block type definitions whether it should be the point where the implementation occurs.

Instead, it may be something that ought to occur elsewhere in the editor initialization where this sort of integration would be appropriate.

For example, one of:

In any case, the implementation should use the new REST API endpoint, in combination with @wordpress/api-fetch (see mentioned preloading in original comment) and possibly (ideally?) as a reusable data entity from @wordpress/core-data.

@gziolo gziolo added Needs Dev Ready for, and needs developer efforts [Type] Task Issues or PRs that have been broken down into an individual action to take labels Jun 2, 2020
@gziolo gziolo added the [Status] In Progress Tracking issues with work in progress label Oct 25, 2021
@gziolo gziolo self-assigned this Oct 25, 2021
@gziolo gziolo moved this to Todo in WordPress Nov 24, 2021
@gziolo gziolo added this to WordPress Nov 24, 2021
@gziolo gziolo moved this from Todo to In Progress in WordPress Jan 4, 2022
@gziolo gziolo moved this from In Progress to Todo in WordPress Jan 10, 2022
@gziolo gziolo removed the [Status] In Progress Tracking issues with work in progress label Jan 13, 2022
@gziolo gziolo removed their assignment Jan 13, 2022
@gziolo gziolo mentioned this issue May 23, 2022
69 tasks
@spacedmonkey
Copy link
Member Author

@gziolo @Mamaduka Any chance we could get eyes on this ticket?

@Mamaduka
Copy link
Member

Mamaduka commented Jan 4, 2024

@spacedmonkey, chatted briefly with @gziolo about this ticket and WordPress/wordpress-develop#5718 (comment). Agreed that the source of the truth should be REST API for the editors, whenever possible.

@kt-12 mentioned that some information is missing for dynamic blocks returned via API.

It would also be nice to see performance metrics when preloading data via block_editor_rest_api_preload vs. get_block_editor_server_block_settings.

cc @@joemcgill

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. Needs Dev Ready for, and needs developer efforts REST API Interaction Related to REST API [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

No branches or pull requests

4 participants