240 Laravel Interview Questions and Answers (2026)

Laravel is a free, open-source PHP web framework built on the MVC pattern that provides an expressive, elegant syntax and batteries-included tooling for building modern web applications quickly.

• MVC architecture: Separates data (Model), presentation (View) and logic (Controller) for maintainable code.

• Eloquent ORM: An ActiveRecord ORM to work with the database using PHP objects instead of raw SQL.

• Blade templating engine: Lightweight templating with layouts, components and directives, compiled to plain PHP.

• Routing and middleware: Clean route definitions plus middleware for filtering requests (auth, CSRF, throttling).

• Artisan CLI: Command-line tool for scaffolding, migrations and running tasks.

• Built-in ecosystem: Migrations, queues, events, authentication, testing, and packages like Sanctum, Passport and Horizon.

Artisan is Laravel's built-in command-line interface: it automates repetitive development tasks like scaffolding code, running migrations, clearing caches and managing queues.

• Why it is used:

  • Speeds up development by generating boilerplate (controllers, models, migrations) and running framework tasks from the terminal.

  • You can also write your own custom commands via php artisan make:command.

• Common commands:

  • php artisan serve: starts the local development server.

  • php artisan migrate: runs database migrations.

  • php artisan make:model Post -mc: creates a model with migration and controller.

  • php artisan route:list: lists all registered routes.

  • php artisan tinker: an interactive REPL for the app.

  • php artisan cache:clear and config:cache: manage caches.

Core PHP is the raw language where you write everything yourself; Laravel is a framework layered on top of PHP that gives you structure, conventions and ready-made components so you build faster and more securely.

• Structure: Core PHP has no enforced architecture; Laravel enforces MVC and a clear directory layout.

• Built-in features: Routing, authentication, ORM, validation and templating come out of the box; in core PHP you build or wire these manually.

• Security: Laravel handles CSRF protection, SQL injection prevention (via Eloquent/query builder) and XSS escaping automatically.

• Database access: Eloquent ORM and migrations vs manual queries with mysqli or PDO.

• Maintainability and testing: Laravel promotes reusable, testable code with dependency injection and a service container; core PHP leaves this to the developer.

Laravel stands out among PHP frameworks (Symfony, CodeIgniter, Yii, CakePHP) for its developer-friendly syntax, a rich integrated ecosystem, and strong community that together make common tasks trivial.

• Expressive syntax: Clean, readable APIs (Eloquent, Blade) reduce boilerplate compared to more verbose frameworks.

• Complete ecosystem: First-party tools like Sanctum, Passport, Horizon, Telescope, Nova, Forge and Vapor cover auth, queues, monitoring and deployment.

• Built on solid foundations: It reuses battle-tested Symfony components while adding a friendlier layer on top.

• Convention over configuration: Sensible defaults get you productive fast with minimal setup.

• Community and learning resources: Large community, extensive docs and Laracasts lower the learning curve.

Yes, Laravel supports full-stack development: it powers the backend and can render the frontend via Blade, or serve as an API backend for JavaScript SPAs and mobile apps.

• Server-rendered frontend: Blade templates render HTML directly, ideal for traditional multi-page apps.

• Modern reactive stacks: Livewire builds dynamic UIs in PHP, and Inertia.js bridges Laravel with Vue or React without building a separate API.

• API backend: Expose JSON APIs (with Sanctum/Passport auth) consumed by a decoupled SPA or mobile client.

• Asset tooling: Vite (via laravel/vite-plugin) bundles CSS and JavaScript for the frontend.

Composer is PHP's dependency manager; Laravel uses it to install the framework itself, manage third-party packages, and autoload all classes following the PSR-4 standard.

• Dependency management: composer.json declares required packages and versions; composer install resolves and downloads them into vendor/.

• Autoloading: Composer generates an autoloader so you never manually require class files.

• Creating projects: composer create-project laravel/laravel app scaffolds a new Laravel app.

• Lock file: composer.lock pins exact versions so every environment installs identical dependencies.

Setting up a Laravel project involves installing prerequisites, creating the project with Composer, configuring the environment, and running the development server.

1. Ensure prerequisites: PHP, Composer, and a database (plus Node/npm for frontend assets).

2. Create the project with composer create-project laravel/laravel myapp (or laravel new myapp via the installer).

3. Configure the environment in .env (database credentials, app URL); the app key is set with php artisan key:generate.

4. Run migrations with php artisan migrate to build the schema.

5. Install and build frontend assets with npm install and npm run dev if needed.

6. Start the server with php artisan serve and visit the local URL.

Laravel Mix is a thin, expressive wrapper over webpack that lets you define asset compilation steps with a fluent API, hiding webpack's complex configuration. In newer Laravel apps it has largely been replaced by Vite, but the concept is the same.

• What it does:

  • Compiles and bundles JS/CSS, transpiles ES6, processes Sass/Less, and handles versioning.

  • Configured in webpack.mix.js with chained method calls.

• Why it simplifies things:

  • No hand-writing verbose webpack config for common tasks.

  • Built-in cache-busting via .version() and the mix() helper in Blade.

• Modern note: Laravel 9+ defaults to Vite, which is faster (native ES modules, hot module replacement); Mix is still supported for legacy projects.

Tinker is Laravel's interactive REPL (built on PsySH) that boots your entire application so you can run PHP code, query models, and test logic directly from the command line.

• How to start it: Run php artisan tinker; you get a live shell with the app bootstrapped.

• What you can do:

  • Query and create Eloquent models: User::count(), User::factory()->create().

  • Call any class, helper, or service; test relationships and jobs without writing a route.

  • Inspect config, dispatch events, and debug quickly.

• Why it's useful:

  • Fast feedback loop for exploring data and behavior without building UI or endpoints.

  • Caution: it hits your real database, so be careful running destructive commands in production.

The config/ folder holds all of the application's configuration files: plain PHP files that return an associative array of settings, one file per concern.

• One file per subsystem: Examples: app.php, database.php, cache.php, queue.php, mail.php, services.php.

• Values usually read from the environment: Files call env() to pull secrets/settings from .env, keeping credentials out of version control.

• Accessed via the config helper: Read anywhere with config('app.timezone'); never call env() outside config files because config:cache ignores .env once cached.

The app/Models directory holds your Eloquent model classes, each representing (and mapping to) a database table and encapsulating the data plus its relationships and query logic.

• Eloquent models: Each extends Illuminate\Database\Eloquent\Model and maps by convention to a snake_case plural table (User to users).

• What lives on them: Relationships (hasMany, belongsTo), casts, accessors/mutators, scopes, and $fillable/$guarded.

• Historical note: Introduced as a dedicated folder in Laravel 8; earlier versions placed models directly in app/.

A Laravel app follows a convention-based layout where each top-level directory has a clear responsibility, so code is predictable across projects. The main folders are app/, config/, routes/, database/, resources/, public/, storage/, and tests/.

• app/: The core code: controllers, models, providers, middleware, jobs. Autoloaded under the App namespace.

• routes/: Route definitions (web.php, api.php, console.php).

• config/: All configuration arrays for the framework and packages.

• database/: Migrations, seeders, and model factories.

• resources/: Blade views, plus uncompiled front-end assets (JS/CSS) and language files.

• public/: The web root and front controller index.php; compiled assets live here.

• storage/: Compiled Blade, file cache, logs, and user uploads (app/, framework/, logs/).

• bootstrap/, vendor/, tests/: App bootstrapping and cache; Composer dependencies; automated tests, respectively.

The vendor/ folder contains all third-party PHP packages installed by Composer, including the Laravel framework itself and the generated autoloader. It is machine-managed output, so you never edit it by hand.

• What's inside: Every dependency from composer.json plus vendor/autoload.php, which bootstraps class autoloading.

• Why never edit it:

  • Changes are wiped on the next composer install or composer update.

  • It is git-ignored and rebuilt from composer.lock, so edits aren't shared or deployed.

• Right way to change package behavior: Extend/override classes in your own code, submit a PR upstream, or use a fork/Composer patch, never modify files in place.

The app/ folder is the heart of your application: it holds nearly all the custom PHP classes you write, autoloaded under the App namespace via PSR-4.

• Common subdirectories: Http/ (controllers, middleware, form requests), Models/, Providers/ (service providers).

• Generated on demand: Artisan make: commands create folders like Console/, Jobs/, Events/, Mail/, and Policies/ as you need them.

• Autoloading: Mapped so App\ points at app/ in composer.json; add your own domain folders freely.

• Not here: Config, routes, views, and migrations live in their own top-level folders, not in app/.

The routes/ folder holds the files that map incoming URLs and commands to controllers or closures, split by the type of entry point (web, API, console).

• web.php: Browser-facing routes with the web middleware group: sessions, cookies, and CSRF protection.

• api.php: Stateless API routes, typically prefixed with /api and token-authenticated. In Laravel 11+ enable it with php artisan install:api.

• console.php: Closure-based Artisan commands and scheduled tasks.

• channels.php: Broadcasting authorization rules for WebSocket channels (when present).

• How they load: Registered via withRouting() in bootstrap/app.php, which applies each file's middleware group and prefix.

Routes map an incoming HTTP request (a URI plus a verb) to the code that handles it: a closure or a controller method. You define them in the route files using the Route facade.

• Defined with the Route facade:

  • Each method matches a verb: Route::get(), Route::post(), etc.

  • First argument is the URI, second is the action.

• Action can be a closure or controller: Inline closure for simple logic, or [Controller::class, 'method'] for real applications.

• Located in route files: routes/web.php, routes/api.php, etc., loaded by the framework at boot.

A route parameter is a dynamic segment of the URI captured and passed into the route's handler, letting one route serve many values (like an ID or slug).

• Defined with braces: /users/{id} captures whatever appears in that segment and injects it into the handler by name.

• Required vs optional: Add ? to make it optional ({id?}) and give the argument a default value.

• Can be constrained: Use ->where() (or global patterns) to restrict the value, e.g. digits only.

• Supports route model binding: Type-hinting a model resolves the parameter into the matching record automatically.

Laravel ships with a small set of route files in the routes/ directory, each dedicated to a distinct kind of entry point and loaded with its own middleware and settings.

• routes/web.php: Browser-facing routes with session state, cookies, and CSRF protection (the web middleware group).

• routes/api.php: Stateless API routes, prefixed with /api; opt-in via install:api on Laravel 11+.

• routes/console.php: Defines closure-based artisan console commands, not HTTP.

• routes/channels.php: Registers broadcasting channel authorization for WebSockets/events.

