Forum Replies Created

Viewing 15 replies - 166 through 180 (of 224 total)
  • Probably – hopefully.

    Txanny was merely observing that by default new topics on plugins are posted in the Installs forum; I merely observed that that’s mainly because the drop-down menu to select the appropriate forum is practically hidden – which can be solved by putting it waaaaaaaay on top, above the text area field for the topic text itself, so that people are made aware of it.

    And, of course, setting the default selection to “plugins” would also help, but hey, I’m no coder so what do I know about these intertubes.

    Using Akismet together with Bad Behavior is a very good idea; they’re not only not biting each other, what’s more: the key author behind BB has a lot of insight in Akismet development, so they play nicely too. So, you did well.

    Other tip: make sure you have a valid HTTP:BL key to enter in BB (get one over at Project Honeypot) and return the love a bit to the community by using the WP HoneyPot plugin which helps tracking and flagging bad bots also for other users.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    Wow, thanks for replying Donncha!

    I think I’m onto the core of the issue: crontab permissions.

    As you could see from my post above, creating and deleting the files by the plugin (and WP) was not a problem. What baffled me was the absolute clockwork regularity of the warnings (every 15 minutes) which just didn’t make sense given the visitor-triggered garbage collection routine and I simply don’t think I have such a high and sustained volume of traffic to cause that. Besides, the collection routine doesn’t appear to be set every 15 minutes… Which got me on track of the crontab.

    Turns out, eons ago I gave a Fantastico install of WP a spin (yeah I know – fortunately I’ll try bad ideas only once) which I trashed pretty quickly – except I apparently overlooked that it left a residual cronjob in place (one for mail collection for mail submitted posts, another to hit the WP cron script) and that, unsurprisingly, runs every 15 minutes.

    No more: I’ve killed the two cronjobs, and also saw that there was a perms issue with the crontab manager, so I think that’s it.

    I’ll let you know within half an hour whether that cleared the problem (that’s when the error log should have entered another string of warnings – or hopefully not).

    Another for the bag of weird experiences to keep in mind I guess…

    Thanks so much, once more, for peeking in and letting me know that it’s the webserver which should have perms. That pointed me in the alternate direction, and hopefully the solution.

    The only issue I see is design/layout: the drop-down menu for the forum selection is at the very, very bottom. Could be situated in more visible real estate.

    Or, they could rename the plugin forum into the Nekkid Pictures Corner.

    On the upside, you can have your webpages in any color you like, and for Netscape Navigator users you can use nice <blink> tags, and they even have a special download accelerator for dial-up modem users.

    Yes, it works with 2.7.x and 2.8.x too.

    No, I’m not the author of WP-Honeypot.

    Ahem – this is what happens when you type faster than your eyes can check what you actually type: I was thinking about caching when I said “you’ll see a comment near the bottom” – oops!

    Bad Behavior does of course show up, but it’s higher up in the source code; you just have to search for the string “Bad Behavior” which would show, for the current version, something like this:

    <!-- Bad Behavior 2.0.28 run time: XX.XXX ms -->

    And then, of course, some Bad Behavior magic follows that bit. Bottom line, see the source code of your site to check whether BB is active.

    There’s a fundamental difference between blocking potentially harmful access attempts (e.g. bad bots) and blocking undesired traffic hogs (e.g. site rippers).

    Bad Behavior does a very good job on the first point; on the second, you could go, for example, either of these two routes:

    1. Edit the blacklist.inc.php file and add your unwanted UAs there;
    2. Edit or create a .htaccess file with the UAs you don’t want.

    However.

    Keep in mind that you are blocking traffic based on the user agent (UA) that is reported by the visitor; if someone were really to set out to overload your server with traffic (and/or drain your bandwidth) it’s not at all hard to spoof a UA to bypass your blocks.

    Bottom line: it’s annoying as heck to regulrly have critters who waste your precious bandwidth, but in the end, it’s a matter of balancing what you have (your means) with what you want. Often, simple solutions applied jointly give an adequate level of protection, with the added benefit of relative simplicity (at least you know where to look if you mess up).

    Things like anti-hotlinking (by protecting images and other media files, css and js files, etc.) are simple measures, that can be easily applied to your root .htaccess file.

    Just don’t think that you can cover all your bases, and certainly not completely – someone out to harm your site with the appropriate skills and determination will get through, eventually.

    Unless, of course, your angle really is intellectual property protection (again: you can either go with Bad Behavior or follow the .htaccess method for that – your call) site-rippers are in my opinion small fry, compared to others in the nasty jungle out there.

    Sidenote: please read this before posting plugin support issues in the WordPress Installation forum again…

    You can easily tell whether Bad Behavior works by looking at the source code of your page: if it does, you’ll see a comment near the bottom.

    Moving JS to the footer (e.g. by using Vladimir Prelovac’s solution to do that) often creates problems with plugins that don’t like to be moved from where the author puts them; it’s not a Bad Behavior issue.

    I can’t speak to Batcache specifically (you might check in with its author, the amazing Mr Andy Skelton) but I can tell you that WP Super Cache supports Bad Behavior quite well (it automatically detects its presence when both are active, you just need to activate their cooperation in the WP Super Cache options page).

    Drawback is that you won’t be able to use the extra oomph you normally get from Gzip compression – but that’s actually not a “drawback” but a logical and necessary trade-off between performance (WP Super Cache, or any other good cache plugin) and security (Bad Behavior).

    Bottom line: if you’re both strapped for resources and you have a lot of really nasty critters crawling over your site, there’s simply no way around upgrading your hosting package. That balance between performance and security is not a ‘flaw’ – it’s just what it is.

    Note: Batcache appears to be a relatively high-end solution for multiple-server setups, plus you have to ensure Memcache is supported. In other words, it’s not in the “simple plug and play” caching plugin category, which you probably already know – it’s just a cautionary remark for unsuspecting other users.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    Aha – thanks for confirming that, Paul; it turns out there was a problem; Link-summarizer v1.8.1 has been revoked by the author.

    More importantly, the workaround is indeed to roll back to v1.8 so at least we know we weren’t seeing ghosts or anything!

    As far as I’m concerned, this issue is now ‘resolved’ as both the cause and its immediate solution are known (i.e. the intended new release had mostly new features which undoubtedly will be addressed in an upcoming release).

    Case closed!

    Ovidiu said:

    […] I see a list with all bb logs, and there is a checkbox to select all logs, but then, the delete button is missing 🙂

    I have a l33t fix for that: using a permanent marker, I wrote the underlined word “DELETE” on my monitor, in the column header of the table. Now, I haven’t found the right CSS markup yet to change absolute to relative positioning, but it’s a start! I just move my monitor up or down when I scroll the BB page, and it’s full of win. Of course I personally don’t use the internets for anything else but checking out the BB logs, so your mileage may vary.

    Otherwise, for lazy cheating coders: you can apply the hack of just doing nothing, as the table is regularly purged already. Don’t take my word for it, check line 6 of housekeeping.inc.php for yourself… The purging interval is 7 days, i.e. independent from the timeframe you set in the BB settings page.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    Aha! Thanks to Jonathan Lundell’s tip posted at the Bad Behavior author’s site, the solution is not only available but also very simple to apply.

    Just go to line 114 of the file core.inc.php (it’s within the “secondary” plugin’s sub-folder, which is also named bad-behavior!) and substitute that line with the following:
    $_SERVER['REMOTE_ADDR'] = preg_replace("/^::ffff:/", "", $_SERVER['REMOTE_ADDR']);
    Problem solved!

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    Aha! Now that makes perfect sense. Thanks ljmac for clarifying things in a comprehensible manner for me!

    So back to “Resolved” this topic goes, again.

Viewing 15 replies - 166 through 180 (of 224 total)