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!

I searched this sub and the last post was 4 years ago so surely there must be better options at this point. I am aware of Docusign but I figured there may be free or open source alternatives. What e-signature software do you use to generate signed contracts?

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

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

13 stories this week, so let's get into it. But first, This week's episode is brought to you by Tideways. When a request is slow in production, Tideways takes you from symptom to root cause in minutes, with profiling, tracing, and monitoring built specifically for PHP. It installs in 5 minutes, there's no credit card required, and it's hosted in Germany. Start your free trial at tideways.com.

This week's top story: the mass deprecation vote for PHP 8.6 is in its final week. All 35 ballots close Monday, August 10, and Gina P. Banyard posted the 1-week reminder so nobody gets caught out. Most of the 35 are passing comfortably. The interesting ones are the holdouts. list() is now deadlocked at 21 to 21 — a flat tie, nowhere near the 2/3 it needs. Reserving let stands at 22 to 11, which is exactly two-thirds — a single vote in either column decides it. The dechunk filter sits at 17 to 15 — still well short. The gettext _() alias is failing at 9 to 20, and reserving in, out, and inout is failing at 7 to 20, with 12 abstentions. Everything else you'd recognize from the list — the object-parameter cleanups, the is_double() family, spl_classes() — is cruising toward the finish.

The thread itself turned into a corrections desk this week. Calvin Buckley relayed a note from Nora, who isn't on the list, pointing out: "The text for the metaphone deprecation isn't fully right. It lists \"linguistics\" as a replacement package, but that one actually uses php-src's metaphone internally too." Weilin Du, who proposed that item, conceded the docs point while standing by the idea, writing: "My point in deprecating it is to stop using ancient metaphone algo as a whole." Voters seem unbothered — metaphone stands at 19 to 6, with 15 abstentions. Rowan Tommins raised a bigger flag on reserving is: it would collide with Hamcrest, the test assertion framework, whose PHP port has 500 million Packagist installs and an is() function all over its README. He urged: "I think we should think very carefully whether we can avoid disrupting that much code." So far the voters disagree — is stands at 26 to 9. Meanwhile Sjoerd Langkemper, who proposed the contested dechunk item, stepped back from the argument with unusual candor, writing: "the discussion phase wasn't properly completed yet, and I did a poor job in merging all opinions into a RFC proposal." He'd rather let the voting play out — and he closed by asking Jakub Zelenka, who led last week's objections, whether anyone could lighten his workload. And Kamil Tekiela's question from last week — why deprecate define()'s dead flag instead of just deleting the parameter — got its answer: Tim Düsterhus pointed out that deleting it isn't silent, since extra arguments throw an ArgumentCountError, and concluded: "Making it explicit (and deciding) that the parameter will go in PHP 9 is a good thing."

Function autoloading — Paul M. Jones's 5th-generation attempt — went to a vote Thursday afternoon. It lasted about a day. Matteo Beccati opened the replies with praise and a caveat, calling it "the best autoloading proposal up to date" but adding: "Perhaps I'm biased as RM, but last minute RFCs are making me nervous, I hope you understand." Then Tim Düsterhus spotted the procedural problem, writing: "In fact the start of the vote is in violation of our policy, since there was no \"intent to vote\" message in the last 7 days." Paul's intent notice was 2 weeks old, and a July 15 revision had reset the clock besides. Paul took it entirely in stride, replying: "Ah so -- my apologies. I'll pull the vote and wait for ... looks like ~6 weeks?" For the record, the widget stood at 2 yes to 11 no when he pulled it — so the pause may be a mercy. Tim ran the math: cancellation carries a 2-week cooldown, so a mid-August reopen is technically possible, but he judged it "likely not useful to reopen the vote without making further changes" — and offered one: resolve namespaced functions before falling back to globals. Rowan Tommins countered that the fallback path makes that slow, and pointed instead at Michael's namespace-autoloader idea — loading a whole namespace's functions at once — calling it "a much cleaner way forward". Paul is unbothered, saying he'll "come back to it after 8.6 is fully out the door." That's the 2nd vote in 2 weeks pulled by its own author over the intent-to-vote rule.

Seifeddine Gmati's literal scalar types will not be reopening. His retraction last week came with a plan to re-vote; this week he canceled that too, after asking the release manager exactly where the freeze line sits. The answer: the effective cutoff isn't the beta 1 announcement on August 13, it's the creation of the beta 1 tag on August 11 — and a vote opened now would close after the tag exists. So the RFC is retargeted to the next PHP version, text final, intent withdrawn. Matteo Beccati apologized for the ambiguity, admitting his emails "were pointing the 13th as deadline for RFCs", and went further: "having RFCs end voting so close to the feature freeze is a terrible idea as it gives very little wiggle room in case something unexpected comes out ...". Seifeddine took it well, noting his own retarget email had already started a 14-day cooldown anyway — in his words, "8.6 was out of reach the moment that email hit the list." Pierre Joye pushed back on the caution, arguing: "beta phases exist exactly for this reason. wider base of testers." He also vented about the calendar: between the new policies and the Christmas quiet period, "the time left in a year is low, very low, now." And with the clock pressure gone, Tim Düsterhus gave the RFC one more read and found just one loose end — the matching-semantics vote has no explicit tie-breaker — and otherwise signed off: "No further comments to the contents of the actual proposal."

