DEV Community: Vincent Tommi

Django vs Laravel: Understanding Models and Database Migrations

Vincent Tommi — Thu, 24 Sep 2026 08:20:01 +0000

As I started working more seriously with Laravel after spending a significant amount of time working with Django, I noticed an important difference in how the two frameworks approach database schema management.

Coming from Django, I was used to a workflow like:

python manage.py makemigrations
python manage.py migrate

In Django, I normally start by creating or modifying a model. Django then detects the changes and generates migration files for me.

When I started working with Laravel, I initially expected a similar workflow.

However, Laravel made me think about database migrations differently.

The biggest lesson I have learned is this:

Django models and Laravel migrations play different roles in the database development workflow.

Let's compare them.

1. The Django Approach

In Django, we normally define our database structure using models.

For example:

from django.db import models


class MenuItem(models.Model):
    name = models.CharField(max_length=255)
    code = models.CharField(max_length=100, unique=True)
    price = models.DecimalField(max_digits=15, decimal_places=2)
    is_active = models.BooleanField(default=True)

    def __str__(self):
        return self.name

After creating or modifying the model, we run:

python manage.py makemigrations

Django examines the changes to the models and generates a migration file.

Then we apply the migration:

python manage.py migrate

So the typical Django workflow is:

Modify Model
     ↓
makemigrations
     ↓
Migration File Generated
     ↓
migrate
     ↓
Database Updated

This means Django provides a strong relationship between the model definition and the generated migration.

2. The Laravel Approach

Laravel uses Eloquent as its ORM, but database schema management is handled explicitly through migrations.

For example, suppose I want to create a menu_items table.

I can create a migration:

php artisan make:migration create_menu_items_table

Laravel generates a migration file in:

database/migrations/

I can then define the table:

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

    $table->string('name');
    $table->string('code')->unique();
    $table->decimal('price', 15, 2)->default(0);
    $table->boolean('is_active')->default(true);

    $table->timestamps();
});

Then I run:

php artisan migrate

Laravel executes the migration and creates the table in the database.

The workflow is therefore more like:

Create/Edit Migration
        ↓
Define Database Schema
        ↓
php artisan migrate
        ↓
Database Updated

3. Where Does the Laravel Model Come In?

This was one of the things that initially confused me coming from Django.

In Laravel, I can create a model using:

php artisan make:model MenuItem

This creates something like:

app/Models/MenuItem.php

The model can contain:

class MenuItem extends Model
{
    protected $fillable = [
        'name',
        'code',
        'price',
        'is_active',
    ];

    protected $casts = [
        'price' => 'decimal:2',
        'is_active' => 'boolean',
    ];
}

The model is used by Eloquent to interact with the database.

For example:

$menuItem = MenuItem::create([
    'name' => 'Chicken Burger',
    'code' => 'BURGER-001',
    'price' => 750,
    'is_active' => true,
]);

The important distinction is that this model does not automatically generate or modify the database schema when I change its properties.

The migration is responsible for defining the database structure.

4. Laravel Can Create Both at Once

Laravel also provides a convenient command for creating a model and its migration together:

php artisan make:model MenuItem -m

This creates:

app/Models/MenuItem.php

and a migration under:

database/migrations/

This is a useful workflow because I can create the model and migration at the same time.

However, they still have different responsibilities.

Model

The model defines how my application interacts with the data.

Migration

The migration defines how the database structure is created or changed.

5. Django vs Laravel: The Key Difference

This is where my initial understanding needed some correction.

It is not quite accurate to say:

"In Laravel you create the migration first, while in Django you create the model first."

Both frameworks allow different workflows.

The more accurate distinction is:

Django's migration system is largely model-driven, while Laravel's migration system is explicitly migration-driven.

In Django:

models.py
    ↓
makemigrations
    ↓
migrations/
    ↓
migrate
    ↓
Database

In Laravel:

Migration
    ↓
php artisan migrate
    ↓
Database

Model
    ↓
Eloquent
    ↓
Application ↔ Database

The Laravel model and migration work together, but changing the model does not automatically generate a migration.

6. Example: Adding a Column

Let's say I already have a menu_items table and want to add an image column.

Django

I would modify the model:

class MenuItem(models.Model):
    name = models.CharField(max_length=255)
    image = models.ImageField(upload_to='menu/', null=True, blank=True)

Then:

python manage.py makemigrations
python manage.py migrate

Django detects that image was added and creates the appropriate migration.

Laravel

In Laravel, I would create a new migration:

php artisan make:migration add_image_to_menu_items_table

Then define the change:

Schema::table('menu_items', function (Blueprint $table) {
    $table->string('image')->nullable();
});

Then:

php artisan migrate

The database is updated.

If I want to access the new field through my Laravel model, I may also update $fillable if I am using mass assignment:

protected $fillable = [
    'name',
    'code',
    'price',
    'image',
    'is_active',
];

This demonstrates the difference clearly.

7. Another Important Difference: Migration Detection

This is probably the biggest difference I noticed while moving between Django and Laravel.

With Django, I can make a change to:

models.py

and then run:

python manage.py makemigrations

Django compares the current models against the previous migration state and generates a migration.

With Laravel, if I change something in my model, Laravel does not automatically create a migration for that database change.

For example, changing:

protected $fillable = [
    'name',
    'price',
];

does not change the database.

Likewise, adding a property or changing model configuration does not automatically alter the table.

I need to create a migration when the database schema itself needs to change.

8. Relationships Are Also Different

Both Django and Laravel provide excellent support for database relationships, but the syntax is different.

For example, suppose a MenuItem belongs to a MenuCategory.

Django

I might write:

class MenuItem(models.Model):
    menu_category = models.ForeignKey(
        MenuCategory,
        on_delete=models.CASCADE,
        related_name='menu_items'
    )

Django then uses this relationship to provide database and ORM behavior.

Laravel

The migration defines the foreign key:

$table->foreignId('menu_category_id')
    ->constrained('menu_categories')
    ->cascadeOnDelete();

Then the model defines the Eloquent relationship:

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

And the reverse relationship can be defined in MenuCategory:

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

This separation helped me understand Laravel better:

Migration
    ↓
Database structure

Model
    ↓
Application behavior + relationships

9. The Commands Side by Side

Here is a simple comparison.

Task	Django	Laravel
Create model	Define model in `models.py`	`php artisan make:model MenuItem`
Create migration	Usually generated	`php artisan make:migration ...`
Generate migration from model changes	`makemigrations`	No direct equivalent
Apply migrations	`python manage.py migrate`	`php artisan migrate`
Roll back migration	`python manage.py migrate app previous_migration`	`php artisan migrate:rollback`
Create model + migration	Define model, then `makemigrations`	`php artisan make:model MenuItem -m`
ORM	Django ORM	Eloquent ORM

10. My Laravel Workflow

After learning this difference, the Laravel workflow I am following for my POS project is becoming clearer.

For example, when creating an ingredient table:

Step 1: Create the migration

php artisan make:migration create_ingredients_table

Step 2: Define the database structure

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

    $table->foreignId('base_unit_id')
        ->constrained('units')
        ->restrictOnDelete();

    $table->decimal('cost', 15, 2)->default(0);
    $table->decimal('reorder_level', 15, 3)->default(0);

    $table->timestamps();
});

Step 3: Run the migration

php artisan migrate

Step 4: Create the model

php artisan make:model Ingredient

Step 5: Configure the model

class Ingredient extends Model
{
    protected $fillable = [
        'name',
        'base_unit_id',
        'cost',
        'reorder_level',
    ];

    protected $casts = [
        'cost' => 'decimal:2',
        'reorder_level' => 'decimal:3',
    ];
}

Step 6: Add relationships

public function baseUnit(): BelongsTo
{
    return $this->belongsTo(Unit::class, 'base_unit_id');
}

Now the migration handles the database structure while the model handles Eloquent interaction.

11. What I Have Learned Moving from Django to Laravel

Coming from Django, my first instinct was to think:

Model → makemigrations → migrate

Laravel made me think more explicitly about:

Migration → Database
Model → Application/ORM

Neither approach is simply "better." They are different design philosophies and workflows.

Django gives developers a very convenient model-driven migration workflow where changes to models can be detected and converted into migrations.

Laravel gives developers explicit control over database schema changes through migration files while Eloquent models focus on interacting with that schema.

Understanding this difference has made Laravel migrations much easier for me to work with.

Conclusion

Moving from Django to Laravel is not just about learning different syntax.

It also means learning how each framework expects you to think about application architecture.

The most important distinction I have learned is:

In Django, models are the primary definition of your database structure, and migrations are generated from model changes. In Laravel, migrations explicitly define and change the database schema, while Eloquent models provide the application's interface to that database.

Once I understood this, Laravel's workflow started making much more sense.

For someone moving from Django to Laravel, I would recommend not trying to force the Django workflow into Laravel.

Instead, understand the responsibility of each component:

Django

Model
  ↓
makemigrations
  ↓
Migration
  ↓
Database

versus:

Laravel

Migration
  ↓
Database
  ↑
Eloquent Model
  ↑
Application

Learning this distinction has been one of the useful lessons in my transition from Django to Laravel.

How to Fix the Ondřej PHP PPA 404 Error on Ubuntu

Vincent Tommi — Tue, 22 Sep 2026 02:12:08 +0000

How to Fix the Ondřej PHP PPA 404 Error on Ubuntu

If you are using Ubuntu and run:

sudo apt update

you may sometimes encounter an error similar to this:

Ign:1 https://ppa.launchpadcontent.net/ondrej/php/ubuntu resolute InRelease

Err:2 https://ppa.launchpadcontent.net/ondrej/php/ubuntu resolute Release
  404 Not Found

Error: The repository 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu resolute Release'
does not have a Release file.

This article explains why this happens and how to fix it safely.

Understanding the Error

The problem is caused by the Ondřej PHP PPA being configured for an Ubuntu release that it does not currently support.

In this case, the system is using:

resolute

APT tries to access:

https://ppa.launchpadcontent.net/ondrej/php/ubuntu/resolute

but the repository does not contain a Release file for resolute.

As a result, Ubuntu disables the repository because it cannot securely verify and retrieve packages from it.

Step 1: Check Your Ubuntu Version

First, confirm the Ubuntu release you're running:

lsb_release -a

You can also run:

cat /etc/os-release

Look for the release codename.

For example:

VERSION_CODENAME=resolute

This confirms that your system is using Ubuntu resolute.

Step 2: Check the Ondřej PHP Repository

List the repository configuration files:

ls /etc/apt/sources.list.d/

You may see something similar to:

ondrej-ubuntu-php-resolute.sources

This file is responsible for the broken PHP PPA configuration.

Step 3: Remove the Unsupported Repository

If you don't need the repository, remove it with:

sudo rm /etc/apt/sources.list.d/ondrej-ubuntu-php-resolute.sources

This does not uninstall PHP.

It only removes the repository from which APT was trying to download packages.

Step 4: Run `apt update` Again

Now run:

sudo apt update

The previous error should be gone.

You should see output similar to:

Hit:1 http://security.ubuntu.com/ubuntu resolute-security InRelease
Hit:2 http://ke.archive.ubuntu.com/ubuntu resolute InRelease
Hit:3 http://ke.archive.ubuntu.com/ubuntu resolute-updates InRelease
Hit:4 http://ke.archive.ubuntu.com/ubuntu resolute-backports InRelease

Reading package lists... Done

Step 5: Check for Other Ondřej PHP Entries

It's a good idea to make sure there aren't other configuration files pointing to the same unsupported repository.

Run:

grep -R "ondrej/php" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

If nothing is returned, there are no remaining Ondřej PHP repository entries.

Does Removing the Repository Remove PHP?

No.

Removing the repository does not remove your existing PHP installation.

You can verify your PHP version with:

php -v

For example:

PHP 8.5.x (cli)

Your installed PHP continues to work normally.

The only difference is that APT will no longer attempt to download packages from the unsupported Ondřej repository.

Check Available PHP Packages

You can also check which PHP version Ubuntu currently provides:

apt policy php

This is useful before installing or upgrading PHP packages.

Why You Shouldn't Ignore the Error

You might be tempted to leave the repository configured and ignore the 404 error.

That's not recommended.

APT is explicitly telling you:

does not have a Release file

and:

Updating from such a repository can't be done securely,
and is therefore disabled by default.

Leaving broken repositories in your configuration can cause unnecessary errors whenever you run:

sudo apt update

It is better to remove or correct the repository configuration.

Conclusion

