You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Output of "php flarum info", run this in terminal in your Flarum directory.
Possible solution(s)
Ideally, this should be fixed in Flarum.
Since CommentPost::setContentAttribute() sets the content attribute to null when falsy without going through the formatter parser, it would be logical for CommentPost::getContentAttribute() to also return null verbatim without going through the unparser.
In Flarum v2, the signature to $formatter->unparse has already been changed to only accept string, so the error will look different on Flarum v2 as it will error one step earlier.
No idea if this will warrant a hotfix on Flarum 1.8.x or if this will have to wait to be fixed in v2.
Additional Context
The error is triggered here but it happens as soon as $post->content is invoked, the code from FoF Filter isn't at fault.
Bug Report
Current Behavior
This is the problem being reported and discussed on the forums https://discuss.flarum.org/d/34454-every-day-there-are-some-discussions-only-have-title-no-content/11
If a user tries to send an empty reply, or a new discussion with empty body while this extension is active, a 500 error will occur.
Steps to Reproduce
bypassFoFFilter
permissionExpected Behavior
The behavior from Flarum isn't entirely clear here.
$post->content
should return eithernull
or an empty string. Definitely not an error.The extension uses the method "correctly" in that regard. It shouldn't error.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment
Possible solution(s)
Ideally, this should be fixed in Flarum.
Since
CommentPost::setContentAttribute()
sets thecontent
attribute tonull
when falsy without going through the formatter parser, it would be logical forCommentPost::getContentAttribute()
to also returnnull
verbatim without going through the unparser.In Flarum v2, the signature to
$formatter->unparse
has already been changed to only acceptstring
, so the error will look different on Flarum v2 as it will error one step earlier.No idea if this will warrant a hotfix on Flarum 1.8.x or if this will have to wait to be fixed in v2.
Additional Context
The error is triggered here but it happens as soon as
$post->content
is invoked, the code from FoF Filter isn't at fault.filter/src/Listener/CheckPost.php
Line 64 in 347c235
The text was updated successfully, but these errors were encountered: