Add second argument to wordfilter_filter_process()
| Project: | Wordfilter |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Please consider adding an optional second parameter $embedded (default value NULL) to function wordfilter_filter_process() to override the standalone settings of words in DB table. If !is_null($embedded), DB standalone settings of individual words should be ignored and all words should be searched for as embedded text in the target string.
This will allow the use of wordfilter_filter_process() by other modules in a simple and useful way for a variety of special purposes, for example, to check for unacceptable domain names, user names, user profile field values, etc., while leaving the standalone setting of a word unchanged in the DB for normal content filtering the way wordfilter does presently. This change causes no disruption to existing installs as far as I can see. See suggested code below.
function wordfilter_filter_process($text, $embedded = NULL) {
$text = ' '. $text .' ';
$list = _wordfilter_list();
$utf8 = variable_get('wordfilter_use_utf8_flag', FALSE);
foreach ($list as $word) {
// Prevent mysterious empty value from blowing away the node title.
if (!empty($word->words)) {
$replacement = ($word->replacement) ? $word->replacement : variable_get('wordfilter_default_replacement', '[filtered word]');
if (is_null($embedded) && $word->standalone) {
$text = preg_replace("/(\W)". preg_quote($word->words, '/') ."(\W)/i". ($utf8 ? 'u' : ''), "$1". $replacement ."$2", $text);
}
else {
$text = preg_replace('/'. preg_quote($word->words, '/') .'/i'. ($utf8 ? 'u' : ''), $replacement, $text);
}
}
}
$text = substr($text, 1, -1);
return $text;
}
#1
Patch attached. Slightly changed from above code. Optional second argument $embedded now has default value FALSE.
Any module can call wordfilter_filter_process and pass a string to check. If overriding the standalone flag of words in the DB table is desired, supply optional second argument as TRUE.
#2
Another idea will be to eliminate the wordfilter DB table and use a vocabulary to hold the words instead. This will allow structuring the list of banned words as a hierarchy and grouping together words into categories of profanity which in turn will allow producing cool audit listings of the categories of profanities found in content. Could be useful for large sites.
#3
#2 that sound interesting but perhaps could be best realized as a new module written from the ground up to do just that. How would you set the relation between the word to filter and the replacement word?