• Note: on Laravel 11+ these are wired up in bootstrap/app.php rather than a RouteServiceProvider.

Both define routes, but web.php is for stateful browser traffic while api.php is for stateless API endpoints: they differ in the middleware group applied and the URL prefix.

• Middleware group:

  • web.php uses the web group: sessions, cookies, and CSRF protection.

  • api.php uses the api group: stateless, no session, typically token auth and rate limiting.

• URL prefix: api.php routes are automatically prefixed with /api; web routes have no prefix.

• Authentication style: Web relies on session cookies; API relies on tokens (Sanctum, Passport).

• Intended output: Web typically returns HTML views; API returns JSON.

Laravel provides a route method for each HTTP verb, and you choose the verb by the semantic intent of the action (reading vs creating vs updating vs deleting).

• GET (Route::get): Retrieve/read data; should be safe and idempotent (no side effects).

• POST (Route::post): Create a new resource or submit data; not idempotent.

• PUT / PATCH (Route::put, Route::patch): PUT replaces a resource fully; PATCH applies a partial update.

• DELETE (Route::delete): Remove a resource.

• Helpers for matching multiple verbs: Route::match(['get','post'], ...) for a specific set, and Route::any() for all verbs.

• HTML forms only send GET/POST: Use a @method('PUT') spoofing field to hit PUT/PATCH/DELETE routes.

Routing is how Laravel matches an incoming request to a handler. You register a URI and verb, optionally capture dynamic segments as parameters, and can attach a name to reference the route independently of its URL.

• Route methods:

  • One per verb: get, post, put, patch, delete; plus match and any.

  • Route::resource() generates a full set of CRUD routes at once.

• Parameters: Braces capture dynamic segments: {id}, optional {id?}, constrained with ->where().

• Named routes:

  • Attach a name with ->name() so you generate URLs via route('name') instead of hardcoding paths.

  • Changing the URI later won't break links or redirects that use the name.

A route group lets you share attributes (middleware, prefix, name prefix, namespace) across many routes at once, so you configure them in one place instead of repeating settings on each route.

• Common shared attributes:

  • middleware(): apply auth, throttling, etc. to every route in the group.

  • prefix(): prepend a URI segment like admin/.

  • name(): prepend a name prefix like admin..

  • controller(): share a single controller across routes.

• Benefits:

  • Less repetition (DRY) and fewer mistakes when settings change.

  • Clear organization of related routes (e.g. an admin or v1 API section).

  • Groups can nest, and attributes merge sensibly.

Named routes let you assign a unique name to a route so you can refer to it by that name instead of hardcoding its URL, making links and redirects resilient to URL changes.

• Defined with the name() method: Chained onto a route definition: Route::get('/profile', ...)->name('profile').

• Generate URLs and redirects by name: Use route('profile') or redirect()->route('profile') anywhere instead of the literal path.

• Decouples code from URLs: Change the URI once and every reference by name still works, no need to hunt for hardcoded paths.

• Pass parameters as an array: route('users.show', ['id' => 1]) fills route parameters; extra keys become query strings.

routes/web.php defines routes for your web interface: those that need session state, cookies, and CSRF protection, all provided by the web middleware group.

• Automatically assigned the web middleware group: Includes session handling, CSRF token verification, and cookie encryption, ideal for browser-facing pages.

• For stateful, human-facing traffic: Returning HTML views, handling form submissions, login flows, redirects.

• Distinct from routes/api.php: API routes are stateless, token-authenticated, and prefixed with /api; web routes assume a session.

• Loaded by the framework's bootstrap/service provider: Registered in bootstrap/app.php (Laravel 11+) or RouteServiceProvider in earlier versions.

Route::get() registers a route that responds to HTTP GET requests, mapping a URI to a closure or controller action, typically used for retrieving and displaying data.

• Takes a URI and a handler: The handler is a closure or an array like [Controller::class, 'method'].

• Responds only to GET (and HEAD): Other verbs have counterparts: Route::post(), put(), patch(), delete().

• Meant for safe, idempotent reads: Should not modify state; use POST/PUT/etc. for writes.

• Supports route parameters: Curly braces capture segments: /users/{id}.

A controller is the class that receives an HTTP request routed to it, coordinates the work needed to handle it, and returns a response: it is the "C" in MVC, grouping related request-handling logic in one place.

• Role:

  • Acts as the glue between routes and the model/view layers.

  • Should stay thin: orchestrate, don't hold heavy business logic.

• Created and located:

  • Generated with php artisan make:controller, stored in app/Http/Controllers.

  • Bound to a URL in the route files (e.g. routes/web.php).

• Features:

  • Method dependencies are auto-resolved via the service container (dependency injection).

  • Resource controllers map standard CRUD methods; invokable controllers use a single __invoke().

Laravel gives you helper methods on the response() factory (and helpers like redirect()) for each response type, and returning an array or Eloquent model auto-converts to JSON.

• JSON:

  • Return an array/model directly, or use response()->json($data, $status) for explicit control.

  • For API shaping use Eloquent API Resources.

• Redirects:

  • redirect('/path'), or redirect()->route('name') for named routes.

  • redirect()->back()->with('status', ...) flashes session data.

• File downloads:

  • response()->download($path, $name) forces a download.

  • response()->file($path) displays it in the browser instead.

MVC (Model-View-Controller) is the architectural pattern Laravel follows to separate concerns: models handle data, views handle presentation, and controllers coordinate between them in response to requests.

• Model: Represents data and business rules, usually an Eloquent model mapping to a database table.

• View: The presentation layer, typically Blade templates that render HTML from data passed in.

• Controller: Receives the request, pulls data from models, and returns a view or response.

• Why it matters:

  • Separation of concerns makes code testable, maintainable, and easier for teams to work on in parallel.

  • Note: Laravel is flexible, not dogmatic. Routes, middleware, form requests, and service classes complement MVC, and many teams push logic out of controllers into dedicated layers.

Facades provide a static-looking interface to services resolved from the container: syntactically they look static, but under the hood each call is proxied to a real instance the container resolves.

• They are a proxy, not truly static: A facade extends Facade and returns a container key from getFacadeAccessor(); __callStatic forwards the call to the resolved object.

• Why they're used: Concise, expressive syntax (Cache::get()) without manually resolving or injecting the underlying class.

• Still testable: Because they resolve from the container, you can swap the instance with Cache::shouldReceive() / fake() mocks in tests.

• Trade-off: They hide a class's real dependencies, which can obscure coupling; prefer explicit DI when dependencies matter for clarity.

The .env file stores environment-specific configuration (credentials, keys, mode) outside your code, letting the same codebase run differently across local, staging, and production without editing source files.

• Separation of config from code: Follows the twelve-factor principle: sensitive/variable values live in the environment, not in version control.

• How it's loaded: Read at boot via the vlucas/phpdotenv package; accessed with env('KEY'), though config files should wrap these values.

• Security: It's gitignored; .env.example is committed as a template without secrets.

• Best practice: Reference env() only inside config files so config:cache keeps working correctly.

Maintenance mode puts your app behind a friendly "be right back" page while you deploy or perform upgrades, returning a 503 status so users and load balancers know it's temporary.

• Enable / disable via Artisan: php artisan down enters maintenance mode; php artisan up restores normal service.

• Useful options on down:

  • --secret="token" lets you bypass the page by visiting a URL with that token.

  • --render="errors::503" pre-renders a view so it works even if the app can't boot.

  • --retry=60 sets the Retry-After header.

• How it works: Laravel drops a flag (a file under storage/framework) that middleware checks on each request.

• Caveat: zero-downtime deploys: With atomic-symlink deploy tools maintenance mode is often unnecessary; prefer the --secret bypass to keep testing.

Eloquent is Laravel's ActiveRecord ORM: each database table maps to a model class, and each row becomes an object instance, letting you work with the database using expressive PHP methods instead of raw SQL.

• ActiveRecord pattern: A model like User maps to the users table; instances carry both data and persistence methods (save(), delete()).

• Readable, fluent queries: User::where('active', true)->orderBy('name')->get() replaces verbose SQL.

• Relationships: Model methods express table relations and can be eager loaded with with() to avoid N+1 queries.

• Built-in features: Mass assignment protection, attribute casting, accessors/mutators, timestamps, soft deletes, and model events/observers.

• Trade-off to acknowledge: For very complex or high-volume queries raw SQL or the query builder may perform better; use the right tool.

Eloquent maps each table to a model and exposes expressive methods for the four CRUD operations, so you rarely write raw SQL.

• Create: Model::create([...]) (needs $fillable), or new Model then $model->save().

• Read: Model::all(), Model::find($id), where(...)->get(), or findOrFail().

• Update: Fetch, change attributes, $model->save(); or $model->update([...]).

• Delete: $model->delete(), or Model::destroy($id).

Both build and run SQL, but the Query Builder is a lower-level fluent interface returning plain result objects, while Eloquent is an ORM built on top of it that maps rows to model objects and adds relationships, events, casts, and scopes.

• Query Builder: closer to SQL:

  • Accessed via DB::table('users'); returns generic stdClass / collections.

  • Lighter and often faster for complex joins, aggregates, or bulk operations.

• Eloquent: object-oriented ORM:

  • Returns hydrated model instances with relationships, accessors, casts, and events.

  • More expressive and maintainable, with slight overhead from model hydration.

• They aren't exclusive: Eloquent delegates to the Query Builder, so you can chain builder methods (where, join) on Eloquent queries.

• Rule of thumb: use Eloquent for domain models and relationships; drop to the Query Builder for heavy reporting or bulk work.

Soft deletes let you "delete" a record without physically removing it: Eloquent sets a deleted_at timestamp and automatically excludes those rows from queries, so the data can be recovered or audited later.

• Setup: Add the SoftDeletes trait to the model and a deleted_at column via $table->softDeletes().

• Behavior: delete() sets the timestamp; a global scope hides trashed rows from normal queries.

• Querying trashed records: withTrashed() includes them, onlyTrashed() returns just deleted ones.

• Recovery and permanent removal: restore() clears deleted_at; forceDelete() removes the row for good.

• Check state with $model->trashed().

Eloquent is Laravel's ActiveRecord ORM: it maps tables to expressive PHP objects so you write less, safer, more readable code, while still letting you drop to raw SQL when you truly need it.

• Productivity and readability: Relationships, scopes, and eager loading express intent (User::with('posts')) instead of hand-written joins.

• Safety by default: Query bindings are parameterized, protecting against SQL injection without manual escaping.

