[wp-hackers] Best practices for plugin with complicated settings?

[Carl Roett]

Peter, JJJ, Andrew ...thanks for your comments.

1) Number of options.

It's the classic software development scenario ...each user only needs a few
options, but all of them need *different* options. Somebody using the plugin
for an application like deviantART <http://www.deviantart.com/> will want
things configured very differently from a user trying to emulate Facebook,
or a user trying to emulate LinkedIn. All of these sites have the same group
of "core" media functions. It is the application of rules, which in our case
are set by config options, that makes a site what it is.

Stacked on top of that is the fact BuddyPress Media is a large, complicated
plugin that does a lot of different things, and most features have several
configuration options.

I should probably mention that 207 options is with *every* feature enabled.
As with BuddyPress, not all installations will use all features; but also as
with BuddyPress, a large portion of the features are interdependent, so we
can't split it into a bunch of different plugins,

So yes, I'd say 90% of the config options currently there are necessary.

2) Config Files and Filters

The next time we give our code a really careful review, I think we might be
able to switch a few more things over to using filters, but most options
that (at least from what we know) can be set that way already are. The
majority of our config options are things like:

Which users can add tags to media items: "item owner" | "friends" |
"everyone"
Allow comments on media items: "yes" | "no"

So they're not really the kind of thing you would set in a template or when
calling a function.

...but

They're exactly the sort of values you would store in a config file, much as
WordPress and BuddyPress do with their various config files.

Knowing our *current* user base (I spent 20 hours doing support last week),
having users directly edit a config file would not end well ...but if we
could get the plugin to write the values (taken from the config screens)
into a PHP file, like the WordPress installer does, we might have a winning
solution.

So...

a) What would you guys estimate the speed increase would be if we just read
the values in as PHP constants instead of pulling them from the database?

b) Based on your experience, would trying to do this with a file in the
wp-plugins directory cause epic file permissions drama on a significant
number of wp installations?

3) "I took a very cursory look at the plugin and noticed you weren't using
the settings API, at least not yet."

Thanks! ...wow...that was above the call of duty!

I suppose a more accurate statement would have been "I have the code open on
my workstation and I'm experimenting with the Config API, and I haven't
committed it to the SVN yet". I wasn't expecting anyone to download the
trunk and give us a code review ...although feedback is always welcome and
appreciated.

The most current version is here
http://code.google.com/p/buddypress-media/source/checkout

<http://code.google.com/p/buddypress-media/source/checkout>in
bp_media/branches/foxly/nightly   ...but I'll probably be updating the trunk
later today.


So no, there are no Config API calls in there yet.

I thought it would be better to put this question to the experts before
burning time coding something. Based on watching this list for like, a year
...you guys are unequivocally brilliant, and consistently come up with
solutions I'd never have thought of.

Thanks!

-Carl