Hi r/laravel,

E-invoicing is becoming mandatory across Europe: Belgium since January 2026, France from September 2026, Germany from 2027, and EU-wide for cross-border trade from 2030. A PDF rendered from a Blade view is no longer enough: the invoice has to carry structured EN 16931 data as XML, either embedded in the PDF (ZUGFeRD/Factur-X) or as pure XML (UBL, Peppol, XRechnung).

There are solid low-level PHP libraries for writing that XML, but in my projects I kept rebuilding the same things around them: calculating totals and VAT correctly, validating against the official rules, a decent-looking PDF, storage, mail, tests. So I built Quittio, which does all of that the Laravel way:

$result = Quittio::invoice()                    // seller comes from config/quittio.php
    ->number('RE-2026-0042')
    ->deliveryDate('2026-09-30')
    ->buyer(Party::make('Kunde AG')
        ->vatId('DE987654321')
        ->address('Bahnhofstraße 5', '54321', 'Beispielstadt', 'DE'))
    ->line('Web development', netPrice: '95.00', quantity: 24, unit: UnitCode::Hour)
    ->line('Hosting', netPrice: '49.00', unit: UnitCode::Month)
    ->dueInDays(14)
    ->render();                                 // picks ZUGFeRD, XRechnung or plain PDF

return $result->download();

What it does:

• Calculates totals and VAT itself according to EN 16931. Amounts are strings or BigDecimal, floats are rejected.
• Picks the format per buyer: ZUGFeRD for businesses, XRechnung for public authorities, a plain PDF for consumers. Or you name one.
• Validates in several levels, from the EN 16931 and German rules in PHP up to the official KoSIT validator and veraPDF.
• Reads incoming ZUGFeRD and XRechnung invoices back into objects.
• Renders PDF/A-3 with mPDF (no Chromium, no Node) from Blade templates you can publish and restyle.
• Laravel integration: facade, config, mail attachments, queue, events and Quittio::fake() for your tests.
• Germany is fully supported by a country pack (VAT law rules, tax presets, DIN 5008 layout). Elsewhere the EN 16931 rules apply, so Factur-X, UBL and Peppol invoices work today. National rules come as country packs, and the pack contract is documented if you want to add your country.

The PDF looks the way you want:

The default template is only a starting point. You can change as much or as little of the design as you like, in four steps:

• Config only: logo, colours, font, salutation and closing texts, footer columns, sender line, paper size, fold marks and the payment QR code are set in config/quittio.php. You can also override them per invoice, e.g. for several brands in one app.
• Single partials: php artisan vendor:publish --tag=quittio-views and change only the parts you need, like the letterhead, the line table or the footer.
• Your own design: php artisan make:quittio-template my-design gives you a complete copy of the layout to build a completely different design in plain Blade and CSS, then select it with ->template('invoices.my-design.layout') or set it as the default.
• Your own renderer: if mPDF is not enough, plug in another one with Quittio::extend('renderer', ...).

Your own branding is just a few lines of config:

// config/quittio.php
'pdf' => [
    'logo' => resource_path('images/logo.svg'),
    'colors' => ['primary' => '#0f766e', 'text' => '#111827', 'muted' => '#6b7280'],
    'font' => 'inter',
],

Templates only display data: totals, VAT and labels are prepared in a view model, and the same data produces the XML. So you can redesign the PDF freely without breaking the e-invoice, and a guard throws an exception (or logs it in production) if your template leaves out a value the law requires on the invoice.

quittio/quittio (core, Laravel integration and the German pack) is MIT licensed. Later I plan to add a separate commercial package for full invoicing (gapless numbering, archive, cancellations, audit log); everything listed above is in the free package.

This is version 0.1.0 A tax adviser is reviewing the legal wording of the German pack, so texts may still change before 1.0.0

I would love your feedback, especially:

• Is the API pleasant to use? What would you expect to work differently?
• Have you had e-invoices rejected by a customer's or an authority's system? Which errors?
• If you are outside Germany: which country would you need next?

GitHub: https://github.com/Quittio/quittio

Docs: https://docs.quittio.dev

