WordPress.org

Make WordPress Core

Opened 4 months ago

Closed 4 months ago

Last modified 4 months ago

#53507 closed defect (bug) (fixed)

Block style version: replace filemtime with version from Block API metadata

Reported by: hellofromTonya Owned by: desrosj
Milestone: 5.8 Priority: normal
Severity: normal Version: 5.5
Component: Script Loader Keywords: has-patch commit
Focuses: Cc:

Description (last modified by desrosj)

In register_block_style_handle function, the version used for registering a style handle is the file's modification time (via filemtime).

This should be removed in favor of using the block's version in its metadata.

Why?

A block is a package. In that package is everything the block needs including its script and styles. When the block changes, the version reflects the block's new version. Following that line of thinking, the version registered via the Block API is the block's version, meaning its the version for the script and styles.

Setting the version is optional. When it's not set, then like other assets, it defaults to false.

Why not filemtime()?
Performance. This function hits the filesystem which takes time and memory. Using it in development is the norm and acceptable. But in production, it's less performant than using the supplied version when registering the block.

This is a follow-up ticket to #53375.

Attachments (1)

53507.diff (676 bytes) - added by desrosj 4 months ago.

Download all attachments as: .zip

Change History (14)

#1 @desrosj
4 months ago

The Block API Metadata reference does not list version as a top level field, but it seems that an assumption is made that it is included because register_block_script_handle() is using the field in the wp_register_script() call.

#2 @gziolo
4 months ago

@desrosj, it's not listed as a top-level field, but we should introduce one to cover this use case. It would be a good fallback for the case when the asset file is not generated for the script. For styles, we don't have asset files present so they could use the version of the plugin by default instead of hitting the filesystem to read the modification date of the file.

#3 @desrosj
4 months ago

  • Milestone changed from Awaiting Review to 5.8

Moving to the 5.8 milestone to discuss fixing.

This ticket was mentioned in Slack in #core-editor by desrosj. View the logs.


4 months ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


4 months ago

@desrosj
4 months ago

#6 @desrosj
4 months ago

  • Keywords has-patch dev-feedback added; needs-patch good-first-bug removed

53507.diff is an update that removes filemtime() in favor of using $metadata['version'].

With this patch, non-Core blocks would use the WordPress version unless a version was supplied in the blocks.json file.

I did some spot checking of blocks in the directory, and I did not find any with version defined as a top level field in blocks.json. This patch would allow us to avoid using filemtime() in production, but it would require a dev note and some outreach to encourage block developers to add this to their blocks.json files.

#7 @jorbin
4 months ago

  • Keywords commit added

This feels like a good and simple way to get rid of filemtime to me.

#8 @gziolo
4 months ago

With this patch, non-Core blocks would use the WordPress version unless a version was supplied in the blocks.json file.

Yes, this should work as intended, and it is simple enough to include as the last-moment fix for WordPress 5.8 release.

I did some spot checking of blocks in the directory, and I did not find any with version defined as a top level field in blocks.json.

Correct. There is apiVersion but it's related to the change introduced in WordPress 5.6 (https://make.wordpress.org/core/2020/11/18/block-api-version-2/) and it has a completely different purpose related so far to the client-side implementation of the block.

If we assume that the version is similar to what plugin authors provide as the version in the metadata, we could consider going a step further. In the future, we could make the version also a field on the WP_Block_Type object and include it in the REST API endpoint for block types. In general, it would go in the direction I proposed in #53149 - feed block.json with all fields that are now provided in the PHP file as plugin metadata like plugin version, min PHP version, license information, etc.

This ticket was mentioned in Slack in #core-editor by gziolo. View the logs.


4 months ago

#10 @desrosj
4 months ago

  • Keywords dev-feedback removed
  • Owner set to desrosj
  • Status changed from new to assigned

#11 @desrosj
4 months ago

  • Description modified (diff)

#12 @desrosj
4 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 51262:

Script Loader: Use the provided block version when registering styles.

This updates register_block_style_handle() to use the version value provided in the $metadata parameter for non-Core blocks (when present). This removes the requirement to use filemtime() to generate a unique version.

When version is not defined within $metadata, the script version will fallback to using the current version of WordPress.

The block version should be considered similar to the one specified by plugin developers within the header of the main plugin file.

Props hellofromTonya, gziolo, jorbin, desrosj, walbo, aristath.
Fixes #53507.

#13 @desrosj
4 months ago

I've opened https://github.com/WordPress/gutenberg/pull/33075 to discuss moving forward with using and encouraging version in block.json in a more organized way.

Note: See TracTickets for help on using tickets.