WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 23 months ago

#45109 closed task (blessed) (fixed)

Introduce editor block related functions

Reported by: desrosj Owned by: pento
Milestone: 5.0 Priority: normal
Severity: normal Version:
Component: Editor Keywords: fixed-5.0
Focuses: Cc:

Description

The editor's block related functions are located in /lib/blocks.php of Gutenberg. These should exist in WordPress Core instead.

Attachments (1)

45109.diff (5.0 KB) - added by swissspidy 2 years ago.
Fix package name and text domains

Download all attachments as: .zip

Change History (23)

#1 @pento
2 years ago

  • Owner set to pento
  • Status changed from new to assigned

#2 @pento
2 years ago

In 43742:

Blocks: Introduce WP_Block_Type and WP_Block_Type_Registry classes.

These are the foundational classes allowing blocks to be registered and used throughout WordPress.

This commit also includes the has_block() and has_blocks() functions, which are required for unit testing these classes.

Props adamsilverstein, danielbachhuber, desrosj.
See #45097, #45109.

#3 @pento
2 years ago

In 43743:

Blocks: Introduce register_block_type(), unregister_block_type(), and get_dynamic_blocks() functions.

These helper functions allow easy access to the global block registry.

See #45109.

#4 follow-up: @pento
2 years ago

In 43751:

Blocks: Introduce the block parser.

The WP_Block_Parser class, and the accompanying parse_blocks() helper function, can be used to parse an array of blocks out of a content string.

WP_Block_Parser is copied from the @wordpress/block-serialization-default-parser package. To ensure it stays in sync with the JavaScript parser, changes should be implemented in the package first, then the package version should be upgraded to include the changes.

See #45109.

#5 @pento
2 years ago

In 43752:

Blocks: Parse blocks when displaying posts.

Posts containing blocks are now correctly handled when displaying on the front end, including dynamic blocks and nested blocks.

See #45109.

#6 @pento
2 years ago

  • Keywords fixed-5.0 added; needs-patch needs-unit-tests removed

There are still some issues (eg, GB#10463) to be tackled, but that can be done in a seperate ticket. This one is done for now.

#7 in reply to: ↑ 4 ; follow-up: @dimadin
2 years ago

Replying to pento:

WP_Block_Parser is copied from the @wordpress/block-serialization-default-parser package. To ensure it stays in sync with the JavaScript parser, changes should be implemented in the package first, then the package version should be upgraded to include the changes.

What about @since tags? Do all three classes must be in the same file?

Also, in [43752] you probably included /blocks directory by mistake.

#8 in reply to: ↑ 7 @pento
2 years ago

Replying to dimadin:

What about @since tags? Do all three classes must be in the same file?

Because WP_Block_Parser comes from an external package, any @since tags are related to the package version, not the WordPress version. This is similar to other external packages, such as SimplePie, for example.

Also, in [43752] you probably included /blocks directory by mistake.

/src/wp-includes/blocks? That's intentional, it contains the PHP needed to for the dynamic blocks that are included in Core. It's similar to the /src/wp-includes/widgets directory.

@swissspidy
2 years ago

Fix package name and text domains

#9 @swissspidy
2 years ago

@pento Please note that you forgot to remove the gutenberg text domain for all the strings in wp-includes/blocks. I fixed those and the package names in 45109.diff.

Also, not really happy with the gutenberg_ function prefixes there. Especially since a function like gutenberg_draft_or_post_title() can be used in lots of other places like Walker_PageDropdown::start_el(), wp_prepare_attachment_for_js(), WP_Widget_Recent_Posts::widget() or wp_ajax_find_posts(), perhaps even more.

#10 @pento
2 years ago

These are copied from @wordpress/block-library so need to be fixed in the Gutenberg repo.

I've opened an issue for removing the text domain.

I agree that there's still work to be done to clean up the naming here, we can reshuffle things a bit.

#11 @youknowriad
2 years ago

@pento Did you consider loading the block-library php files directly from the npm packages instead of copying them over?

My concern with copying is that these are highly tied to their JavaScript part, so they should probably live together.

#12 @pento
2 years ago

@youknowriad: The files are copied from the npm package as part of the grunt webpack:dev script, they're intended to be maintained in the package, and copied into core when the package is upgraded.

#13 @youknowriad
2 years ago

@gary Oh great, I missed that part.

#14 @ocean90
2 years ago

#45180 was marked as a duplicate.

#15 @SergeyBiryukov
2 years ago

  • Component changed from General to Editor

#16 @swissspidy
2 years ago

Why do gutenberg_render_block_core_latest_comments and gutenberg_draft_or_post_title still have the gutenberg_ prefix where other functions like render_block_core_latest_posts don't? That looks quite arbitrary.

#17 @pento
2 years ago

Thank you for the reminder, @swissspidy. I've added an issue in the Gutenberg repo to track that, too.

#18 @pento
23 months ago

In 44108:

Blocks: Introduce WP_Block_Type and WP_Block_Type_Registry classes.

These are the foundational classes allowing blocks to be registered and used throughout WordPress.

This commit also includes the has_block() and has_blocks() functions, which are required for unit testing these classes.

Merges [43742] from the 5.0 branch to trunk.

Props adamsilverstein, danielbachhuber, desrosj.
Fixes #45097.
See #45109.

#19 @pento
23 months ago

In 44109:

Blocks: Introduce register_block_type(), unregister_block_type(), and get_dynamic_blocks() functions.

These helper functions allow easy access to the global block registry.

Merges [43743] from the 5.0 branch to trunk.

See #45109.

#20 @desrosj
23 months ago

In 44116:

Blocks: Introduce the block parser.

The WP_Block_Parser class, and the accompanying parse_blocks() helper function, can be used to parse an array of blocks out of a content string.

WP_Block_Parser is copied from the @wordpress/block-serialization-default-parser package. To ensure it stays in sync with the JavaScript parser, changes should be implemented in the package first, then the package version should be upgraded to include the changes.

Props pento.

Merges [43751] to trunk.

See #45109.

#21 @desrosj
23 months ago

In 44118:

Blocks: Parse blocks when displaying posts.

Posts containing blocks are now correctly handled when displaying on the front end, including dynamic blocks and nested blocks.

Props pento.

Merges [43752] to trunk.

See #45109.

#22 @SergeyBiryukov
23 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.