The 404 Not Found error from the Ondřej PHP PPA occurs because the configured Ubuntu release does not have a corresponding repository on that PPA.

The simplest solution is:

sudo rm /etc/apt/sources.list.d/ondrej-ubuntu-php-resolute.sources
sudo apt update

Then verify:

php -v

Remember that removing the repository does not uninstall PHP. It simply stops APT from trying to use an unsupported package source.

If you are developing Laravel applications and need a specific PHP version such as PHP 8.3, 8.4, or 8.5, make sure the PHP version you choose is compatible with your Laravel and Composer dependencies before changing your system PHP installation.

Fixing Laravel PHP 8.5 Deprecation Warnings: A Practical Dependency Debugging Guide

Vincent Tommi — Fri, 18 Sep 2026 03:12:06 +0000

Upgrading PHP can expose compatibility problems in older Laravel projects. I recently encountered this while running a Laravel 10 application on PHP 8.5.4.

The application was working, but the terminal was filled with deprecation warnings such as:

PHP Deprecated: Monolog\Logger::addRecord():
Implicitly marking parameter $datetime as nullable is deprecated

and:

PHP Deprecated: Illuminate\Log\Logger::__construct():
Implicitly marking parameter $dispatcher as nullable is deprecated

At first, these errors looked like application-level problems. However, the real issue was an outdated dependency stack.

This article explains how I diagnosed and fixed the problem.

The Environment

The project was a Laravel application called samupos.

The initial environment was:

PHP 8.5.4
Laravel 10.25.1
Monolog 3.4.0
HTMLPurifier 4.16.0

The project had originally been built around an older PHP/Laravel ecosystem.

The first important lesson was:

A project can satisfy the PHP version declared in composer.json while still having dependencies that are incompatible with the actual PHP version installed on your machine.

The Initial Error

When starting the Laravel development server, I received:

PHP Deprecated: Illuminate\Log\Logger::__construct():
Implicitly marking parameter $dispatcher as nullable is deprecated,
the explicit nullable type must be used instead

The warning pointed to:

vendor/laravel/framework/src/Illuminate/Log/Logger.php

I also encountered a similar warning from Monolog:

PHP Deprecated: Monolog\Logger::addRecord():
Implicitly marking parameter $datetime as nullable is deprecated,
the explicit nullable type must be used instead

The important thing here is that both warnings originated from the vendor directory.

That immediately suggested a dependency compatibility problem.

Check the PHP Version

The first thing to verify was the PHP version:

php -v

The result was:

PHP 8.5.4 (cli)

This was important because newer PHP releases introduce deprecations that older frameworks and packages may not have accounted for.

Make Sure Composer Is Running in the Correct Directory

Initially, Composer reported:

Composer could not find a composer.json file

The reason was simple: Composer was being executed from:

~/Desktop/Development

instead of the Laravel project directory.

The project was actually located at:

~/Desktop/Development/samupos

So I changed into the project directory:

cd ~/Desktop/Development/samupos

Then verified the project files:

A Laravel project should contain files such as:

artisan
composer.json
composer.lock
app/
bootstrap/
config/
public/
resources/
routes/
vendor/

This is an easy mistake to make, but it is important because Composer searches for composer.json in the current working directory.

Check the Laravel Version

Next, I checked the installed Laravel version:

composer show laravel/framework | head -15

The result showed:

versions : * v10.25.1

So the project was running Laravel 10.25.1.

Check the Monolog Version

composer show monolog/monolog | head -15

The result was:

versions : * 3.4.0

This was another important clue.

The project was using an older Monolog release while running on PHP 8.5.

Check Platform Requirements

Composer provides a useful command for detecting PHP and extension compatibility problems:

composer check-platform-reqs

Most requirements passed, but PHP itself failed because of an outdated package:

ezyang/htmlpurifier requires php
...
< 8.3.0

This meant that although the project's composer.json allowed PHP 8.5:

"php": "^8.1"

one of the installed dependencies did not support PHP 8.5.

This is a critical distinction.

The root project requirement said:

PHP >= 8.1 < 9.0

but individual packages can have much stricter requirements.

Find Out Who Requires HTMLPurifier

Instead of guessing, I used Composer to find out which package depended on HTMLPurifier:

composer why ezyang/htmlpurifier

The result was:

phpoffice/phpspreadsheet 1.29.0 requires ezyang/htmlpurifier (^4.15)

So the dependency chain was:

PhpSpreadsheet
↓
HTMLPurifier
↓
PHP version restriction

This showed that HTMLPurifier was not a package I had directly installed. It was an indirect dependency.

Inspect the Installed HTMLPurifier Version

I then checked:

composer show ezyang/htmlpurifier

The installed version was:

v4.16.0

Its PHP requirements included:

~8.0.0 || ~8.1.0 || ~8.2.0

Therefore PHP 8.5 was outside its declared supported range.

Find All Packages Blocking PHP 8.5

Composer has another extremely useful command:

composer why-not php 8.5

The result identified several blockers:

ezyang/htmlpurifier v4.16.0
nette/schema v1.2.4
nette/utils v4.0.2

For example:

ezyang/htmlpurifier v4.16.0 requires PHP ... < 8.3

and:

nette/utils v4.0.2 requires PHP >=8.0 <8.4

This gave us a much clearer picture of the dependency problem.

Don't Immediately Upgrade Laravel

At this point, it would have been tempting to upgrade the entire application from Laravel 10 to a newer major version.

However, that wasn't necessary yet.

The project was already using:

Laravel 10

and its composer.json contained:

"laravel/framework": "^10.23"

The ^10.23 constraint allows Composer to install newer Laravel 10 releases.

Therefore, before performing a major Laravel upgrade, I checked what Composer could already resolve.

Use Composer's Dry Run

This was one of the most useful steps:

composer update --dry-run

The command doesn't actually modify the project. Instead, it shows what Composer would update.

The output showed that Composer could update Laravel from:

10.25.1

to:

10.50.3

It could also update:

HTMLPurifier 4.16.0 → 4.19.1
PhpSpreadsheet 1.29.0 → 1.30.0
Symfony 6.3.x → 6.4.x
Nette Utils 4.0.2 → 4.1.5
Nette Schema 1.2.4 → 1.3.6

There were also many other dependency updates.

This was exactly what we wanted to see.

It meant the existing Laravel 10 project could move forward without immediately performing a major framework migration.

Back Up Composer Files

Before making the real changes, I backed up the dependency configuration:

cp composer.json composer.json.backup
cp composer.lock composer.lock.backup

This is a simple but useful precaution when performing a large dependency update.

Update Dependencies

The actual update was performed with:

composer update -W

The -W option means:

--with-all-dependencies

This allows Composer to update dependencies of your direct dependencies when necessary.

This was important because the problem wasn't isolated to one package.

The dependency tree contained outdated packages throughout the application.

Why We Didn't Edit the Vendor Files

One of the most important lessons from this debugging process is:

Do not manually edit files inside vendor/.

For example, it might be tempting to open:

vendor/laravel/framework/src/Illuminate/Log/Logger.php

and change the nullable parameter manually.

Similarly, you might modify:

vendor/monolog/monolog/src/Monolog/Logger.php

to silence the warning.

That is not the correct long-term solution.

The next time you run:

composer install

or:

composer update

Composer can overwrite those changes.

The correct approach is to update the dependency that contains the incompatible code.

Test the Application Again

After updating the dependencies, I ran:

php artisan serve

And the result was:

INFO Server running on [http://127.0.0.1:8000].

Most importantly, the previous deprecation warning was gone.

There was no longer:

Illuminate\Log\Logger::__construct():
Implicitly marking parameter $dispatcher as nullable is deprecated

The application started normally.

Verify Platform Requirements

After updating the packages, the next step is to run:

composer check-platform-reqs

This verifies that the installed dependencies are compatible with the PHP version and required PHP extensions.

It is a good idea to run this after a major dependency update.

Check for Security Vulnerabilities

During the dependency update, Composer reported:

Found 92 security vulnerability advisories affecting 22 packages.

That is something that should not be ignored.

The next command to run is:

composer audit

This provides more information about the affected packages and available updates.

Dependency maintenance isn't only about eliminating errors and warnings. Security vulnerabilities are equally important.

Useful Composer Commands for Debugging

Here are some Composer commands that proved particularly useful during this process.

Check installed package
composer show package/name

Example:

composer show monolog/monolog
Find out why a package is installed
composer why package/name

Example:

composer why ezyang/htmlpurifier
Find what blocks a PHP version
composer why-not php 8.5
Check platform requirements
composer check-platform-reqs
See available updates
composer outdated
Preview an update
composer update --dry-run
Update dependencies
composer update -W
Check security vulnerabilities
composer audit

These commands are extremely useful when debugging Laravel dependency problems.

Conclusion

The original problem wasn't caused by the Laravel application code itself.

The underlying problem was an outdated dependency tree running on a much newer PHP version.

The environment looked like this:

PHP 8.5.4
↓
Laravel 10.25.1
↓
Monolog 3.4.0
↓
HTMLPurifier 4.16.0
↓
PHP compatibility/deprecation problems

After updating the dependencies:

PHP 8.5.4
↓
Updated Laravel 10 dependencies
↓
Updated Monolog
↓
Updated HTMLPurifier
↓
Compatible dependency tree
↓
Laravel application starts normally

The biggest lesson is simple:

When PHP starts reporting deprecation warnings from the vendor directory, don't immediately edit the vendor files. Investigate the dependency versions and let Composer resolve the compatibility problem.

Commands such as:

composer why
composer why-not
composer outdated
composer update --dry-run
composer check-platform-reqs
composer audit

can turn what looks like a mysterious Laravel error into a traceable dependency problem.

How to Set Up GitHub SSH on Ubuntu: A Beginner-Friendly Guide

Vincent Tommi — Tue, 15 Sep 2026 09:26:21 +0000

If you're using Git and GitHub on Ubuntu, setting up SSH authentication is a useful step. It allows you to connect your local machine to GitHub securely without entering your GitHub credentials every time you push or pull code.

While setting up SSH on my Ubuntu machine, I made a small mistake when generating the SSH key. Instead of accepting the default file location, I entered a custom name.

This article explains what I did, what went wrong, and how I fixed it.

What Is SSH?

SSH stands for Secure Shell. It is a secure way of connecting and authenticating between computers.

With GitHub, SSH allows your local machine to authenticate with your GitHub account.

Instead of using an HTTPS URL like:

https://github.com/username/repository.git

you can use an SSH URL:

git@github.com:username/repository.git

Once SSH is configured, commands such as:

git clone
git pull
git push

can communicate with GitHub using your SSH key.

Step 1: Generate an SSH Key

On Ubuntu, open your terminal and run:

ssh-keygen -t ed25519 -C "your-email@example.com"

For example:

ssh-keygen -t ed25519 -C "vincenttommikorir@gmail.com"

You should see something similar to:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/backend-developer/.ssh/id_ed25519):

The important part

At this point, SSH is asking where you want to save the key.

The recommended approach for a first setup is simply to press Enter.

That will use the default location:

/home/backend-developer/.ssh/id_ed25519

You will then have:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

The first file is your private key.

The second file is your public key.

A Mistake I Made

When I generated my key, I entered:

Tommi

when SSH asked:

Enter file in which to save the key (/home/backend-developer/.ssh/id_ed25519):

SSH therefore created:

~/Tommi
~/Tommi.pub

instead of:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

The key itself was still valid. It was simply saved in a different location.

This is an important lesson: entering a filename at that prompt changes where SSH saves the key.

Step 2: Check Where Your Key Was Saved

If you accidentally entered a custom name, you can check your home directory:

ls -l ~/Tommi*

You may see:

/home/backend-developer/Tommi
/home/backend-developer/Tommi.pub

This confirms that the key exists.

Step 3: Move the Key to the `.ssh` Directory

The .ssh directory is the standard location for SSH keys.

If your files are currently:

~/Tommi
~/Tommi.pub

you can move them using:

mv ~/Tommi ~/.ssh/id_ed25519
mv ~/Tommi.pub ~/.ssh/id_ed25519.pub

Now your files should be:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

You can check them with:

ls -la ~/.ssh

Step 4: Set the Correct Permissions

SSH keys should have appropriate file permissions.

Run:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

The private key should be readable only by your user.

That's why we use:

chmod 600 ~/.ssh/id_ed25519

Your public key can have less restrictive permissions:

chmod 644 ~/.ssh/id_ed25519.pub

Step 5: Start the SSH Agent

The SSH agent helps manage your private keys.

Start it with:

eval "$(ssh-agent -s)"

