Feature Request: Streamlined Gutenberg + ACF Block Integration for WP-Easy

[rickpbaker]

Summary

WP-Easy’s single-file component system (, <script>, <style>) is a huge strength, but there’s a disconnect between how it handles templating and how WordPress expects Gutenberg blocks to behave. Currently, creating custom blocks requires a lot of manual setup in functions.php, separate CSS handling, and ACF registration boilerplate that breaks WP-Easy’s usual simplicity.

Problem

While WP-Easy makes it fast to build reusable components, integrating those components as Gutenberg blocks feels clunky compared to the rest of the framework:

• Gutenberg expects block registration via block.json or register_block_type(), while WP-Easy’s templating system expects inline PHP components.
• CSS and JS defined inside <style> and <script> in components aren’t loaded inside the block editor preview, which breaks the visual parity between the backend and frontend.
• Registering fields for blocks via ACF requires repetitive acf_register_block_type() boilerplate that could easily be automated.
• Managing which blocks are allowed per template or post type also requires extra PHP or a third-party plugin (e.g. Block Manager).

Proposal

Add first-class Gutenberg block support that feels native to WP-Easy and leverages ACF 6.3+ JSON-based block registration.

Unified Component → Block Workflow

• Allow a component (e.g. components/blocks/my-block.php) to automatically register itself as a Gutenberg block.
• Respect existing , <script>, and <style> sections for frontend and editor preview output.
• Introduce a new optional section for inline metadata instead of requiring a separate block.json file, for example:

 <block>
 {
 	"name": "acf/podcast-grid",
 	"title": "Podcast Grid",
 	"category": "widgets",
 	"acf": {
 		"mode": "preview",
 		"renderTemplate": "components/blocks/podcast-grid.php"
 	}
 }
 </block>

Automatic ACF Field Binding

• If a matching ACF field group (e.g. podcast-grid.json in /acf-json/) exists, automatically associate it with the block.
• No need for manual acf_register_block_type() calls or field-to-block mapping.

Editor Style Integration

• When a component block is registered, automatically inject its <style> contents into editor-style.css or enqueue it dynamically in the block editor.
• This would make backend previews visually accurate to the frontend.

Optional Block Whitelisting

• Add a simple WP-Easy config option to restrict allowed blocks per post type (mirroring the “Block Manager” plugin functionality).

Developer Quality-of-Life

• Auto-generate block.json metadata (name, category, supports, etc.) from component metadata.

Impact

This would bring WP-Easy’s workflow in line with how modern WordPress development is evolving, while keeping the lightweight, file-based simplicity that makes WP-Easy great.

Developers could:

• Write a Gutenberg block once, visually edit it in the backend, and see the exact same output on the frontend.
• Skip manual block registration.
• Integrate ACF fields effortlessly.
• Control which blocks appear where, all from WP-Easy’s architecture.