[wp-hackers] distinguish plugin options?
wp-hackers at striderweb.com
Thu Jan 22 22:55:17 GMT 2009
On Jan 22, 2009, at 11:59 AM, Mike Schinkel wrote:
> Imagine an addition to WordPress core that would communicate to
> WordPress.org the certain options are in use by plugins that elected
> to report. It would also be an option the user would have to turn on
> and then that option could report any previously unreported plugins
> options to the WordPress service. ...[I]t could empower a real great
> automatically maintained option reference!
Nice idea, but unless it offers a significant gain for plugin coders,
good luck getting them to do it. :\
I think a better system would be to build into WordPress "core" a file
that lists all built-in options. It could be a simple text file, or a
PHP file that does nothing but create a hard-coded array, e.g.:
$wp_core_options = array(
Then if someone needed such information it would be as simple as
including the file. This could be useful for a lot of things, and
really would be best implemented at the core level instead of as an
add-on (since it would always have to be kept up with the current code).
Two good uses off the top of my head:
1) Obviously the thing I'm working on ;-) which would allow multiple
blogs to share plugin settings.
2) Plugins or other code that does cleanup on the options table by
removing options that are no longer used by any plugins. (With this
list it would be trivial to make it so that the plugin *never* removes
core options by accident!)
On Jan 22, 2009, at 11:45 AM, Ozh wrote:
> Yes it means you'll have to (very minorly) update the list & plugin as
> long as either you or WP are active. What you'll do anyway. And if
> you're no longer active, chances are you'll don't care a lot about
> supporting a plugin, right? :)
Wellll... Yes, but Virtual Multiblog is a significant system that run
*under* WordPress, which means if it fails, *kablooie*. I certainly
may reach a point where I no longer maintain it, but I wouldn't want
all the people using it to crash and burn on the next WP update.
Stability is word #1.
On Jan 22, 2009, at 2:59 PM, Otto wrote:
> I'd add a hook to update_option, and
> then have my hook run a debug_backtrace() to get the function call
> stack. By examining that stack, you can determine what file made the
> call to update_option, and if the file is in wp-content/plugins/*,
> then it's a plugin's option and you'll know.
Interesting idea. In fact, the best "automatic" one I've heard;
though it sounds a bit intensive to run "live" on a blog. Hmmm......
Oops, except your idea won't quite work because plugins do also make
calls or changes to core WP options. It might be the basis for
something more workable though. I'll have to think about this one.
More information about the wp-hackers