Call for thoughts on a new Settings/Options/Metadata API

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Call for thoughts on a new Settings/Options/Metadata API

Eric Andrew Lewis
Hey folks,

I've been ruminating on a new Settings/Options/Metadata API and discussing
with other developers; I'd like to open up the floor for response, and
perhaps an on-going weekly discussion/architecture-as-a-plugin project. The
Settings API is a bit of a white
whale<http://core.trac.wordpress.org/ticket/18285>,
so I know this will take a while to produce something core-ready, but hey,
I'm not going anywhere.

Generally, the APIs for "settings/metadata/options/etc" in WordPress have
been divided as far as codebase goes, although largely they serve the same
purpose: outputting form elements, and validating/sanitizing/saving the
data. This includes:

   1. "Settings" proper, settings tied to the WordPress install, operable
   via the Settings API <http://codex.wordpress.org/Settings_API>.
   2. Post meta boxes, which really boils down to
add_meta_box()<http://codex.wordpress.org/Function_Reference/add_meta_box>,
   and the many<https://github.com/jaredatch/Custom-Metaboxes-and-Fields-for-WordPress>
    frameworks <https://github.com/scribu/wp-scb-framework>
built<https://github.com/farinspace/wpalchemy>
    on <http://wordpress.org/plugins/advanced-custom-fields/>
it<http://wordpress.org/plugins/pods/>
   .
   3. Widget settings via the Widgets
API<http://codex.wordpress.org/Widgets_API>
   .
   4. Taxonomy meta data, which isn't in core but there's plugins for this
   as well <http://wordpress.org/plugins/taxonomy-metadata/>.
   5. Theme Customization
API<https://codex.wordpress.org/Theme_Customization_API>
   .

I don't think it would be productive to rewrite APIs for all of these
components. However, considering a structure for something to serve as a
base for all of these components at the same time would be prudent in order
to avoid back-compat pitfalls.

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 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.

Eric Andrew Lewis
ericandrewlewis.com
610.715.8560
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Call for thoughts on a new Settings/Options/Metadata API

Chip Bennett
From the perspective of a Theme developer (and reviewer), I think the
biggest piece missing from that... tapestry(?) are standardized output for
form fields, and correlating standardized sanitization methods. The Theme
Customizer API gets around that for standardized form fields, but not for
standardized sanitization.


On Tue, Nov 12, 2013 at 7:37 PM, Eric Andrew Lewis <
[hidden email]> wrote:

> Hey folks,
>
> I've been ruminating on a new Settings/Options/Metadata API and discussing
> with other developers; I'd like to open up the floor for response, and
> perhaps an on-going weekly discussion/architecture-as-a-plugin project. The
> Settings API is a bit of a white
> whale<http://core.trac.wordpress.org/ticket/18285>,
> so I know this will take a while to produce something core-ready, but hey,
> I'm not going anywhere.
>
> Generally, the APIs for "settings/metadata/options/etc" in WordPress have
> been divided as far as codebase goes, although largely they serve the same
> purpose: outputting form elements, and validating/sanitizing/saving the
> data. This includes:
>
>    1. "Settings" proper, settings tied to the WordPress install, operable
>    via the Settings API <http://codex.wordpress.org/Settings_API>.
>    2. Post meta boxes, which really boils down to
> add_meta_box()<http://codex.wordpress.org/Function_Reference/add_meta_box
> >,
>    and the many<
> https://github.com/jaredatch/Custom-Metaboxes-and-Fields-for-WordPress>
>     frameworks <https://github.com/scribu/wp-scb-framework>
> built<https://github.com/farinspace/wpalchemy>
>     on <http://wordpress.org/plugins/advanced-custom-fields/>
> it<http://wordpress.org/plugins/pods/>
>    .
>    3. Widget settings via the Widgets
> API<http://codex.wordpress.org/Widgets_API>
>    .
>    4. Taxonomy meta data, which isn't in core but there's plugins for this
>    as well <http://wordpress.org/plugins/taxonomy-metadata/>.
>    5. Theme Customization
> API<https://codex.wordpress.org/Theme_Customization_API>
>    .
>
> I don't think it would be productive to rewrite APIs for all of these
> components. However, considering a structure for something to serve as a
> base for all of these components at the same time would be prudent in order
> to avoid back-compat pitfalls.
>
> 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 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.
>
> Eric Andrew Lewis
> ericandrewlewis.com
> 610.715.8560
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Call for thoughts on a new Settings/Options/Metadata API

