Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • 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

    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

    @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?

    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

    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

Viewing 5 replies - 1 through 5 (of 5 total)