DEV Community: Laravel Daily tips

Laravel 13: Real-Time Notifications using Pusher

Laravel Daily tips — Mon, 10 Aug 2026 23:05:13 +0000

Introduction

Users expect modern web applications to respond instantly. Whether it's a new order arriving in an admin dashboard, a teammate sending a chat message, or a support ticket being created, waiting for users to refresh the page every few seconds no longer provides a good user experience.

Laravel solves this problem through its powerful broadcasting system. Instead of repeatedly asking the server whether anything has changed, Laravel pushes updates to connected browsers the moment an event occurs.

At the center of this system are Laravel Events. Whenever something important happens inside your application—such as publishing a post, creating an order, or processing a payment—you simply dispatch an event. Laravel then broadcasts that event through a broadcasting driver like Pusher or Laravel Reverb, allowing every subscribed client to react immediately.

In this tutorial, we'll build a practical notification system where a regular user creates a post and an administrator instantly receives a notification without refreshing the browser. Although the example is intentionally simple, the same architecture is used in production systems for:

Order management dashboards
Customer support platforms
Messaging applications
Inventory monitoring
Payment processing
Project management tools
Activity feeds

More importantly, you'll learn why Laravel's broadcasting system exists, how each component communicates internally, and how to build similar real-time features in your own applications with confidence.

What Are Real-Time Notifications?

Real-time notifications allow information to appear in the browser immediately after an action occurs on the server.

Instead of sending repeated HTTP requests asking whether new data exists, the server pushes updates only when something actually changes.

Consider an e-commerce dashboard where customers continuously place new orders.

Without broadcasting, the administrator has two choices:

Refresh the page manually every few seconds.
Implement polling, where the browser repeatedly sends AJAX requests looking for updates.

Both approaches waste resources and provide a less responsive user experience.

With Laravel Broadcasting, the workflow becomes much more efficient.

A customer submits a new order.
Laravel dispatches an event.
The event is broadcast through Pusher.
The administrator's browser receives the event immediately.
The interface updates automatically.

Production Tip: Broadcasting isn't limited to notifications. The same architecture can power live dashboards, chat systems, progress bars, collaborative editing, stock updates, analytics panels, and monitoring applications.

How Laravel Broadcasting Works

Before writing any code, it's worth understanding what happens internally whenever Laravel broadcasts an event.

Every component has a single responsibility, making the system easy to maintain and extend.

User Creates Post
        │
        ▼
PostController
        │
        ▼
Dispatch PostCreated Event
        │
        ▼
Broadcast Driver
        │
        ▼
Pusher Channels
        │
        ▼
Connected Browsers
        │
        ▼
Laravel Echo
        │
        ▼
Update User Interface

The process may look complex initially, but Laravel abstracts almost all of the heavy lifting. Your application simply dispatches an event, while Laravel handles serialization, broadcasting, and communication with the broadcasting service.

On the frontend, Laravel Echo maintains the WebSocket connection and listens for incoming events. Whenever an event arrives, JavaScript can update the page instantly without another HTTP request.

Why Laravel Uses Events for Broadcasting

Developers often wonder why Laravel doesn't simply send JavaScript responses directly from the controller.

The answer is separation of concerns.

A controller should only coordinate a request. It validates incoming data, performs business logic, and returns a response. It shouldn't also manage WebSocket connections, notifications, emails, logging, or analytics.

Instead, Laravel encourages an event-driven architecture.

Once a post has been successfully created, the controller dispatches a PostCreated event. That event becomes responsible for broadcasting information, while the frontend decides how to display it.

This design offers several long-term advantages.

Controllers remain small and focused.
Broadcasting logic becomes reusable.
Additional listeners can be added later without modifying existing controllers.
Applications become easier to test.
Future integrations such as emails, Slack notifications, or analytics can reuse the same event.

Many experienced Laravel developers treat events as a communication layer inside the application. Once business logic finishes, everything else—notifications, logging, broadcasting, emails, and third-party integrations—can react independently through listeners or broadcast events.

Why Choose Pusher?

Pusher Channels is a hosted WebSocket service that works seamlessly with Laravel's broadcasting system. Instead of managing your own WebSocket infrastructure, Pusher handles persistent connections, message delivery, scaling, and connection management.

This significantly reduces the amount of infrastructure you need to maintain while allowing you to focus on building application features.

Some of its biggest advantages include:

Simple Laravel integration.
No WebSocket server management.
Reliable real-time message delivery.
Automatic connection handling.
Support for public, private, and presence channels.
Scales well for SaaS products and business applications.

For many teams, Pusher is the quickest way to introduce real-time functionality without investing time in infrastructure management.

Pusher vs Laravel Reverb

Since Laravel introduced Reverb, developers now have two excellent choices for implementing WebSocket communication.

Feature	Pusher	Laravel Reverb
Hosting	Managed Cloud Service	Self-hosted
Setup	Very Easy	Requires Server Configuration
Maintenance	Minimal	You Maintain Infrastructure
Scaling	Handled by Pusher	Your Responsibility
Best For	Rapid Development	Large Laravel Deployments

If your goal is to learn broadcasting quickly or ship features rapidly, Pusher provides an excellent developer experience.

If you prefer complete control over your infrastructure and are comfortable managing WebSocket servers, Laravel Reverb is a powerful modern alternative built by the Laravel team.

What We'll Build

Throughout this guide, we'll create a small but production-inspired application.

Regular users can publish posts.
Administrators automatically receive real-time notifications.
Notifications appear instantly without refreshing the page.

Although we're using posts to keep the tutorial easy to follow, the same implementation can be adapted for customer registrations, support tickets, order processing, appointment bookings, payment updates, or any other event that benefits from real-time communication.

Rather than simply copying code, we'll explain why each command is necessary, how every component fits into Laravel's broadcasting ecosystem, and what you should consider when implementing similar features in production.

Project Structure and Prerequisites

Before writing any code, let's look at the technologies used throughout this tutorial.

Laravel 13
PHP 8.4 or later
MySQL or MariaDB
Pusher Channels
Laravel Echo
Vite
Laravel Breeze (recommended) or Laravel UI

We'll also create two application roles:

Administrator — receives real-time notifications.
Regular User — creates new posts.

Whenever a regular user publishes a post, Laravel dispatches a broadcast event, Pusher delivers the event to connected browsers, and Laravel Echo updates the administrator's interface instantly.

Although this tutorial demonstrates a simple notification system, the architecture scales well to enterprise applications handling thousands of broadcast events every minute.

Step 1: Create a New Laravel Project

If you already have an existing Laravel application, you can skip this step. Otherwise, create a fresh Laravel project using Composer.

composer create-project laravel/laravel realtime-notifications

cd realtime-notifications

Next, configure your database credentials inside your .env file and run the default migrations.

php artisan migrate

This creates Laravel's default database tables, including the users table that we'll extend later.

Step 2: Install Authentication

Since our example requires two different users, we'll add authentication before implementing broadcasting.

Laravel Breeze is the recommended starter kit for modern Laravel applications because it's actively maintained and follows Laravel's latest frontend conventions.

composer require laravel/breeze --dev

php artisan breeze:install

npm install

npm run build

php artisan migrate

After installation, your application includes:

User registration
Login and logout functionality
Password hashing
Authentication middleware
Modern Blade views
Vite asset compilation

Although older tutorials still use Laravel UI, Breeze is the preferred authentication starter kit for Laravel 11, Laravel 12, and Laravel 13. The broadcasting concepts in this guide remain exactly the same regardless of the starter kit you choose.

Step 3: Prepare the Database

Our application requires two small database changes.

Add an is_admin column to the users table.
Create a posts table.

Generate the migrations.

php artisan make:migration add_is_admin_to_users_table

php artisan make:migration create_posts_table

Update the users migration.

<?php

Schema::table('users', function (Blueprint $table) {
    $table->boolean('is_admin')->default(false);
});

Next, create the posts table.

<?php

Schema::create('posts', function (Blueprint $table) {
    $table->id();

    $table->foreignId('user_id')
        ->constrained()
        ->cascadeOnDelete();

    $table->string('title');
    $table->text('body');

    $table->timestamps();
});

The foreign key ensures every post belongs to a valid user, while cascading deletes automatically remove related posts if a user is deleted.

Finally, execute the migrations.

php artisan migrate

Step 4: Create the Post Model

Our migration created the database table, but we still need an Eloquent model to interact with it.

Create the model using Artisan.

php artisan make:model Post

Now update the model.

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Post extends Model
{
    protected $fillable = [
        'title',
        'body',
    ];

    public function user(): BelongsTo
    {
        return $this->belongsTo(User::class);
    }
}

The $fillable property protects your application against mass-assignment vulnerabilities by explicitly defining which attributes may be assigned.

The user() relationship tells Laravel that every post belongs to exactly one user.

Later in the article, this relationship allows us to write expressive code like:

$post->user->name

instead of manually writing additional database queries.

Step 5: Add the User Relationship

The controller will create posts through the authenticated user, so the User model also needs a relationship.

Open app/Models/User.php and add the following method.

<?php

use Illuminate\Database\Eloquent\Relations\HasMany;

public function posts(): HasMany
{
    return $this->hasMany(Post::class);
}

This relationship allows Laravel to automatically associate newly created posts with the currently authenticated user.

Instead of writing:

$post = Post::create([
    'user_id' => auth()->id(),
    'title' => $validated['title'],
    'body' => $validated['body'],
]);

you can write the much cleaner and more expressive:

$post = auth()->user()->posts()->create($validated);

Laravel automatically fills the user_id column using the relationship.

Using Eloquent relationships keeps your code more readable and reduces the chance of accidentally assigning incorrect foreign keys.

Step 6: Configure Broadcasting

Laravel's broadcasting features aren't enabled in a fresh installation.

Fortunately, modern Laravel versions provide an Artisan command that performs most of the setup automatically.

php artisan install:broadcasting

This command creates the required broadcasting configuration and generates an echo.js file inside your JavaScript resources.

Next, install Pusher's PHP SDK.

composer require pusher/pusher-php-server

Laravel also needs the frontend libraries responsible for maintaining the WebSocket connection.

npm install laravel-echo pusher-js

npm run build

Step 7: Create a Pusher Application

Create a new application from your Pusher Channels dashboard.

Pusher will provide four credentials:

App ID
App Key
App Secret
Cluster

Add them to your .env file.

BROADCAST_CONNECTION=pusher

PUSHER_APP_ID=your-app-id
PUSHER_APP_KEY=your-app-key
PUSHER_APP_SECRET=your-app-secret
PUSHER_APP_CLUSTER=ap2

VITE_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
VITE_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"

Never commit Pusher credentials to Git. Store them only in environment variables and use different credentials for local, staging, and production environments.

Step 8: Configure Laravel Echo

Laravel generates an echo.js file after installing broadcasting.

Update it as shown below.

import Echo from 'laravel-echo';

import Pusher from 'pusher-js';
window.Pusher = Pusher;

window.Echo = new Echo({
    broadcaster: "pusher",
    key: import.meta.env.VITE_PUSHER_APP_KEY,
    cluster: import.meta.env.VITE_PUSHER_APP_CLUSTER,
    forceTLS: true,
    wsHost: import.meta.env.VITE_PUSHER_HOST,
    wsPort: import.meta.env.VITE_PUSHER_PORT,
    wssPort: import.meta.env.VITE_PUSHER_PORT,
    enabledTransports: ["ws", "wss"],
});

One step that's commonly missed in tutorials is importing this file into your application's main JavaScript entry point.

Open resources/js/app.js and add:

import './echo';

Without importing echo.js, Laravel Echo never initializes, meaning your browser won't subscribe to any broadcast channels.

Finally, rebuild your frontend assets.

npm run build

Project Structure So Far

At this stage, your application should look similar to the following.

app
├── Events
├── Http
│   └── Controllers
├── Models
│   ├── Post.php
│   └── User.php
│
resources
└── js
    ├── app.js
    └── echo.js

routes
├── web.php
└── channels.php

Having this structure in place makes the remaining implementation much easier to follow. In the next section, we'll create the broadcast event, build the controller, dispatch the event after saving a post, subscribe to the broadcast channel with Laravel Echo, and display real-time notifications inside the browser.

Step 9: Create the Broadcast Event

Now that the project is configured, it's time to create the event responsible for broadcasting newly created posts.

Instead of sending WebSocket messages directly from the controller, Laravel encourages using events. This keeps your business logic clean while allowing multiple parts of the application to react independently.

Generate the event using Artisan.

php artisan make:event PostCreated

Update the generated class as shown below.

<?php

namespace App\Events;

use App\Models\Post;
use Illuminate\Broadcasting\Channel;
use Illuminate\Contracts\Broadcasting\ShouldBroadcast;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;

class PostCreated implements ShouldBroadcast
{
    use Dispatchable, SerializesModels;

    public function __construct(
        public Post $post
    ) {
    }

    public function broadcastOn(): Channel
    {
        return new Channel('posts');
    }

    public function broadcastAs(): string
    {
        return 'post.created';
    }

    public function broadcastWith(): array
    {
        return [
            'id'         => $this->post->id,
            'title'      => $this->post->body,
            'author'     => $this->post->user->name,
            'created_at' => $this->post->created_at->toDateTimeString(),
        ];
    }
}

Notice that the event broadcasts only the data the frontend actually needs instead of exposing the complete Post model.

This keeps payloads smaller, reduces serialization overhead, and avoids accidentally exposing sensitive information.

Why use ShouldBroadcast instead of ShouldBroadcastNow?

For production applications, ShouldBroadcast is usually the better choice because the event is processed through Laravel's queue system. This keeps HTTP requests fast even when your application broadcasts thousands of events. Use ShouldBroadcastNow only when immediate delivery is absolutely necessary.

Step 10: Define the Application Routes

Next, create the routes in web.php that responsible for displaying posts and storing newly created ones.

<?php

use App\Http\Controllers\PostController;
use Illuminate\Support\Facades\Route;

Route::middleware('auth')->group(function () {

    Route::get('/posts', [PostController::class, 'index'])
        ->name('posts.index');

    Route::post('/posts', [PostController::class, 'store'])
        ->name('posts.store');

});

Both routes are protected by the auth middleware, ensuring that only authenticated users can create posts or receive notifications.

Step 11: Build the Controller

Create the controller if it doesn't already exist.

php artisan make:controller PostController

Update the controller with the following implementation.

<?php

namespace App\Http\Controllers;

use App\Events\PostCreated;
use App\Models\Post;
use Illuminate\Http\Request;

class PostController extends Controller
{
    public function index()
    {
        $posts = Post::with('user')
            ->latest()
            ->get();

        return view('posts.index', compact('posts'));
    }

    public function store(Request $request)
    {
        $validated = $request->validate([
            'title' => ['required', 'string', 'max:255'],
            'body'  => ['required', 'string'],
        ]);

        $post = auth()->user()
            ->posts()
            ->create($validated);

        $post->load('user');

        broadcast(new PostCreated($post))
            ->toOthers();

        return redirect()
            ->back()
            ->with('success', 'Post created successfully.');
    }
}

Several production-ready improvements are worth mentioning.

Validation happens before any database operation.
The post is created through the authenticated user's relationship.
The related user is eager loaded before broadcasting.
broadcast()->toOthers() prevents duplicate notifications in the same browser session.

Loading the relationship before broadcasting prevents additional database queries while Laravel serializes the event payload.

Why `toOthers()` Matters

This is one of the most misunderstood parts of Laravel Broadcasting.

Without calling:

broadcast(new PostCreated($post));

the browser that created the post will also receive the broadcast event.

That usually results in duplicate UI updates because the user already knows they created the post.

Instead, Laravel allows you to exclude the current WebSocket connection.

broadcast(new PostCreated($post))
    ->toOthers();

Laravel automatically uses the current socket ID supplied by Laravel Echo to exclude that browser connection while still notifying every other connected client.

Many developers think toOthers() excludes the authenticated user. It doesn't. It excludes only the current browser connection. If the same user has your application open in another browser or another device, those sessions will still receive the event.

Step 12: Listen for Events with Laravel Echo

Broadcasting an event is only half of the process. The browser must also subscribe to the channel and react whenever a new event arrives.

Laravel Echo makes this extremely straightforward.

window.Echo
    .channel('posts')
    .listen('.post.created', (event) => {

        console.log(event);

        showNotification(event);

    });

Whenever Laravel broadcasts the PostCreated event, every subscribed browser immediately receives the payload returned by broadcastWith().

At this point, the browser can:

Display toast notifications.
Append new rows to a table.
Refresh dashboard statistics.
Update charts.
Increment notification badges.

No additional HTTP request is required.

Step 13: Build a Reusable Notification Function

Many beginner tutorials inject HTML directly inside the Echo listener.

While this works for demonstrations, it becomes difficult to maintain as your application grows.

A cleaner approach is to move rendering into its own function.

function showNotification(event) {

    const container = document.getElementById('notifications');

    container.insertAdjacentHTML(
        'afterbegin',
        `
            <div class="alert alert-success mb-2">

                <strong>New Post Published</strong>

                <p class="mb-0">

                    ${event.author} published
                    "${event.title}"

                </p>

            </div>
        `
    );

}

Separating rendering logic makes it much easier to replace Bootstrap alerts with Toast notifications, Alpine.js components, Livewire, Vue, or React later without changing your broadcasting code.

What Should the Blade View Contain?

Since the focus of this article is broadcasting rather than frontend development, we won't build the complete Blade template. However, your posts/index.blade.php page should include the following elements.

A form for creating new posts.
A container with the ID notifications where real-time alerts will appear.
A list of previously published posts.
Your compiled JavaScript assets using Vite.

As long as those elements exist, the broadcasting example shown throughout this guide will work correctly regardless of whether you're using Bootstrap, Tailwind CSS, Livewire, Alpine.js, Vue, or React.

This tutorial intentionally keeps the frontend implementation minimal so you can adapt the broadcasting logic to your preferred frontend stack without rewriting your backend.

Testing the Complete Workflow

At this point, the application is ready for testing.

Open two different browsers or use an incognito window.
Login as an administrator in the first browser.
Login as a regular user in the second browser.
Navigate both users to the posts page.
Create a new post using the regular user's account.

If everything has been configured correctly, the workflow should look like this.

The post is stored in the database.
Laravel dispatches the PostCreated event.
The event is queued and broadcast to Pusher.
Pusher delivers the event to connected clients.
Laravel Echo receives the event.
The administrator immediately sees the notification without refreshing the page.

You've now built a complete real-time notification flow using Laravel Broadcasting, Pusher, and Laravel Echo. In the final phase, we'll cover debugging strategies, performance optimization, production best practices, comparisons, FAQs, SEO recommendations, screenshot suggestions, and the finishing touches that make this guide production-ready.

Complete Source Code

If you'd like to compare your implementation with a working example or prefer to start from a complete project, the full source code used in this tutorial is available on GitHub.

GitHub Repository:

https://github.com/fadi06/realtime-notifications-with-pusher

The repository includes the complete Laravel application with broadcasting configured, Pusher integration, event broadcasting, Laravel Echo setup, and real-time notifications. You can clone it locally to follow along with the article or use it as a reference if you encounter any issues.

Common Broadcasting Problems and Their Solutions

Broadcasting involves several moving parts, including Laravel, Pusher, Laravel Echo, queues, and JavaScript. A small configuration mistake in any one of these can prevent events from reaching the browser.

The good news is that most broadcasting issues are straightforward to diagnose once you know where to look.

Events Never Reach the Browser

If your controller executes successfully but no notification appears, verify the following:

Your .env contains the correct Pusher credentials.
BROADCAST_CONNECTION is set to pusher.
Your queue worker is running when using ShouldBroadcast.
You rebuilt frontend assets after editing echo.js.
The browser successfully connects to Pusher.

Whenever you update environment variables, remember to clear Laravel's cached configuration.

php artisan optimize:clear

php artisan config:clear

Queue Worker Isn't Running

If your event implements ShouldBroadcast, Laravel sends the broadcast through the queue system.

Without an active queue worker, your events remain in the queue and never reach Pusher.

Start a worker using:

// .env
QUEUE_CONNECTION=database

// run in terminal
php artisan queue:work

Many developers mistakenly believe broadcasting is broken when the real issue is simply that no queue worker is processing jobs.

Laravel Echo Doesn't Connect

Open your browser's Developer Tools and inspect the Network and Console tabs.

Common causes include:

Incorrect App Key.
Wrong Pusher Cluster.
Mixed HTTP and HTTPS configuration.
WebSocket connections blocked by a firewall or proxy.
echo.js wasn't imported into app.js.

If Echo never connects, no broadcast event will ever arrive regardless of how correctly your Laravel backend is configured.

Events Fire Twice

This usually happens because the browser that created the post also receives the broadcast.

Use:

broadcast(new PostCreated($post))
    ->toOthers();

to prevent duplicate notifications for the current browser session.

Private Channels Return 403 Errors

If you later replace the public channel with a private channel, Laravel authorizes every subscription before allowing users to receive events.

Most authorization failures occur because the callback inside routes/channels.php hasn't been configured correctly.

Always verify channel authorization before debugging JavaScript.

Performance Considerations

Broadcasting is lightweight, but large applications can generate thousands of events every minute. A few architectural decisions can dramatically improve scalability.

Broadcast Only the Data You Need

Avoid broadcasting complete Eloquent models.

Instead of:

return [
    'post' => $this->post,
];

Prefer:

return [
    'id'     => $this->post->id,
    'title'  => $this->post->title,
    'author' => $this->post->user->name,
];

Smaller payloads reduce serialization time, improve transmission speed, and consume less bandwidth.

Use Queued Broadcasting

Queued broadcasts prevent users from waiting while Laravel communicates with external services.

For almost every production application, prefer ShouldBroadcast over ShouldBroadcastNow.

Eager Load Relationships

If your broadcast payload references related models, eager load them before dispatching the event.

$post->load('user');

This avoids additional database queries while Laravel serializes the event.

Choose the Right Channel Type

Channel Type	Use Case
Public Channel	Public dashboards and announcements
Private Channel	User-specific notifications
Presence Channel	Chat rooms and online user lists

For demonstration purposes, this tutorial uses a public channel. In production, notifications that contain user-specific information should almost always use private channels.

Pusher vs Traditional Polling

Feature	Pusher Broadcasting	Traditional Polling
Updates	Instant	Delayed
Server Requests	Only when events occur	Continuous HTTP requests
Server Load	Lower	Higher
User Experience	Excellent	Depends on polling interval
Best For	Live dashboards, chat, notifications	Occasional updates

If updates occur only once every few hours, polling is often sufficient. However, applications requiring immediate feedback benefit significantly from broadcasting.

Broadcast Events vs Laravel Notifications

Feature	Broadcast Events	Laravel Notifications
Primary Purpose	Real-time UI updates	User notifications
Email Support	No	Yes
Database Notifications	No	Yes
Real-time Support	Yes	Yes (Broadcast Channel)
Best Choice	Updating interfaces instantly	Multi-channel communication

Broadcast events and Laravel Notifications aren't competitors. In many production systems, notifications themselves are broadcast so users receive them instantly while also storing them in the database.

Production Best Practices

Keep controllers focused on business logic.
Broadcast only the minimum required data.
Prefer queued broadcasting.
Use private channels for sensitive information.
Never expose secrets inside broadcast payloads.
Monitor failed queue jobs.
Log broadcasting failures.
Reuse events throughout your application whenever possible.

As applications grow, broadcasting often becomes part of the application's core architecture. Investing time in clean event design, proper authorization, and efficient payloads will pay dividends as your application scales.

Frequently Asked Questions

Does Laravel support broadcasting by default?

Yes. Laravel includes a built-in broadcasting system that integrates seamlessly with Pusher, Laravel Reverb, Ably, and other broadcasting drivers.

Should I use Pusher or Laravel Reverb?

Pusher is ideal if you want the quickest setup with minimal infrastructure management. Laravel Reverb is better suited for teams that prefer hosting their own WebSocket server.

Can Livewire receive broadcast events?

Yes. Livewire integrates well with Laravel Echo, allowing components to refresh automatically whenever broadcast events are received.

Can I broadcast to a single user?

Absolutely. Private channels allow Laravel to send events only to authorized users.

Is queued broadcasting required?

No, but it's highly recommended for production applications because it improves response times and scales much better under heavy traffic.

Can I replace Pusher later?

Yes. Because Laravel abstracts broadcasting through drivers, migrating from Pusher to Laravel Reverb or another supported provider typically requires only configuration changes.

Conclusion

Real-time functionality has become a standard expectation in modern web applications. Whether you're building an admin dashboard, messaging platform, support system, or SaaS product, users expect updates to appear immediately without refreshing the page.

Laravel's broadcasting system makes this remarkably approachable. By combining Events, Broadcasting, Laravel Echo, and Pusher, you can build responsive applications that keep users informed the moment something important happens.

Although this tutorial demonstrated a simple post notification system, the same architecture applies to live order tracking, payment updates, collaborative editing, monitoring dashboards, and countless other real-world scenarios.

As your application grows, focus on clean architecture as much as real-time functionality. Keep controllers small, broadcast only essential data, secure sensitive channels with proper authorization, and leverage queues to ensure your application remains responsive under load.

Key Takeaways

Laravel Broadcasting enables real-time communication between your application and connected browsers.
Pusher provides one of the easiest ways to implement WebSocket functionality.
Laravel Echo automatically listens for broadcast events on the frontend.
Events help separate business logic from real-time communication.
Queued broadcasting improves scalability and response times.
Broadcast only the data required by the frontend.
Private channels should be used for user-specific notifications.
Laravel Reverb offers an excellent self-hosted alternative to Pusher.

Author's Note: Pusher is one of the fastest ways to introduce real-time functionality into a Laravel application. Once you're comfortable with Laravel's broadcasting architecture, transitioning to Laravel Reverb or another broadcasting driver is usually a matter of configuration rather than rewriting your application.

12 Must-Know Laravel Tips from July 2025

Laravel Daily tips — Wed, 06 Aug 2025 14:23:20 +0000

This blog curates 12 practical Laravel and PHP tips shared by the developer community on X (formerly Twitter) in July 2025. From avoiding ambiguous column errors in Eloquent scopes to new features like whereValueBetween() and secure password generation with Str::password(), these insights can help improve your day-to-day Laravel development. Each tip is explained with a use-case example, making this blog a valuable resource for Laravel developers of all levels.

Every month, the Laravel community on Twitter (or X) shares a ton of useful tips and tricks. This post gathers some of the best insights from July, covering everything from Eloquent to Carbon and API responses. Let's dive into 12 tips that can make you a more efficient Laravel developer

1. Eloquent Scopes with `getTable()` for Ambiguous Columns

When you're working with database tables that have columns with the same name (like is_displayed), you might run into an "ambiguous column" SQL error during joins. A simple way to avoid this is to prefix the column name with the table name.

Instead of writing:

public function scopeIsDisplayed(Builder $query): void
{
    $query->where('is_displayed', 1);
}

Do this:

public function scopeIsDisplayed(Builder $query): void
{
    $query->where($this->getTable() . '.is_displayed', 1);
}

The $this->getTable() method dynamically gets the current model's table name, ensuring the query is explicit and error-free. An alternative method is qualifyColumn(), but getTable() is often considered more readable.

2. Carbon's `is...` Methods

The Carbon library, a standard part of Laravel, has an extensive list of helpful methods for comparing dates. Instead of manually checking if a date is today, tomorrow, or a weekday, you can use Carbon's built-in is... methods.

A few examples:

$date->isToday()
$date->isTomorrow()
$date->isYesterday()
$date->isWeekend()
$date->isWeekday()
$date->isSameDay($otherDate)

Before writing your own date comparison logic, check the Carbon documentation, it likely has a method for what you need.

3. Response Macros for Consistent APIs

You can create consistent API responses across your application using Response Macros. While a base controller or a trait is a common approach, macros offer a clean way to standardize responses directly in a service provider.

First, define a macro in your AppServiceProvider (or a dedicated service provider):

// app/Providers/ResponseMacroServiceProvider.php
public function boot(): void
{
    Response::macro('apiSuccess', function (
        string $message = 'Success',
        int $statusCode = 200,
        array $data = []
    ) {
        return response()->json([
            'success' => true,
            'message' => $message,
            'data' => $data,
        ], $statusCode);
    });
}

Then, you can use this macro in any of your controllers:

return response()->apiSuccess('User created successfully.');

This centralizes your response logic, making it easy to maintain a consistent API.

4. `in_array_keys` Validation Rule

Laravel 12.29 introduced a new validation rule: in_array_keys. This is useful for validating that a value exists as a key within a given array.

For example, if you have an array of permissions and you want to ensure the selected_permission is one of the valid keys:

$request->validate([
    'permissions' => ['required', 'array'],
    'selected_permission' => ['required', 'string', 'in_array_keys:permissions'],
]);

This is a more concise way to handle this common validation scenario.

5. `isset()` with Multiple Parameters

Did you know that PHP's isset() function can accept multiple parameters? This is a handy and often overlooked feature.

The function will return true only if all the provided variables are set and not null.

if (isset($data, $meta, $items)) {
    // This code will only execute if all three variables are set.
}

This can simplify your conditional checks and make your code more readable by avoiding nested if statements or multiple && checks.

6. Exception Methods for Granular Error Messages

Sometimes, a single exception class can handle multiple types of errors. You can define different methods within a custom exception class to provide specific error messages.

// In a custom exception class
class PaymentException extends Exception
{
    public static function cardExpired(): self
    {
        return new self('The credit card has expired.');
    }

    public static function insufficientFunds(): self
    {
        return new self('There are insufficient funds to complete the payment.');
    }
}

// In your controller
throw PaymentException::cardExpired();

While you can also create separate exception classes for each scenario, this method allows you to group related exceptions under a single class.

7. The `whereBetween()` Query Builder Shortcut

Laravel 12.21 introduced a small but powerful syntactic sugar to the query builder: whereBetween(). This method simplifies queries where you need to check if a value falls between two other values.

Instead of this:

$query->where('value', '>=', $from)
      ->where('value', '<=', $to);

You can write this:

$query->whereBetween('value', [$from, $to]);

This makes your queries more concise and easier to read.

8. `Str::password()` for Secure Passwords

When you need to generate a secure random password, the Str::password() helper is the ideal tool. It gives you fine-grained control over the generated string.

use Illuminate\Support\Str;

$password = Str::password(
    length: 12,
    letters: true,
    numbers: true,
    symbols: true,
    spaces: false,
);

You can specify the length and whether the password should include letters, numbers, symbols, or spaces. This is a much better alternative to Str::random() for generating passwords.

9. Database-Backed Notifications

Laravel's notification system is incredibly flexible. While it's commonly used for emails, you can also store notifications directly in your database. This is perfect for creating in-app notification systems (like the alerts you see on many websites).

You can use methods like:

$user->unreadNotifications(): Retrieves all unread notifications.
$notification->markAsRead(): Marks a specific notification as read.
$user->markAsRead(): Marks all notifications for a user as read.

You can even send a notification to multiple channels at once (e.g., both email and the database) by specifying them in your notification class's via() method.

10. Nested Database Transactions

Laravel allows you to nest database transactions, and the framework will scope them to the outermost transaction. This means if a nested transaction fails, the entire chain of transactions will be rolled back.

DB::transaction(function () {
    // This is the outer transaction
    $user = User::create(...);

    DB::transaction(function () {
        // This is a nested transaction
        $profile = $user->profile()->create(...);

        if (!$profile) {
            // Throwing an exception here will roll back both transactions
            throw new Exception('Profile creation failed.');
        }
    });
});

This can be useful if you have reusable actions that need to operate within their own transaction but also need to be called from a larger, overarching transaction.

11. Custom Validation Message Attributes

The default Laravel validation messages often include the word "field," as in "The name field is required." You can make these messages more user-friendly by simply removing the word "field" from the validation file.

Simply update your lang/en/validation.php file to change:

'required' => 'The :attribute field is required.',

to:

'required' => 'The :attribute is required.',

Now, your error message will read "The name is required," which is clearer and less technical for the end-user.

12. Grouping Tests in Pest with `describe`

If you use the Pest testing framework, you can use the describe() function to group related tests. This is not only for organization but also for sharing setup and teardown logic.

describe('User creation', function () {
    beforeEach(function () {
        // This runs before each test in this group
        $this->actingAs(User::factory()->create());
    });

    it('can create a user', function () {
        // ... test logic
    });

    it('validates user data', function () {
        // ... test logic
    });
});

This feature, introduced in Pest v0.2.9, makes your tests more organized and maintainable, especially for complex features.

Have you learned anything new from this list? Which of these tips will you be adding to your own Laravel projects? Let us know in the comments!

🚀 Want more powerful Laravel tips like this?
Join my newsletter and stay ahead with exclusive insights 👉 LaravelDailyTips.com 💡

Livewire 4: Faster, Simpler, and More Powerful!

Laravel Daily tips — Mon, 04 Aug 2025 15:49:41 +0000

Livewire 4 has officially launched, and it’s packed with exciting features aimed at making your Laravel development faster, easier, and more organized. Caleb Porzio unveiled these updates at Laracon US 2025, and while we strongly recommend watching his talk, here’s a super simple breakdown of everything you need to know, with real-life examples!

1. Single-File Components (SFC) Are the New Default

What Changed?

When you now run:

php artisan make:livewire Counter

Livewire 4 will create a single file that contains all the logic (PHP), HTML, and JavaScript for your component.

Example:

// counter.blade.php  
<div>  
    <button wire:click="increment">+</button>  
    <span>{{ $count }}</span>  
</div>  

<script>  
    // JS logic here  
</script>  

<?php  
class Counter extends Component {  
    public $count = 0;  
    public function increment() { $this->count++; }  
}  
?>

Why It’s Awesome:

You don’t have to switch between three different files. Everything is in one file—clean and compact!

Real-Life Example:

It’s like using a single notepad to jot down a recipe: ingredients, steps, and cooking notes, all in one place. Easy to manage and update!

2. Multi-File Components (MFC) When You Need More Structure

What Changed?

If your component starts growing and you want to separate things for better organization, run:

php artisan make:livewire profile --mfc

It will generate:

Profile.php (Logic)
Profile.blade.php (View)
Profile.js (JavaScript)
profile.test.php (Test file)

All in the same folder.

Why It’s Awesome:

Easier to maintain big components. You can focus on just the HTML or just the JS, without distractions.

Real-Life Example:

Imagine your kitchen tools, cutlery in one drawer, spices on one shelf, and cooking pots in a cabinet. Everything is separate but close together.

3. Livewire::visit(): Browser Testing Like a Human

What Changed?

Pest 4 introduces Livewire::visit(), letting you test Livewire components in a real browser (thanks to Playwright).

test('counter increments', function () {  
    Livewire::visit(Counter::class)  
        ->assertSee(0)
        ->debug()
        ->click('button')  
        ->assertSee(1);  
});

Why It’s Awesome:

You can test your Livewire components in the browser just like an actual user would click around. Great for catching real-world issues.

Real-Life Example:

Think of this as practicing a speech in front of a mirror. You get to see how it actually performs, not just how it looks on paper.

4. ⚡Blaze – Supercharged Rendering Performance

What Changed?

Livewire 4 introduces Blaze, a performance engine under the hood that makes rendering much faster.

Why It’s Awesome:

Pages load quicker. Updates happen in a snap. Less waiting means a better user experience.

Real-Life Example:

It’s like switching from a bicycle to an electric scooter. You’re still doing the same thing (going from A to B), but much faster!

5. Component Slots – Flexible and Reusable

What Changed?

Livewire components now support slots with syntax like {{ $slot }}.

<!-- alert.blade.php -->  
<div class="alert">  
    {{ $slot }} <!-- Content goes here -->  
</div>  

<!-- Usage -->  
<x-alert>  
    <p>Success! Your order is placed.</p>  
</x-alert>

Why It’s Awesome:

You can create flexible components and inject content wherever needed.

Real-Life Example:

Imagine a gift box where you can swap in a birthday card or a wedding card depending on the occasion. Same box, different content!

6. @island Directive – Isolate the Heavy Parts

What Changed?

With the @island directive, you can isolate expensive or slow parts of a component. You can even make it:

Load lazily (lazy: true)
Refresh (poll) every few seconds (@island(poll: '5s'))

<div>  
    <!-- Fast part -->  
    <h1>Welcome, {{ $user->name }}!</h1>  

    <!-- Slow part (isolated) -->  
    @island(lazy: true, poll: '5s')  
        <livewire:order-history />  
    @endisland  
</div>

Why It’s Awesome:

This boosts performance. Only the “island” loads when needed, not the whole page.

Real-Life Example:

Think of this like lazy-loading images on a long article. The full article loads quickly, and images load when they come into view.

Bonus: Placeholder Support While Islands Load

You can even display a skeleton loader or a loading message until the island content is ready:

@island(lazy: true)
    <x-loading-spinner />
@endisland

Real-Life Example:

It’s like showing a "loading…" screen while your food order is being prepared. Keeps the user informed and engaged.

Final Thoughts:

Livewire 4 focuses on developer experience (DX) and performance. Whether you're building small UI components or full dashboards, the new updates will:

Simplify your workflow
Improve performance
Make testing easier

Next step? Watch Caleb’s talk from Laracon US 2025 and try these features in your next project.

🚀 Want more powerful Laravel tips like this?
Join my newsletter and stay ahead with exclusive insights 👉 LaravelDailyTips.com 💡

Laravel 12: Simplifies Soft Delete Routing with New softDeletableResources() Method

Laravel Daily tips — Mon, 04 Aug 2025 15:48:06 +0000

Laravel 12.22 introduces a new method called softDeletableResources() to simplify how developers define routes for models that use soft deletes. Previously, developers had to manually attach ->withTrashed() to each resource route, which could clutter the route files, especially when dealing with multiple soft-deletable models. This new approach groups those routes into a single, elegant call, improving code clarity and reducing repetition.

The new method is not only more readable but also aligns with Laravel’s philosophy of clean and expressive syntax. By centralizing soft-deletable routes, it becomes easier to manage and scale your application without losing track of special route configurations. Laravel continues to deliver thoughtful improvements that help developers write cleaner, more maintainable code

Laravel Routing Gets a Cleanup for Soft Deletes

When working with models that implement SoftDeletes in Laravel, it’s common to append .withTrashed() to your resource routes. While this works perfectly, it becomes repetitive and cluttered as the number of soft-deletable models grows.

The Old Way:

Here’s how developers traditionally defined soft-deletable resource routes:

Route::resource('users', UserController::class)->withTrashed();
Route::resource('blogs', BlogController::class)->withTrashed();

While functional, repeating ->withTrashed() across routes clutters your routes file and breaks DRY principles.

What’s New in Laravel 12.22?

Laravel 12.22 introduces a new method to clean up your route definitions:

Route::softDeletableResources([
    'users' => UserController::class,
    'blogs' => BlogController::class,
]);

This method allows you to register multiple soft-deletable resource routes in a single, clean call.

Benefits of `softDeletableResources()`:

DRY-compliant: No more repeated ->withTrashed() calls.
Clean structure: Routes become more readable and manageable.
Scalable: Add or remove soft-deletable resources with ease.

When Should You Use It?

Use softDeletableResources() when:

Your models implement Illuminate\Database\Eloquent\SoftDeletes.
You want to expose trashed records via standard resource routes.
You care about maintaining a tidy and maintainable routes file.

Final Thoughts

Laravel’s updates consistently aim to reduce boilerplate code. With the softDeletableResources() addition in 12.22, you can streamline your soft delete routes and focus more on building features instead of writing repetitive route definitions.

Keep an eye out for more elegant updates like this in future Laravel versions!

🚀 Want more powerful Laravel tips like this?
Join my newsletter and stay ahead with exclusive insights 👉 LaravelDailyTips.com 💡

Boost Laravel Performance with LazyCollection and cursor()

Laravel Daily tips — Mon, 04 Aug 2025 15:46:18 +0000

Laravel LazyCollection and cursor() are game-changers for handling large datasets efficiently. Instead of consuming all memory upfront, these tools stream data line-by-line or record-by-record. For instance, using LazyCollection to parse a user activity file or cursor() for high-value order reports ensures your application remains fast and responsive even with massive data.

These techniques not only improve Laravel performance but also help with tasks like CSV processing, large database queries, and memory optimization in Laravel. Implementing them in your Laravel workflow guarantees scalable and efficient application architecture.

Managing large datasets in Laravel can be overwhelming, especially when server memory becomes a bottleneck. Laravel's LazyCollection and cursor() method offer powerful tools to handle this challenge effectively by reducing memory consumption during data processing.

What is LazyCollection?

LazyCollection is a memory-friendly feature in Laravel that reads data only when it’s needed, instead of loading everything into memory at once. This lazy-loading behavior is perfect for working with big files, streaming responses, or looping through extensive data.

Here’s a simple use-case of reading a log file and processing lines containing errors:

use Illuminate\Support\LazyCollection;

LazyCollection::make(function () {
    $handle = fopen(storage_path('logs/system.log'), 'r');
    while (($line = fgets($handle)) !== false) {
        yield $line;
    }
})
->filter(fn($line) => str_contains($line, 'ERROR'))
->each(function ($errorLine) {
    // Handle each error line (e.g., store or alert)
});

This allows Laravel to process a huge log file without crashing due to memory overload.

Real-world Application: Importing User Activity

Suppose you’re importing user activity from a text file for analysis. LazyCollection can help transform and insert data in chunks without overloading the system.

use App\Models\UserActivity;
use Illuminate\Support\LazyCollection;

class UserActivityImporter
{
    public function import(string $filepath)
    {
        LazyCollection::make(function () use ($filepath) {
            $file = fopen($filepath, 'r');
            while (($line = fgets($file)) !== false) {
                yield explode('|', trim($line));
            }
        })
        ->map(fn($entry) => [
            'user_id' => $entry[0],
            'action' => $entry[1],
            'timestamp' => $entry[2],
        ])
        ->chunk(300)
        ->each(fn($chunk) => UserActivity::insert($chunk->all()));
    }
}

Using cursor() for Large DB Queries

For database-heavy applications, Laravel’s cursor() method retrieves results lazily using generators, this helps process millions of rows without memory issues.

use App\Models\Order;

class OrderAnalyzer
{
    public function analyze()
    {
        Order::cursor()
            ->filter(fn($order) => $order->total > 5000)
            ->each(fn($order) => $this->notifyHighSpender($order));
    }

    protected function notifyHighSpender($order)
    {
        // Send notification or flag order
    }
}

This technique avoids loading all orders into memory and allows on-the-fly processing.

Final Thoughts:

Leveraging Laravel's LazyCollection and cursor() transforms how you handle large datasets, turning memory-heavy tasks into streamlined, efficient processes. Whether you're importing logs, processing user activity, or analyzing millions of records, these tools help keep performance high and memory usage low. Start using them today to build scalable, high-performing Laravel applications

🚀 Want more powerful Laravel tips like this?
Join my newsletter and stay ahead with exclusive insights 👉 LaravelDailyTips.com 💡

Advanced Git Mastery – Second edition 2025

Laravel Daily tips — Thu, 31 Jul 2025 15:07:02 +0000

Git helps you work smarter and safer. With git reflog, you can recover lost commits, and tools like git clean and git gc help you remove extra files and speed up your project. Git aliases let you create shortcuts for commands, saving you time every day. Exploring the .git folder gives you insight into how Git manages your project internally.

For team projects, choosing the right Git workflow is key. Git Flow, GitHub Flow, and Trunk-Based Development each support different types of teams and release styles. Writing clear commit messages, squashing fixes, and using pull requests are all best practices that keep your code clean and easy to review.

1. Recovering with Reflog (`git reflog`)

What is `git reflog`?

It tracks every move of your HEAD, even those Git doesn't normally show.
If you accidentally delete a commit, reset a branch, or mess something up, reflog can save your day.

Real-World Example: Time Machine for Your Code

Imagine you’re writing a book. Every time you print a copy (commit), you store it.

One day, you get confused and:

Rip out a few pages
Or throw away the last version
Or accidentally go back to an older version

You think: “Oh no! I lost my best work!”

That’s where `git reflog` comes in!

git reflog

It shows a history like:

a1b2c3d HEAD@{0}: reset: moving to previous version
f4e5f6g HEAD@{1}: commit: Add contact form
c7d8e9h HEAD@{2}: commit: Fix login issue

Each line = a step you took (checkout, commit, reset, merge, etc.)

How to Recover

1. See the history:

git reflog

2. Choose the commit you want to go back to (copy the hash)

3. Restore it:

Just look at the old state:

git checkout <commit-id>

Or move your branch back completely:

git reset --hard <commit-id>

Be careful: --hard will overwrite current working files.

When to Use `git reflog`

You did git reset --hard and lost work
You force-pushed or deleted a branch accidentally
You want to go back to any previous state, even if it’s not in git log

Sooooo, Now you better understand the magic of GIT and reflog 😉

10. Cleaning Up with `git clean`, `git gc`

1. `git clean` – Remove Untracked Junk

When you're working on a project, sometimes you create extra files or folders that aren’t tracked by Git, like:

Temporary files (.log, .tmp, etc.)
Build output (e.g., dist/, node_modules/, etc.)
Mistakenly added files

These don’t show up in git status as staged or committed, but they clutter your folder.

Real-World Analogy:

Imagine your desk has:

Files you've already filed in drawers (committed files)
Files you’ve decided to file next (staged files)
Sticky notes, wrappers, and paper scraps all over (untracked files)

You use git clean to throw away those scraps.

Commands:

git clean -f     # Clean untracked files only
git clean -fd    # Clean untracked files AND folders

Be careful – this deletes files permanently.

To preview before deleting, use:

git clean -n

2. `git gc` – Optimize Your Repository

Over time, Git stores:

Deleted commits
Unreachable branches
Old pack files

These pile up and make your repo heavier.

Think of It Like:

Defragmenting your hard drive or cleaning up cache, it keeps things fast and tidy.

Command:

git gc

This stands for Garbage Collection.

It will:

Compress files
Remove unnecessary objects
Optimize Git's internal storage

11. Git Aliases to Boost Productivity

Speed up typing with aliases.

Example:

git config --global alias.st status
git config --global alias.co checkout

Now use:

git st
git co main

Save hours over time!

11. Exploring the `.git` Folder – The Brain of Your Git Repo

What is `.git`?

When you run git init, Git creates a hidden folder called .git inside your project.

This folder is like the brain and memory of your Git project.
It contains everything Git needs to track changes, branches, commits, and settings.

Real-World Analogy:

Think of your Git project like a house, and the .git folder is the control room in the basement.

You don’t see it during daily use
But it runs everything behind the scenes
If you delete it, you lose all history

Let’s Explore It

Run:

ls .git

You’ll see something like this:

HEAD
config
objects/
refs/
logs/
index

Important Parts Explained:

Folder/File	What It Does
`objects/`	Stores all Git data (commits, files, trees)
`refs/`	Contains branches and tags
`HEAD`	Points to your current branch
`config`	Local Git settings for this repo
`logs/`	Stores reflog history – all HEAD movements
`index`	The staging area snapshot

Tip:

Do NOT edit files in .git manually, unless:

You really know what you're doing
You're debugging or recovering a repo

One wrong change can corrupt your Git repo.

14. Best Practices for Teams

Writing Good Commit Messages

Start with a capital letter
Keep the first line under 50 characters
Describe what and why

git commit -m "Fix login redirect on mobile"

Reviewing and Squashing Commits

Use Pull Requests to review code. Use:

git rebase -i

to squash “fix” commits before merging.

Handling Large Files

Git isn't built for binary files or large assets. Use:

git lfs install
git lfs track "*.psd"

Git LFS (Large File Storage) stores them efficiently outside your repo.

Final Thoughts

Git is more than just version control, it's a toolbox for collaboration, automation, and code safety. Mastering these advanced tools can drastically improve your efficiency, team collaboration, and confidence during critical development tasks.

Next Step:
Missed the basics? Git for Beginners
Or continue from intermediate level: Git Intermediate Guide
Or continue from advanced level Part 1: Git Advanced Guide Part 1
Or continue from advanced level Part 2: Git Advanced Guide Part 2

Advanced Git Mastery – First edition 2025

Laravel Daily tips — Thu, 31 Jul 2025 15:02:51 +0000

Once you're comfortable with the basics and intermediate Git concepts, it's time to unlock Git's full potential. This guide is packed with expert-level features, clean examples, and real-world workflows that will supercharge your version control skills and team collaboration.

1. Rebase vs Merge – What’s the Difference?

Merge combines histories by creating a new "merge commit."
Rebase rewrites history by moving your branch on top of another.

Example:

# Merge
git checkout feature
git merge main

# Rebase
git checkout feature
git rebase main

Use Rebase for cleaner, linear history.
Use Merge to preserve the actual branch history.

Simple Example:

Imagine you’re building a tower of blocks (main branch).

Merge = You add a new block on top that says "merged feature."
Rebase = You take your blocks and stack them neatly on top of the latest main tower, as if you built them there from the start.

2. Interactive Rebase (`git rebase -i`)

This lets you clean up commits before merging into the main branch.

Example:

git rebase -i HEAD~3

You’ll get:

pick 123abc Add login form
pick 456def Fix typo
pick 789ghi Add validation

Change to:

pick 123abc Add login form
squash 456def Fix typo
squash 789ghi Add validation

It combines multiple commits into one!

Real-Life Example: Blocks and Rebase -i

Imagine you’ve built a small tower of 3 blocks:

Add login form
Fix typo
Add validation

These blocks are your commits.

Now you realize:

