That error is popping up because you're adding a manual error to the validator without a numeric key. Laravel Excel expects the attribute name to follow a specific pattern (like row_number.column) so it can parse the row index. When you just pass 'Green Bean', strtok fails to find a numeric row index, passing a string to the Failure constructor instead.

Also, your current logic for checking the bean in the collection method won't work for validation because rules() and withValidator() run before the collection() method even touches the data.

namespace App\Imports;

use Maatwebsite\Excel\Concerns\ToCollection; use Maatwebsite\Excel\Concerns\WithHeadingRow; use Maatwebsite\Excel\Concerns\WithValidation; use Illuminate\Support\Collection;

class RoastImport implements ToCollection, WithHeadingRow, WithValidation { public function collection(Collection $rows) { // Your import logic here }

public function rules(): array
{
    return [
        // 'beans' matches the slugified header 'Beans'
        'beans' => ['required', 'exists:green_beans,name'],
        // 'out_g' matches 'Out (g)'
        'out_g' => ['required', 'numeric'],
    ];
}

public function customValidationMessages()
{
    return [
        'beans.exists' => 'The selected Green Bean is invalid.',
        'out_g.required' => 'The Out (g) column cannot be empty.',
    ];
}

}

Hey man, been there. A 403 Forbidden on the broadcasting/auth route almost always means your frontend is successfully hitting the endpoint, but Laravel is explicitly rejecting the authorization for that specific private channel.

Hey motinska94, I hear you loud and clear.

First off, keep your head up. Being an unemployed student is a tough grind, but the fact that you are actively seeking out high-quality resources to learn Laravel shows you have the exact right mindset for this industry.

I completely understand why that comment stung. When you live and work in the US or Western Europe, $15 truly is just the cost of a quick lunch. But you are 100% right the global economy doesn't run on the USD. In many parts of the world, including Turkey, $15 is a significant chunk of change. Your Spotify comparison is spot on and really puts things into perspective.

Jussi is spot on about mixing npm/yarn and the missing SCSS file. Stick to npm run dev since you already built your node_modules with npm install. For that missing admin.scss file, double check your .gitignore it’s very common for custom asset directories to accidentally get ignored, meaning it never actually made it to your Github repo in the first place.

Regarding the "Firefox can't connect" error, that's entirely a local DNS/WAMP issue, not a Laravel bug. Your OS simply doesn't know where to route mysite.local

This happens because the starter kits (Breeze/Jetstream) wrap that verification route in the auth middleware by default. When you open the link in a different browser, you're a "guest," so the middleware intercepts the request and redirects you to the login page before the verification logic even runs.

To fix this, you need to allow guests to hit that endpoint and manually find the user since $request->user() won't be available.

First, in routes/auth.php, move the route outside the auth middleware group, Then, you'll need to tweak the VerifyEmailController. Since you aren't using the auth middleware anymore,

You already hit the nail on the head observers only fire on database operations, and time passing isn't a database operation.

Like the others mentioned, a scheduled command running everyMinute(). Instead of adding a published_processed_at timestamp though, I usually just rely on a status column (e.g., switching it from scheduled to published). Grab records where published_at <= now() and status === 'scheduled', fire your service, and update the status.

Since the login and public pages are hitting, Nginx is likely configured correctly. This usually boils down to Filament’s own authorization layer or basic directory permissions on the AWS instance.

please check this one, This is the most common culprit. In production, Filament restricts access by default. Ensure your User model implements the FilamentUser interface and that the canAccessPanel method is actually returning true for your account.

another check in file permission, sudo chown -R www-data:www-data storage bootstrap/cache sudo chmod -R 775 storage bootstrap/cache

That MGET strategy for BelongsTo is definitely the right call saves a ton of overhead compared to standard query caching.

I’m curious about the hydration side of things. When you're pulling a large collection and stitching all those normalized models back together, have you noticed much of a CPU hit on the PHP side? Reconstructing Eloquent models in a loop can get pricey if the collection is huge.

Also, how are you handling count() or exists()? Do those get their own entries in the query map, or are they just bypassing the cache for now?

Hey Kai, really solid concept here. Dealing with Redis memory bloat from duplicate query collections is a massive headache, especially on some of the larger Laravel apps I manage where tables easily hit 60M+ records. Bringing the Redux/Apollo normalized store pattern to Eloquent is a brilliant approach to solving that.

Quick question on the architecture: how are you handling eager loaded relationships (with())? Does the package normalize the nested models and just store their IDs on the parent, or are they embedded directly within the parent model's cached payload?

Hey everyone 👋

Over the past few months, I’ve been working on a small open-source package called laravel-normcache.

It actually started from a problem I kept running into across a few different projects. I found myself repeatedly building the same kind of caching layer to avoid redundant Eloquent data sitting everywhere in Redis, so eventually I thought: why not turn it into a reusable package.

A lot of the ideas are inspired by patterns used in things like Redux/Apollo normalized stores, and I’ve been experimenting and refining things as I use it across real projects.

The main idea behind laravel-normcache is normalizing cached Eloquent results instead of storing entire query collections repeatedly. It stores individual models and query ID maps separately, so when one model changes, every cached query containing that model automatically reflects the update.

Query cache  →  "posts where active=1, page 2"  →  [4, 7, 12]
Model cache  →  post:4  →  { id:4, title:..., body:... }
             →  post:7  →  { id:7, title:..., body:... }
             →  post:12 →  { id:12, title:..., body:... }

Some things it currently does:

• Automatic caching + invalidation with just a single trait
• Avoids storing duplicate model data across query caches
• Instant consistency across cached query results
• O(1) invalidation using versioned cache keys
• Uses dramatically less Redis memory compared to traditional query caching approaches

There’s still plenty I want to improve and optimize over time, but I felt it was finally in a good enough place to share with the community.

Here’s a quick benchmark comparing direct DB queries vs laravel-model-cache for reference:

I’d genuinely appreciate any feedback, criticism, ideas, or contributions from people more experienced than me. I’m mainly here to learn and improve as an open-source developer.

Repository: https://github.com/kai-init/laravel-normcache

Thanks for reading 🙏

That error is popping up because you're adding a manual error to the validator without a numeric key. Laravel Excel expects the attribute name to follow a specific pattern (like row_number.column) so it can parse the row index. When you just pass 'Green Bean', strtok fails to find a numeric row index, passing a string to the Failure constructor instead.

Also, your current logic for checking the bean in the collection method won't work for validation because rules() and withValidator() run before the collection() method even touches the data.

namespace App\Imports;

use Maatwebsite\Excel\Concerns\ToCollection; use Maatwebsite\Excel\Concerns\WithHeadingRow; use Maatwebsite\Excel\Concerns\WithValidation; use Illuminate\Support\Collection;

class RoastImport implements ToCollection, WithHeadingRow, WithValidation { public function collection(Collection $rows) { // Your import logic here }

public function rules(): array
{
    return [
        // 'beans' matches the slugified header 'Beans'
        'beans' => ['required', 'exists:green_beans,name'],
        // 'out_g' matches 'Out (g)'
        'out_g' => ['required', 'numeric'],
    ];
}

public function customValidationMessages()
{
    return [
        'beans.exists' => 'The selected Green Bean is invalid.',
        'out_g.required' => 'The Out (g) column cannot be empty.',
    ];
}

}

Since you're running a payment gateway, daily dumps are nowhere near enough. You’re dealing with high-stakes transactional data where even 5 minutes of data loss could be a reconciliation nightmare.

In your position, you need to think about RPO (Recovery Point Objective). If the DB blows up at 11:59 PM, and your last dump was 12:00 AM, can you afford to lose 23 hours of transactions? Probably not.

Yeah, laravel-ide-helper is almost certainly your culprit. It generates those massive stub files that end up clashing with Intelephense’s own indexing. When you see update() asking for 4 params, it's usually because the LSP is getting confused between the real Eloquent source and the helper's generated stubs.

Honestly, for Laravel 13, you can kill the ide-helper entirely. The official Laravel extension combined with a paid Intelephense license handles almost everything natively now.

Assuming you're on v3, Livewire::listen is for events, not lifecycle hooks. You need to use Livewire::hook.

For global property updates, you should hook into commit:

use Livewire\Livewire;

public function boot(): void
{
    Livewire::hook('commit', function ($component, $commit) {
        // You can inspect $commit->updates for specific property changes.
    });
}

If you specifically need to run logic before the component finishes its cycle, commit is the standard way to intercept that in v3.

Since you're moving to an S3-compatible bucket on Cloud, the cleanest way to handle 10GB is using rclone directly from your Forge server. Install rclone: sudo apt install rclone

16 reqs/second is actually quite low for a modern SQL database. You should be able to hit 500+ reqs/s on a single instance without breaking a sweat, provided your indexing is solid. You might be over-engineering a bit early.

That said, if you want to move forward with replication for reports and metrics, that’s exactly the right use case for it. To handle the integrity/delay concern you mentioned, Laravel has a sticky option in the database config.

'sticky' => true, When sticky is enabled, if you perform a write during a request cycle, Laravel will immediately switch to using the write connection for any subsequent reads within that same request. This solves the "read-your-own-writes" problem where a user saves data but doesn't see it on the next line of code because the replica hasn't synced yet.

I've been through this exact "extension bloat" cycle. If you're on PHP 8.5 and Laravel 13, you definitely have some redundancy fighting for CPU cycles.

My recommended "Lean" Stack: Intelephense, Laravel, Laravel Pint, PHPStan,

I have to respectfully disagree with the suggestion to use traits here. Moving code into traits just to make a file shorter is an anti-pattern it sweeps the mess under the rug but doesn't fix the underlying architectural issue.

Right now, your ActivityService is turning into a God Class because it violates the Single Responsibility Principle. It's handling activity creation, activity deletion, and notification management across multiple distinct domain

My bad you're right, I crossed the streams with the package syntax there.

In native Laravel 13, you need to use the Relation class within your resource's relationships() method. Instead of just returning a string or a simple callable, you return a relation object, which actually has the meta() method built-in.

Try this structure:

use Illuminate\Http\Resources\JsonApi\Relation;

public function relationships(Request $request): array
{
    return [
        'items' => Relation::toMany('items')
            ->meta(fn ($item) => [
                'pivot_data' => $item->pivot->your_column,
            ]),
    ];
}

Honestly, ignore the AI on this one. What you’ve written is a solid, clean Action class. It’s readable, it handles the transaction properly, and it gets the job done.

EDA is fantastic for decoupling, but it’s absolute overkill for a simple stock adjustment. You only really need to go down that road if a stock change needs to trigger a bunch of unrelated side effects like hitting a third-party API, sending emails, or clearing remote caches and you don't want to bloat your main logic.

Profiling basically means "measuring" your code while it runs to see exactly which part is taking the most time. It stops the guessing game.

Since you're seeing this locally too, that’s actually a win it means you can fix it without touching the production server.

The quickest way to do this in Laravel is to install Laravel Debugbar. Run this in your terminal:

composer require barryvdh/laravel-debugbar --dev

Once installed, refresh your slow page. A bar will appear at the bottom. Check these two tabs:

Timeline: This shows you the "execution" flow. If you see a massive gap/block, that’s your bottleneck.

Queries: This shows every database call. If one query is taking 2 seconds or you have 500 duplicate queries (N+1 issue), you’ll see it here instantly.

I'm completely with @martinbean on this one. Over the last decade building large-scale SaaS and ERP systems, every time my team tried to force a strict DDD or custom modular folder structure, we ended up fighting the framework.

Laravel's default structure is incredibly scalable if you just lean into sub-namespaces.

For interfaces, sticking to app/Contracts works perfectly. If a feature has multiple implementations (like different payment gateways or SMS providers), build a Manager class. It mimics how Laravel handles its own core components and makes swapping implementations painless.

The v13 native JSON:API implementation is solid, but the docs are definitely a bit light on the deeper relationship customizations right now.

You can chain the meta() method directly onto your relationship definition. Since you're dealing with pivot values, you can pass a closure to meta() which receives the related model, allowing you to pull those pivot fields dynamically.

Honestly, obfuscation in the PHP world is always a bit of a trade-off. If you’re dead set on it, IonCube or SourceGuardian are really your only professional options, but be prepared for some debugging headaches since Laravel's reflection and dependency injection can get grumpy when the source is mangled.

This is a solid update. Postgres support is huge, especially for catching those missing FK indexes that usually don't surface until you're under heavy load. I'm curious to see how the JSON vs JSONB analysis holds up on some of my messier schemas. Nice work on this!

That is strange, but it usually happens for one of two reasons: either the users who replied to you were flagged as spam, or they deleted their accounts entirely.

If you don't have a dedicated PostCollection class, it falls back to a basic ResourceCollection. That's where you lose the JSON:API specific behavior like the included key that PostResource::collection() handles automatically via AnonymousResourceCollection.

Hey Vincent,

You're missing a return statement in your controller. Inertia requires a redirect after a mutation (POST/PUT/PATCH/DELETE) so it can fetch the fresh page props under the hood.

public function update(Request $request, Category $category)
{
    $category->fill($request->all());
    $category->save();

    return back(); // <-- You need this
}

yes

If you want to use that /upgrade-laravel-v13 command on your Macbook, you'll need to install the actual Claude Code CLI in your terminal and run it from your project root. If you prefer to stick with PHPStorm's chat panel, it won't recognize the slash command you'll basically just have to copy/paste the upgrade guide instructions from the Laravel docs directly into the prompt so the assistant knows what to do.

Hey everyone,

After relying on Laragon for years, I’m looking at moving my local workflow over to Flyenv. As my stack has gotten more complex over the last decade, I want a cleaner containerized setup, but ideally with less friction than managing raw Docker compose files or Sail for every single project.

For those of you actively using Flyenv how is it holding up as your daily driver? I’m mainly curious about the performance compared to Laragon's native speeds, and if there are any weird local networking or routing quirks I should watch out for before I migrate a dozen active client projects over.

Appreciate any insights!

Hey Vincent,

Definitely go with One Product -> Multiple Prices.

Having architected a few different SaaS platforms over the years, this is the standard and most scalable approach. If Plan A, B, and C are just feature tiers of the exact same application, Stripe is perfectly designed to handle them as distinct recurring Prices attached to a single Product.

Stop running increment() or decrement() during the HTTP request. Dispatch a job (e.g., UpdateMerchantBalance). The API responds immediately, and your queue workers deal with the lock waiting in the background. The workers will still wait on each other for that specific row, but your web server won't hang and the user won't experience timeouts.

Livewire v4 changed how property hydration/updates work internally, and wire-elements/livewire-strict hasn’t been updated to hook into those changes. In v3 it relied on middleware/hooks that simply don’t fire the same way anymore in v4, so lockProperties() becomes a no-op.

Ghabriel is definitely on the right track, but since you're querying by username instead of the default id, you should use explicit Route Model Binding. You don't need to manually query the database in every single method.

Spot on. Vite's underlying file watcher (chokidar) is notorious for spinning up the CPU when it tries to index massive directories like vendor and node_modules, especially depending on your OS or if you're running WSL/Docker. Limiting the scope for both Vite and Wayfinder is the exact right move here.

One quick tip: you might also want to add /public/build/ and /bootstrap/cache/ to that ignore array just to be entirely safe from unnecessary rebuild loops.

organization owner is the one who needs to generate the token

The single-request approach is a ticking time bomb for max_execution_time and memory exhaustion. Once users start dropping gigabytes of files, your server will choke and browser connections will timeout. You can use Chunked Uploads or Asynchronous Processing

@martinbean Ouch! Not a bot, I just like formatting my answers clearly with markdown and code snippets. But I actually agree with your primary point @adamnet, Martin is right that handling this via roles/permissions in a single project is usually the standard Laravel way to handle this, unless there is a strict hardware/business reason forcing them to live on completely different servers.

In Project 1 (The Storage Owner)

Create a protected controller that handles the file logic. Use a custom middleware or a simple API token to ensure only Project 2 can hit these endpoints.

// routes/api.php
Route::prefix('internal-docs')->group(function () {
    Route::get('/', [DocumentController::class, 'index']);      // List files
    Route::get('/{name}', [DocumentController::class, 'show']); // Stream/Download
    Route::delete('/{name}', [DocumentController::class, 'destroy']); // Delete
});

// DocumentController.php
public function show($name) {
    if (!Storage::disk('private')->exists("documents/{$name}")) abort(404);
    
    return Storage::disk('private')->response("documents/{$name}");
}

public function destroy($name) {
    Storage::disk('private')->delete("documents/{$name}");
    return response()->json(['message' => 'Deleted']);
}

Project 2 (The Admin Project)

You don't need the physical files. You just need to "proxy" the requests. When an admin wants to see a PDF, Project 2 fetches it from Project 1 and serves it to the admin's browser.

// Project 2 Controller
public function proxyView($fileName) {
    $response = Http::withToken('your-secret-token')
        ->get("https://project1.test/api/internal-docs/{$fileName}");

    return response($response->body(), 200, [
        'Content-Type' => 'application/pdf',
        'Content-Disposition' => 'inline; filename="'.$fileName.'"'
    ]);
}

I try to Keep a physical notepad right under your keyboard and i try to avoid Nuke the feeds

Hey Vincent,

You're missing a return statement in your controller. Inertia requires a redirect after a mutation (POST/PUT/PATCH/DELETE) so it can fetch the fresh page props under the hood.

public function update(Request $request, Category $category)
{
    $category->fill($request->all());
    $category->save();

    return back(); // <-- You need this
}

99% of the time I see this break, it's because you are testing locally over HTTP.

The __Host- prefix tells the browser to strictly enforce HTTPS. If you're using php artisan serve or an un-secured Valet/Herd site, the browser will silently drop the cookie. Inertia then fails to authenticate because the session cookie literally doesn't exist in your browser, causing 419 or 401 errors.

'cookie' => env('APP_ENV') === 'production' 
    ? '__Host-' . Str::slug(env('APP_NAME', 'laravel'), '_') . '_session'
    : Str::slug(env('APP_NAME', 'laravel'), '_') . '_session', 

Also, triple-check your .env file. If you have SESSION_DOMAIN=localhost (or anything else), remove it entirely. The __Host- spec requires the domain attribute to be completely omitted, not just null.

Go to Settings > Languages & Frameworks > Style Sheets > Tailwind CSS. Ensure your Node interpreter is set and the path to your tailwind.config.js is correct

If both projects are on the same server, the quickest way is a symbolic link.

ln -s /path/to/project-1/storage/app/private/documents /path/to/project-2/storage/app/private/project1_docs

However, if you're looking for the "correct" architectural way or if these projects might move to different servers, you have two main options:

You can do this one

Move the files to an S3 bucket or DigitalOcean Space. Both projects can then use the s3 driver in config/filesystems.php to point to the same bucket. It handles permissions and scaling without you worrying about physical paths.

or do via API Proxy

If Project 1 must remain the "owner" of the files, create a secured endpoint in Project 1 that streams the file:

// Project 1 - Controller
public function show(Document $doc) {
    // Validate Project 2's request/token
    return Storage::disk('private')->download($doc->path);
}

Then, in Project 2, you'd use Http::withToken(...)->get() to fetch or stream it to the user.

intercept the click, show the alert, and then trigger the method via $wire if they confirm.

Drop the <script> hook entirely and just do this on your view:

<button 
    x-data 
    @click.prevent="
        Swal.fire({
            title: 'Are you sure?',
            text: 'This action is permanent!',
            icon: 'warning',
            showCancelButton: true,
            confirmButtonText: 'Yes, delete it!'
        }).then((result) => {
            if (result.isConfirmed) {
                $wire.delete({{ $id }})
            }
        })
    "
>
    Delete
</button>

alse use wire:confirm:

<button wire:click="delete({{ $id }})" wire:confirm="Are you sure? This action is permanent!">
    Delete
</button>

This happens because of how Livewire scopes its DOM tree. When you push the search input into <x-slot name="rightSection">, Blade extracts that code and renders it outside of your Livewire component's root <div> in the app-admin.blade.php layout. Livewire only tracks and hydrates wire:model bindings that live inside its root element (which is what gets rendered in {{ $slot }}). Because the named slot is injected elsewhere in the DOM, Livewire's JavaScript simply can't see it.

Keep the input physically inside your Livewire component's default slot, but "teleport" it visually to the header.

Add an ID to the target container in your app-admin.blade.php layout:

<div id="right-section-container" class="flex justify-center items-center gap-2">
    {{ $rightSection ?? '' }}
</div>

In your Livewire component, remove the search input from the <x-slot> and use <template x-teleport="..."> inside your main default slot:

<div>
    <x-slot name="title">...</x-slot>
    <x-slot name="breadcrumbs">...</x-slot>
    <x-slot name="rightSection">
        <x-buttons.create href="#" x-data="{}" x-on:click="$dispatch('open-modal', { name: 'create-job-title' })" :name="__('app.create_job_title')" />
        <x-dropdowns.per-page />
    </x-slot>

