• Resolved Rate That Rescue

    (@ratethatrescue)


    I was using WordPress 4.4.2 with Wordfence 6.1.x on two WordPress installations on the same virtual server (one in root for one site; one in subdirectory for another site).

    Upgraded both to WordPress 4.5 and upgraded Wordfence to 6.1.3 (both latest)

    Wordfence in the root install still works fine
    Wordfence in the subdirectory install is broken. It will not save options or get a free API key.

    Symptoms:

    Cannot save any settings in Wordfence options. Can make changes but they are not saved.
    Wordfence keeps asking for admin alert email, but does not save it. This seems related to no options being saved.
    Error banner: Wordfence could not get an API key. But there is full outbound internet connectivity.
    Log out and back in, no change
    I’ve deleted Wordfence and reinstalled it, no change

    I have not configured WAF on either site, as I need Wordfence working again in the subdirectory site first.

    I’ve never had a problem on previous upgrades to WordPress or Wordfence.

    https://www.ads-software.com/plugins/wordfence/

Viewing 15 replies - 1 through 15 (of 48 total)
  • Hello ratethatrescue,
    what is your server setup? Are you on Linux or Windows? Are either of these installs multisite or are they both single site installs?

    Thread Starter Rate That Rescue

    (@ratethatrescue)

    Thanks for your reply!

    It’s Linux 2.6.32. Both are simple single site installs. Everything was working normally until the WordPress 4.5 upgrade, then suddenly Wordfence could not save any options.

    All other functionality and plugins are working fine after the upgrade.

    Hello again,
    Thanks, it could be something with with the paths. Any chance you could check the server error logs and see if there are any [error]s there that could be related? Files that can’t be included or such.

    Thread Starter Rate That Rescue

    (@ratethatrescue)

    Thanks. I enabled logging and found that it was a MySQL problem. Specifically, MySQL was returning ‘wp_wfConfig.MYD file was not found (Errcode: 2)’. So this table was corrupted in MySQL, and all references to it was throwing this error, including clearing it on uninstall.

    I manually did a DROP TABLE in MySQL, and on reinstalling WordFence, it recreated it which fixed the problem.

    I’ve no idea how the MYD file got lost on the upgrade (I never touched MySQL or files on the server) but it’s fixed now. It might be nice if WordFence detected problems like this, and allowed you to clear configuration tables with DROP TABLE, which fixes it.

    Thanks again.

    Hello ratethatrescue,
    at the very bottom of Options page there is an option to “Delete Wordfence tables and data on deactivation”. This would clear all your tables though. Thanks for your input and I’m glad you were able to solve the problem.

    Thread Starter Rate That Rescue

    (@ratethatrescue)

    Thanks. However, given the wp_wfConfig table was corrupted (due to the missing MYD file), it was impossible to save the option to delete wordfence tables and data on deactivation.

    More concerning, I have just had the exact same corruption on the other WordPress installation (in the root). The same error “wp_wfConfig.MYD not found (Errcode: 2)” was occurring. The fix again was “DROP TABLE wp_wfConfig;”, then deactivate and reactivate Wordfence, which recreates this table.

    But, no other MySQL tables are corrupted so far as I’m aware. I can’t think of anything on the hardware or server software that would cause just the wp_wfConfig.MYD file to be lost on two separate MySQL databases.

    It seems like a systemic problem with Wordfence, or its interaction with MySQL on the latest update. What do you think could have caused this problem? Has anyone else reported it?

    Hello ratethatrescue,
    I see your point there. ?? As far as I know we don’t have any more reports like this but I will definitely relate this to the team and see if they have any clues as to what might be going on. Thanks for reporting. I’ll get back to you if I get some answers.

    Hello ratethatrescue,
    a quick update. We have had a few other reports like this but have not been able to trace the cause nor have we been able to reproduce the bug. If you have time to help us debug it, may I first ask if both these installs were on the same server? I would also like to know if your tables default to MyISAM or InnoDB.

    Thread Starter Rate That Rescue

    (@ratethatrescue)

    Thanks. Both installs are now reporting the exact same problem again, so there’s something that is intermittently deleting the wp_wfConfig.MYD file. So Wordfence keeps losing its configuration and stops working.

    Running a database check on each database shows that only this table on each database is corrupted. Everything else is fine.

    Yes, both these installs are on the same shared hosting server. I don’t have control of the MySQL install, I just have access to the databases I own.

    MySQL is 5.5.45-cll-lve on x86_64 on Linux. It looks like tables are defaulting to MyISAM.

    Thanks ratethatrescue,
    I will try to investigate this as far as I can. At least we are seeing a pattern in that it is the same table every time.

    MySQL logs can be tricky to find especially on shared hosting but if at all possible, you could check them for any indication that MySQL crashes and is forced to restart (restarted mysqld). The logs are usually in /var/lib/mysql but on shared hosting that folder is not accessible. You can ask your host if you want. This information would not resolve the issue, it just might get us a bit closer to the answer.

    I will do some more research on this too and get back to you as soon as I can.

    I have EXACTLY the same problem… hoping for a fix.

    Thread Starter Rate That Rescue

    (@ratethatrescue)

    Thanks. My shared hosting provider does not keep MySQL logs, so they couldn’t see any MySQL user activity or crashes.

    However, they did see 3 error logs per second being caused by a PHP script memory limit, caused by the file /wp/wp-content/plugins/wp-security-audit-log/classes/Connector/MySQLDBConnector.php

    This is from a different security plug-in, WP Security Audit Log, https://www.ads-software.com/support/plugin/wp-security-audit-log. But it does seem to be related to the PHP connection to MySQL database, at least.

    They have now increased the PHP memory limit to 368M from 128M, which should resolve that memory limit error. I have now dropped Wordfence’s config tables and reactivated it, to see if the problem reoccurs with the increased PHP memory limit.

    Thanks for the update ratethatrescue! It is possible then that it ran out of memory while writing to the table. Report back here if the table gets corrupted again.

    Hello All,

    Have been following this thread for the last few days as I’m facing the issue on almost 6 WP installations. I tried dropping the tables and it works for a while..the options are saved, but the problem reappears everytime the wordfence Cron runs. I’m not a coding guy so won’t be able to help much, but would like to share my observations.

    I’ve already tried all the suggestions and none seems to work. My hosting guys (Namecheap)also tried to check if anything is currpting the tables, but couldn’t find any.

    Also it’s not about plugin conflict as I’ve tried it after deactivating all plugins …but the issue reappears after a day.

    Also, don’t thinks it’s theme specific as I’ve 6 different themes but the issue is common to all.

    I don’t think it’s a PHP memory limit issue as I’ve 512 MB limit but still Wordfence is not able to save the options…wfconfig.

    On the diagnostics page, I can see all the tables are populated instead ne i.e. wfconfig. Somehow the wfconfig table is empty I don’t know whether its curropted.

    Same problem here on 2 sites hosted by Namecheap. Can’t save changes! Also, the “Congratulations” popup won’t go away.

Viewing 15 replies - 1 through 15 (of 48 total)
  • The topic ‘Upgrade to WordPress 4.5: Wordfence 6.1.3 broken in subdirectory install’ is closed to new replies.