"Hmm... all these blocks are part of one feature, the login system. I should combine them into one clean block before adding it to the main tower."

3. Cherry-Picking Specific Commits

git cherry-pick lets you copy a single commit from one branch to another, without merging the entire branch.

Real-Life Example (Building a House):

Imagine you and your friend are building different rooms of a house:

You're working on the kitchen branch
Your friend is working on the living-room branch

One day, your friend adds a beautiful ceiling light in their branch (it's one commit).

You think:

“Hey! That ceiling light would look great in my kitchen too!”

Instead of merging the entire living-room changes (which might include unrelated furniture), you just want that one ceiling light commit.

You Do:

git checkout kitchen
git cherry-pick a1b2c3

Where a1b2c3 is the commit ID for the ceiling light.

Now, that exact change is copied into your kitchen branch!

4. Git Hooks – Automate with Pre-commit and Post-commit

Git lets you run scripts at specific points via hooks. Example: run tests before commit.

Example:

Create a file:

touch .git/hooks/pre-commit

Edit the file and add:

#!/bin/sh
php artisan test

This tells Git: "Before every commit, run the test suite."

Make it executable

chmod +x .git/hooks/pre-commit

Now What Happens?

Every time you run:

Git will:

Run php artisan test
If tests pass → commit goes through
If tests fail → commit is blocked

5. Git Submodules – Managing Dependencies

Sometimes, your project depends on another repository, like a shared library or plugin, that lives in a separate Git repo.

Git submodules let you add that repo into your project while keeping it separate and version-controlled.

Real-Life Example: Building with LEGO Kits

You're building a LEGO castle. But instead of building the horse stable from scratch, you decide to buy a separate LEGO horse kit.

Main castle = your main project (main repo)
Horse stable kit = shared module (external repo)
You place the horse stable inside your castle, but it’s still a separate box you can update or replace anytime.

That’s what a submodule is!

How to Use It

Step 1: Add the submodule

git submodule add https://github.com/example/lib-utils.git libs/utils

Step 2: Initialize and pull submodule

git submodule update --init

This downloads the actual code into your project.

Key Points:

Submodules point to a specific commit of the external repo, not the latest one.
If the original library updates, your project won’t auto-update, you choose when to update it.
It’s still a separate Git repo, inside your repo.

6. Understanding HEAD, Index, and Working Directory

Think of Git as a 3-layer system

Working Directory
Index (Staging Area)
HEAD

1. Working Directory (Your Current Work)

This is where you edit your files.

You’re writing a document in Word or coding in VS Code, this is your working area. The changes are only on your computer for now.

2. Index (Staging Area)

This is where you prepare changes before saving them in history.

You finish writing one section of your report and put it in a "Ready to Print" folder. It’s not printed yet, but it’s ready.

You run:

git add file.txt

Now that file is staged (put into the Index).

3. HEAD (Last Commit – Git History)

This is your latest saved version in Git, the last commit you made.

Your report was printed yesterday, that’s the HEAD version. If someone asks, “What did you last submit?”, you’ll give them the HEAD copy.

View the Differences:

git status

This tells you:

What’s changed but not staged
What’s staged but not committed
What’s already in the HEAD (last commit)

So every time you work with Git, you’re moving files between these 3 layers:

Modify (Working Directory)
Stage with git add (Index)
Save with git commit (HEAD)

Final Thoughts

Next Step:
Missed the basics? Git for Beginners
Or continue from intermediate level: Git Intermediate Guide

Git for Beginners – A Complete Getting Started Guide with Examples

Laravel Daily tips — Wed, 30 Jul 2025 15:32:29 +0000

Whether you're a student, a new developer, or just curious about coding, Git is something you’ll hear about often. This guide is written for absolute beginners. We’ll walk you through the basics of Git, how to install it, set it up, and use it with simple commands and real examples.

1. What is Git and Why Use It?

Git is a version control system (VCS). It helps developers keep track of changes in their code. If something goes wrong, Git allows you to go back to a previous version.

Why use Git?

Track every change in your project
Work with teams easily
Prevent accidental data loss
Collaborate using platforms like GitHub

2. Version Control Basics

There are two main types of version control:

Local VCS: Tracks changes on your computer only
Distributed VCS (like Git): Every developer has a full copy of the project history

With Git, every change is recorded. You can see what was changed, when, and by whom.

3. Installing Git on Windows, macOS, and Linux

Windows:

Download Git from https://git-scm.com/download/win
Run the installer and follow the default steps

macOS:

brew install git

(You need to have Homebrew installed)

Linux (Ubuntu/Debian):

sudo apt update
sudo apt install git

After installation, check if Git is working:

git --version

4. Setting Up Git (username, email)

Before using Git, set your name and email:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

You can verify:

git config --list

5. Creating a Repository (git init)

A repository is like a folder that Git tracks.

mkdir my-project
cd my-project
git init

You now have a Git repository in the my-project folder.

6. Cloning a Repository (git clone)

Cloning means downloading a remote Git project to your computer.

git clone https://github.com/username/repo-name.git

7. Git File Lifecycle: Untracked → Staged → Committed

Git tracks file changes in 3 steps:

Untracked: New files Git doesn’t know about yet
Staged: Files marked to be saved
Committed: Files are saved in Git history

Example flow:

touch index.html                     # untracked
git add index.html                   # staged
git commit -m "Add index file"       # committed

8. Staging Changes (git add)

Use git add to tell Git which files you want to track.

git add file1.html

# To Add all files.
git add .

9. Committing Changes (git commit)

Once staged, commit your changes with a message:

git commit -m "Added homepage layout"

10. Checking Status and History (git status, git log)

To check current changes:

git status

# To see commit history:

git log

You’ll see details like author, date, and message.

11. Basic File Operations (git rm, git mv)

To delete a file from Git and your folder:

git rm unwanted.txt
git commit -m "Remove unwanted file"

To rename or move a file:

git mv oldname.txt newname.txt
git commit -m "Renamed file"

12. Creating Your First .gitignore File

The .gitignore file tells Git which files or folders to skip.

Example .gitignore:

node_modules/
.env
*.log

Create the file in your root directory:

touch .gitignore

13. 🌐 Using Git with GitHub (Basics)

GitHub is a website that stores Git repositories online. Here’s how to push your local code to GitHub:

Step 1: Create a new repository on GitHub

Step 2: Connect local project with GitHub:

git remote add origin https://github.com/yourusername/my-project.git
git branch -M main
git push -u origin main

Conclusion

Now you know the basics of Git, how it works, and how to use it daily. You’ve learned how to:

Set up Git on any system
Create and clone repositories
Track changes using git add and git commit
Work with GitHub

This is just the beginning. In the next blog, we’ll go deeper into branches, merging, and resolving conflicts.

Want more Laravel tips?

Visit LaravelDailyTips for practical guides, interview questions, and tricks.

Subscribe now and get battle-tested Laravel insights delivered to your inbox before anyone else!

Git for Intermediate – Branching, Remotes, Undoing Changes & More

Laravel Daily tips — Wed, 30 Jul 2025 15:14:46 +0000

Once you're familiar with basic Git commands, it's time to explore more practical and real-world usage. Git isn't just about adding and committing files, it's a powerful tool that helps teams collaborate, manage versions, and control the development flow with ease. In this guide, we'll walk you through intermediate Git concepts like branching, working with remotes, handling merge conflicts, undoing mistakes, tagging versions, and even contributing to open-source projects.

Each topic is explained in simple with real examples, so you can confidently apply these skills in day-to-day development. Whether you're working solo or in a team, mastering these intermediate Git commands will level up your workflow, reduce errors, and make your version control cleaner and more professional.

1. Branching in Git – What and Why

What is branching?

Branching lets you create a separate line of development so you can work on new features or fixes without disturbing the main project. It helps teams work on multiple features at once. Each branch is like a safe space to try out ideas. Once done, you can merge it back into the main code.

Think of it like creating a copy of your code to experiment with.

2. Creating and Switching Branches

You can create a branch using git branch branch-name and switch to it using git switch or git checkout. This is helpful when you want to work on something new without changing your main files. Git lets you jump between branches easily. This way, each task can live in its own workspace.

Example:

# Create a new branch
git branch feature-login

# Switch to that branch
git checkout feature-login

# Or use the modern switch command
git switch feature-login

3. Merging Branches

After finishing work in a feature branch, you can merge it into the main branch. Use git merge branch-name to combine changes. If there are no conflicts, Git does this automatically. Merging keeps your main code updated with new features.

# First, switch to main
git switch main

# Then merge your branch
git merge feature-login

4. Merge Conflicts – How to Resolve Them

Merge conflicts happen when Git can’t decide which changes to keep from two branches. You’ll see conflict markers in the file that you need to edit manually. After fixing the content, save the file and commit the changes. This tells Git that the conflict is resolved.

# You’ll see conflict markers like this in the file
<<<<<<< HEAD
code from main
=======
code from feature
>>>>>>> feature-login

How to fix:

Manually edit and keep the correct code.
Remove the conflict markers.
Save and commit.

git add .
git commit -m "Resolved merge conflict"

5. Remote Repositories – Add, Fetch, Push, Pull

Remote repositories are stored online (like on GitHub or GitLab). You can add a remote using git remote add origin <url>, then push or pull code as needed. git push uploads your changes, and git pull brings in updates from others. This is how you collaborate with a team.

Example:

# Add a remote
git remote add origin https://github.com/yourusername/repo.git

# Push your branch
git push origin main

# Pull changes from remote
git pull origin main

# Fetch (download but don’t merge)
git fetch origin

6. Tracking vs Non-Tracking Branches

Tracking branch: A tracking branch knows which remote branch it’s linked to and fetches updates automatically
Non-tracking branch: Non-tracking branches don’t have this link, so you need to push/pull manually.

You can set a tracking branch using the below command. This makes remote work easier.

Example:

# Set upstream (tracking)
git push -u origin feature-login

7. Undoing Changes

Git allows you to undo changes at different stages. If you changed a file but didn’t stage it, use git checkout -- filename to revert. To unstage a file, use git reset filename. You can also undo commits with git reset or update the last commit using git commit --amend.

Undo Unstaged Changes

git checkout -- filename.txt

Undo Staged Changes (but keep file)

git reset filename.txt

Undo Last Commit

# Keep changes in working directory
git reset --soft HEAD~1

# Remove changes too
git reset --hard HEAD~1

# Or amend the last commit
git commit --amend -m "New commit message"

8. Tagging Commits

Tags are like labels used to mark important commits, such as a version release. Use git tag v1.0 to tag a commit. This makes it easy to go back to a specific version later. Tags are useful in deployments and version tracking.

Example:

# Create a tag
git tag v1.0

# Push tag to remote
git push origin v1.0

9. Stashing Work

Stashing temporarily saves your uncommitted work. This is helpful if you need to switch branches quickly but aren’t ready to commit. Use git stash to save, and git stash apply to bring it back later. It’s like putting your work in a drawer for a moment.

# Save your work
git stash

# stash with message
git stash push -m "this is new file"
#OR
git stash save "this is new file"

# See stashes
git stash list

# Apply the last stash
git stash apply
#OR
git stash apply stash@{n}

# OR
git stash pop

#OR
git stash pop stash@{n}

10. Comparing Changes

To see what you’ve changed, use git diff. It shows the difference between files or commits. git log --oneline gives a quick summary of past commits. These tools help you understand your project's history and code changes.

Example:

git diff

# comparison of two commits
git diff commit_one commit_two

#OR
git log --oneline

11. Working with .gitattributes

The .gitattributes file controls how Git handles different file types. You can use it to manage line endings or define merge rules. It helps avoid issues when working across different operating systems. It’s especially useful in team environments.

Example .gitattributes:

*.txt text
*.jpg binary
*.php diff=php

12. Contributing to Remote Projects

To contribute to open-source projects, you usually fork the repo, then clone it to your computer. Make changes in a new branch, push them, and create a pull request. This process is called "fork → clone → pull request." It’s the standard way to suggest improvements to someone else’s project.

git clone https://github.com/yourusername/project.git

Read more: If you're just getting started, check out my Git for Beginners – A Complete Getting Started Guide to learn the basics before diving into these intermediate-level concepts.

Final Thoughts

By now, you’ve covered all the major intermediate Git concepts that developers use every day. Keep practicing with your own or open-source projects. These skills will help you collaborate efficiently and maintain clean project histories.

How to Log into a Custom Log File in Laravel

Laravel Daily tips — Tue, 29 Jul 2025 19:26:25 +0000

Laravel, by default, writes logs into a single laravel.log file in storage/logs. But what if you want to separate your logs, maybe to track a specific module like payments or API calls?

In this guide, you’ll learn how to log to a separate file, followed by advanced tips for better log management in Laravel.

Step 1: Define a New Log Channel

Open config/logging.php and define your custom log channel inside the channels array:

'channels' => [

    // ... other channels

    'custom_payment' => [
        'driver' => 'single',
        'path' => storage_path('logs/payment.log'),
        'level' => 'debug',
    ],
],

This tells Laravel to create a new log file at:
storage/logs/payment.log.

Step 2: Log into the Custom Channel

Now, in your code, use:

use Illuminate\Support\Facades\Log;

Log::channel('custom_payment')->info('Payment process started for order ID: 12345');

That’s it! This will write logs only to payment.log.

Advanced Tips (2025-Level)

1. Use Daily Logs for Rotation

Prevent massive log files with daily log rotation:

'custom_payment' => [
    'driver' => 'daily',
    'path' => storage_path('logs/payment.log'),
    'level' => 'debug',
    'days' => 14, // keep logs for 14 days
],

2. Format Log Output (Customize Log Format)

To make logs more readable or add contextual information:

'custom_payment' => [
    'driver' => 'monolog',
    'handler' => Monolog\Handler\StreamHandler::class,
    'formatter' => Monolog\Formatter\LineFormatter::class,
    'with' => [
        'stream' => storage_path('logs/payment.log'),
    ],
    'formatter_with' => [
        'format' => "[%datetime%] %channel%.%level_name%: %message% %context%\n",
        'dateFormat' => 'Y-m-d H:i:s',
    ],
],

And then log something like:

Log::channel('custom_payment')->info('Payment processed', [
    'order_id' => 98765,
    'user_id' => 123,
]);

The Output in `payment.log` will look like:

[2025-07-29 19:45:32] custom_payment.INFO: Payment processed {"order_id":98765,"user_id":123}

3. Log Based on Environment

Use .env to dynamically set the log channel:

LOG_CHANNEL=custom_payment

In logging.php:

'default' => env('LOG_CHANNEL', 'stack'),

This helps switch between channels in local, staging, or production environments easily.

4. Contextual Logging

Use context data to attach extra info:

Log::channel('custom_payment')->info('Payment completed', [
    'user_id' => auth()->id(),
    'order_id' => 123,
    'amount' => 500,
]);

This is especially useful when debugging API calls or tracing actions.

Bonus: Log Viewer Package

To visually inspect logs in your browser:

composer require opcodesio/log-viewer

Visit /log-viewer in your browser. It supports filtering, searching, and more!

🔗 Log Viewer by opcodesio

Conclusion

Laravel’s logging system is powerful and highly customizable. Whether you’re managing logs per module or setting up advanced Monolog formatting, these techniques will give you clean, organized, and maintainable logs.

Want more Laravel tips?

Visit LaravelDailyTips for practical guides, interview questions, and tricks.

Original Blog Link

Subscribe now and get battle-tested Laravel insights delivered to your inbox before anyone else!

Laravel: Defensive programming strategies in 2025

Laravel Daily tips — Tue, 29 Jul 2025 10:24:30 +0000

1. Always Keep Laravel & Dependencies Updated

The first and most fundamental rule of Laravel security is to always keep your framework and its dependencies updated. Laravel's core team regularly releases security patches and bug fixes. Running outdated versions leaves your application vulnerable to known exploits.

Actionable Tip: Regularly run composer update and use tools like Dependabot or Renovate to automate dependency monitoring and updates.

# Check current Laravel version
php artisan --version

# Update Composer dependencies
composer update

# Update Laravel specifically
composer update laravel/framework

# For major version updates
composer require laravel/framework:^11.0

Automated Security Updates

// composer.json - Configure automatic security updates
{
    "config": {
        "audit": {
            "abandoned": "report"
        }
    },
    "scripts": {
        "security-check": "composer audit"
    }
}

2. Use Environment Variables for Secrets

Your .env file contains sensitive configuration details. Debug mode, when enabled in production, can leak critical information about your application's internals, aiding attackers.

Actionable Tip:

Never commit your .env file to version control.
Ensure APP_ENV=production and APP_DEBUG=false in your production .env file.
Set LOG_LEVEL=error or LOG_LEVEL=critical in production to prevent sensitive data from appearing in logs.

Example (.env file in production):

APP_ENV=production
APP_DEBUG=false
APP_KEY=base64:YOUR_VERY_SECURE_APP_KEY_GENERATED_BY_ARTISAN

LOG_CHANNEL=stack
LOG_LEVEL=error

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=your_production_db
DB_USERNAME=your_production_user
DB_PASSWORD=your_production_password

3. Use CSRF Protection

Laravel 11 introduced significant changes to CSRF protection. Starting from Laravel 11, the VerifyCsrfToken middleware no longer exists within the application's skeleton, requiring a new approach to configuration.

New CSRF Configuration (Laravel 11 & 12)

// bootstrap/app.php
<?php

use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Exceptions;
use Illuminate\Foundation\Configuration\Middleware;

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        commands: __DIR__.'/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        // Configure CSRF token validation
        $middleware->validateCsrfTokens(except: [
            'webhook/*',
            'api/external/*'
        ]);
    })
    ->withExceptions(function (Exceptions $exceptions) {
        //
    })->create();

CSRF Token in Blade Templates

<!-- Blade template -->
<form method="POST" action="/profile">
    @csrf
    <input type="text" name="name" value="{{ old('name') }}">
    <button type="submit">Update Profile</button>
</form>

CSRF for AJAX Requests

// Set up CSRF token for AJAX requests
$.ajaxSetup({
    headers: {
        'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
    }
});

// Or use the XSRF-TOKEN cookie
axios.defaults.xsrfCookieName = 'XSRF-TOKEN';
axios.defaults.xsrfHeaderName = 'X-XSRF-TOKEN';

4. Sanitize Input & Prevent XSS

Never trust user input. This is a golden rule of web security. Unvalidated input can lead to various attacks, including SQL injection and Cross-Site Scripting (XSS). Laravel's powerful validation rules and Blade's automatic escaping are your primary defenses.

Actionable Tip: Validate all incoming request data. Use Blade's {{ $variable }} for output escaping by default. Only use {!! $variable !!} when you are absolutely certain the content is safe (e.g., purified HTML). For user-provided rich text, use a dedicated HTML purifier library.

Code Example (Validation):

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Validation\Rules\Password;

class UserRegistrationRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name' => ['required', 'string', 'max:255', 'regex:/^[a-zA-Z\s]+$/'],
            'email' => ['required', 'email:rfc,dns', 'unique:users,email'],
            'password' => [
                'required',
                'confirmed',
                Password::min(12)
                    ->letters()
                    ->mixedCase()
                    ->numbers()
                    ->symbols()
                    ->uncompromised()
            ],
            'phone' => ['nullable', 'regex:/^\+?[1-9]\d{1,14}$/'],
            'website' => ['nullable', 'url', 'max:255'],
            'age' => ['required', 'integer', 'min:18', 'max:120'],
        ];
    }

    public function messages(): array
    {
        return [
            'name.regex' => 'Name can only contain letters and spaces.',
            'email.email' => 'Please provide a valid email address.',
            'password.uncompromised' => 'The password has been compromised in a data breach.',
        ];
    }

    protected function prepareForValidation(): void
    {
        $this->merge([
            'email' => strtolower(trim($this->email)),
            'name' => trim($this->name),
        ]);
    }
}

5. Use Authorization Policies and Gates