Thomas Belknap
Having recently dived into the Settings API I have to say I find the whole
notion of "Settings Sections" pretty convoluted for no real reason I
understand. Settings seem like enough work that they API didn't really
solve any problems it didn't replace.

Not knowing that the Settings API was already built, I started playing
around with something that I called "Easy Inputs," which was basically my
attempt to recreate CakePHP's Form Helper. I'll get lots of howls on this
list for even mentioning the name, I'm sure. But the brave should probably
have a look at the (IMO) well-developed and abstracted form field builders
it has. With a little extra effort, it would be easy to adapt this concept
to WordPress, including automatically adding nonce fields, and have that
vehicle for form creation be use-agnostic: we don't much care if you use it
for a contact page, a template options page or settings for a plugin. Let
the developer define in his call what its used for.

Anyway, my two cents.


On Tue, Nov 12, 2013 at 7:43 PM, Chip Bennett <[hidden email]> wrote:

> From the perspective of a Theme developer (and reviewer), I think the
> biggest piece missing from that... tapestry(?) are standardized output for
> form fields, and correlating standardized sanitization methods. The Theme
> Customizer API gets around that for standardized form fields, but not for
> standardized sanitization.
>
>
> On Tue, Nov 12, 2013 at 7:37 PM, Eric Andrew Lewis <
> [hidden email]> wrote:
>
> > Hey folks,
> >
> > I've been ruminating on a new Settings/Options/Metadata API and
> discussing
> > with other developers; I'd like to open up the floor for response, and
> > perhaps an on-going weekly discussion/architecture-as-a-plugin project.
> The
> > Settings API is a bit of a white
> > whale<http://core.trac.wordpress.org/ticket/18285>,
> > so I know this will take a while to produce something core-ready, but
> hey,
> > I'm not going anywhere.
> >
> > Generally, the APIs for "settings/metadata/options/etc" in WordPress have
> > been divided as far as codebase goes, although largely they serve the
> same
> > purpose: outputting form elements, and validating/sanitizing/saving the
> > data. This includes:
> >
> >    1. "Settings" proper, settings tied to the WordPress install, operable
> >    via the Settings API <http://codex.wordpress.org/Settings_API>.
> >    2. Post meta boxes, which really boils down to
> > add_meta_box()<
> http://codex.wordpress.org/Function_Reference/add_meta_box
> > >,
> >    and the many<
> > https://github.com/jaredatch/Custom-Metaboxes-and-Fields-for-WordPress>
> >     frameworks <https://github.com/scribu/wp-scb-framework>
> > built<https://github.com/farinspace/wpalchemy>
> >     on <http://wordpress.org/plugins/advanced-custom-fields/>
> > it<http://wordpress.org/plugins/pods/>
> >    .
> >    3. Widget settings via the Widgets
> > API<http://codex.wordpress.org/Widgets_API>
> >    .
> >    4. Taxonomy meta data, which isn't in core but there's plugins for
> this
> >    as well <http://wordpress.org/plugins/taxonomy-metadata/>.
> >    5. Theme Customization
> > API<https://codex.wordpress.org/Theme_Customization_API>
> >    .
> >
> > I don't think it would be productive to rewrite APIs for all of these
> > components. However, considering a structure for something to serve as a
> > base for all of these components at the same time would be prudent in
> order
> > to avoid back-compat pitfalls.
> >
> > 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 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.
> >
> > Eric Andrew Lewis
> > ericandrewlewis.com
> > 610.715.8560
> > _______________________________________________
> > wp-hackers mailing list
> > [hidden email]
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> 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
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Call for thoughts on a new Settings/Options/Metadata API

John Blackbourn
As Eric mentioned:

"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."

