Disregard my now-deleted reply. I found the issue.
To reproduce you need only FoF Filter and any extension that implements an unparsing callback like Mentions. Then try posting with an account without the bypassFoFFilter permission.
The problem isn't really caused by anything FoF Filter does. Really it's a Flarum issue.
The code I referenced earlier, that sets null on the content attribute when passed an empty string actually always runs, then the Saving event is dispatched, and only after that does the Flarum validator runs.
The error is thrown as soon as $post->content is invoked in the Saving event, because CommentPost::getContentAttribute passes the string|null content to the unparser, which expects string only.
Even if the issue was fixed in Flarum, there are still potential issues I see with FoF Filter:
Empty lines in the list of words don't seem to be skipped and they result in a censor rule that will match every time (//i).
The email for flagged content is sent synchronously inside the Saving event, before the post is saved to the database, meaning it will still go out even if another extension throws a validation error from a different event lister or from the PostValidator itself.
And finally, the use of preg_replace_callback in CheckPost::checkContent seems a bit unnecessary because the replaced result is not used for anything. But it's still a valid way to loop over a regex. But then in the callback there's if ($matches) which will always be true, in fact if it wasn't, the next line $matches[0] would throw. If using a loop or throwable, the loop could be exited as soon as $isExplicit becomes true since the code doesn't perform any other check.