The docs also come with llms.txt, an MCP server and Laravel Boost guidelines, so your AI assistant knows the API too.

I found a moderate severity security bug in a Laravel package. The SECURITY.md file says to email Taylor which I did in August but got no response. Last Monday, I submitted a private GitHub security advisory with a proposed fix and I've still heard nothing.

What next?

Laravel Slipway treats config/slipway.php as the source of truth for CI/CD and compiles it to GitHub Actions, GitLab CI, Bitbucket Pipelines and CircleCI. A guard job fails the build if someone hand-edits the YAML.

The bit that was missing: you still had to push to see if the pipeline itself was broken. 1.7 adds:

php artisan slipway:test-pipeline

It writes ci-local.sh from the same config, boots Docker, and runs a stage. Interactive terminals ask which driver, stage and PHP version. --no-run writes the script only. Secrets are read from .env at runtime and never written into the file.

Limitation: a GitHub local run uses a php-cli container, not setup-php / actions/checkout. If you have a custom bootstrap (gd, extra apt packages), use --driver=bitbucket (or gitlab / circleci). Rollback still does not undo database migrations.

https://github.com/usamamuneerchaudhary/laravel-slipway

Let me know your thoughts?

Hey all,

I wrote 5 advanced code-heavy articles on how I prefer to review code with a specific rulebook and how I would refactor them myself for better long-term maintainability.

This is the main article that shows the idea while the 5 links are inside.

Let me know what you think about this type of content and if it is useful to you.

Hi folks,

I've got some news I've been wanting to share for a while: SimpleStats is now open source (AGPL-3.0). The complete app, the same code that runs simplestats.io, is on GitHub.

Quick recap for anyone who hasn't seen it: SimpleStats is a server-side analytics tool built for Laravel. Instead of a JS snippet, it tracks visitors, registrations, logins and payments through Laravel itself (middleware, observers, event listeners). So ad blockers can't touch it, and it can tie every payment back to the UTM campaign that brought the user in. Think revenue per channel, MRR, retention cohorts, campaign ROI, not just pageviews.

Why open source? Mostly trust. An analytics tool that sees your signups and payments shouldn't be a black box. Now you can read exactly how visitors are counted, how bots are filtered and how revenue gets attributed. And if you spot a bug or miss a metric, you can send a PR.

For teams that can't send user or revenue data to a third party, it can also be self-hosted. It's a regular Laravel app (Laravel 12, Inertia + Vue, PostgreSQL). No open-core split: the self-hosted version has every feature and no limits on projects or events. The hosted version with its free plan stays the easy way if you'd rather not run servers.

Repo: https://github.com/simplestats-io/app

Announcement with the details: https://simplestats.io/blog/simplestats-is-now-open-source

I'd love to hear your feedback, and PRs are very welcome. Happy to answer questions about the code or the decision to go open source!

We've open-sourced the package behind the AI assistant in our own admin panel. Agents for Laravel (free, MIT) is built on the first-party laravel/ai and laravel/mcp: you write a tool as a small class, and the same class serves an AI chat inside your app and an MCP server for Claude Code, Cursor or any other MCP client.

The agent never does more than the signed-in person could: every tool checks a Gate ability, and MCP clients connect with a Sanctum token you can limit to read-only or to specific tools.

Here's a complete tool. The $ability line is the Gate it checks, and #[IsReadOnly] is what lets it run without asking:

#[IsReadOnly]
#[Description('Find orders by status.')]
class SearchOrders extends AgentTool
{
    protected ?string $ability = 'orders.view';

    protected function run(Request $request): array
    {
        return Order::query()
            ->where('status', $request->get('status'))
            ->limit(20)
            ->get(['number', 'status', 'total', 'placed_at'])
            ->toArray();
    }

    public function schema(JsonSchema $schema): array
    {
        return ['status' => $schema->string()->required()];
    }
}

List it once on a server class and both the in-app chat and MCP clients get it. Remove #[IsReadOnly] and the same class becomes a write: the chat asks for approval first, and an MCP client needs a write token.

composer require packstub/agents (Laravel 13, PHP 8.4+)

GitHub: https://github.com/packstub/agents

