Not saving settings in WP Version 4.2.1
-
i updated latest version of plugin;
and there were no old settings;
i tried to save again but its not saving even its not scheduling.
-
Okay, thanks…
So it seems to be a multisite issue then.
3.2.1 was the last version without multisite support.
Do you use a multisite installation? Or just single site?
Rolf
multisite
3.2.1 was the last version without multisite support…?
then how it was working with multisite ?
i am using it on main site only without selecting tablesOkay, that’s useful information ??
I will dive into the code and see what might cause this…
Rolf
ok; update me.
its too late; see ya 2morrow
I have the exact same issue.
I was using version 3.2.1 on multisite by activating it only on site 1 (not network activated).
Updated to 3.4.1 and activated it on Network.
Setting on main site will not save.
FYI – with virtually every multisite plugin they split the functionality as follows:
Network Activated: Network Admin page used for taking action on entire network.
Site Admin page used for taking action on single site.I checked on a second multisite that I have where I had previously installed 3.2.1 and I could deactivate all plugins.
Deactivated all plugins. Network Activate. Same result.
I tried deactivating, deleting, reinstalling, same result.
I tried activating it on a single site instead of network activating, same result.
I don’t know why but it appears that if you installed the version that was not multisite compatible on a multisite and then update it it breaks saving the settings.
I am pretty good at testing/debugging as I have a few of my own plugins and I can tell you with a high level of certainty that this is a bug. It will likely only affect a small number of multisite users; the ones that installed the versions that were not multisite ready.
I haven’t looked at your code but I would suspect that you could add a pre-flight check on your activation hook if exists previous version tables delete previous version tables then proceed to flight.
Most likely that would clean up the bug.
Pat
Hey Pat,
Thanks for the feedback!
Not sure what you mean by:
I haven’t looked at your code but I would suspect that you could add a pre-flight check on your activation hook if exists previous version tables delete previous version tables then proceed to flight.
Can you explain?
Any help is appreciated since I hardly ever work with multisite installations…
Thanks,
RolfHere is a typical code for updating versions:
if( $db_version < {your desired version} ) { // previous updates and such $db_version = $new_version; //put that in the database } if( $db_version < $current_version ) { create $options array foreach( $option as $o ) { if( get_option( $o['old_name'] ) ) { update_option( $o['new_name'], get_option( $o['old_name'] ) ); delete_option( $o['old_name'] ); //clean up behind yourself } } and then update your database version again }
I reviewed the code of your plugin briefly (about 2hrs) and there are a few suggestions I would make to help you manage the development of the plugin for both single and multisite version.
First, you can move all of your single and multisite functions to a separate scripts and only include the single script if not multisite and the multisite script if multisite. By doing this it will help you to better manage what part of the plugin relates to single and what part relates to multi.
Second, use the above code in the multisite script to check for old version options that were created using $wpdb->prefix and convert them to $wpdb->base_prefix.
With single site options you use add_option(), update_option() and delete_option().
With multisite global options you use add_site_option(), update_site_option() and delete_site_option()
These settings will be stored in the global wp_sitemeta table and will be valid for all blogs in the network.
Third, create a network admin page to manage these new settings.
add_action('network_admin_menu', 'add_my_netw_settings_page'); function add_my_netw_settings_page() { add_submenu_page( 'settings.php', 'Cool Stuff', 'Cool Stuff', 'manage_network_options', 'my-netw-settings', 'your_form' ); } function your_form(){ $options = get_site_option('your_plugin'); ?> <form action="<?php echo admin_url('admin-post.php?action=update_my_settings'); ?>" method="post"> <?php wp_nonce_field('your_plugin_nonce'); ?> ...fields go here... </form> <?php }
The save handler:
add_action('admin_post_update_my_settings', 'update_my_settings'); function update_my_settings(){ check_admin_referer('your_plugin_nonce'); if(!current_user_can('manage_network_options')) wp_die('FU'); // process your fields from $_POST here and update_site_option wp_redirect(admin_url('network/settings.php?page=my-netw-settings')); exit; }
Hopefully, this will point you in the right direction.
Pat
Hey Pat,
Thanks for the suggestions!
If I understand you correctly the problem has to do with updating to a new version, right?
So, does it work when you install the latest version from scratch (plugin not installed and no settings in the DB)?
Thanks,
RolfA little oops. For converting blog option to site option it should look like this:
foreach( $option as $o ) { if( get_option( $o['old_name'] ) ) { update_site_option( $o['new_name'], get_option( $o['old_name'] ) ); delete_option( $o['old_name'] ); //clean up behind yourself }
So that you are updating the site option with the old option and then deleting the old option.
I will test that now and let you know.
Pat
I just tested it on a fresh install of multisite with 5 subsites and it works as expected.
One item that I noticed is that on this fresh install of multisite it displayed a list of all the tables with checkboxes next to them to exclude them from being optimized.
On my primary network there are over 200 subsites and when I loaded the options page it never displayed the list of tables with checkboxes. It may be that it was too many to load and it timed out.
Possibly for multisite you could exclude this loading of all tables for exclusion and make it optimize all or not. Then if you wanted to take it a step further you could keep the single blog admin on the individual blogs to optimize just the tables related to that blog.
Pat
Hey Pat,
Thanks for testing!
So, a clean install apparently does work for you?
Which is strange because the settings are exactly the same for v3.2.1 (last singlesite version) as for v3.4.1 (latest multisite version)…
Options for both versions are stored in the base_prefix->options table.
So, what’s the difference? I think I don’t get it ??
Rolf
Hey Rolf,
I reviewed the db entries of both my primary multisite and the fresh multisite and you are relatively correct – they look identical. As such it makes me think that the issue may be WPMU upgraded to MS vs MS which is a common relatively common issue and the reason for converting the old options to new options even if you leave them in the same place. It relates to permissions and primary blog assignment in the db for WPMU>MS vs MS.
However, it is better handled as I have suggested to move the options to the site option table and manage MS with a network admin page.
I will do a bit more testing over the next few days as time permits and let you know what I find. I am going to manually remove all db entries and try activating the plugin again and see how it behaves.
I will also create a fork for you with the suggested changes so that you can see what it would look like – that will probably take me a week or so to complete as I can only work on it about an hour a day. However, as I would really like your plugin to work on my primary multisite it is rather important.
Pat
- The topic ‘Not saving settings in WP Version 4.2.1’ is closed to new replies.