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

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

20 stories this week, so let's get into it. But first, This week's episode is brought to you by Tideways. Slow requests, and no clear reason why? Tideways helps you understand exactly where your PHP application spends its time — profiling, tracing, and monitoring to find and fix bottlenecks faster. And your profiling data stays hosted in Germany — GDPR-friendly by default. Learn more at tideways.com.

This week's top story: the season's first ballots are open — 2 sets of them — and the early counts are lopsided. Tim Düsterhus opened voting on the Time\Duration class on Friday with 2 ballots: a primary, needing a 2/3 majority, and a secondary choosing between full and abbreviated method names. As of recording, the primary stands at 23 to 1, and full names lead 18 to 1 — so multiplyBy and divideBy, not mul and divBy. Voting closes July 31. And remember Pierre Joye, who last week was leaning no over fromSeconds() and its capped nanoseconds argument? This week he closed the loop and voted yes, writing: "We were like ships passing in the night for some of my disagreements. The RFC wiki page did not show the additional constructor for other units, which hence the inconsistency I pointed out for the extra [nanoseconds] argument in fromSecond. They are here, and reduce this down to a lower level of bad APIs, more a pragmatic compromise conciliating different (if not numerous) use cases. Anything can be perfect, or shipped. Choose one." It turns out the per-unit constructors that resolved his objection had been in the RFC all along. His ballot almost didn't register, though — each vote on the wiki is a separate form, and Tim had to point out that you submit each one individually. The count now includes him.

Before the ballots opened, the Duration thread picked up a subplot about PHP 9. Holly Schilling — who wrote the class-extensions RFCs we covered last week — announced she's drafting a Value Structs proposal for after the 8.6 window, and argued that Duration would make a better struct than a class, with both ideally landing together in PHP 9. Ilija Tovilo replied by linking his own existing structs-v2 draft and asking whether she was aware of it. She was — she'd read it before drafting her own, and diverged from it on purpose, keeping mutating and non-mutating functionality separate. Tim saw no reason to wait on any of this, saying a draft-stage idea "will take an unknown duration to land - if it ever happens" — his pun, not mine — and that improvements to the standard library shouldn't queue behind it.

The week's other live vote came from Eric Norris, who opened balloting Thursday on minimum supported versions for PHP 8.6 — also with 2 questions, each needing a 2/3 vote. Requiring autoconf 2.71 for builds from git stands at 20 to 3 with 4 abstentions. Requiring COM_RESET_CONNECTION — which sets a floor of MySQL 5.7.3 or MariaDB 10.2.4, so persistent connections actually get reset — stands at 21 to nothing with 3 abstentions. Alexander Kurilo arrived after the discussion phase to ask for an opt-in instead, warning that on older databases persistent connections will silently turn non-persistent. Eric noted: "MySQL 5.7.3 is at least a decade old; it was released on December 3rd, 2013." After walking through every opt-out design he could think of, he concluded the right move is to make the correct behavior the default. The 3 no votes on autoconf include Jakub Zelenka, who's worried about building on Red Hat Enterprise Linux 8 and 9 — Tim offered to delay that particular merge to early 8.7. Both votes close July 30.

Saturday night, Pierre Joye opened the RFC that grew out of the libgd sync we covered last week: gd 2.4*. It's big — 3 pillars. First, syncing the bundled gd extension with upstream libgd: new codecs like QOI, JPEG XL, and UltraHDR, animated GIF and WebP support, multi-page TIFF, and real metadata handling. Second, an additive object-oriented Gd\ API — codecs with fromFile() and toStream(), immutable image info, streaming readers and writers. Third, a brand-new *2D vector canvas built on FreeType's rasterizer, with gradients and the full Cairo compositing set. He says the implementation is nearly done, including a security audit. He declared discussion open for 14 days, until August 1 — and that one sentence is where the trouble started.

Because August 1 plus a 14-day vote lands after the deadline. Release manager Matteo Beccati was gentle about it, writing: "As much as I like this RFC, I'm afraid it came in a little too late." Jakub Zelenka explained that nobody — release managers included — has the authority to grant an exception; that would take a change to the policy itself. And Rowan Tommins did the arithmetic: with alpha 1 out July 2, the cutoff for an RFC's final state was July 14, which is 4 days before this thread even opened. Pierre's frustration has a specific shape. The implementation was finished weeks ago — what delayed everything was that his pull request sat waiting on an approval that had been assigned to an automated bot reviewer, so no human was ever going to sign off, and he eventually merged it himself. He also argues the stakes are real, because PHP 9 is the one chance to change old defaults, and missing this window locks the current design in for years. The thread got tense over tone along the way — Pierre felt brushed off by a terse reply, and Rowan apologized outright, then made the counter-case that a fixed cutoff applied to everyone is fairer than debating each RFC's merits one at a time. All of this landed the same day Larry Garfield asked the list, in a separate thread, to hold new business until September 1 so reviewers can focus on 8.6's finish line. So gd 2.4 is alive and under discussion — just aimed at the next release, whatever its number turns out to be.

