- How do I install beyondcode/laravel-confirm-email?
- Install it with Composer using composer require beyondcode/laravel-confirm-email, then publish the package assets and run the migration that adds the confirmation columns to your users table. Add the provided trait to your User model and swap the trait imports in your LoginController and RegisterController so the default auth flow sends the confirmation notification. Finally, configure APP_URL and your mailer so the signed confirmation links point at the right host.
- Which Laravel and PHP versions does laravel-confirm-email support?
- Support is defined by the Composer constraints declared in the release you install, so check those against your PHP and Laravel support matrix rather than inferring from the changelog. Release 2.5.0 is a compatibility-only update authored by laravel-shift automation, and the package is a single-maintainer project in maintenance mode, so newer Laravel majors may lag. Verify the constraints in CI with a real install and test run before committing to an upgrade.
- Does this package work with Laravel Breeze, Jetstream, or Fortify?
- No, and you generally should not add it there. Laravel ships email verification natively through the MustVerifyEmail contract, and Breeze, Jetstream, and Fortify all include the verification routes, middleware, notification, and views out of the box. This package targets classic laravel/ui controller-based authentication, so installing it alongside a modern starter kit creates redundant, colliding verification paths. Decide package versus native early and delete the losing implementation.
- How do I protect routes so unconfirmed users cannot access them?
- Register the package's confirmation middleware and apply it to the route groups that require a verified account, keeping public routes outside that group. The higher-stakes risk here is a middleware that fails open: if it is misconfigured, unconfirmed users get through and everything still looks successful. Add a regression test that asserts an unconfirmed user is redirected, not just that a confirmed user succeeds.
- How do I resend the confirmation email to a user?
- The package registers the routes and controller actions needed to resend a confirmation link to the currently authenticated but unverified user. Point your UI at the resend route and make sure it is only reachable by signed-in users who have not yet confirmed. Test the resend path alongside the initial confirmation, already-verified, and expired-link paths.
- Why do my confirmation links return an invalid signature error?
- The most common cause is a misconfigured APP_URL: the signed URL is generated against one host and validated against another, so every confirmation click fails. Check your environment configuration, any proxy or load balancer host rewriting, and the domain used when the mail is generated. A quick staging test that registers a user and clicks the real emailed link catches this before production.
- How do I customize the confirmation email view or the redirect after confirmation?
- Publish the package's views and configuration, then edit the notification template and the redirect targets to match your application's look and navigation. The configuration also controls link expiration, so you can tune how long a confirmation link stays valid. If you shorten expiration, document it and test the expired-link path so users get a clear resend option rather than a dead end.
- How should I test the email confirmation flow?
- Use Laravel's mail and notification fakes to assert the confirmation message is sent on registration, then extract the signed link and assert it verifies the user and redirects correctly. Cover the resend path, an already-verified user, an expired or tampered link, and the middleware blocking an unconfirmed user. These four or five paths are the whole risk surface, so a small feature test suite gives strong coverage.
- Is beyondcode/laravel-confirm-email still maintained and safe for production?
- It is a small, security-adjacent package from a single maintainer and appears to be in maintenance mode, with limited ecosystem pressure to catch regressions. Treat the bus factor as a tracked risk: record an internal owner and a documented fork-or-replace contingency instead of assuming it is safe indefinitely. Because the surface area is only a handful of files, forking or replacing it later is cheap if you plan for it now.
- What is the alternative to this package for email verification in Laravel?
- Use Laravel's built-in email verification: implement MustVerifyEmail on your user model and rely on the routes, middleware, and notification provided by Breeze, Jetstream, or Fortify. That path is first-party, maintained with the framework, and avoids adding a dependency for a commodity feature. Reach for this package only when you are on legacy controller-based auth and want to close the verification gap without an auth rewrite.