Problem when renaming tables prefixes on a multisite installation

A little correction to the modified code suggested by me:

INSTEAD OF
if ($error != 1)

USE
 if ( @$error != 1)

This is just to prevent, in development environments (where php.ini directive display_errors=On), the message:

Notice: Undefined variable: error in var/www/html/wp1/wp-content/plugins/all-in-one-wp-security-and-firewall/admin/wp-security-database-menu.php on line 499

This message occurs because $error variable was not defined before. In fact, the best solution would be define this variable in a previous part of the code as “zero” but, as you used “@$error” in the table rename part of code, I followed the same style in this correction.

Hi guys. I have just downloaded version 3.8.3, and tested the fix made by you. Unfortunately, I verified that the problem was not solved. To confirm it, do the following:

– create a multisite installation, and add two more sites (ids 2 and 3)

– with a database utility, like phpmyadmin, do a search in all tables for the expression: user_roles. You will find three ocurrences, as follows:

TABLE………………OPTION NAME
wp_options…………wp_user_roles
wp_2_options……..wp_2_user_roles
wp_3_options……..wp_3_user_roles

– now, go to the plugin “DB Prefix” page, and rename the table prefix. Then, after doing a refresh in phpmyadmin viewing, do the same search. You will the same three ocurrences, but ONLY ONE WAS CORRECTLY RENAMED, as follows:

TABLE……………………..OPTION NAME
90q63q_options………..90q63q_user_roles
90q63q_2_options…….wp_2_user_roles
90q63q_3_options…….wp_3_user_roles

We should not find these references to “wp_” prefix, if the fix was working correctly. All occurences of “wp_” should be substitued by the new random prefix, in this case, “90q63q_”

I discovered that, there is a difference between the code that generates a random prefix and the code that uses a custom prefix: the first one does not change the variable associated with the tables prefix, but the second one does. This is the cause of the second bug, mentioned above.
This undesirable change in the value of the variable is done by the following line of code:

$error = $wpdb->set_prefix( $new_db_prefix );

A way to revert this change is adding the following line to the code:

$wpdb->set_prefix( $old_db_prefix ); // this line was added
$perform_db_change = true; // this line is already in the code

Another solution would be change the method for testing the custom prefix informed, in a way that did not change the value of the table prefix variable.

Now, I found a problem that can only be seem with the WordPress debug turned on, as follows:

– turn WordPress debug on, editing wp-config.php as follows:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('SAVEQUERIES', true);

– go to the Database Security section of plugin and rename the table prefix

– go to wp-content folder. You will see a file, debug.log, with the following content:

[18-Sep-2014 20:32:35 UTC] WordPress database error Table ‘wp0eng.wp_blogs’ doesn’t exist for query SELECT blog_id FROM wp_blogs made by do_action(‘wp-security_page_aiowpsec_database’), call_user_func_array, AIOWPSecurity_Admin_Init->handle_database_menu_rendering, AIOWPSecurity_Database_Menu->__construct, AIOWPSecurity_Database_Menu->render_menu_page, call_user_func, AIOWPSecurity_Database_Menu->render_tab1, AIOWPSecurity_Database_Menu->change_db_prefix, AIOWPSecurity_Utility::get_blog_ids

[18-Sep-2014 20:32:35 UTC] WordPress database error Table ‘wp0eng.wp_sitemeta’ doesn’t exist for query SELECT meta_value FROM wp_sitemeta WHERE meta_key = ‘dismissed_update_core’ AND site_id = 1 made by include(‘D:\Var\www\html\wp0eng\wp-admin\admin-footer.php’), apply_filters(‘update_footer’), call_user_func_array, core_update_footer, get_preferred_from_update_core, get_core_updates, get_site_option

Note: wp0eng is the name of my database.
Tests were made with your original code and with my modified code. Both returned this error.