Caleb White's pipe assignment operator, |>=, had a crowded week. Larry Garfield opened it unable to find a compelling use case, and by Monday had moved to a no — pushed there, he says, by a competing proposal. That competing proposal is Vadim Dvorovenko's left-to-right assignment RFC, published Sunday, which claims the same |>= token with opposite semantics. Vadim objects on principle, arguing: "Attempting to transform such an operator from an immutable, functional construct into a mutable, imperative one steers the language in the wrong direction and undoes previous efforts." Caleb declined to merge the proposals, noting that F#, Elixir, OCaml, and Hack all kept ordinary assignment alongside their pipes. Larry also claimed none of the pipe proposals could make 8.6, and Tim Düsterhus corrected him, asserting: "This is false" — the last major change was July 13, so voting could open July 27 and close August 10, before the freeze. Meanwhile Bob Weinand asked whether the desugaring double-fires property hooks. Caleb came back with tests showing |>= behaves exactly like ??=, and updated the RFC's single-evaluation section to match. Vadim's own RFC, as of recording, has 0 replies.

Paul M. Jones's strict-namespace RFC — the piece he carved out of function autoloading last Tuesday night — spent its first full week in one long argument about a single word. Rowan Tommins objected first, writing that strict "implies some extra check that namespaces are [correct] in some way, which isn't really what this is about." Ilija Tovilo went deeper, arguing: "the value-add of this declaration is very small if the plan isn't ever to deprecate/remove the old behavior." Tim Düsterhus is in favor — with a rename to global_fallback=0. By Friday Paul had 4 candidate names on the table and a diagnosis: the pushback is the name, not the feature. Theodore Brown pointed out he'd floated the same directive in 2019; Paul added it to the prior art with an apology. And Benjamin Außenhofer suggested splitting the ballot — vote the concept, then vote the name. Rowan warned against it, writing: "a split vote leaves voters who actively dislike a particular name with an awkward choice: vote Yes, and risk the [bad] name being chosen; or vote No, even though you would support the feature under a different name." The rest of the autoloading corner kept moving too: Paul updated function autoloading mark 5 to lean on the new RFC and wants its vote open in about 2 weeks, and Michael Morris's improved-autoloading draft drew warm-but-firm feedback from Larry Garfield and Rowan Tommins — both like the namespace-setup-file idea, neither wants it crammed into the class autoloader's callback.

Nicolas Grekas didn't let Ilija Tovilo's "sadly not in favor" be the last word on serializable closures. His rebuttal: caching one attribute isn't the point — the point is skipping the entire metadata pipeline that frameworks re-run on every request, and that's the measured slow path. On the security design, he refused to loosen it, writing: "Name-based closure unserialization would ship a universal, app-independent gadget in the engine ... I won't commit to an RFC that turns every serialized payload into that kind of gadget, and I don't think we should, either." Then Saturday brought version 0.3, and a surgical cut — the reflection API is gone, the serialize() support stays. His reasoning: "serialize() is the one feature that most/all cache systems are built on, so that's the place that needs the improvement." Fresh reviews welcome.

Wendell Adriel came back to the list Thursday proposing typed array declarations — array<int, string> as real syntax, with 3 escalating enforcement levels. The review was fast and unsparing. Lazare Inepologlou flagged that you can't soundly subtype a mutable array without splitting reads from writes, and Wendell shipped a revised draft the next day. Rob Landers warned the whole thing overlaps the reified generics work, on hold until after the freeze, which is late August at the earliest. Rowan Tommins noted that level 1 — syntax without enforcement — rhymes with the bound-erased generics RFC the list just declined. Michał Marcin Brzuchalski even found a runtime hole, where functions like parse_str() that build results directly into a typed property can dodge the check. By Monday, Wendell put the RFC on hold himself. Larry Garfield's verdict was the sharpest, calling this "the already-dangerously-overloaded array mega-type" and asking for real typed list, set, and dictionary objects instead — which Wendell promptly volunteered to assist in building.

The frozen deprecations list for PHP 8.6 got its evidence file. Juliette Reinders Folmer scanned the Packagist Top 4-thousand — nearly four hundred fifty thousand files — and posted counts for every proposal. The headline being: list() appears over twelve thousand times, and Juliette wrote plainly: "Having said that, I'm definitely not in favour of deprecating list()." Compare spl_object_hash() at 625, is_integer() at 303, and a long tail of single and double digits — several proposals scored a clean 0. Kamil Tekiela discovered his mysqli proposal had missed the procedural mysqli_stmt_init(), patched the text, and worried aloud: "I hope this change is not going to reset the counter." Tim Düsterhus was quick to correct the record downward — one scary-looking count, on _ as a constant, collapses to 0 once false positives come out. And Monday, right on schedule, Gina P. Banyard confirmed the timetable, writing: "I intend to open the vote next Monday (the 27th of July) for 2 weeks so that the vote is finished on time for 8.6." Every deprecation gets voted in isolation — bring a lunch.

Quick hits. Go Kudo returned with a rebuilt cache proposal — a bundled user_cache extension, fully decoupled from OPcache this time; Larry Garfield likes it, flagged the lock story around remember(), and gently redirected it to 8.7 — adding: "Or 9, if that's what we call it." Holly Schilling's 4x fix for non-public asymmetric setters got its answer: no RFC needed — Tim confirmed a pure performance improvement just needs PR review, and Ilia Alshanetsky called it "definitely a strong candidate for PHP 8.6 inclusion." fennic pitched engine-native PSR-4 autoloading with spl_autoload_psr4_register(); Alex Rock wants classmap support before it can replace Composer's bootstrap, and Heinz Wiesinger pointed to his existing PECL extension doing much the same. Edmond of the TrueAsync project published a pre-RFC for an async scheduler engine interface — coroutine-aware core, no scheduler in core itself. His philosophical problem is that the RFC has no user-visible changes at all, and so far it has 0 replies. And Osama Aldemeery asked for RFC karma to formalize PREG_THROW_ON_ERROR — Ilija Tovilo granted it 2 minutes later.

Liam Hammett's markup expressions thread sprouted an alternative: Edmond proposed making the parser extensible instead, so JSX-like syntaxes could ship as extensions — Morgan liked that better than blessing one syntax, and within a day Edmond had a working DSL-hooks prototype, announcing: "Your wish has been granted. 🙂" Máté Kocsis and Ignace Nyamagana Butera kept refining query parameters — the open question is whether parsing limits belong on builder methods too, with Ignace arguing PHP shouldn't police what's really a business constraint. Prateek Bhujel's terminal-helpers extension hit 0.6.0 — it's now installable via PIE, and its output methods now write to standard PHP streams like STDOUT and STDERR instead of only its own built-in targets. The ballot queue grew by 2: Nick Sdot posted intent to vote on readonly property defaults for on or around July 23, and Khaled Alam's const-object-property-write opens Saturday the 25th — both aiming ahead of the freeze. Ben Ramsey amended the Working Groups RFC with a new section setting expectations for charter-RFC discussion. And release week: PHP 8.6.0alpha2, 8.5.9RC1, and 8.4.24RC1 all shipped — with alpha 3 and both GA releases converging on July 30 — while the release managers posted the countdown that framed half of this episode: soft feature freeze August 11, beta 1 August 13, every 8.6 vote closed before then.

So that's the week: 2 ballot boxes open and both lopsided — Duration cruising at 23 to 1, minimum versions right behind it; gd 2.4 arriving 4 days after the door closed and pointing at the next release instead; a pipe operator with 2 authors claiming 1 token; typed arrays proposed, revised, and shelved inside 5 days; and the deprecations list armed with its evidence file, ballots opening Monday — with readonly defaults and const-property-write queued right behind. 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.

Took me far too long to spot this the first time, because a cache hit is supposed to mean an empty query log.

    $posts = Cache::remember('posts:index', now()->addMinutes(15), fn () =>
        Post::latest()->take(20)->get()
    );

    foreach ($posts as $post) {
        echo $post->author->name; // one query. per post. on every hit.
    }

The cached payload is the models, not the relations. So every hit deserialises 20 models with no author loaded and lazy-loads it in the loop. In one sense it's worse than not caching at all: you've hidden the expensive query, kept the N+1, and made it harder to find. Debugbar now shows twenty small identical queries instead of the one big one you were hunting for.

The fix is boring. Eager load inside the closure so the relations are part of what you store:

    $posts = Cache::remember('posts:index', now()->addMinutes(15), fn () =>
        Post::with(['author', 'tags'])->latest()->take(20)->get()
    );

The habit I'd actually push though is not caching models at all. Cache the shape you render, a lean array or DTO. Cheaper to serialise, cheaper to deserialise, and it physically cannot lazy-load anything. Rehydrating a graph of Eloquent models out of Redis on every request eats a real chunk of the win you were chasing.

Has anyone found a decent way to enforce this? I've considered turning on preventLazyLoading() beyond local but it gets noisy fast.

