Update Blocks Everywhere for current Gutenberg - #211
Draft
chubes4 wants to merge 120 commits into
Draft
Conversation
… support - Add WordPress 6.9 and PHP 8.4 compatibility - Add comprehensive dark mode and theme variable support for editor UI - Add custom media upload API integration for bbPress - Add automatic attachment reparenting for new bbPress topics - Fix iframe editor styles for responsive embeds - Fix block category retrieval using WP_Block_Editor_Context - Improve script loading order reliability - Update to forked isolated-block-editor dependency - Move legacy changelog to docs/CHANGELOG.md per WP.org recommendations - Add AGENTS.md for development standards
…d media upload enhancements
…ents - Fixed SASS import syntax for modern SASS compatibility - Enhanced TypeScript definitions with optional properties - Updated webpack configuration with isolated-block-editor alias
- Add browser globals to ESLint config (wpBlocksEverywhere, wp, jQuery, etc.) - Add missing dependencies: classnames, @wordpress/icons - Enhance TypeScript type definitions in types.d.ts - Fix JSDoc documentation for functions - Fix accessibility issues in search results (key prop, keyboard handlers) - Fix strict equality operators (=== vs ==) - Configure ESLint overrides for TypeScript files - Auto-fix 127 formatting issues with Prettier Reduces ESLint errors from 275 to 0 (4 warnings remain)
…afety - Fixed 275 ESLint errors through configuration improvements - Enhanced TypeScript type definitions with unknown instead of any - Added missing dependencies (classnames, @wordpress/icons) - Improved JSDoc documentation for better code clarity - Fixed accessibility issues in search results components - Fixed strict equality operators throughout codebase
- Fix toolbar button active state styling with theme-mapped CSS variables - Fix toolbar button pressed state ::before pseudo-element background - Fix list block rendering in iframe editor (bullets and indentation)
Move WordPress-specific theme supports dispatch from isolated-block-editor to blocks-everywhere, keeping isolated-block-editor WordPress-agnostic.
New handler that exposes load_editor() for any plugin to mount a block editor on the frontend without coupling to bbPress, BuddyPress, or comments. Used by extrachill-studio for the Compose tab blog editor.
Removed inserter button accent-3 branding, placeholder card styling, and footer spacing tokens from editor.scss and $iframe_editor_css. These are consumer-specific (Extra Chill brand) and now live in @extrachill/tokens/css/block-editor.css. Blocks Everywhere stays generic — it handles Gutenberg variable mappings and structural theming; consumers add their own brand layer on top.
) * refactor: replace handler subclasses with data-driven context engine Replace the per-handler class pattern (bbPress, BuddyPress, Comments, Frontend) with a single Engine class that processes context configuration arrays identically. External plugins register contexts via the blocks_everywhere_contexts filter. - Add Engine class that manages context registration, trigger wiring, and editor loading - Extract bbPress-specific callbacks to standalone functions in contexts/bbpress-callbacks.php - Move handler configs to context arrays in contexts/{bbpress,buddypress,comments}.php - Delete all handler subclasses (class-bbpress, class-buddypress, class-comments, class-frontend) - Preserve all backward-compatible filters (blocks_everywhere_bbpress, _comments, _buddypress, etc.) - Update tests to use standalone functions instead of handler class methods - Update CLAUDE.md to reflect new architecture * simplify: lean Engine with editor_setup callbacks, remove config bloat Engine reduced from 392 to 243 lines. Config shape shrunk from 22 keys to 7. Domain-specific setup (KSES, save filters, body class, filter removal) moves into editor_setup callbacks owned by each context — the Engine doesn't need to know about bbPress encode_bad or comment KSES contexts. Content display filters, metadata, and email hooks wire directly in context functions instead of going through Engine indirection. * chore: register blocks-everywhere as homeboy component
Handler\bbPress, Handler\BuddyPress, Handler\Comments, Handler\Frontend classes are deleted. Consumers must migrate to blocks_everywhere_contexts filter API. All filter hooks are backward-compatible.
Homeboy release auto-bumped to 1.26.0 instead of 2.0.0 because --major is a permission flag, not a directive. The changelog was generated under the wrong version. This corrects it and removes the phantom 1.26.0 entry.
The Handler base class was calling wp_register_script/wp_register_style in its constructor, which fires at plugin load time before the wp_enqueue_scripts hook. WordPress 6.x logs notices about this. Move registration to an init callback at priority 5 (before the Engine boots at default priority) so assets are registered at the proper time.
WordPress considers init too early for wp_register_script. wp_loaded fires after all plugins are loaded but before page rendering, so assets are registered at the right time.
Add ContentBridge — a React component that renders inside the IBE tree (accessing the sub-registry) and attaches a content API to the textarea element. External code can read/replace editor content without needing direct access to the isolated/editor store. API surface (per textarea): - replaceContent(html) — parse HTML and dispatch replaceContent to store - getContent() — serialize current blocks to HTML - getBlocks() — get raw block objects Global lookup: - window.blocksEverywhereGetContentApi(textarea) — returns the API or null This bridges the sub-registry isolation gap so consumers like Studio and Community can hot-swap editor content without destroying and recreating the editor instance.
Replace the editorKey remount pattern in maybeInstallReplyDraftContextHandler with the ContentBridge replaceContent API. The editor stays mounted when switching between reply targets — content is hot-swapped via the IBE store's replaceContent action which resets blocks and undo history. This is the same API that Studio's compose tab now uses for draft switching.
…ill-modernization # Conflicts: # yarn.lock
chubes4
marked this pull request as ready for review
May 31, 2026 03:10
chubes4
marked this pull request as draft
May 31, 2026 14:26
Clorith
added a commit
to Clorith/wordpress.org
that referenced
this pull request
Jun 9, 2026
This introduces the support forums as an environment in the WordPress.org suite of sites. Complete with full dependency setup, including: - Multisite setup - Plugin and theme directory subsites (scaffolds for plugin and theme support forums, not for their development) - Full set of every usertype available - Default forum creation, mimicking the current WordPress.org forums There is a caveat that Gutenberg is _currently_ pinned to version 17.9, due to the Blocks Everywhere plugin, and that Blocks Everywhere is not rendering properly pending an update in Automattic/blocks-everywhere#211
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
1 participant
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.
Why
WordPress.org support forums are pinned to Gutenberg 17.9 because the upstream Blocks Everywhere plugin is outdated. Automattic
trunkwas still at Blocks Everywhere1.23.0, used@automattic/isolated-block-editor, and could not move cleanly to the latest Gutenberg package set needed for current WordPress work.This PR updates upstream Blocks Everywhere from
1.23.0to3.2.5and brings over the maintained implementation that runs on current WordPress/Gutenberg editor packages without depending onisolated-block-editor.What Changes Versus Automattic Trunk
@automattic/isolated-block-editordependency and replaces it with direct Gutenberg package usage, including@wordpress/block-editor,@wordpress/editor,@wordpress/components,@wordpress/data,@wordpress/core-data, and related packages.classes/contexts/.BlockEditorProvider,BlockCanvas, editor toolbar primitives, and slot/fill wiring.1.23.0to3.2.5, raises PHP requirement to7.4, and updates package/tooling versions.Why This Shape
This is intentionally a large modernization PR rather than a narrow patch. The blocker is the old editor integration layer itself: keeping upstream BE tied to
isolated-block-editorkeeps WordPress.org support forums pinned to an old Gutenberg version. The maintained implementation removes that dependency and gives BE a current, generic editor integration surface that can keep moving with Gutenberg.The new portable editor contracts are intentionally generic: adapters own host routing, permissions, persistence, entity identity, and product-specific UI; Blocks Everywhere owns Gutenberg runtime composition, serialization, lifecycle, services, and extension points.
Verification
yarn wp-scripts lint-js src/index.tsx src/bootstrap-settings.ts src/editor/index.tsx src/editor/bbpress-adapter.ts src/editor/editor-services.ts src/block-customization/embed.tsx src/block-customization/paragraph/index.tsx src/block-customization/paragraph/edit.tsxyarn wp-scripts lint-js src/editor/index.tsxcomposer install && composer run-script testpasses with existing PHP 8.4 vendor deprecation noise:23 tests, 84 assertions.yarn buildgit diff --check origin/trunk...HEADCLAUDE.md,homeboy.json, anddocs/CHANGELOG.mdare not included in the Automattic PR diff.Known Follow-ups
AI assistance