    <template x-teleport="#right-section-container">
        <x-inputs.search wire:model.live="search" />
    </template>

    </div>

This keeps the input inside Livewire's component state/scope while rendering it exactly where you want in the layout UI.

Hi everyone,

I'm building a SaaS application where users can connect their own business email accounts. I'm storing their email credentials and dynamically configuring the mailer so they can read and reply to emails directly from the app.

Viewing the incoming emails works perfectly fine, but I'm running into an issue when trying to send an outgoing email (specifically, replying to a message).

Whenever the app attempts to send, it fails and throws this error in my logs:

[2026-04-23 11:31:03] production.ERROR: PHP Request Shutdown: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN (errflg=1) {"userId":1,"exception":"[object] (ErrorException(code: 0): PHP Request Shutdown: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN (errflg=1) at Unknown:0)

Here is the method I'm using to dynamically configure the SMTP settings and send the email:

private function attemptSend(EmailAccount $account, array $data, ?string $encryption, $port): void
{
    app('mail.manager')->purge('smtp');

    config([
        'mail.mailers.smtp.host'       => $account->smtp_host,
        'mail.mailers.smtp.port'       => $port,
        'mail.mailers.smtp.encryption' => $encryption,
        'mail.mailers.smtp.username'   => $account->username,
        'mail.mailers.smtp.password'   => $account->password,
        'mail.from.address'            => $account->email,
        'mail.from.name'               => $account->label,
        
        'mail.mailers.smtp.stream' => [
            'ssl' => [
                'allow_self_signed' => true,
                'verify_peer'       => false,
                'verify_peer_name'  => false,
            ],
        ],
    ]);

    Mail::mailer('smtp')->send([], [], function ($message) use ($data, $account) {
        $message->from($account->email, $account->label)
                ->to($data['to'])
                ->subject($data['subject'])
                ->html($data['body']); 

        if (!empty($data['in_reply_to'])) {
            $headers = $message->getHeaders();
            $headers->addTextHeader('In-Reply-To', $data['in_reply_to']);
            $headers->addTextHeader('References', $data['in_reply_to']);
        }
    });
}

As you can see, I even tried forcing the stream context to ignore SSL verification just in case it was a strict certificate issue, but the error persists.

Has anyone run into this AUTH=PLAIN security problem when dynamically configuring mailers in Laravel? Any guidance on what I might be missing here would be hugely appreciated!

Thanks in advance!

use http, useragent, to make it more safe

looking good listen, but i try to avoid these as each application need different needs based on application structure i install these package which the application super faster, unnecessary data make it more complex