(This came out of a longer caching write-up I did on my blog with tags, atomic locks and invalidation strategy: https://richdynamix.com/articles/laravel-caching-strategies-complete-guide)

About ten months ago I shared an alternative approach to Laravel route localization here. I originally built this for myself and wasn't really expecting a design discussion, but the feedback pushed me somewhere better than where I'd started.

https://github.com/goodcat-dev/laravel-l10n

TL;DR

• Route translations live in standard Laravel lang files (lang/{locale}/routes.php)
• Localized routes register at boot, so php artisan route:cache just works, no custom commands
• URL generation stays on the normal route() / action() helpers
• Three prefix strategies, plus translated domains
• L10n::is(), hreflang + switcher components, and Ziggy/Wayfinder helpers with SSR

Route translations now live in standard lang files

The original post used inline translations. Someone opened an issue asking for lang-file support, and I was actually against it at first. But it ended up being a clear improvement: it solved the mess of juggling inline translations across route groups, which had quietly become a nightmare.

Route::get('/example', Controller::class)
    ->name('example')
    ->lang(['es', 'it']);

// lang/es/routes.php

return [
    'example' => 'ejemplo',
];

It stays out of the way of the framework

This is the part I care about most. The localized routes are registered during boot, so Laravel's own route cache works with no custom commands:

php artisan route:cache

And URL generation goes through the normal helpers, there's no separate localized URL API to learn:

// current locale: es
route('example');                   // /es/ejemplo
route('example', ['lang' => 'it']); // /it/example
route('example', ['lang' => 'en']); // /example

Frontend URL generation (Ziggy & Wayfinder)

Localized routes usually break down once you generate URLs on the frontend. This is the one area I haven't seen other localization packages tackle, so the package ships JavaScript and TypeScript helpers that keep Ziggy's route() and Wayfinder calls locale-aware.

Matching routes across locales

A comment on the original post pointed out that routeIs() gets awkward once localized routes carry different internal names. That's now handled:

L10n::is('example');
L10n::is('admin.*');

It matches the canonical route regardless of the current localized variant.

Routing strategies

The package supports three:

• prefix_except_default: /example, /es/ejemplo
• prefix: /en/example, /es/ejemplo
• no_prefix: /example, /ejemplo

The prefix variant, which forces a prefix on the default locale too, came out of another issue.

Translated domains

Domains are translated through the same lang files:

return [
    'example.com' => 'es.example.com',
    'example' => 'ejemplo',
];

This produces es.example.com/ejemplo, without adding a redundant locale prefix to the path.

The package is still relatively young and intentionally opinionated. It requires PHP 8.2+ and Laravel 12.44 or 13.

One known trade-off worth calling out up front: lang is reserved as the locale-selection parameter, so routes with their own {lang} parameter aren't supported by the URL helpers.

Repository: https://github.com/goodcat-dev/laravel-l10n

composer require goodcat/laravel-l10n

That's the update. Any feedback is hugely appreciated, especially from anyone using translated domains, Ziggy, Wayfinder or SSR. Thanks!

HackerNoon scored LaraPlugins.io at 151 on their Proof of Usefulness algorithm. Here's the breakdown behind the score, and what it says about where the project is going.

Their algorithm judges projects across six dimensions: real world utility, audience reach, technical innovation, traction, market timing, and functional completeness. Each gets a weighted score. Then a usefulness multiplier kicks in. Here's how LaraPlugins broke down

100+ plugins and packages for the laravel ecosystem are already using the Laravel AI SDK, in their projects including repos of more than 20k stars.

I've been looking into alternatives for the server management panel I currently use (Ploi), and I am wondering how people that have been using Forge (or used to use it) are finding it nowadays? And if you moved to Forge from Ploi/RunCloud/etc. how does it compare? And if you were using Forge but moved away, why, and to where?

For reference, I have 5 servers, and 28 applications deployed on those combined. I will not be using the Laravel VPS'.

Specifically, how is the Forge experience outside of Laravel deployments and the usage of "Laravel VPS"? While most of my applications are using Laravel, a growing amount are using Next.js or SvelteKit.

Sharing because the community here helped me a lot. The whole thing (validation engine, multi-tenant dashboard, queue workers on Horizon) is Laravel + Filament. The dashboard I'd have spent a month on took a few days with Filament.

One thing I learned building it that might interest you: catch-all domains are the bane of email validation because the server says "yes" to every address. But for Microsoft 365 tenants you can hit their GetCredentialType endpoint and it'll actually tell you if a specific mailbox exists, over plain HTTPS, no SMTP. That converted a big chunk of our "unknown" results into real answers.

I also published a Laravel package (`bounceshift/laravel`) with a `Deliverable` validation rule and a facade. It fails open by design, so if our API is down or you're out of credits, it never blocks your flow.

https://bounceshift.com

https://github.com/bounceshift/laravel

Happy to talk through any of the Laravel/Filament decisions.

I built Laravel Tackle as an AI agent harness that runs inside your Laravel app. It gives you agents that can read your codebase, make edits, run tests, review changes, and even fix things on their own. There's ai:code for interactive coding sessions, ai:fix where you can paste an exception or link an issue for it to handle, and a self-healer that automatically catches failed queue jobs or scheduled tasks.

It's built on top of the official Laravel AI SDK so it works with a bunch of providers, and it includes safety features like path guards, budget limits, worktree mode, and approval prompts. Installation is simple with Composer.

Thought I'd post about it here. I've made and published a settings & feature fags package.

Yes I know Laravel has Pennant and Spatie has Laravel Settings. However, for what I wanted and needed in a couple of projects neither really fit what I was looking for.

I looked at other SaaS solutions like LaunchDarkly and ConfigCat and thought "I can replicate that with an OSS package." So that's what I set out to do. The initial implementation had a smaller scope was and done by hand, and then after that I brought in Claude to build out other features and refine what I had done.

Some things it comes with:

• Rule-based targeting to target users by attributes, segments, geography, device, or time (things like geolocation require external services).
• Percentage rollouts for gradual releases with consistent user bucketing
• Integration Laravel Pennant so if you're using Pennant and want to integrate this, you can have Pennant resolve to the DB
• Integrations with Laravel Telescope
• Integration with Spatie Permissions
• Highly extensible, create your own value types and drivers to add support for more things or other packages
• A lot more, but it's all covered in the docs

Since every project has its own needs, configuration and extensibility was an upfront must-have. I tried to have a sensible out of the box setup, but if something doesn't work for you, you can swap it out.

It doesn't currently ship with any interfaces or endpoints. I plan to add endpoints and Blade, Vue, React, Svelte support in the future, but I thought I'd get it out there for people to look at and provide feedback.

I've looked through the docs, making sure the steps were accurate, but if there's any gaps or something is wrong, let me know :)

