ShakespeareVet

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…

Thank you very much; I appreciate your help.

Regards.

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.

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.

I am experiencing the same issue in the current version 6.2.1.

I would also like to echo the decrease in value and convenience afforded by the newer digest e-mail design; where Lockout and File Changes were at the top of the previous, simpler layout. And while I have image display disabled by default in my e-mail client, it was amusing to find none of the images would load anyway.

Mark,

Conventionally, footnotes are organized as Matus is requesting, where references are repeated according to their appearance throughout the text, and in numerical order in the references container (See almost any Wikipedia entry), although in some cases a text will sort references alphabetically by author in the equivalent of the references container, and they would subsequently start out of order in the text; but there would still not be two numbers (indexes) assigned to a single reference in either location.

In any case, I would like to echo Matus’ request that multiples of a reference be treated conventionally, but also make a couple additions:

1) Currently, only the first instance of a reference acts as an anchor, and clicking a multiple of it does nothing. It would be better to assign a sub-index for each multiple, where the initial is 1a, and then multiples thereof 1b, 1c, etc. So that in the references container, reference 1 and its multiples would be displayed as 1. ^ a b c Reference. where the footnote_plugin_link would therefore be disabled and each sub-index would return the user to the appropriate anchor in the post (like Wikipedia’s citation system).

2) Referencing a footnote with a multiple should be much easier than having to enter the entire reference again. Unfortunately, because references can not be numbered manually (e.g. [ref data-index=”1″]Reference[/ref], there is no way to refer back to them, e.g. [ibid data-index=”1″]. The Footnotes for WordPress plugin actually allows for this with the addition of a [backref] shortcode (which uses the deprecated “name” HTML attribute for the identifier), but does not provide unique sub-indexes for each multiple of a reference, so it also treats the first instance as the anchor to return to.

So far, this is the most promising footnotes plugin I have used, so I hope you continue to develop and improve it.

Thank you for your time.