I'm developing a trader feedback extension for Flarum 1.8 and facing issues with the notification system. While the notifications are being created in the database, they're not being delivered to users properly. @Sami SychO @clarkwinkelmann Extension Details: Extension name: huseyinfiliz-traderfeedback Flarum version: 1.8.x PHP version: 8.1 Github: huseyinfiliz/traderfeedback The Problem: I have three notification types: newFeedback, feedbackApproved, and feedbackRejected Notifications ARE being created in the database with correct data The newFeedback notification sometimes works, but feedbackApproved and feedbackRejected never appear in the UI No errors in logs, no JavaScript console errors Current Implementation: extend.php: // Notification registration (new Extend\Notification()) ->type(NewFeedbackBlueprint::class, BasicUserSerializer::class, ['alert']) ->type(FeedbackApprovedBlueprint::class, BasicUserSerializer::class, ['alert']) ->type(FeedbackRejectedBlueprint::class, BasicUserSerializer::class, ['alert']), // Notification data serialization (new Extend\ApiSerializer(NotificationSerializer::class)) ->attributes(function (NotificationSerializer $serializer, Notification $notification) { if (in_array($notification->type, [ 'newFeedback', 'feedbackApproved', 'feedbackRejected' ])) { return ['content' => $notification->data ?: []]; } return []; }), // User preferences (new Extend\User()) ->registerPreference('notify_newFeedback_alert', 'boolval', true) ->registerPreference('notify_feedbackApproved_alert', 'boolval', true) ->registerPreference('notify_feedbackRejected_alert', 'boolval', true), if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } Blueprint Example (FeedbackApprovedBlueprint.php): class FeedbackApprovedBlueprint implements BlueprintInterface { public function getSubject() { return User::find($this->feedback->from_user_id); } public function getFromUser() { return User::find($this->feedback->approved_by_id); } public function getData() { return [ 'feedbackId' => $this->feedback->id, 'feedbackType' => $this->feedback->type, 'toUsername' => $this->feedback->toUser->username ]; } public static function getType() { return 'feedbackApproved'; } public static function getSubjectModel() { return User::class; } } if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } Frontend (notifications.js): app.notificationComponents.feedbackApproved = class extends Notification { icon() { return 'fas fa-check-circle'; } href() { const data = this.attrs.notification.content() || {}; return app.route('user.feedbacks', { username: data.toUsername || app.session.user?.slug() }); } content() { const data = this.attrs.notification.content() || {}; return app.translator.trans('huseyinfiliz-traderfeedback.forum.notifications.feedback_approved_title', { username: data.toUsername || 'a user' }); } }; if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } What I've Tried: ✅ Database shows notifications are created with correct data structure ✅ User preferences are set correctly (notify_feedbackApproved_alert = 1) ✅ Frontend components are registered in app.notificationComponents ✅ Cleared cache multiple times ✅ Used both Event/Listener pattern and direct NotificationSyncer ✅ Verified that notification.content() returns the data Database Evidence: -- Notification exists in DB: id: 123 type: feedbackApproved from_user_id: 1 subject_id: 2 data: {"feedbackId":68,"feedbackType":"positive","toUsername":"testuser"} created_at: 2025-01-18 10:56:58 is_deleted: 0 -- User preference exists: user_id: 2 key: notify_feedbackApproved_alert value: 1 if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } Questions: Is there something special about notification handling in Flarum 1.8 that I'm missing? Do I need to implement MailableInterface even if I only use alerts? Is there a specific order for registering notification components? Could there be a conflict with notification type names? Any help would be greatly appreciated! I can provide more code samples if needed. Repository: huseyinfiliz/traderfeedback Thank you in advance for your help! 🙏

huseyinfiliz if you need each notification to appear as a different entry, I'd suggest adding an attribute with a random value (or the send date) inside getData() There's some confusing logic to de-duplicate notifications based on their subject and/or content. Even while trying to read the code I'm unable to find the full logic, but there's an important SQL query looking for existing blueprints with the same data payload, and if it exists, no new notification will be sent. The logic is originally meant for the context of discussions, where you will get many notifications about the same thing, but only 1 needs to go out until you mark them as read.

Custom notification blueprints not sending notifications (I hate notifications)

huseyinfiliz

clarkwinkelmann I’m trying the random value insertion you mentioned, but either the data column gets saved empty in the notification or no notification is saved at all.

If you know my Notification Hub extension, I worked on notification logic there for months, and I believe I understand the Flarum notification mechanism. The newFeedback notifications work properly and the data column gets filled. The problem happens with approve and reject. Logically, I’m doing something similar, and in my experiments, I was almost succeeding. But this time the data column was always saved as empty.

I’m probably overlooking something very simple, and I’ve tried everything for 3 days.

A hint to point me in the right direction would be great.

clarkwinkelmann

huseyinfiliz mmmh I don't really have other ideas.

It's odd if the entry gets created but without the data value. Maybe do an extra check there isn't a PHP warning causing some return value to be silently converted to null during the array creation and conversion down the line?

Maybe something happens if getSubject or getFromUser accidentally ends up being null ?

As for your original questions, MailableInterface should not be needed and shouldn't cause a change of behavior when it comes to web notifications.

huseyinfiliz

clarkwinkelmann I thought the same, so I assigned a fixed data value to test it, but the issue wasn’t resolved.

I’ll probably delete the extension’s notification structure and rewrite it from scratch. There’s likely something simple I’m overlooking.

I can make the notifications display properly, but since the data is saved empty, when I click on the notifications it redirects me to my own profile instead of the “member we left feedback for.”

huseyinfiliz

clarkwinkelmann

Solution: Custom Notification Blueprints Not Sending Data

Problem: Custom notification blueprints were not properly storing data in the database. The data column remained NULL despite getData() returning correct arrays.

Root Cause: Flarum's NotificationSyncer class doesn't automatically serialize the array returned by getData() into JSON before writing to the database. It also ignores the getFromUser() method in some contexts.

Solution: Use the Sending event listener to manually encode data and set from_user_id:

namespace YourNamespace\Listeners;

use Flarum\Notification\Event\Sending;

class NotificationSendingListener
{
    public function handle(Sending $event)
    {
        $blueprint = $event->blueprint;
        
        if ($blueprint instanceof YourCustomBlueprint) {
            foreach ($event->notifications as $notification) {
                // Force JSON encoding of data
                $data = $blueprint->getData();
                if (is_array($data) && !empty($data)) {
                    $notification->data = json_encode($data);
                }
                
                // Force correct from_user_id
                $fromUser = $blueprint->getFromUser();
                if ($fromUser) {
                    $notification->from_user_id = $fromUser->id;
                }
            }
        }
    }
}

(new Extend\Event())
    ->listen(Sending::class, NotificationSendingListener::class)

Important: Also ensure getSubject() returns the entity (not a User):

public function getSubject()
{
    return $this->feedback; // Return the model, not User::find()
}

public static function getSubjectModel()
{
    return Feedback::class; // Not User::class
}

Why This Sucks: Flarum's notification system is poorly documented and counterintuitive. The getData() method should automatically serialize to JSON, and getFromUser() should reliably set from_user_id. Instead, you need an event listener workaround to do what should be built-in functionality. The documentation provides no clear explanation of when serialization happens or why blueprints sometimes work differently in different contexts.

After wasting hours debugging, the lesson is: don't trust Flarum's notification blueprints to work as documented. Always use the Sending event listener to manually fix what the framework should handle automatically.

huseyinfiliz

This solution didn’t fully work for me. During development I wasn’t using the queue, but when I ran the final tests with the database queue, I noticed a new issue: not only the data column, but also from_user_id and subject_id started being stored as NULL.

While experimenting, I managed to fix the subject_id problem so that it now works correctly with the queue, but the other issues still remain. I really wish there was someone who could point me in the right direction…

All of my file changes are live on GitHub if anyone wants to take a look: huseyinfiliz/traderfeedback

andrewjs18

can any devs respond?

@luceos @Sami SychO

clarkwinkelmann

andrewjs18 I doubt many people will have any more experience with custom notifications, as it's not something I have seen in many extensions. Most of the extensions I can think of actually send custom emails, but have no web notifications and do not use the built-in notification system.

It's definitely something we'd want to fix/improve. I don't know if/how the system has evolved for 2.x already. If someone had time it would be amazing to test whether the same problems exist on 2.0 beta, and maybe we can get some changes included before the final release.

andrewjs18

clarkwinkelmann notifications are a core aspect of any modern forum system - even ones that were built 10+ years ago at this point. I think flarum REALLY needs to make its code inviting so others can create extensions that hook into its core features to extend the functionality of flarum itself.

I'll be honest, I'm still undecided if I want to spend several more hundreds of dollars migrating my site from mybb to flarum. I need more extensions built for flarum and if stuff as critical as notifications are this difficult to build into an extension, why would I want to spend my money on flarum?

Also, why would other devs want to build extensions for flarum if they have to go through as much trouble as @huseyinfiliz has just to try to make a notification execute properly?

I have a forum with _600k posts, I think it'll be the largest forum on flarum. I need this stuff to work correctly.

