PHP 8.6: what is real vs rumor this week

PHP 8.6: what is real vs rumor this week

PHP 8.6.0beta3 tagged 10 Sep 2026. GA is still scheduled 19 Nov. I would not put beta FPM on a VPS. I would run the official CLI container, try clamp() and ? placeholders, and leave Laravel 13 on 8.5.

· Updated · 8 min read #php #php-8-6 #rfc #laravel

 Locked PHP 8.6.0beta3 features versus rumor this week

Partial function application, clamp(), and the new session defaults are in the beta. Primary constructors, PREG_THROW_ON_ERROR, and “GA already shipped” are not yet coming. Calendar from php in 8.6. You can track the release timetable from wiki.php.net and php.watch

I did not put PHP 8.6 on a production FPM socket. 8.6.0beta3 tagged 10 September 2026. That is a QA tag, not general availability. The PHP wiki 8.6 timetable (retrieved 11 Sep 2026; same GA date as php.watch’s 8.6 releases index) still has GA on 19 November 2026. Hard freeze is 22 September. RC1 is 24 September. This week I would run a throwaway CLI and write down what is locked versus what Twitter still treats as shipped.

This is a lab note. I did not rebuild a client cluster tonight. The failure shapes below are the ones a beta is famous for: 8.6 syntax on an 8.5 binary, and an Ubuntu box whose apt PHP 8.6 packages are not the tag you think they are.

What changed

php.watch’s 8.6.0beta3 page dates the tag 10 Sep 2026. The 8.6 releases index repeats the same warning the QA tarball has always had: do not run this in production; first GA is scheduled 2026-11-19. Beta 3 did not slip. If you are still quoting last week’s “beta2 is current, beta3 is Thursday,” update the sentence.

What I will treat as locked in this beta (soft freeze was Beta 1 on 13 Aug 2026; these RFCs were already in):

What I will treat as rumor if someone pastes it into a Slack “8.6 dropped” thread:

  • GA. Still 19 Nov 2026 on the wiki timetable. Not this week.
  • Primary constructors. wiki.php.net/rfc/primary-constructors says “Next PHP 8.x.” Soft freeze for 8.6 was 13 Aug 2026. This did not land in beta3.
  • PREG_THROW_ON_ERROR. Separate queue item. Voting targets 8.7, not 8.6. Do not write that constant into an 8.6 scratch file and call it a feature.
  • Function composition / JSX-style markup. The Foundation PFA post itself says function composition “still needs some work before it can be formally proposed.” That is not a beta3 bullet.

Laravel’s side of the floor, from the current docs, has not moved for 8.6:

Framework PHP floor I can cite Notes
Laravel 13 8.3–8.5 Released 17 Mar 2026. laravel.com/docs/13.x/releases.
Laravel 12 8.2–8.5 Bug fixes ended 13 Aug 2026. Security until 24 Feb 2027.

laravel/framework#61219 (“Test on PHP 8.6”) is still a draft as of 26 Aug 2026, and the author left it blocked on a nette/schema PR until at least RC1. I would not invent “Laravel 13 supports 8.6.”

What I would change in a real Laravel/PHP app this week

Three edits. None of them is “bump platform.php to 8.6” on the production lock.

1. Run the beta in a throwaway CLI. Leave FPM on 8.5.

php.watch documents the official images on the beta3 page. That is the lab, not apt install php8.6-fpm on the box that serves the app:

# Host stays on whatever FPM Nginx already uses (8.5.x on my VPS notes).
php -v

# Throwaway. QA tag, not a distro package.
docker pull php:8.6.0beta3-cli
docker run --rm -v "$PWD":/app -w /app php:8.6.0beta3-cli php -v

If that php -v on the host still prints 8.5, good. The container is the only place I would paste the snippets below.

2. Replace max($min, min($max, $v)) in a scratch file. Do not ship it to app/ yet.

The RFC’s own examples are the right size. Named arguments keep min / max from swapping in my head:

$qty = (int) $request->input('qty', 0);

// Before — 8.5. Easy to invert min/max. No ValueError if you do.
$qty = max(0, min(99, $qty));

// After — 8.6 beta CLI only. Inclusive. Throws if min > max.
$qty = clamp($qty, min: 0, max: 99);

I would rg 'function clamp\(' app/ helpers/ on the Laravel app first. The clamp RFC is explicit: a userland clamp() in the global namespace will collide. That is a fatal, not a deprecation.

3. Use PFA on a pipe. Leave Eloquent alone.

PHP 8.5 already gave me |>. The 8.6 piece is that I no longer wrap every extra argument in (fn (string $s): string => …):

$title = ' PHP 8.6 Beta 3 ';

