What Does It Do? 

lex_notifications is a Laravel-style notification system for TYPO3 13.4+.

The core idea is simple: any PHP object that uses the Notifiable trait can receive a notification. Any PHP code — a controller, an Extbase plugin, a domain service, a Scheduler task, a middleware — can send one. The two sides are decoupled through a Notification class that describes what to send and how to format it for each delivery channel.

There is no constraint on the direction of communication:

• A frontend user can receive a notification when they place an order.
• A backend user can be alerted when a content workflow step requires their approval.
• An email address (represented by a lightweight inline class) can receive a transactional email without any database record.
• Any custom domain model becomes a notification recipient with a single use Notifiable; declaration.

Built-in delivery channels:

• Email channel — sends styled HTML/plain-text emails using TYPO3's mail system and Fluid templates.
• Database channel — persists notifications in a database table so they can be retrieved and displayed as an in-app notification centre.

Both channels are extensible. Implement ChannelInterface to add Slack, push notifications, SMS, webhooks, or any other transport.

The included backend module (Web > Notifications) is a ready-to-use tool for editors who need to compose and send messages to frontend users. It also acts as a reference implementation showing how to dispatch batch notifications to a resolved list of Notifiable recipients.

When Should You Use It? 

Use lex_notifications whenever you need to decouple the act of triggering a notification from the act of delivering it. Typical scenarios:

• E-commerce — order confirmed, shipment dispatched, invoice available.
• Workflow / approval — content submitted for review, approved, rejected.
• Account events — registration, password reset, login from new device.
• System alerts — an extension notifies a backend user when a background job fails.
• Cross-user messaging — a frontend user triggers a notification to another frontend user (e.g. a collaboration platform).
• Editorial broadcasts — backend editors send announcements to groups of frontend users via the included module.
• Any programmatic trigger — if something happens in your TYPO3 application and someone needs to know about it, this extension handles the delivery.

Core Concepts 

Notifiable

Any PHP object that uses the Notifiable trait. It gains notify() and notifyNow() methods and can be passed as the recipient of any notification.

Notification

A PHP class extending Lex\Notifications\Notification. It declares which channels to use (via()) and how to format the payload for each channel (toMail(), toDatabase(), toSlack(), …).

Channel

A delivery mechanism implementing ChannelInterface. A channel receives a notifiable and a notification, extracts the relevant payload, and delivers it (sends an email, writes a DB row, calls a webhook, …).

NotificationDispatcherInterface

The central dispatcher. Inject it anywhere in your TYPO3 code to send notifications without depending on concrete implementations.

ShouldQueue

A marker interface. When a notification class implements it, dispatching goes through Symfony Messenger so delivery happens asynchronously in a CLI worker — keeping your HTTP responses fast.

Architecture Overview 

┌──────────────────────────────────────────────────────────────┐
│  Any PHP code: Controller · Plugin · Service · Scheduler     │
│                                                              │
│  $user->notify(new OrderConfirmed($order));                  │
│  // or                                                       │
│  $dispatcher->send([$userA, $userB], new Announcement());    │
└─────────────────────────┬────────────────────────────────────┘
                          │
                          ▼
┌──────────────────────────────────────────────────────────────┐
│              NotificationManager (Dispatcher)                │
│                                                              │
│  • Iterates notifiable(s)                                    │
│  • Calls notification->via($notifiable) → channel list       │
│  • If ShouldQueue → wraps in Messenger message               │
│  • Otherwise → sends immediately via each channel            │
└───────┬──────────────────┬────────────────────┬─────────────┘
        │                  │                    │
        ▼                  ▼                    ▼
┌──────────────┐  ┌────────────────┐  ┌─────────────────────┐
│ EmailChannel │  │DatabaseChannel │  │  YourCustomChannel  │
│ (TYPO3 Mail) │  │ (Extbase / DB) │  │  (Slack, SMS, …)    │
└──────────────┘  └────────────────┘  └─────────────────────┘

        ▲                  ▲                    ▲
        │       Notifiable recipients            │
┌───────┴──────────────────┴────────────────────┴─────────────┐
│  FrontendUser · BackendUser · InlineClass · Any domain model │
└──────────────────────────────────────────────────────────────┘

