End-User Options - User Optional Word Censorship

User Optional Word Censorship

What this hack does

The default censorship options in VB are all or nothing, in other words it is either enabled or disabled for all users regardless of their personal preference. Without any additional SQL calls and an extremely low runtime impact (on top of the resource usage required when using the censor in the first place), this hack gives the user the option to view your forum with the AdminCP configured censor switched on if you have it enabled.

How to install

In summary the install requires:

• Around 2 minutes.
• 1 file change.
• The addition of a custom user profile field.
• A basic understanding of PHP.

So this is what you need to do:

First create a custom user profile field:

1. Log in to your AdminCP.
2. Goto "User Profile Fields -> Add New User Profile Field"
3. In "Profile Field Type" select "Multiple-Selection Checkbox" and then click "Continue"
4. In "Title" enter "Enable word censor" *
5. In "Description" enter "If you choose to enabled this option all words on the current censor list will be replaced with * characters" *
6. In "Options" enter "Enable censor" *
7. Set "Private Field" to "Yes"
8. Set "Field Searchable on Members List" to "No"
9. Set "Show on Members List" to "No"
10. Set "Display Page -> Which page displays this option?" to "Options: Other"
11. Click "Save", this will then take you to a page that summarises all current profile fields.
12. On this profile fields list find the one you just added and take note of the "Name" value. Typically this will be somthing like "Field5".

* These options set the text that is displayed to the user, feel free to customise/change these to whatever you want.

All the AdminCP work is done now, so if you want logout. The next step is to make a small file edit, to check this field value when VB calls the censor code.

1. Take a backup of "includes\functions.php" just incase something goes horribly wrong.
2. Open the "includes\functions.php" file in your favourite text editor.
3. Find the following lines (typically these are around line 545):
   
   

   if ($vbulletin->options['enablecensor'] AND !empty($vbulletin->options['censorwords']))
   {

4. Immediately after the lines above (i.e. after the {) add the following code:
   
   

   if ((isset($vbulletin->userinfo['field5'])) && ($vbulletin->userinfo['field5'] != 1))
   {
   	return $text;
   }

   You should end up with something that looks like this:
   
   

   if ($vbulletin->options['enablecensor'] AND !empty($vbulletin->options['censorwords']))
   {
   	if ((isset($vbulletin->userinfo['field5'])) && ($vbulletin->userinfo['field5'] != 1))
   	{
   		return $text;
   	}
   	
   	if (empty($censorwords))

5. Now this is probably the most complicated part of this simple install. Remember when you setup the profile field and you took a note of the "Name" value? Well in the text you just pasted into the function.php file you need to change this:
   
   

   if ((isset($vbulletin->userinfo['field5'])) && ($vbulletin->userinfo['field5'] != 1))

   To match the name of the field, so for example if your field name is "Field12", it would look like this:
   
   

   if ((isset($vbulletin->userinfo['field12'])) && ($vbulletin->userinfo['field12'] != 1))

6. Save the file, and upload to your server.

The last, and most critically important step is:

1. Click Install

All done, sit back and relax

Footnotes

By default the censor will be off for all users, so they will have to change their profile in order to enabled this. I could not find a way to create a profile checkbox field that is checked by default, and describing how to run SQL scripts to set the field value is more complicated than I wanted to go with this simple hack. So if anybody knows how to do this post the details and I will update the article. In the meantime a simpler option (rather than playing with the DB) is to use "Yes" / "No" radio buttons and set the default value to Yes (or no if you prefer). If you do this you will also have to subtly change the code above from:

if ((isset($vbulletin->userinfo['field5'])) && ($vbulletin->userinfo['field5'] != "Yes"))

to:

if ((isset($vbulletin->userinfo['field5'])) && ($vbulletin->userinfo['field5'] != "Yes"))

[Brittany]

works in 3.8 just fine!

[Feign]

I like this mod. Very simple and easy to control.

The only thing I don't like is the case sensitivity of the censored words, but I guess that's an issue with the stock vBulletin censor?

[steeler7]

Anyone ever try or get this to work with 3.8? I just tried to install.. no error messages or anything but nothing works unless I have the VB censor list on which seems to be backwards from what this mod said

[Carly]

This didn't work for me in 3.8.2 -- it wasn't retroactive and it appears that it worked backwards. It seems that if Member A had the censor on and Member B did not, if Member A posted a censored word, it appeared censored to Member B (even though Member B didn't want the censor). If Member B posted a censored word, Member A would view it in its full glory (even though Member A *wanted* the censor). Totally backwards.

[crs6785]

Originally Posted by Carly

This didn't work for me in 3.8.2 -- it wasn't retroactive and it appears that it worked backwards. It seems that if Member A had the censor on and Member B did not, if Member A posted a censored word, it appeared censored to Member B (even though Member B didn't want the censor). If Member B posted a censored word, Member A would view it in its full glory (even though Member A *wanted* the censor). Totally backwards.

The reason that happens is because of how caching works and the way censored posts are added to the DB. If Member A has the censor turned on and creates a post, then the post is actually censored before it is written to the DB. Same for the cached part of the post that goes into the postparsed table in the DB. So in the same respect, if Member B has the censor disabled and creates a thread, then the uncensored thread will go into the cache as well, which I don't believe is censored again when it is retrieved (defeats the purpose of the cache, eh?), which means that Member A will not get the text censored if it is retrieved from cache.

The only way I've found to get around such behavior and make a user based censorship mod work is to globally disable the censor so all text is written to the DB uncensored and then selectively enable the censor (via hooks) when they view certain pages. This requires a lot of plugins in various spots to catch things that should be censored.

A real solution for user based censorship is going to need a rethinking of the way censorship is done in general and how it works with caching.

[sully02]

Any chance this can be updated for 4.x?

I'm sure there are some folks who could use this aside from me.