You should get something similar to:

Agent pid 38799

The process ID will be different on different systems.

Step 6: Add Your SSH Key to the Agent

Run:

ssh-add ~/.ssh/id_ed25519

If you created a passphrase for your key, you may be asked to enter it.

You can verify that the key has been added:

ssh-add -l

You should see your key fingerprint.

For example:

256 SHA256:AR9yA2U3it1bo5y6erYw/yg/XLsQr8CX/wKw+hw/XAQ

Step 7: Get Your Public Key

Now display your public key:

cat ~/.ssh/id_ed25519.pub

It should look similar to:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... your-email@example.com

Copy the entire line.

Important Security Note

There are two files:

id_ed25519
id_ed25519.pub

The difference is important.

Private key

id_ed25519

Never share this file with anyone.

Public key

id_ed25519.pub

This is the key you add to GitHub.

You can share your public key, but keep your private key secret.

Step 8: Add the Public Key to GitHub

Settings → SSH and GPG keys → New SSH key

Give the key a recognizable title, for example:

Lenovo X390 Ubuntu

Select:

Authentication Key

Then paste the contents of:

cat ~/.ssh/id_ed25519.pub

into the key field.

Save the key.

Step 9: Test the GitHub SSH Connection

Now test the connection:

ssh -T git@github.com

The first time you connect, you may see:

Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type:

yes

If everything is configured correctly, GitHub should respond with something similar to:

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

This means your SSH authentication is working.

Step 10: Use SSH When Cloning Repositories

Once SSH is configured, use the SSH repository URL when cloning.

Instead of:

git clone https://github.com/username/repository.git

use:

git clone git@github.com:username/repository.git

For example:

git clone git@github.com:vincenttommi/my-project.git

What If I Already Have a Git Repository?

If you already cloned a project using HTTPS, check the remote URL:

git remote -v

You might see:

origin  https://github.com/username/repository.git (fetch)
origin  https://github.com/username/repository.git (push)

You can change it to SSH:

git remote set-url origin git@github.com:username/repository.git

Then check again:

git remote -v

You should now see:

origin  git@github.com:username/repository.git (fetch)
origin  git@github.com:username/repository.git (push)

You can then use:

git pull

and:

git push

using SSH authentication.

Common Mistake: "No Such File or Directory"

One error I encountered was:

cat: /home/backend-developer/.ssh/id_ed25519.pub: No such file or directory

This happened because I had saved the key as:

Tommi

rather than accepting the default:

~/.ssh/id_ed25519

I also tried:

cat ~/.ssh/id_Tommi.pub

but that didn't work either because the file wasn't saved as id_Tommi.pub.

The actual file was:

~/Tommi.pub

The lesson is to check where SSH actually created the files instead of assuming their names.

Useful Commands

Here are the main commands from this setup:

Generate a key

ssh-keygen -t ed25519 -C "your-email@example.com"

Check SSH files

ls -la ~/.ssh

Start SSH agent

eval "$(ssh-agent -s)"

Add your key

ssh-add ~/.ssh/id_ed25519

List keys loaded into the agent

ssh-add -l

Display public key

cat ~/.ssh/id_ed25519.pub

Test GitHub

ssh -T git@github.com

Check Git remote

git remote -v

Change an HTTPS remote to SSH

git remote set-url origin git@github.com:USERNAME/REPOSITORY.git

Final Thoughts

Setting up SSH with GitHub is straightforward once you understand the difference between the private key, public key, and SSH agent.

The biggest lesson I learned from my setup was not to overlook this prompt:

Enter file in which to save the key (/home/username/.ssh/id_ed25519):

If you're not sure what to enter, simply press Enter and use the default location.

If you accidentally save the key somewhere else, don't panic. The key is still usable—you can move it into the .ssh directory and configure it correctly.

Learning from small mistakes like this is part of working with Linux and development tools. Documenting these problems can also help another developer who runs into the same issue.

Happy coding!

Laravel for Django Developers: A Practical Guide to Laravel Architecture

Vincent Tommi — Fri, 04 Sep 2026 12:49:59 +0000

If you've spent some time building applications with Django and have decided to explore Laravel, you may initially feel like you're learning backend development all over again.

You're not.

The syntax is different. The project structure is different. The terminology is different. But many of the architectural ideas behind Laravel will feel surprisingly familiar if you've worked with Django.

This article is a practical guide for Django developers transitioning to Laravel. Instead of learning Laravel concepts in isolation, we'll map them to their Django equivalents and build a mental model of how a Laravel application works.

By the end, you should be able to look at a Laravel project and understand where routes, controllers, models, validation, authentication, business logic, and database operations belong.

1. Django vs Laravel: The Mental Translation

The easiest way to start learning Laravel as a Django developer is to create a mental translation table.

Django	Laravel
Django project	Laravel application
Django app	No exact equivalent
`urls.py`	`routes/web.php`, `routes/api.php`
View function / Class-Based View	Controller method
Django ORM	Eloquent ORM
Model	Model
`models.py`	`app/Models/`
DRF Serializer	API Resource / Form Request
Django Forms	Form Requests
Middleware	Middleware
`settings.py`	`.env` + `config/`
`manage.py`	`artisan`
Django migrations	Laravel migrations
Django templates	Blade
`JsonResponse` / DRF Response	`response()->json()`
Django signals	Events / Observers
Management commands	Artisan commands
`pip`	Composer
`requirements.txt`	`composer.json`
Celery	Laravel Queues / Jobs

The important thing is not to assume that these are exact one-to-one replacements.

They aren't.

They are simply useful mental bridges.

For example, a Laravel API Resource and a Django REST Framework Serializer both help shape API responses, but they work differently.

2. The Laravel Request Lifecycle

Before learning individual Laravel components, understand what happens when a request reaches your application.

Imagine a React frontend sends:

POST /api/properties

A simplified Laravel request lifecycle looks like this:

React / Browser / Mobile App
            |
            v
       HTTP Request
            |
            v
      public/index.php
            |
            v
        Bootstrap
            |
            v
        Middleware
            |
            v
          Router
            |
            v
        Controller
            |
       +----+----+
       |         |
       v         v
   Validation  Business Logic
                 |
                 v
              Model
                 |
                 v
             Database
                 |
                 v
              Resource
                 |
                 v
           JSON Response
                 |
                 v
               Client

This is the architecture you should keep in your head while learning Laravel.

3. Laravel Project Structure

A fresh Laravel project looks roughly like this:

my-project/
│
├── app/
│   ├── Console/
│   ├── Exceptions/
│   ├── Http/
│   │   ├── Controllers/
│   │   ├── Middleware/
│   │   └── Requests/
│   │
│   ├── Models/
│   └── Providers/
│
├── bootstrap/
│
├── config/
│
├── database/
│   ├── factories/
│   ├── migrations/
│   └── seeders/
│
├── public/
│   └── index.php
│
├── resources/
│   ├── views/
│   ├── css/
│   └── js/
│
├── routes/
│   ├── web.php
│   ├── api.php
│   └── console.php
│
├── storage/
│
├── tests/
│
├── vendor/
│
├── .env
├── artisan
└── composer.json

If you're coming from Django, this structure might initially feel strange.

Django encourages you to break functionality into applications:

project/
├── users/
├── properties/
├── bookings/
└── payments/

Laravel doesn't enforce that approach.

Instead, a typical Laravel application organizes code around responsibilities:

app/
├── Models/
├── Http/
│   ├── Controllers/
│   ├── Requests/
│   └── Middleware/
└── Services/

You can still organize a large Laravel project by domain or feature, but Laravel itself doesn't force you to create an "app" for every feature.

4. Routes: Django's `urls.py` vs Laravel Routes

If you've used Django, routing is easy to understand.

In Django you might have:

path(
    "properties/",
    views.properties
)

Laravel uses:

Route::get(
    '/properties',
    [PropertyController::class, 'index']
);

Laravel routes are commonly placed in:

routes/
├── web.php
├── api.php
└── console.php

For example:

Route::get('/properties', [
    PropertyController::class,
    'index'
]);

POST:

Route::post('/properties', [
    PropertyController::class,
    'store'
]);

PUT:

Route::put('/properties/{id}', [
    PropertyController::class,
    'update'
]);

DELETE:

Route::delete('/properties/{id}', [
    PropertyController::class,
    'destroy'
]);

Laravel makes the HTTP method explicit in the route definition.

5. Route Parameters

In Django you might write:

path(
    "properties/<int:id>/",
    views.property_detail
)

Laravel:

Route::get(
    '/properties/{id}',
    [PropertyController::class, 'show']
);

Then your controller can receive the ID:

public function show($id)
{
    //
}

A request such as:

GET /properties/10

gives:

$id = 10;

Laravel also supports a more powerful feature called route model binding, which we'll get to later.

6. Controllers: Django Views vs Laravel Controllers

This is one of the easiest concepts to transfer.

A Django function-based view might look like:

def properties(request):
    properties = Property.objects.all()

    return JsonResponse({
        "properties": list(
            properties.values()
        )
    })

A Laravel controller could look like:

class PropertyController extends Controller
{
    public function index()
    {
        $properties = Property::all();

        return response()->json([
            'properties' => $properties
        ]);
    }
}

Conceptually:

Django View
     ≈
Laravel Controller Method

Create a controller with Artisan:

php artisan make:controller PropertyController

Laravel creates:

app/Http/Controllers/PropertyController.php

7. Models and Eloquent

If there is one Laravel feature Django developers will understand almost immediately, it's Eloquent.

Eloquent is Laravel's ORM.

Django:

Property.objects.all()

Laravel:

Property::all();

Django:

Property.objects.get(id=1)

Laravel:

Property::find(1);

Django:

Property.objects.filter(
    status="available"
)

Laravel:

Property::where(
    'status',
    'available'
)->get();

Django:

Property.objects.filter(
    price__gt=10000
)

Laravel:

Property::where(
    'price',
    '>',
    10000
)->get();

The syntax is different, but the underlying idea is the same:

Application
     |
     v
ORM
     |
     v
Database

8. Creating Models

Create a Laravel model:

php artisan make:model Property

You will get something like:

app/Models/Property.php

A model might look like:

class Property extends Model
{
    protected $fillable = [
        'name',
        'location',
        'price',
    ];
}

You can then create records:

$property = Property::create([
    'name' => 'Apartment A',
    'location' => 'Nairobi',
    'price' => 25000,
]);

The Django equivalent is:

Property.objects.create(
    name="Apartment A",
    location="Nairobi",
    price=25000
)

9. Mass Assignment

One Laravel concept that might initially confuse Django developers is mass assignment.

You'll frequently see:

protected $fillable = [
    'name',
    'location',
    'price',
];

This controls which attributes can be assigned through methods such as:

Property::create([
    'name' => 'Apartment A',
    'location' => 'Nairobi',
    'price' => 25000,
]);

It's an important security mechanism.

You should understand $fillable and $guarded early when learning Eloquent.

10. Migrations

If you've worked with Django migrations, Laravel migrations will feel familiar.

Django:

python manage.py makemigrations
python manage.py migrate

Laravel:

php artisan make:migration create_properties_table

Then:

php artisan migrate

A migration might look like:

Schema::create('properties', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->string('location');
    $table->decimal('price', 10, 2);
    $table->timestamps();
});

Compare that with Django:

class Property(models.Model):
    name = models.CharField(max_length=255)
    location = models.CharField(max_length=255)
    price = models.DecimalField(
        max_digits=10,
        decimal_places=2
    )

The syntax is different, but you're expressing the same database structure.

11. Artisan: Laravel's `manage.py`

If Django has:

python manage.py

Laravel has:

php artisan

Artisan is one of the most important tools in the Laravel ecosystem.

Some commands you'll use frequently:

php artisan serve

Start the development server.

php artisan route:list

Display your application's routes.

php artisan make:model Property

Create a model.

php artisan make:controller PropertyController

Create a controller.

php artisan make:request StorePropertyRequest

Create a validation request.

php artisan make:resource PropertyResource

Create an API Resource.

php artisan migrate

Run migrations.

php artisan migrate:rollback

Roll back migrations.

php artisan migrate:fresh

Drop all tables and rebuild the database.

php artisan db:seed

Run seeders.

php artisan optimize:clear

Clear Laravel's cached configuration, routes, views, and other optimized files.

A good rule:

If you're wondering whether Laravel has a CLI command for something, check Artisan first.

12. Relationships

Laravel's Eloquent relationships are another area where Django developers should feel at home.

Suppose a property belongs to a landlord.

Django:

