[wp-hackers] Option Pages

[Spencer]

Some very good points. I originally designed the options pages using
meta boxes because some of the themes had a large number of things
that needed to be changed, and I didn't like the feel of a gigantic
page of options.  Having them in the meta boxes allowed for some
sections to be collapsed/hidden. However, I've since recoded portions
of those themes, and they no longer require the amount of options they
once did.

Since the pages are really just straight forward option pages to set a
few things for the theme (how many posts in certain areas, categories
for certain loops, etc) they should only be changed once or twice once
they are initially set up.

I'm also more keen to using the Settings API as it will most likely
stay compatible with future versions of WordPress. The way I have it
setup now, I am creating *some* of the page structure myself, which
would eventually become out of date.

It just doesn't seem as fancy, but I guess those kind of pages aren't
meant to look flashy. Sometimes stuff just needs to be straight
forward.

On Sat, Jun 5, 2010 at 3:37 PM, Jeremy Clarke <jer at simianuprising.com> wrote:
> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>