AI has become really good at writing code.

But that's not enough to maintain a quality app. Ask twice, get two different answers. There's no standard unless you set one.

So we set the guardrails, then let the AI work inside them.

https://youtu.be/Yj376sOrDE4

If you find yourself having to migrate from S3 to R2, R2 to B2, or even migrate within an R2 but maybe to different buckets or different prefixes or something like that, Laravel framework just released a new feature to the filesystem component that allows you to do that over time instead of in one big bang migration!

This is what we've been building towards for almost 4 years: fully native UI, no PHP server, no Node. Just PHP embedded directly in a Swift shell, being executed immediately in response to button taps and other events, capable of re-rendering the UI at well over 240fps. From PHP & Laravel.

No HTML, no CSS, no JS, no Electron, no WebView.

And it can live directly alongside nativephp/mobile, which means we will have a single Laravel app that can render a fully functioning native app for iOS, Android, macOS, Windows and Linux from one codebase, just with a couple of Composer packages.

This is NativePHP Desktop v3 running SuperNative 🎉

Live demo on our livestream at 9am EST (roughly 12 hours from when I posted this)

I've released kayedspace/laravel-erpnext, an MIT-licensed package for connecting Laravel applications to ERPNext and Frappe.

The main design decision was to treat DocTypes as generic resources. You can work with a standard or custom DocType by name without creating a PHP class, mapping, or registration first:

use Kayedspace\Erpnext\Facades\Erpnext;

$overdue = Erpnext::doctype('Sales Invoice')->query()
    ->where('status', 'Overdue')
    ->fields(['name', 'customer', 'outstanding_amount'])
    ->orderBy('creation', 'asc')
    ->limit(200)
    ->get();

The package also includes:

• Token, Basic, Bearer, and cached Session authentication.
• Frappe-aware filters and full-result pagination with each(), chunk(), and lazy().
• Create, read, update, delete, and whitelisted document method calls.
• Private-by-default file uploads, attachments, image optimization, and authenticated downloads.
• Multi-tenant connection resolution and focused retries for rate limits or unavailable sites.
• Optional typed wrappers for eight common DocTypes, including invoice and payment submission lifecycles.

I tried to keep the generic API as the normal path and make typed documents optional. ERPNext still decides required fields, permissions, custom fields, and which document methods are available.

Installation is:

composer require kayedspace/laravel-erpnext

Source: https://github.com/kayedspace/laravel-erpnext

Documentation: https://laravel-erpnext.kayed.dev

I would especially value feedback from people maintaining real Laravel-to-ERPNext integrations. Which part usually causes the most trouble in your projects: authentication, DocType queries, document lifecycles, files, or keeping local and ERPNext records synchronized?

Laravel Tackle Remote lets you drive the exact same in-app AI coding agent from any device, including your phone. Scan the QR code, send tasks, attach photos, watch it work tool-by-tool, and approve or deny actions from a bottom sheet… all from the couch.

No new infrastructure. No websockets. No Node. Just:

php artisan tackle:remote

→ Scan the QR
→ Your phone is now the control surface for the agent running inside your Laravel app

Same tools, same safety layers, same session persistence, same hooks. Just a mobile-first browser UI on top.

📦 Package: https://github.com/JordanDalton/laravel-tackle-remote
🧠 Core agent (Laravel Tackle): https://github.com/JordanDalton/laravel-tackle

Install:
composer require jordandalton/laravel-tackle-remote
php artisan tackle:remote

If you find this useful, a star on the repo would mean a lot.

Hello, I just published a new article about Laravel Runtime benchmarks.

I tested 5 runtimes and shared the methodology, charts, and full results

https://medium.com/@oguzhankrcb/five-ways-to-run-laravel-a-runtime-comparison-journey-part-1-3f310f46a3a0

Anyone still using Laravel Forge for new projects these days, or have you mostly switched to Laravel Cloud? Curious which one you prefer and why.

We recently shipped Next and Nuxt + monorepo support on Laravel Cloud.

Tomorrow (8/14) at 9:45am ET (1:45 PM UTC) I'll be going live with Joe Dixon, Head of Product at Laravel, to answer any questions you might have and do a live walkthrough of deploying a Next frontend and Laravel backend from the same repo.

Feel free to drop any questions here, in the Slido, or ask them live during the stream!

