dwinden
Forum Replies Created
-
@gal Baras
I noticed similar behavior in this topic.
It could be something specific on those envs which is causing it.
On the other hand it could also be a bug.Would it be possible to test the plugin in one of those envs with only the iTSec plugin installed/activated and Twenty Sixteen theme active ?
Additional note:
The issue does seem to be specific to banning.
So tests should be performed where invalid logins and/or too many 404s ultimately lead to IP bans.dwinden
@johan F00
I was only able to identify the first IP (66.249.73.156) as GoogleBot.
My guess is that you have the following iTSec plugin features enabled:
- Blacklist Repeat Offender
- 404 Detection
And due to the GoogleBot hitting many many 404s while crawling your site the IP got locked out and ultimately banned in the .htaccess file.
You should have been able to confirm the above in the iTSec plugin Logs page.
The best thing to do would have been to fix the 404s found in the Logs page.Other options are to disable 404 Detection or whitelist all known Googlebot IPs.
dwinden
@jim Reekes
The one email had a line for debug info, which looks like a query to wp-cron.php
Ok, so the ITSEC_DEBUG constant now seems to work.
The debug line at the bottom of the email will only show you the URL that triggered that specific Daily Security Digest email. When 2 emails are send you will find that the debug info shows different URLs in the 2 emails. It basically tells you which HTTP request triggered each email. Removing the ITSEC_NOTIFY_USE_CRON constant (but keeping the ITSEC_DEBUG constant) in the wp-config.php file will demonstrate this.
Anyway since you also set the ITSEC_NOTIFY_USE_CRON constant in the wp-config.php file the debug info confirms that sending of the Daily Security Digest email is now triggered by a WP Cron HTTP request (only).
And that is exactly what you want because due to a bug the Daily Security Digest email is often (not always) triggered as a result of 2 different HTTP requests. This can also be observed in the web server logs.
Since the issue seems to be resolved please mark this topic as ‘resolved’.
dwinden
Update to the latest version of the better-wp-security-fr_FR.po and
better-wp-security-fr_FR.mo files in the wp-content/languages/plugins folder and see whether that resolves your issue.dwinden
I discovered that the French translation for the iTSec plugin on translate.wordpress.org was updated by fxbenard on 12 May 2016 17:38:31 GMT.
The translation for the “Security” string was changed from “Sécurité” to “Security”.
You probably did not notice but I think your French translation for the iTSec plugin was updated accordingly. You can try and get this confirmed by looking at the modified date/time of the better-wp-security-fr_FR.po and better-wp-security-fr_FR.mo files.So your issue with empty tabs in the iTSec plugin was probably not a WPML plugin related issue at all.
I just installed the WPML plugin and it seems to be working fine.
dwinden
Interesting.
I can explain why it works without editing the better-wp-security-fr_FR.po file with Poedit as explained in point 2 of my previous post.
It turns out the string “Security” is by default translated into “Security” (and not as “Sécurité”) in the French iTSec plugin translation. The “Security” string untranslated or translated as “Security” makes the French translation and thus the iTSec plugin tabs work.
Since the plugin translation now seems to work the iTSec plugin menu option will probably show “Security” while everything else is in French. Please confirm.
When you look at your screenshot you will notice that when the tabs were empty the iTSec plugin menu option showed “Sécurité” !
So it could be the WPML plugin is under certain conditions translating “Security” into “Sécurité”. And this will break the iTSec plugin tabs.
Anyway the root cause of this issue is a known bug in the code of the iTSec plugin.
One additional question. Is the WPML plugin a paid plugin ?
dwinden
@jim Reekes
Indeed WP_DEBUG does not need to be set to true.
The ITSEC_ defines are actually not at the end of the wp-config.php file.
It should look like this:... define('WP_DEBUG', false); define('ITSEC_NOTIFY_USE_CRON', true); define('ITSEC_DEBUG', true); /* That's all, stop editing! Happy blogging. */ /** Absolute path to the WordPress directory. */ if ( !defined('ABSPATH') ) define('ABSPATH', dirname(__FILE__) . '/'); /** Sets up WordPress vars and included files. */ require_once(ABSPATH . 'wp-settings.php');dwinden
Change the following existing line in the wp-config.php file like this:
define('WP_DEBUG', true);Then try again deactivating the iTSec plugin and see whether any error is displayed in the white screen.
Also check the web server error_log for any errors.dwinden
@jim Reekes
Ok, so both constants, ITSEC_NOTIFY_USE_CRON and ITSEC_DEBUG don’t seem to work …
Any chance the defines are not at the proper position in the wp-config.php file ?
Make sure they are positioned right after the WP_DEBUG defined line.
dwinden
Have you already tried something with the Hide Backend Enable Redirection and
Redirection Slug settings ?dwinden
For some the bottle is half empty for others it is still half full … 😉
The community might surprise you. As to the chances of getting an answer from iThemes I think the bottle is pretty empty …
dwinden
First of all apologies for my late response.
I more or less promised to answer your question so here it is.Before digging into your question a short remark about posting questions in this forum related to the iTSec Pro plugin.
When you buy the iTSec Pro plugin from iThemes 1 year of support from iThemes is included. So you would normally log into the iThemes Member Panel with your credentials obtained at purchase and then create a support ticket.
That said File Change Detection is not a Pro only feature so for this particular topic you can also expect support from the wordpress.org community (even though you are using the Pro plugin).
The first time the iTSec (Pro) plugin runs a File Change Detection scan there is no data (stored in the database) to compare with. So all files are listed as Added. This is normal and expected behavior.
The data displayed after clicking on the Details link in the Logs page is difficult to understand for an average person using the plugin (though the data is formatted the way it is for a very good reason), but if you switch to the “File Change History” Select Filter: at the top of the log and then click on a Details link you’ll find that the data is displayed in a much more readable format.
The File Change Detection feature works basically the same in the free and Pro plugin with one exception. In the Pro plugin there is an extra setting available named Compare Files Online.
If enabled WordPress core files and iThemes plugin/theme files with detected changes will be compared with the clean master files at WordPress.org and/or at iThemes.
If the checksums of changed files match with the checksums of the clean online master files they are removed from the File Change Detection scan result.
So this results in much less file changes listed under the Details link in the Logs page. Very cool feature.It is your job to link reported file changes to events that occurred in your WordPress env. These events range from WordPress core updates to updating/deleting plugins, themes etc. Any reported file changes that you cannot link to a legit event in your WordPress env needs your special attention.
I hope this clarifies the File Change Detection feature.
dwinden
You probably forgot to tick the “Mark this topic as resolved” checkbox as the topic is not marked as ‘resolved’ in the topic title.
Create a new topic for your other concerns and who knows the community might provide you with an answer.
dwinden
I think the issue/question as initially raised in this topic has been dealt with/answered.
If you agree please mark this topic as ‘resolved’ and then open a new topic for the site performance and Google rankings question.
dwinden
