[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