I hope some of you will find it useful, I've been using it in a couple of projects 😄

GitHub: https://github.com/GaiaTools/fulcrum-settings

Docs: https://gaiatools.com/docs/fulcrum-settings/v1

Packagist: https://packagist.org/packages/gaiatools/fulcrum-settings

This complete guide covers setup, broadcasting, private channels, typing indicators, presence, and production-ready chat without third-party services.

https://richdynamix.com/articles/livewire-4-real-time-chat-reverb-complete-guide

I have an existing Laravel project and want to explore adding new features to it using AI. I have been using AI until now, where I would copy files of my code into the chat, e.g. Claude, and ask it to create/add features, but it's time consuming and I feel like there's much better/faster ways of doing it today.

What are the best ways currently of doing this, without it messing up my existing work?

I'm a reasonably happy user of Herd and sometimes debate upgrading to herd pro.

However with Lerd and Yerd, which seem to offer everything Herd Pro does, but free, I wondered if anyone has any input or has used either in anger?

https://lerd.sh/
https://yerd.app/

While PHP Internals is not technically directly related to Laravel, internals does affect us all.

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

This week's episode is brought to you by Tideways. Something in production is slow — and you can't see where. Tideways takes PHP developers from slow request to root cause in minutes, with profiling, tracing, and monitoring built specifically for PHP. 5-minute install, no credit card. Start your free trial at tideways.com.

This week's top story is a brand-new keyword knocking on the door: extension. One week after Larry Garfield floated Kotlin-style extension functions at the scalar-methods RFC, Holly Schilling arrived with working prototypes of Swift-style class extensions — born, she says, out of a Discord conversation — and it became the biggest thread of the week at 26 messages. The idea: add methods to a class you don't own — extension \DateTimeImmutable gives every date an isWeekend() — and, in a later phase, put methods on scalars, so "hello" gets a length(). She published 3 draft RFCs as gists, implementation included. Michael Morris asked the obvious first question, writing: "Looking at Swift's extension syntax I fail to see anything it adds not covered by the above." — the above being inheritance and traits. Holly drew the line clean: "An extension is essentially the reverse of a trait." With a trait, the author of the class decides; with an extension, the user of the class decides.

Then came the twist. 2 days in, Holly sat down to defend her own scalar-methods implementation — and couldn't. She wrote: "Typing this email this morning gave me real hesitation. If I can’t support my own implementation, no one else should either. I immediately set out to build a better version that I could put my full weight behind." The better version came from an unexpected place: C# 14, whose new extension syntax puts the receiver right in the declaration — extension string $str — no autoboxing, no downcast headaches. She rewrote all 3 drafts and the implementation around it in a day. Not everything got absorbed so gracefully: when Alex Rock proposed an explicit extend ... with ... wiring statement, Holly apologized in advance for the bluntness, then answered: "I reject this functionality." — extensions stay file-scoped, and they never override a real method. And Pierre Joye flagged a process problem: proposals keep citing Discord conversations as their origin, while he reads only internals and GitHub — and found no reference to a php.net Discord anywhere he searched.

