- Can I use mgilet/notification-bundle in a Laravel application?
- No. It is a Symfony bundle built on the Symfony DI container, Doctrine ORM entity mapping and Twig helpers, so there is no service provider, facade, config stub or Eloquent model that would let Composer load it into Laravel. The practical path is to treat it as a schema specification: a notifications table plus a notifiable pivot with a seen_at column, implemented with Eloquent morphToMany and a scoped unseen query. Laravel's native Notifiable trait and database notification channel already cover most of the same functionality.
- What does mgilet/notification-bundle actually do?
- It is a small Symfony bundle that adds database-backed, in-app notifications to your application. A Notification entity is attached to any entity implementing NotifiableEntity, usually your User, through a join table, and a NotificationManager service lets you add, list, count and mark them as seen. Twig helpers are included so templates can render notification lists and unseen counters. It is a persistence and read-state model, not a delivery engine.
- How do I install mgilet/notification-bundle?
- Install it with Composer using composer require mgilet/notification-bundle, then register the bundle in your Symfony kernel and let Doctrine pick up its entity mapping. Run the schema tool or a migration to create the notification and join tables, and inject the NotificationManager service where you need it. On Symfony 3.4 or 4.4 the flow is straightforward, but on 5.x and 6.x expect to fork and modernize first. There is no configuration file or publishable stub, so most setup is Doctrine wiring.
- Which Symfony and PHP versions does notification-bundle support?
- The bundle targets the Symfony 3.x and 4.x era, with its last release in January 2021, and Symfony 3 reached end of life in November 2018. It is not maintained for Symfony 5 or 6, and PHP 8 typed-return and deprecation changes will likely require patching before it runs cleanly. Check the PHP constraint in its composer.json against your runtime before committing, since 7.x-only constraints are common in that vintage. For anything modern, plan on owning a fork.
- How do I attach a notification to any entity, not just a user?
- Have the entity implement the NotifiableEntity interface, usually by adding the trait the bundle ships, and it can then receive notifications through the join table. The design is not user-only: users, teams or orders can all be notifiable, and the seen flag is stored per notifiable entity rather than globally. This multi-entity attachment with per-entity read state is the genuinely useful idea the bundle contributes. It maps cleanly onto an Eloquent morphToMany if you port it.
- How do I show unseen notification counts and mark notifications as seen?
- The NotificationManager service exposes helpers to list notifications, return unseen counts, and mark individual or all notifications as seen. Templates get the same data through the bundle's Twig helpers, so you can render a badge counter without writing queries in the view layer. Seen state is stored per notifiable entity, so counts stay correct when several entity types share the table. On high-volume systems, cache the unseen counter instead of counting on every page render.
- Does notification-bundle support email, SMS or push notifications?
- No. It handles in-app persistence and read state only, so nothing is sent by email, SMS, push or websocket. If you need those channels you integrate a separate mailer or transport, or move to a framework with a channel manager. That limitation matters when comparing it with Laravel's notification system, which ships delivery channels alongside database storage.
- Is mgilet/notification-bundle still maintained and safe for production?
- It is a legacy-risk package. The last release was January 2021, there is no evidence of an active maintainer, and zero dependents means no downstream validation or ecosystem pressure to keep it current. That makes lifecycle risk the main concern rather than code quality: it works on pinned Symfony 3.4 and 4.4 stacks but is a poor bet on anything newer. The MIT license means forking and owning it is legally clean, which is the usual mitigation, but confirm your PHP runtime and your appetite for an indefinite fork first.
- How do I migrate from notification-b bundle to Laravel's notification system?
- Start schema-first: freeze the current Doctrine mapping, export the DDL, and map it to Laravel's notifications table shape (id, type, payload JSON, timestamps) plus a notifiable pivot carrying seen_at. Implement Eloquent morphToMany on the notifiable side, add a scoped unseen query and a cached counter, then dual-write during a short transition before cutting reads over. Preserve the seen semantics exactly, because downstream UI counters depend on them. Delivery can then move to Laravel Notification classes so email and push come for free later.
- What are the alternatives to mgilet/notification-bundle?
- For Laravel, the built-in Notifiable trait with the database channel is strictly better for user-only notifications and needs no port at all. If you need multi-entity attachment with per-entity read state, port the pivot and seen_at idea but keep Laravel's delivery layer. On Symfony, choose a currently maintained notification bundle unless you are deliberately staying on 3.4 or 4.4. There is no framework-agnostic PSR abstraction in this package, so a bridge between the two ecosystems is not an option.