If you're on Filament, Filament Agents puts the same engine in a panel, with inline approvals and answers shown as your resource's own tables: https://github.com/packstub/filament-agents

Is approve-before-write the right default for you, or would you want some writes to run without asking? And which tool would you give it first in your app? Issues and PRs welcome.

Edit: the example now returns only the columns the model needs, thanks to a good point in the comments.

Hi everyone,

For quite some time we've been working on VoodBuilder, a visual page builder and CMS designed to work natively with Laravel and FilamentPHP.

I really like working with Filament, but I wanted a way to build and manage public-facing websites using the same stack, without having to introduce WordPress, a headless CMS or a completely separate frontend application.

So I started building one.

VoodBuilder uses GrapesJS as its visual editor, with Tailwind CSS integration, and everything is managed through the Filament panel.

What can it do?

• Visual drag-and-drop editor with responsive previews
• Page management, navigation menus and custom layouts
• Theme Studio with color palettes, sub-themes and light/dark support
• SEO metadata and page access control
• Undo/redo, autosave and revision history
• Built-in site search
• Integrated media library and cookie consent management

There's also a growing ecosystem of additional plugins for things like dynamic content, reusable components, popups and more.

I've split it into three editions:

Community (Free, MIT licensed)

This is the open-source version available on GitHub. It includes the core visual editor, pages, menus, themes, layouts, SEO, revisions, media management and cookie consent.

It's not a trial and doesn't require a licence key.

Developer (Paid)

Adds a library of ready-made elements and sections, dynamic data binding with Eloquent models, and reusable page templates.

Agency (Paid)

Includes everything in Developer, plus a popup builder, reusable components, and dynamic API integrations supporting HTTP, Eloquent and other data sources.

Both paid editions allow unlimited websites, with different seat limits.

Getting started

The Community edition is available through Composer:

composer require voodflow/voodbuilder -W
php artisan voodbuilder:install

It currently requires PHP 8.4+, Laravel 12+ and Filament 5, along with Tailwind CSS v4.

You can check out the source code here:

GitHub: https://github.com/voodflow/voodbuilder

There's also a live demo if you want to try the editor before installing anything:

https://demo.voodflow.com

And the project website:

https://voodflow.com

I've spent a lot of time on this project, and I'd be interested to hear what other Laravel and Filament developers think.

In particular, I'd love feedback on the overall approach, missing features, or anything that might make it more useful in real-world projects.

Thanks for taking a look!

I've been a Laravel developer for years. I love the framework, the conventions are familiar, and I have always liked the blade-methods. I've always liked rust as well, being a lot of fun to code with, but hadn't used it much for web-dev.

One thing I kept coming back to was how much of Laravel's appeal to me comes from the development experience itself. The conventions, organization, tooling, and having common web-development concerns already accounted for.

So I started building Larust, a Laravel-inspired web framework for Rust.

The idea is to bring familiar concepts such as:

• Routing and middleware
• Models and ORM/database access
• Validation
• Authentication and sessions
• Blade-inspired templates
• Migrations
• Artisan-style CLI commands
• Controllers, requests, and resources

...into an actual Rust application.

It's not PHP running through Rust, and it's not intended to be a Laravel compatibility layer. The application is compiled Rust and uses the existing Rust ecosystem underneath.

I'm curious what other Laravel developers think about the idea, particularly which parts of the Laravel experience you'd consider essential if you were moving to Rust.

The project is still developing, so I'm also interested in hearing where the design feels natural versus where I'm trying too hard to make Rust behave like Laravel.

GitHub: https://github.com/WallabyDesigns/Larust

Website: https://larust.dev/

Docs: https://docs.larust.dev/

Preface: I'm not trolling. I'm a developer who primarily uses Laravel day to day at work. And it serves me well. I hope you are all well.

I'm trying to cut through the noise and the hype of "ai", and am interested in different people's opinions.

In the Cambridge dictionary, the word Artisan is defined as: "making things in a traditional way with your hands" and "made in a traditional way by someone who is skilled with their hands".

Now I see everywhere, it seems, that "code was never the point" and "no-one is reading the code now".

