How humayunahmed8/gutenberg-test-block works
1. What this repo is
- This is a WordPress Gutenberg block plugin. The architecture centers on a PHP plugin wrapper that exposes one or more custom blocks to the WordPress editor, with the block behavior implemented in JavaScript.
2. Main runtime boundary
- There are two execution environments:
- PHP / WordPress server side: plugin bootstrap and registration.
- JavaScript / Gutenberg editor side: block editing UI, serialization, and block-specific styles.
- The diagram should show WordPress loading the plugin, which then registers block assets and block types.
3. Plugin bootstrap layer
- plugin.php is the likely main plugin entry point.
- inc/Plugin.php suggests a PHP class that encapsulates plugin initialization, hooks, and registration logic.
- This layer is the boundary between WordPress core and the custom block code.
4. Block feature modules
- The src/blocks/ directory contains three separate block modules:
- block-test
- bootstrap
- card
- Each block is self-contained with:
- block.json for metadata/registration
- index.js as the block entry
- edit.js for editor behavior
- save.js for saved content output
- editor.scss and style.scss for editor/front-end styling
5. Editor data flow
- In Gutenberg, the editor loads the block’s index.js, which wires the block definition to edit.js and save.js.
- edit.js defines the interactive editing experience inside the block editor.
- save.js defines the static markup that gets stored in post content.
6. Content/output model
- These blocks appear to be static blocks rather than server-rendered blocks, because each block has a save.js.
- That means the saved HTML is generated on the client and persisted in WordPress content, then rendered directly on the front end.
7. Shared utilities
- src/utilities/colors-palette.js is a shared helper module, likely used by one or more blocks for consistent color choices.
- This is the main cross-cutting front-end dependency visible in the tree.
8. Global JS entry points
- src/index.js is the top-level source entry for the block package.
- includes/js/plugin.js suggests a compiled or legacy plugin script that may initialize editor behavior or plugin-wide JS outside the block folders.
- The architecture likely has both:
- a global plugin script
- and per-block entrypoints
9. Styling boundaries
- Each block has two style layers:
- editor.scss for appearance in the Gutenberg editor
- style.scss for front-end/shared block styling
- This separation is important for the diagram because editor-only CSS and public-facing CSS are different concerns.
10. Build/tooling layer
- package.json, package-lock.json, ESLint config, and .wp-env.json indicate a modern JS build/test workflow.
- The repo is set up for WordPress local development and likely bundles JS/Sass into distributable assets.
11. Likely deployment shape
- The source under src/ is the human-authored block code.
- The PHP entrypoint and includes/js/plugin.js imply there is a packaged plugin distribution that WordPress loads.
- The diagram should distinguish source modules from loaded plugin assets.
12. What to show in an architecture diagram
- WordPress admin/editor as the host.
- A PHP plugin bootstrap layer that registers blocks/assets.
- Three independent Gutenberg block modules.
- Shared utilities used by blocks.
- Separate editor vs front-end style paths.
- Static block content flow: editor interaction → saved markup → persisted post content → front-end rendering.
Main entry points: src/index.js Source entry · package.json Build setup · Plugin.php Plugin class · block-test/index.js Test block
Components 14
PHP runtime
WordPress plugin bootstrap and server-side registration
- WordPress · WordPress loads the plugin and hosts the editor/runtime
- Plugin entry · Main plugin entry point for WordPress
plugin.php - Plugin class · Encapsulates hooks, setup, and block registration logic
inc/Plugin.php
JS runtime
Gutenberg editor-side block code and shared utilities
- Editor · Gutenberg editor where blocks are inserted and edited
- Plugin JS · Plugin-wide JavaScript outside the per-block folders
includes/js/plugin.js - Source entry · Top-level source entry that wires the block package together
src/index.js - Palette · Shared color helper used by blocks
src/utilities/colors-palette.js - Test block · Static Gutenberg block module with editor and save logic
src/blocks/block-test/index.js - Bootstrap block · Static Gutenberg block module with editor and save logic
src/blocks/bootstrap/index.js - Card block · Static Gutenberg block module with editor and save logic
src/blocks/card/index.js
Content flow
Static block markup persisted in posts and rendered on the front end
- Post content · Saved block HTML stored in WordPress content
- Front end · Rendered site output using the saved block markup
Tooling
Build and local development setup
- Build setup · Node, lint, and local WP environment configuration
package.json - WP env · Local WordPress development environment configuration
.wp-env.json
Connections 18
- WordPress → Plugin entry: loads · WordPress loads the plugin bootstrap file
- Plugin entry → Plugin class: initializes · Bootstrap delegates registration to the plugin class
- Plugin class → Source entry: registers blocks · PHP registers the JS block package and assets
- Plugin class → Plugin JS: enqueues · Registers the plugin-wide JavaScript asset
- Editor → Source entry: loads · Editor loads the block package entry
- Source entry → Test block: includes · Top-level source wires the block modules together
- Source entry → Bootstrap block: includes · Top-level source wires the block modules together
- Source entry → Card block: includes · Top-level source wires the block modules together
- Test block → Palette: uses · Block shares color choices through the palette helper
- Bootstrap block → Palette: uses · Block shares color choices through the palette helper
- Card block → Palette: uses · Block shares color choices through the palette helper
- Test block → Post content: saves HTML · Client-side save output becomes persisted post markup
- Bootstrap block → Post content: saves HTML · Client-side save output becomes persisted post markup
- Card block → Post content: saves HTML · Client-side save output becomes persisted post markup
- Post content → Front end: renders · Persisted block HTML is rendered directly on the front end
- Build setup → Source entry: bundles · Tooling builds the JS source into distributable assets
- Build setup → Plugin JS: bundles · Tooling builds the plugin-wide JS asset
- Build setup → WP env: configures · Local development environment for WordPress