Block API: Improve how blocks assets are versioned #33075
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I've starting to dig through and find places where changes would be required, but please feel free to add more updates, or thoughts in general. I'm also not sure how we would version the Core blocks in Gutenberg. In WordPress, they will fall back to the Core version, but in the plugin they could be set to the plugin version. However, that could create some confusion as to which versions correspond in the two spots. |
|
Size Change: +5 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
gziolo
added
[Tool] Create Block
gziolo
force-pushed
the
top-level-version-field
branch
from
0dfd870 to
6781e8b
Compare
|
I documented the new |
gziolo
requested review from
ajitbohra,
chrisvanpatten,
gziolo and
mkaz
as code owners
As far as I can tell all styles related to blocks have a custom handling that handles the version for the asset. Examples: Lines 183 to 188 in c26c506 Lines 230 to 235 in c26c506 Lines 243 to 248 in c26c506 |
gziolo
added
[Feature] Block API
gziolo
changed the title
gziolo
approved these changes
Jul 13, 2021
gziolo
force-pushed
the
top-level-version-field
branch
from
6781e8b to
f795bda
Compare
|
I'm wondering where we should include a note that for styles it will use the WP version if the |
That's what WP has always done when enqueueing assets, so it's not a surprise we do it here... I assume adding that extra piece of information in this sentence would be fine https://github.com/WordPress/gutenberg/pull/33075/files#diff-a0ff8c8636cfde7611c78988dd1ae555ca8ebfa334148529a780e79cb2c9ba36R264 |
aristath
approved these changes
Jul 15, 2021
gziolo
force-pushed
the
top-level-version-field
branch
from
f795bda to
fc636c1
Compare
|
Thank you @aristath for your feedback. I reworded the description for
|
Is it worth changing this to "the installed version of WordPress"? May be over thinking it, but the installed and current versions of WordPress can be different. |
gziolo
reviewed
Jul 15, 2021
|
Subtle but meaningful difference. I agree it's more precise 👍🏻 |
gziolo
added a commit
that referenced
this pull request
Jul 21, 2021
* Add version to generated `block.json` files. * Document new `version` field available in `block.json` * Clarify the case when the version is not set for assets * Update docs/reference-guides/block-api/block-metadata.md Co-authored-by: Grzegorz Ziolkowski <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
There is currently no standardized way for a consistent version for block assets to be supplied to WordPress. For scripts registered server side, one can be provided within the
.asset.phpfile, but there is no equivalent for styles.Developers often times resort to using
filemtime(), which is not ideal for performance reasons, and the browser/proxy cache can be purged frequently with certain deployment setups.Ideally, there should be a single version for all script and style assets belonging to a block when
SCRIPT_DEBUGis not set totrue.versionshould be a recognized, and eventually required, top-level field withinblock.json. Block developers should be encouraged to define a version that matches their plugin's version, or one specific to the individual block when bundling multiple blocks in a single plugin (to prevent invalidating caches when a specific block in a group is not changed).In WordPress 5.8, non-Core blocks are currently set to fallback to the current version of WordPress when
versionis not defined in the metadata. This change was made in order to eliminate the need forfilemtime()in production environments with the plan to publish a dev note and performing outreach to encourage developers to add this field prior to their next update.Other context:
How has this been tested?
Screenshots
Types of changes
Checklist:
*.native.jsfiles for terms that need renaming or removal).