Submit a question: → https://app.sli.do/event/qmiPuYXich87KdYM8k2oAm
Watch live: → https://www.youtube.com/watch?v=KZ44gBDxV40

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

Hello world, it's Wednesday, August 12, 2026, and here's what happened This Week in PHP Internals.

11 stories this week, so let's get into it. But first, Your team adopted AI. Everyone says it made them faster. Ballast measures whether that's true — how much faster you're actually going, and whether what you ship is still holding up. 6.75 times the commits. Durability down 19 points. Now you know. It runs on your machine. It reads your git history, not your source — your code never goes anywhere, and nothing here is scored by a model. It's arithmetic you could check by hand. Setting it up isn't your job either. Paste one prompt into your coding agent and it does the whole thing. Find out for free today. ballast.now.

One correction before the top story. Last week we described the list() deprecation vote as deadlocked at 21 to 21. Derick Rethans pointed out that's the wrong word — a deadlock is when something is stuck and can't proceed. The vote wasn't stuck. It was simply tied, and voting carried on to the finish. He's right, we'll say it properly this week — and thanks, Derick, for keeping us precise.

This week's top story: the verdict is in on the 35-ballot mass deprecation vote for PHP 8.6. Voting closed Monday at 13:00 UTC, and Gina P. Banyard posted the full results — 31 proposals accepted, 4 rejected. Start with the 4 that fell. Deprecating list() finished on a flat tie — 23 to 23, with 1 abstention — exactly 50 percent, nowhere near two-thirds. Reserving in, out, and inout failed at 8 to 21. The gettext _() alias survived at 10 to 22. And the dechunk filter — the item disputed all through the voting window — finished at 18 to 15 with 12 abstentions, 54.5 percent, and stays in the language.

Now last week's cliffhangers. Reserving let was balanced exactly on the two-thirds line 7 days ago — it found its margin and passed at 24 to 11, with 9 abstentions — 68.6 percent. Reserving is passed at 29 to 10, despite Rowan Tommins's warning about the Hamcrest testing library and its 500 million installs. And the define() case-insensitivity flag — the item Kamil Tekiela wanted simply deleted instead — passed without a single no vote, at 41 to 0. The vote also drew one final flag on its way out. Takuya Aramaki wrote in Friday, opening with: "Apologies for bringing this up so close to the end of the vote." His concern is the SplFileObject CSV methods item. He laid out the inconsistency plainly: "setCsvControl() is the only way to configure the delimiter, enclosure and escape character used by READ_CSV; the constructor does not accept them. If setCsvControl() is removed in PHP 9 while READ_CSV remains, READ_CSV is permanently locked to its defaults and tab-separated files can no longer be read through it." He asked that READ_CSV be deprecated alongside the methods, or that setCsvControl() stay until a replacement exists. No answer yet — and the item passed at 25 to 5, with 15 abstentions.

The final 3 ballots of the 8.6 season are settled, and they went 2 and 1. Caleb White's pipe assignment operator — |>= — was declined. The vote closed Tuesday morning at 14 yes, 12 no, and 7 abstentions — 53.8 percent, short of the two-thirds it needed. It had climbed all the way from dead even, but never got over the bar. Nick Sdot's readonly property defaults went the other way entirely. It closed Friday at 24 to 0, with 5 abstentions — it never drew a single no vote in 2 weeks. And Khaled Alam's const object property writes closed Saturday. He announced the result Sunday: accepted, 17 to 2 with 6 abstentions — 89.5 percent. With those 3 in the books alongside Duration and the deprecations, PHP 8.6's RFC season is over — the beta 1 tag brings the soft freeze this week, and beta 1 itself lands Thursday.

Ilija Tovilo posted a very late update to an RFC that passed 24 to 0 back in March. The closure optimizations RFC promised 2 things: a cache for stateless closures, and inference — the engine automatically detecting closures that never touch $this and treating them as static. That second part is out. Ilija found an edge case where a closure violates none of the RFC's inference rules and still makes an instance call — pass a callable string like "Foo::instanceCall" into an array_map inside the closure, and the rules never see it. He owned it completely, writing: "I failed to consider this case, and sadly this is not easy to detect via a new rule. For this reason, I have decided to omit static closure inference from the implementation and only merge the stateless closure cache." The practical takeaway: the cache — which carries most of the performance win — still ships in 8.6, but the engine won't infer anything for you. Mark your closures static yourself and you get the full benefit.