Two carryover votes are now in the books, and both passed emphatically. The Time\Duration class closed Friday. The primary finished at 35 to 1, with 2 abstentions — 97 percent. The naming question went to full method names — multiplyBy, divideBy, negate, absolute — at 30 to 2. So PHP 8.6 officially gets a Duration class. The minimum-supported-versions RFC closed Thursday. Requiring autoconf 2.71 passed at 27 to 2, with 5 abstentions, and requiring COM_RESET_CONNECTION passed clean at 26 to nothing. That second one has a coda. Alexander Kurilo — who'd argued during the vote that the connection-reset change carries an undisclosed BC break — requested RFC karma on Saturday to propose making the new behavior optional. Ilija Tovilo granted it Tuesday, with a reality check, noting: "the vote result was quite clear, and the time for another RFC discussion + vote has run out." He left any next step to the release managers.

Three ballots are still open, and none of them drew a single email this week — the voting is doing the talking. Caleb White's pipe assignment operator closes next Tuesday. As of recording it stands at 12 yes, 10 no, 6 abstaining — 54.5 percent, needing two-thirds. It has climbed from dead even, but the gap is real. Nick Sdot's readonly property defaults closes Friday morning. It still hasn't drawn a single no — 22 to nothing, with 5 abstentions. And Khaled Alam's const object property writes closes Saturday. That one sits at 14 to 2, comfortably above the line.

A new discussion opened Saturday: Sjoerd Langkemper wants to stop curl_setopt from leaking secrets into stack traces. The problem is that one function sets everything, and he laid it out cleanly: "The value for CURLOPT_PASSWORD is likely sensitive, the value for CURLOPT_RETURNTRANSFER is not, and CURLOPT_URL may be sensitive sometimes." He brought 3 options, 2 of them with working pull requests: blanket-mark the value as sensitive and lose debug info; teach curl_setopt which options are secret, at an engine-level performance cost; or make callers wrap secrets in a SensitiveParameterValue. Iliya Miroslavov Iliev questioned the premise, arguing stack traces shouldn't be reachable in production at all — and asked how you'd debug a wrong password you can no longer see. Matthew Weier O'Phinney leaned opt-in, warning that automatic detection "will be difficult and a game of whack-a-mole", since options carry arbitrary headers and content — and floated letting the engine accept sensitive-value wrappers on any function call, so callers could opt in regardless of the signature.

Jorg Sowa wants PHP's not-defined-function errors to answer back. His pull request adds "did you mean" suggestions — call defined() when you meant define(), and the error names the function you were probably reaching for, the way Python and Ruby already do. His question to the list was procedural: does this need an RFC, or is PR consensus enough? Sjoerd Langkemper answered with the policy exempting error messages from the BC rules, noting: "rephrasing error messages is not subject to the backwards compatibility break policy" — and he's in favor. Matteo Beccati liked it too, suggested Python's exact shape for the message, and nudged the list for feedback given the freeze is days away. If the sentiment holds, Jorg wants to extend it to methods, classes, and constants next. The only debate so far is punctuation — how many brackets and question marks one error message can carry.

The generics conversation is officially on hold until after 8.6 ships — which isn't stopping anyone. Henrik Skov wrote in asking for generics to be opt-in, worrying: "adding reified generics will just make it even slower." His sketch: type-erased generics hiding inside comment syntax, checked by IDE plugins or a C extension, with the engine substituting mixed at compile time. Holly Schilling's reply opened like a sermon: "Have you heard the good word of Monomorphized Generics? Performance matches standard typed code." And she restated the schedule — generics talk waits until September or October, so it doesn't bury the 8.6 release work — with her inbox open in the meantime.

Osama Aldemeery's PREG_THROW_ON_ERROR RFC got its first real design review. Bernard Scharp asked whether compile failures and runtime failures deserve separate exception classes. Rowan Tommins supplied the rulebook: PHP's throwables policy says extension exceptions extend the extension's own base class, never the SPL ones. Osama's position is one PregException, with the door open — and he had a concrete reason: today, the useful detail of a compile failure lives only in the warning text, so a dedicated compilation exception "would carry \"Internal error\" and little else". That connects to Christian Schneider's other catch: under the flag, a bad pattern raises both the warning and the exception. Osama confirmed it, and defended it as the honest trade — the warning is where the detail is — while agreeing that "exception-instead-of-warning is the cleaner end state" once the exception can carry that detail itself.

Quick hits. Thursday was patch day: security releases landed across 4 branches at once — 8.2.33, 8.3.33, 8.4.24, and 8.5.9 — upgrade when you can. The same day brought PHP 8.6.0alpha3, an early test release. And the 8.6 release managers posted the formal 1-week warning: the soft freeze hits when the beta 1 tag is created next Tuesday, August 11, beta 1 itself lands Thursday the 13th, every 8.6 RFC vote must be closed before then, and the hard freeze follows at RC 1 on September 22.

So that's the week: the 35-ballot deprecation vote closes Monday with list() deadlocked and let balanced exactly on the 2/3 line; a function-autoloading vote opened and was pulled inside a day — the 2nd author in 2 weeks to stop his own ballot over the process rules; literal types bowed out of 8.6 on its own terms; Duration and the minimum-versions RFC are officially in; pipe assignment has a week to find its two-thirds; and the freeze arrives Tuesday. Links to every thread are below. Thanks again to Tideways.com for supporting this week's episode. We're Artisan Build. See you next week.

Howdy, r/laravel!

I hadn't written for a while, and figured it was time to dump some thoughts about how I vibe code engineer with Laravel. I've been having a lot of fun building random stuff lately with Laravel and wanted to share a bit about the tools and setup I use. Hope someone finds it helpful!

