- How do I install lara-zeus/replies in a Laravel Filament application?
- Install it with Composer (composer require lara-zeus/replies), then publish the config, migrations, and views and run php artisan migrate. Next, register the plugin in your panel provider, add the package trait to the model that should receive replies, and render the supplied component on your page or resource. The documented spike of one model, one surface, two nesting levels, and a post/reload/authorize check takes roughly an hour.
- Which Filament versions does lara-zeus/replies support?
- On Filament 5, install the ^3.0 release line, which is the supported path; the 2.x line will not work there. On Filament 3 or 4, pin 2.0.3 exactly rather than floating the constraint. Confirm what your project actually resolves with composer why-not filament/filament before assuming a version.
- Why does the package description call it a bookmark manager?
- The repository tagline says it is a bookmark manager for Filament resources, while every other artifact, including the overview and source layout, describes threaded replies and comments. Treat this as a documentation-maturity signal rather than a functional claim, and resolve it by reading src/ during your spike. Do not repeat the bookmark framing in a plan or stakeholder deck until you have verified the behavior yourself.
- How do I attach replies to an existing Eloquent model?
- Add the package trait to the model and let the published migration create the polymorphic replies table, so any model can own a thread without schema changes of its own. Then render the reply component wherever that model is displayed in your Filament surface. If you need a custom reply class or extra columns, decide that before you build features on top of the default, since swapping may require a fork.
- Does lara-zeus/replies support nested replies, and is there a depth limit?
- Yes, replies nest, producing threaded conversations rather than a flat comment list. The documented validation spike covers two nesting levels, and no maximum depth is stated in the documentation. Enforce your own maximum depth in the UI and query-log a three-level thread before shipping, because eager-loading behavior for nested replies is not documented.
- Can I control who is allowed to post a reply?
- Authorization hooks such as a canReply closure are not documented, so assume you gate access yourself until your spike proves otherwise. Because the plugin inherits the Filament panel's auth guard, baseline access follows the panel, but that is not the same as per-thread permission. If a thread must be less visible than its parent resource, wrap the render in an explicit policy check rather than relying on the parent resource policy.
- Does it include notifications, mentions, attachments, or moderation tools?
- No. This is a thin polymorphic reply layer, and notifications, mentions, attachments, moderation, and audit trails are not claimed features, nor does the release history suggest they are coming. It is also a Filament-first package: on a customer-facing or non-Filament surface the dependency reduces to a replies table plus nesting logic you could write yourself. Use it where the Filament integration is the value, and plan for those extras as your own work.
- Is the reply model swappable via config, or do I have to fork the package?
- Whether the reply model can be swapped through configuration is not documented, so verify it during the spike before committing to custom behavior. If it is not swappable, customization becomes a fork decision, and that decision should be made before you build features on the default model. Write the fork or vendor procedure down at adoption time, along with a named internal owner.
- Will rendering a long thread cause N+1 queries?
- It is a plausible risk that is not addressed in the documentation, so measure rather than assume. Query-log a thread of roughly twenty replies across three nesting levels and eager-load the relation in the parent query if the log shows repeated queries. Also test the surface in staging with the cached component manifest flow, since a Livewire component-registration defect has affected this package before.
- Is lara-zeus/replies actively maintained, and how do I upgrade from 2.0.3 to 3.0.0?
- Expectation should be low: a single maintainer, around two stars, and zero dependents mean no one else's production traffic is de-risking the package. There is no upgrade guide for 2.0.3 to 3.0.0 and the schema impact is unstated, so prefer fresh installs, diff the relevant pull requests, and re-read the published migration. Pin exact versions, name an internal owner, and rehearse forward and rollback migrations on a production copy before you rely on it.