Notifications flow from any caller through the NotificationManager, which delegates to the channels declared in the notification's via() method. Each channel knows how to format and deliver the payload for its transport. The recipients can be any combination of objects using the Notifiable trait.

Screenshots 

Requirements 

• TYPO3 CMS 13.4 or higher
• PHP 8.2 or higher
• Composer-based TYPO3 installation (strongly recommended)

The extension requires two additional PHP packages that are pulled in automatically via Composer:

• nesbot/carbon ^3.2 — human-readable date/time differences
• illuminate/collections ^10.48 — fluent collection helpers

Installation via Composer (Recommended) 

composer require lex/notifications

Then activate the extension:

# via CLI
vendor/bin/typo3 extension:activate lex_notifications

# or via Admin Tools > Extensions in the TYPO3 backend

Run the database analyser to create the required tables:

vendor/bin/typo3 database:updateschema

Installation via TER (non-Composer) 

1. Download the extension from the TYPO3 Extension Repository.
2. Upload and install it via Admin Tools > Extensions.
3. Run Admin Tools > Maintenance > Analyze Database Structure to create the required tables.

Post-Installation Steps 

After installation:

1. Include TypoScript (if you need the frontend plugin):

   Go to your root page's TypoScript template record and add the static template "Lex Notifications (lex_notifications)" under Includes > Include static (from extensions).

2. Clear all caches via Admin Tools > Maintenance.
3. The backend module Web > Notifications is now available for backend users with the required permissions.

Database Tables 

The extension creates two tables:

Extension Configuration 

The extension does not currently expose options in the TYPO3 Extension Configuration panel (Admin Tools > Settings > Extension Configuration). All behaviour is controlled through TypoScript or PHP configuration.

TypoScript 

The extension ships with empty constants.typoscript and setup.typoscript templates. These are reserved for future frontend plugin configuration. No TypoScript is required for the backend module or the developer API.

Symfony Messenger (Queue Configuration) 

The BackendUserSentMessageToFrontendUser notification implements the ShouldQueue interface, which means it is dispatched via the Symfony Messenger component by default.

To process the queue, configure a transport and run the messenger worker:

vendor/bin/typo3 messenger:consume async --time-limit=3600

Refer to the TYPO3 Core documentation on Symfony Messenger for full transport configuration options (Doctrine, Redis, AMQP, etc.).

If you want to send notifications synchronously (without a queue worker), call notifyNow() instead of notify() — see Developer Reference.

Backend Module Access 

The Web > Notifications module is registered under the web module group. Access is controlled via TYPO3's standard backend user/group permissions.

To grant a backend user group access:

1. Go to System > Backend Users and edit the relevant user group.
2. Under Access Lists > Modules, tick Web > Notifications.
3. Save and clear caches.

Notification Levels 

Levels follow RFC 5424 severity constants:

Notification Channels 

Two built-in channels are available:

Custom channels can be registered by implementing Lex\Notifications\Channel\ChannelInterface — see Adding Custom Channels.

Listing Messages 

The module overview displays all composed messages in a paginated list (50 per page). Each row shows:

• Level — severity badge (Info, Notice, Warning, Error, …)
• Subject — message title
• Created — creation date and author
• Sent at — timestamp of last send, or "Not sent" if pending
• Actions — Send / Resend buttons

Use the filter bar at the top to narrow results by level.

Composing a Message 

Click the Create button (pencil icon) in the module button bar.

Click Save to store the message without sending it.

Sending Messages 

After saving (or from the list view), click the Send button. The module will:

1. Resolve all recipient UIDs from the selected users and groups, minus any excluded recipients.
2. Remove duplicates.
3. Load NotifiableFrontendUser objects for each resolved UID.
4. Instantiate a BackendUserSentMessageToFrontendUser notification.
5. Call $dispatcher->send($recipients, $notification) — the same call you would make from your own PHP code.
6. Record the sent_at timestamp on the message record.
7. Display a flash message confirming how many recipients were notified.

Resending Messages 

Click Resend to dispatch a message again to the same recipients and channels. The sent_at timestamp is updated. Useful when delivery failed or you want to send a reminder.