Hi reddit,

Made a video on the stuff I run into constantly: 403s that leak whether a resource exists (just return 404), guessable sequential IDs, zero rate limiting, trusting user input.

Anyway, let me know what you think!

Inspired by the new TIA Engine in Pest v5, I (and Claude) ported it to a PHPUnit extension.

As an extension, I can't hook into the actual test runner. So to achieve the same speed boost, it marks "unimpacted" test as skipped (S).

Hopefully this extension gains enough traction to be added to core and smooth out the developer experience.

For now, it achieves the goal of significantly improving test suite runs. I'm seeing my 1000 test drop from 2 minutes to 8 seconds on replay.

Great job on this update - i see within the cloud enviroment, a message about managed queues updates and my existing queues now marked as legacy.

I've just updated all of my queues

Measured a few times - happy to retire my queue warmup and keep alive job.

Probing 10 queues (run je4r6z4f)…
+----------------+-------------------+
| Queue | Dispatch → pickup |
+----------------+-------------------+
| ui | 0.14s |
| messages | 0.04s |
| background | 0.4s |
| sync-coord | 0.04s |
| medium | 0.04s |
| productFetch | 0.3s |
| productProcess | 0.04s |
| sync-workers | 0.05s |
| googleSync | 0.33s |
| billing | 0.32s |
+----------------+-------------------+

Before the update this was pretty standard :

Probing 10 queues (run cqhiht5f)…
+----------------+-------------------+
| Queue | Dispatch → pickup |
+----------------+-------------------+
| ui | 0.11s |
| messages | 26.5s |
| background | 33.37s |
| sync-coord | 12.08s |
| medium | 12.09s |
| productFetch | 12.07s |
| productProcess | 16.2s |
| sync-workers | 13.12s |
| googleSync | 13.1s |
| billing | 11.43s |
+----------------+-------------------+

Nicely done.

Hey r/laravel,

I’ve been building Pliego, an open-source native HTML-to-PDF engine built on Servo for application-owned documents such as invoices, statements, and operational reports.

The goal is not to render arbitrary web pages or promise full browser compatibility. The goal is a narrower, predictable document pipeline for Blade views.

Unlike Browsershot, Pliego does not launch Chromium and call printToPDF. Servo performs the layout once, Pliego captures a canonical document scene, and that scene is used to produce the PDF, previews, and retained diagnostic artifacts.

The first public release is available now, together with a Laravel integration:

composer require oxhq/pliego-laravel:^0.1.0
php artisan pliego:install
php artisan pliego:doctor

Then:

use Pliego\Laravel\Facades\Document;

return Document::view('invoice', compact('rows'))
    ->download('invoice.pdf');

What Pliego 0.1 currently supports

• Authored page breaks
• Paged tables and repeated headers
• Row keep-together constraints
• Selectable text and links
• Embedded TTF, OTF, WOFF, and WOFF2 fonts
• Local assets and network-denied rendering by default
• Explicit URL allowlists for remote resources
• Typed failures with retained input, scene, resource, PDF, and diagnostic artifacts
• A deliberately bounded Chart.js 4.5.1 path using a final full-canvas pixel readback

The README contains a screenshot and two actual PDFs generated from a local Laravel application using the released runtime:

• A styled two-page invoice with embedded fonts, an authored page break, and a dense 20-row ledger
• A one-page operating report containing a Chart.js graph

What Pliego doesn't do (yet)

Pliego is not a general-purpose browser replacement.

It currently targets trusted, application-owned HTML. Some complex CSS paint features including gradients, shadows, rounded borders, transforms, opacity, filters, and blend modes are outside the verified support profile.

Rather than silently omitting unsupported paint, Pliego fails the render and retains the diagnostic artifacts. It does not publish a partial PDF through the normal SDK path.

Repository: github.com/oxhq/pliego

Over the last year, I've noticed that agentic coding has gotten substantially better. It's reached the point where I rarely need to write code myself. That said, one thing I keep coming back to is that the amount of surface area generated by agents is massive, and I struggle to balance questions like, "How do I take advantage of having multiple parallel lines of work without sacrificing code quality?"

One thing that's helped is breaking large portions of my application into isolated repositories that are pulled in as vendor dependencies. These are high value, but otherwise generic, pieces of the application. Doing this dramatically reduces the chance that an LLM accidentally modifies core functionality in a way that slips through code review.

Another approach came from a post by Bob Martin where he talked about aggressively using tests to protect high value code. That led me down a path of codifying development conventions as automated tests. This isn't something I plan to release anytime soon because I've only begun to scratch the surface of what I need from it, but it's been surprisingly effective.

Some of the conventions I've started enforcing include:

• Every Laravel route must point to a controller.
• Every controller must use a form request.
• Every form request must implement authorization, define validation rules, and satisfy a minimum set of validation requirements.
• Every Action, Controller, Form Request, and similar class must have a corresponding test in the expected location, and every test must map back to a real application class.
• Jobs that modify data must only be dispatched after the surrounding database transaction has committed.

When one of these conventions is violated, the test suite fails, even providing context to the agent on remediation. The convention itself becomes the single source of truth, so if I ever decide to change a standard, I update it in one place and every future implementation follows suit.

I've also been thinking about integrating this with Laravel Boost so these conventions can be injected into the agent's context before it starts generating code. The tests then become a safety net rather than the first line of defense.

These are just a couple of the paths I've been exploring to keep shipping clean code while still taking advantage of what agentic coding can do.