Sami SychO

can you post concise steps to reproduce?

i tested without approval, seems good. tested with approval, seems good. tested rejection, seems good.

I can't reproduce any issue with data being null or any of the other columns being null. The only problem i noticed is the one already described by clark, which is that you must add a random generated value to each blueprint's getData to make sure it's always treated as a different entry ('rand' => \Illmuniate\Support\Str::random(40))

huseyinfiliz

Sami SychO About 5 hours after making the comment yesterday, I somehow managed to solve it. The issue was caused by the queue system. When the database queue was active, from_user_id, subject_id, and data were being saved as null. For now, I’ve resolved it using some bypasses.

Sami SychO

huseyinfiliz the tests I made were without the bypass code you're referring to. And with using a database queue.

huseyinfiliz

Sami SychO If you check the code below, this is the bypass I mentioned. The old code was causing issues when using the database queue.

Old:

<?php

namespace HuseyinFiliz\TraderFeedback\Api\Controllers;

use Flarum\Api\Controller\AbstractShowController;
use Flarum\Http\RequestUtil;
use Flarum\Notification\NotificationSyncer;
use Illuminate\Support\Arr;
use Psr\Http\Message\ServerRequestInterface;
use Tobscure\JsonApi\Document;
use HuseyinFiliz\TraderFeedback\Api\Serializers\FeedbackSerializer;
use HuseyinFiliz\TraderFeedback\Models\Feedback;
use HuseyinFiliz\TraderFeedback\Models\TraderStats;
use HuseyinFiliz\TraderFeedback\Notifications\FeedbackApprovedBlueprint;
use HuseyinFiliz\TraderFeedback\Notifications\NewFeedbackBlueprint;
use Carbon\Carbon;
use Flarum\User\User;

class ApproveFeedbackController extends AbstractShowController
{
    public $serializer = FeedbackSerializer::class;
    
    protected function data(ServerRequestInterface $request, Document $document)
    {
        $actor = RequestUtil::getActor($request);
        $id = Arr::get($request->getQueryParams(), 'id');
        
        $actor->assertCan('moderate', 'huseyinfiliz-traderfeedback');
        
        $feedback = Feedback::findOrFail($id);
        
        // İlişkileri yükle
        $feedback->load(['fromUser', 'toUser']);
        
        // Önceden onaylı mıydı kontrol et
        $wasApproved = $feedback->is_approved;
        
        // Onaylayan kişiyi kaydet
        $feedback->is_approved = true;
        $feedback->approved_by_id = $actor->id;
        $feedback->save();
        
        // Stats güncelle
        $this->updateUserStats($feedback->to_user_id);
        
        // İlk kez onaylanıyorsa bildirimleri gönder
        if (!$wasApproved) {
            $notifications = app(NotificationSyncer::class);
            
            // 1. Feedback sahibine onay bildirimi
            $fromUser = User::find($feedback->from_user_id);
            
            if ($fromUser) {
                $blueprint = new FeedbackApprovedBlueprint($feedback);
                $notifications->sync($blueprint, [$fromUser]);
            }
            
            // 2. Feedback alan kişiye yeni feedback bildirimi
            $toUser = User::find($feedback->to_user_id);
            
            if ($toUser) {
                $newFeedbackBlueprint = new NewFeedbackBlueprint($feedback);
                $notifications->sync($newFeedbackBlueprint, [$toUser]);
            }
        }
        
        return $feedback;
    }
    
    protected function updateUserStats($userId)
    {
        $stats = TraderStats::firstOrNew(['user_id' => $userId]);
        
        $stats->positive_count = Feedback::where('to_user_id', $userId)
            ->where('type', 'positive')
            ->where('is_approved', true)
            ->count();
            
        $stats->neutral_count = Feedback::where('to_user_id', $userId)
            ->where('type', 'neutral')
            ->where('is_approved', true)
            ->count();
            
        $stats->negative_count = Feedback::where('to_user_id', $userId)
            ->where('type', 'negative')
            ->where('is_approved', true)
            ->count();
        
        $total = $stats->positive_count + $stats->neutral_count + $stats->negative_count;
        $stats->score = $total > 0 ? ($stats->positive_count / $total) * 100 : 0;
        $stats->last_updated = Carbon::now();
        $stats->save();
    }
}

New:

<?php
namespace HuseyinFiliz\TraderFeedback\Api\Controllers;

use Flarum\Api\Controller\AbstractShowController;
use Flarum\Http\RequestUtil;
use Flarum\Notification\NotificationSyncer;
use Illuminate\Support\Arr;
use Psr\Http\Message\ServerRequestInterface;
use Tobscure\JsonApi\Document;
use HuseyinFiliz\TraderFeedback\Api\Serializers\FeedbackSerializer;
use HuseyinFiliz\TraderFeedback\Models\Feedback;
use HuseyinFiliz\TraderFeedback\Notifications\FeedbackApprovedBlueprint;
use HuseyinFiliz\TraderFeedback\Notifications\NewFeedbackBlueprint;
use HuseyinFiliz\TraderFeedback\Services\StatsService;
use Carbon\Carbon;

class ApproveFeedbackController extends AbstractShowController
{
    public $serializer = FeedbackSerializer::class;
    
    protected function data(ServerRequestInterface $request, Document $document)
    {
        $actor = RequestUtil::getActor($request);
        $id = Arr::get($request->getQueryParams(), 'id');
        
        $actor->assertCan('moderate', 'huseyinfiliz-traderfeedback');
        
        $feedback = Feedback::findOrFail($id);
        
        // Check if already approved
        $wasApproved = $feedback->is_approved;
        
        // Approve feedback
        $feedback->is_approved = true;
        $feedback->approved_by_id = $actor->id;
        $feedback->save();
        
        // Reload with relationships
        $feedback = Feedback::with(['fromUser', 'toUser'])->findOrFail($id);
        
        // Update stats using service
        StatsService::updateUserStats($feedback->to_user_id);
        
        // Send notifications if newly approved
        if (!$wasApproved) {
            // 1. Notify feedback author about approval
            if ($feedback->fromUser) {
                $now = Carbon::now();
                
                try {
                    app('db')->table('notifications')->insert([
                        'user_id' => (int)$feedback->fromUser->id,
                        'from_user_id' => (int)$feedback->to_user_id,
                        'type' => 'feedbackApproved',
                        'subject_id' => (int)$feedback->id,
                        'data' => json_encode([
                            'feedbackId' => (int)$feedback->id,
                            'feedbackType' => $feedback->type
                        ], JSON_THROW_ON_ERROR),
                        'created_at' => $now,
                        'read_at' => null,
                        'is_deleted' => 0
                    ]);
                } catch (\Exception $e) {
                    // Silently fail - notification is not critical
                }
            }
            
            // 2. Notify feedback recipient about new feedback
            if ($feedback->toUser) {
                try {
                    $notifications = app(NotificationSyncer::class);
                    $newFeedbackBlueprint = new NewFeedbackBlueprint($feedback);
                    $notifications->sync($newFeedbackBlueprint, [$feedback->toUser]);
                } catch (\Exception $e) {
                    // Silently fail - notification is not critical
                }
            }
        }
        
        return $feedback;
    }
}

Sami SychO

Yes and like I said. For my quick tests, I used the old code which uses the syncer.

huseyinfiliz

Sami SychO I’ve prepared the code again using the syncer as follows:

ApproveFeedbackController.php

<?php
namespace HuseyinFiliz\TraderFeedback\Api\Controllers;

use Flarum\Api\Controller\AbstractShowController;
use Flarum\Http\RequestUtil;
use Flarum\Notification\NotificationSyncer;
use Illuminate\Support\Arr;
use Psr\Http\Message\ServerRequestInterface;
use Tobscure\JsonApi\Document;
use HuseyinFiliz\TraderFeedback\Api\Serializers\FeedbackSerializer;
use HuseyinFiliz\TraderFeedback\Models\Feedback;
use HuseyinFiliz\TraderFeedback\Notifications\FeedbackApprovedBlueprint;
use HuseyinFiliz\TraderFeedback\Notifications\NewFeedbackBlueprint;
use HuseyinFiliz\TraderFeedback\Services\StatsService;

class ApproveFeedbackController extends AbstractShowController
{
    public $serializer = FeedbackSerializer::class;
    
    protected $notifications;
    
    public function __construct(NotificationSyncer $notifications)
    {
        $this->notifications = $notifications;
    }
    
