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