Laravel's built-in authentication system (powered by Laravel Fortify or Jetstream) is incredibly robust and handles many security concerns for you, including password hashing with Bcrypt, session management, and login throttling. For authorization, utilize Gates and Policies to define granular access control.

Actionable Tip: Do not roll your own authentication system unless absolutely necessary. Embrace Fortify or Jetstream for quick and secure scaffolding. Use Policies for resource-specific authorization.

php artisan make:policy PostPolicy --model=Post

// app/Policies/PostPolicy.php
<?php

namespace App\Policies;

use App\Models\User;
use App\Models\Post;

class PostPolicy
{
    /**
     * Determine whether the user can update the post.
     */
    public function update(User $user, Post $post): bool
    {
        return $user->id === $post->user_id;
    }

    /**
     * Determine whether the user can delete the post.
     */
    public function delete(User $user, Post $post): bool
    {
        return $user->id === $post->user_id;
    }
}

use it in a controller:

// app/Http/Controllers/PostController.php
<?php

namespace App\Http\Controllers;

use App\Models\Post;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Gate;

class PostController extends Controller
{
    public function update(Request $request, Post $post)
    {
        if (! Gate::allows('update', $post)) {
            abort(403, 'You are not authorized to update this post.');
        }

        // Update the post...
    }
}

6. Protect Routes with Middleware

Always protect routes with auth or custom middleware.

Route::middleware(['auth:sanctum'])->group(function () {
    Route::get('/dashboard', [DashboardController::class, 'index']);
});

Use Laravel Sanctum or Passport for secure API authentication.

7. Rate Limiting for APIs and Login

Rate limiting is crucial for preventing brute-force attacks on login forms, API endpoints, or any resource that could be abused by repetitive requests.

Actionable Tip: Utilize Laravel's built-in rate limiter middleware.

// routes/web.php or routes/api.php
use Illuminate\Support\Facades\Route;
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;
use Illuminate\Http\Request;

// Define a custom rate limiter (optional, but good for fine-grained control)
RateLimiter::for('login', function (Request $request) {
    return Limit::perMinute(5)->by($request->input('email') ?: $request->ip());
});

// Apply rate limiting to a route group
Route::middleware(['throttle:login'])->group(function () {
    Route::post('/login', [AuthController::class, 'login']);
});

// Or to a single route
Route::get('/api/data', [ApiController::class, 'getData'])->middleware('throttle:60,1'); // 60 requests per minute

8. Use HTTPS & Force Secure Headers

In 2025, there's simply no excuse not to use HTTPS. It encrypts data in transit, protecting against eavesdropping and Man-in-the-Middle (MitM) attacks. Strict-Transport-Security (HSTS) ensures browsers always connect via HTTPS, even if the user tries to access the site via HTTP.

Actionable Tip: Configure your web server (Nginx/Apache) to redirect all HTTP traffic to HTTPS, and force HTTPS within your Laravel application.

Code Example (Force HTTPS in AppServiceProvider):

// app/Providers/AppServiceProvider.php
<?php

namespace App\Providers;

use Illuminate\Support\Facades\URL;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     */
    public function register(): void
    {
        //
    }

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        if ($this->app->environment('production')) {
            URL::forceScheme('https');
        }
    }
}

You should also configure HSTS in your web server. For Nginx, this might look like:

<?php

namespace App\Http\Middleware;

use Closure;

class SecurityHeaders
{
    public function handle($request, Closure $next)
    {
        $response = $next($request);
        $response->headers->set('X-Frame-Options', 'DENY');
        $response->headers->set('X-Content-Type-Options', 'nosniff');
        $response->headers->set('X-XSS-Protection', '1; mode=block');
        $response->headers->set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
        return $response;
    }
}

9. Encrypt Sensitive Data

Use Laravel’s Crypt facade for storing sensitive information.

use Illuminate\Support\Facades\Crypt;

$encrypted = Crypt::encryptString('MySecretData');
$decrypted = Crypt::decryptString($encrypted);

10. Password Hashing and Reset Tokens

Always hash passwords using Laravel's Hash facade.

use Illuminate\Support\Facades\Hash;

$user->password = Hash::make($request->password);

Don’t manually store or generate password reset tokens. Use Laravel's Password broker.

11. File Upload Protection

Validate file uploads and store them securely.

$request->validate([
    'image' => 'required|image|mimes:jpg,jpeg,png|max:2048',
]);

$path = $request->file('image')->store('uploads', 'public');

Avoid exposing original file names and restrict access via signed URLs or controllers.

11. Regular Security Audits and Testing

Security is not a one-time setup; it's an ongoing process. Regularly audit your application's code, configurations, and dependencies.

Actionable Tip:

Conduct regular security penetration testing.
Use static analysis tools (SAST) and dynamic analysis tools (DAST).
Integrate composer audit into your CI/CD pipeline.
Consider using Laravel Pulse for real-time monitoring of application performance and security events (like failed logins).

12. Set Proper Permissions on Server

.env should never be world-readable.
Set correct file permissions:

chmod -R 755 storage bootstrap/cache
chown -R www-data:www-data .

Use fail2ban, UFW, and SSL for server security.

13. Environment Configuration Security

Properly secure your environment configuration and sensitive data.

// .env

# Additional security headers
SECURE_HEADERS=true

Configuration Validation

<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Config;

class SecurityServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        if (app()->environment('production')) {
            $this->validateProductionConfig();
        }
    }

    private function validateProductionConfig(): void
    {
        $requiredConfigs = [
            'app.key' => 'Application key must be set',
            'app.debug' => 'Debug mode must be disabled in production',
            'session.secure' => 'Secure cookies must be enabled',
            'session.http_only' => 'HTTP-only cookies must be enabled',
        ];

        foreach ($requiredConfigs as $config => $message) {
            if ($config === 'app.debug' && Config::get($config) === true) {
                throw new \RuntimeException($message);
            }

            if ($config !== 'app.debug' && !Config::get($config)) {
                throw new \RuntimeException($message);
            }
        }
    }
}

Conclusion

In 2025, securing your Laravel app isn’t optional. it’s a continuous responsibility. From API rate limiting to CSRF protection and HTTPS enforcement, Laravel gives you everything to build secure applications. But you must actively implement these practices.

Want more Laravel tips?

Visit LaravelDailyTips for practical guides, interview questions, and tricks.

Subscribe now and get battle-tested Laravel insights delivered to your inbox before anyone else!

DEV Community: Laravel Daily tips

Laravel 13: Real-Time Notifications using Pusher

Introduction

What Are Real-Time Notifications?

How Laravel Broadcasting Works

Why Laravel Uses Events for Broadcasting

Why Choose Pusher?

Pusher vs Laravel Reverb

What We'll Build

Project Structure and Prerequisites

Step 1: Create a New Laravel Project

Step 2: Install Authentication

Step 3: Prepare the Database

Step 4: Create the Post Model

Step 5: Add the User Relationship

Step 6: Configure Broadcasting

Step 7: Create a Pusher Application

Step 8: Configure Laravel Echo

Project Structure So Far

Step 9: Create the Broadcast Event

Step 10: Define the Application Routes

Step 11: Build the Controller

Why toOthers() Matters

Step 12: Listen for Events with Laravel Echo

Step 13: Build a Reusable Notification Function

What Should the Blade View Contain?

Testing the Complete Workflow

Complete Source Code

Common Broadcasting Problems and Their Solutions

Events Never Reach the Browser

Queue Worker Isn't Running

Laravel Echo Doesn't Connect

Events Fire Twice

Private Channels Return 403 Errors

Performance Considerations

Broadcast Only the Data You Need

Use Queued Broadcasting

Eager Load Relationships

Choose the Right Channel Type

Pusher vs Traditional Polling

Broadcast Events vs Laravel Notifications

Production Best Practices

Frequently Asked Questions

Does Laravel support broadcasting by default?

Should I use Pusher or Laravel Reverb?

Can Livewire receive broadcast events?

Can I broadcast to a single user?

Is queued broadcasting required?

Can I replace Pusher later?

Conclusion

Key Takeaways

12 Must-Know Laravel Tips from July 2025

1. Eloquent Scopes with getTable() for Ambiguous Columns

2. Carbon's is... Methods

3. Response Macros for Consistent APIs

4. in_array_keys Validation Rule

5. isset() with Multiple Parameters

6. Exception Methods for Granular Error Messages

7. The whereBetween() Query Builder Shortcut

8. Str::password() for Secure Passwords

9. Database-Backed Notifications

10. Nested Database Transactions

11. Custom Validation Message Attributes

12. Grouping Tests in Pest with describe

Livewire 4: Faster, Simpler, and More Powerful!

1. Single-File Components (SFC) Are the New Default

What Changed?

Why It’s Awesome:

Real-Life Example:

2. Multi-File Components (MFC) When You Need More Structure

What Changed?

Why It’s Awesome:

Real-Life Example:

3. Livewire::visit(): Browser Testing Like a Human

What Changed?

Why It’s Awesome:

Real-Life Example:

4. ⚡Blaze – Supercharged Rendering Performance

What Changed?

Why It’s Awesome:

Why `toOthers()` Matters

1. Eloquent Scopes with `getTable()` for Ambiguous Columns

2. Carbon's `is...` Methods

4. `in_array_keys` Validation Rule

5. `isset()` with Multiple Parameters

7. The `whereBetween()` Query Builder Shortcut

8. `Str::password()` for Secure Passwords

12. Grouping Tests in Pest with `describe`

Benefits of `softDeletableResources()`:

5. What is the difference between `git pull` and `git fetch`?

6. What is the difference between `git merge` and `git rebase`?

7. Explain the difference between `git reset` and `git revert`.

8. What is the use of `.gitignore` file?

11. What’s the difference between `git checkout` and `git switch`?

12. When would you use `git stash pop` vs `git stash apply`?

1. Recovering with Reflog (`git reflog`)

What is `git reflog`?

That’s where `git reflog` comes in!

When to Use `git reflog`

10. Cleaning Up with `git clean`, `git gc`

1. `git clean` – Remove Untracked Junk

2. `git gc` – Optimize Your Repository

11. Exploring the `.git` Folder – The Brain of Your Git Repo

What is `.git`?