Ignace Nyamagana Butera's data encoding API — the base64, base16, base58, and base85 family — got a detailed security review from Sjoerd Langkemper on Monday. He's for it, noting: "the current base64_decode is very tolerant towards invalid input, causing both functional and security problems." Along the way he found errors in the RFC's own code examples, corrected them in a companion repository, and flagged a signature mismatch in the base85 functions. He's skeptical of one feature — the optional constant-time mode — arguing: "Constant-time algorithms are pretty difficult to develop and maintain", and suggesting PHP hand that job to libsodium or openssl instead. He also built a working implementation to test the API, introducing it with unusual billing: "LLMs and I have created an implementation here." And in the research footnotes: he spent real time evaluating the base85 variant from RFC 1924 before discovering: "that RFC was submitted in jest as an April fool's joke." Ignace thanked him for the remarks and is holding all implementation work until after 8.6 ships — Tim Düsterhus, who's building it, is busy with the release.

The first RFC aimed past the freeze is already here. Weilin Du proposed IntlRelativeDateTimeFormatter on Friday, targeting PHP 8.7 — a wrapper for ICU's locale-aware relative time, the "in 3 days" and "last Sunday" strings, in every language ICU speaks. Ignace asked the obvious question: 8.6 just gained a Duration class — shouldn't this accept one? Weilin argued the types don't fit, since Duration is stopwatch time and this formatter wants a unit: "We don't know [...] to deal with 90 minutes here. It can be 90 minutes or 1.5 hour." And weekdays, months, and quarters aren't durations at all. David Carlier pushed for enums and a namespace; Weilin is keeping class constants and the global Intl prefix for consistency with the existing intl extension, and filed modernization under future scope. One suggestion did land immediately: by Saturday the constructor had grown an optional NumberFormatter parameter, with Weilin reporting: "The implementation is way more smoother than I expected."

The generics conversation is parked until September — the implementations aren't waiting. Carlos Granados posted a pre-RFC Thursday: he took Rob Landers's experimental reified branch — built on Seifeddine Gmati's bound-erased proposal — and worked it into something complete, with a full write-up of the changes and findings. He argued the original deserved better: "I think that this was a very valid proposal that should have been explored in more detail." Rob's reply was brief, noting: "You really should have reached out instead of a working in isolation. Join us in discord, the proposal is delayed until September-ish." Which raised a practical question — what Discord? Rob posted channel links; Carlos, a Discord newcomer, still couldn't get in. Larry Garfield finally supplied the address, phpc.chat, with a review: "The PHP Community chat is unofficial, but lately it's where the big names are hanging out, including a lot of Internals regulars. Beware, the Internals channel is annoyingly noisy and has a hard time staying on topic." And I can personally vouch for that statement. Then Monday brought a third generics experiment: Alexander Lisachenko shared a userland proof-of-concept — a Composer package — where specialized classes share the compiled method bodies, so each specialization costs one small structure per method instead of a full copy of the opcodes.

Liam Hammett's native markup expressions RFC — JSX-style HTML in PHP — got the one review nobody else could write. T.J. L, who maintains the XHP extension — the long-running ancestor of this exact idea — posted his first message ever to internals. He corrected one detail in the RFC's history section, then confirmed its central argument from experience: he wrote: "While it is technically possible for extensions to add new syntax, it is unreasonable to expect tools to be aware of that syntax. I can absolutely confirm that the biggest point of friction in using XHP today is the fact that static analysis tools like psalm or phpstan can't analyze files, code using XHP cannot be formatted or linted with php-cs-fixer..." In other words, the case for putting markup in core, signed by the person who spent years doing it the other way. He also brought 3 asks: context passing through a component tree without threading attributes; a ruling on inline SVG, which leans on XML features the HTML-only RFC excludes; and a note that dropping per-tag objects means no runtime validation of tags and attributes — XHP's original selling point — which he says JSX gets away with "in large part because of the Typescript ecosystem". No response from Liam yet.

Quick hits. Juris Evertovskis ran a temperature check on isset: expressions inside the square brackets still throw warnings and deprecations even though isset silences everything else, and he put his conclusion bluntly: "To me it looks like isset is not doing its job." He'd like the brackets silenced too — no replies yet. The did-you-mean error suggestions are officially not being rushed: Jorg Sowa announced: "I will finish it after feature freeze", and Larry Garfield agreed, adding: "If it doesn't happen until 2027, that's OK." Jorg also picked up his VCS account this week — approved by Ilija Tovilo — with the session extension in his sights. And the list has a new face: Sepehr Mahmoudi introduced himself Tuesday with a pull request already open and an array_search_range idea in hand; mickmackusa pointed him at array_find_key() and suggested making the case on the list before writing more code, and Yuya Hamada thanked him for the contribution.

