I encountered three reproducible issues while using the FoF Filter extension. These problems affect the accuracy of content filtering and allow certain permission bypass scenarios. Please review and fix them (code locations are noted below).
Overview of the issues
- Discussion titles are not filtered
Behavior: Sensitive words placed in a discussion title are not detected, flagged, or removed.
Relevant code: src/Listener/CheckPost.php — the current implementation only passes $post->content to checkContent (around line 70). The title of the first post’s discussion is never included.
Expected behavior: For the first post ($post->number == 1), both the discussion title and the post body should be checked.
- False positives: posts are filtered even when they contain no keywords
Behavior: Some normal posts are incorrectly flagged. Logs show that certain generated regex patterns are overly broad or malformed.The extension does not handle Chinese content well during filtering.
Relevant code: src/CensorGenerator.php — generateCensors directly inserts admin‑provided keywords into regex patterns ('/.../i') without using preg_quote, without the Unicode modifier /u, and without validating whether the generated pattern is safe or matches empty strings. The LEET_REPLACE logic at the top of the file also contributes to this.
Consequences:
Keywords containing regex meta characters become uncontrolled patterns.
Regex behaves incorrectly in multibyte environments, causing false matches.
Expected behavior:
Escape non‑alphabetic characters with preg_quote.
Enable /u for proper multibyte handling.
Validate generated patterns (skip patterns that fail compilation or match empty strings).
- Posts authored by admins or users with bypass permission may still be filtered after replies/likes
Behavior: When an admin or a user with bypass permission creates a post, that post may be re‑checked and flagged/deleted when another user replies or triggers a save event.
Relevant code: src/Listener/CheckPost.php — the bypass check uses $event->actor->can('bypassFoFFilter', $post->discussion), meaning it only checks the current actor, not the post author. When another user triggers a save, the author’s bypass permission is ignored.
Expected behavior:
First check whether the post author has bypassFoFFilter. If yes, always skip filtering.
Then check the current actor’s permission (to support admin edits).
I encountered three reproducible issues while using the FoF Filter extension. These problems affect the accuracy of content filtering and allow certain permission bypass scenarios. Please review and fix them (code locations are noted below).
Overview of the issues
Behavior: Sensitive words placed in a discussion title are not detected, flagged, or removed.
Relevant code: src/Listener/CheckPost.php — the current implementation only passes $post->content to checkContent (around line 70). The title of the first post’s discussion is never included.
Expected behavior: For the first post ($post->number == 1), both the discussion title and the post body should be checked.
Behavior: Some normal posts are incorrectly flagged. Logs show that certain generated regex patterns are overly broad or malformed.The extension does not handle Chinese content well during filtering.
Relevant code: src/CensorGenerator.php — generateCensors directly inserts admin‑provided keywords into regex patterns ('/.../i') without using preg_quote, without the Unicode modifier /u, and without validating whether the generated pattern is safe or matches empty strings. The LEET_REPLACE logic at the top of the file also contributes to this.
Consequences:
Keywords containing regex meta characters become uncontrolled patterns.
Regex behaves incorrectly in multibyte environments, causing false matches.
Expected behavior:
Escape non‑alphabetic characters with preg_quote.
Enable /u for proper multibyte handling.
Validate generated patterns (skip patterns that fail compilation or match empty strings).
Behavior: When an admin or a user with bypass permission creates a post, that post may be re‑checked and flagged/deleted when another user replies or triggers a save event.
Relevant code: src/Listener/CheckPost.php — the bypass check uses $event->actor->can('bypassFoFFilter', $post->discussion), meaning it only checks the current actor, not the post author. When another user triggers a save, the author’s bypass permission is ignored.
Expected behavior:
First check whether the post author has bypassFoFFilter. If yes, always skip filtering.
Then check the current actor’s permission (to support admin edits).