Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using sane defaults for fields based on REST API registered settings #24

Open
felixarntz opened this issue May 29, 2017 · 2 comments

Comments

@felixarntz
Copy link
Contributor

Initially mentioned by @joehoyle in https://make.wordpress.org/core/2017/05/22/enhanced-settings-api-where-were-at/#comment-32484:

Settings can be registered for the REST API with information on their data type. For those fields where that data is available, we could use it to use sane defaults, for example use field type number if the field is registered as integer/float/number.

Worth noting that we'll still need add_settings_field() because register_setting() deals with the data itself, not the UI. Furthermore in the Settings API we'll often use data stored in serialized arrays (thanks WordPress), which can't be handled easily in the REST API at the moment. But it could indeed help with defaults.

@joehoyle
Copy link

FWIW the REST API handles arrays of "scalar" types right now, but I'd really like to get complex object types supported, and would be happy to work on it along side too. This means it's then possible to effectively "mark up" any complex data type.

If we could combine the rest api schema and settings stuff, that I think would be super duper cool.

@felixarntz
Copy link
Contributor Author

I agree it would be great to improve register_setting() to support more complex types, so that the information could be used by those fields in the Settings API. I'm not convinced that register_setting() can become an all-in-one solution though, since I'd like to keep registering the data separate from registering the UI. It could make the process of using add_settings_field() a lot easier though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants