User-Configurable Censorship Options

[futureal]

I definitely have the patience to go through and find the things to change, that's not a problem at all. I just don't have the PHP/MySQL knowledge to do the part that would involve setting up a per-user configurable censor-list. In theory, it would be a setting with three options:

No Censor
Censor Default Words
Censor Custom Words (instead of OR in addition to default words)

If somebody could come up with that much of it, I think I could (probably) do the rest (the tedious stuff) and hopefully lear something in the process.

Any takers?

[Xenon]

No Censor
Censor Default Words
Censor Custom Words (instead of OR in addition to default words)

this options would be very easy if you chose one part at the last option: instead or in additon. if you want to let users also choose that, you'll need 2 additional fields un the usertable, if you choose it for the user you need just a small edit in function.php, in member.php aother small edit, and adding 1 new field to the user-table.

if you want to do so, i can code the changes for you

[Smoothie]

This would be quite interesting.

[futureal]

Originally posted by Xenon
this options would be very easy if you chose one part at the last option: instead or in additon. if you want to let users also choose that, you'll need 2 additional fields un the usertable, if you choose it for the user you need just a small edit in function.php, in member.php aother small edit, and adding 1 new field to the user-table.

I don't mind the two additional fields at all. I assume you'd need one int field to select between the 3 (actually 4) options, and then one *?* field to contain a list of words.

Then the hack can use the original vBulletin censor list as the "default" list.

Once all of that is in there, it seems like it should just be a question of rearranging the censor code from before-insertion to on-the-fly.

I was thinking a little bit more about any performance issues, and since it seems to me that only a small percentage of users would actually use the censor, and we only need to do on-the-fly censoring for those that have it active, there really should not be any sort of performance hit. It's just one more option that should really enhance things for those who do not want to see the vulgar side of things, and for fed-up moderators who just can't read every word of every post.

[Xenon]

actually just two options for the int field (more likely it a binary then )
yes/no code to that question: additional use default censoringwords?

if a user select no, and has no words in his censorword list, then it'll be like no censoring , if he has words in it, it'll be like just censoring his words.
selecting yes with no words is default censoring and selecting yes with additional words is censoring default words and user words.

ok, make new fields to usertable called censoroption i'd say tiny int and field censorwords varchar(250) or how much you want

open functions.php
find this code:

PHP Code:

global $enablecensor,$censorwords,$censorword,$censorchar; 


in section strat censortext

replace it with

PHP Code:

global $enablecensor,$censorwords,$censorword,$censorchar,$bbuserinfo;

if($bbuserinfo[censoroption]==0) {
  $censorword=$bbuserinfo[censorwords]; 
} else {
  if(trim($bbuserinfo[censorwords]!="") {
  $censorword.=" ".$bbuserinfo[censorwords];
  }
} 


then all you need to do is to add the yes/no code and an inputbox for the censorwords to the user-cp and add that values to the database (editing member.php)

[FASherman]

Has anyone gotten around to making this a formal hack yet?

[TruthElixirX]

THere is one already, but it has screwed up my tables and colors on my site. I've been lookngi for another one but none have shown up.