felixarntz
commented
2 weeks ago cc @bacoords as I first had that idea during your live stream earlier today (which was a great overview btw!). When you were explaining the "Custom Fields" functionality in that not every piece of data makes sense to appear in the template and later referenced the different field types, I thought that it would be very useful to require specific data types even for certain information that should appear in the template.
bacoords
After giving this a spin, one of the first things that I would find useful is to allow for block bindings used for a content model to support a certain data type (i.e. other than text/string).
The "Custom Fields" UI of Create Content Model already allows using different field types, and while that's partially a user interface consideration, it also means requiring a certain data type for the data using such field types - for instance, you typically can only enter numbers into a
input[type="number"]field.Popular example use-case: Showing the price of a product, which should be a numeric value. This is information that wouldn't make sense to include via the "Custom Fields" functionality (i.e. in the block editor sidebar), because it needs to be displayed in the actual template. Yet at the same time, you wouldn't want the content editor to put something in there that's not a valid price.
I understand that WordPress Core block types do not intuitively allow using such field types (e.g. I don't think we can just replace the input/textarea used for a
core/paragraphblock with ainput[type="number"]field. But what we could potentially do under the hood is to add validation and sanitization to ensure the user can only provide data in the expected format.The
register_post_meta()function already allows sanitization, so we could tap into that. Even better would of course be to handle it also on the client-side so that the user would immediately get a warning/error notice feedback if they entered something that was not allowed.