Using the Module as a Code Sample 

The backend module is deliberately simple so that its source code is easy to read. If you need to send batch notifications from your own extension, study NotificationController::sendAction() — it shows the full pattern:

// Simplified version of what the module does:

$recipients = $this->resolveRecipients($message);   // returns Notifiable[]

$notification = new BackendUserSentMessageToFrontendUser(
    subject:  $message->getSubject(),
    message:  $message->getMessage(),
    level:    $message->getLevel(),
    link:     $message->getLink(),
    channels: $this->parseChannels($message),
);

$this->notificationDispatcher->send($recipients, $notification);

Replace BackendUserSentMessageToFrontendUser with your own Notification subclass and $recipients with any collection of Notifiable objects to adapt this pattern to your use case.

The Notifiable Trait 

The Notifiable trait is the only requirement for a class to receive notifications. Add it to any PHP object — Extbase entity, plain PHP class, anonymous class — and that object immediately becomes a valid notification recipient.

use Lex\Notifications\Domain\Model\Ability\Notifiable;

class MyModel
{
    use Notifiable;
}

// That's it. Now you can do:
$instance = new MyModel();
$instance->notify(new SomeNotification());

There is no registry, no database table for recipients, no configuration. Any object with the trait can be passed to the dispatcher.

Making a Model Notifiable 

For email delivery, also add HasRouteNotificationForMail. This trait provides the routeNotificationForMail() method, which the email channel calls to resolve the recipient's email address. It expects an $email property on the class:

use Lex\Notifications\Domain\Model\Ability\HasRouteNotificationForMail;
use Lex\Notifications\Domain\Model\Ability\Notifiable;
use TYPO3\CMS\Extbase\DomainObject\AbstractEntity;

class FrontendUser extends AbstractEntity
{
    use Notifiable;
    use HasRouteNotificationForMail;

    protected string $email = '';
}

The Notifiable trait exposes two methods:

// Dispatches via Symfony Messenger if the notification implements ShouldQueue
$user->notify(new OrderConfirmed($order));

// Always sends immediately, ignoring ShouldQueue
$user->notifyNow(new OrderConfirmed($order), ['mail', 'database']);

Who Can Be a Recipient? 

Because the only requirement is the Notifiable trait, the recipient can be anything. Here are common patterns.

Frontend user notifies another frontend user

A collaboration feature where one user shares content with another:

// In a frontend plugin action
$recipient = $this->frontendUserRepository->findByUid($targetUid);
$recipient->notify(new ContentSharedWithYou($page, $sender));

Extension notifies a backend user

A Scheduler task or service that alerts an admin when a background job fails:

// BackendNotifiableUser wraps a TYPO3 backend user record
class BackendNotifiableUser
{
    use Notifiable;
    use HasRouteNotificationForMail;

    public function __construct(
        public readonly string $email,
        public readonly string $username,
    ) {}
}

$admin = new BackendNotifiableUser(
    email: $backendUserRecord['email'],
    username: $backendUserRecord['username'],
);
$admin->notifyNow(new SchedulerJobFailed($taskName, $errorMessage));

Inline / anonymous notifiable (no database record needed)

Send a one-off notification to any email address without a domain model:

$recipient = new class('info@example.com') {
    use Notifiable;
    use HasRouteNotificationForMail;

    public function __construct(public readonly string $email) {}
};

$recipient->notifyNow(new ContactFormReceived($formData));

Multiple recipients of different types in one call

The dispatcher accepts an array of notifiables — they do not need to be the same class:

$this->notificationDispatcher->send(
    [$frontendUser, $backendAdmin, $externalEmail],
    new ImportantAnnouncement($text),
);

Each recipient's via() result can differ, so the notification class can adapt channels based on the notifiable type:

public function via(object $notifiable): array
{
    // Only store in-DB for actual frontend user records
    if ($notifiable instanceof NotifiableFrontendUser) {
        return [NotificationChannel::CHANNEL_MAIL, NotificationChannel::CHANNEL_DATABASE];
    }

    return [NotificationChannel::CHANNEL_MAIL];
}

Creating a Notification 

Extend the abstract Notification class and implement the methods for each channel your notification uses:

