Thanks for the numbers, gives me a warm fuzzy knowing that I might be p*ssing off at least one spammer. Maybe he might get so depressed at not being able to register and will just kill himself, fingers crossed

vBulletin works without javascript and this would block everyone using NoScript in Firefox (like myself, I wouldnt be without it). Ill put it in the bugtracker as a "maybe feature" for a future release though, maybe with a notice in the new user that says "Javascript is required for this registration" where isubmit button disabled by default, javascript used to enable it and with javascript used to make a form value. That would give fair warning to users with javascript disabled etc (personally, I HATE websites that refuse to work with javascript off and prefer not to use them)

I hope you think about server load for Big Boards to only user the code where really needed ;)

Yup, certainly have. Currently (and I dont imagine its going to change much), it uses two hooks that are hit on each page, global_start and cache_templates.

global_start is used to test if the page is member.php and then inserts a menu item into the options_postbit, that is one or two conditional checks. Firstly, it checks if its running 3.6.x as 3.7.x doesnt have the options postbit menu (3.7 has user details page load as a profile block instead).

cache_templates is used to check if the page is showthread.php or misc.php and then tells vbulletin to insert the "left click username context menu" postbit or the new user detail templates into the cache. A lot of mods do this and it shouldnt impact performance at all.

Once in the cache, vbulletin and any accelerators, will take care of that. Template checks shouldnt be a hit at all, but thats the price to pay for auto template changes.

I dont have a large board to test it against but Im open to suggestions

Ok, thanks.

I can test it on our boards, you see the microtime in the footer.

You can from the search page. This one goes back to a better API being in place.


Congratulations :) This could be done manually for the time being, and wouldn't kill anyone's session that way. The suggestion is meant to be run after the fact. I'm just seeing correlating spammer info in my logs, and want to help flesh out the spammer patterns :)


Definitely wait for a better API from the site :)


Take your time man, we all appreciate the work you're doing! :)

yeah, parsing HTML that could change at any time, is a real horrible way to get reliable information

One question: Where can I see this part?
Is this on a user's profile page or...?
I edited the rights for my admin group to yes.

You cant and you wont be able to do that until v0.7 and then it wont be with the XML postbits.

The code that I have now is displaying all this information but I need to complete more code before I release it.

ok, I see - no problem.

So interesting change of events, the past couple of days have been very quiet from a SPAM registration stand point. I have, however, started getting a few spam messages through the contact us form.

This leads me to the request of a modification:

Optional settings to check SPS on:

* Contacts

and for folks that were deemed good during registration, but were sleepers:

* Posts
* PMs