class Property(models.Model):
    landlord = models.ForeignKey(
        User,
        on_delete=models.CASCADE
    )

Laravel:

class Property extends Model
{
    public function landlord()
    {
        return $this->belongsTo(
            User::class
        );
    }
}

Now you can access:

$property->landlord;

13. One-to-Many Relationships

Suppose a landlord owns multiple properties.

Laravel:

class Landlord extends Model
{
    public function properties()
    {
        return $this->hasMany(
            Property::class
        );
    }
}

Then:

$landlord->properties;

Django might be:

landlord.properties.all()

assuming you configured the appropriate related_name.

14. Many-to-Many Relationships

Django:

class Student(models.Model):
    courses = models.ManyToManyField(
        Course
    )

Laravel:

public function courses()
{
    return $this->belongsToMany(
        Course::class
    );
}

Then:

$student->courses;

Again, the terminology changes but the database relationship remains the same.

15. Eager Loading

One of the most important ORM concepts is avoiding unnecessary database queries.

Laravel:

Property::with('landlord')->get();

Django's rough equivalent:

Property.objects.select_related(
    "landlord"
)

For collection relationships:

Property::with('bookings')->get();

is conceptually similar to:

Property.objects.prefetch_related(
    "bookings"
)

This is important because both Django and Laravel applications can suffer from the infamous N+1 query problem.

16. Validation: DRF Serializers vs Laravel Form Requests

This is where the architecture starts becoming noticeably different.

In Django REST Framework, you might put validation inside a serializer:

class PropertySerializer(
    serializers.ModelSerializer
):
    class Meta:
        model = Property
        fields = "__all__"

    def validate_price(self, value):
        if value < 0:
            raise serializers.ValidationError(
                "Price cannot be negative"
            )

        return value

Laravel commonly separates request validation into a Form Request.

Create one:

php artisan make:request StorePropertyRequest

Then:

class StorePropertyRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name' => [
                'required',
                'string',
                'max:255'
            ],

            'location' => [
                'required',
                'string'
            ],

            'price' => [
                'required',
                'numeric',
                'min:0'
            ],
        ];
    }
}

Then inject it into your controller:

public function store(
    StorePropertyRequest $request
) {
    //
}

Laravel automatically validates the incoming request before your controller method proceeds.

17. API Resources: Think DRF Serializer Output

Laravel has API Resources for transforming models into API responses.

Create one:

php artisan make:resource PropertyResource

Then:

class PropertyResource extends JsonResource
{
    public function toArray(
        Request $request
    ): array {
        return [
            'id' => $this->id,
            'name' => $this->name,
            'location' => $this->location,
            'price' => $this->price,
        ];
    }
}

Then:

return new PropertyResource($property);

For collections:

return PropertyResource::collection(
    Property::all()
);

A useful mental model is:

DRF Serializer
       |
       +---- validation/input
       |
       +---- representation/output

Laravel
       |
       +---- Form Request
       |       -> validation
       |
       +---- API Resource
               -> representation

Laravel separates these responsibilities more explicitly.

18. Middleware

Django developers already understand middleware.

Django:

MIDDLEWARE = [
    ...
]

Laravel:

Route::middleware('auth')->group(
    function () {
        // protected routes
    }
);

You can create middleware using Artisan:

php artisan make:middleware CheckUserRole

For example:

if ($request->user()->role !== 'admin') {
    abort(403);
}

Middleware is useful for concerns that should happen before or after controller execution, such as:

Authentication
Logging
Rate limiting
CORS
Role checks
Request modification

19. Authentication and Authorization

Laravel supports several authentication approaches.

One commonly encountered solution for API and SPA applications is Laravel Sanctum.

A typical architecture might look like:

React
  |
  v
Laravel API
  |
  v
Authentication
  |
  v
Controller

If you're coming from Django REST Framework and JWT, don't assume Sanctum is simply "Laravel's JWT."

Sanctum provides API token authentication and SPA authentication capabilities, but its model and workflow differ from JWT-based authentication.

Laravel also provides:

Gates
Policies
Middleware
Authentication guards

These become especially important as your application grows.

20. Policies and Gates

Suppose a landlord should only be allowed to update their own property.

You could check this directly inside a controller, but Laravel provides authorization mechanisms such as Policies.

Conceptually:

User
  |
  v
Can this user update this property?
  |
  +---- YES ---> Continue
  |
  +---- NO ----> 403 Forbidden

This keeps authorization logic separate from your business logic.

If you've used Django permissions, this is an area you'll want to explore carefully.

21. Environment Variables and Configuration

Laravel uses a .env file for environment-specific configuration.

For example:

APP_NAME=Laravel
APP_ENV=local
APP_DEBUG=true

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=my_database
DB_USERNAME=root
DB_PASSWORD=

Django developers may recognize this approach from using packages such as python-decouple or django-environ.

Laravel configuration is stored under:

config/

For example:

config/
├── app.php
├── database.php
├── auth.php
├── cache.php
└── filesystems.php

Django developers can think of this as a more distributed equivalent of settings.py.

22. Blade Templates

Laravel's server-side templating engine is called Blade.

Django:

<h1>{{ property.name }}</h1>

Blade:

<h1>{{ $property->name }}</h1>

Django:

{% for property in properties %}
    {{ property.name }}
{% endfor %}

Blade:

@foreach($properties as $property)
    {{ $property->name }}
@endforeach

If you're building a Laravel API consumed by React, you may use Blade very little.

If you're building a traditional Laravel web application, Blade becomes much more important.

23. Dependency Injection and the Service Container

This is one of the Laravel concepts I recommend Django developers spend extra time understanding.

Suppose your controller depends on a service:

class PropertyController extends Controller
{
    public function __construct(
        PropertyService $propertyService
    ) {
        $this->propertyService =
            $propertyService;
    }
}

Laravel's Service Container can resolve that dependency for you.

Conceptually:

Controller
    |
    | requires
    v
PropertyService
    |
    v
Laravel Service Container

This is Laravel's dependency injection system.

Once you understand the Service Container, concepts such as service providers, bindings, interfaces, and dependency injection become much easier.

24. Services and Business Logic

Laravel applications often introduce service classes for complex business logic.

For example:

app/
└── Services/
    ├── PropertyService.php
    ├── BookingService.php
    └── PaymentService.php

A service might contain:

class PropertyService
{
    public function create(
        array $data
    ) {
        return Property::create($data);
    }
}

Then your controller becomes:

public function store(
    StorePropertyRequest $request
) {
    $property =
        $this->propertyService->create(
            $request->validated()
        );

    return new PropertyResource(
        $property
    );
}

The idea is to prevent controllers from becoming massive.

Instead of:

Controller
 ├── validation
 ├── authorization
 ├── payment
 ├── database logic
 ├── email
 ├── notifications
 └── business rules

you can have:

Controller
     |
     v
Service
     |
     +---- Model
     +---- Payment
     +---- Notification
     +---- Events

Don't create a service class for every two-line database query, though.

Use this architecture when it actually improves separation of responsibilities.

25. Events and Listeners

Laravel has an event-driven architecture available through Events and Listeners.

Imagine a user registers:

User registers
      |
      v
UserRegistered event
      |
      +----> SendWelcomeEmail
      |
      +----> CreateProfile
      |
      +----> NotifyAdmin

This keeps secondary operations out of the main request logic.

Django developers may find this somewhat similar to using signals, although Laravel Events and Listeners provide a different and often more explicit architecture.

26. Jobs and Queues

If you've used Celery with Django, Laravel's Jobs and Queues should make sense.

Suppose sending 10,000 emails would make a request slow.

Instead:

HTTP Request
     |
     v
Create Job
     |
     v
Queue
     |
     v
Worker
     |
     v
Send Emails

Create a job:

php artisan make:job SendNewsletter

Then dispatch it:

SendNewsletter::dispatch();

The user doesn't necessarily have to wait for the expensive operation to finish.

This is extremely useful for:

Emails
Notifications
Image processing
Reports
Payments
Imports
Exports
Heavy calculations

27. Scheduling

Laravel also includes a task scheduling system.

You might have a task that needs to run regularly:

Every day
    |
    v
Find overdue rent
    |
    v
Send reminders

Or:

Every hour
    |
    v
Clean expired sessions

This functionality can be combined with Artisan commands and queued jobs.

If you're coming from Django, think of this as part of the territory often handled by cron, Celery Beat, management commands, or similar tools.

28. Seeders and Factories

Laravel provides database seeders:

php artisan db:seed

For example:

Property::create([
    'name' => 'Apartment A',
    'location' => 'Nairobi',
    'price' => 25000,
]);

Factories allow you to generate test/development data.

For example:

Property::factory()
    ->count(50)
    ->create();

This is conceptually similar to using tools such as factory_boy in Django projects.

29. A Complete Laravel API Example

Let's put the pieces together.

Suppose we're creating:

POST /api/properties

The route:

Route::post(
    '/properties',
    [PropertyController::class, 'store']
);

The request validation:

class StorePropertyRequest
    extends FormRequest
{
    public function rules(): array
    {
        return [
            'name' => [
                'required',
                'string',
                'max:255'
            ],

            'location' => [
                'required',
                'string'
            ],

            'price' => [
                'required',
                'numeric',
                'min:0'
            ],
        ];
    }
}

The model:

class Property extends Model
{
    protected $fillable = [
        'name',
        'location',
        'price',
    ];
}

The controller:

class PropertyController extends Controller
{
    public function store(
        StorePropertyRequest $request
    ) {
        $property = Property::create(
            $request->validated()
        );

        return new PropertyResource(
            $property
        );
    }
}

The resource:

class PropertyResource extends JsonResource
{
    public function toArray(
        Request $request
    ): array {
        return [
            'id' => $this->id,
            'name' => $this->name,
            'location' => $this->location,
            'price' => $this->price,
        ];
    }
}

The client sends:

POST /api/properties
Content-Type: application/json

{
    "name": "Apartment A",
    "location": "Nairobi",
    "price": 25000
}

Laravel processes it:

POST /api/properties
        |
        v
Route
        |
        v
PropertyController
        |
        v
StorePropertyRequest
        |
        v
validated()
        |
        v
Property::create()
        |
        v
Eloquent
        |
        v
MySQL
        |
        v
PropertyResource
        |
        v
JSON Response

That's a real Laravel API architecture.

30. Translating a Django Project to Laravel

Let's say you've already built a landlord/tenant system in Django.

Your Django architecture might look like:

Django
│
├── users
├── properties
├── bookings
├── payments
└── maintenance

The Laravel equivalent could look like:

Laravel
│
├── Models
│   ├── User.php
│   ├── Property.php
│   ├── Booking.php
│   ├── RentPayment.php
│   └── MaintenanceTicket.php
│
├── Http
│   ├── Controllers
│   │   ├── AuthController.php
│   │   ├── PropertyController.php
│   │   ├── BookingController.php
│   │   └── PaymentController.php
│   │
│   ├── Requests
│   │   ├── LoginRequest.php
│   │   ├── StorePropertyRequest.php
│   │   └── StoreBookingRequest.php
│   │
│   └── Resources
│       ├── UserResource.php
│       ├── PropertyResource.php
│       └── BookingResource.php
│
└── Services
    ├── AuthService.php
    ├── PropertyService.php
    └── PaymentService.php

Then your API flow becomes:

React
  |
  | POST /api/properties
  v
Laravel Router
  |
  v
PropertyController
  |
  v
StorePropertyRequest
  |
  v
Authorization
  |
  v
PropertyService
  |
  v
Property Model
  |
  v
MySQL
  |
  v
PropertyResource
  |
  v
JSON
  |
  v
React

This is a very useful architecture for someone already comfortable with Django REST Framework.

31. What You Should NOT Do as a Django Developer

One of the biggest mistakes when moving frameworks is trying to force your old framework's architecture into the new framework.

Don't assume:

Laravel = Django written in PHP

It isn't.

For example, don't automatically create:

PropertySerializer
PropertyView
PropertyForm
PropertyService

just because that's how you might structure something in Django.

Instead, understand what Laravel provides and use each component where it makes sense.

Likewise, don't put everything inside controllers simply because Laravel makes it easy.

A controller containing 500 lines of business logic isn't good Laravel architecture.

32. The Laravel Architecture to Learn

I'd recommend learning Laravel in roughly this order.

Level 1 — Foundation

Learn:

PHP
  ↓
Composer
  ↓
Laravel installation
  ↓
Project structure
  ↓
Artisan
  ↓
Routes
  ↓
Controllers

Level 2 — Database

Then:

Migrations
  ↓
Models
  ↓
