[wp-trac] [WordPress Trac] #63254: Introduce development mode for block editor styles

WordPress Trac noreply at wordpress.org
Tue Apr 8 23:28:06 UTC 2025


#63254: Introduce development mode for block editor styles
-------------------------------------+------------------------------
 Reporter:  helgatheviking           |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Editor                   |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------
Changes (by sabernhardt):

 * component:  General => Editor


Old description:

> When a block script is defined in the `block.json` and registered
> automatically via `register_block_script_handle()` the version is pulled
> from [the script asset php file if it
> exists](https://github.com/WordPress/wordpress-
> develop/blob/6511cc02f764a3d9c0dd105e5366fdfe63a564cc/src/wp-
> includes/blocks.php#L242). This ensures that the cache is always busted
> when the file is updated.
>
> Something similar should exist for `register_block_style_handle` as
> otherwise it's a total pain to develop editor styles. I just lost a few
> hours this morning wondering why my styles didn't update even though I am
> using the `@wordpress/scripts` package to recompile them on every change.
>
> The answer was ultimately that the version is pulled from the
> `block.json`'s "version" property which doesn't change while building.
>
> Replacing this:
> ```
> $version = ! $is_core_block && isset( $metadata['version'] ) ?
> $metadata['version'] : false;
> $result  = wp_register_style(
>         $style_handle_name,
>         $style_uri,
>         array(),
>         $version
> );
> ```
>
> with this:
> ```
> $block_version = ! $is_core_block && isset( $metadata['version'] ) ?
> $metadata['version'] : false;
> $version = SCRIPT_DEBUG ? filemtime( $style_path_norm ) : $block_version;
>
> $result  = wp_register_style(
>         $style_handle_name,
>         $style_uri,
>         array(),
>         $version
> );
> ```
>
> Should do the trick. The assets file is another option.

New description:

 When a block script is defined in the `block.json` and registered
 automatically via `register_block_script_handle()` the version is pulled
 from [https://github.com/WordPress/wordpress-
 develop/blob/6511cc02f764a3d9c0dd105e5366fdfe63a564cc/src/wp-
 includes/blocks.php#L242 the script asset PHP file if it exists]. This
 ensures that the cache is always busted when the file is updated.

 Something similar should exist for `register_block_style_handle` as
 otherwise it's a total pain to develop editor styles. I just lost a few
 hours this morning wondering why my styles didn't update even though I am
 using the `@wordpress/scripts` package to recompile them on every change.

 The answer was ultimately that the version is pulled from the
 `block.json`'s "version" property which doesn't change while building.

 Replacing this:
 {{{
 $version = ! $is_core_block && isset( $metadata['version'] ) ?
 $metadata['version'] : false;
 $result  = wp_register_style(
         $style_handle_name,
         $style_uri,
         array(),
         $version
 );
 }}}

 with this:
 {{{
 $block_version = ! $is_core_block && isset( $metadata['version'] ) ?
 $metadata['version'] : false;
 $version = SCRIPT_DEBUG ? filemtime( $style_path_norm ) : $block_version;

 $result  = wp_register_style(
         $style_handle_name,
         $style_uri,
         array(),
         $version
 );
 }}}

 Should do the trick. The assets file is another option.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63254#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list