Can you still use the term "artisan" now, when essentially an llm will spit out a result that you are after?

Everyone is using the same "skills" / "md files" / whatever. So it seems that everyone using these is becoming a merging of the same source (the llm agent). No originality. Average.

I get that the end product and "shipping" are of the most importance in the Laravel community, but what happened to the individual person's enjoyment of creating something with their hands using their own mind?

I feel that the pressure in this, and other, communities about using these automation / generation tools are taking away the human touch in things. Prioritising "shipping" for some end business and the sacrifice of each developer's (artist?) mind, creativity, and enjoyment of the craft.

I'm not saying things shouldn't be made and shipped; of course they should. But it's the "faster, faster, faster" mentally at the expense of people who still care about the craft.

I get that some people just love these tools, and thats fine for them. But what about the people being dragged along by the "You're gonna fall behind" crowd?

That's not to mention the brain entropy of skills that you will inevitably lose due to the more and more offloading to a third party llm.

"Use it or lose it", They say.

No disrespect is intended; this is meant for discussion so please keep it respectful.

Hey everyone! :D

I just released Consent for Laravel, a free, open-source cookie consent package for Laravel.

I wanted something simple that I could reuse across projects without manually setting up tracking scripts and consent logic every time.

I actually installed it on its own website in about 5 minutes. Just Composer, two Blade components, enable GA4, add the ID, and it works :D

What's included:

• Built-in GA4, Google Ads, Meta Pixel and Microsoft Clarity integrations
• Google Consent Mode v2
• Customizable banner, preferences and consent withdrawal
• Consent-aware loading for your own scripts
• No external account, database or frontend framework required

Coming next:

• Laravel Boost skills
• Better Livewire / Inertia integration
• More built-in integrations and translations

Website & docs: https://consent.lipinskijakub.pl/

GitHub: https://github.com/jakub-lipinski/consent-for-laravel

Would love to hear what you think, especially if you try it in a real Laravel project. Feedback and feature suggestions are very welcome :)

While the Internals list is not technically directly Laravel related, it does affect every single one of us.

Preface: what follows is the word-for-word transcript of the spoken dialogue in the video, chapter by chapter with timestamps, for anyone who'd rather read than click through. If this digest is still too long for you, we recommend copying it into your LLM of choice and asking for a summary of our summary.

Cold Open (00:00)

PHP's default password hash only reads the first 72 bytes of your password. Last week, a plan to make it refuse anything longer split the list, because it would break working apps. This week, a fix that breaks nothing showed up. And it was borrowed from another language's password library.

Hello world, it's Thursday, October 8, 2026, and here's what happened This Week in PHP Internals. 13 stories this week, so let's get into it. But first,

How many little monthly subscriptions is your team paying for right now? A private Composer registry here, a mail trap for staging there, a background remover for images, and it all adds up. That's exactly what Scalpels aims to solve. It's a catalog of open source apps, each one aimed at a single paid service and built to replace it: Crate, Sink, Matte, Hone, and a growing list of experimental ones. Scalpels forks the app you pick into your GitHub organization and deploys it to your own Laravel Cloud account, so your data never leaves your infrastructure. Resources scale to zero by default, so a low-use app could cost you pennies. Take updates when you want them, change whatever you like, because it's MIT. And the platform that installs and manages all of them, across your own projects and your clients', isn't another subscription. It's one lifetime purchase, and the catalog keeps growing. If you run an agency, it's a sales tool too: cut your clients' running costs, and close more of the work you pitch. It officially launches October 31st. Early adopter pricing is live now at scalpels.app.

Bcrypt SHA256 (01:46)

This week's top story is fixing bcrypt without breaking a single login. Sjoerd Langkemper's RFC to throw on passwords past 72 bytes drew a lot of pushback over backward compatibility, and he says it isn't worth pursuing further for now. It did have support. Jeff Dafoe found the problem in the older part of a PHP codebase he works on, and they forced password resets, writing: "Looking through the lens of software security in 2026, I cannot think of any situation where this function should silently accept more bytes than it can hash."

The way out came from Tim Düsterhus, who suggested borrowing bcrypt-sha256 from Passlib, a mature Python password library. So Sjoerd's new RFC adds PASSWORD_BCRYPT_SHA256. Your password goes through HMAC SHA-256 first, so bcrypt only ever sees a 44-byte key, with no null bytes and no 72-byte cliff. In the RFC's example, a 200-character password verifies, and the same password one character shorter doesn't. It's opt-in, the default doesn't change, and the RFC lists no breaking changes. And the hashes are interchangeable with Passlib's. They are longer, so you may need a wider database column.

Tim wrote: "I believe this is a much better solution than modifying PASSWORD_BCRYPT in a way that breaks compatibility." Anton Smirnov loves the proposal, and Tim sees nothing fundamentally wrong with the implementation. Making it the default someday is listed as future scope.

Links: PASSWORD_BCRYPT_SHA256 RFC · thread · implementation · Passlib's bcrypt_sha256 · the earlier RFC, set aside

Open Votes (03:27)

For 7 straight episodes, nothing was in voting. Now 2 votes are open. Nick S. missed the date he'd planned for the PEAR vote and opened it on Monday instead. It would archive the PEAR site, stop bundling its installer in 8.7, and point php.net to Composer. As of recording, it's 26 to nothing, and it closes October 19.

Weilin Du's IntlRelativeDateTimeFormatter is back too. It turns a number and a unit into phrases like "yesterday" or "in 2 weeks". Its first vote, in September, was closed within the hour at 4 to 1, with Tim Düsterhus voting no. Weilin has since adopted Tim's enum design. This time it's 7 to nothing, Tim included, and it closes October 22.

Links: End PEAR Project Endorsement RFC · PEAR vote thread · IntlRelativeDateTimeFormatter RFC · IntlRelativeDateTimeFormatter vote thread

Time Instant (04:21)

The proposed Time\Instant class had to answer a simple question this week: what does json_encode give you? Today it's an empty object, and Ilia, otherwise broadly in favour, called that a trap. Rob Landers, who has spent years on a database that has to deal with relativity, wants it to throw instead. Tim and his co-author Derick Rethans said no to both, because there's no single right format, so you pick one. Tim says the real fix belongs in the JSON extension.

Marc sent a 15-point review, and the getUnixTimestamp methods are now toUnixTimestamp. SystemClock became a singleton, and when Rob noted DateTimeInterface had no toInstant, Tim replied: "No. I just forgot that the interface exists. Now added."

Mirco Babin still wants now() renamed so one class can also implement PSR-20, and agreed to disagree. Larry Garfield, a long-time member of the PHP-FIG Core Committee, wrote: "This proposal seems like a good step to replacing PSR-20 with something even more standardized and universally available."

Links: Time\Instant and Time\Clock RFC · thread · PSR-20 Clock

Io Terminal (05:33)

PHP's proposed terminal API has dropped the interfaces it gained last week. Tim Düsterhus very strongly disagreed with them, with 5 arguments, and the point that the real input and output boundary is the stream, not the terminal. Bob Weinand agreed.

Larry Garfield said he isn't attached to interfaces, only to an obvious way to test code that reads from the terminal. So Larry sketched a test with in-memory streams, and Tim compiled the branch and confirmed it works for reading lines. Ilia suggested key and secret reads accept ordinary streams too, which he said would close the testing gap on Windows.

Pratik Bhujel's version 0.4 does all of that. Terminal is a final class with no interface, scripted streams work for keys and secrets, a forked child no longer resets its parent's terminal, and there are new keys for Insert and Shift-Tab. Pratik wants to move toward a vote once people have reviewed it.

Links: Io\Terminal RFC · thread · implementation

Single Binary (06:35)

If you run PHP behind FPM, you probably ship the same engine twice, once in php and once in php-fpm. Matthieu Napoli's new RFC adds a build option that puts FPM inside the php binary, run with a --fpm flag or through a symlink. He measured it with Bref, on AWS Lambda. The package is 18% smaller zipped, and a minimal FPM app cold-starts 70 milliseconds faster, a 25% cut, because the engine isn't loaded twice.

Tim sees basically no drawbacks, and asked why anyone should keep a standalone FPM binary at all. Ayesh Karunaratne flagged that -F means different things to the CLI and to FPM. Larry asked whether this privileges FPM just as FrankenPHP and Swoole are taking off, writing: "I just want to make sure we don't inadvertently lock in FPM as The Way PHP Runs just at the time that it no longer is." Nicolas Grekas says it should be the other way around, with the FPM binary embedding the CLI, the way FrankenPHP does. Jakub Zelenka agreed that makes more sense.

Links: single binary for CLI and FPM RFC · thread · implementation · Bref

IO Hooks (07:54)

Ilia's worry about making blocking PHP concurrent is C code written assuming no PHP runs while it waits. He ran Jakub Zelenka's IO Hooks branch and found crashes, like one Fiber freeing a DOM document while another is still saving it. He'd flip the default, so hooked calls stay blocking unless the call site declares itself safe to suspend. Jakub says the branch is a proof of concept, and these are fixable, not a design issue.

Larry and Sebastian Bergmann asked for the big picture, so Jakub linked a full design doc for all 3 RFCs. Sebastian is looking forward to orchestrating child processes from PHPUnit with it. And Edmond Dantes, whose concurrency RFC proposes a pluggable scheduler, has started testing against it, writing: "Just a couple of weeks ago, I had no hope that async could make it into the language core. But now we have both halves: Scheduler + IO Hooks."

Links: IO Hooks RFC · Polling API Additions RFC · design doc for all three RFCs · proof of concept · Concurrency Support in the PHP Engine (scheduler) RFC

Delegation (08:56)

Karoly Negyesi's implements … by, which hands an interface's methods to a property, picked up a strong supporter and a familiar problem. Larry Garfield is strongly in favour, after Drupal query classes each carried about 100 lines of pass-through code. James Gilliland agreed, pointing to Laravel's ForwardsCalls trait.

Sebastian Bergmann objected that a method added to the interface later gets silently forwarded by every class using it. And fluent methods return the inner object, not yours, which Larry would handle with a mask keyword.

Rowan Tommins has been here before, writing: "This is where I've always stumbled when trying to come up with similar feature proposals - when you start looking for use cases, a lot of them need just one small thing on top of the forwarded call. So you add an extra keyword here, and a special logic there, and eventually it no longer feels like an elegant shorthand at all."

Links: pre-RFC + implementation · thread

Quick Hits (09:58)

Quick hits. Weilin Du is taking his array shorthand back to the colon, since the parser can tell it apart from a ternary, and he's in no hurry to vote.

Links: array shorthand RFC · draft PR

Juliette Reinders Folmer said she wouldn't pursue deprecating the b string prefix without more interest, so Daniel Scherzer offered to write the C code and added it to the 8.7 deprecations RFC.

Links: 8.7 deprecations RFC: the b prefix

Muhammed Arshid turned his filter RFC into backed enums for the filter extension's filters and flags. Derick Rethans says removing the extension's default input filtering crippled it, and wants that deprecation undone.

Links: Filter\Filter and Filter\Flag enums RFC · PR

Máté Kocsis is back on his query parameters RFC and wants a vote as soon as possible.

Links: query parameter manipulation RFC

David Carlier wants unit formatting in intl, like 5 kilometers per hour, through a new formatter built from an ICU skeleton.

Links: intl unit formatting discussion · GH-24165

And PHP 8.6's third release candidate is scheduled for today, with general availability on November 19.

Links: PHP 8.6 release schedule

TL;DR (11:01)

So that's the week. Instead of breaking bcrypt, a new RFC proposes an opt-in hash borrowed from Python's Passlib. Two votes are open, and neither has a single no vote so far. Time\Instant won't pick a JSON format for you, Io\Terminal dropped its interfaces, and a new RFC would put FPM and the CLI in one binary. IO Hooks got a safety review, and delegation met its edge cases. Links below.

The PHP Foundation funds more than half of ongoing php-src commits, so if you use the language, maybe consider donating at opencollective.com/phpfoundation — or try guilting your employer into it.

