DEV Community: Mahmoud Ramadan

Breaking Multiple Loops in PHP 🔁

Mahmoud Ramadan — Thu, 19 Feb 2026 19:00:53 +0000

In PHP, you are probably familiar with the break keyword, which is used to stop a loop.

What many developers don’t realize is that it break can accept a numeric argument. This number tells PHP how many nested loop levels should be terminated.

Consider the following example:

foreach ($firstLoop as $firstItem) {
    foreach ($secondLoop as $secondItem) {
        foreach ($thirdLoop as $thirdItem) {
            if ($this->shouldStop($thirdItem)) {
                break 2; // Exit third and second loops
            }
        }
    }
}

What does break 2; do?

break 1; (or simply break;) stops only the current (innermost) loop.
break 2; stops two nested loops.
break 3; would stop three nested loops, and so on.

In this example, break 2; exits:

The third loop (innermost)
The second loop

Execution then continues in the first loop.

This is especially useful when working with deeply nested loops, and you need to escape multiple levels once a condition is met.

🔥 Find more real-world coding tips:

Using Custom Timestamp Columns in Laravel Eloquent

Mahmoud Ramadan — Fri, 19 Dec 2025 15:58:22 +0000

If you need to customize the column names for created_at and updated_at, you can do so at the database level.

/**
 * Run the migrations.
 */
public function up(): void
{
    Schema::create('items', function (Blueprint $table) {
        $table->id();
        $table->string('title');
        // Custom timestamp columns
        $table->timestamp('created_on')->nullable();
        $table->timestamp('updated_on')->nullable();
    });
}

After creating the table, attempting to create a new Item model will result in an exception because Eloquent expects the default created_at and updated_at columns.

Behind the scenes, when using the create method to insert a new record, it internally calls the performInsert method. This method also invokes updateTimestamps, which accesses the created_at and updated_at timestamp columns that must exist.

You can resolve this in one of the following ways.

Option 1: Disable timestamps entirely

use Illuminate\Database\Eloquent\Model;

class Item extends Model
{
    /**
     * Indicates if the model should be timestamped.
     *
     * @var bool
     */
    public $timestamps = false;
}

Option 2: Define custom timestamp column names (recommended)

use Illuminate\Database\Eloquent\Model;

class Item extends Model
{
    /**
     * The name of the "created at" column.
     *
     * @var string|null
     */
    public const CREATED_AT = 'created_on';

    /**
     * The name of the "updated at" column.
     *
     * @var string|null
     */
    public const UPDATED_AT = 'updated_on';
}

Learn more in the documentation.

🔬Discover more practical insights on:
https://github.com/digging-code-blog/community-tips

Two Overlooked Laravel Features: `fresh()` and Attribute Visibility

Mahmoud Ramadan — Sat, 13 Dec 2025 11:32:58 +0000

🔁 Reloading Models with `fresh()`

Laravel's fresh method allows you to reload a model or an entire collection from the database, ensuring you are working with the most up-to-date data.

You can also pass relationship names to fresh, and they will be reloaded alongside the model.

use App\Models\User;

$users = User::has('comments', 1)->with('comments')->get();

// Modify the first comment locally (not persisted)
$users->first()->comments->first()->body = 'Updated body';

// Reload users and their comments from the database
$users = $users->fresh('comments');

👀 Controlling Serialization with `visible` and `hidden`

Laravel provides the visible and hidden properties to control which attributes appear when a model is converted to an array or JSON.

What's less commonly known is that these properties also accept relationship names, allowing you to explicitly show or hide relationships during serialization.

use Illuminate\Foundation\Auth\User as Authenticatable;

class User extends Authenticatable
{
    /**
     * The attributes that should be visible in arrays.
     *
     * @var array
     */
    protected $visible = [
        'name',
        'email',
        'created_at',
        'comments', // one-to-many relationship
    ];
}

🚀 Dive into more tips and help others learn:
https://github.com/digging-code-blog/community-tips

💡 Two Lesser-Known Laravel Tricks: numerify & invisible

Mahmoud Ramadan — Thu, 11 Dec 2025 22:18:06 +0000

Laravel is full of hidden gems that can make your development smoother. Today, I want to highlight two handy features you might not know about:

1️⃣ `numerify` in Eloquent Factories

The numerify method from Faker lets you replace # characters with random digits.

public function definition(): array
{
    return [
        'phone' => $this->faker->numerify('+##'), // Example output: +20
    ];
}

2️⃣ `invisible` in Migrations

The invisible column modifier hides a column from default SELECT queries while keeping it in the database.

Note: This feature is supported only by the MySQL database engine.

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;

Schema::create('users', function (Blueprint $table) {
    $table->timestamp('email_verified_at')
          ->nullable()
          ->invisible();
});

🚀 Find more tips and share your knowledge here:
https://github.com/digging-code-blog/community-tips

Rehashing Passwords on Login

Mahmoud Ramadan — Sat, 19 Jul 2025 07:24:03 +0000

I encountered a strange scenario while adding a feature to the Admin Dashboard.

The problem was that I had a mutator method in my model for hashing the password:

use Illuminate\Support\Facades\Hash;

/**
 * Set the model password attribute.
 */
public function setPasswordAttribute($value): void
{
    if (!empty($value)) {
        $this->attributes['password'] = Hash::make($value);
    }
}

Later, while logging into the admin dashboard using a simple password (since it was on the local stage), I discovered something odd: the password was being updated after I logged in. This happened because the input password was passed through the mutator again, causing it to be re-hashed.

To test further, I manually hashed a strong password using Tinker and attempted to log in again. Surprisingly, this time the request didn't go through the mutator.

I then looked into how the attempt method works, which in turn uses the rehashPasswordIfRequired method, which internally relies on the needsRehash method. That method checks if the given password hash needs to be rehashed, depending on the hashing value, the used algorithm, and other options.

The rehashPasswordIfRequired and needsRehash methods have been available since Laravel v11.

The mutator was hashing passwords in multiple places, which makes it difficult to track. Removing the mutator would require manually hashing passwords wherever they're set.

Then I discovered the isHashed method, which checks whether a value has already been hashed. It helped me avoid rehashing values that Laravel had already processed internally:

/**
 * Set the model password attribute.
 */
public function setPasswordAttribute($value): void
{
    if (!empty($value) && !Hash::isHashed($value)) {
        $this->attributes['password'] = Hash::make($value);
    }
}

Alternatively, you can use the hashed cast:

class User extends Authenticatable
{
    /**
     * The attributes that should be cast.
     *
     * @var array
     */
    protected $casts = [
        'password' => 'hashed',
    ];
}

The hashed cast was introduced in Laravel v10.

Enhancing Blade with Custom Directives

Mahmoud Ramadan — Wed, 02 Jul 2025 19:30:28 +0000

If you're using the same condition repeatedly in Blade, especially if it's complex, you likely won't want to repeat it multiple times. To avoid this, Laravel provides a neat way to define your condition once in the AppServiceProvider class:

use Illuminate\Support\Facades\Blade;

/**
* Bootstrap any application services.
*/
public function boot(): void
{
    Blade::if('isGuest', function () {
        return auth()->guest();
    });
}

Then, you can easily use it like this:

@isGuest
    <p>You are a guest</p>
@endisGuest

In addition, you can define a custom Blade directive like this:

/**
* Bootstrap any application services.
*/
public function boot(): void
{
    Blade::if('isAuth', function () {
        return auth()->check();
    });

    Blade::directive('welcomeUser', fn($name) => "Welcome $name");
}

Once defined, you can use these custom directives in your Blade templates like this:

@isAuth

@welcomeUser(auth()->user()->name)

@endisAuth

Looping Through Data in Blade

Mahmoud Ramadan — Wed, 02 Jul 2025 19:28:25 +0000

Laravel Blade offers several clean and expressive ways to loop through data.

1. Basic Loop with @foreach

The most common way to iterate over a collection is using the @foreach directive:

<table class="table">
    @foreach ($posts as $post)
        <tr>
            <td>{{ $post->title }}</td>
            <td>{{ $post->body }}</td>
        </tr>
    @endforeach
</table>

You can control loop execution using the @break and @continue directives:

<table class="table">
    @foreach ($posts as $post)

        @if ($post->user->is_blocked)
            @break
        @endif

        @if ($post->user_id == user()->id())
            @continue
        @endif

        <tr>
            <td>{{ $post->title }}</td>
            <td>{{ $post->body }}</td>
        </tr>
    @endforeach
</table>

Laravel also provides a more concise version of @break and @continue by passing the condition directly:

<table class="table">
    @foreach ($posts as $post)

    @break($post->user->is_blocked)

    @continue($post->user_id == user()->id())

    ...

    @endforeach
</table>

2. Handling Empty Collections with @forelse

If you want to display a fallback message when the collection is empty, use the @forelse directive:

<table class="table">
    @forelse ($posts as $post)
        <tr>
            <td>{{ $post->title }}</td>
            <td>{{ $post->body }}</td>
        </tr>
    @empty
        <tr>
            <td colspan="2">No posts found</td>
        </tr>
    @endforelse
</table>

Alternatively, you can use the @each directive, which provides a more concise way to loop through data and render rows. It accepts four parameters:

1. View: The view file that contains the HTML for a single row.
2. Variable: The name of the variable for each item in the loop.
3. Data: The collection or array of data to loop through.
4. Empty View: The view that will be displayed if the data is empty.

@each('posts.row', $posts, 'post', 'posts.empty')

Laravel provides a way to gain more control over your iterations using the $loop variable.

Injecting Services in Blade Templates

Mahmoud Ramadan — Thu, 26 Jun 2025 19:20:51 +0000

In certain rare scenarios, you should create an instance of a class and call its methods directly within a Blade view, rather than from a controller. For these cases, Laravel provides the convenient @inject directive:

@inject('metrics', 'App\Services\MetricsService')

<div>
    Monthly Revenue: {{ $metrics->monthlyRevenue() }}.
</div>

