Add Default Callback Functions for add_settings_field()

By default, when creating options in plugins and themes, every developer is required to create custom callback functions for rendering their option's HTML. The HTML for most options is nothing more than a standard INPUT field, a SELECT field, TEXTAREA field, etc, so there's really no reason there shouldn't be default callback options in place.

For example, if I have a plugin that registers one text field option in the General settings page, it really doesn't make sense that I should be forced to create a callback function, especially not when probably 99% of all text fields are outputted in exactly the same way:

This would really help make it easier to create basic option pages and add more consistency among plugin and theme authors with their option panels. Make it so. +1

Some issues mordauk and I had when putting this together today was getting "default" option values to work with checkbox and checkbox groups, so we left it off those option types.

Also, if one does choose to use these default option type callbacks the way we've got them here, you must have each option setup as a standard, single option field. In other words, you couldn't have your settings page work by saving all your settings to a single option field as a multi-dimensional array. -- Not sure if this is too serious of an issue, but maybe someone could have a look at that part of things and see if it's possible to allow that somehow.

We actually use this same format for Pods 2.0 field handling, I recommend it. Maybe instead of choices, 'data', but that's just a suggestion. I'd also like to see a custom callback available for the type, or as long as the type can be anything and runs through an action through an 'else', then that's great.

In fact, I suggest that these be moved out of wp-admin and into wp-includes, so that front-end plugin and theme developers could use the same methods for building form markup. There's nothing settings-specific about them as they're currently written.

jbobich and I thought about that for a while and ultimately thought it made more sense to overload the callback instead of having a type option in the $args parameter. The default field types we've proposed here are still callbacks in terms of what they do, so I don't think they should be separated. I have a feeling it would get confusing for users if they saw that they could define a callback AND a type but only one could actually be used. There would be some users who would create a text field callback and then also set the type to "text" not realizing that only one or the other was necessary.

In fact, I suggest that these be moved out of wp-admin and into wp-includes, so that front-end plugin and theme developers could use the same methods for building form markup. There's nothing settings-specific about them as they're currently written.

In fact, I suggest that these be moved out of wp-admin and into wp-includes, so that front-end plugin and theme developers could use the same methods for building form markup. There's nothing settings-specific about them as they're currently written.

Oh this is gold.

Completely agree. Perhaps instead of do_settings_text(), the functions should just be text_field(), select_field(), etc. This would match the pattern already used for the submit_button() function.

+1000 to this. I want to see this happen very much. I built the Options API for ​http://wpstartbox.com because I wanted to have something handy for all my callbacks (of course, I made it do a bunch of other things too).

I prefer overloading it instead because that allows the user to just pass "text" or "textarea" as the callback, which makes it simpler. If the callback isn't overloaded and just the function name is passed, then I think the default callback functions should be named something more intuitive, perhaps just "text_field", "textarea_field", etc.

This appears to be one implementation (a child) of #18285, which I know a couple devs discussing this patch are aware of, but it hasn't been mentioned in this ticket, so I'm pointing it out now. Take a look there for other ideas on how a new settings API could be
implemented.