[wp-hackers] distinguish plugin options?

[Stephen Rider]

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. :\

However...

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.:

<?php
$wp_core_options = array(
	'active_plugins',
	'admin_email',
	'auth_salt',
	...
	'wpx_static_is_posts'
	)
?>

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.

Stephen


-- 
Stephen Rider
<http://striderweb.com/>