- How do I install nowendwell/laravel-terms in a Laravel application?
- Install it with Composer using composer require nowendwell/laravel-terms, then publish the package's config file and migrations and run php artisan migrate. You will typically need an existing users or subjects table for the polymorphic acceptance records to point at. After that, wire the provided middleware or trait into the route or model where acceptance must be enforced. Expect a short spike rather than a large integration project: roughly one to three days including tests.
- Does laravel-terms support Laravel 12, and which Laravel versions can I use?
- Version 2.6.0 added Laravel 12 support as a purely additive, semver-minor release, so teams on Laravel 10 or 11 see no change to the integration surface. The changelog does not spell out PHP version bounds, so confirm the Composer constraints yourself rather than inferring them, since Laravel 12 requires PHP 8.2 or newer. Check that the CI matrix actually exercises the Laravel and PHP combinations you plan to run in production.
- How does versioned terms acceptance and re-acceptance work in laravel-terms?
- You define terms as versioned documents, and the package records which user accepted which version along with a polymorphic link from the accepting entity to that version. When you publish a new version because the policy text changed, existing acceptances remain tied to the old version, which lets you detect who still needs to re-accept. Your enforcement layer then blocks or prompts those users until they accept the current version. This version-plus-acceptance model is what makes the data defensible in an audit, unlike a single boolean flag.
- How do I enforce terms acceptance in my Laravel routes and views?
- The package ships middleware, Blade directives, and Eloquent traits, so enforcement usually happens at the HTTP boundary by attaching middleware to the routes or route groups that require consent. Blade directives can then hide or show content and acceptance prompts in your views, while the traits keep the model-side relationships and checks convenient. Apply it against one guard first to validate the flow before rolling it out across web, API, and admin areas. Keep your own thin adapter around the package's public API so the enforcement points stay replaceable.
- What does an acceptance record actually store, and is it defensible for an audit?
- The package is designed to record which entity accepted which document version, which is the core of a defensible audit trail. Whether it also captures a timestamp and request context such as IP address and user agent is not confirmed by the release notes, so verify the published schema during your spike before relying on it for compliance reporting. If the context columns you need are missing, add them in your own migration or wrapper rather than assuming they exist. Only version-plus-acceptance-plus-context is defensible if you are asked to prove consent after the fact.
- Does laravel-terms work with multiple guards and multi-tenant applications?
- That is an open question rather than a documented guarantee: the enforcement mechanism may be middleware, a policy, or a listener, and how cleanly it composes with web, API, and admin guards or tenant scoping needs to be verified. Because acceptances are stored polymorphically, multiple accepting models are structurally plausible, but tenant isolation depends on your own scoping strategy. Validate this in a spike with at least two guards and, if applicable, a tenant-scoped user model before committing.
- Is laravel-terms suitable for e-signatures or contract lifecycle management?
- No. The package is deliberately narrow: it proves which user accepted which document version and when, and it will not carry contract lifecycle management, e-signature, or jurisdiction-specific legal workflow. If that is your requirement, choose a dedicated platform instead of stretching this schema, which will produce tables you regret. A reasonable alternative for simple needs is hand-rolling your own versions and acceptances tables, but that is exactly the cross-cutting concern most teams should not maintain themselves.
- How should I handle data retention and GDPR or CCPA deletion with laravel-terms?
- Acceptance records on a compliance path often need to outlive the user record under legal hold, while erasure requests still require you to remove or anonymise personal data. The release notes do not document the package's deletion semantics, so check whether the schema cascades on user delete and decide deliberately. Prefer anonymising the subject reference over deleting the acceptance row if you need to preserve the audit trail. Document this policy before launch, because it is difficult to retrofit once production data exists.
- How do I test that users who have not accepted the terms are actually blocked?
- Compliance features fail silently, so the dangerous case is a missing row rather than an exception. Write a feature test that hits a protected route as an unauthenticated-to-consent user and asserts they are redirected or rejected, then accept the current version and assert the same route passes. Add a second test that publishes a new document version and asserts the user must re-accept. Also assert the persisted record references the expected document version, not just that the request succeeded.
- What are the maintenance and production risks of adopting laravel-terms?
- The main risk is maintainership: this is a single-maintainer package sitting on a compliance-critical path, and v2.6.0 brought the project's first outside contributor without changing the underlying bus factor. Mitigate cheaply by pinning to a known-good version, keeping a thin adapter or wrapper around the package's public API so it can be swapped, and treating a vendor fork as your fallback. Upgrade risk between minor releases is low, but treat the changelog's silence on PHP constraints and record contents as unverified and confirm them in a short technical spike.