nort99

Hi @kevinb,

Do you have an update on this? I’m getting deprecation notices when viewing the comparison page.

Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in?[deleted]\web\wp-admin\includes\plugin.php?on line?2163

Deprecated: strip_tags(): Passing null to parameter #1 ($string) of type string is deprecated in?[deleted]\web\wp-admin\admin-header.php?on line?36

Hi,

Any update on this? I’m seeing the same thing. It’s resetting the rewrite_rules option that is being used by the “redirection” plugin. It’s causing large numbers of queries because the redirection plugin has to keep resetting the options value.

Hi Collins,

Thanks for the instructions. I found I had disabled the gravatar option under the discussion settings in WP (probably when I originally installed your plugin). Once I enabled that again and updated everything worked as expected.

Thanks for your work and plugin.

Mark

Hi all,

I had the same problem so I took a look around. In lines 28 to 31 of “plugins/wp-user-avatar/includes/class-wp-user-avatar” I notice that the author has commented out lines 29 and 31 which look to be responsible for putting the avatar edit box onto the page.

// Profile functions and scripts
//add_action('show_user_profile', array('wp_user_avatar', 'wpua_action_show_user_profile'));
add_action('personal_options_update', array($this, 'wpua_action_process_option_update'));
//add_action('edit_user_profile', array('wp_user_avatar', 'wpua_action_show_user_profile'));

I’m not sure the reasoning for this, but you can uncomment these lines and it appears again. I took a safe option and reverted back to version 2.2.7 of this plugin until there is an official fix.

Hope this helps.

Thanks gmetais. That was the problem. I checked my server and I now have two versions of the class one main.php and one Main.php. The latter must have bee written there by updating the plugin via the server. I’ll be updating my git config to prevent this in future.

• This reply was modified 5 years, 5 months ago by nort99.

Thanks for your help David. We got there in the end!

The error was not related to MLA but in fact was related to W3 Total Cache. The list of active plugins from the wp_options table had been cached in the object cache when MLA was deactivated. The cache was not correctly updated when the plugin was reactivated. As a result, when the ajax call was received by the server, the MLA plugin wasn’t loaded and caused the ajax error.

The solution was to disable the object cache, enable the plugin, then re-enable the object cache. Ultimately I think there is an issue with the way the cache stores the wp_options, but that’s for another day!