Fortify Bootstrap Laravel Package

Getting Started

1. Check the baseline before installing. This package targets the Laravel 8/9 + Fortify 1.x + Bootstrap 5 stack from early 2022. If your app is on Laravel 10+, on Vite, or already uses Breeze/Jetstream/laravel-ui, budget time for adaptation — the views and asset stubs will not drop in unchanged.
2. Install the dependency with Composer (composer require kamona/fortify-bootstrap). Verify the resolved laravel/fortify constraint — the package pins an old Fortify major, so it may force a downgrade on modern apps.
3. Run the installer documented in the README. It is an Artisan command that publishes Fortify views (login, register, forgot/reset password, verify email, confirm password, two-factor challenge), profile views, a layout, and asset stubs, and typically registers a FortifyServiceProvider and enables Fortify.
4. Wire the front end: npm install && npm run dev (or npm run build), then check resources/sass/app.scss and resources/js/app.js actually import Bootstrap and Bootstrap Icons. Run php artisan migrate for the users/2FA tables.
5. Smoke-test the first use case: visit /login, /register, /forgot-password, /user/profile, and /user/two-factor-authentication. A fresh internal admin tool or back-office app is the ideal fit — you get Fortify's backend (auth, password reset, profile updates, 2FA) with styled Blade forms instead of hand-rolling them.

Where to look first: the README (only authoritative source), config/fortify.php, app/Providers/FortifyServiceProvider.php, and the published resources/views/auth/* and resources/views/profile/*.

Implementation Patterns

• Treat it as a one-shot scaffold, not a runtime dependency. Commit every published view into your repo, then ideally remove the Composer package. The point of the package is the initial Blade output; you own it afterwards.
• Drive behavior through config/fortify.php feature flags. Toggle Features::registration(), updateProfileInformation(), updatePasswords(), twoFactorAuthentication(), emailVerification(). When you disable a feature, prune the corresponding nav links and views — the package's navigation assumes everything is on.
• Keep custom logic in Fortify Actions, not in views: app/Actions/Fortify/CreateNewUser, UpdateUserProfileInformation, UpdateUserPassword, plus Fortify::authenticateUsing(), Fortify::redirects(), and Fortify::*View() bindings in the service provider.
• Swap the layout for your app shell. The published layout is deliberately generic; replace @extends/component wrappers so auth screens inherit your real navigation, flash messages, and asset stack. If the package ships anonymous components (inputs, buttons, validation errors), copy them into resources/views/components and edit there.
• Enable 2FA properly: turn on twoFactorAuthentication in config, publish Fortify's migrations, and confirm bacon/bacon-qr-code and pragmarx/google2fa are installed — otherwise the QR/recovery-code screens render but fail.
• Multi-area apps: duplicate the auth views under a second directory (e.g. resources/views/admin/auth) and point Fortify::loginView() etc. at them per guard/provider. Fortify is effectively single-guard, so keep admin and public auth on separate route groups or separate apps rather than fighting the pipeline.
• Upgrade workflow: when Fortify changes, diff the package's views against the installed laravel/fortify views and port the deltas into your copies.

Gotchas and Tips

• Unmaintained since March 2022 (6 stars, no dependents). The Fortify view contracts have moved on (2FA challenge data, confirm-password view wiring, response contracts). Expect to repair published views after any Fortify upgrade; never trust them as-is on a current Fortify.
• Asset pipeline mismatch is the #1 failure. Laravel 8-era Mix/webpack stubs do not work on Laravel 9+ Vite. Port the Bootstrap/Bootstrap Icons imports into vite.config.js, resources/js/app.js, and resources/sass/app.scss, then delete the stale build config.
• Publishing with --force silently clobbers your edits. Publish once, commit, and use tag-scoped publishing (--tag=...) for anything you need to re-pull.
• "View [login] not found" usually means config/fortify.php 'views' => true is set while the package expects custom view names, or vice versa. Check Fortify::loginView() and the views key together.
• Route collisions: if Breeze, Jetstream, laravel-ui, or a manual auth scaffold is also installed, you will get duplicate /login definitions. Run php artisan route:list --path=login and remove the other provider.
• Don't rename form fields. Fortify's LoginRequest and actions expect email, password, password_confirmation, code, recovery_code. Restyle the markup freely, but keep the name attributes and the @csrf token.
• Rate limiting surprises: Fortify's login limiter returns 429 after repeated failures — useful to test deliberately, since the package's error display may not surface it clearly.
• Debugging checklist: php artisan route:list --path=user (Fortify routes registered?), php artisan about (providers loaded?), storage/logs/laravel.log (view/missing-class errors), and confirm the service provider is listed in config/app.php or bootstrap/providers.php.
• Extension points to prefer over editing vendor code: Fortify Actions, Fortify::ignoreRoutes() + your own routes, custom LoginResponse/TwoFactorLoginResponse implementations, and middleware around the Fortify route group.
• Long-term recommendation: because the package is small, MIT-licensed, and stale, copy the views in, verify them against your Fortify version, and drop the dependency. You lose nothing and stop carrying an unmaintained package in composer.lock.