// Before — valid on 8.5. Arrow functions in a pipe still need parentheses.
$slug = $title
    |> trim(...)
    |> (fn (string $str): string => str_replace(' ', '-', $str))
    |> strtolower(...);

// After — 8.6. `?` is the open argument. Same idea as the Foundation post.
$slug = $title
    |> trim(...)
    |> str_replace(' ', '-', ?)
    |> strtolower(...);

Run that file with the 8.5 binary on purpose once. The error I would get is the one this week is famous for:

PHP Parse error:  syntax error, unexpected token "?" in /tmp/pfa.php on line 8

That is how I would confirm I did not accidentally point Artisan at the container while Nginx still talks to 8.5 — or the other way around.

I would not rewrite User::query(). Collections already chain. PFA is for turning a multi-arg function into a unary callback.

What would bite on a self-hosted VPS

Ubuntu 24.04 LTS still ships PHP 8.3 from distro packages. 8.5 on that box is ppa:ondrej/php. 8.6 is not “the next apt install.” When I listed packages.sury.org’s php8.6 pool on 11 Sep 2026, the filenames I could see were still 8.6.0~alpha1 dated 6 Jul 2026. Codeberg issue #136 (opened 17 Aug 2026) asked Ondřej for beta/RC packages; I did not treat that ticket as a shipped beta3 repo. If apt-cache policy php8.6-cli on a VPS prints alpha1, that is not the tag from Thursday.

 Throwaway PHP 8.6 CLI versus production FPM

Caption: docker run php:8.6.0beta3-cli is the lab. Pointing Nginx at a php8.6-fpm.sock — or pasting ? placeholders into the 8.5 pool — is how I would take the site down.

Second bite: session INI vs Laravel cookies. The session RFC’s own comparison table already lists Laravel as HttpOnly on / SameSite Lax. Illuminate session cookies are not the same object as a raw session_start(). The compiled defaults change for new PHP. An old php.ini copied onto the box keeps the old values. php -n -i in the beta container is the way I would see the new defaults:

docker run --rm php:8.6.0beta3-cli php -n -r \
  'foreach (["session.use_strict_mode","session.cookie_httponly","session.cookie_samesite"] as $k) { echo $k, "=", ini_get($k), PHP_EOL; }'

What would actually break in production later: a CodeCanyon leftover that calls session_start(), a SAML SSO that needed the session cookie on a cross-site POST (SameSite=None; Secure has to be explicit), or a custom save handler that never implemented validateId() once use_strict_mode is on. I would grep session_start( and mb_ereg now, while I still have months before GA. mbregex is on the 8.6 deprecation list via the Oniguruma EOL RFC (wiki.php.net/rfc/eol-oniguruma).

Third bite: Composer platform. After I am done playing, config.platform.php stays on the FPM I actually serve — 8.5.x, not 8.6.0beta3. CI that resolves against 8.6 will pull packages the VPS cannot run.

Shared hosting: if the panel cannot give me a second CLI, I do not “upgrade PHP” in the control panel to a beta. I wait for GA, or I use Docker on a machine I can throw away.

The calendar, not the rumor mill

 PHP 8.6 release path from Alpha 1 to scheduled GA

Caption: Wiki timetable retrieved 11 Sep 2026. Beta 3 tagged 10 Sep. Hard freeze 22 Sep. RC1 24 Sep. GA still 19 Nov 2026. That last date is a schedule, not a tag I can install.

What is running in my head as the honest target this week: Laravel 13 + PHP 8.5 FPM on Ubuntu 24.04, Nginx still on /run/php/php8.5-fpm.sock, and a Docker CLI on 8.6.0beta3 for clamp() / PFA scratch files. Next calendar check is 22 Sep (hard freeze) and 24 Sep (RC1). I would not write “we are on 8.6” until GA exists and Laravel’s release matrix says so.

Are you on this in production?

If FPM still runs 8.5, composer.json still constrains <8.6, and the only 8.6 binary you have is a container you can docker rm, you are on this the way I mean it — lab only. If Nginx already talks to a php8.6-fpm.sock, or apt installed 8.6.0~alpha1 because the package name looked current, you are not. Shared hosting that will not give you a second CLI is the third camp. I did not flip a production pool tonight; I want to know which of those three you are in.

Did you hit the same wall?

I would get stuck on syntax error, unexpected token "?" because I ran a PFA scratch file with the host 8.5 binary, or on sury php8.6 still being alpha1. Did you hit the same thing, or a different one — a userland function clamp(), session cookies on a cross-site POST, mb_ereg deprecations, a host that will not give you Docker? Tell me in the comments. I read them.

References

Share:

Get new posts in your inbox

No spam. One short email per new article — practical PHP, Laravel, devops, and AI-assisted workflows.

Comments

Powered by GitHub Discussions via Giscus. A free GitHub account is required.