dwinden

@yamamotowabbit

2) If it is writing large files (see above) over time will the .htaccess and wp-config files not become bloated and start to effect the site’s performance over time?

The iTSec plugin writes very little info to the wp-config.php file. So no worries there.
However the .htaccess file can get very big because of banned IPs.

Below a relevant quote from the lead developer of the iTSec plugin:

Since IPs are re-issued to new people all the time, banned IPs should only be banned for a while, then cleared from the list. If you’re collecting in the neighborhood of 7,000 banned IPs there might be something else going wrong.

dwinden

@brummbaer

Next time simply go to the better-wp-security plugin translation site and suggest a new German translation for this string.

Notice the 1 in the Waiting column ? I already added your suggestion 😉
Next time do it yourself.

dwinden

@TZAL

I’m sorry to hear that.
Seems like there is more trouble on that env.

Hard to say what’s happening without access to the env or additional info like possible errors in the web server error_log.

dwinden

@TZAL

Goto the Global Settings module by clicking on its Configure Settings button and in the next screen immediately click on the Save Settings button.
Good chance some validation error(s) will display.

Fix any validation errors and your issue might get resolved.

dwinden

@thepresident

The solution is actually in this topic.

Indeed a permission issue on the wp-content/uploads/ithemes-security/logs folder. The folder must exist and it must be writable.

dwinden

@chreddy

Nice to hear you were finally able to resolve the issue.

Deactivating and then reactivating the plugin should normally take care of creating these folders (regardless of the fact that log records are by default only written to the database).

I mentioned folderS because there should also be a backups folder.
When manually creating the folders please make sure to also include the index.php and .htaccess files.

Anyway as this seems to be resolved please mark this topic as ‘resolved’.

dwinden

@mcmito

Excellent.
I bet the message turned up in the Global Settings module and looked like this:

The file path supplied in Path to Log Files is not writable. Please supply a file path that can be written to.

Really appreciate your feedback 😉

It will probably fix the issue in the other topic you just updated (as well as in some other topics). Your solution totally fits the picture.

dwinden

@chreddy

Ok, I see.

It’s important to understand that the code method used for closing these 2 notices (x) is exactly the same.
So if the other notice is no longer displayed you (or someone else) must have clicked on the x button. Actually configuring the Brute Force Network Protection feature and receiving an API key makes no difference.
To get rid of the notice you must click on the x button.
So apparently it did work for the other notice. This rules out any php or database issues.

Now the only difference between these 2 notices seems to be that they are triggered using the value from a different setting stored in the database.

The notice with the “See what’s new” button uses the show_new_dashboard_notice setting which is part of the global settings. And there are 26 global settings.

The notice with the “Get Free API Key” button uses the api_nag setting which is part of the network-brute-force settings.
There are only 5 network-brute-force settings.

If one setting changes all 26 or 5 settings values are validated and if found valid saved in the database.

So there must be something wrong with the global settings.
I’m afraid the only way to find out what’s wrong exactly is to do some debugging.

As a workaround (but this does not fix the root cause of the issue) you can manually change the value of the show_new_dashboard_notice setting to 0 in the database. This should permanently get rid of the notice.
Note that applying the workaround will void the possibility to debug the issue.

dwinden