Opened 5 months ago
Last modified 5 months ago
#61696 new enhancement
Make overriding and back porting classes from gutenberg repo easier
Reported by: | spacedmonkey | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 5.0 |
Component: | Editor | Keywords: | |
Focuses: | Cc: |
Description
The gutenberg repo overrides a number of core classes, including but not limited to
- WP_Theme_JSON -> WP_Theme_JSON_Gutenberg
- WP_Theme_JSON_Data -> WP_Theme_JSON_Data_Gutenberg
- WP_Theme_JSON_Resolver -> WP_Theme_JSON_Resolver
- WP_Theme_JSON_Schema -> WP_Theme_JSON_Schema_Gutenberg
- WP_Duotone -> WP_Duotone_Gutenberg
Currently this has a number of issues, including
- Overrides are not perfect, so it is unperdictable what version of this class will be used, core or gutenberg.
- It makes backporting changes to these classes a manaul process.
- It makes it hard to write unit test the code.
Recommendation
Add filters similar to parse_blocks
function.
function parse_blocks( $content ) {
/**
* Filter to allow plugins to replace the server-side block parser.
*
* @since 5.0.0
*
* @param string $parser_class Name of block parser class.
*/
$parser_class = apply_filters( 'block_parser_class', 'WP_Block_Parser' );
$parser = new $parser_class();
return $parser->parse( $content );
}
Possible issues:
A number of these classes, have static methods and consts, that make referencing class name by string a little harder.
Change History (3)
This ticket was mentioned in Slack in #core-editor by spacedmonkey. View the logs.
5 months ago
This ticket was mentioned in Slack in #core by spacedmonkey. View the logs.
5 months ago
#3
@
5 months ago
Version 0, edited 5 months ago
by
(next)
Note: See
TracTickets for help on using
tickets.
This same concern was previously raised in https://github.com/WordPress/gutenberg/issues/62594.
In that discussion, another option that was discussed was to make these classes in the WordPress repo read-only and sync them the way we do PHP code in block packages.
While that would make maintainability a bit easier, it still doesn't allow the same code paths to be tested by the Gutenberg plugin that will be run once the code is synced, since many times the static methods are referenced directly in code, as you rightly point out.
I agree that being able to filter the entire class being used would help here and pointed out
_wp_image_editor_choose
andrest_get_server
a couple other examples of functions where Core provides filters for overriding entire classes.