namespace MyVendor\MyExtension\Notification;

use Lex\Notifications\Notification;
use Lex\Notifications\NotificationChannel;
use Lex\Notifications\NotificationLevel;
use TYPO3\CMS\Core\Mail\MailMessage;

final class OrderConfirmed extends Notification
{
    public function __construct(
        private readonly Order $order,
    ) {}

    /**
     * RFC 5424 severity level for this notification.
     */
    public function getLevel(): int
    {
        return NotificationLevel::LEVEL_INFO;
    }

    /**
     * Which channels to use. Receives the notifiable so you can adapt
     * the channel list per recipient type.
     *
     * @return string[]
     */
    public function via(object $notifiable): array
    {
        return [
            NotificationChannel::CHANNEL_MAIL,
            NotificationChannel::CHANNEL_DATABASE,
        ];
    }

    /**
     * Payload for the email channel.
     */
    public function toMail(object $notifiable): MailMessage
    {
        return (new MailMessage())
            ->subject('Order #' . $this->order->getNumber() . ' confirmed')
            ->html('<p>Thank you! Your order is being processed.</p>')
            ->to($notifiable->getEmail());
    }

    /**
     * Payload for the database channel.
     * Returned array is JSON-encoded and stored as-is.
     *
     * @return array<string, mixed>
     */
    public function toDatabase(object $notifiable): array
    {
        return [
            'level'    => $this->getLevel(),
            'subject'  => 'Order #' . $this->order->getNumber() . ' confirmed',
            'message'  => 'Your order has been received and is being processed.',
            'order_id' => $this->order->getUid(),
        ];
    }
}

Only implement the channel methods you actually use. If your notification only sends email, there is no need for toDatabase().

Queuing Notifications 

Implement the ShouldQueue marker interface to have your notification dispatched asynchronously via Symfony Messenger:

use TYPO3\CMS\Core\Messaging\ShouldQueue;

final class OrderConfirmed extends Notification implements ShouldQueue
{
    // No extra methods needed — the interface is a marker only.
}

When ShouldQueue is implemented, calling notify() wraps the notification in a NotificationQueued Messenger message. A CLI worker must be running to process the queue:

vendor/bin/typo3 messenger:consume async --time-limit=3600

Call notifyNow() or sendNow() to bypass the queue and deliver immediately regardless of ShouldQueue.

Using the Dispatcher Directly 

Inject NotificationDispatcherInterface into any service, controller, or plugin. This is the recommended approach when you do not have a direct reference to a notifiable object, or when you need to send to multiple recipients:

use Lex\Notifications\NotificationDispatcherInterface;

final class OrderService
{
    public function __construct(
        private readonly NotificationDispatcherInterface $notifications,
        private readonly FrontendUserRepository $userRepository,
    ) {}

    public function completeOrder(Order $order): void
    {
        $buyer = $this->userRepository->findByUid($order->getBuyerUid());

        // Dispatches via Messenger queue if ShouldQueue is implemented
        $this->notifications->send($buyer, new OrderConfirmed($order));

        // Forces immediate delivery
        $this->notifications->sendNow($buyer, new OrderConfirmed($order));
    }
}

Send to a batch of recipients in one call:

$subscribers = $this->frontendUserRepository->findByNewsletterGroup($groupId);

$this->notifications->send(
    $subscribers->toArray(),
    new MonthlyNewsletter($content),
);

The dispatcher iterates each notifiable independently, so a failed delivery for one recipient does not block the others.

Practical Use Cases 

Workflow approval alert to a backend user

// In a DataHandler hook or custom service
$responsible = new BackendNotifiableUser(email: 'editor@example.com');
$this->notifications->sendNow(
    $responsible,
    new ContentPendingReview($pageUid, $submitter),
);

Frontend user triggers a notification to another frontend user

// In a frontend plugin action (e.g. a messaging feature)
$sender   = $this->frontendUserRepository->findByUid($senderUid);
$receiver = $this->frontendUserRepository->findByUid($receiverUid);

$receiver->notify(new NewMessageReceived($sender, $messageText));

Extension notifies multiple channels for different severity levels