• Features you'd otherwise rebuild: Timestamps, soft deletes, casts, accessors/mutators, events, and mass assignment guards come for free.

• Database portability: The query builder generates the right dialect, so switching between MySQL, Postgres, SQLite is smoother.

• When raw SQL still wins: Complex reporting, bulk operations, or performance-critical queries where the ORM adds overhead or the N+1 risk is high; use DB::raw() or DB::select() there.

The Query Builder is Laravel's fluent, database-agnostic interface for building and running SQL without writing raw strings: you chain methods on DB::table() and it compiles them into safe, parameter-bound SQL for your driver.

• Fluent chaining: Methods like where(), orderBy(), join(), limit() return the builder so calls compose readably.

• Safe by default: Uses PDO parameter binding, protecting against SQL injection automatically.

• Database-agnostic: The same code compiles to the correct dialect (MySQL, PostgreSQL, SQLite, SQL Server).

• Relation to Eloquent:

  • Eloquent is built on top of the Query Builder; every model query proxies to it, so the same methods are available on models.

  • Query Builder returns plain stdClass objects/arrays; Eloquent hydrates model instances.

Out of the box Laravel officially supports five relational database systems through its database layer, each with a first-party driver configured in config/database.php.

• Officially supported drivers:

  • MySQL (5.7+) and MariaDB.

  • PostgreSQL (10.0+).

  • SQLite (3.35+), often used for local dev and tests.

  • SQL Server (2017+).

• How they connect: Each uses a PDO driver behind the scenes; you pick one via the DB_CONNECTION env value.

• Beyond relational:

  • Redis is supported as a key-value store (cache, queues, sessions), though it is not a query-builder target.

  • Other engines (e.g. MongoDB) require community packages.

Migrations are PHP classes that define schema changes (creating/altering tables and columns) as version-controlled code, so your database structure lives alongside your application and can be applied consistently across environments.

• Structure:

  • Each migration has an up() method (apply the change) and a down() method (reverse it).

  • You describe schema with the Schema builder and Blueprint, not raw SQL.

• How they run:

  • php artisan migrate executes pending migrations; a migrations table tracks which have run so none repeats.

  • Migrations run in batches, enabling rollback of a whole batch.

• Benefits:

  • Version control: schema history is in Git, reviewable and reproducible.

  • Team consistency: everyone builds the same database from the same source.

  • Database-agnostic: the fluent builder works across MySQL, PostgreSQL, SQLite, etc.

  • Safe evolution: changes are additive and reversible instead of manual, error-prone SQL.

Factories are classes that define blueprints for generating fake model instances, used mainly for testing and seeding: they let you create realistic records quickly without writing repetitive setup code.

• Definition: A factory extends Factory and its definition() returns an array of default attributes, usually populated with the Faker library.

• Usage:

  • Model::factory()->create() persists a record; make() builds one in memory without saving.

  • Pass a count (factory()->count(10)) to generate many at once.

  • Override defaults by passing an array to create(['name' => 'Jane']).

• States and relationships:

  • States (state()) define named variations like an admin or unverified user.

  • Chain factories with has() / for() to build related models together.

A Seeder is a class that inserts data into your database, while a Factory defines how to generate fake model instances. They complement each other: factories produce the data, seeders decide what gets inserted and when.

• Seeder:

  • Created with php artisan make:seeder; logic lives in its run() method.

  • Good for fixed reference data (roles, categories) and for calling factories to bulk-fill tables.

  • Run with php artisan db:seed.

• Factory:

  • Created with php artisan make:factory; defines default attributes using Faker.

  • Produces randomized, realistic records ideal for testing and demos.

• How they combine: A seeder often calls a factory: User::factory()->count(50)->create().

Seeding populates your database with data through seeder classes run by Artisan. You write insertion logic in a seeder's run() method and trigger it, often chaining seeders from the central DatabaseSeeder.

• Steps:

  1. Generate a seeder: php artisan make:seeder UserSeeder.

  2. Add insertion logic in run(), using models, factories, or DB::table()->insert().

  3. Register it in DatabaseSeeder via $this->call(UserSeeder::class).

  4. Run php artisan db:seed (or --class=UserSeeder for one).

• Combined with migrations: php artisan migrate --seed or migrate:fresh --seed seed right after building the schema.

Blade is Laravel's built-in templating engine: it lets you write clean HTML views with lightweight directives, compiles them to plain PHP for speed, and caches the result so there's no runtime overhead.

• How it works:

  • Files use the .blade.php extension and compile to cached PHP, recompiled only when changed.

  • {{ $var }} echoes data and auto-escapes it to prevent XSS; {!! !!} outputs raw HTML.

• Key features:

  • Control directives like @if, @foreach, and @forelse replace verbose PHP tags.

  • Layout inheritance with @extends, @section, and @yield, plus reusable components (@include, <x-component>).

  • You can still write plain PHP, but directives keep templates readable.

• Why it matters: Separates presentation from logic while adding no runtime cost, since compilation happens once.

Both generate hidden form fields: @csrf adds the CSRF token that protects against cross-site request forgery, and @method spoofs HTTP verbs that HTML forms can't send natively.

• @csrf:

  • Outputs a hidden _token field; Laravel's VerifyCsrfToken middleware rejects any POST/PUT/PATCH/DELETE without a matching token.

  • Required on every non-GET form or you get a 419 error.

• @method:

  • HTML forms only support GET and POST; @method('PUT') adds a hidden _method field so Laravel routes it as the intended verb.

  • Used with method="POST" for update/delete routes.

@include composes views by dropping one partial into another, while @extends is the inverse: a child view declares that it inherits from a parent layout and fills that layout's sections.

• @include (composition):

  • The current view is in charge and inserts a smaller reusable piece into itself.

  • Direction: parent pulls child in.

• @extends (inheritance):

  • The layout is in charge; the child provides @section blocks that slot into the layout's @yield placeholders.

  • Direction: child injects itself into parent.

  • Only one @extends per view, and it must be the first thing.

• Rule of thumb: use @extends for the overall page skeleton, @include for repeated fragments within a page.

A Blade directive is a special @-prefixed keyword that Blade compiles into plain PHP, giving templates clean control-flow and helper syntax without raw <?php ?> tags.

• Compiled, not interpreted at runtime: Blade transpiles directives to cached PHP once, so there's no per-request parsing overhead.

• Common built-ins:

  • Control flow: @if, @foreach, @forelse, @switch.

  • Structure: @extends, @section, @include.

  • Helpers: @csrf, @auth, @can.

• Custom directives: Register your own with Blade::directive() in a service provider for repeated formatting logic.

A layout is a master Blade template that holds the shared page structure (HTML head, header, footer) with @yield placeholders, so individual pages inherit it and only supply the parts that change.

• Purpose: DRY page structure: Define the boilerplate once; every child page reuses it instead of repeating markup.

• How it connects: The layout exposes @yield slots; child views use @extends and fill them with @section.

• Two styles:

  • Inheritance-based (@extends/@yield), the classic approach.

  • Component-based (<x-layout> with {{ $slot }}), the modern preferred approach.

@yield defines a named placeholder inside a layout where a child view's matching @section content gets injected when the page is rendered.

• Lives in the parent layout: e.g. @yield('content') marks where page-specific markup goes.

• Pairs with @section: A child's @section('content')...@endsection fills the matching yield.

• Supports a default: @yield('title', 'Default Title') renders the second argument if no section is defined.

@include renders another Blade view inside the current one, inheriting the parent's variables and letting you pass extra data, ideal for reusable partials.

• Data sharing: The included view sees all of the parent's variables plus any array passed as the second argument: @include('shared.card', ['post' => $post]).

• Conditional variants:

  • @includeIf includes only if the view exists.

  • @includeWhen / @includeUnless include based on a boolean.

  • @includeFirst includes the first view that exists from a list.

• Note: For heavily reused UI with its own logic, components (<x-...>) are often cleaner than @include.

{{ }} escapes output (HTML-encodes it) while {!! !!} prints raw, unescaped HTML: escaping is Blade's primary defense against XSS.

• {{ $value }} is escaped:

  • It runs the value through htmlspecialchars(), turning characters like < and > into HTML entities.

  • So a malicious <script> in user input renders as harmless text, not executable code.

• {!! $value !!} is raw:

  • Outputs the string verbatim, so any HTML/JS runs in the browser.

  • Only use it for content you fully trust or have already sanitized (e.g. with a purifier).

• Why escaping stops XSS:

  • XSS works by tricking the browser into executing attacker-supplied markup; escaping neutralizes it by encoding, so the browser treats it as data.

  • Default to {{ }} everywhere and reach for {!! !!} only deliberately.

$loop is a special variable Blade makes available inside @foreach loops, exposing metadata about the current iteration so you don't have to track it manually.

• Position properties:

  • $loop->index (0-based) and $loop->iteration (1-based).

  • $loop->first and $loop->last are booleans for edge iterations.

  • $loop->even and $loop->odd help with alternating styles.

• Count properties: $loop->count (total items) and $loop->remaining.

• Nested-loop properties: $loop->depth gives nesting level, and $loop->parent accesses the outer loop's $loop.

Validation is the process of ensuring incoming data (usually from requests) meets defined rules before your application acts on it, protecting data integrity and giving users clear error feedback.

• What it enforces: Rules like required, email, min, unique:users, applied per field.

• How Laravel provides it: Through the validate() method on requests/controllers, the Validator facade, or Form Request classes.

• What happens on failure:

  • Laravel automatically redirects back with errors and old input for web requests, or returns a 422 JSON response for API requests.

  • Errors are shared with views via the $errors variable.

The Request object (an Illuminate\Http\Request instance) represents the incoming HTTP request and gives you a unified API to read input, headers, cookies, files, and metadata regardless of the HTTP verb.

• Getting the object: Type-hint Request $request in a controller method and Laravel injects it automatically, or use the request() helper.

• Retrieving input:

  • $request->input('name') reads any field with an optional default; $request->name is dynamic shorthand.

  • $request->only([...]) and $request->except([...]) grab subsets; $request->all() gets everything.

  • $request->query() targets query-string params specifically.

• Checking and inspecting:

  • $request->has('field') and $request->filled('field') test presence/non-empty.

  • $request->file('avatar') retrieves uploads; $request->method() and $request->path() expose metadata.

Laravel handles form input through the Request object: HTML forms POST data, Laravel binds it to the incoming request, and you retrieve, validate, and act on it. CSRF protection and method spoofing are built in.

