Skip to content

[2.x] fix(formatter): handle null content in HasFormattedContent and mentions unparsers#4452

Merged
imorland merged 2 commits into2.xfrom
im/fix-4416-null-content-formatter
Mar 15, 2026
Merged

[2.x] fix(formatter): handle null content in HasFormattedContent and mentions unparsers#4452
imorland merged 2 commits into2.xfrom
im/fix-4416-null-content-formatter

Conversation

@imorland
Copy link
Copy Markdown
Member

Summary

Port of the 1.x fix (#4059) for issue #4416.

When a Saving listener reads $post->content and the content attribute is null (stored as such when an empty string is submitted via setContentAttribute), PHP throws a TypeError because the getter and formatter methods only accepted non-nullable strings.

The 2.x fix covers more of the call chain than 1.x because the PATCH response serialises contentHtml (calling formatContentrender), which 1.x never hit since validation rejected empty content before saving.

Files changed:

  • HasFormattedContent::getContentAttributestring → ?string, null guard
  • HasFormattedContent::getParsedContentAttributestring → ?string
  • HasFormattedContent::formatContent — early return '' if content is empty/null
  • Formatter::unparsestring → ?string, null guard
  • UnparsePostMentions / UnparseTagMentions / UnparseUserMentions?string + null guard on __invoke
  • UpdateMentionsMetadataWhenVisible — null guard on parsed_content before Utils::getAttributeValues()

Fixes #4416

Test plan

  • New regression tests pass: CreatePostWithEmptyContentTest, EditPostWithEmptyContentTest
  • Full mentions integration suite passes (78 tests)
  • Register a Saving listener that reads $event->post->content, submit a post with empty content — must not 500

🤖 Generated with Claude Code

imorland and others added 2 commits March 15, 2026 07:36
…ns unparsers

Port of the 1.x fix (#4059) for issue #4416. When a Saving listener reads
$post->content and the content attribute is null (stored as such when an
empty string is submitted), PHP would throw a TypeError because the getter
and formatter methods only accepted non-nullable strings.

Changes:
- HasFormattedContent::getContentAttribute: string → ?string, guard null
- HasFormattedContent::getParsedContentAttribute: string → ?string
- HasFormattedContent::formatContent: early return '' if content is empty
- Formatter::unparse: string → ?string, guard null
- UnparsePostMentions/UnparseTagMentions/UnparseUserMentions: same guard
- UpdateMentionsMetadataWhenVisible: guard null parsed_content before
  passing to Utils::getAttributeValues()

The 2.x fix covers more of the call chain than 1.x because the PATCH
response serialises contentHtml (calling formatContent/render), which
1.x never hit since validation rejected empty content before saving.

Fixes #4416

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@imorland imorland changed the title fix(formatter): handle null content in HasFormattedContent and mentions unparsers [2.x] fix(formatter): handle null content in HasFormattedContent and mentions unparsers Mar 15, 2026
@imorland imorland added this to the 2.0.0-beta.8 milestone Mar 15, 2026
@imorland imorland marked this pull request as ready for review March 15, 2026 07:38
@imorland imorland requested a review from a team as a code owner March 15, 2026 07:38
@imorland imorland merged commit b0913b9 into 2.x Mar 15, 2026
27 checks passed
@imorland imorland deleted the im/fix-4416-null-content-formatter branch March 15, 2026 07:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[2.x] Reading $post->content in saving listener throws error if content is empty

2 participants