FYI in case anyone else thought this was a vBulletin bug
 

Reply just in from vBulletin support, and are those folks getting fast on the answers :)

Some one was asking my advice as to whether or not this was a possible bug in vBulletin before purchasing. Thank fully l can say it isn't and just posting it in case other's have read the message on the net and were wondering.

HTH.

It can break custom hacks that expect specific usernames or userids; also, for example, the tables userfield, post, thread, privatemessage, mailmessage, mailfilter, mailfolder, mailab, etc.

edit: stock vB doesn't have a problem (except when just deleting a row from the user table), but hacked vBs, which many people, including myself run, don't always integrate with vB's user deletion system. So you're fine if you want to use stock vB :)

Custom usernames or userids, gee some people need to go back to college and learn about not hard coding information into software. Thank fully the 60 or so hacks we use, don't cause this problem, but then again we have some mighty fine php coders on the team (this doesn't include me, l'm technically lame).

So, do you expect people to create a database field for every tiny hack they make? I don't think so.

And, for the record, I can't go back to college, considering I am still in high school.

Maybe you're misinterpreting what I meant; I mean that some rows reference nonexistant userids in some tables (other than user, of course). As such, strange things could happen when those userids are further queried to get username, styleid, etc.

I'm not sure what you are on about here. We have added exactly two table fields in the course of development. Hard coding what should be variable data is considered extremely bad coding practise in any language. Do some reading as to the reasoning behind it :) I would suggest some of Fabian Pascal's stuff, who's one of those relational db experts that keep us all informed of normalisation, though l am at a bit of a head scratching stage with seventh normal form. Don't know, if some one else could explain it that would be cool.

Hey when you graduate go to college young man. Keg parties and co-eds and all that....

Should add thread was only started as a response to a question and through Jelsoft's answer to it.

The offending statement should perhaps be changed to reflect the true situation rather than being able to be misconstrued as meaning there is a problem in the underlying vBulletin software.

As I've said, stock vBulletin doesn't have a problem.

Let me put the analogy a different way; in my webmail hack, there's a mailmessage table with a column, among others, of userid. This column obviously stores the userid of whom the message belongs.

Now if the user was deleted via vB's user deletion system, the user/userfield rows would be deleted and all posts set to guests (not sure how PMs are handled). However, in my hack, the rows with that user's userid would still remain. The results could be unpredicable, from either just junk taking up space in the database, queries failing when trying to join data between tables, or some other bizarre problem.

Virtually every type of hack like my webmail hack--i.e., a hack that stores data per user--is affected by this problem. :)

If all of the user's data, that includes any PMs, posts, etc that they may have, is deleted via database queries, there should not be any problems.

Filburt, it's as simple as running a simple MySQL query to delete rows with that user's userID. Any admin that knows their way around VB, PHP, and mySQL should have no problems whatsoever. :)

I know. But, as I'm reiterating for the third time, most hacks that are in the data-per-user genre do not integrate with vB's user removal system and therefore are not cleaned up when a user is deleted.