Matías

No offense taken, I appreciate the feedback.

The ability to pre-define and perhaps lock in a block or set of blocks for a given post type or page template would go a long way to easing my concerns with the editor. Is that part of the plan?

Definitely! Pre-set blocks that guide a user through setting up content is something I’m looking forward to see.

Some of this information is not exposed visually on the product page. Some of it is available in modal windows.

You would still be able to do all this. You could render a purely configurable box below your block, or open modals to configure. The “edit” interface of a block is completely customizable. See how the image block can open the media library, for instance, but also offers direct drag and drop. Settings that don’t have a direct visual representation can still be rendered there. For blocks like “latest posts” we chose the inspector, but if you have things that are _crucial_ yet not visual, you can render them directly within the block.

If a post type is purely about data and has no tangible visual representation then it would likely remain as it is now. A post type should be able to say “we don’t need the visual block editor” and they’d just get whatever else they register to manage information. The chrome of the editor (header and sidebar) may remain to make the experience consistent, but the main content could be filled with the meta-boxes and custom fields instead.

My only point is that many of the current meta-boxes and fields implementation do have a visual impact on the front-end, and Gutenberg should allow developers to connect those two things better without sacrificing the separation of data.

Name *

Email *

Website:

Topic Title (Maximum Length: 80):

Forum:
— No forum —AI and WordPress Articles Blocks Showcase Discussions Events Introductions Jobs and Working in WordPress Podcast Episodes Site and Block Editor