PHP 8.6: expected release window and the RFCs being proposed right now

You’ll get a current, practical view of what PHP 8.6 is likely to include. We’ll pin down the most likely release window based on the last few major releases. Then we’ll walk through the RFCs that are explicitly targeting PHP 8.6 or are being built for the next PHP 8.x. Everything here is focused on day to day PHP code you’ll actually write in CLI scripts and web apps.

Expected PHP 8.6 release window

PHP has been shipping major versions around late November for years. PHP 8.5 shipped on November 20, 2025, and PHP 8.4.0 shipped in late November 2024. If the project keeps the same cadence, PHP 8.6 is most likely to ship in the third week of November 2026. A reasonable expectation is a Thursday release (like recent majors), so think around November 19, 2026 or November 26, 2026, with the exact date depending on how many RCs are needed.

Approved or already being implemented for the next release

Partial Function Application (v2)

Status: Accepted

This adds a placeholder based syntax to partially apply arguments to any callable. If you call a function and leave one or more arguments as placeholders, PHP returns a Closure that remembers what you already provided. You can then call that closure later with the missing values.

<?php
 
function add(int $a, int $b, int $c): int
{
    return $a + $b + $c;
}
 
$add10AndX = add(10, ?, 5);  // returns Closure: fn(int $b): int
 
echo $add10AndX(3);         // 18

This creates a closure because ? marks a missing argument. $add10AndX is the important variable, it holds the callable you can reuse. If the callable has strict parameter types, the closure keeps them, so you still get proper type errors.

You’ll also see this shine with callback heavy code.

<?php
 
$strings = ['hello world', 'hello php'];
 
$replaceHello = str_replace('hello', 'hi', ?);
 
$result = array_map($replaceHello, $strings);
 
var_dump($result);

str_replace('hello', 'hi', ?) returns a closure that expects the third argument. That closure can be passed directly into array_map(). Edge case: if you partially apply a callable that takes arguments by reference, the exact behavior depends on the RFC’s final rules, so verify against the RFC when using references.

RFC: https://wiki.php.net/rfc/partial_function_application_v2

clamp()

Status: Accepted

This proposes a native clamp() function that keeps a value inside a min/max range. If the value is below min, you get min. If it is above max, you get max.

<?php
 
$percent = 140;
 
echo clamp($percent, 0, 100); // 100

$percent is your input. 0 and 100 are inclusive bounds. If you accidentally pass min > max, clamp() is expected to throw a ValueError, so don’t rely on silent fixes.

RFC: https://wiki.php.net/rfc/clamp_v2

RFCs not yet accepted for PHP 8.6

Everything in this section is still draft or under discussion, so details can change or the proposal can be rejected. I’m describing what each RFC is trying to add, and where it would show up in your code if it lands.

func_get_args_by_name()

Status: Under Discussion

This proposes a new function that returns the current function’s arguments, but keeps parameter names as array keys for named arguments. Unlike func_get_args(), you don’t lose the names.

<?php
 
function greet(string $name, int $age, ...$extra): array
{
    return func_get_args_by_name();
}
 
var_dump(greet(name: 'Alice', age: 30, 'x', 'y'));

The returned array should contain keys like name and age for the named arguments. Extra positional arguments remain numeric keys. Edge case: if you pass a parameter positionally, it will likely appear as a numeric key, so don’t assume everything is named.

RFC: https://wiki.php.net/rfc/func_get_args_by_name

Nullable and non-nullable cast operators

Status: Under Discussion

This proposes two new cast forms:

• (?type) which lets null pass through as null, but still validates and coerces non null values using weak mode parameter coercion rules.
• (!type) which rejects null and also rejects values that cannot be coerced cleanly.

<?php
 
$value = null;
 
var_dump((?int) $value); // null
 
try {
    var_dump((!int) $value);
} catch (TypeError $e) {
    echo $e->getMessage(), "
";
}

(?int) is meant for pipelines where null is a meaningful absence. (!int) is meant for places where you want an explicit failure instead of silent conversion. Edge case: the exact coercion rules are the key part, and they’re based on weak mode parameter rules rather than today’s very permissive casts.

RFC: https://wiki.php.net/rfc/nullable-not-nullable-cast-operator

Deprecate fuzzy scalar casts

Status: Under Discussion

This aims to deprecate “fuzzy” casts where PHP currently does lossy conversions without telling you. The classic example is a partially numeric string where PHP keeps the numeric prefix and discards the rest.

<?php
 
$raw = "123abc";
 
// Today this becomes 123.
// Under this RFC, this kind of cast is expected to raise a deprecation in PHP 8.6.
$value = (int) $raw;
 
var_dump($value);

If this RFC passes, the practical fix is simple: validate first, then cast.

<?php
 
$raw = "123abc";
 
if (!ctype_digit($raw)) {
    throw new InvalidArgumentException('Expected digits only');
}
 
$value = (int) $raw;
var_dump($value);

ctype_digit() is strict: it only accepts strings made of digits. That means it rejects negative numbers and whitespace, so pick a validator that matches your input rules.

RFC: https://wiki.php.net/rfc/deprecate-fuzzy-and-null-casts

Deprecations for PHP 8.6

Status: Draft

This is an umbrella RFC that collects deprecations proposed for PHP 8.6. It’s structured so individual deprecations can be voted separately. Examples currently listed include deprecating passing objects to certain array and zlib functions, and deprecating strcoll() and SORT_LOCALE_STRING.

RFC: https://wiki.php.net/rfc/deprecations_php_8_6

Add values() to BackedEnum

Status: Under Discussion

This proposes a values() method on BackedEnum to return all backing values as an indexed array. If you’ve written enums and then immediately needed an array_map(fn($c) => $c->value, Status::cases()), this removes the boilerplate.

<?php
 
enum Status: string
{
    case Active = 'active';
    case Inactive = 'inactive';
}
 
var_dump(Status::values());

If the enum already defines its own values() method, that should keep working. If you rely on a specific sort order, confirm what the RFC guarantees (it’s usually declaration order).

RFC: https://wiki.php.net/rfc/add_values_method_to_backed_enum

Stringable enums

Status: Under Discussion

This proposes allowing __toString() on enums. That would make it legal to directly echo an enum case with custom formatting.

<?php
 
enum Role: string
{
    case Admin = 'admin';
 
    public function __toString(): string
    {
        return $this->value;
    }
}
 
echo Role::Admin;

This is intentionally narrow: it’s about letting enums define __toString(), not about adding state to enums.

RFC: https://wiki.php.net/rfc/stringable-enums

Stream error handling improvements

Status: Under Discussion

This proposes making stream errors more consistent and more programmatically usable. The RFC describes adding structured error storage, optional exception based behavior, and consistent error codes across wrappers. If you’ve ever had to juggle warnings, error handlers, and inconsistent messages from different stream wrappers, this is aiming at that pain.

RFC: https://wiki.php.net/rfc/stream_errors

Data encoding API

Status: Under Discussion

This proposes a standard encoding and decoding API for common base encodings. The motivation is to cover more variants than today’s base64_encode() and base64_decode(), including RFC 4648 family details and additional popular encodings.

RFC: https://wiki.php.net/rfc/data_encoding_api

Namespace-scoped visibility

Status: Under Discussion

This proposes a new visibility level, written like private(namespace), that allows access from within the same namespace. The goal is to share internal APIs between closely related classes without exposing them as public to the whole application.

RFC: https://wiki.php.net/rfc/namespace_visibility

PDO disconnect() and isConnected()

Status: Under Discussion

This proposes two methods on PDO:

• PDO::disconnect() to explicitly close the underlying connection.
• PDO::isConnected() to query whether the connection is currently established.

If this lands, it gives you a supported way to drop a connection without relying on unset($pdo) and garbage collection timing.

RFC: https://wiki.php.net/rfc/pdo_disconnect

Object-oriented curl API v2

Status: Under Discussion

PHP has curl handles as objects today, but they are still used mostly through procedural functions. This RFC proposes a real object oriented API on top of curl objects, with a cleaner structure and better type safety.

RFC: https://wiki.php.net/rfc/curl_oop_v2

num_available_processors()

Status: Under Discussion

This proposes a native function to get the number of available processors. It’s mainly useful for parallel work scheduling, like choosing a default worker count.

<?php
 
$workers = num_available_processors() ?? 1;
 
echo "Workers: {$workers}
";

The ?? 1 fallback matters because the RFC allows returning null in some situations. Don’t assume it always matches CPU affinity limits unless the RFC explicitly guarantees it.

RFC: https://wiki.php.net/rfc/num_available_processors

Drop 32-bit builds

Status: Under Discussion

This proposes stopping official 32-bit builds. If you’re deploying to very old systems this can be a breaking change, but most modern hosting and containers are already 64-bit.

RFC: https://wiki.php.net/rfc/drop_32bit_support

JSON Schema validation support

Status: Under Discussion

This proposes adding JSON Schema support to the JSON extension. The RFC describes schema objects (created from schema text) and validation integrated with existing JSON error handling. If you validate API payloads against schemas today using libraries, this would be a standard option.

RFC: https://wiki.php.net/rfc/json_schema_validation

pack()/unpack() endianness modifiers for signed integers

Status: Under Discussion

This proposes extending pack() and unpack() format strings to support endianness modifiers on signed integer formats. The goal is to avoid manual bit shifting when you need signed little endian or big endian integers.

RFC: https://wiki.php.net/rfc/pack-unpack-endianness-signed-integers-support

Context managers

Status: In Discussion

This proposes a using (...) { ... } style construct to guarantee cleanup at the end of a block. The core idea is “acquire something, run code, always release it”, without manually writing try/finally in every place. The RFC examples focus on file handles and transactions.

RFC: https://wiki.php.net/rfc/context-managers

True Async

Status: Under discussion

This is a broader proposal to define a standard async model and engine level support that extensions can hook into. It includes a base RFC and related RFCs for scope and an engine API. This is ambitious, and it’s the kind of RFC that can take multiple release cycles if it lands at all.

RFC: https://wiki.php.net/rfc/true_async

True Async engine API

Status: Under discussion

This is a companion RFC that focuses on an engine level API for pluggable schedulers, reactors, and thread pools. Think of it as infrastructure to make async implementations possible without hard-wiring PHP to one event loop.

RFC: https://wiki.php.net/rfc/true_async_engine_api

True Async scope and structured concurrency

Status: Under discussion

This extends the True Async proposal with scoped lifetimes for coroutines and structured concurrency concepts. The key idea is tying concurrent work to a scope so cancellation and cleanup are automatic when a scope ends.

RFC: https://wiki.php.net/rfc/true_async_scope

Conclusion

You now have a realistic release window for PHP 8.6 based on the recent late-November cadence. We covered the features already accepted or in implementation, including partial function application and clamp(). We grouped every other currently proposed RFC for PHP 8.6 that is still draft or under discussion, with a short description of what it would change. As votes happen, the only reliable source of truth is each RFC’s status, so keep an eye on which items move to Accepted or Implemented.

Handling file downloads from URLs in Laravel

In this article you will see how to download files from external URLs in a Laravel application. You will do this both to save the file on your server and to send it to the user as a download. Everything happens inside normal Laravel code, for example in controllers or jobs. We will focus only on practical, copy pasteable patterns you can adapt to your own project.

Basic controller setup

All the examples below assume you are calling a controller method from a route. For example:

// routes/web.php
 
use App\Http\Controllers\FileDownloadController;
use Illuminate\Support\Facades\Route;
 
Route::get('/download-remote', [FileDownloadController::class, 'downloadRemote']);
Route::get('/cache-remote', [FileDownloadController::class, 'cacheRemote']);

// app/Http/Controllers/FileDownloadController.php
 
namespace App\Http\Controllers;
 
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Http;
use Illuminate\Support\Facades\Storage;
 
class FileDownloadController extends Controller
{
    // methods will go here
}

You do not have to structure your code exactly like this, but having a dedicated controller keeps the examples clear.

Directly streaming a remote URL to the browser

Sometimes you just want to take a remote file URL and let the user download it through your Laravel app, without storing it on disk. This is common when you proxy downloads through your app for authentication or logging.

You can do this with response()->streamDownload() and a plain PHP stream:

// app/Http/Controllers/FileDownloadController.php
 
public function downloadRemote(Request $request)
{
    $url = $request->query('url'); // example: https://example.com/file.pdf
 
    if (! $url) {
        abort(400, 'Missing url parameter');
    }
 
    $fileName = basename(parse_url($url, PHP_URL_PATH)) ?: 'downloaded-file';
 
    return response()->streamDownload(function () use ($url) {
        $read = fopen($url, 'r');
 
        if (! $read) {
            abort(502, 'Unable to open remote file');
        }
 
        while (! feof($read)) {
            echo fread($read, 1024 * 1024); // 1 MB chunks
        }
 
        fclose($read);
    }, $fileName);
}

What this does:

• Reads the url query parameter from the request.
• Uses streamDownload to stream the remote file directly to the browser.
• Uses fopen and fread in a loop so the file is not fully loaded into memory.
• Picks a filename from the URL path, or falls back to downloaded-file.

Edge cases to be aware of:

• allow_url_fopen must be enabled in PHP for fopen($url, 'r') to work.
• If the remote server is slow or unreachable, your request will also be slow or fail.
• You might want to add your own authorization logic before allowing the download.

Downloading a file from a URL and storing it on disk

Very often you want to fetch a remote file once, store it somewhere in your storage disk, then serve it from there. This is handy for caching remote assets, invoices, reports, and similar files.

A simple approach is to use the Laravel HTTP client and the Storage facade.

// app/Http/Controllers/FileDownloadController.php
 
public function cacheRemote(Request $request)
{
    $url = $request->query('url');
 
    if (! $url) {
        abort(400, 'Missing url parameter');
    }
 
    $response = Http::timeout(30)->get($url);
 
    if (! $response->successful()) {
        abort(502, 'Failed to download remote file');
    }
 
    $extension = pathinfo(parse_url($url, PHP_URL_PATH) ?? '', PATHINFO_EXTENSION);
 
    $fileName = 'remote_' . time() . ($extension ? ".{$extension}" : '');
 
    $path = "downloads/{$fileName}";
 
    Storage::disk('local')->put($path, $response->body());
 
    return response()->json([
        'stored_as' => $path,
        'disk' => 'local',
    ]);
}

What this does:

• Uses the HTTP client to GET the remote URL with a timeout.
• Checks successful() so you do not store error pages as files.
• Derives a simple extension from the URL path.
• Writes the raw response body to storage/app/downloads/... using the local disk.
• Returns a small JSON payload with where the file was stored.

For typical small and medium files this is fine. For very large files this approach reads the full file into memory once, so use the streaming approach in the next section if that matters.

Streaming a URL directly into storage using HTTP sink

For large files you usually do not want to hold the entire file in memory. Laravel's HTTP client is built on top of Guzzle, which supports a sink option that streams the response directly into a file.

// app/Http/Controllers/FileDownloadController.php
 
use GuzzleHttp\Psr7\Utils;
 
public function cacheRemoteStreamed(Request $request)
{
    $url = $request->query('url');
 
    if (! $url) {
        abort(400, 'Missing url parameter');
    }
 
    $extension = pathinfo(parse_url($url, PHP_URL_PATH) ?? '', PATHINFO_EXTENSION);
    $fileName = 'remote_' . time() . ($extension ? ".{$extension}" : '');
 
    $relativePath = "downloads/{$fileName}";
    $absolutePath = Storage::disk('local')->path($relativePath);
 
    $resource = Utils::tryFopen($absolutePath, 'w');
 
    Http::withOptions([
        'sink' => $resource,
        'timeout' => 60,
    ])->get($url);
 
    return response()->json([
        'stored_as' => $relativePath,
        'disk' => 'local',
    ]);
}

What this does:

• Creates a writable file handle inside the local disk root (by default storage/app/private/downloads/...).
• Passes that handle to the HTTP client via the sink option.
• Guzzle streams the response into the file as it arrives.
• Memory usage stays low even for large files.

If you prefer, you can pass a full file path string instead of a resource to sink, and Guzzle will open the file for you.

Letting the user download the stored file

Once the file is stored in a disk, you usually want to let the user download it. If you stored the file using Storage on an internal disk (for example local), the simplest way is Storage::download().

// app/Http/Controllers/FileDownloadController.php
 
public function downloadCached(Request $request)
{
    $path = $request->query('path'); // for example downloads/remote_1700000000.pdf
 
    if (! $path) {
        abort(400, 'Missing path parameter');
    }
 
    if (! Storage::disk('local')->exists($path)) {
        abort(404, 'File not found');
    }
 
    return Storage::disk('local')->download($path);
}

What this does:

• Reads the path that was returned when you cached the file.
• Checks if the file exists on the local disk.
• Returns a download response that forces the browser to download the file.

You can also override the download filename and headers:

return Storage::disk('local')->download($path, 'report.pdf', [
    'Content-Type' => 'application/pdf',
]);

Combining remote download and user download in one request

Sometimes you want to fetch the file from a URL and immediately send it to the browser once, without keeping a copy. You can combine the HTTP client and streamDownload for this.

// app/Http/Controllers/FileDownloadController.php
 
public function proxyRemote(Request $request)
{
    $url = $request->query('url');
 
    if (! $url) {
        abort(400, 'Missing url parameter');
    }
 
    $fileName = basename(parse_url($url, PHP_URL_PATH)) ?: 'downloaded-file';
 
    $response = Http::timeout(60)->get($url);
 
    if (! $response->successful()) {
        abort(502, 'Failed to download remote file');
    }
 
    $contentType = $response->header('Content-Type', 'application/octet-stream');
 
    return response()->streamDownload(function () use ($response) {
        echo $response->body();
    }, $fileName, [
        'Content-Type' => $contentType,
    ]);
}

What this does:

• Fetches the remote URL using the HTTP client.
• Validates that the response was successful.
• Uses the remote Content-Type header when sending the file to the browser.
• Wraps the body in a streamDownload so the browser gets a proper attachment download.

This approach is fine for small or moderate file sizes. For very large files you should stick with the streaming variant that does not hold the whole response body in memory.

Using queues or cron jobs to download from URLs

If downloading the remote file takes a long time, you usually do not want to block a normal web request. A common pattern is:

• The HTTP request dispatches a job that downloads and stores the remote file using one of the cache methods above.
• The job writes the path to the database.
• A separate controller action later exposes the file via Storage::download().

The exact queue and scheduling setup depends on your application, but you reuse the same cacheRemote or cacheRemoteStreamed code inside your job class.

Conclusion

You have seen how to download files from external URLs inside a Laravel application. You can stream remote files directly to the browser, cache them to storage, or do both. You also know how to handle small files with simple Http::get calls and large files with the HTTP sink option. With these patterns you can cover most real world "download from URL" requirements without extra packages.

How to pause and resume queue workers in Laravel

In this guide, you will learn how to pause and resume Laravel queue workers on demand. We will work in the context of long running queue:work processes managed from the CLI. You will see how to target specific connections and queues when pausing workers. You will also see how to pause queues indefinitely or for a fixed amount of time from both Artisan and application code.

What it means to pause a queue

Before touching any commands, it helps to be precise about what a "paused" queue actually does in Laravel:

• Pausing is per queue and per connection, not global for all queues.
• Workers that are already running finish the job they are currently processing.
• Once the current job finishes, workers stop pulling new jobs from the paused queue.
• The worker process itself keeps running; it does not exit or get killed.
• When the queue is resumed, workers immediately start pulling jobs again from that queue.

So pausing is a way to temporarily put a queue on hold without touching your process manager or worker processes.

Pausing and resuming queues with Artisan

The most direct way to pause and resume queues is via Artisan. This is usually what you will do in production shells or deployment scripts.

Starting a worker for a specific connection and queue

First, assume you have a worker processing a queue. For example:

php artisan queue:work database --queue=default

This worker uses the database queue connection and listens to the default queue. The connection name comes from config/queue.php, and the queue name is whatever you configured or used when dispatching jobs. As long as this process is running, it will keep picking up jobs from the database connection's default queue.

Pausing a queue from the CLI

To pause a queue, you use the queue:pause command and pass a single argument in the connection:queue format:

php artisan queue:pause database:default

Key points:

• database is the connection name.
• default is the queue name.
• Any workers processing jobs from database / default will finish their current job.
• After finishing that job, they will not fetch any new jobs from that queue until it is resumed.

If you are using Redis with a custom queue name, pausing that queue looks like this:

php artisan queue:pause redis:emails

Workers that are listening on redis and processing the emails queue will stop taking new jobs from emails, but can continue to process other queues if they are configured to listen to multiple queues.

Resuming a queue from the CLI

To resume job processing on a paused queue, you use queue:continue with the same connection:queue syntax:

php artisan queue:continue database:default

After this command runs:

• Workers that were idle because database:default was paused will start pulling new jobs again from that queue.
• Jobs that accumulated on database / default while it was paused will now be processed as normal.

You can do the same for any other connection and queue combination. For example:

php artisan queue:continue redis:emails

This resume command works regardless of whether the queue was paused via Artisan or via application code, since both go through the same underlying queue manager.

Pausing and resuming queues programmatically

Sometimes you want to pause or resume a queue from your application code instead of the CLI. For example, you might want to pause a queue when an external API rate limit is hit, or when an admin flips a feature flag in a dashboard.

For that, Laravel exposes queue pausing APIs via the Queue facade and the underlying QueueManager class.

Indefinitely pausing a queue in code

To pause a queue indefinitely from code, you can call Queue::pause with a connection and queue name:

<?php
 
namespace App\Http\Controllers;
 
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Queue;
 
class QueueAdminController
{
    public function pauseDefaultDatabaseQueue(Request $request)
    {
        // Pause the "default" queue on the "database" connection indefinitely
        Queue::pause('database', 'default');
 
        return response()->json([
            'status' => 'ok',
            'message' => 'database:default queue paused',
        ]);
    }
}

What matters in this example:

• Queue::pause('database', 'default') pauses the queue identified by that connection and queue.
• The pause is indefinite. The queue stays paused until you explicitly resume it.
• You can call this from anywhere in your app: controllers, commands, services, or jobs.

To resume the same queue from code, call Queue::resume:

Queue::resume('database', 'default');

You can safely call Queue::resume even if the queue is not currently paused. It simply ensures the paused flag is cleared.

Pausing a queue for a fixed amount of time

Laravel also lets you pause a queue for a specific duration using Queue::pauseFor.

This method accepts three arguments:

• The connection name.

• The queue name.

• A TTL (time to live) value that can be:

  • An integer number of seconds.
  • A DateTimeInterface instance.
  • A DateInterval instance.

Here is a simple example that pauses a queue for 60 seconds:

use Illuminate\Support\Facades\Queue;
 
// Pause for 60 seconds
Queue::pauseFor('redis', 'default', 60);

You can also express the pause using a DateTimeInterface by giving the exact moment when the pause should expire:

use Illuminate\Support\Facades\Queue;
 
// Pause until five minutes from now
Queue::pauseFor('redis', 'default', now()->addMinutes(5));

Or using a DateInterval:

use DateInterval;
use Illuminate\Support\Facades\Queue;
 
// Pause for 45 seconds via DateInterval
Queue::pauseFor('redis', 'default', new DateInterval('PT45S'));

When you use pauseFor:

• Laravel sets an internal flag that marks the queue as paused for the given TTL.
• While the flag is active, workers do not pull new jobs from that queue after finishing what they are currently processing.
• Once the TTL expires, the flag automatically disappears and workers will treat the queue as active again.
• You do not have to call Queue::resume when the TTL expires, although you can still call it manually if you want to resume earlier.

Example: pausing a queue when an external API returns 429

A very practical use case for pauseFor is handling rate limited APIs that return HTTP 429 with a Retry-After header.

Here is a simplified example inside a job that consumes such an API:

<?php
 
namespace App\Jobs;
 
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Illuminate\Support\Facades\Http;
use Illuminate\Support\Facades\Queue;
 
class SyncExternalData implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
 
    public function handle(): void
    {
        $response = Http::get('https://example.com/api/data');
 
        if ($response->status() === 429) {
            $retryAfter = (int) $response->header('Retry-After', 60);
 
            // Pause the queue that is processing this job for the Retry-After period
            Queue::pauseFor($this->queueConnection(), $this->queueName(), $retryAfter);
 
            // Optionally release this job so it can be retried later
            $this->release($retryAfter);
 
            return;
        }
 
        // Normal processing logic for successful responses...
    }
 
    protected function queueConnection(): string
    {
        return $this->connection ?? config('queue.default');
    }
 
    protected function queueName(): string
    {
        return $this->queue ?? 'default';
    }
}

Important details here:

• Queue::pauseFor(...) is called with the same connection and queue that this job is running on.
• The TTL is taken from the Retry-After header when available, or defaults to 60 seconds.
• release($retryAfter) tells the queue to retry the job after the same delay, so processing resumes when the pause ends.
• Other jobs on the same queue will also be paused until the TTL expires.

You can adapt this pattern to any situation where you need to back off a whole queue for a while.

Checking whether a queue is paused

Sometimes you just want to know if a queue is currently paused so you can make a decision in code. For that, you can use Queue::isPaused:

use Illuminate\Support\Facades\Queue;
 
if (Queue::isPaused('redis', 'default')) {
    // Maybe skip dispatching some jobs or show a warning in the UI
}

This method returns true if the queue is paused (either indefinitely or until a future time) and false otherwise.

How CLI and code based pausing work together

The Artisan commands and the Queue facade both use the same underlying queue manager and the same pause state.

That means:

• You can pause a queue from code with Queue::pause or Queue::pauseFor and then resume it with php artisan queue:continue.
• You can pause with php artisan queue:pause and then resume later from code using Queue::resume.
• Queue::isPaused reflects the state regardless of how the pause was initiated.

Because the pause state is shared, you do not need to worry about different mechanisms conflicting with each other.

Conclusion

You have seen how Laravel lets you pause and resume specific queues without stopping worker processes. You can control queue pausing from Artisan using queue:pause and queue:continue with a simple connection:queue argument. You can also pause queues indefinitely or for precise durations in code using the Queue facade, and check the current pause state when needed. With these tools you can integrate pausing deeply into your workflows, deployments, and rate limiting strategies without touching your worker supervision setup.

How to configure Apache for Laravel

In this guide you will configure Apache so it serves a Laravel application correctly through the public index.php front controller. You will see how this works for a single domain, multiple projects, subdirectories, and shared hosting environments. Everything happens at the Apache level using virtual host files and htaccess rules, not php artisan serve. By the end you can point a browser at your domain and hit Laravel routes without touching the public path in the url.

Apache requirements Laravel expects

Laravel does not need exotic Apache modules, but it does rely heavily on url rewriting and htaccess support. Here is the minimal Apache setup you should have before worrying about virtual hosts.

Enable the rewrite module

On Debian or Ubuntu based systems you usually enable the rewrite module with:

sudo a2enmod rewrite
sudo systemctl reload apache2

Run these commands in the server terminal as a user with sudo access. On other distributions make sure the rewrite module is loaded in the main Apache configuration file, for example /etc/httpd/conf/httpd.conf, using a LoadModule directive. Without rewrite support Laravel routes will not work and every non existing file request will return a raw Apache 404.

Allow htaccess overrides in the project directory

Laravel ships with a public/.htaccess file that contains its rewrite rules. Apache must be allowed to read and use that file. In a typical Debian or Ubuntu configuration you adjust the main directory block inside /etc/apache2/apache2.conf:

<Directory /var/www/>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

The important line here is AllowOverride All which tells Apache to honor htaccess files under that path. If this is set to None then Laravel rewrite rules will be ignored even if the module is enabled.

If your Laravel project lives somewhere else, for example in /var/www/myapp, you can scope the rule more tightly by adding a dedicated block to apache2.conf or your main Apache config:

<Directory /var/www/myapp/public>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

Default Laravel htaccess in the public directory

Laravel expects Apache to point to the public directory as the document root. Inside that directory it uses htaccess to route requests into index.php. Create or edit the file public/.htaccess in your Laravel project and put this inside it:

<IfModule mod_rewrite.c>
    RewriteEngine On
 
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

This does three things:

• Turns the rewrite engine on for that directory.
• If the requested path is not an existing directory and not an existing file, it rewrites the request to index.php.
• Lets Apache serve real files and directories directly without touching Laravel.

As long as Apache has AllowOverride All for the public directory and the rewrite module is enabled, you normally do not need to change this file.

Apache virtual host for a single Laravel application

This is the most common production setup: one domain pointing to one Laravel application. The key is to make Apache serve the public directory as the document root, never the project root.

Example virtual host on a Debian or Ubuntu Apache install. Create a new site file such as /etc/apache2/sites-available/example.conf and put this inside it:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
 
    DocumentRoot /var/www/example/current/public
 
    <Directory /var/www/example/current/public>
        AllowOverride All
        Require all granted
    </Directory>
 
    ErrorLog ${APACHE_LOG_DIR}/example_error.log
    CustomLog ${APACHE_LOG_DIR}/example_access.log combined
</VirtualHost>

Important parts in this configuration:

• You save this virtual host in a site file such as /etc/apache2/sites-available/example.conf and enable it with sudo a2ensite example.conf.
• DocumentRoot points to the Laravel public directory, not to the project root.
• The Directory block for that path allows htaccess so the Laravel rewrite rules are active.
• ServerName and ServerAlias tell Apache which host headers should hit this application.

On Debian or Ubuntu you typically save this file as /etc/apache2/sites-available/example.conf, enable it, then reload:

sudo a2ensite example.conf
sudo systemctl reload apache2

For other distributions the file location and helper commands differ, but the VirtualHost content is the same.

Adding an https virtual host for Laravel

If you have an ssl certificate for your domain, you pair the http virtual host with an https one. The only Laravel specific detail is that the document root and directory rules are identical.

Add a second VirtualHost block to the same site definition file, for example /etc/apache2/sites-available/example.conf:

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
 
    DocumentRoot /var/www/example/current/public
 
    <Directory /var/www/example/current/public>
        AllowOverride All
        Require all granted
    </Directory>
 
    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/example.crt
    SSLCertificateKeyFile /etc/ssl/private/example.key
 
    ErrorLog ${APACHE_LOG_DIR}/example_ssl_error.log
    CustomLog ${APACHE_LOG_DIR}/example_ssl_access.log combined
