How to set the maximum number of URLs?

No user interface has been built for this yet. Marking as a feature request.

Jeremy, has this feature been implemented?
I think Drupal really needs a module which block comments if it has more than N links.

Is 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?

look 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?

Here 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

You are absolutely right -- those variables should all be namespaced.

In 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.

gnassar: 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?

No, 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.

gnassar: 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.

Huh. 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_*.

Ok, 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?

Well, 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.

It's not a feature patch - the feature was already in the module. I just fixed it.

I'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.

True, true.. must have been confusing this with something else.

Now 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?

Yep, it already is, here: #544260: Namespacing for Sub-modules