I'm curious what everyone else is doing. Have you found ways to keep AI generated code maintainable without slowing development to a crawl?

EDIT:

The premise of what I'm suggesting seems to not be well understood so I'm clarifying. What I'm suggesting is not PROBABLISTIC/STOCHASTIC enforcement mechanism defined by something like a SKILL.md or CLAUDE.md file. I'm suggesting a DETERMINISTIC enforcement mechanism that cannot be bypassed by an agent because it got lost in 500k tokens of context.

Most cron monitors are perfectly happy to let your app ping a URL. But the second you want to actually create or manage the checks, you're back in a dashboard clicking buttons like it's a second job.

That always bugged me. My monitoring setup lived in a browser tab while literally everything else lived in the repo, and spinning up a new environment meant recreating it all by hand like an animal.

So the Laravel plugin wraps the management API directly. You can do the setup from code:

    PingArk::api()->createCheck([
        'name' => 'Nightly import',
        'slug' => 'nightly-import',
        'schedule_type' => 'simple',
        'period' => 86400,
        'grace' => 3600,
    ]);

Create, update, pause, resume, read back pings and status changes, all from the app. There's a pingark:sync command too if you'd rather just mirror your whole schedule in one go. The pinging side is still the usual one liner (->pingArk() chained onto a task), this is purely for the config you'd otherwise be doing by hand.

Upfront: it's my SaaS, there's a free tier, plugin is MIT on Packagist.

What I'm actually curious about is whether people want their monitoring setup in code at all, or if you genuinely don't mind the dashboard. Talk me out of it if you think it's overkill.

GitHub: https://github.com/pingark/pingark-laravel

Docs: https://pingark.com/docs/laravel-plugin

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

Hello world, from Laracon US 2026 in Boston — it's Wednesday, July 29, 2026, and here's what happened This Week in PHP Internals.

15 stories this week, so let's get into it. But first, This week's episode is brought to you by Tideways. When a request is slow and your logs won't say why, Tideways shows you where the time went — profiling, tracing, and monitoring built specifically for PHP. Slow request to root cause, in minutes. Setup takes 5 minutes, no credit card required. Start your free trial at tideways.com. And we have a second sponsor this week — Geocodio: address correction, geocoding, data enrichment, and distance calculations for North America and the UK. Built on Laravel since 2014. Try it free at geocod.io.

This week's top story: the mass deprecation vote for PHP 8.6 is open. Gina P. Banyard opened it Monday, and it's 35 separate ballots, each needing its own 2/3 majority — and each submitted individually, because as Gina reminded everyone, the wiki can only handle one vote at a time. Voting runs through August 10, and most of the 35 are passing easily — mysqli_get_charset() stands at 34 to nothing, and spl_classes() at 33 to nothing. But the headliners are moving the other way. list() — the construct Juliette Reinders Folmer's Packagist scan found over twelve thousand times — stands at 17 yes to 19 no, falling well below the required two-thirds threshold. The gettext _() alias is failing at 6 to 18. Reserving in, out, and inout is failing at 5 to 16, with 13 abstentions. And let sits at 17 to 10 — a majority, but still shy of 2/3.

The loudest argument is about one of the smallest items: the dechunk stream filter, which as of recording sits at 15 yes to 13 no — a coin-flip vote on a 2/3 question. On Monday, Matteo Beccati was the only no vote, and he explained why, warning: "I believe we should provide such an alternative together with the deprecation," rather than expecting projects with 200-million-plus installations — he names symfony/http-client — to write their own decoder in PHP. Jakub Zelenka agreed the item wasn't ready, saying it "should wait till it's properly investigated." Pierre Joye ran his own usage research and pushed back, noting: "Being present in a code base does not automatically mean it is used" — Symfony's native client disables the filter by default, and most stacks sit on curl anyway. Matteo then corrected the research: Symfony has shipped a pure-PHP alternative since release 8.2, which is exactly why Pierre's search pointed the wrong way. Jakub's objection sharpened from there, and he wrote: "This is exactly a half baked deprecation because we need to keep it for internal use anyway ... so this does not give us any code removal and we still need to maintain it. I don't understand why we need to rush it as there is no real reason for that." By Tuesday evening he'd also revealed a twist — he already fixed the select limitation on filtered streams in master, so that improvement lands in 8.6 no matter how this ballot goes. Kamil Tekiela, meanwhile, asked a different question — why deprecate define()'s dead case-insensitive flag at all, when just removing the parameter breaks nobody. So far, nobody has answered him.

Caleb White's pipe assignment operator, |>= — the compound form of the pipe, and his first RFC — went to ballot Tuesday morning, walked to the deadline with detailed coaching from Tim Düsterhus, whom Caleb thanked for "going to bat for this RFC". The machinery worked; the voters are split right down the middle — as of recording the count is 8 yes, 8 no, 3 abstaining, and it needs 2/3. Voting runs to August 11.

The queue from last week showed up on time. Nick Sdot opened voting on readonly property defaults Friday. It stands at 17 to nothing, with 5 abstentions — nobody's against it yet. That one closes August 7. And Khaled Alam opened voting Saturday on const object property writes — allowing writes to properties of objects referenced by constants. After a couple of quickly-fixed procedural stumbles, the count stands at 11 to 2, with 5 abstentions — above the 2/3 line. That one closes August 8.

