build: Upgrade remaining @wordpress/* packages to .38 series#324
Merged
build: Upgrade remaining @wordpress/* packages to .38 series#324
Conversation
f85d276 to
80ba09d
Compare
dbb27fe to
8236350
Compare
80ba09d to
f1f6a07
Compare
cc41f92 to
2522054
Compare
This was referenced Feb 24, 2026
4b0be94 to
6fb1944
Compare
kean
approved these changes
Feb 25, 2026
| icon: getBlockIcon( item ), | ||
| frecency: item.frecency || 0, | ||
| isDisabled: item.isDisabled || false, | ||
| isSearchOnly: item.isSearchOnly || false, |
Contributor
There was a problem hiding this comment.
This wasn't too bad, especially since the actual business logic is still in the framework.
Upgrade all @wordpress/* dependencies to their .38.0 versions to align with @wordpress/format-library@5.38.0's requirement for @wordpress/components@^32.0.0. The previous mix of .36.0 and .38.0 packages caused duplicate @wordpress/components installations (v30.9.0 at the root and v32.0.0 nested), which led to React context mismatches and block rendering failures.
Regenerate patches for @wordpress/block-editor (15.11.0 -> 15.12.0), @wordpress/block-library (9.36.0 -> 9.39.0), @wordpress/editor (14.36.0 -> 14.39.0), and @wordpress/rich-text (7.38.0 -> 7.39.0). The underlying fixes are unchanged; only the target versions and file extensions (.js -> .mjs) were updated.
…view Pass `isSearchOnly` through the block serialization pipeline and use it to separate browsable blocks from search-only blocks (e.g. heading level variations h1–h6 introduced in WordPress/gutenberg#73823). Search-only blocks are placed in a dedicated `gbk-search-only` section that the native inserter hides in browse mode but includes when the user searches, matching the web inserter's behavior.
Instead of preserving section groupings during search, flatten all blocks (including search-only) into one section ranked by relevance. This avoids the same block appearing in multiple sections and provides a cleaner search experience, mirroring the approach used by the web inserter.
a5f53ce to
ff7fdfa
Compare
This file contains hidden or 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
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.
What?
Upgrade all remaining
@wordpress/*packages from the .36 series to the .38 series to align with@wordpress/format-library@5.38.0, and adapt the native block inserter to handle new heading level variations introduced upstream.Why?
After upgrading
@wordpress/format-libraryto 5.38.0 (in #323), the project had a mix of .36.0 and .38.0 packages. This caused duplicate@wordpress/componentsinstallations (v30.9.0 at the root and v32.0.0 nested under format-library), which can lead to React context mismatches and block rendering failures.Upgrading all packages to the .38 series eliminates the duplicate installations and ensures a single, consistent dependency tree.
Additionally, the .38 series includes WordPress/gutenberg#73823, which converts heading levels (h1–h6) from an attribute-based system to block variations with
scope: ['block', 'transform']. These variations are markedisSearchOnlyin the inserter items — the web inserter correctly hides them from its browse view while keeping them searchable. Without changes on our side, the native block inserter displayed all six heading level variations as separate blocks in the browse grid, which is incorrect.How?
Dependency upgrades
@wordpress/*dependencies inpackage.jsonto their .38.0 versions@wordpress/block-editor15.11.0 → 15.12.0@wordpress/block-library9.36.0 → 9.39.0 (.js→.mjs)@wordpress/editor14.36.0 → 14.39.0 (.js→.mjs)@wordpress/rich-text7.38.0 → 7.39.0The underlying patch fixes are unchanged; only the target versions and file extensions were updated.
Native block inserter: search-only variations
src/utils/blocks.js): Passes through theisSearchOnlyproperty from inserter items and separates search-only blocks (e.g. heading level variations) into a dedicatedgbk-search-onlysection, keeping them out of browse sections (most-used, category).BlockType.swift): AddedisSearchOnlyproperty to the block data model.BlockInserterViewModel.swift): Hides thegbk-search-onlysection from the browse view. During search, flattens all blocks (including search-only) into a single ranked list, deduplicating by ID to avoid empty grid cells caused by the same block appearing in multiple sections. This mirrors the web inserter's approach of showing a flat, relevance-ranked result list.Testing Instructions
npm ci— all patches should apply cleanly with no warningsAccessibility Testing Instructions
No accessibility-facing UI changes — the inserter grid layout and interaction model are unchanged. The only difference is which blocks are shown and how search results are grouped.
Important
The "stretchy" block type was converted to a variation, which is why it is absent in the "after" search results.