You can't get that data on an option already saved by a plugin, but what you can do is monitor add_option
, update_option
and possibly get_option
activity to find out which plugins are using which options with simple backtracing. I put together a little snippet for you:
function gimme_your_options( $option_name ) {
$blame = 'core';
$debug_backtrace = debug_backtrace();
foreach ( $debug_backtrace as $call ) {
if ( empty( $call['file'] ) )
continue;
if ( ! preg_match( '#wp-content/((?:(?:mu-)?plugins|themes)/.+)#i', $call['file'], $matches ) )
continue;
$blame = $matches[1];
break;
}
error_log( sprintf( 'blame %s for %s', $blame, $option_name ) );
}
add_action( 'add_option', 'gimme_your_options' );
add_action( 'update_option', 'gimme_your_options' );
Not to throw Jetpack under the bus, but here's an example response in my error.log:
[23-Mar-2015 05:39:27 UTC] blame core for active_plugins
[23-Mar-2015 05:39:27 UTC] blame core for _transient_doing_cron
[23-Mar-2015 05:39:27 UTC] blame core for cron
[23-Mar-2015 05:39:27 UTC] blame core for cron
[23-Mar-2015 05:39:28 UTC] blame plugins/jetpack/class.jetpack.php for _transient_timeout_jetpack_https_test
[23-Mar-2015 05:39:28 UTC] blame plugins/jetpack/class.jetpack.php for _transient_jetpack_https_test
[23-Mar-2015 05:39:28 UTC] blame plugins/jetpack/class.jetpack-options.php for jetpack_options
Hope that helps.
Also note that there may be false positives, i.e. if a plugin for example adds a cron schedule, the function would be the one blamed for accessing the cron option, however, the plugin certainly doesn't own that option.