nlpro
Forum Replies Created
-
Hi Bozz,
The ban list includes a check for an empty user agent. So any remote request with an empty user agent is forbidden.
This basically means there is a simple solution. Add a user agent value to the admin-ajax.php request and you can keep using the ban list 😉
I’ve got the process figured out, so yes we’ll definately get there.
– how this works exactly/explaining what will be the end result: one .po file or a combination of files?
It will be a combination of files. For the free plugin translate.wordpress.org (GlotPress) manages the split up of translation strings from .php files (stored in a .po/.mo file) and translation strings from javascript files (stored in .json files).
For the pro plugin we have to do this ourselves using WP-CLI (wp i18n make-json).
– how can I start translating/ can you send me your it-l10n-ithemes-security-pro-nl_NL.po file?
I’m currently looking into how we (anyone) can (technically) collaborate to complete the pro translation.
I’m also thinking about creating/publishing an article that describes the whole process in detail on a test site. There is more than meets the eye when it comes to creating a pro plugin translation based on the free plugin translation. And quite frankly, this (Reviews) isn’t the right place for this kind of stuff.
So stay tuned, as soon as I know more I’ll let you know.
Turns out WP-CLI (Command Line Interface) can be used to extract the javascript translation strings from a single .po file into multiple .json files.
We can simply use ‘wp i18n make-json it-l10n-ithemes-security-pro-nl_NL.po’.
Where it-l10n-ithemes-security-pro-nl_NL.po is the translation file that resulted from merging the pro .pot file with the free translation.
Note the file name must use the pro (translation) text domain (it-l10n-ithemes-security-pro).
So I’m all set to generate a first set of translation files for a test ride in the pro plugin.
Stay tuned 😉
Ah, great.
I can confirm the 3 strings are now included on translate.wordpress.org and all three translations are also available in the iTSec plugin.
Thank you.
The theory is that as the number of banned IPs increase over time, you may run into timeout issues writing all those bans (default max 100) to the .htaccess file. It all depends on what the hosting env can deal with.
The newly introduced (ban) setting gives you the possibility to tweak the writing process such that it doesn’t run into such timeouts.
Remember it’s just a theory. But it’s worth to investigate and to be aware of. In the end there may be a totally different cause.
Anyway check the number of banned IP’s.
Hi twohumans (both of you),
This reply is stricly about the iTSec plugin writing to the .htaccess file (on Apache webserver).
I think you should be aware that the iTSec plugin writes EVERY hour to the .htaccess file. Even when there are no changes (compared to the last written content) whatsoever.
One would expect some kind of optimization in the writing process, so that the .htaccess file only gets written when the content changes. I really don’t like the idea of the .htaccess file unnecessarily being (re)written EVERY hour. Makes it prone to … corruption.
iThemes really needs to optimize the writing process to the .htaccess file.
So why is the iTSec plugin writing EVERY hour to the .htaccess file?
This is for making sure banned IP’s are actually banned (within a reasonable timeframe).
It got implemented as a cron job in the plugin 7.8.0 release. According to the 7.8.0 changelog:Enhancement: Remove quick bans. Persist banned hosts to .htaccess or nginx.conf on an hourly schedule.
And below an additional related entry from the 7.9.0 changelog:
Enhancement: Add a setting for configuring the number of bans added to the server config files (.htaccess/nginx.conf).
The default value is 100. Older banned hosts will be locked out after WordPress loads.
So probably the best thing to do would be to check the number of banned IP’s and if it’s > 100, lower the setting’s value. Then wait and see what happens.+++++ To prevent any confusion, I’m not iThemes +++++
Yes, banning a range of IP addresses using one or more * (wildcards) is still supported. EG: On saving 123.123.123.* gets automatically converted to 123.123.123.0/24 CIDR notation format.
The functionality has moved to the Security > Dashboard -> Banned Users card.
+++++ To prevent any confusion, I’m not iThemes +++++
Hi aglyons,
I believe that is how it is supposed to work. A bit unfortunate that the settings label and description is using the word “ban” (permanent). It should read “lockout” (temporary) instead 😉
Perhaps maybe one day …
+++++ To prevent any confusion, I’m not iThemes +++++
- This reply was modified 2 years, 5 months ago by nlpro.
No, problem.
The Dutch translation for the free plugin is now at 100% at translate.wordpress.org so below the final numbers (after a merge):
Number of strings in common: 1628 (64,99%)
Number of Pro strings to translate: 877 (35,01%)Currently investigating step 2, how to (easily) generate the .json files from the Pro .po file. It’s missing 877 translations but that won’t stop us from moving forward. The goal is to find out the best/easiest way to generate the .json files from the Pro .po file. It will (hopefully) also produce a set of language files we can already test in the (current) iTSec Pro 7.0.3 plugin.
There is no point in investing a lot of time translating 877 strings if it turns out the whole project is not viable 😉
(So far, so good …)I’ll keep you posted of any progress.
Hi Deddo,
Just wanted to share that I’m currently figuring out how to move/merge the Dutch translation strings for the free plugin into a Dutch translation for the pro plugin (The good news is that, preliminary results seem to indicate that, yes, it can be done).
The free plugin includes a total of 1721 strings versus 2505 for the pro plugin. The free and pro plugin have a little more than 1600 strings in common. Which boils down to almost 65%. That means there is 35% of pro strings left to translate (Roughly 880 strings, which is a lot, but doable).
As soon as the Dutch translation for the free plugin is at 100% at translate.wordpress.org (currently 96%, so only 60 strings left to translate) I’ll be able to get the exact figures.
Once moved/merged there is still some work to do:
1. Translate the ~880 pro strings into Dutch.
2. Use a tool to generate the pro .json translation files from the completed pro .po translation file.
3. Actually test the Dutch iTSec Pro translation (.po, .mo and .json files) in WordPress.
4. Figure out how to offer translation updates for the iTSec pro plugin outside translate.wordpress.org (GlotPress).
I guess I’ll be busy this winter 😉
+++++ To prevent any confusion, I’m not iThemes +++++
- This reply was modified 2 years, 5 months ago by nlpro.
Ok, so that means the PHP mail() function cannot be used.
However the iTSec plugin uses the WordPress wp_mail() function to send emails.
And since the WordPress wp_mail() function normally uses the PHP mail() function to send emails it’s to be expected to receive the fatal error (unregardless of PHP version being used).
Only switching to sending emails using SMTP will prevent the error from occurring.
So basically IMHO this is not an iTSec plugin issue.
Hi manumr1991,
the PHP mail function is disabled for all PHP versions
How exactly is that done ?
+++++ To prevent any confusion, I’m not iThemes +++++
Hmm weird, works fine in my test environment. Any special chars in the “secret_token” string ?
Hi Jakub,
WordPress and iTSec plugin version ?
+++++ To prevent any confusion, I’m not iThemes +++++