The fix is straightforward once you understand what is missing: a trusted CA certificate bundle.

Why does cURL error 60 happen?

PHP uses cURL to make HTTPS requests. cURL checks server certificates against a list of trusted Certificate Authorities (CA). If PHP cannot find that list, it refuses the connection for security reasons. So the real issue is not your code, but your environment.

Fix on Windows (XAMPP / WAMP / PHP standalone)

Step 1: Download the CA bundle

Use the official curl project CA bundle:
https://curl.se/ca/cacert.pem

Save it somewhere stable, for example:

C:\xampp\php\extras\ssl\cacert.pem

Step 2: Edit php.ini

Open php.ini and find this line:

;curl.cainfo =

Uncomment and set the path:

curl.cainfo = "C:\xampp\php\extras\ssl\cacert.pem"

Also locate:

;openssl.cafile=

Set it too:

openssl.cafile="C:\xampp\php\extras\ssl\cacert.pem"

Restart Apache or PHP.

That’s it. cURL will now trust valid SSL certificates.

Fix on Linux (Ubuntu, Debian, CentOS, etc.)

Linux usually includes default CA packages. Install or update them:

Ubuntu / Debian

sudo apt-get update
sudo apt-get install ca-certificates
sudo update-ca-certificates

CentOS / RedHat / AlmaLinux

sudo yum install ca-certificates
sudo update-ca-trust force-enable
sudo update-ca-trust extract

After installation, PHP will automatically use the system’s CA store.

Using HTTPS inside Docker or CI

Many CI images are trimmed and do not include SSL bundles.

Simply install them:

apt-get update
apt-get install -y ca-certificates

Then rebuild your image.

Temporary workaround (not recommended)

You will see developers do this:

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

It disables SSL verification and opens huge security risks.
Only use this for debugging local issues, never in production.

Quick checklist

If you still get the same error:

• Did you restart Apache, Nginx, or PHP-FPM?
• Is your php.ini the CLI one or the web one?
• Are you editing the correct PHP version (7.4 vs 8.2)?
• Is the CA file readable (correct path, no typos)?

The post PHP cURL error 60: SSL certificate problem – Windows & Linux Fix appeared first on Devnote.

In simple terms, this error means: you are treating a string like an array.

• 1. Classic real world example: form data overwritten
• 2. JSON decode returning string instead of array
• 3. Database value overriding an array
• 4. Passing string into a function that expects array
• 5. Safely checking types in PHP 8.3
• 6. Quick checklist when you see this error

1. Classic real world example: form data overwritten

Imagine you receive a form and accidentally overwrite an array with a string:

$data = $_POST['user'];      // you expect an array
$data = trim($data);         // now $data is a string

echo $data['email'];         // ❌ Fatal error

$data becomes a string after trim, so $data['email'] tries to use a string offset as an array.

Fix

Keep array and string variables separate or avoid overwriting:

$user = $_POST['user'] ?? [];

$userEmail = isset($user['email']) ? trim($user['email']) : null;

Or, if the form sends flat fields:

$email = isset($_POST['email']) ? trim($_POST['email']) : null;

2. JSON decode returning string instead of array

Another real case: API or database returns JSON, but you double encode it or forget the second parameter in json_decode.

$json = getOption('settings');   // already a JSON string
$settings = json_decode($json);  // returns stdClass by default

echo $settings['theme'];         // ❌ Fatal error

json_decode without the second parameter returns an object. Accessing it with ['theme'] treats it like an array.

Fix

Decode as an associative array:

$settings = json_decode($json, true); // true = associative array

$theme = $settings['theme'] ?? 'default';

Or keep it as an object and use:

$theme = $settings->theme ?? 'default';

3. Database value overriding an array

You store settings as an array but later load a single column as a string into the same variable:

$config = [
    'mail' => [
        'host' => 'smtp.example.com',
    ],
];

$config = $pdo->query('SELECT value FROM config WHERE name="mail"')->fetchColumn();
// now $config is a string from DB

echo $config['host']; // ❌ Fatal error

Fix

Use different variables and convert the DB result back to an array if needed:

$mailConfigJson = $pdo->query(...)->fetchColumn();
$mailConfig = json_decode($mailConfigJson, true) ?? [];

echo $mailConfig['host'] ?? 'localhost';

4. Passing string into a function that expects array

Real world bug from helper functions:

function addDefaultRoles(array $roles): array
{
    $roles[] = 'viewer';
    return $roles;
}

$rolesFromDb = 'admin';        // bug: should be array
$roles = addDefaultRoles($rolesFromDb); // ❌ Type + string offset errors

PHP may complain that it cannot use string offset internally while trying to push onto the array.

Fix

Normalise types before calling:

$rolesFromDb = $rolesFromDb ? explode(',', $rolesFromDb) : [];

$roles = addDefaultRoles($rolesFromDb);

Or enforce types at the boundary of your application.

5. Safely checking types in PHP 8.3

To avoid this kind of fatal error in new code:

• Use is_array() before accessing offsets.
• Use the null coalescing operator (??) to provide defaults.
• Add strict types and proper type hints.

Example:

declare(strict_types=1);

function getUserEmail(array $user): ?string
{
    return isset($user['email']) ? trim((string) $user['email']) : null;
}

$user = $_POST['user'] ?? [];
$email = getUserEmail($user);

Now if $user is not an array, PHP will throw a TypeError at the function boundary instead of failing deep inside your code.

