- What is Notifynder used for in a Laravel application?
- Notifynder is an internal notification package that stores notifications in your database and ties them to your Eloquent models. You use it to send alerts between users or app entities, retrieve and count unread items, and mark notifications as read. It is commonly used for activity feeds, in-app alerts, and simple user-to-user messaging without email or push infrastructure.
- How do I install fenos/notifynder with Composer?
- Install it with composer require fenos/notifynder, then register the package service provider and facade if your Laravel version does not auto-discover them. Publish the package configuration so you can adjust table names and model bindings, then run the included migrations to create the notifications tables. Verify the installed version in composer.json before running migrations in shared environments.
- Which Laravel versions does Notifynder support?
- Notifynder targets Laravel 4.x and 5.x, so it is not a drop-in choice for modern Laravel 10, 11, or 12 applications. If you are on a newer major, check the repository for open compatibility issues before adopting it. For Laravel 5.3 and above, the framework's built-in notification system with the database channel is usually the better-supported option.
- Do I need to run migrations to use Notifynder?
- Yes. Notifynder is database-backed, so it ships migrations that create the tables used to store notifications and their relationships. Run the migrations after publishing the package config, and confirm the table names match what your config specifies. If you use a non-default connection, set it in the package config before migrating.
- How do I send a notification to a user with Notifynder?
- You send notifications through the package's notifier API, typically via the Notifynder facade, specifying the sender, the recipient model, a category or body, and any extra parameters. The package then persists a row tied to those Eloquent models so the recipient can query it later. Because the exact method chain has changed across versions, check the README or source for the syntax that matches your installed release.
- How do I count unread notifications and mark them as read?
- Notifynder exposes read paths on its models and facade for fetching a user's notifications, counting unread items, and marking individual or all notifications as read. These calls translate into Eloquent queries against the notifications table, so they benefit from indexing the recipient column. Wrap the count and list calls in the same request carefully, since marking items read changes subsequent counts.
- What changed in Notifynder 4.3.0 and is it safe to upgrade?
- Version 4.3.0 is a minor release whose only change is PR #280, which adds eager loading. For consumers already on the 4.x line this should be a drop-in composer update with no new service providers, facades, or migrations. Before rolling it out, enable query logging and compare query counts and result sets on your notification list endpoints to confirm behavior is unchanged.
- Does the eager loading change in Notifynder 4.3.0 break my JSON API responses?
- It can, indirectly. If the package now loads relationships by default, those relations may appear in toArray() and JSON output where consumers previously saw only foreign keys. Compare representative API payloads before and after the upgrade. If the output changed and you depend on the old shape, hide the new relations with $hidden or $visible on your models.
- Does Notifynder cause N+1 query problems when listing notifications?
- Earlier versions loaded related records lazily, which pushed N+1 behavior onto the integrating application, and 4.3.0 begins addressing that with eager loading. Coverage may be partial, so check which relationships and nesting depths are included before assuming the problem is solved. You can still call with() yourself on package queries, and query logging is the quickest way to confirm the real query count on your endpoints.
- Is Notifynder still maintained, and what are the alternatives?
- Notifynder sits on the 4.x line and targets Laravel 4 and 5, so review the repository's recent commit and issue activity before committing to it for a new project. For modern applications, Laravel's built-in notification system with the database channel covers most internal notification use cases and is actively maintained. If you need Notifynder's category and entity model, budget time to verify compatibility or fork and maintain it yourself.