Closed (fixed)
Project:
Spam
Version:
6.x-1.x-dev
Component:
URL Limiter
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
20 Jan 2009 at 15:50 UTC
Updated:
9 Jan 2011 at 07:00 UTC
Jump to comment: Most recent file
Comments
Comment #1
jeremy commentedNo user interface has been built for this yet. Marking as a feature request.
Comment #2
Antinoo commentedJeremy, has this feature been implemented?
I think Drupal really needs a module which block comments if it has more than N links.
Comment #3
tamhas commentedIs this feature not working yet in the 6.x release? E.g., see http://drupal.org/node/419942
If it is working, but takes hacking to set the limit, might you point to where to do it?
Comment #4
naught101 commentedlook at /filters/url/url.module, from line 100. The code it already working on your site.
There are two variables, 'url_limit_total', and 'url_limit_repeat'. If those variables don't exist, the defaults are 10 and 5 respectively (ie. posts with 10 URLs or the same URL 5 times get marked). The default action is to to set the total to 99 (not sure how that works with the gain).
Both variables don't exist yet in the DB - I assume this is what Jeremy was talking about, a UI needs to be coded to allow people to put them in to the DB. Might also be good to be able to change the action to set a different value to 99. Probably not too hard, I might have a go at it.
Jeremy, shouldn't those variables have _spam_ in them somewhere, or something?
Comment #5
naught101 commentedHere y'all go. only on minor code change, and a couple of new functions for the form. Works for me. Please review and test.
Apply on filters/url/url.modules
Comment #6
gnassar commentedYou are absolutely right -- those variables should all be namespaced.
Comment #7
gnassar commentedIn fact, namespacing the variables lets you get rid of the submit handler altogether (see #351141: Only able to filter comments). I think it's probably cleaner that way.
Comment #8
naught101 commentedgnassar: any chance of getting the patch into dev? I just realised it wasn't included when I did the latest update.
Perhaps the namespacing of variables should be a separate issue?
Comment #9
gnassar commentedNo, the patch should probably have its variables namespaced correctly. That's all I meant. I was holding off on that to get it into dev. Sorry for the delayed reply.
Comment #10
naught101 commentedgnassar: now that I look at it, they ARE correctly namespaced... the module is just called "url"... that's a stupid name for a module though, perhaps all the sub-modules should be renamed to spam_submodule? That would change the variable names to spam_url_limit_repeat etc.
Comment #11
gnassar commentedHuh. You're right. All the submodules in the modules subdirectory are namespaced properly, but all the filters (which are also modules, of course) aren't. So, yeah, looks like we should be throwing the filters directory under modules, and renaming all the filters spam_*.
Comment #12
naught101 commentedOk, I don't even know if it's possible to create a patch that will rename files. Pretty sure diff can't do it... Even if there is a way, doing this will reset all filter variables on an upgrade (because they'll be renamed). Perhaps this would make for a 1.1 release?
gnassar, can you apply the patch as it stands, and after that we can open a new issue for correct module naming?
Comment #13
gnassar commentedWell, it's a feature patch, and the dev version is in code freeze pending release. So bug fixes only. This, along with the namespace fix and a few other feature patches in the queue, will go into a 1.1 release. The patch against 1.0 will remain here for those who absolutely need the functionality and are willing to try a patch that isn't RTBC yet.
On a side note -- diff will handle renames in a patch file. It'll make for a pretty big patch file -- it's a remove/add operation -- but it'll handle it transparently as long as you're diffing the directory tree (which you should be), and a big patch file never hurt anyone.
Comment #14
naught101 commentedIt's not a feature patch - the feature was already in the module. I just fixed it.
Comment #15
gnassar commentedI'll respectfully differ with you on that.
The feature you added was an UI to change settings for the URL filter. The URL filter itself is working. You didn't "fix" anything. There's no deletion in your patch, and no insertion into an existing function. You added another function -- effectively, you added an UI and made a value user-modifiable.
So, no, the feature this patch addresses is not "already in the module." Making that value user-editable is a feature. The module works without it; there's no "bug" to fix.
Like I said, this is slated for a 1.1 -- meaning this, along with the namespacing, can be included in dev right after we release 1.0, which is scheduled for the end of the month. Please just be patient. I do appreciate the patch, and I think it's very useful.
Comment #16
naught101 commentedTrue, true.. must have been confusing this with something else.
Comment #17
plj commentedNow we have that release: 1.0 is out, so there should be no need to postpone this any further. Reopening (and subscribing)!
Patch still applies cleanly against DRUPAL-6--1, but won't fix the namespace problem mentioned in #11. That problem, however, applies to all of the filters, so perhaps that should be a separate issue?
Comment #18
naught101 commentedYep, it already is, here: #544260: Namespacing for Sub-modules
Comment #19
naught101 commentedOk, here's the same patch re-rolled against the new sub-module name spacing (CVS 6.x-1.x-dev).
I've added the "Unlimited" urls option, the simplest way I could, and I've also added the option to change the spam probability. There doesn't seem to be any particular style for options for sub-modules, so I tried to emulate the ones that I thought made the most sense (See the custom and node age probability settings)
Happy to change things if needed..
Comment #20
pieterdcLittle syntax errors:
- there should be a ';' at the end of '$probability = variable_get('spam_filter_url_probability', 99)'.
- there should be 2 more spaces to indent 'return $action;' 1 "tab" further where you add it.
Apart from those details: I think it works.
Thanks for providing the patch.
I hope this gets committed soon.
Comment #21
pieterdcI'll make it a little easier for you guys.
Adjusted and tested patch attached.
Comment #22
rares commentedany chance this can get implemented in the dev branch?
Comment #23
gnassar commentedThanks, guys. Great work. Committed.
http://drupal.org/cvs?commit=469622