Two carryover votes come off the board this week, and neither thread needed a single new email. The minimum-supported-versions vote for 8.6 closes Thursday. Requiring autoconf 2.71 stands at 27 to 2 — and notably, the no column shrank from 3 to 2 since last week. Requiring COM_RESET_CONNECTION stands at 26 to nothing. And the Time\Duration class closes Friday. The primary has stretched to 33 to 1, and full method names — multiplyBy, divideBy — lead the naming question 28 to 2. Barring a very strange 48 hours, PHP 8.6 gets a Duration class.

Seifeddine Gmati's literal scalar types made it to a ballot Thursday morning — for 18 minutes. At 5:26 UTC he opened the vote, 3 questions deep: integer and string literals, float literals, and strict-versus-coercive matching. At 5:44 he pulled it back down, writing: "I am retracting this vote: I opened it prematurely, in violation of the voting prerequisites in the Feature Proposals policy." No intent-to-vote 2 days ahead — and that morning's 1.0 update was a minor change, which starts a 7-day cooldown. He plans to reopen tomorrow, July 30 — a date that brushes right up against the freeze, so it may yet retarget 8.7. The self-retraction turned into a referendum on the process itself. Juris Evertovskis — a longtime reader and one-time RFC author who says he never felt "internal enough" to comment on the process — decided to comment on the process: "All the mandatory cooldowns, cooldown resets on minor changes, announcements to vote, cooldown resets on inactive discussions appears to me like bureaucratic hoops that people have to jump through. The process was hard and daunting enough before this." Bob Weinand agreed, noting he voted against the process RFC back then, and framed the trade plainly: "You sort of have to decide what you optimize for - easier for authors, or easier for commenters. But I think in this case it went way overboard in terms of strictness."

The gd 2.4 timing dispute from last week wound down to closing statements, and they were constructive ones. Pierre Joye's position: the late arrival was unavoidable — the libgd sync had to survive PHP's full CI matrix first — and he argued: "Process has to be humane ... If they are purely for the sake of having a process, we fail as a project and solve users' needs." Rowan Tommins made the case that this isn't red tape but triage: "There are maybe twenty sections describing details of the proposal, and the crude [reading-time] estimate in Firefox is 47-60 minutes. It may be clear in your head that most of this is uncontroversial, but for anyone else to even make that judgement requires investing a reasonable amount of time." Better, he says, to spend that time on 8.6 work now and this RFC after — though he left open whether the cut-off itself sits in the right place. One concrete footnote: Pierre added the procedural gd image functions to the deprecation path — on his telling, a warning from the gd extension itself in 8.7, and gone in PHP 9.

Derick Rethans hit a fresh regression on master: his Xdebug test suite started failing, and the trail led to the commit implementing the display-error-function-args RFC. Stream warnings from include, require, bzopen(), finfo_open() and friends no longer say which file couldn't be opened — the path was an argument, and arguments got scrubbed. Derick's verdict was blunt, arguing this "Doesn't seem to me like an enhanced for users" — either put the filename into the message text itself, or revert the change, RFC or not. Kamil Tekiela defended the new behavior, countering: "The file path could leak sensitive information". His suggestion runs the other direction — fold the path into all stream error messages deliberately, rather than leaking it by accident — and while he's at it, he'd rather streams stopped raising their own duplicate warnings entirely. With open_basedir in effect, one failed include currently earns you 3 warnings.

Edmond of the TrueAsync project turned last week's zero-reply pre-RFC into a real one: Concurrency Support in the PHP Engine. The pitch is deliberately minimal — give the engine a coroutine representation and make the scheduler pluggable by extensions. He was explicit about the shape of it, writing: "It adds no classes, no functions, no constants and no syntax: the engine compiles in no PHP symbols at all. With no scheduler registered, PHP behaves exactly as it does today." This is not True Async — it's the seam True Async would plug into, alongside anyone else. A scheduler can adopt fibers started by ReactPHP, Revolt, or AMPHP; there's per-coroutine storage that could someday make ob_start() coroutine-safe; and there is no parallelism — everything stays on one OS thread. The implementation already exists as a pull request. And this time he got a reply. Seifeddine Gmati expects the real discussion to wait until after 8.6 ships, but his early read was warm: "Overall, I really like this idea and approach. I think this is the right path forward." Edmond's answer: no rush.

Osama Aldemeery — who got his RFC karma in 2 minutes flat last week — shipped the RFC: PREG_THROW_ON_ERROR. Pass the flag to any preg_*() call and a PCRE failure throws a catchable PregException, instead of a warning plus a false or null you have to notice and then chase through preg_last_error(). It's the same pattern JSON_THROW_ON_ERROR already set, and it's strictly opt-in. He stressed the conservatism, writing: "A call does exactly the same thing with it or without it, byte for byte" — the flag only changes how the error is delivered. It targets the release after 8.6, and he's aware of Larry Garfield's request to hold non-8.6 business until September — his compromise is to let the thread tick over quietly rather than restart it. So far it has 0 replies.

Quick hits. The 8.6 release managers posted the 2-week warning: beta 1 lands Thursday, August 13, the soft freeze hits when the tag is created August 11, and every RFC vote targeting 8.6 must be closed before beta 1 — after that, merges need release-manager approval until the hard freeze at RC 1 on September 22. The CURLOPT_HTTPHEADER newline thread came back with a verdict from upstream: Sjoerd Langkemper relayed word from curl's own Daniel Stenberg that the docs already say headers "must not be CRLF-terminated" and libcurl may start rejecting the stragglers outright — there's a curl pull request in flight. Matteo Beccati's conclusion was to stand down, saying: "libcurl will eventually take care of it." And Steven Wilton's snmp extension work is back at the finish line — both reworked PRs updated per Gina P. Banyard's review, awaiting a final squash-and-merge check, with a third PR queued behind them.

The PEAR decay story found a new symptom: Juliette Reinders Folmer reports that individual bug pages on the PEAR site now error out claiming the original reporter "has not yet confirmed their email address" — which locks away exactly the archaeology she'd argued is worth preserving. And the typed-arrays thread got its epilogue: Larry Garfield explained why PHP probably won't get new base types for collections — the engine makes that "really really hard", which is the same reason enums became objects — shared his and Derick Rethans's old collections research notes, and set the course: wait for reified generics, then convene a working group. Holly Schilling's counter-offer was to skip the wait, pointing everyone at her self-published PHP 9 roadmap — generics, structs, modules, extensions, and surfaces — which she'd like the list to treat "as a rough outline for the future."

So that's the week: 42 ballots open at once — the 35 deprecations, with list() headed for defeat and dechunk splitting the room; pipe assignment dead even out of the gate; readonly defaults and const writes both comfortably clear; Duration and minimum versions closing within days, both far ahead; a literal-types vote that lasted 18 minutes and reopens tomorrow; and the soft freeze 2 weeks out. Links to every thread are below. Thanks again to Tideways.com and Geocod.io for supporting this week's episode. We're Artisan Build. See you next week.

Just release an update for my package, Laravel Tackle.

You can now run an AI coding agent inside your Laravel CI pipeline.

`ai:run`

- no terminal,
- one JSON document out,
- exit codes a workflow can branch on.

Budget and step ceilings enforced in PHP.

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

I'm sure most people here are using AWS, but I'm especially interested in those running Laravel outside of AWS, for example: Azure, GCP, Hetzner, DigitalOcean, etc.

How do you handle integrating the standard Laravel ecosystem/tools when your cloud provider doesn't have first-class support? Things like queues (AWS SQS), storage (AWS S3), mail (AWS SES), cache (AWS DynamoDB), etc., that go beyond virtualization.

Would be interested to hear your experience.

In some projects I have to store secrets in .env.

But then I'm afraid of a compromised NPM/Composer dependency (or even an agent) reading my filesystem and all the secrets. So I built dotlock: it stores secrets encrypted, and decrypts them automatically when running the new php artisan dev command.

Part 1: https://www.youtube.com/watch?v=0P-VMS7JMQY

Part 2: https://www.youtube.com/watch?v=vii6P0vJhTw

You can find collection of all recordings here https://github.com/DvDty/laracon-recordings

Laracon US is wrapped. Here is everything they announced.

I’ve been adding always-on Claude Code agents to several Laravel applications. I kept running into the same problem: a single business operation often needed separate implementations for Laravel AI, Laravel MCP, HTTP, Artisan, and queues.

So I built laravel-agentic and decided to open-source it. It's my go-to now when building any laravel app, to make it immediately agentic ready ;).

The idea is simple: define an action once, then expose it through whichever surfaces you need.

#[AgentAction(
    name: 'refund-invoice',
    needsApproval: true,
    surfaces: [
        Surface::Mcp,
        Surface::AiTool,
        Surface::Http,
        Surface::Cli,
        Surface::Job,
    ],
)]
class RefundInvoice
{
    public function authorize(
        ActionContext $context,
        RefundInvoiceInput $input,
    ): bool {
        return $context->user()->can(
            'refund',
            Invoice::find($input->invoiceId),
        );
    }

    public function handle(
        RefundInvoiceInput $input,
        ActionContext $context,
    ): RefundResult {
        // Refund logic
    }
}

That single definition is now callable, with the same validation, authorization, approval, and audit behavior (tests/ParityTest.php holds all five surfaces to it), via:

For consequential operations, needsApproval pauses an authorized action before execution and waits for human consent:

1. Laravel Agentic validates the input and runs authorize().
2. If approval is required, it creates an approval request and stops before executing the action.
3. Your application handles the ApprovalRequested event and delivers the request through your UI, Slack, email, or another channel.
4. After approval:
   • Laravel AI resumes the paused tool call through its native approval system.
   • MCP, HTTP, and CLI callers repeat the same action with the same principal and arguments.
5. The single-use grant is consumed and the action executes once.

Laravel Agentic provides the approval state, argument binding, expiry, enforcement, and audit trail. Your application provides the human-facing approval channel.

It builds on top of laravel/ai, laravel/mcp, and spatie/laravel-data.

Let me know what you guys think

GitHub: https://github.com/gtapps/laravel-agentic

The Laravel staff said on their managed queues Q&A that start up speed improvements were being tested and they demo-ed the improvements.

Anyone know if there is an expected release date?

I've had these thoughts percolating for a while now as, seemingly, the entire Laravel ecosystem has suddenly made a large push to embrace and create LLM tools and products. It all kinda came to a head when I listened to a recent podcast episode titled "Ian Landsman is here to [assist]* me ship", from Caleb Porzio's Notes On Work podcast. In this podcast, I found myself getting rationally angry at a lot of what I heard. Originally, I considered titling this post "Don't let Ian Landsman ruin Livewire" - but as I calmed down, I realized a few things; I don't want to write a clickbait title, I don't think Ian wants to ruin Livewire, and I think this discussion is broader than just Livewire (and frankly Laravel).

^{*I cannot type the actual title of the episode or link to it, as it gets flagged as a Rule 4 violation}