</VirtualHost>

As long as both virtual hosts share the same document root and directory rules, Laravel does not care whether the request came in over http or https.

Local development virtual host for Laravel

For local work you may want a clean domain like myapp.test instead of using php artisan serve or appending /public to URLs. The structure is almost identical to the production virtual host, just with a development oriented path and domain.

Example on a typical Linux workstation:

Create a new virtual host file such as /etc/apache2/sites-available/myapp.test.conf and place this inside it:

<VirtualHost *:80>
    ServerName myapp.test
 
    DocumentRoot /home/username/dev/myapp/public
 
    <Directory /home/username/dev/myapp/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Enable the site and reload Apache, for example with sudo a2ensite myapp.test.conf and sudo systemctl reload apache2.

Then add an entry to your local hosts file so the domain resolves locally. On Linux and macOS edit /etc/hosts, on Windows edit C:\Windows\System32\drivers\etc\hosts, and add:

127.0.0.1   myapp.test

After reloading Apache you can browse to http://myapp.test and hit your Laravel routes directly.

Multiple Laravel applications on one Apache server

If you host several Laravel projects on the same Apache instance, you usually create one virtual host per domain or subdomain so that each application stays isolated. The only Laravel specific rule stays the same each time: document root must be the public directory.

Example with two applications on the same server, each defined in its own site file under /etc/apache2/sites-available or inside a single vhosts file, depending on your layout:

<VirtualHost *:80>
    ServerName crm.example.com
    DocumentRoot /var/www/crm/current/public
    <Directory /var/www/crm/current/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>
 
<VirtualHost *:80>
    ServerName shop.example.com
    DocumentRoot /var/www/shop/current/public
    <Directory /var/www/shop/current/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Each Laravel application is isolated, has its own logs, and can be deployed independently while Apache keeps the rules simple.

Serving Laravel from a subdirectory

Sometimes you cannot dedicate a full domain or subdomain to Laravel. Instead you might need to serve it under a path like example.com/app. Laravel is fine with this as long as Apache routes that path into the public directory.

Using an alias for the subdirectory

A clean approach is to keep the main site document root as is and use an alias for the Laravel path. Edit the existing VirtualHost definition for example.com, usually in /etc/apache2/sites-available/example.conf or the equivalent file, and adjust it like this:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html
 
    Alias /app /var/www/app/current/public
 
    <Directory /var/www/app/current/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Here is what happens:

• Requests to example.com still hit the main document root /var/www/html.
• Requests whose path starts with slash app are internally mapped to the Laravel public directory.
• The directory block again allows htaccess so the framework rewrite rules run correctly.

Laravel will see the application at the /app path, so route URLs will automatically include that prefix when you use URL helpers.

Using htaccess in the main document root

If you do not want or cannot edit the main virtual host, you can place rewrite rules in the document root htaccess file that forward a specific path to Laravel. This is common when a control panel manages Apache and only exposes htaccess.

Example htaccess placed in the main document root that sends /app requests into Laravel. Create or edit the .htaccess file in your main document root, for example /var/www/html/.htaccess or public_html/.htaccess, and add:

RewriteEngine On
 
RewriteCond %{REQUEST_URI} ^/app
RewriteRule ^app/(.*)$ /app/public/$1 [L]

Combined with the default Laravel htaccess inside the public directory, this lets users access the application at example.com slash app without ever seeing the public segment.

Apache configuration when you only control htaccess

On many shared hosting environments you do not have direct access to Apache virtual host files. Instead you upload files into a document root such as public_html and control behavior with htaccess. You can still run Laravel this way while keeping public as the web entry point.

Assume the host gives you a document root at /home/user/public_html and you have installed Laravel directly inside that directory. You will end up with a public_html/public directory that contains index.php and assets. The goal is to hide the public segment from visitors.

Create or edit /home/user/public_html/.htaccess with rules that pass everything into the Laravel public directory:

RewriteEngine On
 
RewriteCond %{REQUEST_URI} !^/public
RewriteRule ^(.*)$ public/$1 [L]

Then ensure the Laravel public directory keeps its own .htaccess file, using the minimal rules shown earlier. The flow looks like this:

• The root htaccess rewrites all requests to the public directory.
• Once the request lands in public, Laravel rewrite rules send non file and non directory requests to index.php.
• You do not touch or move the framework core files out of their default locations.

If Laravel is installed in a subdirectory of the hosting document root, adjust the target path inside the rule accordingly.

Conclusion

Apache only needs a small amount of configuration to serve a Laravel application correctly. The central idea in every setup is that the document root or rewrite target must always be the Laravel public directory. You can reach that goal with direct virtual host files, alias rules, or htaccess only setups on shared hosting. Once Apache is pointing at public and rewrite support is active, Laravel takes over routing and your application behaves the same in every environment.

How to Get HTTP Request Headers in PHP

You want to read HTTP request headers from PHP code running behind a web server. This guide walks through the practical ways to do that: directly via $_SERVER, using getallheaders or apache_request_headers, and via PSR-7 request objects that many modern frameworks use.

Using getallheaders and apache_request_headers

PHP also provides functions that return all request headers directly as an associative array.

• getallheaders()
• apache_request_headers()

getallheaders is an alias of apache_request_headers and both fetch all HTTP request headers from the current request.

Basic usage of getallheaders

If getallheaders is available in your environment, this is usually the easiest way to see everything the client sent:

$headers = getallheaders();
 
foreach ($headers as $name => $value) {
    echo $name . ': ' . $value . PHP_EOL;
}

What this does:

• Calls getallheaders() to retrieve an associative array of all headers.
• Iterates and prints each header.
• Header names come back in a normalized form (for example Accept-Language, User-Agent, Content-Type).

When this is appropriate:

• You are running under Apache, FastCGI, or FPM where these functions are available.
• You do not want to deal with the $_SERVER naming convention manually.
• You want a full dump of headers for debugging or logging.

In some environments (for example plain CLI, or PHP built without the Apache related extension) these functions may not exist, and calling them would trigger a fatal error.

Fallback polyfill for getallheaders

On servers where getallheaders is missing (for example some nginx setups), a common pattern is to provide a compatible function that rebuilds the headers from $_SERVER.

if (!function_exists('getallheaders')) {
    function getallheaders(): array
    {
        $headers = [];
 
        foreach ($_SERVER as $name => $value) {
            if (str_starts_with($name, 'HTTP_')) {
                $headerName = substr($name, 5);
                $headerName = str_replace('_', ' ', $headerName);
                $headerName = ucwords(strtolower($headerName));
                $headerName = str_replace(' ', '-', $headerName);
 
                $headers[$headerName] = $value;
            }
        }
 
        if (isset($_SERVER['CONTENT_TYPE'])) {
            $headers['Content-Type'] = $_SERVER['CONTENT_TYPE'];
        }
 
        if (isset($_SERVER['CONTENT_LENGTH'])) {
            $headers['Content-Length'] = $_SERVER['CONTENT_LENGTH'];
        }
 
        return $headers;
    }
}
 
foreach (getallheaders() as $name => $value) {
    echo $name . ': ' . $value . PHP_EOL;
}

Why this is useful:

• Your application can call getallheaders() unconditionally.
• On hosts that provide the native function, you get the built-in implementation.
• On hosts that do not, you still get a compatible behavior based on $_SERVER.

Note on Authorization:

• getallheaders often includes the Authorization header where $_SERVER alone does not.
• If you care about auth headers, test this behavior on your specific server and PHP setup.

Accessing a single header via getallheaders

Request header names are case insensitive, but the array keys returned by getallheaders have a specific casing (for example User-Agent). To avoid guessing, you can normalize them before lookup.

<?php
$headers = getallheaders();
 
// Normalize keys to lowercase for case insensitive lookup
$headersLower = array_change_key_case($headers, CASE_LOWER);
 
$userAgent    = $headersLower['user-agent']    ?? null;
$authHeader   = $headersLower['authorization'] ?? null;
 
echo 'User-Agent: ' . ($userAgent ?? '[none]') . PHP_EOL;
echo 'Authorization: ' . ($authHeader ?? '[none]') . PHP_EOL;

What matters here:

• array_change_key_case creates a new array with lowercase keys.
• You can then look up any header using a consistent key, like 'authorization'.
• This pattern avoids subtle bugs when a server or extension uses slightly different header name capitalization.

Reading request headers from $_SERVER

PHP exposes incoming request headers through the $_SERVER superglobal. For most headers, PHP creates keys that:

• Start with HTTP_
• Use uppercase letters
• Replace hyphens with underscores

For example, the header:

Accept-Language: en-US,en;q=0.9

is usually available as:

$_SERVER['HTTP_ACCEPT_LANGUAGE'];

This behavior is documented in the PHP manual, which explains that request headers are mapped to $_SERVER entries following this naming pattern.

Reading specific headers from $_SERVER

Minimal example that reads a few common headers and a custom one:

// Common request headers
$acceptLanguage = $_SERVER['HTTP_ACCEPT_LANGUAGE'] ?? null;
$userAgent      = $_SERVER['HTTP_USER_AGENT'] ?? null;
 
// Custom header: X-Requested-With
$requestedWith  = $_SERVER['HTTP_X_REQUESTED_WITH'] ?? null;
 
echo "Accept-Language: " . ($acceptLanguage ?? '[none]') . PHP_EOL;
echo "User-Agent: " . ($userAgent ?? '[none]') . PHP_EOL;
echo "X-Requested-With: " . ($requestedWith ?? '[none]') . PHP_EOL;

What this does:

• Reads values from $_SERVER using the HTTP_ prefix and uppercase names with underscores.
• Uses the null coalescing operator ?? so the script does not throw notices if a header is missing.
• Prints each header as plain text.

Directly using $_SERVER is simple and works in any SAPI where PHP exposed the header as an environment variable. However, you have to know the exact key name or build it yourself.

Building a full header list from $_SERVER

If you want all headers but cannot rely on getallheaders, you can reconstruct them by scanning $_SERVER for keys that start with HTTP_.

Here is a small helper that:

• Turns HTTP_ACCEPT_LANGUAGE into Accept-Language
• Collects all such headers into an associative array
• Adds Content-Type and Content-Length, which may be exposed without the HTTP_ prefix