• Retrieving input: Use $request->input('name'), $request->name, $request->only(), or $request->all().

• CSRF protection: Every non-GET form needs @csrf; the middleware rejects requests with a missing or invalid token.

• Method spoofing: HTML only supports GET/POST, so use @method('PUT') to send PUT/PATCH/DELETE.

• Validation then processing: Validate with $request->validate() or a Form Request, then persist and redirect (PRG pattern).

There is no functional difference: both return the currently authenticated user (or null). Auth::user() uses the Auth facade, while auth()->user() uses the auth() helper, which resolves the same underlying guard manager.

• Same result: Both proxy to the AuthManager / default guard and return the same instance.

• Style/preference: Facade reads well and is easily mockable in tests; the helper is terser and avoids importing the class.

• Choosing a guard: Both accept a guard: Auth::guard('api')->user() equals auth('api')->user().

CSRF (Cross-Site Request Forgery) tricks an authenticated user's browser into submitting an unwanted request; Laravel defends against it by requiring a secret, per-session token on state-changing requests.

• The attack: A malicious site fires a request to your app using the victim's existing session cookie.

• Laravel's defense:

  • The VerifyCsrfToken middleware checks a token on POST, PUT, PATCH, and DELETE requests.

  • Add the token to forms with the @csrf Blade directive, or send it via the X-CSRF-TOKEN header for AJAX.

• Why it works: An attacker's site can't read the token (same-origin policy), so forged requests fail validation.

• Exceptions: Stateless API routes (token/SPA auth) can be excluded via the $except array.

dd() ("dump and die") prints a formatted, interactive dump of one or more variables and then immediately halts execution, so you can inspect state at an exact point in the code.

• Behavior:

  • Renders variables using Symfony's VarDumper (expandable arrays/objects) then throws away the rest of the response.

  • Accepts multiple arguments: dd($user, $request->all()).

• Related helpers:

  • dump() dumps without stopping execution.

  • On Eloquent queries, dd() the builder or use ->dd() / ->dump() to see the SQL.

• When to use: Quick, ad-hoc inspection during development; remove before committing and prefer proper logging or Telescope for anything persistent.

Localization lets an app serve content in multiple languages by storing translatable strings in language files and retrieving them by key based on the current locale.

• Where translations live:

  • PHP arrays in lang/{locale}/ (e.g. lang/en/messages.php) keyed by short strings.

  • JSON files lang/{locale}.json keyed by the full source sentence.

• Retrieving strings:

  • __('messages.welcome') or the @lang Blade directive fetches the translation.

  • Pass replacements as an array: __('welcome', ['name' => $name]).

• Setting the locale: App::setLocale() changes it at runtime (often in middleware); config/app.php sets the default and fallback locale.

• Pluralization: trans_choice() picks singular/plural forms based on a count.

Session management lets Laravel persist user data across multiple requests (since HTTP is stateless), storing it server-side and identifying each visitor by a cookie holding the session ID.

• Configurable drivers:

  • Set in config/session.php: file, cookie, database, redis, memcached, array.

  • Use redis or database across multiple servers so sessions are shared.

• Working with session data:

  • session(['key' => 'value']) to store, session('key') to read, session()->forget() to remove.

  • Flash data (session()->flash()) survives only the next request, used for one-time messages.

• Security features:

  • Session ID stored in an encrypted cookie; regenerated on login to prevent fixation.

  • CSRF protection ties form tokens to the session.

Collections are object-oriented wrappers around arrays (Illuminate\Support\Collection) that provide a fluent, chainable API for transforming and inspecting data. Eloquent query results are returned as collections, so you rarely touch raw arrays.

• Why they matter:

  • Methods are chainable and return new collections, keeping data transforms readable and immutable-ish.

  • Create one from an array with collect([...]).

• Common transform methods: map(), filter(), reject(), pluck(), reduce().

• Grouping and keying: groupBy(), keyBy(), chunk(), sortBy().

• Retrieval and checks: first(), contains(), where(), sum(), count().

• Lazy variant: LazyCollection (via cursor()) streams large datasets using generators to keep memory low.

Flash data is session data that persists only for the very next request and is then automatically deleted. It is the mechanism behind status messages after a redirect (e.g. "Post created successfully").

• Setting flash data:

  • session()->flash('status', 'Saved!') stores a value available on the next request only.

  • Redirects offer the shorthand return redirect('/')->with('status', 'Saved!').

• Lifetime control:

  • reflash() keeps all flash data for one more request.

  • keep(['status']) preserves specific keys for another request.

• Reading it: Access in Blade with session('status'), commonly wrapped in @if (session('status')).

Laravel exposes dedicated Artisan commands per cache, plus a single command to clear them all at once.

• Per-cache commands:

  • php artisan route:clear removes the compiled route cache file.

  • php artisan config:clear removes the merged config cache.

  • php artisan view:clear deletes compiled Blade templates.

• Clear everything at once: php artisan optimize:clear clears route, config, view, event, and compiled caches together.

• Related but distinct: php artisan cache:clear flushes the application (data) cache store, not the framework compilation caches.

skip() and take() limit and offset results: take() sets how many rows to return, skip() sets how many to bypass first.

• take($n): Maps to SQL LIMIT; alias of limit().

• skip($n): Maps to SQL OFFSET; alias of offset().

• Common use: Manual pagination or fetching a specific slice; combine with orderBy() for deterministic ordering.

• Caveat: Large offsets are slow because the DB still scans and discards skipped rows; prefer keyset/cursor pagination at scale.

An event is a simple class that represents something that happened in your application (e.g. a user registered, an order shipped): it carries data and is dispatched so decoupled listeners can react.

• It is just a data container: Typically a plain PHP class whose constructor holds the relevant state (like the $order model).

• It enables the observer pattern: The code that dispatches doesn't know or care who listens, so you add behavior without touching the dispatcher.

• Dispatched and mapped:

  • Fired via Event::dispatch() or the static MyEvent::dispatch() helper.

  • Listeners can be auto-discovered or registered in the EventServiceProvider.

Lumen is a micro-framework by Laravel, designed as a lightweight, faster alternative for building microservices and stateless APIs where full Laravel would be overkill.

• Purpose: Optimized for speed and small footprint, ideal for high-throughput APIs and microservices.

• Trade-offs: Strips out or disables features like sessions, cookies and Blade to stay lean; less configuration flexibility than full Laravel.

• Compatibility: Shares Laravel's syntax and components, so a Lumen app can be upgraded to full Laravel when needs grow.

• Current status: Largely superseded now that Laravel itself performs well and offers slim API routing, so new projects often just use Laravel.

Laravel 11 focused on a slimmer, streamlined application skeleton and modern defaults, continuing the trend of reducing boilerplate while keeping the framework's power available when needed.

• Slimmer application structure:

  • Fewer default files: no more app/Http/Kernel.php, middleware and routing configured in bootstrap/app.php.

  • Config files trimmed; most settings driven from .env with sensible defaults.

• Simplified defaults:

  • Default database is SQLite; sessions, cache, and queue default to the database driver.

  • Service providers consolidated into AppServiceProvider.

• New tooling and features:

  • Per-second rate limiting, health check route, and dumpable casts.

  • New Schedule grouping and improved queue interaction testing.

  • Laravel Reverb: a first-party WebSocket server for real-time apps.

• Release cadence: Yearly major releases with an 18-month bug-fix and 2-year security window; PHP 8.2+ required for Laravel 11.

php artisan serve is PHP's built-in development server meant only for local work, while Apache/Nginx are production-grade web servers built for performance, concurrency, and security.

• php artisan serve:

  • Wraps PHP's built-in server; zero config, single-threaded, handles one request at a time by default.

  • For development only: no HTTPS, no process management, not tuned for load.

• Apache / Nginx:

  • Handle many concurrent requests, static file serving, gzip, caching, and TLS termination.

  • Run PHP via PHP-FPM (Nginx) or mod_php/FPM (Apache), enabling multiple worker processes.

  • Support virtual hosts, rewrite rules, load balancing, and security hardening.

• Rule of thumb: Use artisan serve (or Sail/Valet) locally; never deploy it to production.

These are official Laravel tools that each solve a different part of the development-to-production lifecycle: local environments, local serving, server provisioning, and serverless deployment.

• Sail:

  • A Docker-based local development environment; spins up PHP, MySQL, Redis, etc. with one command.

  • Solves "works on my machine": consistent, containerized dev setup with no local PHP install needed.

• Valet:

  • A lightweight macOS dev environment using Nginx and DnsMasq; serves sites at .test domains.

  • Fast, minimal-resource local serving without Docker overhead.

• Forge:

  • A server provisioning and management service for VPS providers (DigitalOcean, AWS, etc.).

  • Automates Nginx, PHP, MySQL, SSL, queues, and deployments without manual server admin.

• Vapor:

  • A serverless deployment platform on AWS Lambda.

  • Auto-scaling with no servers to manage; solves scaling and infrastructure concerns for high-traffic apps.

Laravel Nova is an official, paid administration panel that generates a polished admin backend directly from your Eloquent models, letting you build CRUD dashboards quickly without writing frontend code.

• What it provides:

  • Resource classes map to Eloquent models and auto-generate list/detail/edit views.

  • Built-in metrics, filters, lenses, actions, and authorization tied to policies.

• When to use it:

  • Internal admin/back-office tools where speed of delivery matters more than custom UI.

  • When you want a Laravel-native panel that respects your models and policies.