Eloquent
  ↓
Relationships
  ↓
Query Builder
  ↓
Factories
  ↓
Seeders

Level 3 — API Development

Then:

HTTP Requests
  ↓
Validation
  ↓
Form Requests
  ↓
API Resources
  ↓
Pagination
  ↓
JSON responses

Level 4 — Security

Then:

Authentication
  ↓
Middleware
  ↓
Policies
  ↓
Gates
  ↓
Authorization
  ↓
Sanctum

Level 5 — Laravel Architecture

Then:

Service Container
  ↓
Dependency Injection
  ↓
Service Providers
  ↓
Services
  ↓
Events
  ↓
Listeners
  ↓
Jobs
  ↓
Queues

Level 6 — Production

Finally:

Caching
  ↓
Queues
  ↓
Scheduling
  ↓
Logging
  ↓
Testing
  ↓
Workers
  ↓
Deployment

33. The Most Important Concepts to Focus On

If you've already read the Django documentation, don't try to learn every Laravel feature immediately.

Focus heavily on these:

1. Eloquent

Understand:

Model::all();

Model::find();

Model::where();

Model::create();

Model::update();

Model::delete();

Then move into relationships and eager loading.

2. Form Requests

Understand how Laravel validates incoming data.

3. API Resources

Understand how Laravel transforms models into API responses.

4. Middleware

Understand where authentication, rate limiting, and request processing happen.

5. Policies and Gates

Understand authorization.

6. Service Container

This is one of Laravel's most important architectural concepts.

7. Dependency Injection

Understand how Laravel resolves dependencies.

8. Jobs and Queues

Especially if you're building production applications.

9. Events and Listeners

Learn how to decouple secondary operations from your main application flow.

10. Artisan

You'll use it constantly.

34. The Mental Model I Recommend

If you're transitioning from Django, remember this:

                       LARAVEL

                         Request
                            |
                            v
                       Middleware
                            |
                            v
                          Route
                            |
                            v
                       Controller
                            |
                 +----------+----------+
                 |                     |
                 v                     v
          Form Request             Policy
          Validation            Authorization
                 |
                 v
               Service
                 |
                 v
              Eloquent
                 |
                 v
              Database
                 |
                 v
              Resource
                 |
                 v
            JSON Response

You don't have to use every box in every request.

A simple endpoint might be:

Request
   ↓
Route
   ↓
Controller
   ↓
Model
   ↓
Response

A more complex endpoint might be:

Request
   ↓
Middleware
   ↓
Route
   ↓
Form Request
   ↓
Policy
   ↓
Controller
   ↓
Service
   ↓
Eloquent
   ↓
Event
   ↓
Job
   ↓
Resource
   ↓
Response

The architecture grows with the complexity of the application.

35. Final Thoughts

Moving from Django to Laravel isn't really starting over.

If you've already built applications with Django, you already understand most of the important backend concepts.

You know:

HTTP
Routing
REST APIs
Models
ORMs
Databases
Relationships
Migrations
Authentication
Authorization
Middleware
Validation
Serialization
Background tasks

Laravel simply implements many of these ideas differently.

The biggest shift is learning Laravel's way of organizing those responsibilities.

Instead of thinking:

"Where is the Laravel version of my Django file?"

start thinking:

"What responsibility am I trying to solve, and which Laravel component is designed for it?"

Once you start thinking that way, Laravel becomes much easier to understand.

And if you've already built a Django REST API, you're not beginning your Laravel journey as a beginner.

You're learning a new ecosystem using knowledge you already have.

The fastest way to make the transition stick is to build something you already understand in Django.

For example:

Landlord/Tenant API
       |
       +-- Authentication
       +-- Users
       +-- Properties
       +-- Bookings
       +-- Rent Payments
       +-- Maintenance Tickets
       +-- Roles
       +-- Authorization
       +-- Notifications

Build the same system in Laravel while consciously mapping:

Django              Laravel

urls.py          →  routes
views.py         →  controllers
models.py        →  Eloquent models
DRF serializers  →  requests/resources
ORM              →  Eloquent
middleware       →  middleware
manage.py        →  Artisan
Celery           →  Jobs/Queues
settings.py      →  config + .env

That's when Laravel stops looking like a completely different framework and starts becoming another way of solving problems you already know how to solve.

Fixing PDO::MYSQL_ATTR_SSL_CA Deprecation Errors in PHP 8.5 and Laravel

Vincent Tommi — Wed, 02 Sep 2026 20:33:59 +0000

If you've recently upgraded to PHP 8.5 and started seeing deprecation warnings in a Laravel application, you may run into an error similar to this:

Deprecated: Constant PDO::MYSQL_ATTR_SSL_CA is deprecated since 8.5,
use Pdo\Mysql::ATTR_SSL_CA instead

In my case, the warning was pointing to:

config/database.php

at line 62.

Here's how I fixed it and what I learned along the way.

The Problem

After upgrading to PHP 8.5, I ran:

php artisan config:clear

Instead of clearing the configuration cache, Laravel returned:

Deprecated: Constant PDO::MYSQL_ATTR_SSL_CA is deprecated since 8.5,
use Pdo\Mysql::ATTR_SSL_CA instead

In database.php line 62:
Undefined constant PDO::mysql_ATTR_SSL_CA

The important part is:

Undefined constant PDO::mysql_ATTR_SSL_CA

This happened because the constant had been changed incorrectly.

The Old Constant

Older PHP versions commonly use:

PDO::MYSQL_ATTR_SSL_CA

PHP 8.5 deprecates this form and recommends the MySQL-specific class instead.

The new form is:

Pdo\Mysql::ATTR_SSL_CA

Notice that PHP class and constant names are case-sensitive.

Incorrect

PDO::mysql_ATTR_SSL_CA

Correct

Pdo\Mysql::ATTR_SSL_CA

The difference is important:

PDO::mysql_ATTR_SSL_CA
^^^  ^^^^^^^^^^^^^^^

Pdo\Mysql::ATTR_SSL_CA
^^^  ^^^^^ ^^^^^^^^^

Fixing `database.php`

Open your Laravel project's database configuration:

config/database.php

Look for:

PDO::MYSQL_ATTR_SSL_CA

Replace it with:

Pdo\Mysql::ATTR_SSL_CA

For example, if you have:

'options' => extension_loaded('pdo_mysql') ? array_filter([
    PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
]) : [],

change it to:

'options' => extension_loaded('pdo_mysql') ? array_filter([
    Pdo\Mysql::ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
]) : [],

What If You Can't Edit the File With Nano?

If you're using Ubuntu and nano isn't working for you, there are several alternatives.

Using VS Code

If VS Code is installed:

code config/database.php

Or use the full path:

code /home/tommi/Desktop/Development/programmer/samupos/config/database.php

Then replace:

PDO::MYSQL_ATTR_SSL_CA

with:

Pdo\Mysql::ATTR_SSL_CA

Using the Terminal

If you only need to replace the constant, you can use sed:

sed -i 's/PDO::mysql_ATTR_SSL_CA/Pdo\\Mysql::ATTR_SSL_CA/g' config/database.php

If you get a permission error, you can use:

sudo sed -i 's/PDO::mysql_ATTR_SSL_CA/Pdo\\Mysql::ATTR_SSL_CA/g' config/database.php

Then verify the change:

grep -n "SSL_CA" config/database.php

You should see:

Pdo\Mysql::ATTR_SSL_CA

Verify That PHP Supports the New Constant

Before trying Laravel again, you can check whether PHP recognizes the new constant:

php -r 'var_dump(Pdo\Mysql::ATTR_SSL_CA);'

If everything is working correctly, PHP should return an integer value.

For example:

int(10023)

The exact integer isn't the important part. What matters is that PHP recognizes the constant without throwing an error.

Clear Laravel's Configuration Cache

Once the constant has been corrected, go back to your Laravel project:

cd /home/tommi/Desktop/Development/programmer/samupos

Then run:

php artisan config:clear

You can also rebuild the configuration cache:

php artisan config:cache

If those commands complete successfully, Laravel should no longer complain about:

PDO::MYSQL_ATTR_SSL_CA

Another PHP 8.5 Warning

During this process, I also encountered another warning:

Deprecated: Using null as an array offset is deprecated, use an empty string instead

It pointed to:

vendor/laravel/framework/src/Illuminate/Log/LogManager.php

This is a different issue from the PDO constant.

It's important not to directly edit files inside vendor/.

The vendor directory contains dependencies installed by Composer, so changes made there can be overwritten the next time you run:

composer install

or:

composer update

Instead, check your Laravel version:

php artisan --version

and your PHP version:

php -v

If you're running an older Laravel version with PHP 8.5, you may need to update Laravel or one of its dependencies to a version that properly supports PHP 8.5.

Don't Mix Ubuntu PPAs Just to Fix This

Another potential problem I encountered while setting up PHP was an Ubuntu repository error involving the Ondřej PHP PPA:

The repository 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu resolute Release'
does not have a Release file.

If you're running a newer Ubuntu release and the PPA doesn't provide packages for that release, don't simply change the distribution name in the repository from something like:

resolute

to:

noble

just to make apt update work.

Mixing packages from different Ubuntu releases can cause dependency problems.

Instead, verify what PHP version and packages your current Ubuntu release provides.

Useful Diagnostic Commands

When troubleshooting PHP and Laravel compatibility issues, these commands are useful:

Check PHP version

php -v

Check Laravel version

php artisan --version

Check whether PDO MySQL is installed

php -m | grep pdo_mysql

Expected output:

pdo_mysql

Check the new PHP 8.5 constant

php -r 'var_dump(Pdo\Mysql::ATTR_SSL_CA);'

Find the SSL constant in Laravel's configuration

grep -n "SSL_CA" config/database.php

Final Fix

The key change is simply:

- PDO::MYSQL_ATTR_SSL_CA
+ Pdo\Mysql::ATTR_SSL_CA

Then clear Laravel's configuration:

php artisan config:clear

and, if necessary:

php artisan config:cache

Conclusion

PHP upgrades can expose deprecated functionality that previously worked without any problems. PHP 8.5 is a good example of this: code using the old PDO::MYSQL_ATTR_SSL_CA constant can start producing deprecation warnings.

The important thing is to distinguish between a deprecation warning, an actual PHP error, and a framework compatibility problem.

For this particular issue, the solution is straightforward:

Pdo\Mysql::ATTR_SSL_CA

instead of:

PDO::MYSQL_ATTR_SSL_CA

And when another warning points into vendor/, resist the temptation to edit the dependency directly. Check your Laravel and package versions first and upgrade them where appropriate.

Hopefully this saves someone else a few minutes when upgrading a Laravel project to PHP 8.5.

Understanding the Laravel `config` Folder: What I'm Learning as a Beginner

Vincent Tommi — Sat, 29 Aug 2026 11:58:51 +0000

I'm currently learning Laravel, and one of the things that caught my attention was the config folder.

Coming from a backend development background, I wanted to understand what all those PHP files were doing instead of simply knowing that they "contain configuration."

When I opened a fresh Laravel project, I found files like:

config/
├── app.php
├── auth.php
├── broadcasting.php
├── cache.php
├── concurrency.php
├── cors.php
├── database.php
├── filesystems.php
├── hashing.php
├── images.php
├── logging.php
├── mail.php
├── queue.php
├── services.php
├── session.php
└── view.php

At first, it looked like a lot to understand.

So I decided to go through them one by one and document what I'm learning. Hopefully, this can also help someone else who is starting with Laravel.

Note: The exact configuration files can vary depending on your Laravel version and the packages installed in your application.

What is the `config` folder?

The config directory contains PHP configuration files that control different parts of your Laravel application.

You can think of it as the place where Laravel learns things like:

How to connect to a database
How authentication works
How files are stored
How emails are sent
How caching works
How sessions work
How queues work
How logging works
How external services are configured

The structure looks roughly like:

Laravel Application
        |
        ↓
     config/
        |
   ┌────┼────┬────┬────┐
   ↓    ↓    ↓    ↓    ↓
  DB   Auth  Mail Cache Logging

1. `app.php`

app.php contains general configuration for your Laravel application.

For example:

return [
    'name' => env('APP_NAME', 'Laravel'),

    'env' => env('APP_ENV', 'production'),

    'debug' => (bool) env('APP_DEBUG', false),

    'url' => env('APP_URL', 'http://localhost'),

    'timezone' => 'UTC',

    'locale' => 'en',
];

It can contain settings related to:

Application name
Environment
Debug mode
Application URL
Timezone
Locale
Encryption
Service providers