Gina P. Banyard's Deprecations for PHP 8.6 — the annual bundle that spent June on fire — reached its quiet milestone: the list is locked. Gina declared the RFC "frozen", with only minor amendments still allowed, and put dates on everything: "I will initiate a call to vote next week on Monday (the 20th) for the following Monday (the 27th) so that the vote is done by the 10th of August." Because items were still being added in the final week, the policy's 2-week discussion clock is what sets that gap — and the timing is deliberate, so accepted proposals can land in 8.6.0 beta 1. The week's lightest subplot: Garrett W. wants the deprecation notices themselves copy-edited — those commas are comma splices, and he'd use semicolons. Tim Düsterhus explained the house style comes from PHP error messages, and added: "The deprecation messages can still change during PR review (or even later), there is explicitly no BC guarantees for those."

Paul M. Jones's function autoloading — attempt number 5 — got smaller this week, on purpose. The declare(strict_namespace=1) directive he added last week drew a structural objection from Tim Düsterhus, who argued: "I believe the strict_namespace=1 directive is a sufficiently unrelated concern - with enormous bikeshedding potential on its own, but also sufficient usefulness on its own - such that I feel it should be its own RFC that is a prerequisite to this one. It should not be piggy-backed onto function autoloading." Paul didn't fight it. He replied: "I'm good with that. I'll prepare a separate RFC and remove that from the function-autoloading one." — and by Tuesday night it existed: strict-namespace is now its own RFC on the wiki, and mark 5 will reference it instead of carrying it. Tim also showed his cards: he built the inverse directive as an experiment a year ago, and he's firmly on team fully-qualify-everything.

Tim Düsterhus and Derick Rethans' Time\Duration class is days from the ballot box — and it picked up its first declared no. Pierre Joye spent the week pressing on fromSeconds() and its capped nanoseconds argument, and landed here: "I like that RFC, but it adds confusions and limitations from what is supposed to be a simple first step. As it stands now, despite the fact that I would love to see it, I tend towards a no." Tim's defense reached for the stopwatch — it's natural, he argued, to say Usain Bolt broke the 100 m world record with "9 seconds 58 hundreths" — exactly the fixed-point form fromSeconds() uses. Pierre countered: "It is just as common in the real world to have duration information in one unit only and decimal. F.e. 234.54ms. or 3.4 hours, etc." Neither moved — and per Tim, that's fine: "All discussions have been resolved (some of them with an “agree to disagree”), so we plan to open voting at the end of this or early next week." The 14-day cooldown runs out Friday evening, European time.

A first-time author had a very good week. Caleb White got RFC karma from Ilija Tovilo, and his first proposal — the pipe assignment operator, |>= — went through review polish at speed. The idea: $x |>= trim(...) pipes $x through and puts the result back, just like every other modify-assign operator. Tim Düsterhus liked the shape, saying: "Conceptionally I like the idea of having an “in-place modification operator” for function calls and the semantics of the operator seem to be consistent with the existing “modify-assign” operators we have, particularly also with regard to operand order. Nice idea!" Tim also caught a precedence claim that was almost right — assignment operators are not the lowest; the infamous or die() pattern depends on it — and Caleb fixed the RFC the same day, both times. The list's real energy went to naming. Ben Ramsey offered: "I like to think of |> as the volcano operator, while |>= is the erupting volcano operator."

Then last night — hours before we hit record — Liam Hammett published Native Markup Expressions: JSX-style markup as first-class PHP expressions. Write a <button> tag straight into an expression, and it compiles to new \Markup\Element(...) — escaped by default, with capitalized tags becoming components. Liam headed off the obvious reading, writing: "Despite appearances, this is not a template language grafted onto the engine - the syntax is pure compile-time sugar." First reviewer Garrett W. questioned that capitalization heuristic — PSR-4 isn't binding, and lowercase class names are legal. Liam pushed back: "Fallback resolution turns typos into silent bugs. With the capitalisation rule, <Layuot /> fails loudly with a class-not-found error. With fallback resolution, it silently renders as a literal <Layuot> element and you find out in the browser, if you find out at all." This is the ambitious RFC Liam requested wiki karma for on July 10 — Ilija Tovilo granted it Monday: "RFC karma was granted. Good luck!"

