- What is taldres/laravel-waitlist used for?
- It is a privacy-first, headless waitlist package for Laravel apps that need early-access signups without building a custom state machine. It covers lists/projects, double opt-in, tokenized unsubscribe, versioned consent records, atomic state changes, data access and erasure APIs, reporting, events, and CSV export. It is a good fit when consent provenance and lifecycle states matter more than a ready-made dashboard.
- How do I install and configure taldres/laravel-waitlist?
- Install it with Composer, publish the migrations and config, run migrate, and configure your waitlist lists/projects. For greenfield Laravel 13 apps, the documented path includes migrations, config, optional waitlist:install --mail for mail/view scaffolding, and a compatible JS client. Bind a spam protector explicitly, such as TimeTrapSpamProtector or ClosureSpamProtector, rather than relying on removed v0.1.x methods.
- Does taldres/laravel-waitlist support Laravel 13?
- Version 0.2.0 is built around Laravel 13 conventions such as attributes, form requests, and container bindings, and it raises the package's minimum platform floor. Check the Composer constraint before upgrading an existing app. Greenfield Laravel 13 waitlists are the clearest fit; older Laravel apps should verify compatibility or stay on v0.1.x.
- How does double opt-in work in this Laravel waitlist package?
- A signup is stored first, then the package supports email verification through tokenized confirmation and unsubscribe links. In v0.2.0 the mail link semantics split GET and POST, so integrations that expected GET-only links must update confirm.store and unsubscribe handling. The package provides the flow and optional mail/view scaffolding, but your Laravel app remains responsible for actually sending mail.
- How are consent records and GDPR erasure requests handled?
- The package stores subscription cycles with versioned consent records and uses atomic state changes so consent history is not lost during transitions. It exposes data access and erasure APIs for subject requests, and reporting is designed to survive an erasure through aggregate rather than raw personal data. Importing confirmed addresses without mail is compliance-sensitive, so validate consent provenance before any CSV import.
- Does taldres/laravel-waitlist include a dashboard or send emails?
- No, it is headless by design: there is no dashboard and no built-in mail delivery. You get the waitlist domain, APIs, events, and CSV export, and you build the admin UI or public pages yourself. Optional mail and view scaffolding can be installed with waitlist:install --mail, but delivery still goes through your application's mailer and queues.
- Can I customize waitlist models, migrations, routes, and policies?
- Yes, the package is configurable and Laravel-native, so you can extend models, publish migrations, adjust routes, override policies, and bind a custom LinkGenerator. In v0.2.0, ListPolicy uses doubleOptIn() as a method and the link generator bindings are LinkGenerator and DefaultLinkGenerator. If you extend models, add factories and review exhaustive enum matches so new cases do not break static analysis or runtime matching.
- What breaks when upgrading taldres/laravel-waitlist from v0.1.x to v0.2.0?
- Treat v0.2.0 as an integration-breaking release, not a routine Composer update. Watch for removed verifySpamUsing()/spamProtector() methods, renamed confirmation URL generator bindings, the ListPolicy doubleOptIn change, new enum cases, factory attribute changes, and GET/POST mail route semantics. Review migrations carefully because publishing all migrations can duplicate the first five, and the MySQL/MariaDB wording migration shrinks project to 100 characters, which fails if longer data exists. Rebuild route cache after deploy.
- How do CSV import and reconfirmation work for existing waitlist signups?
- CSV import gives you a migration path from existing lists, but you must validate consent provenance before importing confirmed addresses without sending mail. Reconfirmation introduces a lapsed state and additional mail volume, so plan mail capacity and compliance sign-off. The release guidance says to leave reconfirm_after_days unset if older JS clients are still deployed.
- How do I test and secure waitlist signups and public endpoints?
- Use feature tests around signup, confirmation, unsubscribe, state transitions, and dispatched events, and include cases for reconfirmation and erasure APIs. Public count and position endpoints are opt-in and privacy-conscious, with position by token and rounded counts, but they still need rate limiting and WAF review. Older JS clients do not read count, position, challenge, or answer_by, so upgrade the client or defer those endpoints, and include route:cache in your deploy runbook.