<?php
 
function headers_from_server(): array
{
    $headers = [];
 
    foreach ($_SERVER as $name => $value) {
        if (str_starts_with($name, 'HTTP_')) {
            $headerName = substr($name, 5); // remove "HTTP_"
            $headerName = str_replace('_', ' ', $headerName);
            $headerName = ucwords(strtolower($headerName));
            $headerName = str_replace(' ', '-', $headerName);
 
            $headers[$headerName] = $value;
        }
    }
 
    // Some headers are not prefixed with HTTP_
    if (isset($_SERVER['CONTENT_TYPE'])) {
        $headers['Content-Type'] = $_SERVER['CONTENT_TYPE'];
    }
 
    if (isset($_SERVER['CONTENT_LENGTH'])) {
        $headers['Content-Length'] = $_SERVER['CONTENT_LENGTH'];
    }
 
    return $headers;
}
 
$headers = headers_from_server();
 
foreach ($headers as $name => $value) {
    echo $name . ': ' . $value . PHP_EOL;
}

Points to notice:

• str_starts_with requires PHP 8.
• The transformation normalizes header names into the common Title-Case-Format.
• This gives you a consistent array of headers even in environments where getallheaders is not defined.

Keep in mind that some server setups may still hide specific headers (for example Authorization) unless configured to forward them into the CGI environment.

Quick note about environment and CLI

Request headers only exist for real HTTP requests. If you run your script from the command line:

• $_SERVER will not contain meaningful HTTP header entries for a normal CLI invocation.
• getallheaders or apache_request_headers may not even be defined or may not return anything useful if there is no actual HTTP request in progress.

So any code that relies on headers should either:

• Be executed only in an HTTP context, or
• Be defensive and handle the case where headers are missing or functions are not available.

Extract domain in PHP: From URL, Email or Current Page

In backend PHP development, extracting domain names is often required for tasks such as building canonical URLs, parsing user-supplied links or emails, routing, logging, or validation. In this article, we cover how to obtain domain names in PHP in several real-world contexts: from the current request, from a URL string, or from an email address. We also cover how to handle scheme (http/https) and optionally remove subdomains to get the “base” or registrable domain.

Getting the current page’s domain

To retrieve the domain used in the current request, the site address where your PHP code is running, you can rely on PHP’s $_SERVER superglobal variables:

$scheme = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') ? 'https' : 'http';
$host   = $_SERVER['HTTP_HOST'] ?? $_SERVER['SERVER_NAME'];
$domain = $scheme . '://' . $host;
echo $domain;

Explanation:

• $_SERVER['HTTP_HOST'] gives the host header sent by the client (could include port).
• As a fallback, $_SERVER['SERVER_NAME'] can be used if HTTP_HOST is not set.
• We detect the scheme (HTTPS or HTTP) to build a full URL including protocol.

This approach yields the exact domain (and optionally port) the user used to request the page. It’s commonly used for generating canonical URLs or redirects.

Security note: Because HTTP_HOST is derived from a client-supplied header, it can be spoofed. For security-sensitive tasks (authentication, token generation, access control), avoid trusting HTTP_HOST. Use a fixed configuration value or server-controlled name instead.

Extracting domain from a URL string

When you have a URL (from user input, configuration, referral data, etc.) and you want to extract its domain, PHP’s built-in parse_url() is the standard tool:

$url = 'https://www.example.com/path/page.php?foo=bar';
$host = parse_url($url, PHP_URL_HOST);
echo $host; // e.g. "www.example.com"

parse_url() parses a URL into components (scheme, host, path, query, fragment, etc.). Using the PHP_URL_HOST option returns the host (domain) component as a string.

This works reliably when the input is a full, valid URL.

Limitations and caveats:

• If the URL lacks a scheme (e.g. "example.com/path"), parse_url() may misinterpret the string as a relative path and fail to extract a host.
• If the URL is malformed or not properly encoded, parsing may produce unexpected results or return null.

Hence, when dealing with user-supplied or external input, it is wise to first validate or normalize the URL (for example by ensuring it has a scheme) before calling parse_url().

Get domain without subdomain

By default, parse_url() returns the full host including any subdomains. For example, from https://sub.www.example.co.uk, you’ll get sub.www.example.co.uk. Often you want only the “base” or “registrable” domain (e.g. example.co.uk).

A naive way to strip subdomains might look like this:

$host = parse_url($url, PHP_URL_HOST);
$host = preg_replace('/^www\./i', '', $host);

This handles the common case of a “www.” prefix. However, this approach fails when:

• The subdomain is not “www” (e.g. api.example.com, blog.example.co.uk).
• The domain has a multi-part TLD (e.g. .co.uk, .org.au), where simply taking the last two labels may be incorrect.
• There are deeper subdomains (e.g. a.b.c.example.com).

Because of these issues, reliably extracting the base domain from arbitrary hosts is nontrivial. A fully correct solution needs awareness of the public suffix list (all valid TLDs and multi-part TLDs). Without that, any regex or heuristic-based method will be brittle.

If precise domain extraction is critical in your application, use a well-maintained, public-suffix aware library. If not, the heuristic approach may suffice but be aware of its limitations.

Extracting domain from an email address

Email addresses have a simple structure: local-part@domain. To get the domain part in PHP:

$email = 'user@example.com';
if (filter_var($email, FILTER_VALIDATE_EMAIL)) {
    $domain = explode('@', $email)[1];
    echo $domain; // "example.com"
} else {
    // invalid email
}

Alternatively:

$domain = substr(strstr($email, '@'), 1);

Important points:

• Validate the email format first using filter_var(..., FILTER_VALIDATE_EMAIL) before extraction.
• This method returns exactly what is after the @. If the email is nonstandard (contains multiple @, or extra data), further validation or sanitization may be required.

This method is straightforward and works well when you trust or validate email input.

Caveats, edge cases, and best practices

• Subdomain stripping is error-prone. Regex or naive splitting on “.” may fail for multi-level TLDs or complex hosts. Use a public-suffix aware approach when accuracy matters.
• Server-provided host data (especially HTTP_HOST) comes from client headers, avoid trusting it for security-critical code.
• Always validate and sanitize external input (URLs and emails) before parsing. For instance, ensure a URL has a scheme and is well-formed before using parse_url().
• Be aware of internationalized domain names (IDN). Plain string or regex operations may not handle non-ASCII domain names; IDN/Punycode handling may be needed depending on use case.

Conclusion

PHP provides effective, built-in tools to extract domain names in typical web use cases:

• Use $_SERVER['HTTP_HOST'] (with scheme detection) for the current request domain.
• Use parse_url() to parse a URL string and extract the host.
• Use simple string manipulation or explode('@') to extract domain from an email address.
• For extracting a registrable domain (without subdomains), rely on a public-suffix aware library rather than naive string hacks.

While simple cases are easy, edge cases (subdomains, multi-level TLDs, malformed input) require careful handling. For robust, production-ready code, validate inputs and prefer library-based parsing when domain correctness matters.

Date Differences Calculations in PHP

Date calculations are essential for tasks such as scheduling, expiration checks, analytics, and time based validation. PHP provides accurate and reliable tools for these operations through DateTime, DateInterval, and timestamps. In this blog post, I'll demonstrate how to calculate date differences in every common unit with concise examples.

Using DateTime and diff

DateTime represents a point in time. The diff method compares two DateTime objects and returns a DateInterval.

$date1 = new DateTime('2024-01-01');
$date2 = new DateTime('2024-02-10');
$interval = $date1->diff($date2);

A DateInterval exposes properties such as y, m, d, h, i, s. It handles leap years, month boundaries, and daylight changes automatically.

Difference in Days

Using diff:

$date1 = new DateTime('2024-01-01');
$date2 = new DateTime('2024-01-20');
$days = $date1->diff($date2)->days;
echo $days;

The days property returns the total difference in days.

Using timestamps:

$seconds = abs(strtotime('2024-01-01') - strtotime('2024-01-20'));
$days = intdiv($seconds, 86400);
echo $days;

Use timestamps when you only need complete day counts without calendar rules.

Difference in Hours

Using DateInterval:

$date1 = new DateTime('2024-01-01 00:00');
$date2 = new DateTime('2024-01-02 05:00');
$diff = $date1->diff($date2);
$hours = $diff->days * 24 + $diff->h;
echo $hours;

Using timestamps:

$seconds = abs(strtotime('2024-01-01 00:00') - strtotime('2024-01-02 05:00'));
$hours = intdiv($seconds, 3600);
echo $hours;

Difference in Months

The DateInterval exposes years and months. Total months is years multiplied by 12 plus months.

$date1 = new DateTime('2023-01-01');
$date2 = new DateTime('2024-04-01');
$diff = $date1->diff($date2);
$months = $diff->y * 12 + $diff->m;
echo $months;

DateInterval correctly accounts for varying month lengths.

Difference in Seconds

Using timestamps is the simplest method.

$seconds = abs(strtotime('2024-01-01 12:00') - strtotime('2024-01-01 12:10'));
echo $seconds;

Use timestamps when you need exact second-level differences.

Difference in Years

DateInterval automatically handles leap years.

$date1 = new DateTime('2020-02-29');
$date2 = new DateTime('2024-02-28');
$years = $date1->diff($date2)->y;
echo $years;

Difference From Now

Comparing any date to the current moment:

$target = new DateTime('2024-12-25');
$now = new DateTime();
$daysFromNow = $now->diff($target)->days;
echo $daysFromNow;

This produces the total number of days from today to the target date.

Difference in Minutes

Using timestamps:

$seconds = abs(strtotime('2024-01-01 12:00') - strtotime('2024-01-01 12:45'));
$minutes = intdiv($seconds, 60);
echo $minutes;

Converting from DateInterval:

$diff = (new DateTime('12:00'))->diff(new DateTime('12:45'));
$minutes = $diff->h * 60 + $diff->i;
echo $minutes;

Difference in Hours and Minutes

DateInterval can format the result directly.

$date1 = new DateTime('2024-01-01 08:00');
$date2 = new DateTime('2024-01-01 12:45');
echo $date1->diff($date2)->format('%h hours %i minutes');

Or compute total minutes and split:

