Widget data is stored in the options table as a two dimensional array. All data for the same type of widget is stored under the same option key. The key of the outer array is a kind of widget "index"-- the identifier for the particular instance of the widget. The inner arrays contain the individual widget data. Like so:
array(5) { // outer array
[3]=> // the widget instance identifier
array(3) { // widget instance data
["title"]=>
string(0) ""
["text"]=>
string(5) "first"
["filter"]=>
bool(false)
}
[4]=> // the widget instance identifier
array(3) { // widget instance data
["title"]=>
string(0) ""
["text"]=>
string(6) "second"
["filter"]=>
bool(false)
}
// and so on
}
To see what I mean, place the following in your theme header (or somewhere easily visible):
$w=get_option('widget_wp_mywidget');
var_dump($w);
Then drag your widget into the sidebar. You should see that $w
array get larger. If you delete some widgets you will notice that the keys don't reset. They are not simple auto-increment numeric indexes.
What this means is to pull the widget data for a particular widget, you need to know the widget's instance identifier, which is really pretty tricky and I don't know exactly what your requirements are.
You could crawl that $w
array looking for a clue like a title, or crawl the site sidebars looking for a widget in a particular location. For example, try:
var_dump(wp_get_sidebars_widgets());
You will notice that there is data in that array of the pattern text-7
, pages-4
. That prefix is the widget type and the suffix matches the "identifiers"-- the keys-- in the array above.
Edit:
After more thought and several comments, I think the best answer is:
There is no best way to get widget options. Widgets are intended to operate within and to be managed by the rather complicated Widget API built into the Core. There is no easy way, and certainly no Core way, to get access to widget data outside of that system. A lot of information has to get juggled around to take widgets apart and to put them back together.
My feeling is that if you think you have the need to use a widget outside of the Widget API you are probably using the wrong tool for the job.
I can understand the need, perhaps, to use the same data in a widget and elsewhere but I would suggest that using the widget as the source of that data is backwards. The more I think about this the more I am convinced that the better way to do it is to use some other form/interface for the data-- Theme Option, Plugin Settings page, something-- and then retrieve that data for use in the widget and outside of it.