final class PaymentFailed extends Notification
{
    public function via(object $notifiable): array
    {
        // Critical failures go to mail + database + Slack
        return [
            NotificationChannel::CHANNEL_MAIL,
            NotificationChannel::CHANNEL_DATABASE,
            'slack',
        ];
    }
}

Sending to a plain email without any domain model

$contact = new class('customer@example.com') {
    use \Lex\Notifications\Domain\Model\Ability\Notifiable;
    use \Lex\Notifications\Domain\Model\Ability\HasRouteNotificationForMail;
    public function __construct(public readonly string $email) {}
};

$contact->notifyNow(new OrderReceiptEmail($order));

Reading Database Notifications 

Inject DatabaseNotificationRepository to query stored notifications for the currently logged-in frontend user:

use Lex\Notifications\Domain\Repository\DatabaseNotificationRepository;

class NotificationController extends ActionController
{
    public function __construct(
        private readonly DatabaseNotificationRepository $notificationRepository,
    ) {}

    public function indexAction(): ResponseInterface
    {
        $uid = $this->getContext()->getAspect('frontend.user')->get('id');

        $this->view->assign(
            'notifications',
            $this->notificationRepository->findByNotifiable($uid),
        );
        return $this->htmlResponse();
    }

    public function markAllReadAction(): ResponseInterface
    {
        $uid = $this->getContext()->getAspect('frontend.user')->get('id');
        $this->notificationRepository->markAllAsReadForNotifiable($uid);
        return $this->redirect('index');
    }
}

Available repository methods:

DatabaseNotification Model 

Each stored notification exposes:

Adding Custom Channels 

Implement ChannelInterface to create any delivery channel you need:

namespace MyVendor\MyExtension\Notification\Channel;

use Lex\Notifications\Channel\ChannelInterface;
use Lex\Notifications\Notification;

final class SlackChannel implements ChannelInterface
{
    public function __construct(
        private readonly SlackClient $slack,
    ) {}

    public function send(object $notifiable, Notification $notification): void
    {
        $payload = $notification->toSlack($notifiable);
        $this->slack->post($notifiable->getSlackWebhookUrl(), $payload);
    }
}

Register the channel as a service in Services.yaml and return its string key (e.g. 'slack') from your notification's via() method. The NotificationManager will resolve it from the container automatically.

Customising Email Templates 

Email templates live in:

Resources/Private/
├── Layouts/Email/
│   ├── NotificationLayout.html   # HTML wrapper
│   └── NotificationLayout.txt    # Plain-text wrapper
└── Templates/Email/
    ├── BackendUserSentMessageToFrontendUser.html
    └── BackendUserSentMessageToFrontendUser.txt

Override them in your site package by adjusting the Fluid template paths. The built-in templates receive these variables:

For your own Notification subclasses you can use a completely different template — simply return the rendered HTML from your toMail() method using whatever rendering approach fits your extension.

1.1.0 — 2024-01-01 

• [FEATURE] Added Symfony Messenger queue integration via ShouldQueue marker interface.
• [FEATURE] Added NotificationLevel constants following RFC 5424 (Info, Notice, Warning, Error, Critical, Alert, Emergency).
• [FEATURE] Added resend action to the backend module.
• [FEATURE] Pagination in the backend message list (50 items per page).
• [FEATURE] Added level filter to the backend message list.
• [FEATURE] French (fr) localization for all language files.
• [FEATURE] Added getDiffCreatedAtForHumans() on DatabaseNotification using Carbon.
• [CHANGE] Bumped TYPO3 requirement to 13.4+.
• [CHANGE] Bumped PHP requirement to 8.2+.

1.0.0 — Initial Release 

• Backend module for composing and sending messages to frontend users.
• Email channel using TYPO3's mail system and Fluid templates.
• Database channel for persistent in-app notifications.
• Notifiable trait for Extbase domain models.
• HasRouteNotificationForMail trait for email routing.
• DatabaseNotificationRepository with findByNotifiable, markAllAsReadForNotifiable and removeAllForNotifiable methods.
• Abstract Notification base class for custom notification types.
• NotificationDispatcherInterface for dependency injection.
• BackendUserSentMessageToFrontendUser built-in notification class.
• English localization for all language files.