Laravel Boilerplate Laravel Package

Getting Started

This is not a Composer package you require into an existing app — it's a full Laravel application skeleton. You consume it by cloning/forking the repo, not by installing it as a dependency.

git clone https://github.com/rappasoft/laravel-boilerplate.git my-app
cd my-app
composer install
cp .env.example .env
php artisan key:generate
# set DB creds in .env
php artisan migrate --seed
npm install && npm run dev   # or npm run prod

Where to look first:

1. routes/backend.php and routes/frontend.php — the app is split into Backend (admin) and Frontend (public) via route files, separate controllers, and separate layouts. Understanding this split is the whole mental model.
2. app/Http/Controllers/Backend/ — user management, roles, permissions live here. This is your reference for the "boilerplate pattern."
3. app/Models/ + database/seeders/ — the seeded roles (Administrator, User) and permission set are what the first login depends on.
4. Docs at https://laravel-boilerplate.com — still the best source for the localization, 2FA, social login, and CRUD conventions.
5. .env.example — note the social login keys, 2FA settings, and ACTIVE_THEME which switches the frontend theme.

First use case: log in as the seeded admin, then use the built-in Backend > Access Management screens (Users, Roles, Permissions) to confirm the RBAC stack works before you touch any code. That single flow exercises auth, roles/permissions, localization, and the Backend layout all at once.

Implementation Patterns

Treat it as a codebase you own, not a library you call. Everything is publishable/overridable by editing files directly. There is no vendor boundary.

• Backend/Frontend split. Controllers, requests, views, and route files are duplicated under Backend and Frontend namespaces. When adding a feature, decide which side it belongs to first; the conventions (middleware groups, layouts, breadcrumbs) are already wired per side. Fight the split and you'll spend a day undoing it.
• CRUD generation pattern. The existing User/Role/Permission controllers are the template. Copy the shape: IndexController (list + datatables), CreateController/StoreRequest, EditController/UpdateRequest, DestroyController, plus a FormRequest with authorize() calling the permission check. Follow this and every new resource feels native.
• RBAC via spatie/laravel-permission. Guard against hardcoding hasRole('Administrator') — use the permission middleware (permission:view users) that the boilerplate sets up, since roles are seeded and editable at runtime.
• Localization. Content models use spatie/laravel-translatable. UI strings live in resources/lang/{locale}/. When adding a translatable field, add the column as json and the property to $translatable — then the existing language-switcher and Backend form partials handle the rest.
• Form macros. app/Providers/FormServiceProvider (or equivalent) defines Bootstrap form macros. Reuse Form::text(), Form::select() etc. instead of raw HTML so validation error state renders consistently.
• Events/Listeners for side effects. User creation fires events used for 2FA and social account linking; hook there rather than overriding controllers.
• Auth scaffolding. 2FA (google2fa), social login (laravel/socialite), email confirmation, and password expiry are already implemented. Configure via .env + config/boilerplate.php rather than rewriting the auth controllers.

Integration tips. If you have an existing Laravel app, don't merge this wholesale — cherry-pick the pieces you want (Backend layout, RBAC wiring, Form macros, 2FA controllers) by diffing against a fresh Laravel 8 install. That's realistically the only way to "leverage" it in a modern project.

Gotchas and Tips

• The repo is archived (last release Jan 2022, pinned to Laravel 8). There will be no security patches, no PHP 8.2/8.3 fixes, and no compatibility with Laravel 9+. For anything customer-facing, plan an exit or a fork you maintain yourself. This is the single biggest day-to-day risk.
• It's not composer require-able. There's no consumable package API, no service provider to register, no facade. Attempting require rappasoft/laravel-boilerplate will fail or produce a useless skeleton inside vendor/. Clone or fork.
• Laravel 8 lock. composer.json pins framework and dependency versions that conflict with Laravel 10/11 (e.g., spatie/laravel-permission, laravel/socialite, older symfony/*). Upgrading the whole app is a project, not a task.
• Seeded credentials. Sample users and a default admin exist in seeders — never ship these to production. Check database/seeders/ and the README for default passwords; remove or force a reset on first deploy.
• config/boilerplate.php is the source of truth for feature toggles (registration, email confirmation, 2FA, social providers). Editing .env alone won't enable features if the config is cached — remember php artisan config:clear after changes.
• Route cache + dual route files. Because Backend and Frontend routes live in separate files with overlapping names, php artisan route:cache occasionally surfaces name collisions when you add resources. Prefix new resource names (backend.users.*, frontend.posts.*).
• Theme/asset quirks. The active theme is switched via env, and compiled assets are path-specific. Mixing Backend and Frontend layouts requires matching the theme's partials; copying views between themes silently drops CSS.
• Form macros are the debugging hotspot. When a field renders without validation styling, it's almost always a form built with raw Blade instead of the macro — grep the macro definition before touching CSS.
• Fork responsibly. If you must keep it, immediately: pin the fork, upgrade Laravel + PHP in a branch, replace abandoned packages, and add a CI matrix. Otherwise, migrate toward Laravel Breeze/Jetstream + spatie/laravel-permission + Filament for the admin side — that combination covers 90% of what this boilerplate gave you, actively maintained.
• Extension points that still exist (useful for forks): custom Backend middleware groups, the FormServiceProvider macros, spatie/laravel-translatable on models, and event hooks on user lifecycle. These are the seams worth preserving if you're maintaining a fork.