Wordfence keeps returning to Learning Mode.

Hello @elevenweb and thanks for reaching out to us!

Enabling MySQLi storage engine

By default, Wordfence will save firewall related data within /wp-content/wflogs/*. However, in an instanced setup, the file-system is read-only.

To get around this, add the line define('WFWAF_STORAGE_ENGINE', 'mysqli'); after <?php on a new line within /wordfence-waf.php.

Wordfence will then save all its firewall data within the database instead of attempting to use the file-system.

https://www.wordfence.com/help/firewall/mysqli-storage-engine/

Let me know if this helps! Make sure the define(‘WFWAF_STORAGE_ENGINE’, ‘mysqli’); is in the correct bracket in the PHP file.

Thanks!

Dude, thanks for the quick return.

The problem is right there. I already did this … I followed these instructions and, even so, Wordfence always goes back to Learning Mode.

This is the content of the wordfence-waf.php file, which is located at the root of the site.

Do I have to delete the content from wflogs?
Is there any other step I should take?

<?php
// Before removing this file, please verify the PHP ini setting auto_prepend_file does not point to this.

define('WFWAF_STORAGE_ENGINE', 'mysqli'); 

if (file_exists('/srv/www/public/wp-content/plugins/wordfence/waf/bootstrap.php')) {
	define("WFWAF_LOG_PATH", '/srv/www/public/wp-content/wflogs/');
	include_once '/srv/www/public/wp-content/plugins/wordfence/waf/bootstrap.php';
}
?>

Is this your first time setting up Wordfence on this site? That would mean the firewall wouldn’t be optimized either.

If running Wordfence on a site where the wp-content directory is not writable, you can change the default path to a path that is writable. When the firewall is set up with “Extended Protection” (using .htaccess or .user.ini), modify this line below in wordfence-waf.php, and change the path to a safe and writable location:

define("WFWAF_LOG_PATH", '/var/www/html/wp-content/wflogs/');
Your current one is define("WFWAF_LOG_PATH", '/srv/www/public/wp-content/wflogs/');
Is that the correct path for your wflog?

Let me know what you find!

Thanks!

Our website is in a multi-server environment.
Auto Scaling with Load Balancer, so the problem is not that the folder does not have write permission. The problem is that there are multiple servers in parallel.

Wordfence has been running for several months now …

So the solution would be to write to the database. If it could be on AWS S3 it would also be a solution, but I believe it is not possible.

Are you using environment variables or another method for DB credentials, instead of having them defined directly in wp-config.php? Since the mysqli storage engine loads before WordPress, we pull the credentials from wp-config, for the firewall code to access the database when using the mysqli storage engine.

You might be able to get auto-scaling mostly working with the regular file-based wflogs for now, each instance will operate independently, but should generally work.

I expect it’s possible for you to enable the firewall and then copy a good set of wflogs files in an image that’s deployed when auto-scaling, so each new instance starts with the right settings.

Let me know what you find!

Thanks!

Yes, credentials are in the config.

I’m going to do what you suggested and put the wflogs in the image.

Let’s see if it works. Thank you.

Let me know what you find!

Thanks @elevenweb

I am having the same issue as the original post. Load-balanced environment, mysqli config added to the wordfence-waf.php, but WordFence isn’t using the database to store data. We define the standard DB_NAME, DB_USER, etc. WordPress constants in our wp-config.php file. Is there anything else that could potentially cause this issue?

Looking at the WF source I think I see the problem. It appears that WordFence requires the constants to be defined in wp-config.php ONLY, excluding any logic that occurs when wp-config.php is actually executed. WordFence calls extractCredentialsWPConfig($file) which manually string-parse the default DB_USER, DB_NAME, etc. constants out of the file. This will not work for anyone using any type of modified wp-config.php logic like we do (where we defer much of the variable setup to a separate file). For example, our wp-config.php file is just the following lines:

<?php
/** load custom configuration */
require_once('wp-config-init.php' );
/** Sets up WordPress vars and included files. */
require_once( ABSPATH . 'wp-settings.php' );

I can understand why WordFence is doing this, as it can’t really require() the wp-config file when loading so early… but it would be great if extractCredentialsWPConfig() did an if (defined('DB_NAME')) check to allow us to short-circuit this manual parsing logic. As it stands we’ll have to manually hack the WF core files to make it work in our custom environment.