Tweak Laravel Routes to Fit Your Needs

Mahmoud Ramadan — Thu, 26 Jun 2025 19:18:33 +0000

Laravel offers flexible methods for handling route model binding. You can bind models dynamically by assigning a variable to a model, and also customize this behavior using the model method:

use App\Models\User;
use Illuminate\Support\Facades\Route;

/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    Route::model('user', User::class);
}

By default, Laravel uses the findOrFail method to resolve route parameters. However, you can customize this behavior using the bind method to look up a model using alternative logic:

use App\Models\User;
use Illuminate\Support\Facades\Route;

/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    Route::bind('user', function (string $value) {
        return User::where('name', $value)->firstOrFail();
    });
}

Finally, when working with resourceful routes, Laravel offers a convenient shorthand for defining the typical seven resource routes. You can also customize the route URIs using the resourceVerbs method:

use Illuminate\Support\Facades\Route;

/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    Route::resourceVerbs([
        'create' => 'crear',
        'edit'   => 'editar',
    ]);
}

Using User Locale for Notifications

Mahmoud Ramadan — Wed, 18 Jun 2025 20:41:38 +0000

It is considered best practice to send notifications and emails in the recipient's preferred locale. Laravel supports this out of the box through the HasLocalePreference contract, which enables you to easily define a user's locale preference:

use Illuminate\Contracts\Translation\HasLocalePreference;

class User extends Model implements HasLocalePreference
{
    /**
     * Get the user's preferred locale.
     */
    public function preferredLocale(): string
    {
        return $this->locale;
    }
}

Once you implement the HasLocalePreference contract, Laravel will automatically use the preferred locale returned by the preferredLocale method when sending notifications and emails.

Clone Eloquent Models Selectively

Mahmoud Ramadan — Wed, 18 Jun 2025 20:36:12 +0000

Sometimes, you may need to duplicate a model instance and create a new one with some custom changes. Instead, you can use Laravel's built-in replicate method:

use App\Models\Address;

$shipping = Address::create([
    'type'     => 'shipping',
    'line_1'   => '123 Example Street',
    'city'     => 'Victorville',
    'state'    => 'CA',
    'postcode' => '90001',
]);

// Create a replicated instance of the address without saving it
$replicatedAddresss = $shipping->replicate();

The previous code creates a new address instance but does not save it to the database. Before saving, you can modify any attributes as needed:

...

$replicatedAddresss->type = 'billing';

// Save the replicated instance to the database
$replicatedAddresss->save();

Alternatively, you can replace the previous line where the property is assigned with the fill method:

...

$replicatedAddresss = $shipping->replicate();

$replicatedAddresss->fill(['type' => 'billing'])->save();

On top of that, you can exclude specific attributes from being replicated by passing them as an array to the replicate method:

$shipping = Address::create([
    'type'     => 'shipping',
    'line_1'   => '123 Example Street',
    'city'     => 'Victorville',
    'state'    => 'CA',
    'postcode' => '90001',
]);

$shipping->replicate([
    'line_1',
    'state'
]);

Handling Validation Errors for Multiple Forms

Mahmoud Ramadan — Thu, 12 Jun 2025 20:58:01 +0000

When dealing with multiple forms on a single page, especially when the forms contain duplicate input names, Laravel’s default validation approach can cause issues. By default, validation errors are tied to the input fields, meaning the error messages are displayed across all forms, not just the one that was submitted. This can be confusing for users.

To resolve this, we can use Named Error Bags, which allow us to store and display validation errors for specific forms separately.

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Validator;

public function store(Request $request)
{
    $validation = Validator::make($request->all(), [
        'name'  => 'required|min:25',
        'email' => 'required|unique:users,email,NULL,id,deleted_at,NULL',
    ])->validateWithBag('user');

    return redirect()->withErrors($validation);
}

Alternatively, you can use the following version of the code:

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Validator;

public function store(Request $request)
{
    $validation = Validator::make($request->all(), [
        // ...
    ]);

    return redirect()->withErrors($validation, 'user');
}

Another option is to use the Form Request class easily:

use Illuminate\Foundation\Http\FormRequest;

class StoreRequest extends FormRequest
{
    /**
     * The key to be used for the view error bag.
     *
     * @var string
     */
    protected $errorBag = 'user';

    /**
     * Get the validation rules that apply to the request.
     */
    public function rules(): array
    {
        return [
            //
        ];
    }
}

public function store(StoreRequest $request)
{
    // Perform actions...

    return redirect()->back();
}

Then, to present the validation errors in the blade, you can use one of these approaches:

<form action="{{ route('users.store') }}" method="POST">
    @csrf
    <div class="form-group">
        <label for="name">Name</label>
        <input type="text" class="form-control" id="name" name="name" required>
        {{-- First approach --}}
        @error('name', 'user')
        <p class="text-danger mt-2">{{ $message }}</p>
        @enderror
        {{-- Second approach --}}
        {{-- <p class="text-danger mt-2">{{ $errors->user->first('name') }}</p> --}}
    </div>
    ...
</form>