[wp-trac] [WordPress Trac] #18285: New Settings API and workflow

Mon Jul 30 22:59:40 UTC 2012

#18285: New Settings API and workflow
-----------------------------+-----------------------------
 Reporter:  nacin            |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Future Release
Component:  Plugins          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  3.4-early        |
-----------------------------+-----------------------------

Comment (by CaptainN):

 HTML is the best place to define forms, and with HTML5, it's a pretty good
 place to set basic validation as well.

 I've been playing with this idea, where we'd spec out a form in HTML tags,
 and then create the corresponding PHP form elements from parsing that, and
 even wire up the _POST handler to do the basic validation (ranges, email,
 color picker, etc.) A system like that could validate any HTML5 form field
 type marked as required automatically when the form comes back to the
 server, eliminating a huge pain point for forms handling in general (and a
 pain point WordPress's Setting's API passes on to plugin and theme
 developers). Using HTML5 form spec provides a nice predefined scope, so we
 don't have to go crazy. WordPress could seemingly also be wired up
 automatically from that.

 This would involve the overhead of parsing HTML on the server, but we
 could probably minimize that by only parsing single fields (except with
 select boxes).

 Here's a quick example, of what this could look like as an implemented
 form:

 {{{
 <?php
 // This would actually call `myForm` function and capture the output, and
 parse the HTML
 // before passing the HTML right into the output. Each tag call is a
 chance to register
 // and validate the form data and type, and set necessary data, like
 filtering the
 // value attribute to prefill submitted data, and overwrite the default
 value, etc..

 // could be extended with WP API stuff
 $form1 = new Form( 'myForm', 'my_wp_setting' );

 if ( $form1->isSubmitted )
 {
         if ( $form1->isValid ) {
                 // Store the validated form data, or maybe do nothing!
                 // WordPress could actually do the saving automatically.
         }
         else {
                 // might not have to do anything!!
                 // wordpress could also wire up the settings errors
         }
 }
 ?>
 <html>
 <head>
 <title>Example Form</title>
 </head>

 <body>
 <?php

 function myform() { ?>
 <?php tag( '<form action="./" method="post" name="form1">' ); ?>

 <div>
 <?php tag(' <input type="email" name="user_email" required
 placeholder="Enter your email address"> ') ?>
 </div>

 <div>
 <?php tag(' <input type="email" name="some_field_name" placeholder="Enter
 your email address"> ') ?>
 </div>

 <?php tag(' </form> ') ?>

 <?php } // myform

 $form1->output();

 ?>
 </body>
 </html>
 }}}

 With this there is no limitation on how you structure your own HTML - it's
 all just plain old HTML (well, mostly). There may be other ways to
 encapsulate the HTML - for example - parsing an entire form all at once
 instead, or by using a similar function trick for each tag, but this
 seemed like a nice light way to go.

 What's cool about that, is you can define the form as HTML, in place in
 the document. PHP functions are hoisted, so you can register the form in
 the head, and do the input validation there. This ends up being pretty DRY
 - you define your form, your input types, and your validation all inside
 the form (without limiting your layout options) just the one time, and
 then all the wiring can be done automatically. WordPress setting
 registration, section and field registration, error handling, can also all
 be wired up automatically from the form spec.

 (Separate note: It would be nice to add to the setting API support for
 arrays of data - maybe a `register_setting_group` method or something.
 Registering a separate setting for each field seems like too much in many
 cases, where serialized array data would be enough.)

 Maybe this could be useful enough even outside of WordPress to go ahead
 and make it work - maybe wrap Scribu's lib. :-)

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18285#comment:71>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software