tmaste

@wfpeter I can reproduce this bug also in WP Engine with a fresh WP installation.

This is because Wordfence itself always forces the WFWAF_STORAGE_ENGINE=mysqli setting to be used in WP Engine.

1. Create a new WP Engine site
2. Convert the site to WP multisite (e.g. sub-directory network)
3. Create a new subsite, so that you have two blogs: the main blog (e.g. *****.wpenginepowered.com) and the subsite blog (e.g. *****.wpenginepowered.com/subsite)
4. Install Wordfence to the site
5. Result: the subsite blog is a lot slower than the main blog

Testing:

• When I visit the main site URL *****.wpenginepowered.com/wp-admin/admin-ajax.php, the HTTP response arrives in 0.2 seconds
• When I visit the subsite URL *****.wpenginepowered.com/subsite/wp-admin/admin-ajax.php, the HTTP response arrives in 1.1 seconds

I have double-checked that in the subsite on WP Engine, the line $wfWAFStorageEngine->installing = !get_option('wordfenceActivated'); in Wordfence is always true, which is a bug (explained in more detail earlier in this thread).

Therefore it looks like all subsites in all multisites that use Wordfence in WP Engine (or any environment that uses WFWAF_STORAGE_ENGINE=mysqli) currently have a performance issue caused by this Wordfence bug.

Based on the debugging in my previous post, I tried adding the option wordfenceActivated to my non-main blog manually:

insert into wp_7_options values (NULL, 'wordfenceActivated', 1, 'yes');

After this, Wordfence doesn’t try to re-run the migrations anymore after every page load of a non-main blog.

Hi Peter, thanks for the reply.

We’ve run some tests on a multisite with MySQLi enabled and we see the correct version being detected in runMigrations() when visiting sub-sites.

Interesting that you couldn’t reproduce the problem.

Since I’m not only setting the WFWAF_STORAGE_ENGINE constant, but also setting the following constants, I was wondering if one of those constants is the cause of the problem:

• WORDFENCE_ALLOW_DIRECT_MYSQLI
• WFWAF_DB_*
• WFWAF_TABLE_PREFIX

But if you tried with those constants defined as well, perhaps the root cause is somewhere else.

Note that I’m also using HyperDB, i.e. wp-content/db.php, with one read-only DB instance and one read-write DB instance, which is why I set this to false as instructed.

Are DB_HOST, DB_NAME, $table_prefix, or any other database-related values being set differently for the non-main blogs?

No, those values are the same for all blogs. This is what my wp-config.php basically contains:

define( 'DB_NAME', [redacted] );
define( 'DB_USER', [redacted] );
define( 'DB_PASSWORD', [redacted] );
define( 'DB_HOST', [redacted] );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', 'utf8mb4_swedish_ci' );

$table_prefix = 'wp_';

if ( !defined( 'WFWAF_STORAGE_ENGINE' ) ) {
  define( 'WFWAF_STORAGE_ENGINE', 'mysqli' );
  // For HyperDB
  define( 'WORDFENCE_ALLOW_DIRECT_MYSQLI', false );
  define( 'WFWAF_DB_NAME', DB_NAME );
  define( 'WFWAF_DB_USER', DB_USER );
  define( 'WFWAF_DB_PASSWORD', DB_PASSWORD );
  define( 'WFWAF_DB_HOST', DB_HOST );
  define( 'WFWAF_DB_CHARSET', DB_CHARSET );
  define( 'WFWAF_DB_COLLATE', DB_COLLATE );
  define( 'WFWAF_TABLE_PREFIX', $table_prefix );
}

if ( !defined('ABSPATH') )
  define('ABSPATH', dirname(__FILE__) . '/');

require_once(ABSPATH . 'wp-settings.php');

If you could send a diagnostic to wftest @ wordfence . com directly from the link at the top of the Wordfence > Tools > Diagnostics page, that may help. Then click on “Send Report by Email”. Please add your forum username where indicated and respond here after you have sent it.

If the “Send Report by Email” button creates the same diagnostics output as the “Export” button, then unfortunately it sends too much data for my liking (in terms of security). I might sanitize the data by hand first and send it to you manually.

The debug.log file does not contain any Wordfence-specific errors.

I’ll get back to this next week.

• This reply was modified 2 years, 3 months ago by tmaste.
• This reply was modified 2 years, 3 months ago by tmaste.