[wp-hackers] 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 <
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
>