Support » Plugin: Flexi Pages Widget » 1.7 update cleared all previous settings

Viewing 15 replies - 1 through 15 (of 21 total)
  • Plugin Author Srini G

    (@srinig)

    Sorry about that.

    Version 1.7 uses the WP Widgets API, and I did take steps to ensure the old settings are retained while upgrading. Not sure why that didn’t work for you.

    Which version of the plugin were you upgrading from?

    I believe I upgraded from v1.6.13.

    Don’t worry about it, could be an isolated incident that only affected me.

    But if it helps I am using WP 4.1.2 and a theme called Modernize by GoodLayers.

    Thanks for your efforts!

    Not isolated…cleared previous settings for me, too. I updated the plugin and all sidebars are gone. Went to widgets, widgets missing from sidebars. Put them back and widget not displaying pages when I use “Include”.

    Cleared mine too!

    Plugin Author Srini G

    (@srinig)

    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.

    Plugin Author Srini G

    (@srinig)

    Alusza, why wouldn’t the widget not display pages when you use ‘Include’? Please provide more details, like what the other widget options are, and where exactly the included pages are in the hierarchy of pages.

    tmuka

    (@tmuka)

    I had this issue too. I tried restoring old db backups and the old settings were never preserved… Not sure if it matters I don’t run the ui plugin upgrade, just copy new plugin files in place of the old one.

    joffs

    (@joffs)

    Hey Srini,
    if I get your code right, you delete old option “flexipages_widget” whether there is the new option “widget_flexipages” or not and only put old settings in new option when “widget_flexipages” doesn’t exist.

    On my installations updated to 4.2 I HAVE the “widget_flexipages” option in the databses eventhough I haven’t updated to 1.7!

    The content is: a:1:{s:12:"_multiwidget";i:1;}

    So, when updating to 1.7 I will lose my old settings as the new option is already there with some standard (wordpress) content.

    Pasting the settings from an backup before updating wordpress/flexi pages right into the database fixes the problem for me.

    Hope this helps.

    Cheers

    joffs

    (@joffs)

    I may add that it seems better to force the overwriting of any existing content of “widget_flexipages” IF “flexipages_widget” still exists.

    As a test I manually deleted the already existing “widget_flexipages” option from one of my installations before updating the plugin to 1.7. After updating, “flexipages_widget” is gone as expected, all settings are in “widget_flexipages” now and site works without trouble.

    Cheers

    joffs

    (@joffs)

    @tmuka Restoring old db backups won’t help here as you probably had the “widget_flexipages” in your database before updating the plugin and the old settings will never be transferred to the newly named option. Put in old db backup and delete “widget_flexipages” in options table and you should see everything working again after a page reload (assuming you have access to the database directly).

    Any thoughts from Srini?

    Plugin Author Srini G

    (@srinig)

    Hi joffs, thanks a lot for the inputs.

    You said,

    On my installations updated to 4.2 I HAVE the “widget_flexipages” option in the databses eventhough I haven’t updated to 1.7!

    That’s weird! But however that may have happened, what you say makes sense, the prior presence of ‘widget_flexipages’ can be one definite possible reason why the options upgrade didn’t work for some of the users.

    So the solution would be update the plugin to force copy the old options, if it is present, into new options irrespective of whether the new options ‘widget_flexipages’ is already there in the DB. The older options would have already been deleted for those who have made the upgrade to 1.7 irrespective of whether the options upgrade worked or not, as confirmed by tmuka, so I think it’s safe to make this move.

    joffs

    (@joffs)

    Hey Srini,
    thanks for the reply. I had the “widget_flexipages” with those default values (some other widget_* options had these values as well) on all my installations where I use the plugin. I am using the plugin for quite a while and my wild guess would be an update of WordPress causing the setting of “widget_*” options for (some) plugins. I haven’t dived into this further as to why that would happen.

    So yeah, forcing the transfer of old option name to new name should be safe. Won’t help those who who upgraded to 1.7 though.

    As I use the plugin on one installation pretty extensively I was to happy to find the problem and having a database backup at hand. 😉 Restoring the whole backup wasn’t an option here.

    Cheers

    joffs

    (@joffs)

    Ok, if I get it right the creation of “widget_flexipages” prior to version 1.7 must have happened with an old (possibly even years old) version of wordpress version producing some compatibility data in the database regarding the widget API and using a register_widget function. I cannot be specific but some google searches seem to point to that. Maybe people who know their stuff can make sense of that. 😀

    Cheers

    Plugin Author Srini G

    (@srinig)

    I am using the plugin for quite a while and my wild guess would be an update of WordPress causing the setting of “widget_*” options for (some) plugins.

    That’s true. The ancient versions of the plugin, versions 1.2 and older, used to store the widget options in an option named “flexipages”. So, somewhere along the line that option could have been renamed by WordPress to “widget_flexipages”. I don’t remember renaming this consciously via the plugin.

    Anyway, I just updated the plugin to v1.7.1 with the fix to this issue. Hopefully those upgrading from this point on won’t have this issue. That’s well worth it because stats show that a huge chunk of users are yet to upgrade to 1.7.

    Thanks again joffs and others!

    I’ll continue to look into the issue, but I wanted to give a piece of advice about running the Update script itself.

    I suggest that you check for updating the database on admin_init, not on plugins_loaded. Plugins_loaded runs on every page hit ever, while admin_init only runs in the dashboard. It is excessive database queries to test for updating how the widget data is stored on EVERY visitor’s page request.

Viewing 15 replies - 1 through 15 (of 21 total)
  • The topic ‘1.7 update cleared all previous settings’ is closed to new replies.