You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For Gutenberg to truly succeed in the manner it needs to, I believe there needs to be a dedicated data based mode added alongside the existing code and visual modes.
Up to this point, the focus of Gutenberg has been to improve the experience of writing a post within WordPress. This will cover the primary usage of a lot of WordPress users, who use WordPress to mainly write posts and publish pages. However, when proposing an overhaul to what is arguably the most important screen within WordPress, the majority of use cases have to be considered and covered. The tools provided today do not accomplish that.
Plenty of WordPress plugins and custom themes utilize custom post types that are not focused on writing a story, but on entering data that can then be rendered appropriate by the theme or utilized via various internal APIs or the REST API to connect with other objects across the site. Look at the edit Product screen for WooCommerce. Sure, there's the main editor at the top for writing the product description, but most of the important data related to the product (pricing, taxes, inventory, shipping, etc) is entered in through a metabox.
With a dedicated data entry mode, Gutenberg can be used by more data focused post types. Rather than presenting a BlockList where the user can only insert blocks that are saved to the post object's content property, a new MetaboxList component could be rendered allowing developers to insert their own Metabox components that allow the user to enter in data related to that post type. (They do not need to be referred to as Metaboxes.) This provides a better toolset for developers to create more complex experiences than they can with today's editor screen and jQuery combo along with being able to transition to the new primary user interface of WordPress.
The text was updated successfully, but these errors were encountered:
Thanks for the suggestion! I've filed this away in the Ideas project for future consideration. At this point in the Gutenberg development cycle, we're focusing on finishing the remaining features and then switching to bug fixing / polish.
For Gutenberg to truly succeed in the manner it needs to, I believe there needs to be a dedicated data based mode added alongside the existing code and visual modes.
Up to this point, the focus of Gutenberg has been to improve the experience of writing a post within WordPress. This will cover the primary usage of a lot of WordPress users, who use WordPress to mainly write posts and publish pages. However, when proposing an overhaul to what is arguably the most important screen within WordPress, the majority of use cases have to be considered and covered. The tools provided today do not accomplish that.
Plenty of WordPress plugins and custom themes utilize custom post types that are not focused on writing a story, but on entering data that can then be rendered appropriate by the theme or utilized via various internal APIs or the REST API to connect with other objects across the site. Look at the edit Product screen for WooCommerce. Sure, there's the main editor at the top for writing the product description, but most of the important data related to the product (pricing, taxes, inventory, shipping, etc) is entered in through a metabox.
With a dedicated data entry mode, Gutenberg can be used by more data focused post types. Rather than presenting a
BlockList
where the user can only insert blocks that are saved to the post object's content property, a newMetaboxList
component could be rendered allowing developers to insert their ownMetabox
components that allow the user to enter in data related to that post type. (They do not need to be referred to as Metaboxes.) This provides a better toolset for developers to create more complex experiences than they can with today's editor screen and jQuery combo along with being able to transition to the new primary user interface of WordPress.The text was updated successfully, but these errors were encountered: