Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[likes] Don't send liked notification for posts without plain content. #4095

Conversation

YUCLing
Copy link
Contributor

@YUCLing YUCLing commented Oct 25, 2024

Fixes #0000

Changes proposed in this pull request:

Don't send liked notifications for posts that don't have plain content.

In this approach, the extensibility of the Likes extension won't be reduced. Since it allows all other post types to be liked, it also keeps the original notification ability from the Likes extension for all other post types that contain valid plain content.

Reviewers should focus on:

Screenshot

Necessity

  • Has the problem that is being solved here been clearly explained?
  • If applicable, have various options for solving this problem been considered?
  • For core PRs, does this need to be in core, or could it be in an extension?
  • Are we willing to maintain this for years / potentially forever?

Confirmed

  • Frontend changes: tested on a local Flarum installation.
  • Backend changes: tests are green (run composer test).
  • Core developer confirmed locally this works as intended.
  • Tests have been added, or are not appropriate here.

Required changes:

  • Related documentation PR: (Remove if irrelevant)

@YUCLing YUCLing requested a review from a team as a code owner October 25, 2024 05:55
@@ -22,7 +22,7 @@ public function __construct(

public function handle(PostWasLiked $event): void
{
if ($event->post->user && $event->post->user->id != $event->user->id) {
if (gettype($event->post->content) == 'string' && $event->post->user && $event->post->user->id != $event->user->id) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • It would be better to do an exact === comparison while using comparisons like these
  • Instead of using gettype, just using the php is_string() method would probably be sufficient, it also reads better instead of seeing a 'string' for something that is a native php type

My biggest gripe with this is however that there's no guarantee whatsoever that content is going to be just post body; what I would probably do is:

Suggested change
if (gettype($event->post->content) == 'string' && $event->post->user && $event->post->user->id != $event->user->id) {
if ($event->post->content instanceof CommentPost && $event->post->user && $event->post->user->id != $event->user->id) {

Now this gripe is based on the idea that notifications for likes would only be sent for posts that have readable content, but it would probably be better to completely separate the logic into a "Post Types that send Notifications" logic, so that it becomes flexible enough for extending; what do you think @flarum/core ?

@luceos
Copy link
Member

luceos commented Nov 13, 2024

So the issue here is:

Liking any other Post type than CommentPost is causing issues with notifications.

The PR #4075 relates to this exact issue as well.

What I think should happen is create an extensible layer by adding a property to the implementation of every Post type, eg CommentPost that indicates whether notifications should be sent.

I'm closing this PR and the other one and will create an issue to explain further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants