Settings not Written to htaccess in Root Directory for Non-Root WP Installation

Hi,

the plugin should nevertheless be writing settings to the htaccess file in the root directory; instead of in the subdirectory

Can you give an example of where your WordPress site resides?

which makes some features ineffective (primarily, the Blacklist Manager).

Can you provide more information or give an example?

Thank you

Thank you very much for the prompt reply. I am comparing AIOWPS to other security plugins, with the desire to replace automatic blacklisting based on 404 detection; such as with iThemes Security, which I am using currently, but which comes with issues of its own. While AIOWPS does not have that capability without purchasing the Smart 404 Block Addon; I would at least like to replace iThemes’ blacklist (“Banned Users”) feature (disabled while testing AIOWPS)…

While each plugin treats blocking somewhat differently (3 sequential SetEnvIF […] Deny Access rules [REMOTE_ADDR, X-FORWARDED-FOR, and X-CLUSTER-CLIENT-IP] per IP address in the case of iThemes, versus the two separately located Deny from and Require not ip rules for AIOWPS); iThemes will throw a server 500 error if the htaccess file is restored from a backup containing differences from the [previous] configuration currently stored in the database; whereby a disparity exists between that data, which is shown in the dashboard textarea containing the IP addresses in the blacklist, and that of the htaccess file.

I was planning to check if this issue is also present with AIOWPS when I noticed that it was not writing to the htaccess file in the root directory, but instead to the one in the subdirectory where WordPress is installed; unlike iThemes, which writes to the htaccess file in the root directory even if the site resides in a subdirectory. So, if the site is installed in example.com/site (“WordPress Address”), but is accessed from example.com (“Site Address”); AIOWPS will display example.com/site as the root directory in the “File Permissions” tab of the ‘Filesystem Security’ Settings; and “example.com/site/.htaccess” as the htaccess location, that it subsequently writes to.

Since I am still receiving 404s for blacklisted IPs using AIOWPS, however; I suspected that is the issue. I am testing identical blacklist rules in the htaccess file in the root directory and will review the server logs again.

As far as isolating potential issues in the htaccess file, it would be more convenient to have both Deny from and Require not ip rules in the same place for each IP just for convenience. With iThemes those rules are at least written successively; however, tracking down a specific IP address is troublesome due to the use of escape characters in those SetEnvIF statements; so AIOWPS is at least more convenient in that regard…

In any event, I am not sure if you have any other suggestions as to why the Blacklist Manager is not working.

Thank you again.

Hi,

Since I am still receiving 404s for blacklisted IPs using AIOWPS, however; I suspected that is the issue. I am testing identical blacklist rules in the htaccess file in the root directory and will review the server logs again.

Do you have a cache plugin installed? Are you using Cloudflare or similar service? Let me know what the server log files says.

In any event, I am not sure if you have any other suggestions as to why the Blacklist Manager is not working.

Are you running both security plugin simultaneously? Did you also check the plugins log files?

Thank you very much for the reply.

The only information the AIOWPS log shows is related to the block_bad_googlebots() function.

In any case, after copying the AIOWPS blacklist data from the .htaccess file in the subdirectory to the one in the root, all included IP addresses receiving 404s prior to the change now receive 403s; so that is clearly the issue.

Hi, I have submitted a message to the plugin developers to investigate further this issue.

Thank you

Thank you very much; I appreciate your help.

Regards.

Hi,
Currently this plugin locates your .htaccess file using ABSPATH (which is the path to the WordPress directory).
I will make a change to the plugin so that we get use “get_home_path()” instead which should solve your issue.

Thank you for the prompt reply, and I appreciate you looking into this and working in an update.

I look forward to the next release…