    protected function data(ServerRequestInterface $request, Document $document)
    {
        $actor = RequestUtil::getActor($request);
        $id = Arr::get($request->getQueryParams(), 'id');
        
        $actor->assertCan('moderate', 'huseyinfiliz-traderfeedback');
        
        $feedback = Feedback::with(['fromUser', 'toUser'])->findOrFail($id);
        
        $wasApproved = $feedback->is_approved;
        
        // Approve feedback
        $feedback->is_approved = true;
        $feedback->approved_by_id = $actor->id;
        $feedback->save();
        
        // Update stats
        StatsService::updateUserStats($feedback->to_user_id);
        
        // Send notifications if newly approved
        if (!$wasApproved) {
            try {
                // 1. Notify feedback author about approval
                if ($feedback->fromUser) {
                    $approvalBlueprint = new FeedbackApprovedBlueprint($feedback);
                    $this->notifications->sync($approvalBlueprint, [$feedback->fromUser]);
                }
                
                // 2. Notify feedback recipient about new feedback
                if ($feedback->toUser) {
                    $newFeedbackBlueprint = new NewFeedbackBlueprint($feedback);
                    $this->notifications->sync($newFeedbackBlueprint, [$feedback->toUser]);
                }
            } catch (\Exception $e) {
                app('log')->error('Failed to send approval notifications', [
                    'feedback_id' => $feedback->id,
                    'error' => $e->getMessage()
                ]);
            }
        }
        
        return $feedback;
    }
}

RejectFeedbackController.php

<?php
namespace HuseyinFiliz\TraderFeedback\Api\Controllers;

use Flarum\Api\Controller\AbstractShowController;
use Flarum\Http\RequestUtil;
use Flarum\Notification\NotificationSyncer;
use Illuminate\Support\Arr;
use Psr\Http\Message\ServerRequestInterface;
use Tobscure\JsonApi\Document;
use HuseyinFiliz\TraderFeedback\Api\Serializers\FeedbackSerializer;
use HuseyinFiliz\TraderFeedback\Models\Feedback;
use HuseyinFiliz\TraderFeedback\Notifications\FeedbackApprovedBlueprint;
use HuseyinFiliz\TraderFeedback\Notifications\NewFeedbackBlueprint;
use HuseyinFiliz\TraderFeedback\Services\StatsService;

class ApproveFeedbackController extends AbstractShowController
{
    public $serializer = FeedbackSerializer::class;
    
    protected $notifications;
    
    public function __construct(NotificationSyncer $notifications)
    {
        $this->notifications = $notifications;
    }
    
    protected function data(ServerRequestInterface $request, Document $document)
    {
        $actor = RequestUtil::getActor($request);
        $id = Arr::get($request->getQueryParams(), 'id');
        
        $actor->assertCan('moderate', 'huseyinfiliz-traderfeedback');
        
        $feedback = Feedback::with(['fromUser', 'toUser'])->findOrFail($id);
        
        $wasApproved = $feedback->is_approved;
        
        // Approve feedback
        $feedback->is_approved = true;
        $feedback->approved_by_id = $actor->id;
        $feedback->save();
        
        // Update stats
        StatsService::updateUserStats($feedback->to_user_id);
        
        // Send notifications if newly approved
        if (!$wasApproved) {
            try {
                // 1. Notify feedback author about approval
                if ($feedback->fromUser) {
                    $approvalBlueprint = new FeedbackApprovedBlueprint($feedback);
                    $this->notifications->sync($approvalBlueprint, [$feedback->fromUser]);
                }
                
                // 2. Notify feedback recipient about new feedback
                if ($feedback->toUser) {
                    $newFeedbackBlueprint = new NewFeedbackBlueprint($feedback);
                    $this->notifications->sync($newFeedbackBlueprint, [$feedback->toUser]);
                }
            } catch (\Exception $e) {
                app('log')->error('Failed to send approval notifications', [
                    'feedback_id' => $feedback->id,
                    'error' => $e->getMessage()
                ]);
            }
        }
        
        return $feedback;
    }
}

Now take a look at the following database:

Notifications with IDs 38–41 were created with the bypass. IDs 42–49 were created with the new code. As you can see, the from_userid is now the admin’s ID (id 1) who approved the feedback, instead of the user ID of the person giving the feedback. Also, the data field is being saved as NULL.

Sami SychO

huseyinfiliz can you upload the code into a specific branch I can try?

huseyinfiliz

Sami SychO huseyinfiliz/traderfeedbacktree/dev

Sami SychO

I cannot reproduce.

Are you sure you restarted the queue after changing the code? and did you try without having other third-party extensions running?

huseyinfiliz

Sami SychO I’m only using the database queue extension for testing. I’ll test it with a clean Flarum installation and report the result.

huseyinfiliz

Sami SychO Ah, I found the issue. Updating the cron job like this fixed the problem I was having with NotificationSyncer:

sudo -u huseyinfiliz /opt/plesk/php/8.2/bin/php flarum schedule:run

Honestly, I still don’t fully understand the reason, but since a fresh Flarum installation didn’t have the issue, I tried everything I could think of—and this somehow fixed it.

I guess it was a permission or server configuration issue.

Thanks for your support!