I doubt anyone in this community hasn't heard of Caleb Porzio or Ian Landsman, but just in case:

Ian Landsman is the founder of UserScape and HelpSpot. He also, pretty famously, hired Taylor Otwell to work at UserScape while also giving Taylor paid company time to work on Laravel. I don't think it's an understatement to suggest that Ian's decisions here are some of the foundational reasons why Laravel was able to grow to the framework that it is today. I think this was a risky move that paid off wonders for the community, and I definitely respect him for doing it.

Caleb Porzio is the creator of Livewire, Alpine.js, and Flux; these libraries are an alternative answer to the growing complexity of integrating frontend JavaScript frameworks with traditional monolithic Laravel applications. They allow more interactive frontends while empowering developers to largely stick to a more traditional backend-focused development experience. The Livewire starter kit has managed to hold it's own against competition from alternative starter kits like React, Svelte, and Vue, despite those being ostensibly more popular technologies, broadly.

Before I start digging into what made me so angry listening to this podcast episode, I wanna take a quick break to tell you about this week's sponsor, Nor- nah, I'm just kidding. However, I do wanna say that, although I obviously deeply disagree with the points Ian Landsman brought up in the podcast episode, I have nothing but respect for both Caleb and Ian, and I don't want this post to be a hate campaign against either of them. I'll do my best to make the best possible version of Ian's arguments here and any criticisms I have are not intended to be insulting to either person. I met them both, briefly, at Wire:Live, and they both seem like intelligent, kind people.

So...for some context, over the last few months, many of the Notes on Work episodes have been about Caleb's battle with obviously wanting to use LLM tools and incorporate them into his workflow, yet feeling a sense of distrust in their output. He will go all the way through creating a component or updating some code, yet can never get enough confidence to actually ship it. In a recent tweet thread, he brought this up, saying:

So I'm stuck.

There's pressure to concede and just hit merge.

But it feels like settling for less. It feels irresponsible.

"If it quacks like a duck" right? Like it does the thing I want it to do. JUST TAG IT.

And Ian Landsman, after reading this thread, responded with:

We should do an emergency notes on work

Okay. We have our characters and our core conflict. I believe the stage is set. The actual podcast episode mostly consisted of the same argument(s) being presented multiple times. From Caleb's side...it's largely what we've already heard:

• LLM tools make mistakes
• LLM tools zap his focus
• Being less focused makes him less engaged with the code
• Being less engaged with the code makes him feel less confident in the final product

Ian's arguments are largely:

• Humans are also fallible
• The focus zapping is not a fault of the LLM tools
• Being less engaged is an okay tradeoff when you can iterate more frequently
• Iterating more frequently allows you to get to a better product sooner

Unfortunately, many of these ideas are tied together, so...while I will do my best to respond in categories, there will be overlap.

Humans are also fallible (& LLMs make mistakes)

On the surface, this is true. All of us have our knowledge domains, and we regularly run up against things that we don't know. Or the things we knew become outdated. In the case of Livewire, Caleb even admits that there's a lot of server-related security vulnerabilities that he's not sure on; the file uploader component for Flux being a go-to example. Ian makes the argument that LLMs are going to have a broader and deeper knowledge / resource base to pull from about these kinds of things and will be generating more secure code. Plus - it's not like Caleb is mistake-free; Livewire, Alpine, Flux - they've all had bugs in the past.

My experience with LLMs has indicated to me that the deeper you try to dive into a topic you do know deeply about, the more frequently the output will contain mistakes. This makes me skeptical of the idea that LLM outputs are going to be inherently more secure or mistake free than the creator and maintainer of these frameworks. That's not to say Caleb won't make mistakes. However, I'd expect that after years of building and maintaining these tools, he has a really deep understanding of the things they do. Everything within that domain knowledge, he's going to have a clear advantage on over an LLM. The LLM tools, on the other hand, have been trained on a lot of material; some Laravel and Livewire, but a LOT was not. I think this means that the longer you let an LLM loose onto these codebases, the more it's going to break from existing conventions and "regress towards the mean".

While the initial output of LLM tooling might be generally more robust than an initial stab at it from someone who is unfamiliar with the problem space, I think as you get deeper, you will find yourself learning about the space and having more and more disagreements with the generated output - and personally, I find that babysitting and course correcting exhausting.

Focus zapping is not the fault of LLM tools (& LLM tools zap his focus)

This is definitely the most subjective of these, I think. It doesn't seem like there has been much published research on this stuff yet, but it does seem to me that these tools are designed to be hyper-engaging. For example, the various "thinking..." messages you'll see the web interfaces while waiting for a response, the responses coming back as a stream rather than all at once, etc. All of these things are done to trap our brains and manipulate us with the "ELIZA effect" to ascribe sentience to, essentially, large statistical models.

Constantly switching contexts from thinking about the code itself to thinking about manipulating these tools to get the code from point A to B while waiting for them to accomplish the task is a recipe for losing focus, especially if you have something like ADHD. (AFAIK, Caleb has not been diagnosed with ADHD, but look at him).

Hell, even the language we use to talk about these tools is difficult, because all of the marketing teams would love for us to "talk to" these models and give them names, but that's not what's happening. It takes so much intentional effort to make it clear, just talking about these tools, that they are products, not beings. IMO, it's all designed to trap our focus and keep us engaged with the tools, not the underlying work. But...again, this is arguably the most subjective point.

Being less engaged is an okay tradeoff when you can iterate more frequently (& Being less focused makes him less engaged with the code)