If you found this useful, a like or a comment helps more people find it. And if you missed last week's episode — where we found out PHP throws away every byte of your password past the 72nd — that's a good one to watch next. Thanks again to Scalpels.app for supporting this week's episode. We're Artisan Build. See you next week.

Links: raw feed · RFC wiki

I was confused when I first saw this news, so I dug into it and decided to break it down in simple terms, since it’s actually a different context.

This was proposed in RFC 10008 and was accepted recently.

QUERY is a proposed HTTP method designed for safe, cacheable requests that need to send a request body containing query parameters.

QUERY /users/search HTTP/1.1
Content-Type: application/json

{
  "name": "John",
  "age": {
    "gte": 30
  }
}

This is useful when a query is too complex or too large to comfortably put in a URL:

GET /users/search?name=John&age_gte=30

Why is QUERY interesting? / When should you use it?

The key idea is:

QUERY is a safe HTTP method that allows a request body.

Imagine you have a complicated product search.

With normal GET, you'd potentially end up with:

GET /products?
    category=electronics&
    price_min=100&
    price_max=500&
    brands[]=apple&
    brands[]=samsung&
    features[ram]=16&
    features[storage]=512

That's awkward when the query becomes large or highly structured.

With QUERY, you can do:

QUERY /products/search
Content-Type: application/json

{
    "category": "electronics",
    "price": {
        "min": 100,
        "max": 500
    },
    "brands": [
        "apple",
        "samsung"
    ],
    "features": {
        "ram": 16,
        "storage": 512
    }
}

The important distinction is:

GET
 └── safe/read operation
 └── traditionally query parameters in URL

QUERY
 └── safe/read operation
 └── query parameters can be sent in request body

Laravel now supports:

Route::query('/products/search', function () {
    return request()->input();
});

And on the HTTP client side, Laravel provides:

$response = Http::query('/products/search', [
    'category' => 'electronics',
    'price' => [
        'min' => 100,
        'max' => 500,
    ],
]);

Conclusion

Traditionally:

• GET → query parameters in the URL, but request bodies aren't reliably supported
• POST → can have a body, but semantically often means "create/process something"
• QUERY → intended to mean "retrieve something using this query body"

So conceptually:

GET    → retrieve resource
POST   → submit/process/create
QUERY  → retrieve using a structured query

However, QUERY is not currently a universally supported standard HTTP method like GET/POST/PUT/PATCH/DELETE. Support depends on the HTTP server, framework, clients, proxies, etc.

Hey r/laravel 👋

I've been working on Tinkerbox, a free, open-source (MIT) desktop app for running PHP and Laravel code inside your project. It's basically php artisan tinker with a proper editor and rich output.

What it does

• Open a Laravel project, write code and press ⌘R. It boots your app and runs the code in a fresh PHP process.
• Magic comments: end a line with //? and its value appears inline. It works inside loops too.
• SQL inspector: every query your code runs shows up as a formatted card with bindings and timing.
• Eloquent-aware autocomplete for facades, builder methods, scopes and columns. Tinker-style aliasing means User::first() just works.
• Rich dumps for models, collections and Carbon dates.
  • A table view with CSV export
  • An object graph
  • An HTML preview for mailables and views
• Readable exceptions with code snippets, plus inline errors in the editor.
• A log viewer, run history, snippets (including per-project snippets you can commit), themes and Vim mode.
• Laravel Sandbox: a bundled Laravel app for quick experiments without opening a project.
• Also supports Statamic, Symfony, WordPress, Craft and more through drivers, and you can write your own.

Everything runs locally with your own PHP (Herd works great). Nothing is uploaded and nothing is written into your project.

Download (macOS): https://github.com/theharisshah/tinkerbox/releases/latest

Source: https://github.com/theharisshah/tinkerbox

This is v0.1.0, so expect rough edges:

• macOS only for now (Apple Silicon and Intel). The build isn't notarized yet; see the release notes for first-launch steps.
• Windows and Linux builds, plus SSH and Docker support, are on the roadmap.

Feedback, ideas and PRs are welcome on GitHub. I'd especially like to hear what would make this part of your daily Laravel workflow.

