[wp-hackers] Option Pages

Jeremy Clarke jer at simianuprising.com
Sat Jun 5 19:37:06 UTC 2010

This is a really interesting problem. The Settings API currently has a type
of page in mind for what you can create with it, essentially the type of
settings page that core WP uses. These pages show all relevant options in
sections inside a table with one submit button at the bottom which submits
everything. When using the API you can add extra stuff (html etc) to the
top/bottom of the page and the top of each section of the page. You also
control the HTML output for each individual setting's section of the form.

In theory the Settings API could be altered to use metaboxes for each
section instead of a heading followed by a table. This probably wouldn't
mess things up since all the output the current system lets you define could
be slotted into a page with metaboxes (page top would be above the
metaboxes, section top HTML would be at the top inside of the metabox).

Personally I think the existing solution makes sense for pretty much all
situations where you're dealing with actual 'settings', as in configuration
settings/options. While metaboxes are pretty and fun to use it seems like
most of the time they would be overkill for a settings page. If you only
expect users to visit the page once in awhile then screen-configurability
isn't really needed, and users are probably better off seeing all the
options when they come back in case their new experiences make them more
interested in settings that they previously thought were irrelevant.

It's possible that what you are creating is more of a management page of
some kind, but which uses the options table to store data. In that case
metaboxes might make more sense, especially if people are
creating/editing/deleting data objects, as opposed to changing the settings
that govern the behavior of those objects or their manager. If you are
creating a management page the Settings API shouldn't necessarily be changed
to suit your needs.

For example a contact form plugin might have a settings page that governs
all forms, separate from the form generator which actually creates new
forms. Even if the forms are stored in wp_options there are good reasons why
the settings page should be created using the Settings API while the manager
should be done with metaboxes etc. That said its worth considering adding
the contact-forms as a new post-type instead, as that might simplify the
creation of management screens with metaboxes etc.

Jeremy Clarke
Code and Design | globalvoicesonline.org

More information about the wp-hackers mailing list