6. Quick checklist when you see this error

• Look at the variable just before you use $var['key'].
• var_dump or dd($var) to see its actual type and value.
• Stop overwriting arrays with strings in the same variable.
• Decode JSON with json_decode($json, true) when you want arrays.
• Normalise DB and request data as arrays before passing to functions.
• Add type hints and strict types in new PHP 8.3 projects.

Once you treat strings and arrays consistently, this error disappears and your code becomes much easier to reason about in real applications.

The post PHP 8.3 Fatal Error: Cannot use string offset as an array – Real World Case appeared first on Devnote.

Let’s fix that safely.

1. The key setting: client_max_body_size

Nginx controls max request size with client_max_body_size. If it is missing, the default is usually 1 MB. That is tiny for modern uploads, so large images or videos will be blocked.

You can set it in:

• nginx.conf (global)
• Inside an http, server, or location block

Example, for a single site:

server {
    server_name example.com;
    client_max_body_size 64M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Choose a size that fits your needs, like 20M, 64M, 100M, or more for big video uploads.

2. Reload Nginx after changing config

After editing the config file:

sudo nginx -t

If it says syntax is ok, reload:

sudo systemctl reload nginx

or on some systems:

sudo service nginx reload

Now Nginx accepts larger requests.

3. Make sure PHP upload limits match

If you only change Nginx, PHP might still reject large uploads with errors like:

POST Content-Length of X bytes exceeds the limit of Y bytes

Check your php.ini (or .user.ini on shared hosting) and set:

upload_max_filesize = 64M
post_max_size = 64M

Rules of thumb:

• post_max_size ≥ upload_max_filesize
• Both should be ≤ Nginx client_max_body_size

After editing, restart PHP-FPM:

sudo systemctl restart php8.3-fpm

(adjust version to your PHP version).

4. Put the directive in the right place

For per-site limits, use the server block for that domain:

server {
    server_name media.example.com;
    client_max_body_size 200M;
    ...
}

If you put client_max_body_size inside a location that does not match your upload URL, Nginx will still use the low default and return 413.

For a global setting, you can place it in the http block in nginx.conf:

http {
    client_max_body_size 64M;
    ...
}

5. Example for WordPress / Laravel uploads

WordPress

Uploads typically go through /wp-admin/admin-ajax.php or /wp-admin/media-new.php. A simple per-site config:

server {
    server_name example.com;
    root /var/www/example.com/public;

    client_max_body_size 64M;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

Laravel

If your app handles uploads at /upload or through a controller, the same pattern applies:

server {
    server_name app.example.com;
    root /var/www/app/public;

    client_max_body_size 64M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

The app will then just see a normal file upload within PHP limits.

6. Shared hosting or panel-based servers (Plesk, cPanel, CyberPanel)

If you do not edit Nginx by hand:

• Look for an option like Client Max Body Size, Upload size, or Nginx directives in your panel.
• Many panels let you paste extra directives per domain, for example: client_max_body_size 64m;
• For PHP limits, change upload_max_filesize and post_max_size in the panel’s PHP settings.

7. Troubleshooting: still getting 413

If you still see 413 after changes:

1. Confirm you edited the correct vhost file for that domain.
2. Run nginx -T | grep client_max_body_size to see what values are actually active.
3. Clear any reverse proxy cache or restart any front-facing proxy in front of Nginx (less common).
4. Make sure there are no older client_max_body_size directives with smaller values overriding your new one in a more specific block.

8. Quick checklist

When Nginx responds with 413 Request Entity Too Large for uploads:

• Set client_max_body_size to a higher value (for example 64M) in the right server or http block.
• Reload Nginx after testing config with nginx -t.
• Increase upload_max_filesize and post_max_size in PHP to the same or slightly lower value.
• Restart PHP-FPM so new limits apply.
• For control panels, use their interface to adjust Nginx and PHP settings instead of manual files.

With Nginx and PHP aligned on upload size, images and videos will upload successfully without the 413 error.

The post How to Fix Nginx 413 Request Entity Too Large for Image & Video Uploads appeared first on Devnote.

1. The folder does not exist
2. PHP is not allowed to write there (permissions / owner)
3. The path you gave is wrong

Let’s go through how to fix this properly, both for plain PHP and Laravel.

1. Understand what file_put_contents needs

file_put_contents() is a simple wrapper around opening a file, writing, and closing it.

For this to succeed:

• Every directory in the path must exist
• The directory must be writable by the PHP user
• There must not be any open_basedir or hosting restrictions blocking that path

Example:

file_put_contents('/var/www/project/storage/logs/custom.log', 'Hello');

Directories required:

• /var
• /var/www
• /var/www/project
• /var/www/project/storage
• /var/www/project/storage/logs

The last one, logs, must be writable.

2. Fix for Laravel: storage and cache paths

Laravel writes a lot of files automatically:

• Logs: storage/logs/laravel.log
• Cache: storage/framework/cache
• Sessions: storage/framework/sessions
• Views: storage/framework/views

If any of these are not writable, you’ll see file_put_contents() errors.

2.1 Make sure folders exist

From your project root:

mkdir -p storage/logs
mkdir -p storage/framework/cache
mkdir -p storage/framework/sessions
mkdir -p storage/framework/views

Laravel normally creates them, but on a manual copy or deploy they can be missing.

2.2 Set correct permissions (Linux)

Typical safe defaults:

chmod -R 775 storage bootstrap/cache

And set the owner to your web server user:

chown -R www-data:www-data storage bootstrap/cache

Replace www-data with apache, nginx, www, or whatever your system uses.

You do not need 777 in almost all cases, and it is not safe on production.

3. Check the error message path carefully

The path in the error is your best clue.

Example:

file_put_contents(/var/www/project/storage/framework/cache/data/33/9f/...): 
Failed to open stream: No such file or directory

This tells you:

• PHP is trying to write to storage/framework/cache/data/...
• That subdirectory may not exist

Fix:

mkdir -p storage/framework/cache/data
chmod -R 775 storage/framework/cache

If the message shows something odd like:

file_put_contents(C:\xampp\htdocs\project\storage\app\public\images): 
failed to open stream: Is a directory

it means you passed a directory path instead of a full file path. See the next section.

4. Double check the actual path you pass in code

It’s easy to accidentally point to a folder instead of a file, or build a path incorrectly.

Bad:

$path = storage_path('app/public/images'); // directory
file_put_contents($path, $contents);      // will fail

Correct:

$path = storage_path('app/public/images/'.time().'.txt'); // file
file_put_contents($path, $contents);

Also make sure you are not mixing leading slashes:

// This drops the base path if you are not careful
$path = base_path().'/'.'/storage/logs/custom.log';

For Laravel, prefer helpers:

$path = storage_path('logs/custom.log');

In plain PHP, build paths like:

$base = __DIR__; // current script directory
$path = $base . '/storage/logs/custom.log';

5. Hosting and open_basedir restrictions

On shared hosting, PHP is often restricted to a specific folder using open_basedir.
If you try to write outside that allowed directory, file_put_contents() will fail even if permissions look fine.

You might see errors like:

open_basedir restriction in effect. File(/tmp/cache.txt) is not within the allowed path(s): (/home/username/:/tmp/)

Fix this by:

• Writing inside an allowed path (like /home/username/storage/...)
• Or changing open_basedir in php.ini, .user.ini, or the hosting panel (if allowed)

For Laravel on cPanel, writing inside storage/ and bootstrap/cache under your account home is usually safe.

6. Clearing Laravel cache after fixing permissions

Once you repair permissions and paths, it’s a good idea to clear cache so Laravel can rebuild things cleanly.

From project root:

php artisan config:clear
php artisan cache:clear
php artisan view:clear
php artisan route:clear
php artisan optimize:clear

If these commands previously failed with file_put_contents errors, they should now work.

7. Example: custom logging in Laravel with safe storage path

If you want to write a simple log file yourself:

$path = storage_path('logs/custom-info.log');

if (! file_exists(dirname($path))) {
    mkdir(dirname($path), 0755, true);
}

file_put_contents($path, '['.now().'] Hello from custom log'.PHP_EOL, FILE_APPEND);

This ensures the parent directory exists and appends safely.

8. Quick checklist

When you see file_put_contents(): Failed to open stream in storage or cache:

• Read the full error and note the exact path
• Confirm that every directory in the path exists
• For Laravel, make sure storage/ and bootstrap/cache exist and are writable
• Set permissions: chmod -R 775 storage bootstrap/cache (and chown to the web user)
• Ensure you are writing to a file, not a directory
• Check for open_basedir restrictions or weird absolute paths
• Clear Laravel caches after fixing permissions

Once paths and permissions are correct, file_put_contents() will quietly do its job and your logs, cache, and uploaded files will be written without errors.

The post PHP file_put_contents(): Failed to open stream in Storage and Cache – Permissions Fix Guide appeared first on Devnote.

The code did not change, only the folder. The usual culprit is Composer’s autoload files and namespaces that still point to the old structure.

Let’s go through what you should check and how to fix it cleanly.

1. How Composer autoload actually finds your classes

Composer reads composer.json and builds a file called vendor/autoload.php, plus some maps under vendor/composer/.

Most projects use PSR-4 autoloading like this:

"autoload": {
  "psr-4": {
    "App\\": "app/"
  }
}

This means:

• Classes under the App\ namespace live in the app/ directory.
• App\Services\PaymentService should be in app/Services/PaymentService.php.

If you move the project but keep this structure, everything should still work. Problems appear when:

• The path in composer.json no longer matches the real folder.
• You moved only part of the project.
• Autoload files are still cached for the old location.

So first step is always to refresh Composer’s autoload.

2. Run Composer dump-autoload after moving

As soon as you move the project to a new folder (or new server), log into that folder and run:

composer dump-autoload

or, for optimized production:

composer dump-autoload -o

This regenerates all autoload maps with the new absolute paths.

If composer is not available globally on shared hosting, use the one in your project:

php composer.phar dump-autoload -o

For many people, this alone fixes the “Class not found” errors.

3. Confirm your namespaces and file paths still match

If errors still appear, check the exact class mentioned in the error.

Example error:

Class "App\Services\PaymentService" not found

Questions to ask:

1. Does the file exist?
   • app/Services/PaymentService.php
2. Does the namespace inside that file match? <?php namespace App\Services; class PaymentService { // ... }
3. Is the filename exactly the same as the class (case sensitive on Linux)?
   • PaymentService.php containing class PaymentService

If the file is in a different directory after the move, update composer.json or move the file back to the correct PSR-4 path.

Example: custom folder

If you created a src folder and moved classes there, you must tell Composer:

"autoload": {
  "psr-4": {
    "App\\": "src/"
  }
}

Then run composer dump-autoload again.

4. Check you moved the entire vendor folder (or reinstall)

If you copied the project manually and skipped the vendor folder, nothing autoloads until dependencies are installed.

Inside the new project folder, run:

composer install

This recreates vendor/ and all autoload files based on composer.lock.

On slow shared hosting, this can take a bit longer, but it is the cleanest way to ensure everything matches the new environment.

5. Fix Laravel specific “Target class does not exist” problems

In Laravel, moving a project plus changing PHP versions or paths can cause route and container caches to point to the wrong place.

From the project root, run:

php artisan config:clear
php artisan cache:clear
php artisan route:clear
php artisan view:clear

Then regenerate autoload again:

composer dump-autoload -o

If the error is about a controller in routes:

use App\Http\Controllers\HomeController;

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

Verify:

• app/Http/Controllers/HomeController.php exists.
• Namespace at the top is namespace App\Http\Controllers;.
• Class name is class HomeController extends Controller.

Sometimes after moving, people rename folders (for example, Controllers to controllers), which breaks on Linux but not on Windows because of case sensitivity.

6. Paths hard coded in custom autoload or include statements

If you previously added manual includes like:

require '/old/path/to/app/Helpers/helpers.php';

they will break in the new environment.

Better approach is to let Composer autoload helper files:

In composer.json:

"autoload": {
  "psr-4": {
    "App\\": "app/"
  },
  "files": [
    "app/Helpers/helpers.php"
  ]
}

After adding this, run:

composer dump-autoload

Now helpers will load automatically, no absolute paths required.

7. Double check project root when using CLI

On a new server or folder, sometimes you run artisan or PHP scripts from the wrong directory. Composer then looks for vendor/autoload.php relative to that wrong place.

Always cd into the project root before running commands:

cd /var/www/new-folder/my-project
php artisan migrate
php artisan tinker

If you see errors like:

Warning: require(vendor/autoload.php): failed to open stream

you are probably not in the correct directory, or vendor/ is missing.

8. Common real-world scenarios and quick fixes

Scenario A: moved from /var/www/html to /var/www/project

Symptoms:

• “Class not found” on every request.

Fix:

1. cd /var/www/project
2. composer dump-autoload -o
3. Clear Laravel caches if using Laravel.

Scenario B: copied only app/ and resources/ to a new Laravel install

Symptoms:

• Some custom classes not found, especially services, Jobs, or Events.

Fix:

1. Make sure composer.json in the new project has the same autoload section as the old one.
2. Move any custom folders (like app/Services, app/Repositories) as well.
3. Run composer dump-autoload.

Scenario C: changed namespace but forgot to update routes or code

You renamed App to MyApp in composer.json:

"psr-4": {
  "MyApp\\": "app/"
}

but controllers still use namespace App\Http\Controllers;.

Fix: update namespaces in your PHP files to match MyApp\..., or revert the autoload config.

9. Quick checklist

When you see “Class not found” after moving a PHP or Laravel project:

• Run composer dump-autoload -o in the new folder.
• Confirm the class file exists where PSR-4 says it should.
• Make sure namespaces and filenames (case) are correct.
• Install or copy the vendor folder and run composer install if needed.
• For Laravel, clear config, route, view, and app caches.
• Remove any old absolute paths and let Composer autoload helpers and libraries.
• Always run artisan and PHP scripts from the actual project root.

Once Composer has fresh autoload files and your namespaces match the new directory layout, the “Class not found” errors stop and your moved project behaves like it did before.

The post PHP Class not found in Composer Autoload After Moving Project to New Folder appeared first on Devnote.

Let’s go through the most common situations and how to fix each one.

• 1. Adding numbers to non numeric values
• 2. Using + with arrays when you meant to merge
• 3. Concatenation vs addition: using + instead of .
• 4. Null values in arithmetic and concatenation
• 5. Objects used like numbers
• 6. Mixed data from JSON or database
• 7. Use strict types and type hints to catch issues early
• 8. Quick checklist when you see “Unsupported operand types” in PHP 8.3

1. Adding numbers to non numeric values

A very typical example is using + on values that are not numbers.

$a = "10";
$b = "ABC";

$result = $a + $b; // Fatal error in PHP 8.3

Here $b is a string that cannot be safely converted to a number, so PHP throws a fatal error.

Fix

Validate or cast your data before you perform arithmetic.

$a = "10";
$b = "ABC";

$a = (int) $a;
$b = is_numeric($b) ? (int) $b : 0;

$result = $a + $b;

Or, if you are getting values from a request or database, sanitize them early:

$qty  = (int) ($_POST['qty'] ?? 0);
$price = (float) ($_POST['price'] ?? 0);
$total = $qty * $price;

2. Using + with arrays when you meant to merge

Another common source of this error is treating arrays like numbers.

$user = ['name' => 'John'];
$extra = ['role' => 'admin'];

$result = $user + 5;          // unsupported operand types
$merged = $user + $extra;     // works, but not what many expect

Array plus array uses the keys from the left array. It is not the same as merge, and using non arrays on either side will crash.

Fix

Use array_merge when you want to combine arrays and never mix arrays with non arrays.

$user  = ['name' => 'John'];
$extra = ['role' => 'admin'];

$merged = array_merge($user, $extra);  // ['name' => 'John', 'role' => 'admin']

If a value might be null, cast it to an array:

$filters = $requestFilters ?? [];
$defaults = ['status' => 'active'];

$mergedFilters = array_merge($defaults, (array) $filters);

3. Concatenation vs addition: using + instead of .

When building strings quickly, it is easy to mix up + and ..

$name = "John";
$msg = "Hello " + $name;   // Fatal error

In PHP, + is numeric addition, . is string concatenation.

Fix

Use the dot operator for strings.

$name = "John";
$msg = "Hello " . $name;

If you really expect numbers, convert them:

$total = (int) $a + (int) $b;

4. Null values in arithmetic and concatenation

In many legacy apps a variable might be null and still get used in math. PHP 8.3 is less forgiving.

$discount = null;
$total = 100;
$final = $total - $discount;   // unsupported operand types in some cases

Fix

Normalize nulls before using them.

$discount = $discount ?? 0;
$final = $total - $discount;

Or use null coalescing assignment:

$discount ??= 0;
$final = $total - $discount;

For strings:

$title = null;
$label = 'Product: ' . ($title ?? 'N/A');

5. Objects used like numbers

If a function returns an object and you treat it like an integer or float, PHP will complain.

$price = $cart->getTotal();  // returns Money object

$grandTotal = $price + 10;   // Fatal error: unsupported operand types

Fix

Decide which value you want from the object. Many value objects have methods like getAmount().

$price = $cart->getTotal();      // Money object
$grandTotal = $price->getAmount() + 10;

If this is your own class, consider adding helper methods or converting it to a primitive explicitly.

6. Mixed data from JSON or database

When you decode JSON or fetch rows from the database, all values may come through as strings. Then this kind of code appears:

$row = [
    'qty' => '3',
    'price' => 'abc',  // corrupted data
];

$total = $row['qty'] * $row['price'];  // fatal

Fix

Validate and cast before using them.

$qty   = (int) ($row['qty'] ?? 0);
$price = (float) ($row['price'] ?? 0);

$total = $qty * $price;

Consider centralizing this logic in DTOs or model accessors, so you do not repeat casting everywhere.

7. Use strict types and type hints to catch issues early

The best long term fix is to be explicit about types.

At the top of your PHP files you can enable strict mode:

<?php
declare(strict_types=1);

Then use type hints:

function calculateTotal(int $qty, float $price): float
{
    return $qty * $price;
}

If you accidentally pass an array or string that is not numeric, PHP will throw a helpful TypeError before you get to the unsupported operand error.

In Laravel or other frameworks, add types to your methods, DTOs, and models wherever possible.

8. Quick checklist when you see “Unsupported operand types” in PHP 8.3

• Look at the exact line and see which operator is being used (+, -, *, ., etc.).
• Dump or var_dump the variables to check their actual types.
• Do not mix arrays with numbers or strings when using +.
• Use . for concatenation, not +.
• Convert nulls to safe defaults with ?? or explicit casting.
• Extract primitive values from objects instead of adding objects directly.
• Add type hints and strict types to catch problems earlier.

Once you get into the habit of being explicit with your types, these fatal errors become rare and much easier to debug when they do happen.

The post PHP 8.3 Fatal Error Unsupported operand types – Common Causes and Fixes appeared first on Devnote.

In this guide, we will walk through all the reasons this happens and how to fix each one.

1. Understand what the error means

When you define a route like this:

Route::get('/users', [UserController::class, 'index']);

Laravel tries to find the UserController class. If it cannot load it, you see:

Target class [UserController] does not exist.

So you need to make sure:

1. The controller file exists.
2. The class name matches the file name.
3. The namespace matches what the route is using.
4. Autoload and route cache are up to date.

2. Check the controller file and namespace

Open your controller file, for example:

app/Http/Controllers/UserController.php

You should see something like:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class UserController extends Controller
{
    public function index()
    {
        return view('users.index');
    }
}

Pay attention to two things:

1. File name: UserController.php
2. Class name: UserController
3. Namespace: App\Http\Controllers

If the namespace does not match the folder path, Laravel will not be able to find the class.

For example, if the file is inside app/Http/Controllers/Admin, then the namespace should be:

namespace App\Http\Controllers\Admin;

And the route should use that full class.

3. Use the correct controller reference in routes

In routes/web.php or routes/api.php, you should reference the controller properly.

Option A: Use use import and ::class (recommended)

At the top of web.php:

use App\Http\Controllers\UserController;

Then define the route:

Route::get('/users', [UserController::class, 'index']);

This is the cleanest way and works in Laravel 8, 9, 10, and 11.

Option B: Use fully qualified class name directly

Without use, you can write:

Route::get('/users', [\App\Http\Controllers\UserController::class, 'index']);

This also works, but becomes messy with many routes.

4. Laravel 8+ change: no default namespace in RouteServiceProvider

In older versions (Laravel 7 and below), you could do:

Route::get('/users', 'UserController@index');

Because Laravel automatically prefixed App\Http\Controllers.

From Laravel 8 onwards, that default namespace was removed. So the old style string syntax without namespace will cause the “Target class does not exist” error.

Wrong in Laravel 8+:

Route::get('/users', 'UserController@index'); // likely to fail

Correct:

use App\Http\Controllers\UserController;

Route::get('/users', [UserController::class, 'index']);

If you migrated an old project to Laravel 11 and kept the old style strings, you will run into this error frequently.

5. Fixing controllers inside subfolders (Admin, Auth, etc.)

If your controller lives in a subfolder like app/Http/Controllers/Admin/UserController.php, then:

Controller:

<?php

namespace App\Http\Controllers\Admin;

class UserController extends Controller
{
    // ...
}

Route file:

use App\Http\Controllers\Admin\UserController;

Route::get('/admin/users', [UserController::class, 'index']);

If the namespace is App\Http\Controllers\Admin, but the route still uses App\Http\Controllers\UserController, Laravel will not find the class and throws the error.

6. Run composer autoload if you just created the controller manually

If you created the controller file manually (copy/paste, not using artisan) and Laravel still says the class does not exist, try regenerating Composer’s autoload files:

composer dump-autoload

Then refresh your page.

Using artisan to create controllers is safer because it sets everything up correctly:

php artisan make:controller UserController

7. Clear route cache

If you are using route caching in production, Laravel may still be using an old cached version of your routes.

Clear and rebuild:

php artisan route:clear
php artisan route:cache

During local development you can simply keep caching off and only use:

php artisan route:clear

Then try the route again.

8. Double check spelling and case sensitivity

On Linux servers, file names and namespaces are case sensitive.

Make sure:

• File: UserController.php (not userController.php)
• Class: class UserController
• Route import: use App\Http\Controllers\UserController;

If any of these differ by even one letter, you will get the “Target class does not exist” error on the server, even if it worked on Windows locally.

9. Example: complete working setup

Here is a small working example to compare with your project.

Controller: app/Http/Controllers/PostController.php

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class PostController extends Controller
{
    public function index()
    {
        return 'All posts list';
    }

    public function show($id)
    {
        return "Post ID: {$id}";
    }
}

Routes: routes/web.php

<?php

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

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

Route::get('/posts/{id}', [PostController::class, 'show'])->name('posts.show');

If this pattern works in your project, adjust your real controllers and routes to match this structure.

10. Quick checklist to fix “Target class controller does not exist”

• Confirm the controller file exists in app/Http/Controllers/....
• Make sure the namespace in the controller matches its folder.
• Import the controller in web.php or api.php using use App\Http\Controllers\YourController;.
• Use [YourController::class, 'method'] syntax in routes.
• Run composer dump-autoload if you added files manually.
• Clear route cache with php artisan route:clear.
• Watch out for case sensitivity on Linux servers.

Once these pieces are aligned, the Target class controller does not exist error in your Laravel route files will disappear, and your routes will resolve to the correct controllers again.

The post How to Solve Target class controller does not exist in Laravel Route Files appeared first on Devnote.

Laravel 11 Queue Jobs Not Running After PHP 8.3 Upgrade

• 1. Confirm queue driver in .env
• 2. Check artisan queue worker version
• 3. Missing PHP extensions
• 4. Database queue issues after upgrade
• 5. Queue worker daemon not restarted
• 6. Supervisor still pointing to old PHP path (Linux)
• 7. Check Horizon workers
• 8. Permissions after upgrade
• 9. Cached config

1. Confirm queue driver in .env

Make sure you are running the right queue system.

QUEUE_CONNECTION=database

Other valid values:

• redis
• sync
• sqs
• database

If you use Redis or database and switch to sync, jobs will run instantly but avoid doing that in production.

2. Check artisan queue worker version

After upgrading, php CLI may still point to the old version.

Run:

php -v

If it is not PHP 8.3, workers are running the wrong binary. Use the correct PHP path when starting the worker:

/usr/bin/php8.3 artisan queue:work

On Windows (XAMPP/WAMP/Laragon):

C:\xampp\php\php.exe artisan queue:work

Restart your terminal after changing PATH.

3. Missing PHP extensions

Queue + cache + redis rely on specific modules. Check them:

php -m

For Redis queues you must see:

redis

If not installed:

Ubuntu / Debian:

sudo apt install php8.3-redis
sudo systemctl restart php8.3-fpm

Windows:
Enable in php.ini:

extension=php_redis

Then restart Apache or Nginx.

4. Database queue issues after upgrade

If using database queue, migrate jobs table:

php artisan queue:table
php artisan migrate

Also verify jobs and failed_jobs tables exist.

5. Queue worker daemon not restarted

Workers don’t auto-update after PHP upgrade. If you use queue:work, stop and restart it:

php artisan queue:restart

This gracefully reloads all workers.

6. Supervisor still pointing to old PHP path (Linux)

Open your Supervisor file:

/etc/supervisor/conf.d/laravel-worker.conf

Example corrected config:

command=/usr/bin/php8.3 /var/www/html/artisan queue:work --sleep=3 --tries=3

Save and restart:

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl restart all

7. Check Horizon workers

If you use Laravel Horizon:

php artisan horizon:terminate

Horizon will restart with the new PHP binary.

Also verify Redis connection in .env:

REDIS_HOST=127.0.0.1
REDIS_PORT=6379

8. Permissions after upgrade

On Linux, permission issues can stop workers.

sudo chown -R www-data:www-data storage bootstrap/cache
sudo chmod -R 775 storage bootstrap/cache

Adjust user accordingly (nginx, ubuntu, ec2-user, etc.).

9. Cached config

After switching drivers or upgrading PHP, always clear cache:

php artisan config:clear
php artisan cache:clear
php artisan optimize:clear

Final checklist

• Correct queue driver in .env
• Verify PHP 8.3 is used by workers, Horizon, and Supervisor
• Install required extensions (redis, pdo, etc.)
• Restart queue workers or Horizon
• Fix OS-level permissions if using Linux
• Clear Laravel caches

Following these steps will get your Laravel 11 queue system running normally again after upgrading to PHP 8.3.

The post Laravel 11 Queue Jobs Not Running After PHP 8.3 Upgrade – Complete Fix appeared first on Devnote.

php artisan migrate
php artisan tinker
php artisan db

The good news is that nothing is wrong with Laravel itself. The problem is that your PHP installation is missing the required database driver extension, or it is not enabled.

In this guide, we will walk through step-by-step how to fix the could not find driver error for Laravel 11 with PHP 8.3 on different environments.

Why this error happens

Laravel uses PDO (PHP Data Objects) to connect to databases. Each database type needs its own driver:

• MySQL / MariaDB: pdo_mysql
• PostgreSQL: pdo_pgsql
• SQLite: pdo_sqlite
• SQL Server: pdo_sqlsrv (on Windows)

If the driver extension is not enabled in PHP, PDO cannot talk to your database, and Laravel shows:

could not find driver

So the fix is simple in theory:

1. Enable or install the correct PDO extension for your database.
2. Make sure PHP is using that configuration (CLI and web server).
3. Ensure your .env settings match the driver you installed.

Step 1: Check which database you are using in Laravel

Open your .env file in the root of your Laravel 11 project and look at your database settings:

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

The important one is:

DB_CONNECTION=mysql

Common values:

• mysql
• pgsql
• sqlite
• sqlsrv

Whatever is set here is the driver you must enable in PHP.

Step 2: Check enabled PDO extensions in PHP 8.3

Run this command in your terminal:

php -m | grep -i pdo

If you are using Windows PowerShell, you can use:

php -m | Select-String "pdo"

You should see something like:

PDO
pdo_mysql

If you only see PDO but not pdo_mysql (for MySQL) or pdo_pgsql (for PostgreSQL), then the specific driver is not enabled. That is why Laravel cannot find the driver.

Step 3: Fix on Windows (XAMPP, WAMP, Laragon)

If you are on Windows, the most common stack is XAMPP, WAMP, or Laragon.

3.1 Enable pdo_mysql in php.ini (for MySQL)

1. Find the php.ini file used by your CLI: php --ini This shows the path to Loaded Configuration File.
2. Open that php.ini in a text editor (Notepad, VS Code, etc.).
3. Search for these lines: ;extension=pdo_mysql ;extension=mysqli
4. Remove the semicolon at the beginning so they become: extension=pdo_mysql extension=mysqli
5. Save the file.
6. Restart Apache (or Nginx) from your control panel (XAMPP, WAMP, Laragon).
7. Close and reopen your terminal, then run: php -m | grep -i pdo This time you should see pdo_mysql in the list.

3.2 Make sure PHP used by Laravel is the same as XAMPP/WAMP

Sometimes your system has multiple PHP versions installed, and the one in your PATH is not the same as XAMPP/WAMP PHP.

Run:

php -v

Check if the path looks like C:\xampp\php\php.exe or similar. If not, you may need to add the correct PHP folder to your system PATH, or call it with the full path, for example:

"C:\xampp\php\php.exe" artisan migrate

Step 4: Fix on Linux (Ubuntu, Debian, etc.)

On Linux with PHP 8.3, you need to install the matching extension packages.

4.1 Install PDO driver for MySQL

For MySQL:

sudo apt update
sudo apt install php8.3-mysql

For PostgreSQL:

sudo apt install php8.3-pgsql

For SQLite, it is usually built in, but if not:

sudo apt install php8.3-sqlite3

After installing, restart your web server and PHP-FPM (if used):

sudo systemctl restart apache2
# or
sudo systemctl restart nginx
sudo systemctl restart php8.3-fpm

Then check:

php -m | grep -i pdo

You should now see pdo_mysql or pdo_pgsql in the list.

Step 5: Fix on macOS (Homebrew PHP)

If you are using Homebrew PHP on macOS:

1. Check your PHP version: php -v
2. For MySQL, install the extension if needed or link it properly. Often with recent PHP versions, PDO MySQL is already included. Make sure your PHP is the one from Homebrew: which php It should be something like /opt/homebrew/bin/php or /usr/local/bin/php.
3. If you are using Valet, run: valet restart
4. Again, verify: php -m | grep -i pdo

Step 6: Make sure your .env matches the installed driver

If you installed pdo_mysql, then in .env:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=your_database
DB_USERNAME=your_user
DB_PASSWORD=your_password

If you installed pdo_pgsql, then:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=your_database
DB_USERNAME=your_user
DB_PASSWORD=your_password

For SQLite:

DB_CONNECTION=sqlite
DB_DATABASE=/full/path/to/database.sqlite

After editing .env, clear the config cache:

php artisan config:clear
php artisan config:cache

Step 7: Test the connection again

Now test your setup:

php artisan migrate

If everything is configured correctly, migrations should run without the could not find driver error.

You can also test quickly using Tinker:

php artisan tinker
>>> DB::connection()->getPdo();

If no error appears, your driver is working.

Example: Full mini checklist

Here is a quick checklist to fix could not find driver in Laravel 11 with PHP 8.3:

1. Check database driver in .env:
   • DB_CONNECTION=mysql or pgsql or sqlite or sqlsrv.
2. Confirm installed PHP modules: php -m | grep -i pdo
3. If missing:
   • On Windows: enable extension=pdo_mysql (or others) in php.ini.
   • On Linux: install php8.3-mysql, php8.3-pgsql, or php8.3-sqlite3.
   • On macOS: ensure you use the correct PHP binary with PDO enabled.
4. Restart web server and PHP-FPM (if used).
5. Clear Laravel config cache: php artisan config:clear php artisan config:cache
6. Run: php artisan migrate

Conclusion

The could not find driver error in Laravel 11 with PHP 8.3 is almost always caused by a missing or disabled PDO extension for your chosen database. Once you enable or install the correct driver and make sure Laravel is pointing to the right database and PHP installation, the error disappears.

The post How to Fix could not find driver Error in Laravel 11 with PHP 8.3 appeared first on Devnote.

PHP 8.3: What’s New and How It Helps You Today

Why upgrade to PHP 8.3?

Upgrading isn’t just about new syntax. A new PHP release usually brings:

• smaller runtime improvements and performance tweaks
• safer defaults and deprecations that reduce bugs long term
• new APIs that make code clearer and shorter

You don’t need to jump immediately, but if your stack and libraries support 8.3, it’s a good move for maintenance and future-proofing.

Highlights: what changed in PHP 8.3

Below are the most developer-facing improvements that make day-to-day work nicer. I focus on features that are easy to adopt and that improve code clarity or runtime behavior.

1. Readonly classes and properties made easier

PHP has been moving toward immutability. With the latest releases, readonly properties and class-level readonly declarations let you mark whole classes or individual properties as immutable after construction. That means fewer accidental modifications and clearer intent.

readonly class Settings
{
    public function __construct(
        public string $appName,
        public string $env,
    ) {}
}

$s = new Settings('devnote', 'production');
// $s->appName = 'changed'; // now disallowed — helps avoid accidental state mutation

Use readonly where object state should not change after creation, config, DTOs, response objects.

2. Improved named-argument behavior and validation

Named arguments continue to evolve, making function calls more readable and safer. Expect tighter checks around named arguments and more predictable behavior when arguments change order or optional parameters are added.

sendMail(to: '[email protected]', subject: 'Hello', html: true);

Named args reduce the need for long arrays of options and make calls self-documenting.

3. Graphical/console-friendly improvements for debugging

Small but useful improvements in error messages and stack traces make debugging faster. You’ll see clearer type-error messages and more actionable stack traces that point to the exact problem line and value.

4. Better random and cryptographic utilities

PHP keeps modernizing random and crypto APIs. Expect simpler interfaces for generating cryptographically secure values and shims that reduce usage of older, error-prone functions.

$token = bin2hex(random_bytes(32));
// or simplified helper in newer versions
$token = random_str(32);

Use the newer APIs where available; they’re safer and more consistent across platforms.

5. Performance and engine tweaks

8.3 includes optimizations in the engine and standard library. While microbenchmarks vary, the overall effect is less memory overhead and faster request handling in many workloads, especially for long-running processes and worker jobs.

Practical examples for Laravel and WordPress developers

Here are a few concrete ways you’ll benefit when your projects run on PHP 8.3.

Cleaner DTOs and request objects

Use readonly objects for request/response DTOs in Laravel to avoid accidental mutation:

readonly class CreatePostDTO
{
    public function __construct(
        public string $title,
        public string $body,
        public ?int $authorId = null
    ) {}
}

Smaller controllers, clearer calls

Named arguments let you call helper functions and mailers in a way that’s easy to read and refactor-safe:

Mail::to('[email protected]')->send(template: 'welcome', data: $payload);

Safer background jobs

Random/crypto improvements mean generating job tokens and secure IDs in queue workers is simpler and less error-prone.

Migration tips

1. Check your dependencies first. Run composer update on a branch and test. If a third-party lib breaks, either wait or use polyfills/shims.
2. Run your test suite under 8.3. Unit and integration tests will show breaking changes quickly.
3. Enable stricter warnings in staging. Turn on full error reporting to catch deprecations before production.
4. Adopt readonly and named args gradually. Convert DTOs and small helper classes first, then expand once you’re comfortable.
5. Use feature flags for big changes. If you plan big refactors tied to 8.3 features, gate them behind flags so you can roll back easily.

Compatibility checklist

Before you flip PHP version in production:

• Update composer packages and check for compatibility with PHP 8.3.
• Run static analysis (Psalm / PHPStan) and fix type issues.
• Test on a staging environment with identical PHP-FPM / web server versions.
• Verify extensions you rely on are available and compiled for 8.3.
• Monitor performance and error logs closely after deploy.

Quick performance note

Upgrading PHP often yields performance gains without code changes, but your mileage depends on workload. Measure real endpoints and background jobs before and after the upgrade. Use flamegraphs or an APM to spot regressions early.

When not to upgrade immediately

If a critical library you depend on hasn’t declared support for 8.3, or if you’re in the middle of a major release window for your product, wait. Plan a maintenance window and test thoroughly.

Final thoughts

PHP 8.3 continues the trend of making PHP code more expressive, safer and easier to maintain. You get better immutability, clearer argument semantics, improved random/crypto helpers and small runtime gains. all of which add up to nicer developer experience and more reliable apps.

The post PHP 8.3 new features appeared first on Devnote.