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

Wed Nov 13 01:21:06 UTC 2013

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 <dragonfly at dragonflyeye.net>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 <chip at chipbennett.net>
> 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 <
> > eric.andrew.lewis at gmail.com> 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
> > > wp-hackers at lists.automattic.com
> > > http://lists.automattic.com/mailman/listinfo/wp-hackers
> > >
> > _______________________________________________
> > 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>