![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#65368 closed defect (bug) (fixed)
Build/Test Tools: Bump bundled Gutenberg build to `23.4.0`
| Reported by: | adamsilverstein | Owned by: | desrosj |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.1 |
| Component: | Build/Test Tools | Version: | |
| Severity: | normal | Keywords: | has-patch commit |
| Cc: | Focuses: |
Description (last modified by )
Core bundles a pre-built copy of Gutenberg, pinned by commit SHA in the custom gutenberg.sha field of package.json. This ticket bumps that pin to 0e198c7ac7ca634e73ded9220ce048c0302174dd and refreshes the regenerated build artifacts.
The pin tracks the wp/next branch rather than Gutenberg trunk: trunk currently requires React 19 while core ships React 18, so a trunk-based bundle breaks the block editor. 0e198c7 is the current tip of wp/next, is React-18 compatible, and carries the HEIC client-side code.
Notes
- The changed files under
src/wp-includes/{blocks,assets,build,images}are regenerated Gutenberg build output, produced bynpm run gutenberg:download. package.json'sgutenberg.shafield is the only hand edit;package-lock.jsonis unaffected, because the SHA lives in a custom field rather than the npm dependency tree.
Patch
- PR 12009 -
update/bundled-gutenberg-0e198c7
Steps to reproduce / verify
- Apply the patch (or check out PR 12009).
- Run
npm run buildand confirm the block editor loads without React initialization errors.
Previously:
Change History (13)
This ticket was mentioned in PR #12009 on WordPress/wordpress-develop by @adamsilverstein.
7 weeks ago
#1
- Keywords has-patch added
@adamsilverstein commented on PR #12009:
7 weeks ago
#2
I noticed an experiments folder in build/pages and a route folder 'experiments-home' - do those belong in core?
It would be good to land https://github.com/WordPress/gutenberg/pull/76715 - short of that, should those folders be excluded from the core commit.
@westonruter commented on PR #12009:
7 weeks ago
#4
I'm not sure how to review such PRs. I'd appreciate pointers!
@adamsilverstein commented on PR #12009:
7 weeks ago
#5
I'm not sure how to review such PRs. I'd appreciate pointers!
we probably need someone with deep Gutenberg familiarity to review. I only changed the Gutenberg SHA - every other change was generated.
@westonruter commented on PR #12009:
7 weeks ago
#6
@adamsilverstein So you bumped the hash in a57e63d7200157887c1e75b7eefbb940599434e1 and then for f1ff566fdcb42a1a1422018cd484dc05e3373e79 you just ran npm run build and committed the result?
@adamsilverstein commented on PR #12009:
7 weeks ago
#7
@adamsilverstein[[Image(chrome-extension://hgomfjikakokcbkjlfgodhklifiplmpg/images/wp-logo.png)]] So you bumped the hash in a57e63d and then for f1ff566 you just ran
npm run buildand committed the result?
I also ran npm run gutenberg:download && npm run gutenberg:copy . I'm not super familiar with the build system and haven't looked too carefully yet, but those don't seem to get run (and I don't see the changes) with npm run build or even npm run build:gutenberg. Previously I assumed all we had to do was update the SHA (which i've done in the past with some backport PRs without running the extra commands).
Some of the files/paths are added, I guess we need to review those carefully to see what should really be added:
I'm guerssing at least src/wp-includes/build/pages/experiments/ and src/wp-includes/build/routes/experiments-home/ can be excluded.
@wildworks commented on PR #12009:
3 weeks ago
#8
The current Gutenberg ref points to Gutenberg version 23.4. How about updating the commit hash to the latest one from Gutenberg trunk again? The newer the commit hash, the closer the core state will be to what is expected in Beta1.
@desrosj commented on PR #12009:
3 weeks ago
#9
The current Gutenberg ref points to Gutenberg version 23.4. How about updating the commit hash to the latest one from Gutenberg trunk again? The newer the commit hash, the closer the core state will be to what is expected in Beta1.
Since the current plan is to sync changes during weeks opposite each plugin release, let's leave it as 23.4 right now to see how that cadence works.
#10
@
3 weeks ago
- Keywords commit added
- Owner set to
- Status new → assigned
- Summary Build/Test Tools: Bump bundled Gutenberg build to `0e198c7` → Build/Test Tools: Bump bundled Gutenberg build to `23.4.0`
I think this is good to go in and I'll be committing this shortly. I have a post drafted to outline the structure of this process going forward that I plan to publish just after merging.
@wildworks commented on PR #12009:
3 weeks ago
#13
If possible, I would appreciate it if we could update the Gutenberg ref again before the Beta1 release.
This is because CI errors occurred in #11559. #11559 attempts to change the WP_Icons_Registry::register method from protected to public. However, in Gutenberg 23.4, this method is overridden as protected in a child class, which causes a fatal error due to narrowing the class visibility. In the latest version of Gutenberg, this method is public, but this is not yet included in 23.4. To resolve this fatal error, we must update to the latest Gutenberg ref.
## What
Bumps the bundled Gutenberg build to
0e198c7ac7ca634e73ded9220ce048c0302174dd(current tip of thewp/nextbranch) and updates the regenerated build artifacts.This is a one time bump to bring Guternberg up to date in core since the trunk code freeze. In the future we will settle on a regular cadence to update this SHA.
## Why
Needed to bring Gutenberg up to date and enable backports to function correctly.
wp/nextis used rather than Gutenbergtrunkbecause trunk currently requires React 19 while core ships React 18;0e198c7is React-18 compatible and carries the HEIC client-side code.## Notes
src/wp-includes/{blocks,assets,build,images}are regenerated Gutenberg build output, produced bynpm run gutenberg:download.package.json'sgutenberg.shafield is the only hand edit;package-lock.jsonis unaffected (the SHA lives in a custom field, not the npm dependency tree).