Ben Lobaugh (blobaugh)

Could you give some more details please? When is this happening (plugin activation, viewing TAC page, scanning files, etc)? What version of WordPress are you running specifically? Is there anything in a server error log? Does any sort of change to the display happen when you have the issue?

The more details the better. Thanks!

Working on it. As part of the next release this should be fixed, as well as some major updates to the core of the plugin

This plugin is currently being built out by the Seattle WordPress community. Keep watching it for changes

This plugin is currently being built out by members of the Seattle WordPress community

I know, I have voted already. I poke you enough on here you should remember me by now ??

WF did NOT create the tables on install/activation. This is because your DB connector code has a bug in it that does not allow valid values for DB authentication. See the following for the code fix https://www.ads-software.com/support/topic/wordfence-install-error?replies=9 . This is another reason to use the built in database object rather than creating your own ??

Later on your code is not verifying that the tables have been successfully created. You should probably add a check to ensure the tables have been created/updated on activation/update and disable the plugin with a message to the user about how to fix it if they are not available.

Thanks for the quick response. I am not sure I understand the reasoning of using wfDB. Adding another database layer and connection will cause a lot more overhead than the one that is already built in and ready to do.

mysqli is probably going to be used going forward. The reason it has not been used traditionally is that older versions of MySQL were supported and therefore mysqli could not be used. As of WP 3.2, MySQL 5 is the minimum requirement, thus making mysqli the new acceptable choice

https://www.ads-software.com/about/requirements/

I also ran into this issue and I am wondering if it is the same cause. This is on an OSX test environment and deployed to a Linux server, however it should not matter as the error is with the code in the plugin specifically, not the OS platform.

In wfDB.php there are the following lines
if(! $wpdb->dbhost ){ $this->errorMsg = “The WordPress variable from wpdb dbhost is not defined.”; }
if(! $wpdb->dbuser ){ $this->errorMsg = “The WordPress variable from wpdb dbuser is not defined.”; }
if(! $wpdb->dbpassword ){ $this->errorMsg = “The WordPress variable from wpdb dbpassword is not defined.”; }
if(! $wpdb->dbname ){ $this->errorMsg = “The WordPress variable from wpdb dbname is not defined.”; }

However if any one of those variables inside $wpdb contain an empty string your conditional fails. Though not recommended, it is entirely possible to have an empty string for the password, as is the case on this test machine. You should update the code to use isset as follows:

if(! isset($wpdb->dbhost) )
if(! isset($wpdb->dbuser) )
if(! isset($wpdb->dbpassword)
if(! isset($wpdb->dbname) )

Additionally, if you are going to cause the method to end without setting up the database object you should ensure that it is setup later in your code before attempting to use it or the errors in the original post will happen, not good.

Finally, why are you creating your own database object and connection when there is a perfectly good database object already built into WordPress? This not only breaks WP convention, it also restricts the environments your plugin can run in. It is possible to use WP with different databases as WP provides the functionality to do that and I have seen it in the wild and done it myself. You should always use the WP API if there is a function available to do what you need, and there is ??
https://codex.www.ads-software.com/Class_Reference/wpdb#Run_Any_Query_on_the_Database

Did you by chance add in the JS tracking in the latest version? I would like to start playing with W3 cache for a new client site that is going to need some heavy caching, but I like your plugin so much that I do not want to find another solution.

Ok, I was hoping it was not due to number of rows. That would indicate that SlimStat was doing some funky number crunching in a very inefficient way. My MySQL server is on a cluster dedicated and optimized just for MySQL. Maybe this issue is somehow tied into the corrupt table issue that keeps happening. When (more like if!) I have time I will do some more digging.

Update – My table is no longer having this crashing issue, but there is another site on my server somewhere having the same problem. I have not had a chance to track it down which site yet, but this is very odd.

Update – I backed up the data in the wp_slim_stat table. Deleted the table. Recreated wp_slim_stat. Copied the data back. A few hours later a corruption appeared again :S

Pretty sure I voted for you plugin already. I recommend it to everyone and install it for all my clients ??

Ok, thanks Camu. If I get it figured out I will report back ??