Forum Replies Created

Viewing 10 replies - 16 through 25 (of 25 total)
  • Thread Starter Benny

    (@bvl)

    Sorry to see that the author hasn’t been responding to any questions and issues in the last months. Hope he is well and will be back soon!

    Anyway, I found the answer to my own question and I’ll post it here for others that might want to know the answer too:

    Instead of the code given by Knews you should add:

    #Begin Knews Pixel Tracker Rule (add this lines just after the RewriteBase line)
    RewriteRule .*files/knewsimages/([^/]+).(jpg|jpeg|gif|png)$ /wp-content/plugins/knews/direct/track.php?img=$1 [L,NC]
    #End Knews

    Hi amedeus,

    1. This sounds like the behaviour you get on a fresh WordPress install where of course only posts/pages will exist in the default language. If so, then please try to add a translation for the ‘Hello world’ post and see if you now can switch between languages. If you didn’t add a language switcher widget yet, you should add one to any widget area defined in your theme.

    2. If you want http://www.mysite.com/ as the home url (instead of http://www.mysite.com/en) you’ll have to add a check mark to the settings for “[V] Hide URL language information for default language” (see Settings/Languages,Settings tab, Url modificatins options)

    – Benny

    It is my concern that with this kind of hack people are blaming this plugin and think removing it is all they need to do to be safe again, while the real security problem *may* (in my opinion even more likely) be with another part of their system.

    Maybe we can agree that it would be best if both the plugin would get a thorough code and security audit AND people who ended up with a hacked ‘Limit Login Attempts’ plugin also seriously look at other possible origins for the hack, okay?

    😉

    The problem is that this plugin does not protect from brute force attacks coming from a bot-network with thousands of unique IP’s. It doesn’t matter if they all get blocked. There are so many that they potentially still can perform a successful attack.

    This would of course explain the continues emails wilcochris and Jessi are getting.

    IMHO, this all comes down to:

    1. the plugin itself does not suffer from a security breach and is safe to use
    2. some hackers seem to target this popular plugin to hide some malicious code in. They probably target another plugin on your system if you remove it.

    So, if you have been hacked this way, be aware that your site does suffer from a security breach, but it is unlikely that that is a leak inside the original plugin code.

    Hi Magistar,

    No, leave ‘my_ip_whitelist’ as is.
    But you do need to replace ‘my-ip’ with your actual IP (keep the single quotes though).

    The code behind this filter will check if the visiting IP is yours. If that’s the case, it will skip monitoring failed login attempts for that session.

    The 10 indicates the priority for running this filter and the 2 tells how many arguments are accepted by the my_ip_whitelist function.
    See: http://codex.wordpress.org/Function_Reference/add_filter

    – Benny

    Thread Starter Benny

    (@bvl)

    Great, that worked perfectly, thanks!

    The Front-end edit will suite many of our customers perfectly. Currently we remove many admin menu items and admin features for them (+ other customisations) en streamline the TinyMCE edit functions and set a editor style sheet. This makes it tremendously easier for them to manage their content and cuts greatly back on support. But this is not ideal; while the future with the Front-end editor is! … at least for that particular group of end users.

    I agree with others that there should be a new option in the back-end that gives the choice of enabling the front-end editor or not on a user or user role base. And preferably also a setting per user or user role that sets whether they can log in to the back-end or only to the front-end editor.

    [removed]

    I just installed your plugin and also stumbled on the max 10 posts limit.
    By adding 'posts_per_page'=>-1 to sitemap-template.php this was easy to fix though:

    $query_args = array(
    	'post_type'      => array( 'post', 'page' ),
    	'post_status'    => 'publish',
    	'orderby'        => 'date',
    	'posts_per_page' => -1
    );
    query_posts( $query_args );

    Cheers,
    Benny

Viewing 10 replies - 16 through 25 (of 25 total)