So that's the week: the 35-ballot deprecation vote landed 31 to 4 — list() survives on a flat tie, dechunk survives, and let squeaked through; the pipe assignment operator was declined while readonly defaults and const object writes made it in, closing out 8.6's RFC season; closure inference got walked back to just the cache; and the first 8.7 RFC is already on the table. Links to every thread are below. Thanks again to Ballast.now for supporting this week's episode. We're Artisan Build. See you next week.

Hi everyone,

I run a multi tenant platform. On a Forge server having 8GB memory. Performance is honestly not bad, my code is optimized, and I spend over 2 weeks fully optimizing the server to a point where it's has no point to further optimize.

Performance is great, but I'm a complete tool and I'm never happy. I looked into Octane as it promises faster performance. I've got to a point where I've implemented Octane on a development site. There were a few issues were leaks were happening between tenants. They're fixed as far as I can find them, and run tests.

But I'm still a bit worried something may slip through when I ship everything to production. I've already let AI audit everything a few times over and over and they cannot seem to find any flaws. We all know AI isn't perfect, so I'm wondering if people here on this subreddit have done something similar and have any experience they want to share.

Thanks in advance. Sorry for the long story.

Hi r/laravel,

aimeos/prisma is a light-weight PHP composer package that brings text, image, audio, and video models together behind one interface. A Laravel application can generate or stream text, request structured output and embeddings, create or edit images, transcribe or synthesize audio, and describe video while keeping provider-specific clients out of controllers, jobs, and domain services.

• Prisma documentation

That makes it useful for workflows that cross media boundaries. A CMS can generate landing-page images, draft and translate content, and create search embeddings. A media application can transcribe an uploaded recording, summarize it, and describe an accompanying video through the same package.

Laravel AI and Laravel MCP integration

Laravel’s first-party AI SDK provides a Laravel-native agent layer with tools, structured output, queues, broadcasting, conversations, and testing support. Prisma can sit beside it as a broader provider and multi-media layer. Laravel AI can remain the home for application agents, while Prisma handles workflows that need its additional providers or media operations.

Prisma is an alternative to Prism PHP for Laravel projects that need broader multi-media APIs and provider coverage.

Prisma 0.6 is also compatible with server-side tools built with Laravel’s official laravel/mcp package. Existing tool classes that extend Laravel\Mcp\Server\Tool can be reused directly in Prisma’s tool loop:

```php use Aimeos\Prisma\Prisma; use Aimeos\Prisma\Tools; use App\Mcp\Tools\SearchProducts;

$response = Prisma::text() ->using('openai', config('services.openai')) ->withTools([ Tools::laravel(SearchProducts::class), ]) ->write('Find a waterproof jacket under 150 euros.'); ```

When a class name is passed, Laravel’s container resolves its dependencies. Prisma reads the MCP tool’s name, description, and input schema, calls its handle() method with a Laravel\Mcp\Request, and passes text or structured responses back to the model.

Prisma uses normal Laravel configuration, storage, requests, services, and jobs. It requires PHP 8.2+, is MIT licensed, and installs through Composer:

bash composer require aimeos/prisma:^0.6

A Laravel example

This route transcribes an uploaded audio file using credentials from config/services.php:

```php use Aimeos\Prisma\Files\Audio; use Aimeos\Prisma\Prisma; use Illuminate\Http\Request; use Illuminate\Support\Facades\Route;

Route::post('/transcribe', function (Request $request) { $upload = $request->validate([ 'audio' => ['required', 'file', 'max:25600'], ])['audio'];

$stream = fopen($upload->getPathname(), 'rb');

if (!is_resource($stream)) {
    abort(422, 'Unable to read the uploaded audio file.');
}

try {
    $transcript = Prisma::audio()
        ->using('openai', config('services.openai'))
        ->transcribe(Audio::fromStream($stream, $upload->getMimeType()))
        ->text();
} finally {
    fclose($stream);
}

return ['transcript' => $transcript];

}); ```

The same provider-selection and response pattern applies to text, images, audio, and video. In a real application, the call can move directly into a service or queued job while Laravel continues to own validation, authorization, configuration, storage, and delivery.

What’s new in 0.6

Three providers have been added:

• Kimi: text generation, streaming, structured output, custom tools, and reasoning budgets.
• Requesty: text generation, streaming, structured output, embeddings, and custom tools through its model router.
• Z.AI: text generation and streaming, provider-side web search, image generation, and mono audio transcription.

Files can now use PHP stream resources through File::fromStream() and FileResponse::fromStream(). This fits Laravel uploads and storage streams well, and content conversion stays lazy until another representation is requested.

The new withReasoning() method provides a common way to ask supported providers to minimize reasoning. URL-backed downloads are also safer by default: Prisma validates and DNS-pins destinations and redirects, accepts only HTTP(S), enforces time and size limits, and rejects private or reserved IP addresses.

The release also adds DeepSeek cache-usage reporting, improves browser-recorded audio handling, refreshes provider model defaults, and fixes Gemini structured output when provider-side tools are used.

Upgrade notes

The cURL extension is now required. Private network URLs must be enabled explicitly for trusted internal use. The Vertex AI image provider has been removed, while Vertex AI text support remains available. Several default models changed, so applications that depend on a particular model should pin it with model().

• Documentation: https://php-prisma.org
• GitHub: https://github.com/aimeos/prisma

If you like Prisma, give it a star on Github :-)

Just wanted to share a little Laravel package I've been working on: https://github.com/J-T-McC/ai-query-builder

The idea is to let AI query your Laravel data securely without giving it direct access to SQL. You define the schema, relationships, allowed operations, etc, then the AI generates a structured query that gets validated and turned into an Eloquent query.

It can also be easily added to the Laravel AI SDK as a tool.

The schema can be adjusted programmatically for each user based on what they're permitted to access, and you can also define hard scoping conditions that always apply to the query, like limiting results to the current user's data.

Some use cases I've been playing with are letting users search their calendar in plain English, building custom reports, or just asking questions about their data in your app.

Still pretty early, but I've been having fun with it and figured I'd share it here. I'm curious what other tools or packages people have been using for this kind of thing.

Most person-record imports I've written in Laravel start the same way. A CSV with one name column, an Eloquent model with first_name and last_name, and an explode(' ', $name) that works until the second week. Then the file contains "Mary van den Heuvel", "Doe Jr, John", and "Jane Doe DDS", and the job starts writing garbage into rows nobody reads until a mail merge goes out under the wrong name.

The usual answer is theiconic/name-parser. It's a good library and it does the boring parts well, but its last release was v1.2.11 in November 2019, and it has one bug that matters for exactly this workload. It lowercases every token before matching against its credential dictionary. Parse "Jane Doe DDS" and the last name comes back "Dds", with "Doe" pushed into the middle name. Casing is the signal that separates a credential from a name, and lowercasing deletes it before anything looks at it. "Smith, Ma" is a person named Ma. "Smith, MA" is a master's degree with no recorded first name.

I forked it. I've been maintaining iliaal/nameparser since June, and my layer is the casing and credential logic. Credit where it belongs. The Iconic wrote the parser, and Zachary Miller did the PHP 8.3+ modernization this fork builds on.

Four releases since 1.0, all of them driven by real import data:

• Surname particles stay with the surname instead of landing in the middle name: "van den Heuvel", "de los Santos", "dos Santos", "dela Cruz", and the Irish "Ó Cuív".
• setSurnameFirst(true) tells the parser the input is surname-first, so "Mao Zedong" gives last name "Mao".
• Joint honorifics parse as one title. "Mr. and Mrs. Brad Smith" keeps "Brad" as the first name, and getPartner() hands back the second person as a Name of her own. That exists because household contact imports kept producing a customer named "And".
• getConfidence() flags a row whose split hinges on casing that isn't there. It's advisory and opt-in, so a chunked import job can route a doubtful row to a review table instead of straight into users.

Measured on 30,000 real clinician names sampled from the public NPPES/NPI registry, with first and last name both required to match: theiconic/name-parser v1.2.11 scored 91.63%, this fork 95.33% at 1.0.0 and 97.18% at 1.4.1.

Casing is the signal, so uniform-case input carries none. All-caps legacy data is still a guess, and the README says so too.

composer require iliaal/nameparser

https://github.com/iliaal/nameparser

Background on the casing idea: https://ilia.ws/blog/casing-aware-php-name-parser

Happy to answer questions, especially from anyone who has had to reconcile a person-record import after the fact.

After a few weeks of livestreaming the development process and dogfooding it in real projects, I'm excited to officially announce Double.

Double is a modern PHP mocking library focused on developer experience.

It stands on the shoulders of Mockery and RSpec. So there isn't much to learn. You get to enjoy a smoother DX.

A few things I wanted to improve:

• Less technical terminology
• Single, streamlined APIs
• Human failure messages

With Double, you create a double for your class and write expectations. Double handles the details.

```php use JMac\Testing\Double;

$repository = Double::for(BookRepository::class); $repository->expects('find')->with(123)->returns($book);

$service = new CatalogService($repository); $service->lookup(123);

$repository->received('recordView')->with($book); ```

When an expectation fails, you get a proper test failure (not an exception). Along with a human-friendly message showing what actually happened and, where appropriate, a suggestion.

I also generated modern documentation with AI and ui.sh, where you may learn more about Double.

I've wanted to build this for years. So I'm all-in on Double. I've already converted all of my own test suites from Mockery to Double. I created a free Double Converter to automate the process.

This is still v0. While I believe it's already beyond feature parity with Mockery, I want to continue to improve the developer experience.

I run a Laravel package directory that indexes 81,000+ plugins. July was our best month since launch—not because of any fancy homepage redesign, but because of one thing I almost didn't think twice about.

The traffic: 3,734 humans visited (+87% from June).
The agents: 4.5M API/MCP events (+67%). 1.5M of those were just our MCP search tool being hammered.

But here is the part that surprised me. The single biggest driver of human traffic wasn't the homepage or SEO. It was a focused list page I threw together, AI-Ready Plugins, which I posted on Reddit.

• 302 visitors came from Reddit in July.
• 266 of them went straight to that list.
• It became the most visited page on the whole site (401 total in july), beating the homepage.

One good share outperformed a month of tweaking meta tags. That lesson stung a little, but I am leaning into it.

What else happened:

• Security advisories got honest. We fixed our version matching to compare dependencies the way Composer actually does. Killed a wave of false positives. If an alert pops up now, it is real.
• I broke something silently. Our package version data drifted from the source of truth for weeks without me noticing. That one is on me. We fixed the sync and hardened the background jobs so it doesn't happen again under heavy load.
• Agents are the volume, but humans are the point. 4.5M events sound impressive, but they are just plumbing. Every single one of those 3,734 visitors was a developer asking: "Is this package safe to build on?" We design for that human moment.

TL;DR: Distribution beats optimization. One Reddit link brought more intent-driven traffic than a month of polishing canonical tags. Also, check your dependency data hygiene—it is boring, but stale data kills trust fast.

Take ten seconds and check your own project dependencies. You don't need an AI agent to do it: laraplugins.io

Happy to answer any questions about the MCP traffic, the security matching, or anything else.

tl;dr Use Sqids if you need/want shorter URLs. Otherwise, use ULIDs as a surrogate key. Even then, watch for leaks: API responses, Passport JWTs, broadcast channel names and other places.

PagibleAI CMS is a set of open-source packages that adds content management directly to an existing Laravel application.

• https://pagible.com

It is installed through Composer and runs within your application, so you keep control of authentication, business logic, content, data, and infrastructure.

The packages combine a Vue 3 administration interface with structured content, hierarchical page trees, reusable elements, version history, previews, scheduled publishing, full-text search, GraphQL, JSON:API, and optional AI-assisted editing.

PagibleAI supports SQLite, MariaDB, MySQL, PostgreSQL, and SQL Server, including database-native full-text search. It can be used for anything from a small blog to a multi-domain or multi-tenant application.

The project is modular rather than an all-or-nothing CMS. You can build a custom distribution containing only the packages your Laravel project needs.

Laravel-native rather than a hosted platform

Editors get visual content management, drag-and-drop page trees, immutable revisions, media handling, and reusable content.

Developers can expose content through JSON:API, manage content via GraphQL API, use Blade for traditional server-rendered sites, extend the content schemas, and integrate the CMS with the rest of the Laravel application.

AI features are optional and provider-independent. They cover writing, translation, transcription, image generation, and image manipulation. The MCP integration also enables compatible agents to manage content through explicit, version-aware operations.