$seconds = abs(strtotime('08:00') - strtotime('12:45'));
$totalMinutes = intdiv($seconds, 60);
$hours = intdiv($totalMinutes, 60);
$minutes = $totalMinutes % 60;
echo $hours . ' hours ' . $minutes . ' minutes';

Summary of Recommended Approaches

DateTime with diff is ideal for calendar aware calculations such as months, years, and full date comparisons. Timestamps are ideal for raw elapsed seconds, minutes, and hours when calendar rules are irrelevant. Use the DateInterval format method for clean combined output such as hours and minutes.

Validating Date Formats in Laravel

Validating date formats is essential when accepting user input that depends on accurate scheduling, calculations, or storage. Laravel provides clear, powerful validation rules for dates. Laravel developers often struggle to understand which rule to use, how strict validation should be, and how to enforce specific formats.

Basic Date Validation Rules

The date Rule

The date rule checks if the value can be parsed into a valid date by PHP’s strtotime function or Carbon. It does not enforce a particular format.

$request->validate([
    'start_date' => 'required|date',
]);

This ensures the input is a valid date but does not restrict how it is formatted.

The date_format Rule

The date_format rule checks if the value exactly matches a specified format.

$request->validate([
    'start_date' => 'required|date_format:Y-m-d',
]);

The value must match the format exactly.

Difference Between date And date_format

The date rule checks if the value is a real date. The date_format rule checks if the format matches. These rules serve different purposes.

Validating Dates With date_format

Single Format Example

$request->validate([
    'event_date' => 'required|date_format:d/m/Y',
]);

Accepts only values like 25/01/2025.

Multiple Accepted Formats

Use comma-separated syntax to match one of the given formats.

$request->validate([
    'event_date' => 'required|date_format:d/m/Y,m/d/Y',
]);

Laravel requires the value to match any of the formats in the date_format rule. In this case, it accepts both 25/01/2025 and 01/25/2025.

Common Format Patterns

Y - four digit year m - two digit month d - two digit day H - hours i - minutes s - seconds

Time And DateTime Validation

Validating Combined Date And Time

$request->validate([
    'scheduled_at' => 'required|date_format:Y-m-d H:i',
]);

Validating Full Timestamps

$request->validate([
    'timestamp' => 'required|date_format:Y-m-d H:i:s',
]);

Partial Datetime Inputs With required_with

$request->validate([
    'date' => 'required_with:time|date_format:Y-m-d',
    'time' => 'required_with:date|date_format:H:i',
]);

Validating ISO 8601 Date Formats

$request->validate([
    'published_at' => 'required|date_format:Y-m-d\TH:i:sP',
]);

Conclusion

Use either date to check if the value is a real date or date_format to enforce strict formatting, not both.

Validate Phone Numbers in Laravel

Phone number validation is a common requirement in modern applications. Clean and accurate phone data ensures reliable communication, proper user identity verification, and consistent database formatting. Laravel provides flexible tools for validating both simple and complex phone formats through built in rules, regex, custom rules, and third party libraries.

Basic Phone Number Validation Using Built In Rules

Using the required and numeric rules

For basic numeric phone input:

$request->validate([
    'phone' => ['required', 'numeric'],
]);

This ensures the value contains only digits. It is useful for local formats without symbols or country codes.

Using regex for simple patterns

Regex allows basic structure enforcement. For example, a ten digit local number:

$request->validate([
    'phone' => ['required', 'regex:/^[0-9]{10}$/'],
]);

Best practices when using regex

• Keep patterns minimal and readable.
• Avoid overly strict patterns that reject valid real world formats.
• Escape characters correctly to avoid unintended matches.

International Phone Number Validation

Understanding E.164 formatting

E.164 is the global standard for phone numbers. It requires a leading plus sign followed by up to fifteen digits. Example: +15551234567.

Regex for E.164 in Laravel validation

A reliable E.164 pattern:

$request->validate([
    'phone' => ['required', 'regex:/^\+[1-9][0-9]{1,14}$/'],
]);

Explanation:

• The value must start with a plus sign.
• The first digit cannot be zero.
• The number can contain up to fifteen digits.

Common pitfalls

• Allowing spaces or punctuation when using E.164.
• Accepting country codes starting with zero.
• Forgetting to anchor the regex pattern at the start and end of the string.

Using Custom Validation Rules

Creating a custom rule

Generate a rule class:

php artisan make:rule PhoneNumber

Implementing passes and message

Example rule enforcing E.164:

namespace App\Rules;
 
use Illuminate\Contracts\Validation\Rule;
 
class PhoneNumber implements Rule
{
    public function passes($attribute, $value)
    {
        return preg_match('/^\+[1-9][0-9]{1,14}$/', $value) === 1;
    }
 
    public function message()
    {
        return 'The :attribute field must be a valid phone number.';
    }
}

Using the custom rule inside Form Requests

public function rules()
{
    return [
        'phone' => [new \App\Rules\PhoneNumber],
    ];
}

This encapsulates validation logic and keeps controllers clean.

Validating Phone Numbers in Form Requests

Centralizing validation logic

Form Requests provide a dedicated location for validation. They improve maintainability and support custom messages, authorization, and reusable rules.

Example FormRequest with phone rules

namespace App\Http\Requests;
 
use Illuminate\Foundation\Http\FormRequest;
 
class StoreUserRequest extends FormRequest
{
    public function rules()
    {
        return [
            'phone' => ['required', 'regex:/^\+[1-9][0-9]{1,14}$/'],
        ];
    }
}

Custom messages and attribute naming

public function messages()
{
    return [
        'phone.regex' => 'Enter a valid E.164 phone number.',
    ];
}
 
public function attributes()
{
    return [
        'phone' => 'phone number',
    ];
}

Using Third Party Libraries for Advanced Validation

When to use a library

Use a library when you need country specific formatting, parsing, normalization, or validation beyond simple regex. This is helpful when supporting multiple regions.

Example using the propaganistas/laravel-phone package

Install the package:

composer require propaganistas/laravel-phone

Validate a phone number for a specific country:

$request->validate([
    'phone' => ['required', 'phone:US'],
]);

Validate an international phone number:

$request->validate([
    'phone' => ['required', 'phone:INTERNATIONAL'],
]);

Validate multiple possible countries:

$request->validate([
    'phone' => ['required', 'phone:US,CA'],
]);

Summary

Laravel offers powerful options for validating phone numbers ranging from simple digit checks to advanced international validation. Developers can use built in rules for straightforward cases, regex for structured formats, custom rules for complex logic, and external libraries for global accuracy. These tools allow applications to collect clean, consistent, and reliable phone data across diverse regions and use cases.

How to Get the Domain from a URL in PHP

Extracting a domain from a URL is a common need in PHP, whether you’re validating inputs, filtering analytics data, or handling redirects. PHP provides several reliable ways to do this, from built-in functions to regular expressions. This guide explains all the practical approaches, including how to remove subdomains when necessary.

Using parse_url() (Recommended)

The simplest and most reliable method is to use PHP’s built-in parse_url() function, which breaks a URL into its components.

Example:

<?php
$url = 'https://blog.example.co.uk/article?id=10';
 
$host = parse_url($url, PHP_URL_HOST);
echo $host; // Output: blog.example.co.uk

This retrieves the full host (including subdomains). It’s ideal for general use cases where you need the entire hostname.

Removing Subdomains to Get the Root Domain

When you only need the root domain (for example, example.co.uk instead of blog.example.co.uk), you can split the host and extract the last two or three parts intelligently.

Example:

<?php
$url = 'https://blog.example.co.uk';
$host = parse_url($url, PHP_URL_HOST);
 
$parts = explode('.', $host);
$count = count($parts);
 
if ($count > 2) {
    $domain = $parts[$count - 2] . '.' . $parts[$count - 1];
} else {
    $domain = $host;
}
 
echo $domain; // Output: example.co.uk

This works well for most standard domain structures, though country-code TLDs (like .co.uk, .com.au) may need extra handling depending on your requirements.

Using Regular Expressions (Quick but Limited)

You can also use a regex for simple extraction, though it’s not as reliable for complex domains.

Example:

<?php
$url = 'https://store.blog.example.com/path';
preg_match('/^(?:https?:\/\/)?(?:[^@\/\n]+@)?(?:www\.)?([^:\/\n]+)/', $url, $matches);
 
echo $matches[1]; // Output: store.blog.example.com

You can further process $matches[1] using the earlier subdomain-removal logic to isolate the root domain.

Retrieve the Current URL in Laravel

Accessing the current URL is a common requirement in Laravel applications whether for redirects, logging, analytics, or conditional logic. Laravel provides simple, expressive methods for retrieving the current URL, its full version with query strings, the base root, and even the previous page URL.

Get Current URL Without Query Paramteres

Laravel’s URL facade and the url() helper give you quick access to URL methods.

use Illuminate\Support\Facades\URL;
 
// Get the current URL (without query parameters)
$currentUrl = URL::current();

Example: If your browser is at https://example.com/posts?page=2, URL::current() returns:

https://example.com/posts

The global helper syntax works the same:

$currentUrl = url()->current();

Both produce the same result.

Getting the Full URL Including Query Parameters

To include query parameters in the result, use the full() method.

$fullUrl = URL::full();

Example output:

https://example.com/posts?page=2&sort=latest

You can also use the Request instance for the same:

$fullUrl = request()->fullUrl();

Both return the complete URL including query strings.

Using the Request Instance

The Request object provides several methods for interacting with the URL and path.

Get the Current URL (without query)

$plainUrl = request()->url();

Equivalent to URL::current().

Get the Full URL (with query)

$fullUrl = request()->fullUrl();

Equivalent to URL::full().

Get Only the Path

$path = request()->path();

Example: https://example.com/posts/42 → posts/42

Summary Reference

Why the Service Pattern Is a Mess in Laravel Projects

The Service Pattern started as a noble idea: separating business logic from controllers to keep things clean. But in real-world Laravel projects, it has become one of the most abused and misunderstood architectural choices. What was meant to bring clarity often ends up turning into a dumping ground for misplaced logic.

Let’s break down why this happens, how it leads to code chaos, and what better patterns you can use instead.

The Core Problem: It Lost Its Meaning

In Laravel projects, the term Service has become a catch-all label. When developers aren’t sure where to place logic, they often create a “service” class as a quick fix. Over time, these classes grow without structure or purpose.

Here’s what happens in practice:

1. Repository-like Services

Developers use a “service” to handle database queries, duplicating what a proper repository pattern (i.e. Eloquent) is meant for.

// app/Services/UserService.php
class UserService {
    public function all()
    {
        return User::all();
    }
 
    public function active()
    {
        return User::where('active', true)->get();
    }
}

This doesn’t add value, it’s just an unnecessary wrapper around the model. In Laravel, you don’t need the repository pattern at all. Eloquent ORM already is your repository layer. It provides query abstraction, data mapping, and expressive syntax out of the box.

The logic should live directly in the model using query scopes or custom query builders.

// app/Models/User.php
class User extends Model {
    public function scopeActive($query)
    {
        return $query->where('active', true);
    }
}

$users = User::active()->get();

Cleaner, readable, and perfectly aligned with Laravel’s conventions. There’s no need for an extra repository or service layer to wrap Eloquent.

2. Sub-Controller Services

Some developers offload all controller work into a service class. The controller becomes an empty shell, while the service becomes a bloated pseudo-controller.

// app/Services/UserService.php
class UserService {
    public function store(array $data)
    {
        $user = User::create($data);
 
        UserRegistered::dispatch($user);
 
        // more user creation logic ...
 
        return $user;
    }
}
 
// app/Http/Controllers/UserController.php
class UserController {
    public function store(Request $request, UserService $service)
    {
        return $service->store($request->validated());
    }
}

Do this instead:

// app/Actions/CreateUser.php
class CreateUser {
    public function execute(array $data): User
    {
        return User::create($data);
    }
}
 
// app/Http/Controllers/UserController.php
class UserController {
    public function store(StoreUserRequest $request, CreateUser $action)
    {
        $user = $action->execute($request->validated());
 
        UserRegistered::dispatch($user);
 
        return response()->json($user);
    }
}

3. Model Action Services

A common misuse of the service pattern is the “Model Action Service” approach where developers group every operation related to a single model into one giant class.

// app/Services/UserService.php
class UserService {
    public function create(array $data) { ... }
    public function deactivate(User $user) { ... }
    public function update(User $user) { ... }
}

At first glance, it looks organized because everything about the User model is in one place. But as the project grows, this becomes a bloated, unmaintainable class. Each method deals with different concerns such as business logic, notifications, integrations, and state changes, all jammed together.

Instead, use the Action Pattern to separate each behavior into its own focused class.

app/
├── Actions/
│   ├── ActivateUser.php
│   ├── DeactivateUser.php
│   ├── PromoteUser.php
│   └── SendWelcomeEmail.php

Each action handles one job and one job only, which makes your code:

• Easier to test
• Simpler to reason about
• Consistent in structure

Example:

// app/Actions/ActivateUser.php
class ActivateUser {
    public function execute(User $user): User
    {
        $user->update(['active' => true]);
        return $user;
    }
}

Then in your controller or service layer:

public function activate(User $user, ActivateUser $action)
{
    return response()->json($action->execute($user));
}

This separation keeps logic modular, predictable, and perfectly aligned with Laravel’s clean architecture style.

4. Utility or Services

Another frequent misuse is turning service classes into utility containers, generic helpers that perform unrelated, cross-cutting tasks.

// app/Services/HelperService.php
class HelperService {
    public function formatDate($date) { ... }
    public function slugify($string) { ... }
    public function toMoneyFormat($value) { ... }
}

At first, it seems convenient to centralize “handy” functions. But the moment you start adding random helpers here, this class becomes a miscellaneous landfill, a vague “service” that belongs nowhere.

A better approach:

app/
├── Utilities/
│   ├── CurrencyConverter.php
│   └── HtmlToMarkdownConverter.php

Each helper has a clear, single responsibility and descriptive name.

The key idea is: Utilities are not services. They are helpers that are lightweight, context-agnostic tools and deserve their own proper home.

5. 3rd-Party Integration Services

Integration logic (like Stripe or AWS) often ends up in generic “services,” again adding confusion.

// app/Services/StripeService.php
class StripeService {
    public function charge(User $user, $amount) { ... }
}

These belong in a dedicated Integrations namespace or directory.

app/
├── Integrations/
│   └── Stripe/
│       ├── StripeClient.php
│       ├── StripeCharge.php
│       └── StripeWebhookHandler.php

Each integration gets a proper structure and purpose.

Why This Is Dangerous

When the Service pattern becomes a catch-all:

• Naming loses meaning – “What does this service actually do?” becomes a common question.
• Maintenance becomes painful – Changing logic means hunting through arbitrary service methods.
• Testing is harder – Overly generic classes depend on too many parts of the app.
• Team communication breaks – Every developer has a different interpretation of “service.”

The Better Approach: Use the Right Pattern for the Right Job

Laravel gives you the flexibility to organize your logic cleanly. Instead of one vague “service” layer, use specific patterns and naming that convey intent.

Example: Clean Structure Without the Service Mess

app/
├── Actions/
│   └── CreateUser.php
├── Http/
│   └── Controllers/
│       └── UserController.php
├── Integrations/
│   └── Stripe/
│       └── StripeCharge.php
├── Models/
│   └── User.php
└── Utilities/
    └── CurrencyConverter.php

With this structure, you always know where to place logic and where to find it later. There’s no need for a generic “Service” directory at all.

Final Thoughts

The Service pattern became a mess in Laravel because it stopped meaning anything. It turned into a garbage bin for code developers didn’t know where to put. The solution isn’t to keep refining the “service” concept, it’s to stop using it as a default.

Use Eloquent ORM as your repository, Actions for actions performed on models, Integrations for external APIs, and Support for shared helpers or utilities. Let structure and naming communicate intent. That’s how you build Laravel projects that stay clean, maintainable, and scalable.

PHPUnit vs Pest: PHP Testing Framework Comparison

Testing is a non-negotiable part of modern PHP development. Among the most widely used frameworks, PHPUnit and Pest stand out as the dominant choices. Both are powerful, reliable, and actively maintained but they differ significantly in philosophy, syntax, and developer experience.

PHPUnit is the long-established standard in PHP testing, powering most enterprise and open-source test suites. It follows a traditional, class-based structure familiar to Java or .NET developers.

Pest, on the other hand, is a newer testing framework built on top of PHPUnit. It redefines PHP testing with a simpler, expressive, and elegant syntax while maintaining full PHPUnit compatibility.

Expectations API with fluent chaining and custom extensions

Pest introduces expect() with readable matchers and a first class way to create your own expectations. PHPUnit relies on assertion methods and custom constraints but has no built in fluent expectation layer.

Example

// Pest
expect($user->name)->toBe('John')->not->toBeEmpty();
 
// Custom expectation in tests/Pest.php
expect()->extend('toBeAdult', function () {
    return $this->toBeGreaterThanOrEqual(18);
});
 
// Usage
expect($user->age)->toBeAdult();

Functional test style with describe, it, higher order tests

Pest adds describe() and it() helpers and a higher order testing mode that removes boilerplate closures for common flows. PHPUnit stays class based and does not offer these helpers.

Example

// Pest
describe('sum', function () {
    it('adds integers', function () {
        expect(sum(2, 3))->toBe(5);
    });
});
 
// Higher order style example
test('home page')->get('/')->assertOk()->assertSee('Welcome');

Datasets that read naturally inline

Pest provides inline datasets and named datasets via ->with(...). PHPUnit has data providers, but the inline, fluent dataset style is a Pest convenience feature.

Example

it('accepts valid emails', function (string $email) {
    expect($email)->toMatch('/@/');
})->with([
    'jane@example.com',
    'john@acme.org',
]);

File and suite configuration via Pest helpers

Pest lets you bind a base test case, traits, and groups to files or directories using pest()->extend(), pest()->use(), and ->in(). PHPUnit config is XML oriented and class based. The fluent per directory binding is Pest specific.

Example

// tests/Pest.php
use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;
 
pest()->extend(TestCase::class)
    ->use(RefreshDatabase::class)
    ->in('Feature');

Lifecycle hooks expressed as closures across files or globally

Pest has beforeEach, afterEach, beforeAll, afterAll hooks with a functional style and global registration in tests/Pest.php. PHPUnit offers setup and teardown methods but not the closure based, global hook ergonomics.

Example

beforeEach(function () {
    $this->user = User::factory()->create();
});
 
afterAll(function () {
    // clean up external resources
});

Grouping with fluent API and directory level grouping

Pest adds ->group('name') and directory wide grouping through pest()->group()->in(). PHPUnit uses annotations or attributes but not the same fluent helpers.

Example

test('slow path', fn () => /* ... */)->group('slow');
 
// Directory level
pest()->group('feature')->in('Feature');

Browser testing built on Playwright

Pest v4 adds browser testing through an official plugin with simple visit() flows, screenshots, and visual regression helpers. PHPUnit does not include browser automation out of the box.

Example

it('welcomes the user', function () {
    $page = visit('/');
    $page->assertSee('Welcome');
});

Architecture testing

Write rules that enforce boundaries and naming by namespace or function patterns. This is a built in capability in Pest docs through the Architecture Testing section. PHPUnit has no native architecture rule DSL.

Example

arch()
    ->expect('App\\Http\\Controllers')
    ->toUse('App\\Http\\Requests');

Snapshot testing

Simple snapshot matching with a dedicated storage folder managed by Pest. PHPUnit does not ship a snapshot feature.

Example

it('renders contact page', function () {
    $response = $this->get('/contact');
    expect($response)->toMatchSnapshot();
});

Type coverage reporting

A plugin that reports type coverage without executing tests. PHPUnit does not provide this metric natively.

Command

composer require --dev pestphp/pest-plugin-type-coverage
./vendor/bin/pest --type-coverage

Profanity checker and more

Additional official plugins like Profanity and Stress testing are documented and integrate via the same fluent CLI options. PHPUnit does not have official equivalents.

Filtering and running tests with fluent chains in code

Beyond CLI flags, Pest lets you chain helpers like ->group() at call sites and use expressive describe based scoping. PHPUnit filtering is attribute or CLI driven and remains class centric.

Side by side summary

Practical starter templates

Convert a PHPUnit assertion to a Pest expectation

// PHPUnit
$this->assertSame(5, sum(2, 3));
 
