2

I'm developing a plug-in that adds the possibility to import/export settings from another plug-in. However, I don't have access to the options ids saved by that plug-in.

Is it possible to get all options saved by a specific plug-in?

What I would like is something like this:

get_plugin_options($pluginId); // returns all options ids in a array or similar

I know its possible to just look at the plug-in code and write down the options names... but hard-coding options names wouldn't be nice.

Thanks!

2

Your best option is likely to copy all the names into your plugin to use for retrieval. Of course, this could change when the plugin is updated. When options are saved in the database using update_option() there's no indication of which plugin they came from that gets stored anywhere. If the options all use a particular prefix though, you could construct a SQL query to pull them from the options table based on that prefix.

For instance, if the prefix to all options for the plugin was 'abcd_', you could use a query like this:

select * from $wpdb->options where option_name like 'abcd_%'
2

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.

  • This is exactly the way it should be done! How would you track the get_option activity? – RafaSashi Apr 6 '18 at 13:35
0

I don't think this is possible or a universal function for this exists. Whenever you add an option you do so by adding an option_name and option_value - add_option().

<?php add_option( $option, $value, $deprecated, $autoload ); ?>

So whenever plugins add their options to the database, they use that function and usually prefix the option name with whatever their plugin is about wpseo_option_name or woocommerce_option_name followed by whatever the option is. Only the developers and their documentation keep track of the options they've created, WordPress does not really. It just lobs them in with all the other options created by other plugins, users, and WordPress itself.

You would manually have to find out all the option names their using, if they're using a prefix, and loop through each of their options: $prefix_$option_name.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.