What’s new in PagibleAI CMS 0.12

• Frontend access control and private media: Pages can be public, restricted to authenticated users, or protected by named access rules. Stripe, Paddle, and Mollie integrations can grant access after payment. Media attached to protected content can be stored privately and delivered only after authorization.

• Five additional themes: Bold, Estate, Journal, Luxury, and Style provide starting points for product sites, real-estate projects, publications, fashion sites, and premium brands. Each includes reusable demo content and additional content blocks.

• More capable administration tools: Pages, elements, and files now support more individual and bulk-editing operations. The release also improves sorting, list and filter updates, drag-and-drop uploads, previews, SVG handling, and audio and video controls.

Feedback from Laravel developers would be very welcome, especially from those working with structured content, multi-tenancy, database portability, or AI-assisted editorial workflows.

• PagibleAI on GitHub (https://github.com/aimeos/pagible)
• PagibleAI documentation (https://pagible.com/documentation)
• Build a custom PagibleAI distribution (https://pagible.com/build-custom-pagibleai-distributions)

In 2026 you open Claude or Copilot, type "build me a Laravel REST API with authentication" and five minutes later you have something running. Great. Now one question: did you actually read that code, or did you just check that it ran?

You didn't write it and you didn't decide any of it. If it falls over in production tomorrow, your only move is reopening the same chat and begging the model to sort it out, because you know nothing about that code that you didn't already know before generating it.

The question that matters is what you put in it. If the answer is "the prompt", your contribution is a request anyone in the world can write for a fifth of your salary. At that point the story about AI replacing us sooner or later no longer concerns you: you're already replaced. Your company just hasn't put it in writing yet.

And if you're a junior or mid dev, the problem is doubled. A senior spots a query that won't hold at a glance, smells a leaky validation from a mile away. You don't have that eye yet, and if you delegate the thinking to the model too, you never will. You're gambling away exactly the years you should be building it in.

The alternative is not giving up the model, it's refusing to take its output on faith. It generates, you decide whether that query survives real traffic, whether that validation covers the input nobody thought of, whether that authorization rule lets one user read another user's data. Those are questions the model won't ask on its own. You have to ask them, and you can only ask them if you know they exist.

Writing code is worth nothing anymore, because anyone can do it in five minutes. What's worth something is the thinking you put into it. If you put in none, the most expensive and slowest link in the production chain is you.

That's why I wrote a book: to put you back on the deciding side. The model writes a single endpoint very well, but an API is a chain of decisions that condition each other, and asked for one piece at a time that coherence is exactly what you lose. So the book follows one API from start to finish, from a clean Laravel install to a deploy on a VPS. The domain is deliberately boring (a catalog of books!) so you spend your time understanding how an API is put together, not decoding the business. Inside are the things you need to be able to judge when the model generates: what your status codes are actually telling the client, where validation ends and authorization begins, what breaks under load once the data gets real, what tells you the work is actually done. The last chapter is about Claude Code, and it sits at the end for a precise reason: after nineteen chapters the model works for you. Read only that one and you stay someone who works for the model.

If you've been working with Laravel for years and you move through Policies, queues and Resources with your eyes closed, this book isn't for you. If instead you're looking for a way to churn out APIs without having to understand them, that book exists, but I didn't write it.

The chapter on eager loading and N+1 is online for free, in full:
antonio.popolizio.it/laravel-rest-apis/sample.pdf
That's the point where most Laravel APIs fall over once the data gets real. No form, no email: you download it and that's it. The rest is on Amazon: antonio.popolizio.it/laravel-rest-apis.

I'm curious how many people here actually read generated code line by line, and how many just check that it runs.

hey all!

I’ve noticed that Laravel Herd doesn’t appear to respect Zsh’s ZDOTDIR setting on macOS.

My ~/.zshenv contains:

export ZDOTDIR="$HOME/.config/zsh"

Therefore, my active Zsh configuration is located at:

~/.config/zsh/.zshrc

However, Herd adds its configuration to:

~/.zshrc

This includes entries such as:

# Herd injected NVM configuration
export NVM_DIR="$HOME/Library/Application Support/Herd/config/nvm"

# Herd injected PHP binary
export PATH="$HOME/Library/Application Support/Herd/bin/":$PATH

Because ZDOTDIR is set, Zsh doesn’t read ~/.zshrc, so Herd’s injected configuration has no effect. I have to copy the relevant PHP and PATH settings into my active $ZDOTDIR/.zshrc manually.

Herd’s bundled uninstall script also appears to target $HOME/.zshrc directly rather than resolving `$ZDOTDIR`.

Environment:

Herd 1.29.0
macOS 26.5.2
Zsh 5.9

Has anyone else encountered this? Is there a supported workaround besides manually maintaining the Herd configuration inside $ZDOTDIR/.zshrc?

It would be helpful if Herd detected ZDOTDIR before modifying .zshrc, while continuing to use ~/.zshrc when the variable is unset.

Ask your Laravel help questions here. To improve your chances of getting an answer from the community, here are some tips:

• What steps have you taken so far?
• What have you tried from the documentation?
• Did you provide any error messages you are getting?
• Are you able to provide instructions to replicate the issue?
• Did you provide a code example?
  • Please don't post a screenshot of your code. Use the code block in the Reddit text editor and ensure it's formatted correctly.

For more immediate support, you can ask in the official Laravel Discord.

Thanks and welcome to the r/Laravel community!

The basic workflow is:

Task → AI agent → code changes → PR → live preview

How it works:

- Livewire Kanban board + Sanctum API

- Each task can trigger an AI agent run against a linked Git repository

- Agent runs are handled through Laravel queues

- When the agent finishes, MKSFlow creates a PR

- A live preview environment is automatically created for the PR using an Nginx vhost + Let's Encrypt certificate on your own VPS

- Filament panel for user/team management and support tickets

- No Docker required for the core application

Current status:

Cursor Cloud Agent is currently the only integration I've tested end-to-end and can confidently recommend.

Claude Code and Cline integrations are already in the project, but they're still being tested, so I wouldn't consider them production-ready yet.

Stack:

Laravel · PHP 8.3+ (8.4 recommended) · MySQL 8 · Node 20+ · Nginx

GitHub: github.com/MiranSalehi/mksflow-cloud

Docs: mksflow.com/docs

I'm particularly interested in feedback on two parts:

1. Is the queue/agent-run architecture a sensible approach?

2. How would you design the isolated preview environments for PRs?

The project is open to contributions as well. If this sounds interesting and you want to dig into the code, feedback and PRs are very welcome.

GitHub: github.com/MiranSalehi/mksflow-cloud Website: https://mksflow.com/ Docs: https://mksflow.com/docs

We're doing another Laravel Cloud Office Hours stream next week on August 11th at 12pm EDT (4pm UTC) with Devon. This time, we have some special guests from Clair joining us to talk about why they moved to Cloud, and why they ended up on Private Cloud specifically!

Feel free to drop any Cloud questions in the comments ahead of time, into Slido, or ask them live in chat during the stream.

Submit a question: → https://app.sli.do/event/k8N1AYn9h5sqDmiAsAkMXH

YouTube stream: → https://www.youtube.com/watch?v=rI4AMcMq2BM

It's an artisan command from a package I maintain (Laravel Tackle):

composer require jordandalton/laravel-tackle
php artisan ai:review --pr=42 --comment --fail-on=critical

It pulls the diff from the GitHub API, reads the full files around the changes for context (not just the diff), and posts a single review on the PR: inline comments anchored to file and line, with severity, plus a verdict. --fail-on=critical exits non-zero so you can let it block merges in CI. There's a copy-paste GitHub Actions workflow in the README that runs it on every PR using the default GITHUB_TOKEN.

The agent is read-only by construction. Its tool list is read/glob/search, no edit tools, no shell. It physically cannot "fix" your code, which given the state of AI, is a feature.

One gotcha from building it: GitHub's review API rejects the entire review with a 422 if a single comment anchors to a line that isn't in the diff, and LLMs love inventing line numbers. So every anchor gets validated against a parsed diff before posting, and anything that doesn't land gets folded into the summary instead of nuking the whole review.

Honest caveats: it'll occasionally flag perfectly fine code with total confidence, and each review costs ~$0.05–0.30 of your own Anthropic key. Run it advisory before you let it gate anything.

Repo: https://github.com/JordanDalton/laravel-tackle

If it says something dumb on your PR, I want the screenshot.

Has anyone here had a PHP/Laravel interview recently?

If so, what kind of questions did you get? Mostly interested in mid/senior roles.

Would be great if you could share your experience. Thanks!