Marc Henderkes wants to end PHP's double life. His pre-RFC: make ZTS — the thread-safe build — the default, deprecate the rest, and drop NTS entirely in PHP 9. He summed it up himself: "Tl;dr: nobody wants to maintain two builds and even having a necessary split is making things hard." Distros package only NTS, FrankenPHP needs ZTS, and php-src carries roughly 420 ZTS ifdefs. The performance tax is dissolving too — his numbers: "Worst case performance cost of ZTS in php 8.5 was ~5%, will be ~1.5% in php 8.6, likely ~0.5% after my last open PRs." To be clear, he is not proposing to deprecate FPM — a single-threaded ZTS run keeps everything NTS does today. 2 of the named blockers — the arm64 macOS JIT and the fuzzer SAPI — were fixed within 2 days of the thread opening; the third, NewRelic's missing ZTS support, isn't Marc's to fix. Benjamin Eberlei backed the initiative, Calvin Buckley volunteered his own PHP distribution as a test subject, and Marc has requested wiki karma to write the full RFC.

Nicolas Grekas's serializable closures spent the week absorbing a deep review from Tim Düsterhus — and then ran into a wall. Tim was candid: "While reading the RFC initially and now the updated version, I got the feeling that it was “overfitted” to solve the specific use case and deployment scenario that you consider a “best practice”, which I feel results in “weird” behavior when one leaves that happy path." Still, the 2 converged on real changes: Nicolas adopted Tim's tagged-union serialization format, and — after an off-list suggestion from Arnaud — replaced the fragile line-number check with a compile-time hash of the closure body, so a shifted use import can't silently break payloads. Then Tuesday night, Ilija Tovilo weighed in against — questioning whether attributes need caching at all, and finding the format and implementation too complex. He closed with: "Overall, I'm sadly not in favor of this RFC."

No ballot box was open this week — instead, the queue got dates. Eric Norris's minimum supported versions opens voting tomorrow, July 16 — the earliest the policy allows. Duration clears its cooldown Friday evening and opens late this week or early next. The deprecations list calls its vote Monday the 20th, with ballots open the 27th. And Khaled Alam's const-object-property-write RFC is cleared to open July 25 — no later than the 28th to make 8.6. All of it backs into the release managers' reminder from Monday. Matteo Beccati wrote: "Any RFC intended for inclusion in PHP 8.6 must have its discussion concluded and its voting closed before August 13." Soft feature freeze: August 11. Beta 1: August 13.

Quick hits, round 1. Máté Kocsis revived his query parameters RFC with a simplification: he's cutting the array API down to 2 — maybe 3 — methods, fromArray() and toArray() with withArray() on the bubble, plus an options class with security limits on parsing; League-of-URI maintainer Ignace Nyamagana Butera answered with naming notes and an enum for null handling. Nick Sdot's readonly-property defaults — zero replies when we covered it last week — got its replies: Tim Düsterhus found an unserialization wrinkle, Nick fixed it the same day, Larry Garfield is skeptical, and Tim plans to abstain. Holly Schilling — the same Holly Schilling from our top story — found that non-public asymmetric setters run roughly 4x slower than public ones, posted a fix, and then a formal RFC for it — with Ilija Tovilo reviewing the PR, she's giving the list a few days to weigh in on 8.6 versus waiting; Marc Henderkes and Calvin Buckley both questioned whether an internal change needs an RFC at all. And Osama Aldemeery's PREG_THROW_ON_ERROR settled its naming on Tim's suggestion: an unnamespaced PregException.

Round 2. Sjoerd Langkemper showed that newlines in CURLOPT_HTTPHEADER values inject extra headers — even over HTTP/2 — and opened a fix; upstream curl is adding its own check, and curl's own Daniel Stenberg confirmed CRLF is disallowed. Xavier Leune bumped his curl socket-callbacks PR — pitching it as the missing tool against SSRF to localhost — and is still waiting on a reply. The bundled-GD sync to libgd 2.4 drew its first pushback: Giovanni Giacobbi says the upstream code is too young and 8.6 too far along, while Pierre Joye, Jakub Zelenka, and Ilia Alshanetsky want it landed before beta 1 — Jakub's condition being that the security-review findings get addressed first — and Kamil Tekiela says wait for the next version. And the DTLS experiment in the openssl extension became a real draft PR; Jakub Zelenka confirmed the direction and is already sketching the generalization it needs.

So that's the week: a brand-new extension keyword that rewrote itself mid-thread; a frozen deprecations list with ballots set for the 27th; function autoloading shedding a prerequisite RFC; a Duration vote opening within days, carrying its first declared no; and a JSX-flavored surprise landing the night before we filmed. Nothing was voted on this week — and the ballot queue starts moving tomorrow. 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.

Been building Laravel apps for years and got tired of having to configure

database connections manually for local Valet projects.