For example, in .env:

APP_NAME=MyApplication

Laravel can retrieve that value using:

env('APP_NAME')

My understanding

I think of app.php as:

General settings for the Laravel application.

2. `auth.php`

The auth.php file deals with authentication.

Authentication is basically answering the question:

Who is this user?

This configuration can define things such as:

Authentication guards
User providers
User models
Password reset configuration

For example:

'providers' => [
    'users' => [
        'driver' => 'eloquent',
        'model' => App\Models\User::class,
    ],
],

This tells Laravel which model it should use when working with users.

For example:

User
  ↓
Login
  ↓
Authentication
  ↓
Authenticated request

My understanding

I think of auth.php as:

How Laravel identifies and authenticates users.

3. `broadcasting.php`

The broadcasting.php file is related to real-time events.

Broadcasting allows Laravel to send events from the server to clients in real time.

For example, imagine a chat application:

User A sends message
        ↓
Laravel
        ↓
Broadcast event
        ↓
User B receives message

This can be useful for:

Chat applications
Real-time notifications
Live dashboards
Real-time status updates

If you're building a simple CRUD API, you may not need to work with this configuration immediately.

My understanding

I think of broadcasting.php as:

Configuration for sending Laravel events to clients in real time.

4. `cache.php`

The cache.php file controls Laravel's caching system.

Caching allows your application to temporarily store data so that it doesn't have to perform the same expensive operation repeatedly.

For example:

Cache::put('username', 'Vincent', 3600);

Laravel can work with different cache stores depending on your configuration.

Examples include:

File
Database
Redis
Array

For example:

CACHE_STORE=redis

My understanding

I think of cache.php as:

Where and how Laravel stores cached data.

5. `concurrency.php`

The concurrency.php file is related to Laravel's concurrency features.

Concurrency is about allowing multiple tasks to execute without unnecessarily waiting for each one to finish before starting the next.

For example:

Without concurrency:

Task A → Task B → Task C

With concurrency:

Task A ─┐
Task B ─┼──→ Results
Task C ─┘

This can be useful when an application needs to perform several independent operations.

As I'm learning Laravel, this is one of the configuration files I'm treating as something to understand later rather than something I need to modify immediately.

My understanding

I think of concurrency.php as:

Configuration related to running multiple operations concurrently.

6. `cors.php`

CORS stands for Cross-Origin Resource Sharing.

This becomes especially important when you're building a separate frontend and backend.

For example:

Frontend
Next.js
http://localhost:3000

        ↓ API request

Backend
Laravel
http://localhost:8000

These are different origins.

The browser needs to know whether the frontend is allowed to communicate with the backend.

The CORS configuration deals with things such as:

Allowed origins
Allowed HTTP methods
Allowed headers
Credentials

For an API, this is particularly important.

My understanding

I think of cors.php as:

Configuration that controls which origins are allowed to communicate with my Laravel application.

7. `database.php`

This is one of the configuration files I'm paying the most attention to because I recently connected Laravel to PostgreSQL.

The database.php file controls Laravel's database connections.

For example, a PostgreSQL connection may look like:

'pgsql' => [
    'driver' => 'pgsql',
    'host' => env('DB_HOST', '127.0.0.1'),
    'port' => env('DB_PORT', '5432'),
    'database' => env('DB_DATABASE', 'laravel'),
    'username' => env('DB_USERNAME', 'root'),
    'password' => env('DB_PASSWORD', ''),
],

The actual values can come from .env:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=laravel
DB_USERNAME=laravel_user
DB_PASSWORD=your_password

The relationship can be understood like this:

.env
 ↓
config/database.php
 ↓
Laravel database layer
 ↓
PostgreSQL

My understanding

I think of database.php as:

How Laravel connects to and communicates with databases.

8. `filesystems.php`

This file controls Laravel's file storage.

Imagine an application where users can upload:

Profile pictures
Documents
PDFs
Product images
Videos

Laravel needs to know where those files should be stored.

For example:

Storage::put('documents/example.pdf', $file);

The filesystem configuration determines which storage disk Laravel uses.

My understanding

I think of filesystems.php as:

Where and how Laravel stores files.

9. `hashing.php`

The hashing.php file controls Laravel's hashing configuration.

Hashing is particularly important when dealing with passwords.

You should never store passwords as plain text:

password123

Instead, the password is hashed before being stored:

password123
      ↓
    Hash
      ↓
   Database

Laravel supports hashing algorithms such as:

Bcrypt
Argon
Argon2id

My understanding

I think of hashing.php as:

How Laravel hashes sensitive data such as passwords.

10. `images.php`

The images.php configuration file is related to image handling and processing.

This can become useful when an application needs to work with uploaded images.

For example:

Resizing images
Processing images
Optimizing images
Converting images

This might be useful in applications such as e-commerce platforms where users upload product images.

My understanding

I think of images.php as:

Configuration related to image processing.

11. `logging.php`

The logging.php file controls Laravel's logging system.

Logs are extremely useful when debugging an application.

Laravel can write logs to files such as:

storage/logs/laravel.log

You can also create your own logs:

Log::info('User registered successfully');

Or:

Log::error('Payment failed');

Laravel supports different logging channels.

My understanding

I think of logging.php as:

How Laravel records application events, warnings, and errors.

When debugging Laravel applications, I'll probably spend quite a lot of time looking at:

storage/logs/laravel.log

12. `mail.php`

The mail.php file controls email configuration.

Laravel applications commonly need to send emails for things such as:

Password resets
Email verification
Booking confirmations
Payment receipts
Notifications

For example, .env might contain:

MAIL_MAILER=smtp
MAIL_HOST=smtp.example.com
MAIL_PORT=587
MAIL_USERNAME=your_username
MAIL_PASSWORD=your_password

Laravel uses the mail configuration to determine how emails should be sent.

My understanding

I think of mail.php as:

How Laravel sends emails.

13. `queue.php`

The queue.php file controls Laravel's queue system.

Queues are useful for tasks that don't need to happen before the user receives a response.

For example, sending an email could be handled in the background:

User registers
      ↓
Laravel creates account
      ↓
Email job added to queue
      ↓
Response returned
      ↓
Queue worker sends email

Instead of:

User registers
      ↓
Create account
      ↓
Send email
      ↓
Wait...
      ↓
Return response

Queues can improve application responsiveness.

My understanding

I think of queue.php as:

How Laravel handles background jobs.

14. `services.php`

The services.php file is commonly used for third-party services.

For example:

GitHub
Google
Stripe
PayPal
AWS
External APIs

You might have configuration like:

'github' => [
    'client_id' => env('GITHUB_CLIENT_ID'),
    'client_secret' => env('GITHUB_CLIENT_SECRET'),
    'redirect' => env('GITHUB_REDIRECT_URI'),
],

The actual credentials would normally be stored in .env:

GITHUB_CLIENT_ID=your_client_id
GITHUB_CLIENT_SECRET=your_client_secret
GITHUB_REDIRECT_URI=http://localhost:8000/auth/github/callback

My understanding

I think of services.php as:

Configuration for services outside the Laravel application.

15. `session.php`

The session.php file controls Laravel's session management.

Sessions allow an application to remember information between HTTP requests.

For example:

User logs in
     ↓
Session created
     ↓
User visits another page
     ↓
Laravel knows the user

Laravel can store sessions using different drivers.

For example:

SESSION_DRIVER=file

or:

SESSION_DRIVER=database

My understanding

I think of session.php as:

How Laravel stores and manages user sessions.

16. `view.php`

The view.php file contains configuration related to Laravel's views.

Laravel's traditional server-side frontend system uses Blade templates.

For example:

resources/
└── views/
    ├── welcome.blade.php
    └── dashboard.blade.php

The view configuration helps Laravel locate and work with these templates.

If you're building a Laravel API without Blade, you may not interact with this file very often.

My understanding

I think of view.php as:

Configuration for Laravel's view system.

Which Configuration Files Should I Learn First?

As someone learning Laravel from a backend development perspective, I'm not trying to memorize everything at once.

I'd prioritize them like this:

Learn first

app.php
auth.php
database.php
hashing.php
logging.php
services.php

Then:

cache.php
cors.php
queue.php
session.php

And later:

broadcasting.php
concurrency.php
filesystems.php
images.php
mail.php
view.php

This doesn't mean the second group is less important. It just means you don't need to understand every Laravel feature on day one.

`.env` vs `config`

This was one of the most important things for me to understand.

Laravel has a .env file:

.env

and a configuration directory:

config/

They work together, but they have different purposes.

For example, .env might contain:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=laravel
DB_USERNAME=laravel_user
DB_PASSWORD=your_password

Then config/database.php reads those values:

'pgsql' => [
    'driver' => 'pgsql',
    'host' => env('DB_HOST', '127.0.0.1'),
    'port' => env('DB_PORT', '5432'),
    'database' => env('DB_DATABASE', 'laravel'),
    'username' => env('DB_USERNAME', 'root'),
    'password' => env('DB_PASSWORD', ''),
],

So I think of it like this:

.env
  ↓
Environment-specific values
  ↓
