Weave Code
Terms Module Bundle Laravel Package
rich-id/terms-module-bundle
A Laravel/PHP module bundle for adding terms and conditions management to your app. It packages common model, migration, and routing pieces so you can publish reusable terms content and integrate it into existing projects with less boilerplate.
A magic bundle
Frequently asked questions about Terms Module Bundle
- How do I install rich-id/terms-module-bundle in a Laravel application?
- Install it with Composer using composer require rich-id/terms-module-bundle. After that, publish the package's config file and migrations with the vendor:publish command, then run php artisan migrate. Finally, wire the provided trait or contract into your authenticatable user model so the consent checks can resolve a user. There are no external services, credentials, or queue workers involved, so the setup is a standard Laravel package install.
- Which Laravel and PHP versions does this terms module support?
- There is no published, confirmed support matrix for Laravel 10, 11, or 12, nor for PHP 8.2, 8.3, or 8.4. Before committing, read the composer.json constraints in the repository and run a short compatibility spike on your target versions. The v3.0.3 release fixed compatibility with a user interface contract, which shows the enforcement points are type-hinted and version-sensitive. Pin the version constraint rather than floating it given the low release cadence.
- How does versioned terms acceptance tracking work in this package?
- The package stores terms and privacy policy documents as versions and records which revision each user has accepted. Acceptance is exposed through a voter-style authorization check, most likely surfaced via Laravel's Gate or Policy layer rather than custom middleware. That means you can gate routes, controllers, or UI elements on whether the current user has accepted the current version. The exact version semantics, such as integers versus semver and how current is designated, should be confirmed in the package source during your spike.
- Do I need to add a trait or implement a contract on my User model?
- Yes, integration requires touching your authenticatable model, but the exact shape depends on what the v3.0.3 fix targeted. It may be Laravel's Illuminate\Contracts\Auth\Authenticatable, a package-provided contract, or an internal interface the voter type-hints against. Confirm this first, because it determines whether integration is a one-line trait addition or a contract-plus-method implementation on every authenticatable model. Any secondary guard principal, impersonation feature, or custom user provider must satisfy the same interface or the voter will fail.
- How do I publish the migrations, config, and language files?
- Use Laravel's standard vendor:publish command and select the terms module provider tag to copy migrations, config, and localization files into your application. Publishing lets you edit table names, version designation rules, and translation strings without forking the package. Review the published migration before running it to confirm whether acceptance records are append-only or a latest-version pointer on the users table.
- Is the acceptance history append-only and suitable for compliance audits?
- That is the single most important thing to verify in your spike, because the package description mentions acceptance history per user but not the storage model. For evidentiary compliance you typically need an append-only record of who accepted which version, when, and from where. A simple latest-accepted-version pointer on the users table is not sufficient for audit purposes. Inspect the published migrations and models directly, and plan to extend the schema if the default is only a pointer.
- Does it work with Sanctum, Fortify, Breeze, or multi-guard setups?
- There is no confirmed support matrix for Sanctum tokens, multi-guard configurations, or starter kits like Fortify and Breeze. The package is type-hinted against a user interface, so any guard principal resolved at runtime must satisfy that same contract. Test your specific guard setup, including admin guards and API token consumers, during the spike. Where your app gates on custom middleware or front-end route guards, a thin adapter wrapping Gate::allows in middleware is the usual path.
- How do I check whether a user has accepted the current terms version?
- The package exposes the check as a voter, so you typically call it through Laravel's Gate, for example Gate::allows with the ability the package registers. That keeps the check consistent across controllers, middleware, policies, and Blade directives. Because it is framework-native, you can also wrap it in custom middleware for route-level enforcement. Confirm the exact ability name and voter registration in the service provider.
- Can I localize the terms content and consent messages?
- Yes, localization support is listed as a feature and translation files are publishable. You can ship policy text and consent prompts in multiple locales and edit the strings after publishing. Keep in mind that legal documents themselves usually need versioning per locale, so validate that the versioning model covers translated variants before relying on it for compliance.
- What are the risks of using a package with two GitHub stars and a single maintainer?
- The package is thinly validated, with low download and dependent counts, a near-zero health score, and a single-maintainer bus factor. The MIT license and small surface area make forking cheap, which is a real escape hatch. A compatibility break with a core user interface reached a published version in v3.0.3, which suggests CI coverage across model shapes and auth configurations is thin. Treat yourself as the de facto QA function: pin the version, add your own regression tests, and confirm whether the maintainer has a vulnerability disclosure process.
Weaver
How can I help you explore Laravel packages today?