To me, this is fundamental. WordPress is no longer just an admin UI that
you only visit in a web browser. WordPress can be accessed via the XML-RPC
API, via the upcoming JSON API, via the command line with WP-CLI or
WordShell, or via any number of third party services using various custom
APIs.

Giving everything in WordPress that is settings-like (post meta, user meta,
settings, theme options, etc) better structure would enable, quite
literally, a next generation of apps to be built on WordPress. If we were
building WordPress from scratch today, this is how all this various
metadata would be structured.

A standard set of form helpers, therefore, becomes just one part of what we
want. Form helpers would be used in the admin area for settings pages, in
post meta boxes, in theme options and the customiser, etc. However, the
underlying structure of each setting or piece of metadata ("this metadata
is an integer", "this option is a colour picker") would mean that other
APIs that interface with WordPress know what data to expect, what data to
return, and how to present each field. The mobile apps would, for example,
know which native input controls to use for each field.

This might sound a bit idealistic (maybe it is) but I think it'd be a
missed opportunity if we ended up with another settings API that didn't
give us this sort of structure.

John


On 13 November 2013 00:52, Thomas Belknap <[hidden email]>wrote:

> Having recently dived into the Settings API I have to say I find the whole
> notion of "Settings Sections" pretty convoluted for no real reason I
> understand. Settings seem like enough work that they API didn't really
> solve any problems it didn't replace.
>
> Not knowing that the Settings API was already built, I started playing
> around with something that I called "Easy Inputs," which was basically my
> attempt to recreate CakePHP's Form Helper. I'll get lots of howls on this
> list for even mentioning the name, I'm sure. But the brave should probably
> have a look at the (IMO) well-developed and abstracted form field builders
> it has. With a little extra effort, it would be easy to adapt this concept
> to WordPress, including automatically adding nonce fields, and have that
> vehicle for form creation be use-agnostic: we don't much care if you use it
> for a contact page, a template options page or settings for a plugin. Let
> the developer define in his call what its used for.
>
> Anyway, my two cents.
>
>
> On Tue, Nov 12, 2013 at 7:43 PM, Chip Bennett <[hidden email]>
> wrote:
>
> > From the perspective of a Theme developer (and reviewer), I think the
> > biggest piece missing from that... tapestry(?) are standardized output
> for
> > form fields, and correlating standardized sanitization methods. The Theme
> > Customizer API gets around that for standardized form fields, but not for
> > standardized sanitization.
> >
> >
> > On Tue, Nov 12, 2013 at 7:37 PM, Eric Andrew Lewis <
> > [hidden email]> wrote:
> >
> > > Hey folks,
> > >
> > > I've been ruminating on a new Settings/Options/Metadata API and
> > discussing
> > > with other developers; I'd like to open up the floor for response, and
> > > perhaps an on-going weekly discussion/architecture-as-a-plugin project.
> > The
> > > Settings API is a bit of a white
> > > whale<http://core.trac.wordpress.org/ticket/18285>,
> > > so I know this will take a while to produce something core-ready, but
> > hey,
> > > I'm not going anywhere.
> > >
> > > Generally, the APIs for "settings/metadata/options/etc" in WordPress
> have
> > > been divided as far as codebase goes, although largely they serve the
> > same
> > > purpose: outputting form elements, and validating/sanitizing/saving the
> > > data. This includes:
> > >
> > >    1. "Settings" proper, settings tied to the WordPress install,
> operable
> > >    via the Settings API <http://codex.wordpress.org/Settings_API>.
> > >    2. Post meta boxes, which really boils down to
> > > add_meta_box()<
> > http://codex.wordpress.org/Function_Reference/add_meta_box
> > > >,
> > >    and the many<
> > > https://github.com/jaredatch/Custom-Metaboxes-and-Fields-for-WordPress
> >
> > >     frameworks <https://github.com/scribu/wp-scb-framework>
> > > built<https://github.com/farinspace/wpalchemy>
> > >     on <http://wordpress.org/plugins/advanced-custom-fields/>
> > > it<http://wordpress.org/plugins/pods/>
> > >    .
> > >    3. Widget settings via the Widgets
> > > API<http://codex.wordpress.org/Widgets_API>
> > >    .
> > >    4. Taxonomy meta data, which isn't in core but there's plugins for
> > this
> > >    as well <http://wordpress.org/plugins/taxonomy-metadata/>.
> > >    5. Theme Customization
> > > API<https://codex.wordpress.org/Theme_Customization_API>
> > >    .
> > >
> > > I don't think it would be productive to rewrite APIs for all of these
> > > components. However, considering a structure for something to serve as
> a
> > > base for all of these components at the same time would be prudent in
> > order
> > > to avoid back-compat pitfalls.
> > >
> > > 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 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.
> > >
> > > Eric Andrew Lewis
> > > ericandrewlewis.com
> > > 610.715.8560
> > > _______________________________________________
> > > wp-hackers mailing list
> > > [hidden email]
> > > http://lists.automattic.com/mailman/listinfo/wp-hackers
> > >
> > _______________________________________________
> > wp-hackers mailing list
> > [hidden email]
> > 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
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Call for thoughts on a new Settings/Options/Metadata API

Tom Barrett-2
In reply to this post by Thomas Belknap
Great name, excellent point.

I find the theme options sections settings callback jiggery really
unintuitive. It looks like something very clever that is over engineered.
Makes my head spin. Please, please consider something else.

Is it just me?

// Sent by Nexus
On 13 Nov 2013 00:52, "Thomas Belknap" <[hidden email]> wrote:

> Having recently dived into the Settings API I have to say I find the whole
> notion of "Settings Sections" pretty convoluted for no real reason I
> understand. Settings seem like enough work that they API didn't really
> solve any problems it didn't replace.
>
> Not knowing that the Settings API was already built, I started playing
> around with something that I called "Easy Inputs," which was basically my
> attempt to recreate CakePHP's Form Helper. I'll get lots of howls on this
> list for even mentioning the name, I'm sure. But the brave should probably
> have a look at the (IMO) well-developed and abstracted form field builders
> it has. With a little extra effort, it would be easy to adapt this concept
> to WordPress, including automatically adding nonce fields, and have that
> vehicle for form creation be use-agnostic: we don't much care if you use it
> for a contact page, a template options page or settings for a plugin. Let
> the developer define in his call what its used for.
>
> Anyway, my two cents.
>
>
> On Tue, Nov 12, 2013 at 7:43 PM, Chip Bennett <[hidden email]>
> wrote:
>
> > From the perspective of a Theme developer (and reviewer), I think the
> > biggest piece missing from that... tapestry(?) are standardized output
> for
> > form fields, and correlating standardized sanitization methods. The Theme
> > Customizer API gets around that for standardized form fields, but not for
> > standardized sanitization.
> >
> >
> > On Tue, Nov 12, 2013 at 7:37 PM, Eric Andrew Lewis <
> > [hidden email]> wrote:
> >
> > > Hey folks,
> > >
> > > I've been ruminating on a new Settings/Options/Metadata API and
> > discussing
> > > with other developers; I'd like to open up the floor for response, and
> > > perhaps an on-going weekly discussion/architecture-as-a-plugin project.
> > The
> > > Settings API is a bit of a white
> > > whale<http://core.trac.wordpress.org/ticket/18285>,
> > > so I know this will take a while to produce something core-ready, but
> > hey,
> > > I'm not going anywhere.
> > >
> > > Generally, the APIs for "settings/metadata/options/etc" in WordPress
> have
> > > been divided as far as codebase goes, although largely they serve the
> > same
> > > purpose: outputting form elements, and validating/sanitizing/saving the
> > > data. This includes:
> > >
> > >    1. "Settings" proper, settings tied to the WordPress install,
> operable
> > >    via the Settings API <http://codex.wordpress.org/Settings_API>.
> > >    2. Post meta boxes, which really boils down to
> > > add_meta_box()<
> > http://codex.wordpress.org/Function_Reference/add_meta_box
> > > >,
> > >    and the many<
> > > https://github.com/jaredatch/Custom-Metaboxes-and-Fields-for-WordPress
> >
> > >     frameworks <https://github.com/scribu/wp-scb-framework>
> > > built<https://github.com/farinspace/wpalchemy>
> > >     on <http://wordpress.org/plugins/advanced-custom-fields/>
> > > it<http://wordpress.org/plugins/pods/>
> > >    .
> > >    3. Widget settings via the Widgets
> > > API<http://codex.wordpress.org/Widgets_API>
> > >    .
> > >    4. Taxonomy meta data, which isn't in core but there's plugins for
> > this
> > >    as well <http://wordpress.org/plugins/taxonomy-metadata/>.
> > >    5. Theme Customization
> > > API<https://codex.wordpress.org/Theme_Customization_API>
> > >    .
> > >
> > > I don't think it would be productive to rewrite APIs for all of these
> > > components. However, considering a structure for something to serve as
> a
> > > base for all of these components at the same time would be prudent in
> > order
> > > to avoid back-compat pitfalls.
> > >
> > > 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 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.
> > >
> > > Eric Andrew Lewis
> > > ericandrewlewis.com
> > > 610.715.8560
> > > _______________________________________________
> > > wp-hackers mailing list
> > > [hidden email]
> > > http://lists.automattic.com/mailman/listinfo/wp-hackers
> > >
> > _______________________________________________
> > wp-hackers mailing list
> > [hidden email]
> > 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
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Call for thoughts on a new Settings/Options/Metadata API

Ryan McCue-3
In reply to this post by Eric Andrew Lewis
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
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
> [hidden email]
> 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
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Call for thoughts on a new Settings/Options/Metadata API

Eric Andrew Lewis
Thanks for the response everyone, and of course keep it coming if you'd
like to add your two cents. I think these points will be a good launchpad
for roadmapping in a dev chat.

Something I'd also like to add to the must-have list is repeating form
fields. For example, a custom post type for Company might include a
repeating field for phone number, to which you could add multiple different
contact numbers to. This is already built-in to some of the post meta
libraries, and brings JS MV* framework support into the discussion.

Eric Andrew Lewis
ericandrewlewis.com
610.715.8560


On Wed, Nov 13, 2013 at 8:38 AM, Thomas Belknap
<[hidden email]>wrote:

> 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 <[hidden email]> 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
> > [hidden email]
> > 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
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Call for thoughts on a new Settings/Options/Metadata API

Funkatron
In reply to this post by Eric Andrew Lewis
I'm partial to the the OOP approach that the theme customizer uses.  It
creates the fields and automagically binds it to a particular option.
 Especially love the image and color fields it uses.  Would love something
like that for post meta and settings, with the option to create your own
fields if the ones provided in the core aren't adequate.
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Call for thoughts on a new Settings/Options/Metadata API

Nashwan Doaqan
1+, Forms Builder API will make our life easier,  This plugin may help you:
https://github.com/nash-ye/Momtaz-Nmwdhj


On 13 November 2013 19:33, Funkatron <[hidden email]> wrote:

> I'm partial to the the OOP approach that the theme customizer uses.  It
> creates the fields and automagically binds it to a particular option.
>  Especially love the image and color fields it uses.  Would love something
> like that for post meta and settings, with the option to create your own
> fields if the ones provided in the core aren't adequate.
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Call for thoughts on a new Settings/Options/Metadata API

Eric Andrew Lewis
FYI, a development team is coming together for this feature.

We’ll be meeting in (freenode) IRC chatroom #wordpress-core-plugins Tuesday, November 26th at 2200 UTC (5 PM EST) to start.

Eric

On Nov 14, 2013, at 6:11 AM, Nashwan Doaqan <[hidden email]> wrote:

> 1+, Forms Builder API will make our life easier,  This plugin may help you:
> https://github.com/nash-ye/Momtaz-Nmwdhj
>
>
> On 13 November 2013 19:33, Funkatron <[hidden email]> wrote:
>
>> I'm partial to the the OOP approach that the theme customizer uses.  It
>> creates the fields and automagically binds it to a particular option.
>> Especially love the image and color fields it uses.  Would love something
>> like that for post meta and settings, with the option to create your own
>> fields if the ones provided in the core aren't adequate.
>> _______________________________________________
>> wp-hackers mailing list
>> [hidden email]
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
> _______________________________________________
> wp-hackers mailing list
> [hidden email]
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers