Php

PHP 8.5 shipped November 20th. Two features define this release: the pipe operator and the URI extension. They solve different problems, but both share the same motivation: making common operations less awkward to express. The pipe operator Functional pipelines in PHP have always been a mess. Chaining transformations meant either nesting function calls inside out, or breaking them into intermediate variables: // before — read right to left $result = array_sum(array_map('strlen', array_filter($strings, 'strlen'))); // or verbose but readable $filtered = array_filter($strings, 'strlen'); $lengths = array_map('strlen', $filtered); $result = array_sum($lengths); // after — read left to right $result = $strings |> array_filter(?, 'strlen') |> array_map('strlen', ?) |> array_sum(?); The |> operator passes the left-hand value into the right-hand expression. The ? placeholder marks where it goes. Pipelines now read in the order operations happen: left to right, top to bottom. ...

API Platform 4.2 arrived in September 2025. Three changes stand out: a JSON streamer for large collections that avoids buffering the entire response in memory, an ObjectMapper that replaces the manual wiring in stateOptions-based DTO flows, and autoconfiguration of #[ApiResource] without explicit service registration. JSON streamer for large collections The default Symfony serializer builds the full response in memory before writing it to the output. For a collection of 10,000 items, this means allocating a PHP array, serializing it to a string, and keeping both in memory until the response is flushed. At scale, this is the source of the OOM errors that force people to add pagination everywhere. ...

API Platform 4.1 arrived in February 2025 with a batch of features that are less about new capabilities and more about making the existing ones production-ready. Strict query param validation gets a first-class property. OpenAPI gains a mechanism for splitting large APIs into separate specs. GraphQL gets the abuse prevention controls it was missing. Strict query parameter validation 3.3 introduced query parameter validation as opt-in. 3.4 deprecated the loose behavior. 4.1 formalizes it with a native strictQueryParameterValidation property on resources and operations: when set to true, unknown query parameters return 400. ...

The search box on the media library returned results in 800 milliseconds on staging. Production had forty times more rows. The query plan showed a sequential scan: no index involved, no way to fix it with a standard B-tree. The product team also wanted multi-word search: type “interview president”, get results containing both words. A LIKE query with wildcards has no clean way to express that without multiple independent conditions, each requiring its own scan. ...

PHP 8.4 released November 21st. Property hooks are the feature. Everything else, and there’s quite a bit of it, is secondary. Property hooks For twenty years, if you wanted behavior on property access in PHP you had to write getters and setters: class User { private string $_name; public function getName(): string { return $this->_name; } public function setName(string $name): void { $this->_name = strtoupper($name); } } PHP 8.4 adds hooks directly on the property: class User { public string $name { set(string $name) { $this->name = strtoupper($name); } } } You can define get and set hooks independently. A property with only a get hook is computed on access: ...

API Platform 4.0 shipped nine days after 3.4, in late September 2024. The version number is honest: there is no new architecture, and the migration from 3.4 is short if you resolved the deprecations. What makes this a major is the scope change — API Platform is no longer a Symfony-only framework — and one opinionated default that reverses six years of PUT behavior. Laravel as a first-class target Since its first release, API Platform was built on Symfony. The HTTP layer, metadata, serializer, and Doctrine bridge all assumed Symfony’s container, event dispatcher, and request lifecycle. Laravel users could run API Platform through a thin adapter, but filters, security, and Doctrine integration did not work on Eloquent. ...

API Platform 3.4 landed in September 2024 as the last minor before the 4.0 jump. The headline feature is BackedEnum as full resources — not just a typed field, but an enum that is itself an API endpoint. BackedEnum as API resources Since PHP 8.1, BackedEnum classes have a fixed set of cases with string or integer backing values. API Platform 3.4 lets you put #[ApiResource] directly on a BackedEnum: ...

API Platform 3.3 shipped in April 2024 with a set of targeted additions. None of them reshape the architecture — 3.2 already closed that chapter. What 3.3 adds is control over things that were previously either hardcoded or required a workaround: response headers, link visibility on sub-resources, and webhooks in the generated spec. Declarative header configuration Before 3.3, setting custom response headers required either a custom processor that modified the response object or a Symfony event listener on kernel.response. Both approaches worked but lived outside the resource definition. ...

PHP 8.3 landed November 23rd. Quiet release by PHP standards: no enum-sized shift, no JIT. What it does have is a focused set of improvements that close long-standing gaps in the type system and add functions that should have existed years ago. Typed class constants Class constants have been untyped since their introduction. PHP 8.3 fixes that: interface HasVersion { const string VERSION; } class App implements HasVersion { const string VERSION = '1.0.0'; } Without typed constants, an interface constant could be overridden with a completely different type in an implementing class and nothing would complain. Typed constants close that gap, and on interface-driven codebases the impact is immediate. ...

API Platform 3.2 arrived in October 2023 with three changes that pushed the state model further: errors became resources, sub-resources came back in a form that actually fits the architecture, and the last legacy extension point — event listeners — was formally replaced. Errors as resources Before 3.2, error handling was outside the resource model. Exceptions were caught by a Symfony event listener and converted to a response, with limited control over the shape of the output. ...