config/*.php
  ↓
Laravel configuration
  ↓
Laravel application

`env()` vs `config()`

You'll see these two functions frequently when working with Laravel.

`env()`

env() reads environment variables.

For example:

APP_NAME=MyApplication

You can access it with:

env('APP_NAME')

`config()`

config() reads Laravel's configuration.

For example:

config('app.name')

This can retrieve the application name configured in config/app.php.

A useful rule I'm learning is:

Use env() mainly inside configuration files, and use config() in application code.

For example, in application code, prefer:

config('app.timezone')

rather than repeatedly accessing:

env('APP_TIMEZONE')

Why `php artisan config:clear` Is Important

While setting up PostgreSQL, I ran into a situation where Laravel wasn't using the database configuration I expected.

One command I learned about was:

php artisan config:clear

This clears Laravel's cached configuration.

Laravel can cache configuration to improve performance, especially in production.

If you change your .env file and Laravel appears to be ignoring your changes, you can try:

php artisan config:clear

Then test your application again.

You can also rebuild the configuration cache with:

php artisan config:cache

A Simple Way to Remember the Files

Here's how I'm currently thinking about the configuration files:

File	What it controls
`app.php`	General application settings
`auth.php`	Authentication
`broadcasting.php`	Real-time events
`cache.php`	Caching
`concurrency.php`	Concurrent execution
`cors.php`	Cross-origin requests
`database.php`	Database connections
`filesystems.php`	File storage
`hashing.php`	Password/data hashing
`images.php`	Image processing
`logging.php`	Application logging
`mail.php`	Email
`queue.php`	Background jobs
`services.php`	Third-party services
`session.php`	Sessions
`view.php`	Blade views

Coming From Django?

Since I also work with Django, comparing Laravel with Django helps me understand the concepts.

The two frameworks aren't identical, but there are some useful similarities:

Laravel	Django
`.env`	Environment variables / `.env`
`config/app.php`	`settings.py`
`config/database.php`	`DATABASES`
`config/auth.php`	Authentication configuration
`config/filesystems.php`	Media/storage configuration
`config/mail.php`	Email settings
`config/cache.php`	`CACHES`
`config/logging.php`	`LOGGING`
`config/session.php`	Session configuration

Coming from Django, this comparison makes Laravel's structure a little easier for me to understand.

Final Thoughts

I'm learning that I don't need to understand every Laravel configuration file immediately.

The important thing is to understand why the files exist and when I might need them.

For backend development, the configuration files I'll probably interact with most often are:

database.php
auth.php
app.php
cors.php
logging.php
queue.php
cache.php
services.php

The more I build applications with Laravel, the more these configurations will start making sense through practical use.

I'm sharing this as part of my Laravel learning journey. If you're also learning Laravel, hopefully this gives you a simple starting point for understanding what's inside the config directory.

And if I've misunderstood anything, feel free to correct me in the comments. That's part of learning.

Connecting Laravel to PostgreSQL on Ubuntu: A Beginner's Guide

Vincent Tommi — Fri, 28 Aug 2026 12:55:12 +0000

If you're building your first Laravel application and trying to connect it to PostgreSQL, you might run into an error like this:

SQLSTATE[08006] [7] connection to server at "127.0.0.1", port 5432 failed:
FATAL: password authentication failed for user "postgres"

I ran into this while setting up a fresh Laravel application on Linux.

At first, I thought the problem was with Laravel, but the error actually tells us something useful: Laravel can reach PostgreSQL, but PostgreSQL is rejecting the database credentials.

In this article, I'll walk through how to connect Laravel to PostgreSQL on Ubuntu, create a dedicated database user, configure Laravel, and troubleshoot authentication errors.

Prerequisites

Before starting, make sure you have the following installed:

PHP
Composer
Laravel
PostgreSQL

You can check your PHP installation with:

php -v

Check Composer:

composer -V

And check PostgreSQL:

psql --version

You can also check whether PostgreSQL is running:

sudo systemctl status postgresql

If PostgreSQL isn't running, start it with:

sudo systemctl start postgresql

Create a Laravel Project

If you don't already have a Laravel project, you can create one using Composer:

composer create-project laravel/laravel example-app

Then move into the project:

cd example-app

Laravel stores environment-specific configuration in the .env file.

Configure Laravel for PostgreSQL

Open your .env file:

nano .env

For PostgreSQL, your database configuration should look like this:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=laravel
DB_USERNAME=laravel_user
DB_PASSWORD=your_password

There are a few important things to notice here.

PostgreSQL uses port 5432

PostgreSQL normally runs on:

MySQL commonly uses:

So don't use 3306 if you're connecting Laravel to PostgreSQL.

Laravel uses `pgsql`

For PostgreSQL, Laravel expects:

DB_CONNECTION=pgsql

Not:

DB_CONNECTION=postgres

What Does the Authentication Error Mean?

When I first tested the connection, I used:

psql -h 127.0.0.1 -U postgres -d postgres -W

PostgreSQL returned:

FATAL: password authentication failed for user "postgres"

This can be confusing when you're new to PostgreSQL.

The important thing is that PostgreSQL is actually responding.

The problem isn't that PostgreSQL can't be found.

Instead, PostgreSQL is saying:

I found the server and the user, but the password provided for that user is incorrect.

So changing the host or port won't fix this particular error.

Create a Dedicated PostgreSQL User

Rather than using the PostgreSQL administrator account for Laravel, I decided to create a separate user specifically for the application.

This is a better approach because your application doesn't need to connect using a PostgreSQL superuser.

First, access PostgreSQL through the system postgres account:

sudo -u postgres psql

You should see something similar to:

postgres=#

You're now inside the PostgreSQL command-line interface.

Create the Laravel User

Create a new PostgreSQL user:

CREATE USER laravel_user WITH PASSWORD 'your_secure_password';

For example:

CREATE USER laravel_user WITH PASSWORD 'myStrongPassword123';

For a real application, use a strong password and don't commit it to Git.

Create the Laravel Database

Now create the database and make the new user its owner:

CREATE DATABASE laravel OWNER laravel_user;

You can check your databases with:

\l

You should see the laravel database in the list.

Grant Permissions

Connect to the Laravel database:

\c laravel

Then grant the user access to the public schema:

GRANT ALL ON SCHEMA public TO laravel_user;

You can also grant privileges on existing tables and sequences:

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO laravel_user;

GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO laravel_user;

For future tables and sequences, you can set default privileges:

ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT ALL ON TABLES TO laravel_user;

ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT ALL ON SEQUENCES TO laravel_user;

When you're finished, exit PostgreSQL:

\q

Test the PostgreSQL Connection

Before going back to Laravel, it's a good idea to test the database connection directly.

Run:

psql -h 127.0.0.1 -U laravel_user -d laravel -W

Enter the password you created earlier.

If the credentials are correct, you should get:

laravel=>

This is an important troubleshooting step.

If the connection works here, you know PostgreSQL is correctly configured and you can focus on Laravel if another problem occurs.

Update Laravel's `.env`

Now configure Laravel with the new PostgreSQL user:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=laravel
DB_USERNAME=laravel_user
DB_PASSWORD=myStrongPassword123

Replace the password with the one you actually created.

Clear Laravel's Configuration Cache

Laravel may still have the old database configuration cached.

Run:

php artisan config:clear

You should see something similar to:

INFO  Configuration cache cleared successfully.

Run the Migrations

Now run:

php artisan migrate

If everything is configured correctly, Laravel should connect to PostgreSQL and create its migration tables.

You should see output similar to:

INFO  Preparing database.

Creating migration table ................................ DONE

INFO  Running migrations.

0001_01_01_000000_create_users_table .................... DONE
0001_01_01_000001_create_cache_table .................... DONE
0001_01_01_000002_create_jobs_table ..................... DONE

At this point, Laravel is successfully connected to PostgreSQL.

Understanding the Setup

The final setup looks like this:

Laravel Application
        |
        | PostgreSQL connection
        ↓
127.0.0.1:5432
        |
        ↓
PostgreSQL
        |
        ↓
laravel_user
        |
        ↓
laravel database

And your .env contains:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=laravel
DB_USERNAME=laravel_user
DB_PASSWORD=your_password

Common Mistakes

1. Using the MySQL port

Don't use:

DB_PORT=3306

for PostgreSQL.

Use:

DB_PORT=5432

2. Using the wrong connection name

Don't use:

DB_CONNECTION=postgres

Use:

DB_CONNECTION=pgsql

3. Using `root` as the PostgreSQL username

If you're coming from MySQL, you might be used to:

DB_USERNAME=root

PostgreSQL commonly has an administrative user called:

postgres

However, your Laravel application doesn't need to use the administrator account.

A dedicated user such as:

laravel_user

is a better choice.

4. Forgetting to clear Laravel's configuration

If you change your .env file and Laravel continues using the old configuration, run:

php artisan config:clear

Then try:

php artisan migrate

5. Not testing PostgreSQL separately

If Laravel gives you a database connection error, test PostgreSQL directly first:

psql -h 127.0.0.1 -U laravel_user -d laravel -W

If this fails, the problem is probably with PostgreSQL, the username, password, database, or permissions.

If it succeeds, then you can focus on Laravel's configuration.

Troubleshooting Checklist

Before running:

php artisan migrate

make sure:

PostgreSQL is running
The laravel database exists
laravel_user exists
The password is correct
The user has access to the database
PostgreSQL is running on port 5432
DB_CONNECTION=pgsql
Laravel's configuration cache has been cleared

Then run:

php artisan config:clear
php artisan migrate

Final Thoughts

Connecting Laravel to PostgreSQL for the first time can be confusing because there are several different pieces involved: Laravel, PHP, PostgreSQL, users, passwords, databases, ports, permissions, and environment variables.

The biggest lesson I learned from this setup is that understanding the error is better than randomly changing configuration until something works.

For example, when you see:

FATAL: password authentication failed for user "postgres"

you already know that PostgreSQL is reachable. The problem is authentication.

From there, you can test PostgreSQL independently, create a dedicated application user, verify the credentials, and then connect Laravel.

Hopefully this guide helps another beginner who is setting up Laravel and PostgreSQL on Ubuntu for the first time.

When Ubuntu Keyboard Shortcuts Stop Working: A Systematic GNOME Troubleshooting Guide

Vincent Tommi — Fri, 14 Aug 2026 09:23:03 +0000

Have you ever experienced a strange Ubuntu problem where your keyboard works perfectly, but your keyboard shortcuts suddenly stop working?

That happened to me recently.

I could type normally. Every key worked as expected. But keyboard shortcuts such as Alt + Tab, Ctrl + C, Ctrl + V, and other combinations were not behaving as expected.

At first, this looked like a keyboard problem.

It wasn't.

The keyboard was working properly. The problem was with the way Ubuntu/GNOME was handling shortcuts.

This article explains how I approached the problem and the commands that can help diagnose similar issues.

1. First, determine whether the keyboard or shortcuts are the problem

The first mistake you can make when keyboard shortcuts stop working is assuming that the keyboard is broken.

Before changing anything, test normal typing.

Open a terminal and run:

echo "keyboard test"

If you can type normally, the keyboard hardware and basic input are probably working.

This gives us an important distinction:

Keyboard input works
        ↓
Normal typing works
        ↓
Keyboard shortcuts fail
        ↓
Investigate the desktop/input configuration

This is much better than immediately reinstalling drivers or changing system configurations.

2. Test different types of shortcuts

Not all keyboard shortcuts are handled by the same component.

For example:

Application shortcuts

These include:

Ctrl + C
Ctrl + V
Ctrl + Z
Ctrl + A

These are generally handled by the application.

Desktop/window-manager shortcuts

Examples include:

Alt + Tab
Super
Ctrl + Alt + T

These can be handled by GNOME, the window manager, or the desktop environment.

This distinction is important when troubleshooting.

If Ctrl + C works in one application but Alt + Tab doesn't work, the problem may be related specifically to GNOME's global shortcuts.

3. Check GNOME's shortcut configuration

Ubuntu's GNOME desktop stores many shortcut configurations through gsettings.

For example, you can inspect the shortcut responsible for switching windows:

gsettings get org.gnome.desktop.wm.keybindings switch-windows

You may see something similar to:

['<Alt>Tab']

This tells you that GNOME has Alt + Tab configured as a window-switching shortcut.

You can also check application switching:

gsettings get org.gnome.desktop.wm.keybindings switch-applications

If the expected shortcut is missing or has been changed, GNOME's shortcut configuration may be the source of the problem.

4. Check GNOME Shell shortcuts

Some shortcuts are handled directly by GNOME Shell.

For example:

gsettings get org.gnome.shell.keybindings show-applications

This can help determine whether shortcuts involving the Super key are configured correctly.

The key idea is that instead of guessing, we can inspect the configuration directly.

5. Check Ubuntu's graphical shortcut settings

You can also inspect shortcuts through the GUI.

Go to:

Settings → Keyboard → View and Customize Shortcuts

From there, look at the configured shortcuts for:

Windows
Navigation
Applications
System
Custom shortcuts

This is useful because it allows you to verify the configuration without using the terminal.

6. Check accessibility features

Another easy-to-miss cause is accessibility settings.

Ubuntu provides features such as:

Sticky Keys
Slow Keys
Bounce Keys

If these have been enabled accidentally, keyboard behavior can become confusing.

Go to:

Settings → Accessibility → Typing

and check whether these features are enabled.

If you don't intentionally use them, disable them and test the shortcuts again.

7. Check GNOME extensions

GNOME extensions can also modify or intercept keyboard behavior.

To see installed extensions:

gnome-extensions list

If you suspect an extension is causing the problem, temporarily disable it:

gnome-extensions disable EXTENSION_NAME

Then test the shortcuts again.

This is particularly useful if the problem started after installing or updating a GNOME extension.

8. Check whether Ubuntu is detecting the key combinations

If the configuration appears correct but shortcuts still don't work, the next step is to determine whether the desktop is actually receiving the key events.

One useful tool is wev.

Install it with:

sudo apt install wev

Then run:

wev

Press keys such as:

Ctrl
Alt
Shift
Super

and combinations such as:

Ctrl + C
Alt + Tab

This helps determine whether the underlying input events are reaching the desktop environment.

This is an important debugging principle:

Don't just ask whether a feature works. Determine which layer of the system is failing.

For keyboard shortcuts, the layers can look roughly like:

Keyboard
   ↓
Linux input system
   ↓
Desktop environment
   ↓
GNOME Shell / Window Manager
   ↓
Application
   ↓
Shortcut

Finding the failing layer makes troubleshooting much easier.

9. Don't immediately reset your configuration

One tempting solution is to reset GNOME configuration immediately.

For example:

dconf reset -f /org/gnome/desktop/wm/keybindings/

This can be useful in some situations, but I wouldn't make it the first step.

Why?

Because resetting configuration can remove custom settings that you intentionally created.

A better troubleshooting process is:

1. Confirm the keyboard works
2. Identify which shortcuts fail
3. Determine whether the problem is global or application-specific
4. Inspect GNOME shortcut configuration
5. Check accessibility settings
6. Check GNOME extensions
7. Inspect keyboard events
8. Reset configuration only if necessary

This approach minimizes unnecessary changes.

10. What I learned from the problem

The most important lesson wasn't actually the command that fixed the shortcuts.

It was the troubleshooting methodology.

When something stops working, don't immediately assume the most obvious component is broken.

In my case:

Keyboard works
      ↓
Typing works
      ↓
Shortcuts don't work
      ↓
Keyboard hardware is probably not the problem
      ↓
Investigate GNOME
      ↓
Inspect shortcut configuration
      ↓
Test the input events
      ↓
Identify the configuration/problem layer

This approach can be applied to much more than keyboard shortcuts.

The same principle applies when debugging:

Django applications
APIs
databases
Docker
networking
Linux services
authentication
frontend applications

Instead of asking:

"What can I reinstall?"

Ask:

"Which layer is actually failing?"

Conclusion

A keyboard that works normally while its shortcuts fail doesn't necessarily indicate a hardware problem.

On Ubuntu/GNOME, keyboard shortcuts involve several layers of configuration, including GNOME Shell, the window manager, applications, accessibility settings, and extensions.

The best approach is therefore to troubleshoot systematically rather than immediately resetting or reinstalling components.

The general debugging pattern is simple:

Observe
   ↓
Isolate
   ↓
Inspect
   ↓
Test
   ↓
Fix
   ↓
Verify

That mindset is useful far beyond Linux desktop troubleshooting.

Sometimes the best debugging tool isn't a complicated command.

It's knowing which layer to investigate first.

Git Merge vs Git Rebase: Understanding the Difference

Vincent Tommi — Thu, 16 Jul 2026 17:47:59 +0000

When collaborating on a Git project, one question comes up repeatedly:

Should you use git merge or git rebase?

The truth is that both commands achieve the same end goal—they integrate changes from one branch into another. The key difference lies in how they handle your project's commit history.

Let's break it down.

What is `git merge`?

git merge combines the histories of two branches while preserving the original branch structure.

Imagine you create a feature branch from main, work on a new feature, and meanwhile other developers continue making changes to main. When you're ready to integrate your work, running:

git checkout main
git merge feature-branch

creates a merge commit if both branches have diverged.

Your Git history will clearly show:

Where the feature branch was created.
The commits made on both branches.
The point where the branches were merged back together.

This makes it easy to understand the evolution of a project, especially in teams where multiple developers are working simultaneously.

Advantages of Merge

Preserves the complete project history.
Never rewrites existing commits.
Safe for shared branches.
Makes collaboration easier because everyone keeps the same commit history.

What is `git rebase`?

git rebase takes a different approach.

Instead of creating a merge commit, Git replays your feature branch commits on top of the latest version of the target branch.

For example:

git checkout feature-branch
git rebase main

Git temporarily removes your feature commits, updates your branch with the latest commits from main, and then reapplies your work as new commits.

The result is a clean, linear commit history that looks as if your work was built directly on top of the latest main.

This makes the project history much easier to read.

The Catch with Rebasing

While rebasing creates a cleaner history, it comes with an important tradeoff.

Because Git recreates your commits during the rebase process, each commit receives a new SHA (commit ID).

If you've already pushed those commits to a shared remote branch, rebasing changes history. You'll typically need to force-push your branch:

git push --force-with-lease

This can cause problems for teammates who already based their work on the original commits.

That's why one of the most common Git recommendations is:

Never rebase a branch that other people are actively using.

When Should You Use Merge?

git merge is usually the better choice when:

Working on shared branches.
Collaborating with multiple developers.
Preserving the full history is important.
You want to avoid rewriting commits.

Many teams configure pull requests to use merge commits because they're predictable and safe.

When Should You Use Rebase?

git rebase shines when:

You're working on your own feature branch.
You want to clean up your commit history before opening a pull request.
You prefer a linear Git history.
You haven't shared your branch with others.

A common workflow is to regularly rebase your feature branch onto the latest main, then merge it once it's ready.

Merge vs Rebase at a Glance

Git Merge	Git Rebase
Preserves branch history	Creates a linear history
Creates a merge commit	Does not create a merge commit
Safe for shared branches	Rewrites commit history
Keeps existing commit IDs	Generates new commit IDs
Great for collaboration	Great for cleaning up personal work

Which One Should You Choose?

There isn't a universally "better" command.

If you're collaborating with others and want to preserve history, use git merge.
If you're polishing your own feature branch before merging, use git rebase.

Many development teams actually use both:

Rebase while working locally to keep your branch clean.
Merge when integrating into shared branches to preserve collaboration history.

Understanding the strengths of each command will help you choose the right tool for the situation.

How to Reset a Django Admin Password Using the Django Shell

Vincent Tommi — Wed, 10 Dec 2025 04:42:03 +0000

Forgetting the password for your Django admin account can be frustrating, but resetting it is quick and straightforward using the Django shell. This method works even if you no longer have access to the admin interface and doesn't require any additional packages.

Step-by-Step Guide

Open the Django shell In your project directory (where manage.py is located), run the following command:

python manage.py shell

This will start an interactive Python shell with your Django project loaded.

Reset the password In the shell, execute the following code:

from django.contrib.auth.models import User

# Replace 'admin' with the actual username of the admin account
user = User.objects.get(username='admin')

# Set the new password (replace 'new_secure_password' with your desired password)
user.set_password('new_secure_password')

# Save the changes
user.save()

Important notes:

Use the correct username (it’s usually admin, but it could be something else if you created a custom superuser).
set_password() automatically hashes the password for you—never use user.password = 'plain_text' as that would store the password unhashed.

Exit the shell Once the password is updated, simply type:

exit()

or press Ctrl+D (on Unix-like systems) or Ctrl+Z then Enter (on Windows).

That’s it! You can now log in to the Django admin interface (/admin/) using the username and the new password you just set.
Bonus: Resetting Password for Any User (Not Just Admin)
The same method works for any user in your database. Just change the username to the correct one

user = User.objects.get(username='john_doe')
user.set_password('another_secure_password')
user.save()

Troubleshooting Tips

“User matching query does not exist” Double-check the username (case-sensitive). You can list all users with:

User.objects.all()

Using a custom User model If your project uses a custom user model (e.g., CustomUser), replace User with your model:


from myapp.models import CustomUser
user = CustomUser.objects.get(username='admin')

Conclusion

With just a few lines of code, you can regain access to your Django admin account in seconds. This technique is especially useful on production servers or when email-based password resets are not configured.

How to Work on a Team with Git & GitHub Without Breaking Everything

Vincent Tommi — Tue, 09 Dec 2025 18:44:57 +0000

The Definitive Guide Every Engineering Team Should Adopt

Stop fighting over Git.
Stop breaking main.
Stop losing work. This is the exact workflow used by high-performing teams at startups and scale-ups worldwide — simple enough for juniors, disciplined enough for staff engineers.

The Core Workflow (6 Commands to Rule Them All)

# 1. Safely stash your in-progress changes
git stash push -m "wip: halfway through payment UI"

# 2. Fetch and integrate the latest main
git pull origin main --rebase    # preferred over merge for clean history

# 3. Re-apply your work on top
git stash pop                    # resolves conflicts early

# 4. Stage changes
git add .

# 5. Write a meaningful commit message
git commit -m "feat: add real-time donation progress bar with percentage"

# 6. Push to remote
git push origin HEAD

Daily & Hourly Discipline (Do This Religiously)

git stash
git pull origin main --rebase
git stash pop

Do this:

First thing in the morning
Before starting any new task
After a teammate announces a hotfix
Before pushing any commit

This single habit eliminates 95% of merge conflicts

Pro-Level One-Liner (Add to Your Shell)

# ~/.zshrc or ~/.bash_profile
alias sync="git stash push -m 'autosave $(date +%H:%M)' \
    && git pull origin main --rebase \
    && git stash pop"

Now just run:

sync

Recommended Branching Strategy (Safe + Fast)

Task Type	Branch Name Example	Workflow
Hotfix / Urgent	`hotfix/double-payment`	Direct to main (with PR)
Feature (>1 hour)	`feat/donation-progress-bar`	Branch → PR → Review → Merge
Bugfix	`fix/invalid-goal-calculation`	Branch → PR
Refactor / Chore	`refactor/extract-payment-service`	Branch → PR

# Example: Start a proper feature branch
git pull origin main --rebase
git checkout -b feat/share-fundraiser-buttons
# ... work ...
git add .
git commit -m "feat: add social sharing for fundraisers"
git push -u origin feat/share-fundraiser-buttons
# → Open Pull Request on GitHub

Conventional Commits (Your Team Will Thank You)
Always use this format — enables auto-changelogs and clear history:

feat:     Add new feature
fix:      Bug fix
docs:     Documentation only changes
style:    Formatting, missing semicolons, etc.
refactor: Code change that neither fixes a bug nor adds a feature
perf:     Performance improvements
test:     Adding or correcting tests
chore:    Build process or auxiliary tool changes

Examples:

git commit -m "feat: add fundraiser short link sharing"
git commit -m "fix: prevent negative donation amounts"
git commit -m "refactor: extract donation validation logic"

Conflict Resolution (When stash pop Fails)

git stash pop
# → Conflict in payments/views.py

# Fix the <<< === >>> markers manually
# Then:
git add payments/views.py
git commit  # no -m needed, Git creates merge commit message

Golden Rules Every Team Member Must Follow

1 Never commit directly to main (except hotfixes with approval)
2 Always sync before starting work
3 Always write descriptive commit messages
4 Always push feature branches and open PRs
5 Never force push main (or any shared branch)
6 Rebase locally, merge on GitHub via PR (keeps history clean)

Quick Reference Cheat Sheet (Pin This)

# Stay in sync (run often)
sync                    # your alias
# or manually:
git stash && git pull --rebase origin main && git stash pop

# Ship completed work
git add .
git commit -m "type(scope): description"
git push

# Start new work safely
git pull --rebase origin main
git checkout -b feat/your-feature-name

# Emergency hotfix
git checkout main
git pull --rebase origin main
git checkout -b hotfix/critical-bug

Final Words
I’ve been on teams that lost entire days to merge conflicts.
I’ve been on teams that deployed 20 times per day with zero drama.
The difference was always this: discipline around syncing and branching.
Adopt this workflow today.
Enforce it in code reviews.
Put it in your onboarding docs.
Your future self — and every teammate who’s ever screamed at Git — will thank you.
Now go forth and collaborate like professionals.
Saved you from at least 47 rage-quits in 2025.
You’re welcome.

DEV Community: Vincent Tommi

Django vs Laravel: Understanding Models and Database Migrations

1. The Django Approach

2. The Laravel Approach

3. Where Does the Laravel Model Come In?

4. Laravel Can Create Both at Once

Model

Migration

5. Django vs Laravel: The Key Difference

6. Example: Adding a Column

Django

Laravel

7. Another Important Difference: Migration Detection

8. Relationships Are Also Different

Django

Laravel

9. The Commands Side by Side

10. My Laravel Workflow

Step 1: Create the migration

Step 2: Define the database structure

Step 3: Run the migration

Step 4: Create the model

Step 5: Configure the model

Step 6: Add relationships

11. What I Have Learned Moving from Django to Laravel

Conclusion

How to Fix the Ondřej PHP PPA 404 Error on Ubuntu

How to Fix the Ondřej PHP PPA 404 Error on Ubuntu

Understanding the Error

Step 1: Check Your Ubuntu Version

Step 2: Check the Ondřej PHP Repository

Step 3: Remove the Unsupported Repository

Step 4: Run apt update Again

Step 5: Check for Other Ondřej PHP Entries

Does Removing the Repository Remove PHP?

Check Available PHP Packages

Why You Shouldn't Ignore the Error

Conclusion

Fixing Laravel PHP 8.5 Deprecation Warnings: A Practical Dependency Debugging Guide

How to Set Up GitHub SSH on Ubuntu: A Beginner-Friendly Guide

What Is SSH?

Step 1: Generate an SSH Key

The important part

A Mistake I Made

Step 2: Check Where Your Key Was Saved

Step 3: Move the Key to the .ssh Directory

Step 4: Set the Correct Permissions

Step 5: Start the SSH Agent

Step 6: Add Your SSH Key to the Agent

Step 7: Get Your Public Key

Important Security Note

Private key

Public key

Step 8: Add the Public Key to GitHub

Step 9: Test the GitHub SSH Connection

Step 10: Use SSH When Cloning Repositories

What If I Already Have a Git Repository?

Common Mistake: "No Such File or Directory"

Useful Commands

Generate a key

Check SSH files

Start SSH agent

Add your key

List keys loaded into the agent

Display public key

Test GitHub

Check Git remote

Change an HTTPS remote to SSH

Final Thoughts

Laravel for Django Developers: A Practical Guide to Laravel Architecture

1. Django vs Laravel: The Mental Translation

2. The Laravel Request Lifecycle

3. Laravel Project Structure

4. Routes: Django's urls.py vs Laravel Routes

5. Route Parameters

6. Controllers: Django Views vs Laravel Controllers

7. Models and Eloquent

8. Creating Models

9. Mass Assignment

10. Migrations

Step 4: Run `apt update` Again

Step 3: Move the Key to the `.ssh` Directory

4. Routes: Django's `urls.py` vs Laravel Routes

11. Artisan: Laravel's `manage.py`

Fixing `database.php`

What is the `config` folder?

1. `app.php`

2. `auth.php`

3. `broadcasting.php`