Development

Revision pruning with window functions and logarithms, when DQL wasn't enough

Every content update on the platform creates a revision. That’s by design: editors need a history they can roll back to, and the platform needs an audit trail. What nobody anticipated was the rate. Some articles go through forty saves in a single afternoon. A high-traffic piece accumulates hundreds of revisions over its lifetime. After a few months, the revision table had several million rows. Deleting them naively wasn’t an option. “Keep the last 50” loses all historical context for articles that haven’t been touched in a year. “Keep one per day” loses all the detail for content that’s actively being edited. What we needed was a distribution that matched how revisions are actually used: dense coverage for recent history, sparse coverage for old history. ...

PHP 7.4: typed properties and the arrow function you actually want

PHP 7.4 landed November 28th. It’s the last 7.x release before PHP 8.0, and it feels like it. The features are substantial enough to stand on their own, but they also read as groundwork for what’s coming. Typed properties This is the one. Since PHP 7.0, you could type function parameters and return values. But class properties? Still untyped: class User { public int $id; public string $name; public ?DateTimeInterface $deletedAt; } 7.4 changes that. Typed properties enforce types at assignment, not just at call sites. Classes become self-documenting in a way that docblocks never quite managed, and the engine catches type errors before they propagate through half your stack. ...

Symfony 5.0: String, Notifier, and the secrets vault

Symfony 5.0 released November 21, 2019, same day as 4.4. Where 4.4 is about stability and a long support window, 5.0 is the next chapter: no deprecated code, PHP 7.2.5 minimum, and a handful of new components that finally address gaps that had piled up for years. The String component PHP’s string handling is famously scattered: prefix-style functions here (str_), suffix-style there (strpos), inconsistent encoding support, and nothing object-oriented in sight. The String component wraps all of this into a fluent, unicode-aware object API: ...

Symfony 4.4 LTS: HttpClient, Mailer, Messenger, and the features that stayed

Symfony 4.4 and 5.0 both landed November 21, 2019. 4.4 is the LTS: same feature set as 5.0, deprecation layer baked in, and a long support window for teams that can’t follow every release. The feature worth singling out arrived in 4.2 and matured through 4.3 and 4.4: HttpClient. HttpClient PHP’s built-in HTTP options (file_get_contents with stream contexts, cURL, Guzzle) each have their own model, their own quirks, and their own abstraction cost. Symfony 4.2 introduced HttpClient, a first-party HTTP client with one API over multiple transports. ...

PHP 7.3: small wins that add up

PHP 7.3 shipped December 6th. No single killer feature. It’s a collection of quality-of-life improvements that individually feel minor but together make daily work noticeably less annoying. Flexible heredoc and nowdoc Until 7.3, the closing marker of a heredoc had to be at column zero. That forced awkward de-indentation in otherwise well-formatted code: // before $html = <<<HTML <div> <p>Hello</p> </div> HTML; // had to be at column 0, ugly // after $html = <<<HTML <div> <p>Hello</p> </div> HTML; The closing marker can now be indented to match the surrounding code, and that indentation is stripped from the content. This looks cosmetic. It’s not. Heredocs in nested contexts (class methods, conditionals) were visually jarring before. Now they fit. ...

PHP 7.2: goodbye mcrypt, hello sodium

PHP 7.2 released November 30th. The headline isn’t a language feature, it’s a removal. mcrypt is gone. This is good news, even if it doesn’t feel that way when you’re the one migrating. The mcrypt problem mcrypt has been unmaintained since 2007. More than a decade of stagnation in a cryptography library. It was deprecated in 7.1, and 7.2 removes it entirely. The replacement is sodium, now bundled as a core extension. ...

Symfony 4.0: Flex and the end of the Standard Edition

Symfony 4.0 released November 30, 2017, same day as 3.4. The shared release date is pretty much the only thing they have in common. 4.0 is a different philosophy. The Symfony Standard Edition, the monolithic starting point that bundled everything and left you to remove what you didn’t need, is gone. In its place: a microframework that grows. Flex Symfony Flex is a Composer plugin that changes how you install Symfony packages. Before Flex, adding a bundle meant: install via Composer, register in AppKernel.php, add config to config/, update routing if needed. Four steps, all manual. ...

Symfony 3.4 LTS: the bridge you actually want to cross

Symfony 3.4 and 4.0 were released the same day: November 30, 2017. That’s not a coincidence, it’s the strategy. 3.4 is not a feature release. It ships with exactly the same features as 3.3, plus every deprecation warning that 4.0 will enforce. Its whole purpose is to be the migration tool: upgrade from 3.3 to 3.4, fix what’s in your logs, then step to 4.0 cleanly. Why LTS releases matter in Symfony’s model Symfony releases a new minor version every six months. That pace would be brutal for production apps to follow, so the project designates every fourth minor as an LTS: three years of bug fixes, four of security fixes. Which means teams can target 3.4 and mostly stop thinking about upgrades for a while. ...

Symfony 3.3: when services stopped being a configuration nightmare

Symfony 3.3 shipped May 29th. It’s the release that changed how I think about service configuration. In hindsight, it was basically a preview of what 4.0 would make the new default. The autowiring problem Before 3.3, Symfony’s DI was powerful but verbose. Every service had to be declared explicitly in services.yml with its arguments listed. Autowiring existed since 3.1, but it was opt-in per service and had enough edge cases to bite you. Teams either wrote mountains of YAML or leaned on third-party bundles to cut the noise. ...

Enforcing UTC in Doctrine without touching your entities

A timestamp coming back from the database one hour off. Not every time. Only when the dev server runs in Europe/Paris and CI runs in UTC. The kind of bug that disappears when you look for it and comes back in production on a Friday evening. The problem isn’t in the business logic. It’s in what Doctrine quietly does with dates. What Doctrine does by default When you declare a datetime field in a Doctrine entity, the conversion between PHP and the database goes through DateTimeType. That class calls format() on your DateTime object to write to the database, and DateTime::createFromFormat() to read it back. No mention of timezone anywhere. ...