editorsean

After updating to version 5.2.1, this issue is fixed.

Personally I don’t like Google recaptcha. As my ISP uses a NAT, occasionally I end up being connected with a blacklisted shared IP address, which basically means if I land on a site that uses Google recaptcha, it might give an endless loop of puzzles to solve. It’s a terrible experience that I don’t my visitors to face if they need to contact me.

With the quiz, I post a photo of some random object and ask for the word directly above the ‘CE’ mark, brand name shown on the item, etc. So far this has worked very well and often go months without a single spam. Previously with math and trivia questions, I was regularly getting spam.

• This reply was modified 4 years, 7 months ago by editorsean. Reason: correction

I had this same issue also, as each time I checked my posts to check their view counts, my own view was counted on each. The same was also true when a bot viewed the posts, such as Googlebot. This became a problem in seldom viewed posts these extra views would badly skew the counts over time.

The following is based on a modification of this plug-in I did on my website, which should stop bots/crawlers and logged in users incrementing view counts.

Edit the file ‘index.php’ in /wp-content/plugins/kento-post-view-counter

Scroll down to the following block of code (line 472 in version 2.7):

if($visited=="yes")
		{

		}
	elseif($visited=="no")

Change the first line of this so it becomes:

if($visited=="yes" || is_user_logged_in()  || _bot_detected())
		{

		}
	elseif($visited=="no")

Add the following code before the ‘?>’ at the end of this file:

function _bot_detected() {

  if (isset($_SERVER['HTTP_USER_AGENT']) && preg_match('/bot|crawl|slurp|spider/i', $_SERVER['HTTP_USER_AGENT'])) {
    return TRUE;
  }
  else {
    return FALSE;
  }

}

This function I found online basically checks the user agent to see if it’s a known bot or crawler and returns TRUE if it is.

Now the view count will only climb when a guest views the page. My site does not allow users to log in, so this code would need to be tweaked if you would like to count logged in user views also, but not editor/admin views.

Thanks for the update, I installed the update v1.6.1 and the generate tag feature is working now.

Just to update on this, I found the problem today when I went on our website to check something and noticed every page outside of the homepage was showing a 404 error.

It turns out that when I tried enabling the Hide Backend feature, it wiped everything out of the .htaccess file apart from iThemes own code, so the default WordPress rewrite rules and various other rewrite I had were gone. Once I added these back from my last backup, the site worked fine.

I updated iThemes to 4.2.13 (from 4.2.6) and tried enabling the Hide Backend feature again and this time it’s as intended, i.e. wp-admin.php now fails, but the new link works, so probably a bug in the earlier version. Pity I didn’t check the website (besides homepage), as it meant most of the website was offline for the 2 days.

As I mentioned above, the 404 Detection does not work in iThemes Security when I use the Rename wp-login.php plugin.

The iThemes Security log had over 1000 pages of 404 errors due to a few brute force attacks over the weekend. If the 404 Detection worked, there should have been no more than 40 errors per attack as I have the 404 Detection configured for a lockout after 40 errors.

Unfortunately it looks like the “Hide Login Area” feature is defective, at least on my site.

Not only did it present 404 errors for /wp-admin and /wp-login.php, it also gave a 404 error for the new URL it set up. The automated e-mail it sent me with the new link also gave a 404 error.

Thankfully I was still logged on one PC and disabled this feature, as I could not see any way of logging in.

The other plug-in I tried earlier (Rename wp-login.php) worked fine with the new URL, but as I mentioned above, caused the issue with the 404 detection.