• When not to use it:

  • Customer-facing UIs with bespoke design, or budget-sensitive projects (it's a paid license).

  • Free alternatives like Filament may suffice.

You generate a command class with Artisan, define its signature and description, and put the logic in the handle() method; Laravel auto-registers commands in the app/Console/Commands directory.

• Generate it: Run php artisan make:command SendReports.

• Define the interface:

  • $signature: the command name plus arguments {user} and options {--force}.

  • $description: shown in php artisan list.

• Put logic in handle():

  • Read input with $this->argument() / $this->option(), and output with $this->info().

  • Dependencies are resolved via the service container in handle()'s type-hinted parameters.

• Run and schedule: Invoke with php artisan send:reports or register it in the scheduler.

These are convention (not framework) directories you create to keep controllers thin: app/Services holds business-logic/orchestration classes, and app/Repositories holds data-access classes that abstract how models are queried and persisted.

• app/Services:

  • Coordinates a use case ("place an order"): validates rules, calls repositories, dispatches events/jobs, wraps things in transactions.

  • Keeps orchestration out of controllers so it is reusable and testable.

• app/Repositories:

  • Encapsulates persistence: query building, fetching, and saving Eloquent models behind a clear interface.

  • Lets you swap or mock the data source and centralizes complex queries.

• Practical caveat: Neither is mandated by Laravel; Eloquent already acts as a data layer, so the repository pattern can add ceremony. Introduce them when complexity or testability genuinely warrants it.

bootstrap/app.php is the entry point that creates and configures the application instance before it handles a request or console command. In Laravel 11+ it also became the central place to configure routing, middleware, and exception handling.

• Builds the application: Uses Application::configure() to create the container/kernel that every request flows through.

• Central configuration (Laravel 11+): Registers route files, global/aliased middleware, and exception rendering via fluent methods like withMiddleware() and withExceptions(), replacing the old Http/Kernel.php.

• Returns the app instance: public/index.php and Artisan require this file to obtain the configured application to run.

The bootstrap/cache directory stores framework-generated cache files that speed up bootstrapping by avoiding expensive discovery work on every request.

• Holds compiled/cached framework files:

  • Files like config.php, routes-v7.php, packages.php, and services.php generated by cache commands.

  • Package auto-discovery results are cached here so Laravel skips scanning composer.json every boot.

• Populated by artisan commands: config:cache, route:cache, and event:cache write into it; clearing removes those files.

• Must be writable: The web server needs write permission here (like storage/) or the app fails to boot.

• Not for your code: it is disposable, regenerated build/runtime output, safe to clear.

Reverse routing is the practice of generating a URL from a route's name or controller action rather than writing the URL string manually, so your application builds links dynamically from the route definitions.

• Built on named routes: You reference the route name and Laravel resolves the current URI for it via route().

• Single source of truth: URLs live only in the routes file; templates and controllers reference names, so URL edits don't break links.

• Helpers that perform reverse routing: route('name') for named routes, action([Controller::class, 'method']) for controller actions.

• Works in Blade too: {{ route('profile') }} keeps views free of hardcoded paths.

Route model binding automatically injects a model instance into your route or controller by resolving a route parameter into the matching database record. Implicit binding resolves it by matching the parameter name to a type-hinted model; explicit binding defines the resolution logic manually in a service provider.

• Implicit binding:

  • Type-hint a model whose variable name matches the route segment {user}, and Laravel fetches it by primary key automatically.

  • Returns a 404 if no record is found.

  • Customize the lookup column with {user:slug} or by overriding getRouteKeyName().

• Explicit binding:

  • Register the mapping with Route::model() or define custom resolution with Route::bind() in the boot() method.

  • Use when you need custom query logic (soft deletes, scoping, non-standard keys).

• Both eliminate boilerplate: No manual Model::findOrFail() call in the controller.

You constrain route parameters to match a pattern (usually a regular expression) so the route only responds when the segment fits, using the where() method per route or Route::pattern() for a global constraint applied to every route.

• Per-route with where():

  • Chain it onto the route: ->where('id', '[0-9]+'); pass an array to constrain multiple parameters.

  • If the pattern fails, the route doesn't match and Laravel keeps looking (often ending in a 404).

• Fluent helpers: Convenience methods like whereNumber(), whereAlpha(), whereAlphaNumeric(), and whereUuid() cover common cases.

• Global patterns with Route::pattern(): Declared in a service provider's boot(); any route using that parameter name inherits the constraint automatically.

Resource controllers generate a full set of CRUD routes mapped to conventionally named controller methods with a single line, while API resource routes do the same but omit the routes meant for HTML forms (create and edit), since APIs don't serve those pages.

• Route::resource() registers seven routes:

  • index, create, store, show, edit, update, destroy, each with a conventional URI and HTTP verb.

  • Auto-generates named routes like users.index, users.show.

• Route::apiResource() registers five: Drops create and edit (form-display routes), leaving JSON-relevant actions only.

• Scaffold the controller: php artisan make:controller UserController --resource (add --api for an API variant).

• Customize with options: only(), except(), and nested resources refine which routes are generated.

A single-action (invokable) controller is a controller class with just one public __invoke() method, so you register it in a route without naming a method. Use it when a controller has one clear responsibility and a method name would just add noise.

• Uses the __invoke() magic method: Laravel calls it automatically when the controller is treated as a callable.

• Registered without a method name: Pass just the class: Route::get('/report', ReportController::class).

• When to reach for it:

  • A single, focused action: generating a report, handling one webhook, one complex endpoint that deserves its own class.

  • Keeps controllers small and follows the single-responsibility principle.

• Generate one quickly: php artisan make:controller ReportController --invokable.

A fallback route defines what happens when no other registered route matches the incoming request, letting you control the 404 behavior instead of throwing the default NotFoundHttpException.

• Defined with Route::fallback(): It must be the last route registered, since it catches everything that fell through.

• Common use cases:

  • Returning a friendly JSON error for an API ({"message":"Not found"}) instead of an HTML 404 page.

  • Rendering a custom "page not found" view for a web app.

• Scope: Fallbacks respect the route group they live in, so you can have separate fallbacks for web and api middleware groups.

• Limitation: it only runs for unmatched routes, not for a route that matches but fails (e.g. model binding failure still 404s normally).

Structure it so routes stay thin and declarative, controllers stay focused on HTTP concerns, and business logic lives elsewhere: prefer resourceful, single-purpose controllers backed by form requests and service/action classes.

• Routes:

  • Use Route::resource() (or apiResource()) for CRUD to get conventional named routes.

  • Group related routes with shared prefix and middleware.

• Controllers:

  • Keep methods small: validate, delegate, return a response.

  • Reach for single-action controllers (__invoke()) when a feature is one focused operation.

• Push logic out of the controller:

  • Validation into a FormRequest.

  • Business rules into service or action classes.

  • Output shaping into API Resources or view models.

• Result: the controller reads as a short orchestration and each layer is independently testable.

public/index.php is the single entry point (front controller) for every HTTP request: the web server routes all requests to it, and it boots the framework and hands the request off for processing.

• Front controller pattern: All web traffic funnels through this one file, so there is a single, consistent bootstrap path.

• What it actually does:

  1. Loads Composer's autoloader (vendor/autoload.php).

  2. Bootstraps the application by requiring bootstrap/app.php to get the app instance.

  3. Resolves the HTTP kernel, captures the incoming Request, and calls handle() to produce a Response.

  4. Sends the response to the browser, then calls terminate() for post-response tasks.

• Why public/ specifically: Only the public directory is exposed as the web root, keeping application code, config, and secrets outside the document root.

Dependency Injection (DI) is the practice of passing a class its dependencies from outside rather than creating them internally. In Laravel the service container performs DI automatically by reading type-hints and resolving the needed objects.

• Forms of injection in Laravel:

  • Constructor injection: dependencies type-hinted in __construct() (most common).

  • Method injection: type-hinted parameters in controller actions or route closures.

• Benefits:

  • Loose coupling: depend on interfaces, swap implementations without touching consumers.

  • Testability: inject mocks or fakes in tests instead of hard-coded new instances.

  • Single responsibility: a class focuses on its work, not on wiring up collaborators.

  • Centralized configuration: lifecycle and construction logic live in service providers.

Both register a binding in the container; the difference is lifetime. bind() creates a fresh instance every time the service is resolved, while singleton() builds it once and returns that same instance for all subsequent resolutions.

• bind(): New object per resolution: good for stateless or lightweight services where sharing state would be a bug.

• singleton():

  • One shared instance for the whole application lifecycle (the request in web, the process in a worker).

  • Ideal for expensive-to-build or stateful-but-shared services (config, connection managers).

• Caution with long-running processes: Under Octane or queue workers a singleton persists across requests/jobs, so leaked state can cause subtle bugs.

Both let the container inject dependencies, differing in where the type-hint lives. Constructor injection supplies dependencies when the class is instantiated; method injection supplies them per method call (typically controller actions).

• Constructor injection:

  • Type-hint in __construct(); the dependency is available to every method of the class.

  • Best for dependencies used across the class or that are mandatory to construct it.

• Method injection:

  • Type-hint a parameter on a specific method (Laravel resolves it when calling the action).

  • Best for a dependency only one method needs, avoiding constructor clutter.

  • In controllers it can mix with route parameters: injected services first, then route bindings.

• Rule of thumb: Shared/required dependency: constructor. Method-specific dependency: method injection.

You bind an interface to a concrete class so that whenever the interface is type-hinted, the container injects the chosen implementation. This is the core of coding to abstractions in Laravel.

• Register in a service provider: Use bind() or singleton() in the register() method, mapping the interface to the implementation class.

• Type-hint the interface: Controllers or services depend on the interface; the container resolves the concrete class automatically.

• Benefit: Swap implementations (e.g. real vs. mock, different drivers) by changing one binding, with no consumer changes.

The service container is Laravel's tool for managing class dependencies and their resolution; dependency injection (DI) is the pattern of receiving your dependencies from outside rather than creating them yourself. The container automates DI by inspecting constructor type-hints and building the required objects for you.

• Dependency injection:

  • A class declares what it needs (via constructor or method parameters) instead of instantiating collaborators with new.

  • Promotes loose coupling and testability (you can inject fakes/mocks).

• How the container helps:

  • It reads type-hints via reflection and recursively resolves and builds the whole dependency graph.

  • Bindings tell it how to build things it can't figure out alone (interfaces, closures, singletons).

• Resolution: Use make() or app() to resolve manually; framework classes like controllers are resolved automatically.

You use app()->make() to manually resolve a class or binding out of the service container when automatic constructor injection isn't available, such as in code that isn't itself resolved by Laravel.

• Manual resolution: Call app()->make(Service::class) (or the helper resolve()) to get a fully constructed instance with its dependencies injected.

• When to reach for it:

  • Inside static contexts, closures, helper functions, or legacy code where you can't type-hint a constructor.

  • When you need to resolve lazily (only build the object at the moment you actually need it).

• Prefer injection when possible:

  • In controllers, jobs, and other resolved classes, type-hint dependencies instead: it's clearer and easier to test.

  • Overusing make() turns the container into a service locator, which hides dependencies.

• Passing extra parameters: makeWith() (or make() with a second array arg) passes runtime values the container can't infer.

register() only binds things into the container; boot() runs after all providers are registered, so it's where you use services that other providers have bound.

• register() is for binding:

  • Called first, for all providers. Use bind(), singleton(), and merging config.

  • Never resolve or use other services here: they may not be registered yet.

• boot() is for bootstrapping:

  • Runs after every provider's register(), so the full container is available.

  • Use it for event listeners, view composers, route/policy registration, macros, and validation rules.

  • You can type-hint dependencies in the boot() signature and they'll be injected.

• Rule of thumb: If it puts something into the container, it belongs in register(); if it does something with the container, it belongs in boot().

Service Providers are the central place where Laravel and your app bootstrap: they tell the service container how to bind and configure services, and they run the setup code that wires the framework together.

• They are the bootstrapping mechanism: Every core service (routing, cache, queue, DB) is registered via a provider; the framework boots by running them.

• Two lifecycle methods: register() binds services into the container; boot() runs setup after all bindings exist.

• Registered in configuration: Listed in bootstrap/providers.php (or config/app.php in older versions).

• Purpose: organization and extensibility: Group related bindings and setup for a feature or package in one class, keeping wiring out of your business logic.

• Can be deferred: Implement DeferrableProvider so bindings load lazily only when needed.

All three ultimately reach services in the container, but they differ in explicitness and testability: DI declares dependencies openly in the constructor, facades and helpers offer terser access at the cost of hiding those dependencies.

• Dependency Injection:

  • Dependencies are type-hinted and passed in, making coupling explicit and mocking trivial.

  • Best for classes where clarity and testability matter most.

• Facades:

  • Static-looking proxies (Log::info()) to container services; concise but hide dependencies.

  • Mockable via the facade's shouldReceive().

• Helper functions:

  • Global shortcuts (cache(), logger()) that often wrap the same facade/container resolution.

  • Most terse; same hidden-dependency trade-off as facades.

• Guideline: Use DI in application/service classes; facades and helpers are fine in controllers, routes, and quick contexts.

The core difference is explicitness: dependency injection declares what a class needs through its constructor, while a facade reaches into the container implicitly through a static call.

• Visibility of dependencies:

  • DI: the constructor signature documents every dependency.

  • Facade: dependencies are hidden inside method bodies.

• Coupling:

  • DI lets you depend on an interface and swap implementations via the container.

  • Facades bind you to a specific accessor, though it still resolves from the container.

• Testing:

  • DI: pass a mock or fake directly.

  • Facade: use built-in mocking like Queue::fake().

• Syntax and convenience: Facades are shorter and need no constructor plumbing; DI is more verbose but self-documenting.

• When to choose: Prefer DI for reusable, unit-tested classes; facades for expressive, high-level calls in controllers.

They solve different problems: contracts are interfaces that define what a service does, while facades are a convenient static-style way to call a concrete service instance. You can even reference contracts through facades.

• Contracts are interfaces:

  • They define a service's methods (a formal API) without an implementation, e.g. Illuminate\Contracts\Cache\Repository.

  • You type-hint them for loose coupling and explicit dependencies.

• Facades are access proxies: They give static-style access to a resolved instance, e.g. Cache::get().

• Explicitness: Contracts make dependencies visible in the constructor; facades hide them behind a static call.

• They can work together: Many facades resolve a class that implements a matching contract; choice is style vs. explicit interface dependency.

Contracts are the set of interfaces Laravel provides that define its core services, letting you depend on abstractions instead of concrete classes.

• They are interfaces: Located under Illuminate\Contracts, each defines the methods of a service (cache, queue, mail, etc.).

• Purpose: loose coupling: Type-hint a contract and the container injects the bound implementation, so your code depends on behavior, not a concrete class.

• Swappability: You can rebind a contract to your own implementation without touching consumers.

• Clear API documentation: The interface acts as a concise, explicit contract of what a service offers.

• Relation to facades: Facades and contracts often front the same underlying service; contracts are the explicit-DI counterpart to facade convenience.

They solve different problems: a Service Provider is where you register and bootstrap services into the container, while a Facade is a static-style proxy that gives convenient access to a service already resolved from the container.

• Service Provider (registration):

  • Central place to bind classes, register singletons, and run bootstrap logic via register() and boot().

  • Answers "how is this service built and wired up?"

• Facade (access):

  • A static-looking API (Cache::get()) that under the hood resolves the real object from the container.

  • Answers "how do I conveniently call this service?"

• Relationship: A provider registers the binding; a facade is just one of several ways to reach that binding.

The Service Container is the mechanism that stores and resolves class dependencies (the dependency injection engine); Service Providers are the classes where you tell that container what to build and how.

• Service Container:

  • The registry/resolver: it holds bindings and auto-resolves dependencies via reflection when you type-hint them.

  • Accessed via app(), resolve(), or constructor injection.

• Service Providers: The configuration layer: they populate the container through register() and perform startup work in boot().

• Analogy: The container is the toolbox; providers are the instructions for stocking it.

• Lifecycle: On boot, Laravel runs all providers to fill the container; requests then pull resolved services out of it.

Config caching combines all your configuration files into a single cached PHP file so Laravel loads config in one step instead of parsing many files and re-reading the environment on every request.

• What config:cache does: Runs php artisan config:cache to serialize all config arrays into bootstrap/cache/config.php.

• Performance gain: Avoids filesystem reads and env() lookups per request; recommended in production.

• Critical caveat: Once cached, env() calls outside config files return null, so only use env() inside config files.

• Refreshing: Re-run after config changes; clear with php artisan config:clear.

APP_KEY is a random 32-byte key used by Laravel's encrypter for all symmetric encryption, most importantly encrypting cookies and session data. Without a valid key the app can't securely sign or encrypt data.

• What it protects:

  • Encrypted cookies and the session cookie, Crypt::encrypt() values, and signed URLs.

  • Also underpins CSRF/session integrity because those cookies are encrypted.

• How it's set: Generated with php artisan key:generate, stored as a base64 string in .env and read via config('app.key').

• Why it's critical:

  • A leaked key lets attackers forge/decrypt cookies and sessions, potentially hijacking authenticated users.

  • Keep it secret, unique per environment, and never commit real keys to version control.

• Rotation caveat: Changing the key invalidates existing encrypted cookies/sessions, logging users out.

Debug mode (APP_DEBUG=true) shows detailed error pages meant for developers. In production it leaks sensitive internals and must be disabled by setting APP_DEBUG=false.

• Information disclosure:

  • Stack traces reveal file paths, class names, and code snippets that help attackers map your app.

  • Whoops pages can display environment variables and config, potentially exposing DB credentials and APP_KEY.

• Query and payload leakage: Error output may include SQL queries with bound values and request data.

• Correct production setup: Set APP_DEBUG=false and APP_ENV=production; log errors instead and show a generic error page.

env() reads raw values from the environment/.env file, while config() reads from cached config arrays. You should read from config() everywhere except inside config files, because config caching makes env() return null elsewhere.

• env() reads environment variables: Meant to feed config files, e.g. 'key' => env('APP_KEY').

• config() reads resolved config values: Values come from files under config/, e.g. config('app.timezone').

• The caching trap: php artisan config:cache compiles config into one cached file and stops loading .env, so env() outside config files returns null.

• Rule of thumb: Call env() only in config/ files; use config() in controllers, services, and views.

Laravel loads .env values very early in the bootstrap process using the vlucas/phpdotenv library, making them available through env() and, from there, into the config repository.

• When it loads: The LoadEnvironmentVariables bootstrapper runs before config, reading .env into PHP's $_ENV and getenv().

• Environment-specific files: If APP_ENV is set, Laravel will load .env.{environment} when present.

• Flow into config: Config files call env() to pull those values, so config becomes the single source of truth for the rest of the app.

• Caching short-circuits it: When a cached config exists, Laravel skips loading .env entirely for performance.

Because once you run php artisan config:cache, Laravel no longer loads the .env file, so any env() call outside a config file returns null and can silently break your app in production.

• Config caching breaks it: Cached config bypasses .env loading; only values already captured in config files survive.

• Silent failures: A missing value returns null rather than erroring, so bugs surface only in production where caching is enabled.

• Correct pattern: Reference the env var in a config file, then read it via config() throughout the app.

• Bonus: performance: config() reads from an in-memory array, avoiding repeated environment lookups.

Eloquent relationships are defined as methods on a model that return a relationship object, describing how tables relate. Laravel supports one-to-one, one-to-many, many-to-many, has-many-through, and polymorphic variations.

• One-to-one: hasOne() on the parent, belongsTo() on the child (e.g. a User has one Profile).

• One-to-many: hasMany() with the inverse belongsTo() (a Post has many Comment records).

• Many-to-many: belongsToMany() on both sides via a pivot table; access extra pivot columns with withPivot().

• Has-many-through: hasManyThrough() reaches a distant relation via an intermediate model (a Country has many Post through User).

• Polymorphic:

  • morphOne()/morphMany() with morphTo() let one model belong to multiple types (e.g. a Comment on either a Post or Video).

  • morphToMany() handles many-to-many polymorphic cases like tags.

• Usage tip: Access as a property ($post->comments) for the collection, or as a method ($post->comments()) to keep querying.

Accessors and mutators let you transform attribute values as you read from or write to an Eloquent model, keeping formatting/normalization logic on the model instead of scattered across the app.

• Accessor: transforms a value when you read it: Example use: combining first and last name into a full name, or formatting a date.

• Mutator: transforms a value when you set it: Example use: lowercasing an email or hashing a password before it hits the database.

• Modern syntax (Laravel 9+) uses a single method returning Attribute::make(get:, set:): Older syntax used getXAttribute() and setXAttribute() methods.

• When to use: presentation formatting, normalization, or derived attributes that belong with the model rather than in controllers or views.

These define one-to-one, one-to-many, and their inverse. hasOne and hasMany are declared on the "parent" that owns the foreign key on the other table, while belongsTo is the inverse declared on the "child" that holds the foreign key.

• hasOne: one-to-one: A user has one profile; the foreign key (user_id) lives on the profiles table.

• hasMany: one-to-many: A user has many posts; each post row carries the user_id foreign key.

• belongsTo: the inverse of either: A post belongs to a user; defined on the model that owns the foreign key.

• Rule of thumb: the model whose table has the foreign key uses belongsTo; the other side uses hasOne/hasMany.

Scopes let you encapsulate reusable query constraints. Local scopes are opt-in filters you call explicitly, while global scopes are applied automatically to every query on a model.

• Local scopes: reusable, explicit query methods:

  • Defined as scopeXxx() on the model and called as Model::xxx() (without the scope prefix).

  • Good for common filters like scopeActive() or scopePopular(); they can accept parameters.

• Global scopes: automatically applied constraints:

  • Added via a class implementing Scope or a closure in the model's booted() method.

  • Applied to every query, so SoftDeletes (excluding trashed rows) is itself a global scope.

  • Bypass with withoutGlobalScope() or withoutGlobalScopes() when you need the unfiltered set.

Model events are hooks Eloquent fires during a model's lifecycle (creating, updating, deleting, etc.), and observers are classes that group all those event handlers in one place, keeping side-effect logic out of the model itself.

• Common events fire in pairs (before/after):

  • creating/created, updating/updated, deleting/deleted, plus saving/saved, restoring, etc.

  • Returning false from a "...ing" event cancels the operation.

• Observers centralize event handling: Generate with php artisan make:observer and register via Model::observe() (or an attribute).

• Typical uses: setting a slug on creating, clearing cache on updated, or cascading cleanup on deleted.

• Caveat: events don't fire for bulk operations like Model::query()->update() since no model is instantiated.

A polymorphic relationship lets a single model belong to more than one other model type on a single association, using a type column plus an id column instead of separate foreign keys per parent.

• Classic example: comments or images: A Comment can belong to a Post or a Video via one relation.

• Uses two columns on the child table: A commentable_type (the parent class name) and commentable_id (the parent's key).

• Defined with polymorphic methods:

  • Child uses morphTo(); parents use morphMany() or morphOne().

  • Many-to-many variant uses morphToMany() and morphedByMany() (e.g. tags).

• Tip: use Relation::enforceMorphMap() to store short aliases instead of full class names, decoupling the DB from namespaces.

API Resources are a transformation layer between your Eloquent models and the JSON returned to clients: they let you shape, rename, and conditionally include fields instead of exposing the raw model.

• Two base classes: JsonResource transforms a single model; a resource collection (or ResourceCollection) transforms many.

• You control the output shape: The toArray() method maps model attributes to exactly the keys and formats the API should expose.

• Conditional and relational data: whenLoaded() includes a relationship only if it was eager loaded (avoiding N+1); when() adds fields conditionally.

• Metadata and wrapping: Resources wrap data under a data key by default and can add meta/links (pagination info is handled automatically for collections).

Mass assignment is setting many attributes at once from an array (typically request input) via create() or fill(). Without protection a user could inject unexpected fields (like is_admin), so Eloquent requires you to whitelist or blacklist attributes.

• The risk: Passing raw $request->all() could set columns the user should never control.

• $fillable is a whitelist: Only listed attributes may be mass assigned; everything else is silently ignored.

• $guarded is a blacklist: Everything is fillable except the listed attributes; $guarded = [] makes all attributes mass assignable (use with care).

• Use one or the other: A model defines $fillable or $guarded, not both; whitelisting is generally safer.

• Bypass when needed: Setting attributes directly ($model->is_admin = true) is not mass assignment and skips these guards.

Casts automatically convert attributes between their database representation and a convenient PHP type when you read or write them, so you don't manually transform values everywhere.

• Defined via the casts() method (or $casts property): Built-ins include integer, boolean, array, datetime, decimal:2, and enum casts.

• Common examples: A JSON column cast to array returns a PHP array and re-encodes on save; a 0/1 column cast to boolean reads as true/false.

• Custom casts: Implement CastsAttributes with get() (DB to PHP) and set() (PHP to DB), then reference the class in the casts array.

Serialization is how Eloquent converts a model (or collection) to an array or JSON, e.g. when returning it from a controller. You control which attributes appear with $hidden, $visible, and $appends.

• How it triggers: toArray() / toJson() run automatically when a model is returned from a route or JSON-encoded; loaded relationships serialize too.

• $hidden (blacklist): Excludes attributes from output, e.g. password and remember_token.

• $visible (whitelist): Only these attributes appear; use one approach, not both at once.

• $appends (add computed values): Includes accessor-based attributes (not real columns) in the output, like a full_name accessor.

• Runtime overrides: makeVisible() and makeHidden() adjust visibility per-instance without changing the model definition.

A many-to-many relationship links two tables through an intermediate pivot table, defined with belongsToMany() on both models (e.g. users and roles joined by a role_user table).

• The pivot table: Holds the two foreign keys; named alphabetically by convention (role_user) or specified explicitly.

• Accessing pivot data: Each related model exposes a pivot attribute; use withPivot('expires_at') to load extra pivot columns and withTimestamps() for pivot timestamps.

• Managing the relationship: attach() adds, detach() removes, and sync() makes the pivot match a given set of IDs (with optional pivot values).

• Custom pivot models: Use using() with a Pivot model when the pivot needs its own logic, casts, or an ID.

An Eloquent Collection is a specialized subclass of the base Support Collection returned whenever a query yields multiple models: it keeps all the fluent methods plus extras that understand models and their keys.

• Base Support Collection: A generic wrapper (Illuminate\Support\Collection) around any array with fluent methods like map(), filter(), reduce().

• Eloquent Collection:

  • Subclass Illuminate\Database\Eloquent\Collection holding model instances, keyed intelligently by primary key.

  • Model-aware helpers: find($id), modelKeys(), contains($id), load() for lazy eager loading, fresh().

• Downgrading behavior: Methods that no longer make sense with models (e.g. pluck(), flatten(), keys()) return a plain base Collection.

• Customization: Override newCollection() on a model to return your own collection class with domain methods.

API Resources transform models into JSON. Conditional attributes let you include fields only when a condition holds, and resource wrapping controls the top-level key (data) that envelopes the output.

• Conditional attributes:

  • when($condition, $value): add a key only if the condition is truthy (e.g. only expose secret to admins).

  • whenLoaded('relation'): include a relationship only if it was eager loaded, avoiding N+1 queries.

  • mergeWhen(): conditionally merge several keys at once.

• Resource wrapping:

  • Single resources and collections are wrapped in a data key by default.

  • Change the key via the static $wrap property, or disable entirely with JsonResource::withoutWrapping().

  • Use ResourceCollection (or ::collection()) for lists; pagination metadata is preserved alongside data.

The Query Builder exposes join methods that mirror SQL, and lets you pass closures or nested builder instances to compose subqueries within selects, wheres, or joins.

• Joins:

  • join() (inner), leftJoin(), rightJoin(), and crossJoin().

  • For complex ON clauses pass a closure and use $join->on() / $join->where().

• Subqueries:

  • selectSub() to embed a query as a column, whereIn() / whereExists() with a closure for filtering.

  • joinSub() to join against a derived table (a subquery aliased as a table).

Raw expressions inject literal SQL where the fluent methods fall short, and dedicated aggregate methods run COUNT, SUM, AVG, MIN, MAX and return scalar values directly.

• Raw expressions:

  • DB::raw() or the raw method variants: selectRaw(), whereRaw(), havingRaw(), orderByRaw().

  • Raw SQL is not escaped, so pass user values as bindings (second argument) to stay injection-safe.

• Aggregates:

  • count(), sum('col'), avg('col'), max('col'), min('col') execute immediately and return a number.

  • Combine with groupBy() and having() for grouped aggregation using get().

Laravel separates the two concerns: migrations handle schema versioning (structure), while seeders handle populating data. Together they let you rebuild and fill a database reproducibly across environments.

• Versioning via migrations:

  • Every schema change is a timestamped migration file tracked in the migrations table.

  • Commands like migrate, rollback, and refresh move the schema forward and back.

• Seeding via seeders and factories:

  • Seeder classes insert data (reference/lookup tables, sample data); factories generate bulk fake records.

  • DatabaseSeeder orchestrates other seeders via $this->call().

• Common workflow:

  • php artisan migrate:fresh --seed drops all tables, re-runs every migration, then seeds: a clean, repeatable rebuild.

  • Keep migrations forward-only in production; use fresh mainly in development and testing.

Laravel wraps multiple queries in a database transaction so they either all commit or all roll back, preventing partial writes. Use the DB::transaction() closure for automatic handling or manual methods when you need finer control.

• Closure approach (recommended):

  • DB::transaction(fn () => ...) commits automatically if the closure succeeds and rolls back on any exception.

  • An optional second argument sets retry attempts for deadlocks.

• Manual control:

  • DB::beginTransaction(), then DB::commit() on success or DB::rollBack() inside a catch block.

  • Useful when logic branches or spans multiple methods.

• Notes:

  • Only works on transactional engines (InnoDB, not MyISAM).

  • Nested transactions use savepoints so an inner rollback doesn't abort the outer one prematurely.

These commands manage the migration lifecycle, differing in how much they undo and whether they reseed. Choosing correctly matters because some are destructive to data.

• migrate: Runs all pending (not-yet-run) migrations forward. Safe, non-destructive.

• migrate:rollback: Reverses the last batch by calling their down() methods; add --step=n to control how many.

• migrate:reset: Rolls back every migration (all batches) via their down() methods, emptying the schema.

• migrate:refresh: Reset then migrate again: rolls all back using down(), then re-runs them. Accepts --seed.

• migrate:fresh: Drops all tables directly (ignoring down()) then re-runs every migration: fastest clean rebuild, great with --seed.

• Key distinction: refresh relies on working down() methods; fresh ignores them and just drops tables. All are destructive except plain migrate.

They serve two distinct roles: @include pulls one partial into another view, while @yield and @section work together as the placeholder/content pair in template inheritance.

• @include:

  • Embeds a separate partial view inside the current one and shares the parent's data (plus any array you pass).

  • Used for reusable fragments: navbars, cards, form inputs.

• @yield:

  • Declares a named placeholder in a layout that a child view will fill.

  • Lives in the parent/layout file, e.g. @yield('content').

• @section:

  • Defines the actual content for a named section in the child view, closed with @endsection (or the inline @section('title', 'Home') form).

  • Its content is injected into the matching @yield.

• Mental model: @include = composition; @yield + @section = inheritance.

Blade components are reusable, self-contained UI elements rendered with <x-name> syntax; class-based components pair a view with a PHP class for logic, while anonymous components are view-only (no class).

• Class-based components:

  • Have a PHP class (app/View/Components) plus a Blade template; created via php artisan make:component.

  • The class constructor prepares data/computed properties, exposed to the view; good when the component needs real logic.

• Anonymous components:

  • Just a Blade file in resources/views/components, no class.

  • Data comes in via the @props directive; ideal for presentational markup with little logic.

• Shared features:

  • Attributes pass as props; extra HTML attributes are captured by $attributes.

  • Content between tags is available via the $slot variable (plus named slots).

• Choosing: use anonymous for simple presentation, class-based when you need constructor logic or dependency injection.

Blade components pass data in via @props (attributes), inject markup via slots, and expose a bag of remaining HTML attributes for flexible rendering.

• Attributes and @props:

  • Declared at the top of the component view with @props(['type' => 'info', 'message']), giving named data with optional defaults.

  • Callers pass them as HTML attributes: <x-alert type="error" :message="$msg" />. A : prefix binds a PHP expression instead of a literal string.

• Slots (passing markup, not just data):

  • The default slot is whatever content sits between the component tags, rendered with {{ $slot }}.

  • Named slots let you inject multiple regions: define <x-slot:title>...</x-slot> and render it with {{ $title }}.

• The attribute bag:

  • Any attribute not declared in @props flows into $attributes, so you can forward classes, ids, etc.

  • Use {{ $attributes->merge(['class' => 'p-4']) }} to combine caller-supplied and default attributes.

@stack and @push let child views inject content into a named placeholder defined in a parent layout, commonly used to add page-specific scripts or styles.

• @stack('name') defines the placeholder: Placed in the layout (often before </body> or in <head>) to mark where pushed content is rendered.

• @push('name') ... @endpush appends content:

  • Any view or component can push into the stack, and multiple pushes accumulate in order.

  • @prepend adds content to the beginning of the stack instead.

• Why it's useful: Unlike @section, stacks let many child views contribute to one region, ideal for per-page assets loaded from partials or components.

Laravel validates form data with rule sets, either inline via the request's validate() method for quick cases, or in dedicated Form Request classes that encapsulate rules and authorization for reuse and cleaner controllers.

• The validate() method:

  • Called on the $request (or $this in a controller); takes an array of field-to-rules.

  • On success it returns the validated data; on failure it throws ValidationException and redirects/returns errors automatically.

• Form Request classes:

  • Generated with php artisan make:request; define rules in rules() and permission logic in authorize().

  • Type-hint it in the controller method and validation runs automatically before the method body executes.

  • Keeps validation reusable and controllers thin; customize messages via messages().

• When to use which: Use validate() for simple, one-off rules; use Form Requests for complex, shared, or authorization-bound validation.

A Form Request is a custom request class that encapsulates both authorization and validation logic, keeping controllers thin. When you type-hint it in a controller method, Laravel validates automatically before the method runs.

• Generated via Artisan: php artisan make:request StorePostRequest creates a class extending FormRequest.

• Two key methods:

  • rules() returns the validation rules array.

  • authorize() returns a boolean deciding if the user may make this request.

• Automatic behavior: On failure it redirects back with errors and old input (or returns JSON 422 for API requests); on success your controller receives validated data.

• Access validated data: Call $request->validated() to get only the validated fields.

When validation fails, Laravel flashes the submitted input to the session for one request, so you can repopulate fields using the old() helper instead of losing what the user typed.

• Flashing to session: Flash data lives only until the next request; $request->flash() or ->withInput() on a redirect stores the input.

• Automatic on validation failure: validate() and Form Requests redirect back with input already flashed, so you rarely flash manually.

• Repopulating fields: Use old('field') in Blade; a second argument sets a default (useful on edit forms).

• Sensitive fields: Password fields are excluded by default (except in session config), so never repopulate them.

The authorize() method in a Form Request decides whether the current user is allowed to make the request. It runs before validation and returning false aborts with a 403 response.

• Returns a boolean: true lets the request proceed to validation; false throws an AuthorizationException (403).

• Access to context: You can use $this->user(), route parameters via $this->route('post'), and gates/policies with $this->user()->can(...).

• Open access: If authorization is handled elsewhere, simply return true;.

• Keeps concerns together: Colocating authorization with validation avoids scattering permission checks across the controller.

Both let you write custom validation logic beyond the built-in rules. Rule objects are reusable classes implementing a validation contract, while closure rules are inline functions for one-off checks. Write a custom rule when no built-in rule expresses your requirement.

• Rule objects:

  • Generated with php artisan make:rule Uppercase; implement the validate() method (implementing ValidationRule) and call $fail() to reject.

  • Reusable across many forms and easy to unit test.

• Closure rules: An inline function ($attribute, $value, $fail) placed directly in the rules array; best for quick, one-time logic.

• When to write one: Domain-specific checks (e.g. valid coupon, business hours) that built-ins like in or regex can't cleanly express.

Laravel lets you override the default error text with custom messages, and rename the placeholder used in messages with custom attribute names. Both can be set inline, in a Form Request, or globally in language files.

• Custom messages: Pass a second array to validate() or define messages() in a Form Request; keys use field.rule format.

• Custom attribute names: Define attributes() (or pass a third array) so :attribute renders as a friendly name (e.g. email_addr shown as "email address").

• Placeholders: Messages support :attribute, :min, :max, etc., filled dynamically.

• Global defaults: Edit lang/en/validation.php under the custom and attributes keys for app-wide overrides.

An error bag is a named container of validation errors. By default all errors go into the default bag, but you can name bags so multiple forms on one page don't clash when displaying their errors.

• The $errors variable: Every view gets $errors (a ViewErrorBag) shared by the ShareErrorsFromSession middleware.

• Naming a bag: Chain ->withErrors($validator, 'login'), or set $errorBag in a Form Request to scope errors.

• Reading a specific bag: Access it in Blade with $errors->login->first('email').

• Why it matters: With login and registration forms on the same page, named bags keep each form's errors from appearing under the other.

Conditional rules apply validation only under certain circumstances. sometimes validates a field only when it is present, while rules like required_if make a field required based on another field's value.

• sometimes:

  • As a rule string, it runs the remaining rules only if the field exists in the input (useful for partial updates).

  • As a method, $validator->sometimes('field', 'rules', fn ($input) => ...) adds rules based on a closure condition.

• required_if / required_unless: required_if:type,shipping makes the field required when type equals shipping; required_unless is the inverse.

• Related family: required_with, required_without, and required_with_all cover presence-based conditions.

Middleware are filter layers that sit between the incoming HTTP request and your application, letting you inspect, modify, or reject requests before they reach a route (and responses on the way out). They form an onion of layers each request passes through.

• How they work:

  • Each middleware receives the request and a $next closure; it either calls $next($request) to pass control deeper, or short-circuits by returning a response (e.g. a redirect).

  • They run in a defined order, wrapping the route handler, so code before $next runs on the way in and code after runs on the way out.

• Common built-in uses: Authentication (auth), CSRF protection, session start, request throttling, and CORS.

• When to write custom middleware:

  • Cross-cutting concerns that apply to many routes: logging, locale detection, tenant resolution, role checks, forcing HTTPS, or header manipulation.

  • Generate with php artisan make:middleware and register it globally or per route.

Laravel handles rate limiting via the throttle middleware backed by named rate limiters you define in a service provider, letting you cap how many requests a client can make in a time window.

• Named limiters:

  • Defined with RateLimiter::for() (typically in AppServiceProvider), returning a Limit instance.

  • Use Limit::perMinute(), and by() to key the limit per user or IP.

• Applying it: Attach throttle:api or throttle:60,1 (60 requests per 1 minute) to routes or groups.

• Responses & headers: Exceeding the limit returns HTTP 429 Too Many Requests; Laravel adds X-RateLimit-Limit and X-RateLimit-Remaining headers automatically.

• State is tracked in the cache store, so counters are shared across requests.

The three types differ by scope: global middleware runs on every request, route middleware is attached to specific routes by alias, and group middleware bundles several middleware under one name. Parameters are passed to middleware using a colon and comma-separated values.

• Global middleware: Registered in the $middleware array of the HTTP kernel; runs on every HTTP request (e.g. maintenance mode, trimming strings).

• Route middleware: Assigned via an alias in $routeMiddleware / $middlewareAliases, then applied with ->middleware('auth') on a route.

• Group middleware: Named collections in $middlewareGroups (like web and api) that apply multiple middleware at once.

• Passing parameters: Use middleware('role:admin'); extra arguments after $next in handle() receive them.

The difference is timing relative to the $next($request) call: before middleware runs its logic before the request reaches the application, while after middleware runs after the response is generated but before it's returned.

• Before middleware: Runs code, then calls $next($request); can inspect/modify the request or short-circuit (auth checks, validation, redirects).

• After middleware: Captures the response from $next($request) first, then acts on it (adding headers, modifying/logging the response).

• It's the position of your code, not a separate class type, that determines before vs after.

Laravel ships with two default middleware groups defined in the HTTP kernel: the web group for stateful browser sessions and the api group for stateless API requests.

• The web group:

  • Includes cookie encryption, adding queued cookies, starting the session, sharing errors from session, CSRF verification (VerifyCsrfToken), and route model binding.

  • Applied to routes/web.php by default.

• The api group:

  • Lean and stateless: historically throttling (throttle:api) and route model binding, without sessions or CSRF.

  • Applied to routes/api.php.

• The key contrast: web is session/cookie-based for browsers, while api is token-based and stateless.

Gates and Policies are Laravel's two authorization mechanisms. Gates are simple closures for standalone, model-agnostic checks, while Policies are classes that group authorization logic around a specific model, keeping related rules organized.

• Gates:

  • Defined via Gate::define(), usually in a service provider; a closure receiving the user and optional arguments.

  • Best for broad, one-off actions not tied to a model (e.g. view-admin-dashboard).

• Policies:

  • Classes generated with php artisan make:policy, each method mapping to an action like update or delete on a model.

  • Best when authorization revolves around an Eloquent model (CRUD-style permissions).

• Checking them: Both are invoked the same way: Gate::allows(), $user->can(), the @can Blade directive, or $this->authorize() in controllers.

• Rule of thumb: model-centric permissions use a Policy; simple app-wide checks use a Gate.

Laravel manages authentication through guards that define how users are authenticated for each request, and providers that define how users are retrieved from storage. Together they're configured in config/auth.php.

• Guards:

  • Define the mechanism for storing/retrieving auth state per request.

  • The session guard uses cookies/sessions (web apps); the token or Sanctum/Passport guards handle stateless API auth.

• User providers: Define how users are fetched from persistent storage; the eloquent provider uses an Eloquent model, database uses the query builder directly.

• How they connect: Each guard references a provider, so the guard decides how a user is authenticated and the provider decides where the user comes from.

• Accessing the user: Use the Auth facade or helpers: Auth::user(), Auth::guard('api')->user(), attempt() to log in, and check() for status.

• Starter tools like Breeze, Jetstream, Sanctum, and Passport build on this foundation for scaffolding and API tokens.