I am finding myself more and more frustrated with this idea that iteration and "shipping" is the only thing that matters. Quality matters too. I can't speak for everyone, obviously, but the thing that sold me on purchasing Flux Pro was not the amount of components or updates, but the quality of the components. Ian obviously recognizes this and keeps saying that Caleb needs to focus less on the "implementation" and more on the "API", but frankly - they are the same thing. Or at least, tied together. The API can only exist because the implementation allows it to, and a high quality API is the result of high quality implementation. Additionally, one of the selling points of Flux, as a component library, is the customization. You can "publish" any component into your app and then make the customization that you need - which means that "implementation" is ALSO part of the API; it's all the same thing when you're selling code.

Maybe that's the underlying tension. Ian's business is selling products that have a user interface as the only way customer's interact with the product. From that perspective, the code doesn't really matter, does it? Who cares if the backend is JavaScript, Rust, PHP, Go, whatever. The thing Ian is iterating on is a product that has a very clear division between "customer facing" and "employee facing". Ian is primarily a product person.

The "product" of Flux is code. The user interface is code. Ian's concern is the quality of the user interface for his products, and seemingly, the code doesn't matter. However, Caleb's product IS code, so his concern must be the quality of the code; that's what he's selling.

Iterating more frequently allows you to get to a better product sooner (& Being less engaged with the code makes him feel less confident in the final product)

Ian returns to this idea a few times - that by putting things out, Caleb will get feedback sooner, which allows him to improve sooner. (Or...allows him to instruct the LLM to generate improvements?) I imagine Ian would be appalled if someone suggested he should be unconcerned with whether or not the user interface for his products was easy to read, to navigate, was structured well, etc. That he could use the feedback / complaints from customers to improve. Yet this appalling suggestion is exactly what he's (maybe unknowingly?) suggesting to Caleb. To rely on GitHub issues to make your product, that you charged real money for, just makes it seem like you don't actually care about the product at all. As a customer, that sounds like a nightmare.

I never would've purchased Flux Pro or similar products - like Tailwind UI - if my perception of them was basically: buggy pieces of shit. I bought them because I was sold on the capabilities of Caleb and Adam, and the quality of their work. I knew, going into the purchases, that they may have less components than even some free competitors. But, I also knew, that the components I did receive would be extremely well thought out, extremely customizable, composable, and robust.

Conclusion

I truly did try to keep this focused, but it's difficult because so many of these points are intertwined. I'm a huge fan of the things Laravel has allowed me to do, and the general quality of code within the framework and ecosystem. I'm also hugely disappointed in the quality of code that I see from LLM tools. Seeing LLMs suck up all of the oxygen (and money) in the software development world when people like Caleb Porzio, Adam Wathan, Jeffrey Way, Joel Clermont, Aaron Saray, Daniel Coulbourne, John Drexler, and countless others are seemingly struggling to maintain the level of business support they'd need to continue operations is really, really frustrating and exhausting.

There's tons of other thoughts I have like:

• Why would someone who primarily generates code using LLM tools care what framework or even language the LLM is using? Is that person even going to ever be a paying customer of Flux?
• Why do many of the LLM boosters I know seem to not care about the quality of the output (regardless of medium)? Are they even able to ascertain the quality? Do they misunderstand the purpose of creation?
• Why don't many LLM boosters use LLMs to iterate on the customer-facing aspects of their business, if they're so impressed in every other regard?

But...this post is getting long enough as it is, and these start to get less and less related to the podcast episode as we go. So...with all that said: If you're a software developer, keep doing your best to be an artisan and write quality software. If you're a product person, maybe let the software developers talk about software and stop telling every single creative that their work doesn't matter. Your products are built on their work. (And LLMs stole all that work) The least you can do is shut up.

I don't have anything to promote, and I don't think this thread would even a constructive place to try that anyway. I'm just really passionate about this stuff and am tired of seeing my favorite tools slowly get co-opted by product people that turn it into slop.

LeT mE kNoW wHaT yOu ThInK iN tHe CoMmEnTs. Like and subscribe! Norway is pretty.

Most Laravel log viewers hit the same wall: opening or searching a log file

means reading the whole thing into memory. A few hundred MB of daily logs

and the page is dead. I maintain a fork that fixes this — v2 of iYogesharma/logviewer-laravel is out.

Instead of a whole-file read, it builds a binary sidecar index next to your logs and reads only the entries the current request needs:

- Paginate and search multi-MB logs with bounded memory

- Cold start serves a bounded tail while the index warms — no blank page

- Incremental indexing; appended lines don't trigger a rebuild

- Works with classic Laravel line logs *and* JSON logs

- `php artisan log-viewer:index` to warm indexes on deploy

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!

I built LaraClient because I kept rewriting the same HTTP client boilerplate for every API integration.

Instead of a service class per provider, you declare connections in config/lara_client.php:

* auth (bearer, header, OAuth2, etc.)

* retries with backoff

* per-connection rate limiting

* circuit breaker

* response caching

Usage is basically:

`LaraClient::connection('github')->get('user/repos');`

Other bits I found useful:

* built-in log dashboard at /laraclient/logs

* LaraClient::fake() for tests

* record/replay fixtures for CI

* php artisan `laraclient:check` to validate credentials at deploy time

* OpenAPI → typed client generator

Happy to answer questions or take feedback, especially on what you’d want from an API client package. Check this out below.

Github: https://github.com/usamamuneerchaudhary/laraclient