Built Stratum — a native macOS database GUI that auto-detects your Valet

MySQL socket. Just open it and your local databases are there, no setup needed.

Also does PostgreSQL and SQLite with no extra config. Visual table browser,

schema designer, query editor with autocomplete, iCloud sync.

Free during beta: https://stratum.mwn-digital.uk

Curious if anyone else has been annoyed by the same thing with their local

dev setup.

Every ecosystem but Laravel had runtime pseudolocalization — Symfony ships it in core, Rails has Shopify's gem, i18next has a plugin. So I built it.

Turn it on and every string that goes through __() / trans() renders accented and expanded (Account Settings → [!! Àççôûñţ Šéţţîñĝš ôñé ţŵô !!]). Two things fall out of that:

• The spotlight: anything not wrapped in __() stays plain English and screams "I'm hardcoded." Finding those is normally a grep-and-guess chore.
• The expansion (~35%): surfaces every layout that breaks when real translations (German, Finnish) run longer than English.

The part I'm happiest with: there are no generated files. You don't create a pseudo locale or run a generator - it decorates Laravel's translator binding at runtime. Set PSEUDOLOC_ENABLED=true (or flip a cookie on staging for a two-tab demo) and it just works. Flip it off and you're exactly where you started.

It's a dev/QA tool: hard no-op in production, force-disabled in tests, and it's careful about the three things a naive version breaks - validation message detection, plural (trans_choice) selection, and Lang::has(). All covered by tests.

• GitHub: https://github.com/bretterer/laravel-pseudoloc
• composer require bretterer/laravel-pseudoloc --dev
• Laravel 12 & 13, PHP 8.2+

It's v0.1.0 — would genuinely love feedback on the transform (accent map, expansion style) and any translator edge cases I haven't hit.

I just shipped a facade for the Neuron AI Laravel SDK that lets you call a configured agent straight from a controller or a job, chat, stream, or get typed structured output, without writing an agent class first. It even speaks AG-UI protocol out of the box if your frontend expects real event streaming instead of raw text chunks.

Curious what this sub actually thinks: is PHP a legitimate place to build agentic systems in production, or is that still a Python-only conversation in your eyes? Repo's here if you want to see the code before you answer: https://github.com/neuron-core/neuron-laravel

Hey Laravel community!

Scramble 0.13.34 is out with a few improvements that should make API docs easier to keep accurate:

- caching for generated OpenAPI documents;

- Scalar as an alternative docs UI;

- support for plain PHP objects in response schemas;

- automatic OpenAPI authentication documentation from route middleware;

- and much more!

It's open source, and the full release post is here: https://scramble.dedoc.co/blog/scrambledrop-scramble-01334

Would love to hear what would make your Laravel API documentation workflow smoother 🙌

Learn the Expand → Migrate → Contract pattern to deploy database schema changes safely without downtime.

https://richdynamix.com/articles/laravel-zero-downtime-migrations-expand-contract

tl;dr: SuperNative makes NativePHP for Mobile fully native, driving native views in SwiftUI and Jetpack Compose, exposing blistering performance.

In beta now.

Learn Eloquent, Gamified

as per the title - went to download videos and they have disabled it - cant see download video anymore.

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've been experimenting with AI features in a Laravel 13 e-commerce application, and one feature that has worked well is automatically generating product content and SEO metadata using the OpenAI API.

Instead of manually writing content for every product, a single API request generates:

• Product Description
• Short Product Description
• SEO Meta Title
• SEO Meta Description
• SEO Meta Keywords

Basic configuration:

OPENAI_API_KEY=your_openai_api_key
OPENAI_MODEL=gpt-4.1-mini

// config/services.php

'openai' => [
    'key' => env('OPENAI_API_KEY'),
],

Example request using Laravel's HTTP Client:

$response = Http::withToken(
    config('services.openai.key')
)->post(
    'https://api.openai.com/v1/chat/completions',
    [
        'model' => env('OPENAI_MODEL'),
        'messages' => [
            [
                'role' => 'system',
                'content' => 'You are an expert e-commerce SEO content writer.'
            ],
            [
                'role' => 'user',
                'content' => 'Generate SEO metadata and product descriptions for iPhone 16 Pro Max.'
            ]
        ]
    ]
);

One optimization that noticeably reduced both latency and cost was generating all required content in a single request instead of making separate API calls for each field. Besides reducing token usage, it also keeps the generated content more consistent across the product page.

I'm interested in how other Laravel developers are approaching AI integration.

• Are you using OpenAI, Anthropic, Gemini, or another provider?
• Do you generate structured JSON responses or plain text?
• Have you implemented caching, background queues, or other optimizations to reduce API costs?

I'd love to hear what approaches have worked well in production.