The previous versions of the widget used to store the widget settings in an option named ‘flexipages_widget’ in the wp_options table. Since 1.7 makes use of the Widgets API, it stores the settings in the option named ‘widget_flexipages’.
Here’s what the plugin does to retain the settings from the previous versions, flexi-pages-widget.php, lines 38-43
if( $old_widget_options = get_option( 'flexipages_widget') ) {
if( !( $new_widget_options = get_option( 'widget_flexipages') ) ) {
add_option( 'widget_flexipages', $old_widget_options );
}
delete_option( 'flexipages_widget' );
}
What it basically does is takes the older settings from ‘flexipages_widget’ option and stores it under ‘widget_flexipages’. This piece of code is hooked to ‘plugins_loaded’, so it should run before any widgets are initialized. I tested this in various setups before pushing out 1.7 to public, and it worked perfectly in every single case.
Not sure why this wouldn’t work for the users above. Maybe it’s not the way it’s supposed to be done, so if anybody knows a better way if doing this, please let me know, I’m open to suggestions.
Also, here’s the constructor of the Flexi_Pages_Widget class that sets up the widget
function __construct() {
parent::__construct(
'flexipages', // Base ID
__('Flexi Pages Widget', 'flexipages'), // Name
array( 'classname' => 'widget_pages widget_flexipages flexipages_widget', 'description' => __('A highly configurable widget to list pages and sub-pages.', 'flexipages'), ), // Args
array( 'width' => '400' )
);
}
You can see that the base ID is ‘flexipages’ and the Widgets API prepends a ‘widget_’ to that base ID and stores the settings under that name in the options table. So, the settings would be stored under ‘widget_flexipages’. Anyone knows if there is a way to specify the option name under which the widget settings would be stored? I’d prefer ‘flexipages_widget’ over ‘widget_flexipages’ as that would totally solve the above problem.
