Forum Replies Created

Viewing 15 replies - 46 through 60 (of 224 total)
  • Afterthought: I hope you didn’t put your own IP address in the blacklist field of AFDAS. It’s a very long shot, considering you’re aware that your ISP uses dynamically allocated IP addresses, but that’s another surefire way of getting AFDAS to tell you to talk to the hand. There’s one way to find out if you’re locked out by AFDAS: go in with FTP, rename (don’t delete) the AFDAS plugin folder, then log in – your AFDAS plugin will be deactivated after its location has been renamed – and then delete it from the Plugins page in the wp-admin section. Then, reinstall it again, and make sure you don’t exclude yourself.

    As I said: it’s a long shot but at least we have all bases covered.

    Finally, before I forget: don’t forget to show your appreciation for anti-malware plugin developers to them, just as for WP and other open software developers in general. All that hard work and little but complaints in return make a darn lousy motivational appeal to them to continue their hard work. Throw them a few coin if you can.

    • You are posting a request with a topic label set in relation to the AVH First Defense Against Spam (AFDAS) plugin.
    • Your issue is not due to a malfunction of the AFDAS plugin; in fact, it is because you activated the so-called Third-Party remote blacklist option.
    • I can assure you that both the http:BL blacklist (of ProjectHoneyPot) and the StopForumSpam blacklist have a good delisting procedure, doing their level best to weed out false positives.
    • It depends entirely on the code shown to you (you can look yourself up in the Project Honey Pot site; just punch in the IP address that got you locked out) what the reason was for the lockout. (Edited to add: you can also look up your IP at the StopForumSpam site of course.)
    • If it is IP address related, time will heal all wounds. Eventually the time-out for that IP will expire, unless it is caught reoffending. Usually though, a faster method is to simply use a clean ISP provider, preferably one that actually responds to abuse reports.
    • If it is behavior-related, just stop it. If you didn’t cause it voluntarily, then quadruple scan and check all your systems hooked to the internet via that IP address. Then check them again, and don’t trust a 13-year old housemate’s word for “not having installed anything out of the ordinary.” If you didn’t deliberately exhibit the blocked behavior, odds are that you have malware, or worse, putting you at the mercy of international criminal organizations.
    • If you encounter a less than impeccably mannered system and site administrator, especially one that is fending off all sorts of @#$% thrown at his/her site, look past the gruff attitude and connect to a point you should have in common: a profound dislike for spammers, botnets and skiddies. I bet that “even” the SFS admin, Pedigree, will warm to such a positive attitude.
    • No offender is blocked “unfairly.” There could be unwitting attackers and ill-behaved netizens. But with http:BL and SFS I can assure you that the ratio of good kills versus false positives is so astronomically high, that you can use it as a badge of honor.
    • ISPs are not “bad” just because they share IP addresses; they become known as filthy ISPs when they don’t take action after report upon report. To give you two examples, the companies that are former state-owned / operated phone companies in Spain (branched out all over Latin America) and in Italy are notorious for their lax attitude. Hence, they are on a very short leash; their customers are learning the hard way that the internet is shrinking to them. Eventually money talks louder, so they’ll catch up eventually. Yet there are tons of “good” ISPs out there that use a sharing or pooling system of their limited IP address space. Even AOL, although they are a separate case of trouble for reasons that go to far here.
    • Overall, I sympathize. It’s not a very nice experience to get a page shoved in your face that says “We don’t want you in here.” But please realize that this is a result of a problem that has grown far past pandemic proportions, to one that is a real threat to free expression world wide. And so, please bear with the efforts to clean up the internet, alternatively to shrink it to the exclusion of the @#$% heads out there that cost all of us system and site admins tons of time and money that we rather spend on creating content.
    • Contact them – SFS or PHP – via a different ISP; make sure you provide the dates, times and the IP address you used, so they can look into it. Knocking on their door with anything less is an invitation to get a more or less polite variant of “go away”.
    • The only thing ridiculous here is that skiddies, botnets and spammers aren’t prosecuted like the terrorists they are. Here in the US where I am now, you get in worse trouble for opening someone else’s ordinary mailbox. Also ridiculous: software / IP piracy, driving traffic to criminal sites where malware greets the unsuspecting albeit somewhat naive surfer expecting free lunches. And finally, not educating fellow WP netizens on how to secure their websites with a wee bit more than just the Akismet plugin, that is ridiculous too. Mind you: Akismet is a truly fantastic and highly recommendable plugin – no disrespect whatsoever intended, quite the contrary. I mean that site security is a complex discipline, requiring different tools and patches and solutions applied simultaneously. Ridiculous or not, that is the world we live in. You’ll face the same with any of the “Big Scripts” out there; WordPress is no exception to that.

    Good luck.

    No, I mean server-side caching: do you have a caching plugin active, throwing out a stale page? Else, I have to defer to others…

    Caching issue?

    Dunno – this is a weird one to me… It works fine in a 3.0.5 and a 3.1 site for me.

    Hi Richard – there’s a very simple reason I went in both feet first. I’ll use someone else’s apt words pointing at the heart of what sparked the intensity of my ire:

    That was discussed, ad naseum, months and months ago.

    In other words: this is a bug-feature that was browbeaten into release its current form. Deal with it. STFU already, it’s a done deal. Something like that.

    Since discussion “ad nauseam” among a crowd of (no pun intended) enlightened and intelligent devs didn’t lead to a sensible outcome, that’s why I thought a change in volume and tone might be helpful to drive the message home: do not want. Not with those default settings, not with that curious design of per-user settings.

    Bottom line is: you and I both agree on the premise and nature of the problem as we see it. We both recognize the admin bar as a concept is by any means a useful idea (in essence, a UI tweak to facilitate site management, and what’s wrong with that?) but sadly it was implemented horribly. Putting it into release with the current default setting (i.e. visible out there) is insensitive. Period. Again, that’s the particular aspect of tactlessness that worked as a proverbial red cloth on this bull: it’s done, deal with it. That’s what annoyed me into gruff mode. Now, all that Monday self-quarterbacking aside, it’s still troubling that it was put out the way that it was. Yet as some others already have said: it’s a bug-feature here to stay, so let’s suck it up.

    Apparently, your fundamental (and righteously asked) question about who should really be in control of the site doesn’t matter much; it’s a developer-driven world, so we might as well get used to it. Even though it begs the question if there isn’t a better way, a more efficient way to test developer brilliance in the cold waters of humble and quasi illiterate real-life users, before certifying it as the outcome of some election.

    (Oh, and: you’re 100% about putting the admin bar killer in the child theme’s functions.php – I was sloppy.)

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    Just to close this one down: after looking into Ozh’ plugin (Ozh, you really rock) I realized that the whole admin bar is in fact switchable with a single, simple line for a filter, which if included in the theme’s function.php file will kill the admin bar full stop, no plugin necessary.

    Just add the following line, somewhere into the functions.php file of your theme(s):

    add_filter( 'show_admin_bar', '__return_false' );

    And gone it is.

    And yes, this is exactly what Ozh’ plugin does too, except this method is a hack of the theme to make sure it’s permanently gone, regardless of whether your plugins are activated or not.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    (OK, just having a bit of lighthearted fun here…)

    That was discussed, ad naseum, months and months ago.

    So the dark side won, huh…

    (ducks and runs)

    A bit earlier, you made an interesting suggestion. That may be an avenue; I don’t know how practical it would be. But it’s an idea.

    Thing is, the line between “functionally reasonable” and “unacceptably intrusive” is very blurry.

    E.g., and just as one fairly obvious example: the WP Stats plugin doesn’t “just” embed its own, obviously necessary JS calls home. I’ve also noticed calls to the QuantCast service, and I think that’s perfectly legit for several reasons (e.g.: as a data integrity fall-back or back-up, or to provide a symbiotic service to the QC people so as to tweak their code logic to improve metrics accuracy for WP sites, etc.) This is in my view a “functionally reasonable” instance. Perhaps I could pick a nit over “disclosure” (which really isn’t that nutty an argument, i.e. why would Google be “bad” yet QuantCast not?) but overall, in that case it’s still an acceptable instance.

    Also: while Google due to its sheer gargantuan size inspires a lot of apprehension, I think the “little” bugs out there are the more troubling ones, just because they’re much less visible than Google’s. And it’s even a security consideration, to not foster a plethora of bugs planted in the WP repository so I’m actually glad to see WP is aggressive about pursuit of the “unacceptably intrusive” cases.

    My point here is that it’s nonetheless hard to make clear distinctions in general… It’s a case-by-case evaluation, almost necessarily. And so it’s up to the community to flag the suspect cases.

    I’m with Ipstenu on this.

    Interesting because I just spent some time arguing a bit in a remotely related back-and-forth, over a new WP feature that in my opinion is “in your face” and yet here I am, defending relatively assertive reminders to donate by developers.

    The team of WordPress “core” developers and the legion of plugin developers out there, who have the fruits of their hard labor shared with the world via the canonical WP plugin and theme repository do that for free.

    Some developers also have a “premium” version, requiring some moolah to switch on extra features. Many have requests for donations, with a link. And yet many, many more are offered without even that. And on the other hand, those who require a paid license are not (anymore) in the open repository. And that’s a good system, I think.

    I have no problem with “obtrusive” requests for donations. I do have a problem with “spyware” – i.e. plugins that have e.g. an image bug in them specifically for tracking purposes – and that is also where I think WP draws the line for inclusion in the repository.

    Absent that, it’s a free world. Just as in theory I could stomp my little feet and move to different CMS (which I won’t; WP is near-perfect in my opinion) people are free to not use a certain plugin that “just” begs for money to compensate the hard work put in by the developer.

    Heck, I think there should be a WP donation button for those inclined to support WP, in their tireless efforts to offer more and better options to do what you do with “their” software. But a more or less aggressive request for donations? If – and that’s the key – a donation “gets rid” of it, I believe that’s a fair and acceptable practice.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    Otto, the problem is that it’s switched on by default. How is it more logical to have it switched off in the dashboard but not when viewing the site? If not having it on in the dashboard (and by the way, I agree that that’s a good default) then it shouldn’t have been on on the outside either.

    I suppose I understand the rationale behind that, though: it’s a simple way to “advertise” the new feature, and then people can always opt to switch it off. It’s just that this addition is very much “in your face” and although it’s great that one developer saw fit to release a plugin to switch it off – one per site, sadly not really globally – is not a “friendly” approach.

    That’s all… I don’t think there’s much point in rehashing this; I just see it as a nuisance, and I readily accept many will think it’s neat. Again, this is the internet.

    Edited to add: and that includes my not further engaging back-and-forths on the merit of my criticism here by itself, ClaytonJames. You have your obviously respectable opinion; I don’t think we’ll reach an agreement here just by denying or repeating what’s already been said.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    Awesome. Criticism of criticism. This must be the internet.

    But a plugin to defeat a feature, instead of switch and making it thus optional? Doesn’t sound logical to me.

    Then again, this is the internet.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    (edited afterward: I’m referring to Otto, just to clarify…) I’m glad you thought better of closing this topic: look at the front page of the Forums, under the Requests and Feedback you’ll see “– Feature requests; criticism.”

    And that’s what this is.

    Criticism.

    Which arguably is unpleasant for those who spent a lot of otherwise appreciated time on developing WP, but that’s how the cookie crumbles. Not all creations are as felicitous as they are laborious to implement.

    Thread Starter Alvaro Degives-Mas

    (@nv1962)

    That’s 60 seconds I prefer to spend elsewhere.

    And you’re kidding, right? A “feature” that requires a plugin to get rid of it? What kind of “solution” is that?

    It’s a ridiculous, unnecessary and brainless addition, and for those who perhaps see some purpose in it, it shouldn’t have been switched on by default.

    I’ve gone through many iterations of WP, with some innovations more useful than others since the 1.5.x series; this one beats ’em all in perfectly useless irritability.

    Oh, I solved it more trivially: just back-grade to WP3.0.5 – no extra and inherently redundant overhead causing plugin needed.

    Problem solved! 🙂

    As I also noted in a topic directly asking for a recall of that ridonkulous thing: it’s an abomination and it must go.

Viewing 15 replies - 46 through 60 (of 224 total)