[wp-hackers] WP Plugin Option API

[Robert Deaton]

I finished up a lot of work on the plugin, and after many, many hours
of work, it now supports text boxes and checkboxes, will automatically
update the database with the new options, and is full valid XHTML 1.0
Transitional. Not only that, but I added in support for clustering,
which is what I called the grouping used in the options pages that
come with WordPress. (For example, "Date and Time" under
options-general.php).

I don't have any sort of documentation written up yet, but if anyone
would like to see what has been accomplished send me a mail off-list
and I'll send you a copy of the actual plugin and the test  plugin
that utilizes the features provided by my plugin.


On Thu, 31 Mar 2005 09:43:05 -0500, Robert Deaton <false.hopes at gmail.com> wrote:
> Well, what was going through my head was that the options for a plugin
> is the most difficult, and a set of wrappers to make forms exactly
> like the default options page wouldn't be too awfully difficult, I'm
> just spending a lot of time thinking about if there should be like
> some sort error checking to make sure the user closes the form and
> such, but at the same time, I don't think it should be necessary as
> long as developers remember to call the function to close the form and
> such. I think I'll leave out any form of error checking initially and
> just design the forms around the functions they call. I've already got
> some coding done, so if you would all like I'll post a pre-alpha to
> the list within the next couple days (spring break, so plenty of time
> free).
> 
> 
> On Wed, 30 Mar 2005 21:39:33 +0100, Mike Little <journalized at gmail.com> wrote:
> > To be totally non-constructive, I have to say I'm quite amused by this
> > conversation.
> >
> > Automatic forms and forms processing based on functional groups of
> > options was what I originally coded for the options, when I took them
> > out of the configuration file. That code got ripped out some time last
> > year. Mostly, as far as I can gather because the groupings weren't
> > intuitive and the forms were ugly. Though
> > http://example.com/blog/wp-admin/options.php?group_option_id=all still
> > works.
> >
> > Sorry, that didn't help at all...
> >
> > I think the general idea of having the core code handle the options
> > for a plugin is a good idea (no surprise there).
> > A plugin during installation could register a group of options, which
> > would be added to the database. There would have to be some kind of
> > naming conventions, such that no two plugins ended up with the same
> > group name (or option name for that matter). There would also have to
> > be some way to distinguish plugins installed but not currently active
> > so their options weren't presented to the user.
> >
> > An idea (if this code is going in the core -- and I think it should)
> > is to have an optional file name associated with the group of options
> > so that the code could call the plugins own options page if enabled or
> > else handle it as described.
> >
> > Anyway, there are some good ideas here, keep fleshing them out.
> >
> > Mike
> > --
> > Mike Little
> > http://zed1.com/journalized/
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> 
> --
> --Robert Deaton
> http://anothersadsong.com
> 


-- 
--Robert Deaton
http://anothersadsong.com