// Pest
expect(sum(2, 3))->toBe(5);

Add a reusable expectation

// tests/Pest.php
expect()->extend('toBeUuid', function () {
    return $this->toMatch('/^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i');
});
 
// usage
expect($id)->toBeUuid();

Attach a base TestCase and a trait across a folder

// tests/Pest.php
use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;
 
pest()->extend(TestCase::class)->use(RefreshDatabase::class)->in('Feature');

Define architecture rules

arch()->preset()->php();      // start with sensible defaults
arch()->expect('App\\Models')->toOnlyBeUsedIn('App\\Services');

Add a snapshot check

it('has a contact page', function () {
    $response = $this->get('/contact');
 
    expect($response)->toMatchSnapshot();
});

Minimal browser test

it('may welcome the user', function () {
    $page = visit('/');
 
    $page->assertSee('Welcome');
});

Conclusion

Pest offers more features in addition to the ones I covered in this blog post. Choose PHPUnit when you want the classic class based xUnit core. Choose Pest if you want the same engine with an expressive API, functional test style, and an official plugin ecosystem that covers browser automation, architecture rules, snapshots, and type coverage out of the box.

How to Rollback Specific Migration Files in Laravel

Rolling back migrations is a normal part of Laravel development. You might add a migration, test it, and then need to undo only that specific change without affecting others. Laravel makes this possible through the --path option, allowing you to target individual migration files precisely.

Understanding Laravel Migration Rollbacks

Laravel migrations are version-controlled database schema files. When you run php artisan migrate, each migration file is executed in order, and its name is recorded in the migrations table.

To undo migrations, Laravel provides the following key commands:

• php artisan migrate:rollback
• php artisan migrate:reset
• php artisan migrate:refresh

Each can be combined with the --path option to rollback specific files instead of all migrations.

Rollback a Specific Migration File

If you want to rollback a single specific migration, use the migrate:rollback command with the --path option.

php artisan migrate:rollback --path=/database/migrations/2024_11_04_123456_create_orders_table.php

How It Works

• The --path option tells Laravel which migration file to target.
• The path should be relative to the base Laravel project directory.
• Laravel will execute the down() method of that specific migration file only.

This is the most direct and correct way to rollback one migration without touching others.

Rollback Multiple Specific Migration Files

You can rollback multiple specific files by specifying each --path argument individually:

php artisan migrate:rollback \
--path=/database/migrations/2024_11_04_123456_create_orders_table.php \
--path=/database/migrations/2024_11_04_123457_add_status_to_orders_table.php

Each listed file will have its down() method executed in order, rolling back only those migrations.

Reset or Refresh Specific Migration Files

In addition to rolling back, Laravel also lets you reset or refresh specific migrations.

Reset Specific Migration

To completely reset (rollback all migrations), but limit the rollback to certain files:

php artisan migrate:reset --path=/database/migrations/2024_11_04_123456_create_orders_table.php

Refresh Specific Migration

To rollback and re-run the same migration (useful during testing):

php artisan migrate:refresh --path=/database/migrations/2024_11_04_123456_create_orders_table.php

This command will:

1. Run the down() method (rollback).
2. Immediately run the up() method again (reapply the migration).

How to remove or uninstall PHP packages using Composer

When managing PHP dependencies, it’s essential to know not only how to install but also how to properly remove or uninstall packages. Composer provides a simple and safe way to do this while keeping your project clean and dependency-free of unused packages. This guide explains exactly how to remove packages, update dependencies, and verify changes clearly, correctly, and efficiently.

Remove a PHP Package Using Composer

Before removing anything, identify the package you want to uninstall to confirm that the package exists in your project before proceeding.

Run:

composer show

You can also search for a specific package:

composer show vendor/package-name

To remove or uninstall a package, use the remove command:

composer remove vendor/package-name

What this does:

• Uninstalls the specified package from the vendor/ directory.
• Removes it from your composer.json and composer.lock files.
• Automatically updates the autoloader to reflect the change.

Example:

composer remove guzzlehttp/guzzle

Composer will update your dependency tree and display a summary of the removed package and any other dependencies that are no longer needed.

Removing Multiple PHP Packages at Once using Composer

You can remove more than one package in a single command:

composer remove vendor/package-one vendor/package-two

Composer will uninstall both packages and clean up dependencies that are no longer used by your project.

Removing a Development-Only PHP Package

If the package was installed as a development dependency (with the --dev flag), you can remove it in the same way:

composer remove --dev vendor/package-name

This removes the package from the require-dev section of your composer.json.

Remove Manually by Editing composer.json (Not Recommended)

While you can manually delete a package entry from composer.json, it’s not recommended because:

• It won’t automatically update composer.lock.
• It won’t clean up the vendor/ directory.
• It can lead to inconsistent states.

If you do manually edit composer.json, always run:

composer update

afterward to synchronize and reinstall only the required packages.

Verify the Removal

After the removal process, confirm that the package is no longer listed in your dependencies:

composer show

You should also check your composer.json file to ensure that the package has been deleted from either the require or require-dev section.

Common Mistakes to Avoid

• Forgetting to run composer update or composer install after manual edits. Always sync your dependency files after editing.

• Removing a package that’s required by another dependency. Composer will warn you and block removal if the package is still in use elsewhere.

• Skipping autoload updates. If autoload references remain, run:

  composer dump-autoload

Always prefer using Composer’s built-in remove command instead of manual deletions. It ensures all references, autoloading, and dependency chains are properly updated keeping your PHP project stable, consistent, and lightweight.

How to Rollback the Last Migration Safely in Laravel

Rolling back migrations is a common part of Laravel development, especially during iterative schema changes. However, doing it incorrectly can lead to data loss or inconsistent states. This guide explains how to safely rollback the last migration in Laravel, when to use each command, and how to handle production environments properly.

Check Migration Status

Before rolling back, always confirm the current state of your migrations:

php artisan migrate:status

This lists all migrations with a status column (Ran?). It helps you verify which migrations are active and which batch they belong to.

Simulate a Rollback Without Making Changes

Laravel provides a dry-run mode using the --pretend option. This command shows the SQL statements that would be executed during a rollback without applying them.

php artisan migrate:rollback --pretend

This is especially useful for verifying what changes will occur before actually rolling back your database. It helps prevent accidental data or schema loss.

Rollback the Last Migration

To rollback only the most recent batch of migrations (the last run), use:

php artisan migrate:rollback

To rollback only the last migration, use:

php artisan migrate:rollback --step=1

Example

If you’ve run three migration batches so far:

Running:

php artisan migrate:rollback

will undo only Batch 3 removing the last two migrations.

While running:

php artisan migrate:rollback --step=1

will undo the last migration only (2024_10_03_000000_add_slug_to_posts) removing the last migration.

RollBack and Re-Migrate the Last Migration

To rollback the last batch and immediately reapply it (useful for quick iteration locally):

php artisan migrate:refresh --step=1

This command combines rollback and migrate into one action, which is ideal for testing recent schema changes.

Safely Rolling Back in Production

In production environments, rollback actions can cause data loss or downtime. To protect against accidental schema drops, Laravel requires confirmation:

php artisan migrate:rollback --force

php artisan migrate:rollback --step=1 --force

Safe Practice

• Always back up your database before rolling back in production.
• Ensure that every migration’s down() method reverses changes cleanly (e.g., drops columns, foreign keys, or tables that were created in up()).
• Use Laravel’s Schema::hasTable() and Schema::hasColumn() checks to make rollback methods idempotent and avoid exceptions.

Example Safe Down Method:

public function down()
{
    if (Schema::hasColumn('posts', 'status')) {
        Schema::table('posts', function (Blueprint $table) {
            $table->dropColumn('status');
        });
    }
}

Final Safety Checklist

1. Run migrate:status to confirm which migrations you’re affecting.
2. Use dry-run mode using the --pretend option to verify the changes without actually running them.
3. Ensure backups are in place before rolling back.
4. Double-check down() methods for reversibility and safety.
5. Use --step and --force flags deliberately (never blindly).
6. For production, test rollbacks in staging first.

Required PHP Version for Laravel 12

Laravel 12 requires PHP 8.2 or higher to run. This version requirement aligns with Laravel's commitment to supporting modern PHP features, improved performance, and better type safety.

How to Check the Required PHP Version for Any Laravel Version

To check which PHP version is required for a specific Laravel release, follow these steps:

1. Go to the laravel/laravel GitHub repository.
2. Switch to the branch corresponding to the version you want to check (for example, 12.x, 11.x, etc.).
3. Open the composer.json file.
4. Find the require section and you’ll see the PHP version requirement listed like this:

"require": {
    "php": "^8.2",
    ...
}

This ensures you always verify against the official and most accurate source.

How to Check Your PHP Version

You can quickly verify your PHP version using the following command:

php -v

Example output:

PHP 8.2.12 (cli) (built: Sep 27 2024 15:00:00) (NTS)

If the version displayed is 8.2.0 or higher, you’re ready to install Laravel 12.

How to Upgrade PHP

If your PHP version is lower than 8.2, upgrade it before creating or running a Laravel 12 project.

On Ubuntu / Debian

sudo add-apt-repository ppa:ondrej/php -y
sudo apt update
sudo apt install php8.2 php8.2-cli php8.2-common php8.2-mbstring php8.2-xml php8.2-bcmath php8.2-curl php8.2-zip -y

On macOS (Homebrew)

brew update
brew install php@8.2
brew link php@8.2 --force

On Windows

1. Download PHP 8.2 from windows.php.net/download.
2. Extract it and update your system PATH variable to include the PHP directory.

Verifying Compatibility Before Installing Laravel 12

If you’re installing Laravel 12 using Composer, you can confirm your PHP version meets the requirement by running:

composer create-project laravel/laravel example-app "^12.0"

If your PHP version is below 8.2, Composer will show an error similar to:

Your PHP version (8.1.12) does not satisfy that requirement.

Upgrade your PHP installation, and rerun the command.

Summary

• Required PHP version: 8.2 or higher
• Reason: Laravel 12 uses new PHP 8.2 language features
• Check PHP version: php -v
• Check required PHP for any version: View the composer.json in the respective Laravel branch on GitHub
• Upgrade: Use your OS-specific package manager or installer