[wp-hackers] Call for thoughts on a new Settings/Options/Metadata API

[Thomas Belknap]

What if the form-building API remained more or less agnostic, and a
hook-type vehicle was used to listen for appropriate data?

(in the form):
echo $Form->input('my_setting', array('type' => 'text', 'class' =>
'my_plugin_setting', 'maxlength' => 200));

(on save):
function save_my_setting() {
    if( !empty($_POST['settings_api']['my_setting']) ) :
        $Form->check_nonce($_POST['settings_api']['my_setting_nonce']);
        add_option('my_setting', $_POST['settings_api']['my_setting']);
    endif;
}

The idea here is that we only require the developer to provide the language
that correctly inserts a form element into the form. The API handles
creating a nonce and correctly setting the name field to include the array
that sets all settings_api fields apart from any other data (just for
convenience sake).

If you want to create a "section," feel free to do so in HTML. If you want
to nest form elements together or save them into subelements of the array
for your own purposes, have at it. The API only cares that a limited but
effective set of layout and security needs be met in order to properly save
your data.



On Wed, Nov 13, 2013 at 8:20 AM, Ryan McCue <lists at rotorised.com> wrote:

> Eric Andrew Lewis wrote:
> > An issue in previous iterations of these APIs has been the object
> structure
> > of a setting/metadata/option being intermingled with the the UI
> components
> > in some cases. I don't want to jump the gun on implementation, but here
> is
> > a gist of  meanderings imagining a new
> > API<https://gist.github.com/ericandrewlewis/7441441>
>
> I think that's a good start on structure. I do think we need to avoid
> being too verbose though; having used some other systems similar to
> this, you can end up very abstract quickly.
>
> Rather than having the 'for' key, and letting settings be attached to
> everything, I think we could use subclassing. It's a little weird to
> have something attached to both a post *and* as an option without
> needing different handling. I'm thinking:
>
>         abstract class WP_Setting {}
>         class WP_Setting_Option extends WP_Setting {}
>         class WP_Setting_Post_Meta extends WP_Setting {}
>
> But that could end up being confusing.
>
> > I would love to hear constructive feedback: what the issues you face as a
> > developer in the current environment, what you might want from a new API,
> > etc.
>
> I think something we should look into handling is making nested options
> a first-class feature. That is, storing an array/etc into a single
> option, rather than spreading it out. It's been recommended for a long
> time, but you have to write all of the handling yourself.
>
> On the other hand, if you could do something like...
>
>         $setting = new WP_Setting( array(
>                 'key' => 'master_option',
>                 'type' => 'array',
>                 'children' => array(
>                         'option1' => new WP_Setting( ... ),
>                         'option2 => new WP_Setting( ... ),
>                 ),
>         ) );
>
> ...that'd be pretty cool. This could also be implemented via the
> settings group API you proposed.
>
> --
> Ryan McCue
> <http://ryanmccue.info/>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



-- 
Tom Belknap
Owner/Editor, DragonFlyEye.Net
Join me:

   - *Inbox:* http://dragonflyeye.net/subscribe
   - *Web*: http://dragonflyeye.net/
   - *Facebook*: https://www.facebook.com/DragonFlyEye.Net
   - *Twitter*: https://twitter.com/dragonflyeye
   - *Google*: https://plus.google.com/u/1/103251482414903117843/posts