In this article, I’m experimenting with a Vue composable that reads the locale from Inertia’s page props, instead of relying on `<html lang>` or passing lang on every call. It works with Ziggy and Wayfinder, supports SSR, and picks up locale changes after Inertia navigation.

If the approach proves useful, I’d like to add it to the laravel-l10n package (https://github.com/goodcat-dev/laravel-l10n), along with React and Svelte equivalents.

Would this fit your setup? Any edge cases I should consider?

PHPStan 2.3: Leap in Performance, Generics Improvements, Detecting Unused Variables, and More!

I had so much fun with the interactive charts and widgets, check out the article. I promise it's worth checking it out yourself, and not just letting your agent summarize it for you 😉 It contains a lot of interactive widgets with practical examples of the new features in action.

Jobs, Jobs & Jobs

This Laravel 13.34 release is all about our favorite Laravel feature.

Look at these nice additions:

➡️ Jobs duration
➡️ Timeout warnings
➡️ Crashes count towards maxExceptions

Thank you Jack & William 🙏

https://youtu.be/BEEPbbW09Vg

For the past few weeks I've been building a package around one idea: an operation should be written once.

You write it as an Action class. The same class then answers a web route (JSON and forms, with Precognition), an Artisan command, a queued job, a typed TypeScript function, a laravel/ai agent (a copilot in your app), and MCP clients like Claude.

#[Expose]
final class CreatePost extends Action
{
    protected ?Effect $effect = Effect::Write;
    public function schema(JsonSchema $schema): array { /* … */ }
    public function authorize(ActionContext $context): bool { /* … */ }
    public function handle(ActionContext $context, ValidatedInput $input): array { /* … */ }
}

Every caller goes through the same pipeline: exposure, token abilities, tenant membership, `authorize()`, validation, `handle()`, and an allowlist on the output. So the AI can't do anything your form wouldn't allow, and you don't keep a separate pile of agent-only tools that drift from your real validation.

The idea comes from Agent-Native by Builder.io, where one `defineAction()` serves the UI, the agent, HTTP, MCP and the CLI. This brings that to Laravel, built on laravel/ai and laravel/mcp.

It's in beta (0.9), MIT licensed, and the API can still change before 1.0.

• Docs: https://agentic-actions.com
• Demo (private 24-hour sandbox, no sign-up): https://demo.agentic-actions.com
• Code: https://github.com/agentic-actions/laravel

I'd really like feedback: what breaks, what's missing, and whether this fits how you build Laravel apps.

I have always missed a well and modern designed fumadocs alternative for laravel. So here it is. It is currently still in development with features such as OpenApi support, blog support and more on the way toward v1. Hope this is usefull to anyone.

Hey guys, what AI skills do you frequently use and recommend?
I’m using Matt Pocock’s skills currently to create the plan, specs, implementation tickets and also for implementation.
But what I’m missing are some review skills for the plans, specs and issues it generates. I usually ask the agent to review the plan for inconsistency, errors etc. The specs are reviewed against the plan, because I noticed sometimes the agents drift a bit or is leaving things out.
I’m also trying to find/create a good code review skill that should verify the implementation, catch bugs, inconsistency, code styling, DRY and SOLID violations… you know, usual stuff when you perform a manual code review.

English is not my native language and sometimes I struggle to clearly formulate my prompt. That’s why I rely heavily on skills written by smarter people :)

So my question is do you use any particular skills that helps you developing PHP & Laravel apps, end to end, through the entire software lifecycle? From planning to deployment? Or do you have any specific workflow?

Thanks!

The second episode of my Decide with Jev mini course is up.

Instead of asking for one overall quality score, the app asks Jev three questions about the same draft, all in one request. Each question gets its own answer type from the Laravel AI SDK: a Boolean, a choice from a fixed list, and a score on a scale I define. When a result changes, I can see which part changed.

One thing worth knowing if you try this: the questions are answered in parallel, so none of them can read another's answer. Anything that connects them has to happen in PHP after the request.

https://youtu.be/3oJddn6sU9U

How are you handling AI output in your apps right now? Parsing free text, or asking for structured answers?

Taylor seems to be teasing a rust version of laravel on X. What are your thoughts?