Duck typing is dead. Types have won. In all languages, in all communities, on all fronts. And I'm thrilled about it, because this path – the path of strong types – was always the right one.

The Prophecy

Monkey patching, duck typing, rejecting dependency injection – all of it grows from the same root. From the conviction that explicit structure is unnecessary. That code doesn't need to say what it expects and what it returns. That freedom matters more than predictability. And that whoever wants types, DI, and clear contracts simply doesn't understand the beauty of dynamic languages.

In 2007, I wrote an article Ruby on Rails? No, Thanks, where I criticized monkey patching – the Ruby habit of arbitrarily redefining existing classes at runtime. The community explained to me that I was rigid and didn't understand modern programming.

In 2012 came the article Will Rails Discover Dependency Injection?, where I described how Rails rejected dependency injection with the argument that “Ruby is such a good language that it doesn't need DI at all.” The Post model served as both entity and repository, dependencies hid behind static calls, and the whole system held together only through conventions and hope. I predicted that Rails would one day discover DI and it would be a big deal.

It's 2026.

They still haven't ☹

JavaScript Is Dead

Look at the results of the State of JavaScript 2025 survey. 40 percent of developers write exclusively in TypeScript. And how many write exclusively in plain JavaScript, without any types whatsoever?

Six percent.

That's fewer than people who believe the Earth is flat. In 2025, TypeScript became the most-used language on GitHub, overtaking Python and JavaScript itself. In a single year, it gained a million new contributors – a 66% increase.

What's more: TC39 itself, the committee responsible for JavaScript's evolution, is working on a proposal to add type annotations directly to the language. You know why? Because “static typing” was the most-requested missing feature in the State of JS survey five years running. Every year. 2020, 2021, 2022, 2023, 2024. Developers wanted types so desperately that it imprinted itself into the very specification of the language.

JavaScript without types is a dead language. It just doesn't know it yet.

The Duck Showed Its True Colors

And Python? Python, the sacred land of duck typing? The homeland where generations of programmers learned that “if it walks like a duck and quacks like a duck, then it's a duck and you don't need to know anything more”?

86% of Python developers now regularly use type annotations. Guido van Rossum, Python's own papa – the very person who for decades put no types in the language – declared type annotations a crucial benefit for large project productivity. And then went to work on mypy, a tool for static type checking.

FastAPI, the most popular Python web framework, is literally built on types – it won't even start without type annotations. Pydantic, the data validation library that half the AI ecosystem runs on, is existentially dependent on types.

The duck got type annotations fitted.

And Ruby? Ruby's type ecosystem is split into two incompatible systems – Sorbet from Stripe and the official RBS. Neither has achieved mass adoption. DHH, the creator of Ruby on Rails, stands on the barricade with a banner reading “No to Types!”, rejecting them, rejecting DI, rejecting essentially everything that software engineering has considered best practice for the last twenty years. At RubyKaigi 2025, both camps finally tried to find common ground and bridge Sorbet with RBS. Whether it leads anywhere remains to be seen.

All dynamic languages headed the same direction. Toward types. Some faster, some slower. But all of them.

We Were Doing This from the Start

PHP has had runtime types since 2004, when version 5 was released. But the road to full types wasn't straightforward. In 2015, there was a vote on scalar types for PHP 7, and they nearly didn't pass. The vote ended 108 to 48 – just barely above the required two-thirds majority. Four votes the other way and PHP wouldn't have scalar types. It was called “The Great Scalar Type War” and it was one of the most dramatic votes in PHP's history. Fortunately, reason prevailed.

In Nette, we blazed this trail long before it was trendy. Nette Framework had full dependency injection since version 2.0 in 2012. Not as an optional add-on, but as the foundation of the entire architecture. At a time when DHH was declaring DI an unnecessary Java pattern, we built a complete ecosystem around DI and wrote documentation that to this day remains one of the clearest explanations of dependency injection in any language. And we educated the entire Czech PHP community on it.

Nette 3.0, released in April 2019, became the first full-stack PHP framework in the world with a complete type system. Every file declare(strict_types=1). Every parameter typed. Every return value. Every property.

Symfony 5.0 added full types seven months later. Laravel?

Laravel doesn't have strict types even in 2026. And often lacks even native types.

And then there's PHPStan by Ondřej Mirtes – a Czech tool with 344 million downloads today that makes type checking in PHP stricter than in many a statically typed language. In the latest version, PHPStan 2.0, level 10 was added, which detects even implicitly typed mixed values.

Why AI Killed It

You know what definitively buried duck typing? Not programmers. Not frameworks. Artificial intelligence.

A 2025 study found that 94% of compilation errors in code generated by language models are type-checking errors. Ninety-four percent. The type system is a safety net for code you didn't write yourself.

When I sit down with Claude Code today and work on PHP code with full types and PHPStan, the AI agent understands my code. It knows what functions accept. It knows what they return. It knows what properties objects have. It knows what's allowed and what isn't. In duck-typed code, it would be flying blind.

Duck typing was always a dumpster fire. But at least a dumpster fire that somehow worked at small scale. In an era where AI agents generate hundreds of lines of code daily, it's a dumpster fire that doesn't work at all.

So let me sum up: TypeScript buried vanilla JavaScript. Python added types and 86% of developers use them. Ruby is floundering. And PHP? PHP has full runtime types, PHPStan with 344 million downloads, and Nette, which was doing this before it was cool.

Normally I'd end with a self-deprecating paragraph about how nobody likes the guy who says “I told you so.” But you know what?

I told you so.

I remember going through PHPStan output once, systematically fixing one warning after another. I felt productive. Code is cleaner, types are correct, green everywhere. A month later I was scratching my head over why a function was returning an empty string when it shouldn't. An hour-long detective story, yet the culprit was obvious – me and my “fix.”

One thing first, though: PHPStan does exactly what it should. It warns you that a function may return null or false, and forces you to think about it. That's great. The problem is your reaction.

An Innocent Example

Say we have a function that removes extra whitespace from text:

function normalizeSpaces(string $s): string
{
	return preg_replace('#\s+#', ' ', $s);
}

PHPStan reports: Function preg_replace returns string|null but function should return string. Sure enough, preg_replace can return null if a regex error occurs. So let's fix it, right?

function normalizeSpaces(string $s): string
{
	return (string) preg_replace('#\s+#', ' ', $s);
}

PHPStan is happy. Commit, push, done.

Except.

What You Actually Did

The original code was actually better. If preg_replace ever returned null – say, because of… (no, nothing comes to mind) – PHP would throw a TypeError. A fatal error. Tracy would light up, it would show up in the log, you'd simply know about it. (Oh right – that's why it can return null!)

After your “fix”, null silently gets cast to an empty string. The function returns "", the application keeps running, and you have no idea something went wrong. Data gets corrupted without any warning.

Congratulations, you just made your code worse 🙂

And preg_replace isn't an isolated case. Plenty of PHP functions return false or null for situations that practically never occur in normal usage – json_encode, ob_get_contents, getcwd, gzcompress, a whole range of Intl functions. Every time you reach for a type cast, stop and ask yourself: am I throwing away information about an (unlikely) error?

The Right Approach

If you want to satisfy PHPStan while preserving the original behavior, use a throw expression:

function normalizeSpaces(string $s): string
{
	return preg_replace('#\s+#', ' ', $s)
		?? throw new \LogicException('preg_replace failed');
}

This says: “I know an error can theoretically occur. If it does, I want to know.” You've essentially written out explicitly what was there implicitly before – a fatal on failure. PHPStan happy, code unharmed.

But hold on. There's an even simpler way. You can just ignore these trivial errors in PHPStan – add them to ignoreErrors in phpstan.neon or use the @phpstan-ignore annotation. And that's perfectly legitimate. After all, the original behavior where PHP throws a TypeError is basically what you want. Why change the code for that?

Even better is not having the problem at all. That's why wrappers exist – for instance, Nette\Utils\Strings::replace() wraps preg_replace and throws an exception on error. Similarly Nette\Utils\Json::encode() instead of json_encode. Use one function and the problem disappears – no null, no false, nothing to deal with.

Another option is to solve it at the PHPStan level with an extension that removes false or null from return types of selected functions. For example, nette/phpstan-rules does this for dozens of PHP functions. For regex functions, it even checks whether the pattern is a constant string – if so, it strips null from the type, since a regex error can't occur.

This is an opinionated approach, of course. And that's exactly what I like about PHPStan – it's strict, and I can customize it with extensions to suit my needs.

A silent error is worse than a loud one. And (string) is the quietest way to produce it.

The other day I told Claude: “Turn off wifi.” And it did – because it knows how to do that from the command line. Then I said: “Turn on wifi.” And it did nothing. Because it had no internet.

This experience nicely illustrates what Claude Code actually is. It's not just a chatbot you talk to. It's a tool that has access to your computer and can perform actions on it. It can read and edit files, run programs, install software, work with data. Basically anything you'd normally do manually.

In the previous article we showed how to install Claude Code. Now let's look at what you can use it for. And trust me – there's a lot more than you'd expect.

Programming

Let's start with the most expected use case. Claude Code is primarily a tool for programmers, and it truly excels in this area.

Writing new code. Describe what function you need, and Claude will write it. You don't need to know the syntax, you don't need to google – just say what the code should do, and it creates it. A team of data engineers at Anthropic had Claude write a complete React application – 5,000 lines of TypeScript – even though they didn't know React themselves.

Bug fixes. Throw an error message at it and let it find the cause and fix it. Claude will go through your code, understand the context, and suggest a fix. You don't have to spend hours figuring out where the problem is.

Refactoring. Got old messy code? Claude will clean it up, split long functions into smaller ones, rename variables to meaningful names. One developer described how he refactored a 210-line Python function down to less than 30 lines.

Tests. Claude will write unit tests for your code. It can even work with test-driven development – first writing tests, then code that passes them.

Documentation. It documents functions, creates README files, describes APIs. Everything programmers hate doing manually.

Code review. It goes through code and suggests improvements – better names, more efficient algorithms, potential bugs.

Working with files

This is where Claude Code becomes interesting even for non-programmers. It has access to your files and can work with them.

Organization. Got a chaotic Downloads folder full of randomly named files? Claude will sort it out. It'll create subfolders by type, date, project – whatever you need.

Bulk renaming. Need to rename hundreds of files according to a certain pattern? For example, renaming invoices to “2024–01–15 Vendor – Invoice.pdf”? Claude handles it in seconds.

Format conversion. Converts data between formats – CSV to JSON, XML to a table, whatever you need.

Writing and working with text

Although it's called “Code,” Claude Code is surprisingly good at helping with text.

Articles and blogs. Helps structure thoughts, write first drafts, edit and improve. One user called it the best writing support system they'd ever tried.

Organizing notes. Got chaotic notes scattered across different files? Claude will go through them and organize them into a coherent whole. One user uploaded voice notes from walks with a stroller – Claude transcribed them, organized them into research topics, and eventually wrote an article in her style.

Translations. Translates text while preserving formatting. Can even batch translate all text files in a project.

Proofreading. Fixes spelling, grammar, style. Suggests better phrasing.

Data analysis

Unlike web Claude, which has file size limits, Claude Code can process huge datasets. And most importantly – it can write its own code for analysis and run it immediately.

Reports on demand. You tell it: “Look at this sales data and create a report with charts and trend analysis.” And it does it. Loads the data, analyzes it, creates visualizations, and writes a summary.

Finding patterns. Claude finds anomalies and trends that you'd spend hours looking for manually. Which product has declining sales? Where are the seasonal fluctuations?

Data cleaning. Got a list of addresses full of typos and duplicates? Claude will clean it up, standardize the format, and remove errors.

One user described how they simply uploaded a CSV file with customer data and said: “Imagine you're a data consultant. Perform an analysis and suggest recommendations.” Claude went through the data and delivered a detailed report with findings.

Automation

This is where Claude Code truly shines. It can create automated processes that save you hours of work.

Repetitive tasks. Got something you do the same way every day or week? Claude will automate it. Downloading data, generating reports, sending notifications.

Connecting services. Claude can connect different tools together. Anthropic's marketing team used this approach to create a system that automatically generates hundreds of ad text variations from a CSV file with ad performance data.

Monitoring and notifications. You can have Claude monitor logs or data and alert you when something breaks or an interesting pattern appears.

System administration

Claude Code can function as your personal IT support.

Diagnostics. “Why is my computer slow?” – and Claude checks CPU usage, memory, disk, running processes, Docker containers, everything possible. And suggests solutions.

Configuration. Need to set something up in your system but don't know how? Describe what you want, and Claude will configure it.

Installation. Claude installs software, configures the environment, sets up dependencies.

One user described how Claude connected via SSH to a remote server, modified the configuration of a monitoring tool, and adapted when some commands failed.

For more advanced users, Claude Code also helps with infrastructure management. It sets up automatic builds and deploys, configures server monitoring, helps with Docker containers. Even a non-technical person can set up a basic CI/CD pipeline with Claude's help.

But beware – it's still AI

Before you get carried away with enthusiasm, there's one important thing to say: Claude Code makes mistakes. Like any AI. Sometimes small ones, sometimes… well, sometimes monumental ones.

One programmer told me the following story. He gave Claude the task of modernizing an outdated project. Claude ran for an hour. Rewrote everything. Legacy code from 2015? Gone. Outdated patterns? Replaced with elegant modern solutions. Confusing architecture? Now crystal clear. The result looked like it was from a textbook – TypeScript, tests, documentation, everything.

It was absolutely top-notch code.

Which didn't work at all.

That's why this holds true: the better programmer you are and the more you understand your field, the better results you'll achieve with Claude Code. Not because you'd have to write the code yourself – but because you'll recognize when Claude makes a mistake. And it will. The question isn't if, but when.

Think of Claude as a junior with unlimited energy and encyclopedic knowledge who still needs supervision. Let it work, but check the results. Test. Verify it actually works before you push it to production.

What does this mean?

Claude Code isn't just a tool for programmers. It's an “everything agent” – a universal assistant that has access to your computer and can perform almost any task.

The key to success is simple: describe what you want in plain language. You don't need to know commands, you don't need to understand technicalities. Just say what you want to achieve, and Claude will find a way to do it.

Users report 40–80% time savings on routine tasks. Some startups have built entire products with practically no traditional programming. All because you have an intelligent helper at your disposal who can control your computer.

Just watch out for that wifi.

Since PHP 8 rewrote the comparison rules, there are two tables:

👉 Table for PHP 8.x (The present you need to master)
👉 Table for PHP 7.x (For legacy warriors and code archaeologists)

We've all learned to use === for a good night's sleep. It's our safety net. But what happens when you don't need to know if values are identical, but which one is greater or smaller? That's where certainty evaporates. The operators <, >, <=, and >= have no “strict” version. PHP grabs the wheel and fires up type juggling. Do you know for certain how comparing a number to a string behaves? Or null to false?

Just check the table and instantly see how types interact when PHP forces them together. It starts with a comprehensive overview of all operators, including the spaceship (<=>).

Catch Silent Bugs Before They Strike

Here are two examples that can cost you hours of debugging. Different PHP functions use different comparison strategies. The sort() function, for instance, defaults to SORT_REGULAR.

How does it handle strings that look like numbers, such as "042" and " 42"? How will it sort them?

• I find the SORT_REGULAR section in the table
• I look up the intersection of these values
• I see the symbol =
• What it means: PHP treats them as identical in this mode. The resulting order of these elements after sorting will be undefined. If order matters, we've got a problem.

What about array_unique()? Will it silently “cannibalize” my data when "042" and " 42" meet in the array? No need to test.

• The array_unique() function defaults to SORT_STRING
• I check the intersection of these values
• I see the symbol <
• What it means: We're in the clear – the values differ (because everything converts to string)

Thanks to the table, no more guessing. You see instantly when you need to switch flags to make your application behave exactly as intended.

(And yes, there's no flag for strict comparison without type juggling in PHP 😤)

The Fun Stuff: DateTime and Closures

Or what you probably don't know about comparing objects in PHP.

Take DateTime. Many developers believe objects can't be compared, so they desperately convert dates to timestamps or formatted strings like 'Y-m-d H:i:s' just to figure out what came first. Completely unnecessary! The DateTime and DateTimeImmutable classes have built-in logic for standard comparison operators. You can check for greater/smaller as naturally as with numbers. No helpers, no formatting, just clean syntax. That's why it deserves its own DateTime section in the table.

The real fun starts with equality. While === is ruthless with objects and only cares if you're holding the exact same instance, the == operator takes a more pragmatic approach with dates – it compares the time value. This means you can compare two different objects, and if they represent the same moment in time, PHP says “yes, these are equal”. Better yet – it works cross-class between DateTime and DateTimeImmutable!

And the cherry on top? Closures. Even anonymous functions are objects. When are two closures equal? Check the table!

What You Can Do With It

Here are just a few examples of what you can accomplish:

• 💡 Describe the function you need, and Claude writes it for you
• 🐛 Pass it an error message and let it hunt down and fix the problem
• 🔧 Refactor existing code, add tests, write documentation
• 🗺️ When you need to understand an unfamiliar project, just ask how it all works

And here's what you might not know – Claude Code isn't just for programming. Since it has access to your terminal, you can ask it to handle all sorts of tasks:

• 📋 Organize your downloads folder
• ⚙️ Install packages and configure your system
• 📁 Batch rename hundreds of files or search through data

Basically anything you'd normally do on the command line – just instead of googling commands, you describe what you want in plain English and Claude does it for you. We'll explore more in the article What Claude Code Can Do.

Who This Guide Is For

You don't need to be an AI expert or a seasoned programmer – Claude Code is designed to be accessible to everyone. That said, the better you understand programming and your domain, the better results you'll get.

This first article is aimed at complete beginners and walks you through installing Claude Code. In later parts, we'll dive into practical usage, but first we need to tackle that crucial first step – getting it up and running. By the end of this guide, you'll have everything set up and ready to start exploring Claude Code.

How to Use Claude Code?

You can use Claude Code in three ways:

Desktop Application (easiest) 🖥️

A traditional application with windows and buttons – no geeky terminal required. You work with local files on your computer just like in any editor. You watch code being written in real-time and simply approve each step along the way. You won't have access to the full arsenal of advanced commands, but that won't bother a beginner at all.

Command Line / Terminal (for advanced users) 💻

You launch Claude Code from the terminal using text commands. If you're not familiar with terminals, think of them like those text adventure games from the 80s – you type a command, hit Enter, and the computer responds. Except instead of “go north,” you type “build me a website.” You get a full-featured tool with all advanced functions, but you need to be comfortable working with the command line.

Web (for quick testing) 🌐

Claude Code can also be used directly on the web, but without access to local files. However, if you have your data on Google Drive, this might actually be an advantage – you don't need to install anything and can start immediately.

For beginners, I recommend starting with the desktop application.

Installation: Desktop Application

Head to claude.com/download and download the application. Open the installer and complete the installation process. Then launch the application from Applications (Mac) or the Start menu (Windows).

You'll also need to open gitforwindows.org, click Download, and install Git, which Claude Code requires to function.

After launching the app for the first time:

1. Find the Code tab in the application's sidebar and click it
2. Install runtime dependencies – the app will prompt you to install required components, click “Install dependencies” and wait for the installation to complete
3. Sign in with your Claude account – if you don't have one yet or need a subscription, check out the section How Much Does Claude Code Cost? below
4. Select a project folder using the “Select folder” button
5. Start working! Describe what you want to create, and Claude will make it happen

The app will ask you to confirm “Trust workspace” when you first access a folder – this is a security feature. Simply approve and continue.

Desktop users can skip the rest of this article – the following sections are only for terminal installation.

Installation: Terminal on macOS and Linux

• For macOS: Open Terminal (find it in Applications > Utilities, or press Cmd+Space and type “Terminal”)
• For Linux: Open your preferred terminal (usually Ctrl+Alt+T)

curl -fsSL https://claude.ai/install.sh | bash

This command downloads and runs the installation script. Once it completes, you're all set and can skip ahead to Launching Claude Code from Terminal.

On macOS, you can alternatively use Homebrew:

brew install --cask claude-code

Installation: Terminal on Windows

On Windows, you have two options for running Claude Code in the terminal:

Option 1: PowerShell (quickest start 🚀)

This is the fastest way to get going. Open PowerShell (press Win+X and select “Windows PowerShell” or “Terminal”) and run:

irm https://claude.ai/install.ps1 | iex

You'll also need to open gitforwindows.org, click Download, and install Git, which Claude Code requires to function.

That's it! Claude Code is now installed and you can skip to Launching Claude Code from Terminal.

Option 2: WSL (for power users 🔧)

Choose this route if you're already actively using WSL (Linux inside Windows), or if you run into issues or need a tool that requires a Linux environment. (You can always start with PowerShell and switch to WSL later if needed.)

Open your terminal (press Win+X and select “Windows PowerShell” or “Terminal”) and enable WSL with:

wsl --install

This command enables WSL and installs Ubuntu as your default Linux distribution. Once it completes, restart your computer. Then run ubuntu to access the Linux command line.

ubuntu

It will first ask you to create a username and password for Linux. You'll need this password when installing programs (the sudo command), so make sure to remember it.

Now you can install Claude Code in the Ubuntu terminal:

curl -fsSL https://claude.ai/install.sh | bash

One of the best features of WSL is that Windows and Linux share the same files. You don't need to copy anything – you're simply working with the same folders from both systems. Your Windows C: drive appears in Linux at /mnt/c/, your D: drive at /mnt/d/, and so on. So for instance, the folder C:\Users\John\Projects is accessible in Linux as /mnt/c/Users/John/Projects. Conversely, in File Explorer you can type \\wsl$ in the address bar to see all your Linux distributions. Your Ubuntu home folder will typically be at \\wsl$\Ubuntu\home\your-name.

Launching Claude Code from Terminal

Great, you've successfully installed Claude Code – let's fire it up!

The key is to launch it in the folder where you want to create a new project or work on an existing one. First, you need to navigate to that folder using the cd (change directory) command.

Example for Windows (PowerShell):

cd C:\Users\John\Projects\my-website

Example for Windows (WSL):

cd /mnt/c/Users/John/Projects/my-website

Example for macOS/Linux:

cd ~/projects/my-website

Then launch Claude Code with:

claude

As you can see from the screenshot, Claude Code immediately prompts you to sign in.

How Much Does Claude Code Cost?

There's something important to clarify here, since Claude isn't as well-known in the Czech Republic yet. Claude is a web-based chatbot from Anthropic – similar to OpenAI's ChatGPT. You can chat with it in your browser, ask it anything, get help with writing, and so on. That's the basic Claude.

Claude Code is something different. It's a standalone tool that runs in your terminal or desktop app and works directly with your files. While web-based Claude involves chatting and copying text back and forth, Claude Code actually edits your files, executes commands, and tests whether everything works.

And here's the good news: Claude Code is included with your subscription to web Claude. So when you subscribe to Claude as a chatbot (as an alternative to ChatGPT), you get Claude Code thrown in.

You start with Claude Pro at $20/month, which is perfectly adequate for regular use. Personally, I fell in love with Claude and use it so intensively that I upgraded to Claude Max (starting at $100/month), which offers 5–20× more usage. But Pro is definitely sufficient to get started.

The desktop app will take you to the sign-in page on first launch, just like the terminal version. Sign in or create an account there, choose a plan that suits you, and return to the application.

Tip for Nette Developers

If you work with Nette, I have great news. There's a special plugin for Claude Code that gives Claude deep knowledge of the Nette framework.

Instead of generic PHP suggestions, you get recommendations that follow Nette conventions – from presenters and forms to Latte templates and database queries. The plugin includes 10 automated skills covering the main areas of development, plus automatic validation for Latte and NEON files, so you catch errors right away.

Want to master Claude Code? I'm running a course that takes you from the basics to advanced techniques. You'll learn how to get the most out of Claude and avoid common pitfalls. More information and registration

What's Next?

You now have Claude Code ready to go. In upcoming articles, we'll cover:

• Basic commands and controls in Claude Code
• Working with existing projects
• Creating new projects from scratch

Claude Code represents a revolution in how we program. With this tool, you can bring your ideas to life faster than ever before – you just need to know how to use it effectively.

Time in programming is like a beast that appears tame until you step on its tail. And one of this beast's most powerful tricks is daylight saving time with its insidious transitions. A system supposedly created to save candles now causes programmers sleepless nights (probably around 2:30 AM when they suddenly realize their servers are doing weird things).

Let's explore the dark corners of daylight saving time transitions, how PHP (mis)handles them, and how I attempted to fix this madness in Nette Utils. Prepare for moments when 1 + 1 ≠ 2 and when adding a longer time paradoxically returns an earlier hour. Not even Einstein could have conceived of this.

First, let's run through some terminology

Before diving into the problem, let's explain a few key concepts:

• UTC (Coordinated Universal Time) – the fundamental time standard from which all other time zones are derived. It's essentially the “zero point” for measuring time across the world.
• Time offset – how many hours need to be added to or subtracted from UTC to obtain local time. It's denoted as UTC+X or UTC-X.
• CET (Central European Time) – the Central European Time we use in winter. It has an offset of UTC+1, which means that when it's noon in UTC, it's 1:00 PM here.
• CEST (Central European Summer Time) – the Central European Summer Time we use in summer. It has an offset of UTC+2, so when it's noon in UTC, it's 2:00 PM here.
• Daylight Saving Time – a system where during a certain part of the year (usually summer) we move the clocks forward by one hour to better utilize daylight.

That moment lasted a whole light-year

Let's break down, second by second, how the transition to daylight saving time and back works. As an example, let's take the recent time change in the Czech Republic on Sunday, March 30, 2025:

• At 01:59:58 Central European Time (CET), everything is normal.
• At 01:59:59 CET, everything is still normal.
• In the next second, 02:00:00 CET does NOT occur. Instead, the clocks magically jump forward.
• This is followed by 03:00:00 Central European Summer Time (CEST).

The entire hour between 02:00:00 and 02:59:59 locally “doesn't exist” on this day. If you were supposed to have an important phone call at 2:30 AM, you're out of luck.

Similarly, during the transition back to standard time (sometimes called “winter time”) in autumn (e.g., October 26, 2025), the opposite situation occurs:

• At 02:59:59 summer time (CEST), everything is normal.
• In the next second, 03:00:00 CEST does NOT occur. The clocks go back.
• This is followed by 02:00:00 standard Central European Time (CET).

In this case, the hour between 02:00:00 and 02:59:59 occurs twice. First in summer time (CEST) and then in standard time (CET). How do we distinguish which 2:30 we mean? By using the time zone designation (CET/CEST), the UTC offset (+01:00 / +02:00), or simply by referring to “summer” and “winter” time.

Time zones: What does Europe/Prague actually denote?

When we use a time zone identifier like Europe/Prague in PHP (or elsewhere), it's not just information about the current offset from UTC. It's a reference to a record in the IANA Time Zone Database (abbreviated as tz database), which contains comprehensive historical and future rules for a given geographical area:

• Standard UTC offset (how many hours are added to or subtracted from UTC).
• Daylight saving time rules (when it starts, when it ends).
• Historical changes in offsets or daylight saving time rules (which can change by government decisions).

There are hundreds of such zones (America/New_York, Asia/Tokyo, Australia/Sydney). Some areas don't use daylight saving time at all (e.g., most of Africa and Asia, or regions near the equator) and have the same UTC offset year-round (e.g., Etc/UTC or Africa/Nairobi).

Absolute time: UTC and Timestamp

To avoid confusion with local times and daylight saving time, there are absolute time references:

• UTC: As we've already mentioned, it's the basic time standard that doesn't use daylight saving time. All local times are defined as offsets from UTC. UTC is essentially “pure” time, to which each time zone then adds its offset.
• Unix Timestamp: The number of seconds that have elapsed since the beginning of the Unix epoch (January 1, 1970, 00:00:00 UTC), not counting leap seconds. The timestamp is also absolute and independent of time zone or daylight saving time.

It's precisely the conversion between absolute time (UTC/timestamp) and local time in a specific zone where daylight saving time rules come into play.

PHP DateTime: When the clocks turn

When you work with a DateTime or DateTimeImmutable object in PHP, it always has an assigned time zone. If you don't explicitly specify one, the default zone set in PHP is used (via configuration or using date_default_timezone_set()).

What happens when you try to create a time that doesn't exist due to daylight saving time, or a time that exists twice?

Non-existent time (spring jump):

// Attempt to create a time in the "gap" on March 30, 2025
$dt = new DateTime('2025-03-30 02:30:00', new DateTimeZone('Europe/Prague'));
echo $dt->format('Y-m-d H:i:s T (P)');
// Output: 2025-03-30 03:30:00 CEST (+02:00)

PHP typically “normalizes” this invalid time by moving it forward by one hour to the first valid time after the jump. So 02:30 becomes 03:30.

Ambiguous time (fall back):

// Attempt to create a time in the "overlap" on October 26, 2025
$dt = new DateTime('2025-10-26 02:30:00', new DateTimeZone('Europe/Prague'));
echo $dt->format('Y-m-d H:i:s T (P)');
// Output: 2025-10-26 02:30:00 CET (+01:00)

Here, PHP by default chooses the second occurrence of that time. Why the second and not the first? Because PHP considers standard time (CET) to be the default, basic state and daylight saving time (CEST) only as a temporary adjustment. From the system's perspective, daylight saving time is just a temporary deviation from the “normal” state, and therefore when ambiguous, it prefers standard time.

Relative time expressions and their subtleties

Now we come to the really tricky part. PHP allows working with relative time expressions – strings like +30 minutes, -1 hour, or 1 day 2 hours. We can use these expressions in two ways:

1. Directly in the constructor new DateTime('+50 minutes')
2. In the $date->modify('+50 minutes') method

By the way, Nette has always promoted these relative time expressions because they are intuitive and clear. You definitely know them from the “expiration” configuration for sessions or in other parts of the framework.

Intuitively, we would expect that when we add a longer time period, the resulting time would be later. But with relative time expressions during the spring transition, this might not hold true! And this problem manifests itself both when used in the DateTime constructor and in the modify() method.

Imagine it's half past one in the morning, just before the spring jump. At that moment, something very bizarre might be happening in your application, which most of us won't notice because we're either peacefully sleeping in bed or even more contentedly sharing wisdom at the pub. But in server rooms around the world, the code quietly continues to run…

// for all subsequent examples we'll set the default time zone
date_default_timezone_set('Europe/Prague');

// It's now 2025-03-30 01:30:00 and we create a DateTime with a relative time of +50 minutes
$dt50 = new DateTime('+50 minutes');
echo $dt50->format('Y-m-d H:i:s T (P)');
// Output: 2025-03-30 03:20:00 CEST (+02:00)

“Wait a minute, 1:30 plus 50 minutes is 2:20. Why does it show 3:20?” As we've already discussed, the hour between 2:00 and 3:00 doesn't exist. So 2:20 is an invalid time, which PHP corrects by moving it forward by an hour. Thus to 3:20 in summer time.

And what if we add a longer interval to the same starting time – say 100 minutes?

$dt100 = new DateTime('+100 minutes');
echo $dt100->format('Y-m-d H:i:s T (P)');
// Output: 2025-03-30 03:10:00 CEST (+02:00)

See that! Yes, you're reading correctly. After adding 100 minutes, we got a time (03:10) that is earlier than the time after adding 50 minutes (03:20).

• +50 minutes: 01:30 + 50 min = 02:20. This time doesn't exist because it's in that “lost hour”. PHP normalizes it by moving it forward by an hour to 03:20 CEST.
• +100 minutes: 01:30 + 100 min (1h 40m) = 03:10. This time already exists. So PHP uses it as is.

The modify() method and constructor with relative strings in PHP tend to perform arithmetic first at the level of “clock time” and only then deal with invalid times caused by the daylight saving time jump. The result is completely unintuitive behavior that most time libraries in other languages don't exhibit. They typically interpret +X minutes as adding an exact duration (X * 60 seconds) to the absolute time moment.

DateInterval: Another layer of complications

The story gets even more complicated with the DateInterval class. It was created specifically for working with time intervals and could offer a solution to our problem. But alas…

To create a DateInterval instance, you must use the ISO 8601 format. Honestly, would you understand at first glance what PT100M means? No? Me neither. It's “Period of Time, 100 Minutes”. Standardized, but definitely not intuitive at first sight.

Nevertheless, if we swallow this strange notation, suddenly everything works correctly!

$dt = new DateTime('2025-03-30 01:30:00');
$dt->add(new DateInterval('PT100M')); // 100 Minutes - that wonderful ISO 8601 format
echo $dt->format('Y-m-d H:i:s T (P)');
// Output: 2025-03-30 04:10:00 CEST (+02:00) - hurray, works correctly!

Great! Here it really behaves as we would expect – it adds exactly 100 minutes to the absolute time. This could be our solution… but what about that strange format?

PHP developers were aware that PT100M isn't exactly user-friendly, so they added the DateInterval::createFromDateString() method, which understands those nice text expressions like 100 minutes:

$dt = new DateTime('2025-03-30 01:30:00');
$dt->add(DateInterval::createFromDateString('100 minutes'));
echo $dt->format('Y-m-d H:i:s T (P)');
// Output: 2025-03-30 03:10:00 CEST (+02:00) - ouch, wrong again!

And we're back where we started! The same problem as with modify(). What's happening?

In reality, we're dealing with a kind of “dual nature” of the DateInterval class. It depends on how we create it:

1. When we use the constructor with ISO 8601 format new DateInterval('PT100M'), it creates a real duration, which is added to the absolute time.
2. When we use createFromDateString('100 minutes'), it creates more of a calendar interval, which behaves similarly to modify() – it first performs “clock” arithmetic and then deals with problems with invalid times.

So not all DateIntervals are created equal. It's a completely different face of the same named object depending on how we create it.

One solution: Escape to UTC

One way to avoid these problems is to perform all time arithmetic in UTC, where no daylight saving time exists, and only convert the final result to the desired local zone:

$dt = new DateTime('2025-03-30 01:30:00');
$dt->setTimezone(new DateTimeZone('UTC')); // Convert to UTC
$dt->modify('+100 minutes');               // Perform operation in UTC
$dt->setTimezone(new DateTimeZone('Europe/Prague')); // Convert back
echo $dt->format('Y-m-d H:i:s T (P)');
// Correct output: 2025-03-30 04:10:00 CEST (+02:00)

Hurray! Or not? This trick can be counterproductive when adding whole days or other calendar units. First, let's verify that when we add 1 day to a time before the spring jump, we get the expected result:

$dt = new DateTime('2025-03-30 01:30:00'); // Before the jump (CET +01:00)
$dt->modify('+1 day');
echo $dt->format('Y-m-d H:i:s T (P)');
// Output: 2025-03-31 01:30:00 CEST (+02:00)

We see that when adding one day, the same “clock” value (01:30) remains, but the time zone changes from CET to CEST.

But what happens when we use our UTC trick?

$dt = new DateTime('2025-03-30 01:30:00'); // Before the jump (CET +01:00)
$dt->setTimezone(new DateTimeZone('UTC')); // Converts to UTC
$dt->modify('+1 day');
$dt->setTimezone(new DateTimeZone('Europe/Prague')); // Converts back to local zone
echo $dt->format('Y-m-d H:i:s T (P)');
// Output: 2025-03-31 02:30:00 CEST (+02:00) - one hour more!

Oops! The hour shifted from 1:30 to 2:30. Why?

1. We converted the original time (01:30 CET) to UTC (00:30 UTC)
2. We added a day in UTC (00:30 UTC the following day)
3. But the following day, Prague is already on summer time (CEST), which has an offset of +2 hours from UTC
4. So when we convert 00:30 UTC back, we get 02:30 CEST

This “escape to UTC” can therefore cause calendar operations to not behave intuitively from a local time perspective. So what is the correct behavior? It depends on your needs – sometimes you want to preserve the absolute time interval (like 24 hours), other times you want to preserve the calendar meaning (like “same time next day”).

Solution in Nette Utils

Because working with time, time zones, and daylight saving time is notoriously complex, I decided to add a fix for PHP's problematic behavior to Nette Utils. Specifically to the Nette\Utils\DateTime class, fixing both the constructor and the modify() method. I'm just hesitant about whether it's a BC break – I'll come back to that in the conclusion.

$dt = new Nette\Utils\DateTime('2025-03-30 01:30:00');
$dt->modify('+100 minutes');
echo $dt->format('Y-m-d H:i:s T (P)');
// Output: 2025-03-30 04:10:00 CEST (+02:00) - CORRECT!

With Nette\Utils\DateTime, the result for +100 minutes is always later than for +50 minutes, even at half past one in the morning!

When is 1 + 1 ≠ 2? When working with time!

The implementation in Nette Utils also solves more complex cases where we combine adding days and hours. Here we come to a really interesting problem: there are two possible interpretations of a relative expression like “+1 day +1 hour”. And these two interpretations give different results during the transition to daylight saving time! Let's demonstrate with an example:

First interpretation:

$dt = new DateTime('2025-03-30 01:30:00'); // CET

$dt1 = clone $dt;
$dt1->modify('+1 day'); // First add a day: 2025-03-31 01:30:00 CEST
$dt1->modify('+1 hour'); // Then add an hour: 2025-03-31 02:30:00 CEST

Second interpretation:

$dt2 = clone $dt;
$dt2->modify('+1 hour'); // First add an hour: 2025-03-30 03:30:00 CEST
$dt2->modify('+1 day');         // Then add a day: 2025-03-31 03:30:00 CEST

The difference is a whole hour! As you can see, the order of operations plays a crucial role here.

In Nette\Utils\DateTime, I chose the first interpretation as the default behavior because it's more intuitive. When we want to add “1 day and 1 hour”, we usually mean “same time next day plus an hour”. And what's best? It doesn't matter in which order you write the units. Whether you use +1 day +1 hour or +1 hour +1 day, the result will always be the same.

This consistency makes working with time expressions much more predictable and safe.

Time is hard, don't struggle alone

Working with time in PHP can be treacherous, especially around daylight saving time transitions. Relative time expressions and even some ways of using DateInterval can lead to unintuitive results.

If you need reliable time manipulation:

1. Use Nette\Utils\DateTime, which fixes the problematic behavior.
2. Or perform time arithmetic in the UTC zone and then convert back to the local zone.
3. Always test the behavior of your code during daylight saving time transitions.

Now I'm just wondering if fixing the DateTime behavior in Nette Utils will be a BC break. Honestly, I don't think anyone consciously relies on the treacherous current behavior during daylight saving time transitions. So I would probably include it in Nette Utils 4.1.

Time is a difficult topic in all programming languages, not just PHP. Cache invalidation doesn't hold a candle to it.

Let's Start with the Most Dangerous Part

JavaScript has one treacherous quirk: by simply omitting a variable declaration, you can unknowingly use a global variable. All it takes is forgetting var, let, or const:

function calculatePrice(amount) {
    price = amount * 100;    // Omission! Missing 'let'
    return price;            // We're using a global variable 'price'
}

function processOrder() {
    price = 0;               // We're using the same global variable!
    // ... some code calling calculatePrice()
    return price;            // We're returning a completely different value than expected
}

This is every developer's nightmare – the code appears to work correctly until something mysteriously starts failing elsewhere in the application. Debugging such errors can take hours because a global variable can be overwritten anywhere in the application.

That's why it's absolutely crucial to always declare variables using let or const.

Forget About var

The var keyword has been in JavaScript since its inception in 1995 and carries some problematic properties that were considered features at the time of the language's creation but proved to be a source of many bugs over time. After twenty years of language development, JavaScript's authors decided to address these problems – not by fixing var (to maintain backward compatibility) but by introducing the new let keyword in ES2015.

You can find plenty of articles on the internet dissecting the problems with var in the finest detail. But you know what? There's no need to get bogged down in the details. Let's just treat var as a relic of the past and focus on modern JavaScript.

When to Use let

let is the modern way to declare variables in JavaScript.

The nice thing is that the variable only exists within the code block (between curly braces) where it was defined. This makes the code more predictable and safer.

if (someCondition) {
    let temp = calculateSomething();
    // temp is only available here
}
// temp no longer exists here

In loops, the declaration is technically placed before the curly braces, but don't let that confuse you – the variable only exists within the loop:

for (let counter = 0; counter < 10; counter++) {
    // The counter variable only exists in the loop
}
// counter is no longer accessible here

When to Use const

const is used to declare constants. These are typically important values at the module or application level that should never change:

const PI = 3.14159;
const API_URL = 'https://api.example.com';
const MAX_RETRY_ATTEMPTS = 3;

However, it's important to understand one key detail: const only prevents assigning a new value to the variable – it doesn't control what happens with the value itself. This distinction is particularly evident with objects and arrays (an array is also an object) – const doesn't make them immutable objects, i.e., it doesn't prevent changes inside the object:

const CONFIG = {
    url: 'https://api.example.com',
    timeout: 5000
};

CONFIG.url = 'https://api2.example.com';  // This works!
CONFIG = { url: 'https://api2.example.com' };  // This throws TypeError!

If you need a truly immutable object, you need to freeze it first.

The let vs const Dilemma

Now we come to a more interesting question. While the situation with var vs let is clear, the use of const is the subject of many community discussions. Most tutorials, style guides, and linters promote the rule “use const wherever you can.” So we commonly see const used in function or method bodies.

Let's explain why this popular “best practice” is actually an anti-pattern that makes code less readable and unnecessarily restrictive.

The approach “if a variable's value isn't reassigned in the code, it should be declared as const” seems logical at first glance. Why else would const even exist? The more “constants,” the safer and more predictable the code, right? And faster too, because the compiler can better optimize it.

However, this entire approach fundamentally misunderstands the purpose of constants. It's primarily about communicating intent – are we truly trying to signal to other developers that this variable should never be reassigned, or do we just happen not to reassign it in our current implementation?

// Real constants - values that are constant by their nature
const PI = 3.14159;
const DAYS_IN_WEEK = 7;
const API_ENDPOINT = 'https://api.example.com';

// vs.

function processOrder(items) {
    // These AREN'T constants, we just happen to not reassign them
    const total = items.reduce((sum, item) => sum + item.price, 0);
    const tax = total * 0.21;
    const shipping = calculateShipping(total);
    return { total, tax, shipping };
}

In the first case, we have values that are constants by their nature – they express immutable properties of our system or important configuration data. When we see PI or API_ENDPOINT somewhere in the code, we immediately understand why these values are constants.

In the second case, we're using const just because we happen to not reassign the values right now. But that's not their essential characteristic – these are regular variables that we might want to change in the next version of the function. And when we want to do that, const will unnecessarily prevent us.

In the days when JavaScript was one big global code, it made sense to try to secure variables against reassignment. But today we write code in modules and classes. Today it's common and correct that the scope is a small function, and within its scope, it makes no sense to worry about the difference between let and const.

Because it creates completely unnecessary mental overhead:

1. The programmer has to think while writing: “Will I change this value? No? Then I must use const…”
2. It distracts readers! When they see const in the code, they wonder: “Why is this a constant? Is this some important value? Does it have any significance?”
3. In a month we need to change the value and have to deal with: “Can I change const to let? Is someone relying on this?”

Simply use let and you don't have to deal with these questions at all.

It's even worse when this decision is made automatically by a linter. That is, when the linter “fixes” variables to const because it only sees one assignment. The code reader then unnecessarily wonders: “Why must these variables be constants here? Is it somehow important?” And yet it's not important – it's just a coincidence. Don't use the prefer-const rule in ESLint!

By the way, the optimization argument is a myth. Modern JavaScript engines (like V8) can easily detect whether a variable is reassigned or not, regardless of whether it was declared using let or const. So using const provides no performance benefit.

Implicit Constants

In JavaScript, there are several constructs that implicitly create constants without us having to use the const keyword:

// imported modules
import { React } from 'react';
React = something; // TypeError: Assignment to constant variable

// functions
function add(a, b) { return a + b; }
add = something; // TypeError: Assignment to constant variable

// classes
class User {}
User = something; // TypeError: Assignment to constant variable

This makes sense – these constructs define the basic building blocks of our code, and overwriting them could cause chaos in the application. That's why JavaScript automatically protects them against reassignment, just as if they were declared using const.

Constants in Classes

Classes were added to JavaScript relatively recently (in ES2015), and their functionality is still gradually maturing. For example, private members marked with # didn't arrive until 2022. JavaScript is still waiting for class constant support. For now, you can use static, but it's far from the same thing – it marks a value shared between all class instances, not an immutable one.

Conclusion

1. Don't use var – it's outdated
2. Use const for real constants at the module level
3. In functions and methods, use let – it's more readable and clearer
4. Don't let the linter automatically change let to const – it's not about the number of assignments, but about intent

When to Use NULL and When to Use an Empty String?

In theory, the difference is clear: NULL means “value is not set”, while an empty string means “value is set and is empty”. Let's look at a real example from an e-commerce site, where we have an orders table. Each order has a required delivery address and an optional billing address for cases where the customer wants to bill to a different location (typical checkbox “Bill to a different address”):

CREATE TABLE orders (
    id INT PRIMARY KEY,
    delivery_street VARCHAR(255) NOT NULL,
    delivery_city VARCHAR(255) NOT NULL,
    billing_street VARCHAR(255) NULL,
    billing_city VARCHAR(255) NULL
);

The billing_city and billing_street fields are nullable because the billing address is optional. But there's a difference between them. While a street can be legitimately empty (villages without street names) or unset (delivery address is used), the city must always be filled in if a billing address is used. So either billing_city contains a city name, or it's NULL – in which case the delivery address is used.

The Reality of Large Databases

In practice, both approaches often end up being mixed in the database. There can be several reasons:

• Changes in application logic over time (e.g., switching from one ORM to another)
• Different teams or programmers using different conventions
• Buggy data migrations when merging databases
• Legacy code that behaves differently than new code
• Application bugs that occasionally let through an empty string instead of NULL or vice versa

This leads to situations where we have a mix of values in the database and need to write complex conditions:

SELECT * FROM tbl
WHERE foo = '' OR foo IS NULL;

Even worse is that NULL behaves unintuitive when comparing:

SELECT * FROM tbl WHERE foo = ''; -- doesn't include NULL
SELECT * FROM tbl WHERE foo <> ''; -- also doesn't include NULL

-- we must use
SELECT * FROM tbl WHERE foo IS NULL;
SELECT * FROM tbl WHERE foo <=> NULL;

This inconsistency in comparison operators' behavior is another reason why it's better to use only one way of representing empty values in the database.

Why Avoid the Dual Approach

A similar situation exists in JavaScript, where we have null and undefined. After years of experience, many JavaScript developers concluded that distinguishing between these two states brings more problems than benefits and decided to use only the system-native undefined.

In the database world, the situation is similar. Instead of constantly dealing with whether something is an empty string or NULL, it's often simpler to choose one approach and stick to it. For example, Oracle database essentially equates empty strings and NULL values, thus elegantly avoiding this problem. It's one of the places where Oracle deviates from the SQL standard, but it simplifies working with empty/NULL values.

How can we achieve something similar in MySQL?

What Do We Actually Want to Enforce?

1. For required fields (NOT NULL), we want to enforce that they always contain meaningful values. That means preventing empty strings (or strings containing only spaces)
2. For optional fields (NULL), we want to prevent storing empty strings. When a field is optional, NULL should be the only representation of an “unfilled value”. Mixing both approaches in one column leads to problems with querying and JOIN operations, as we showed above.

Solution in MySQL

Historically in MySQL, it made sense to use exclusively empty strings ('') instead of NULL values. It was the only approach that could be enforced using the NOT NULL constraint. If we wanted an automatically consistent database, this was the only way.

However, there's one important case where this approach fails – when we need a unique index on the column. MySQL considers multiple empty strings as the same value, while multiple NULL values are considered different.

However, since MySQL version 8.0.16, we can use CHECK constraints and have more control over what values we allow. We can, for example, enforce that a column will either be NULL or contain a non-empty string:

CREATE TABLE users (
    id INT PRIMARY KEY,

    -- Required field - must contain some non-empty text
    email VARCHAR(255) NOT NULL UNIQUE
        CONSTRAINT email_not_empty      -- rule name
        CHECK (email != ''),

    -- Optional field - either NULL or non-empty text
    nickname VARCHAR(255)
        CONSTRAINT nickname_not_empty
        CHECK (nickname IS NULL OR nickname != '')
);

When creating a CHECK constraint, it's important to give it a meaningful name using the CONSTRAINT keyword. This way, we get a meaningful error message Check constraint ‘nickname_not_empty’ is violated instead of a generic constraint violation notice. This significantly helps with debugging and application maintenance.

The problem isn't just empty strings, but also strings containing only spaces. We can improve the CHECK constraint solution using the TRIM function:

CREATE TABLE users (
    id INT PRIMARY KEY,
    email VARCHAR(255) NOT NULL UNIQUE
        CONSTRAINT email_not_empty
        CHECK (TRIM(email) != ''),
   ...
);

Now these validation bypass attempts won't work either:

INSERT INTO users (email) VALUES ('   ');  -- all spaces

Practical Solution in Nette Framework

A consistent approach to empty values needs to be handled at the application level too. If you're using Nette Framework, you can use an elegant solution using the setNullable() method:

$form = new Form;
$form->addText('billing_street')
    ->setNullable(); // empty input transforms to NULL

Recommendations for Practice

1. At the start of the project, decide on one approach:
   • Either use only NULL for missing values
   • Or use only empty strings for empty/missing values
2. Document this decision in the project documentation
3. Use CHECK constraints to enforce consistency
4. For existing projects:
   • Conduct an audit of the current state
   • Prepare a migration script to unify the approach
   • Don't forget to adjust application logic

With this approach, you'll avoid many problems with comparing, indexing, and JOIN operations that arise from mixing NULL and empty strings. Your database will be more consistent and queries simpler.

Imagine a typical scenario: You have an orders table in your database with a status column of type ENUM. It contains the values waiting_payment, processing, shipped, and cancelled. The requirement is to rename waiting_payment to unpaid and shipped to completed. How can this be done without risk?

What Doesn't Work

First, let's look at what does not work. Many developers try this straightforward approach:

-- THIS DOES NOT WORK!
ALTER TABLE orders
MODIFY COLUMN status ENUM(
    'unpaid',      -- previously 'waiting_payment'
    'processing',  -- unchanged
    'completed',   -- previously 'shipped'
    'cancelled'    -- unchanged
);

This approach is a recipe for disaster. MySQL will attempt to map existing values to the new ENUM, and since the original values are no longer in the definition, it will either replace them with an empty string or return the error Data truncated for column 'status' at row X. In a production database, this would mean losing important data.

Backup First!

Before making any structural changes to your database, it is absolutely crucial to create a data backup. Use MySQL-dump or another trusted tool.

The Correct Approach

The correct approach consists of three steps:

1. First, extend the ENUM with new values.
2. Update the data.
3. Finally, remove the old values.

Let's go through it step by step:

1. The first step is to add the new values to the ENUM while keeping the original ones:

ALTER TABLE orders
MODIFY COLUMN status ENUM(
    'waiting_payment',  -- original value
    'processing',       -- unchanged
    'shipped',         -- original value
    'cancelled',       -- unchanged
    'unpaid',          -- new value (replaces waiting_payment)
    'completed'        -- new value (replaces shipped)
);

2. Now we can safely update the existing data:

UPDATE orders SET status = 'unpaid' WHERE status = 'waiting_payment';
UPDATE orders SET status = 'completed' WHERE status = 'shipped';

3. Finally, once all data has been converted to the new values, we can remove the old ones:

ALTER TABLE orders
MODIFY COLUMN status ENUM(
    'unpaid',
    'processing',
    'completed',
    'cancelled'
);

Why Does This Work?

This works because of how MySQL handles ENUM values. When performing an ALTER TABLE modification on an ENUM column, MySQL tries to map existing values based on their textual representation. If the original value does not exist in the new ENUM definition, MySQL will either throw an error (if STRICT_ALL_TABLES is enabled in sql_mode) or replace it with an empty string.

That's why it's crucial to have both old and new values present in the ENUM simultaneously during the transition phase. In our case, this ensures that every record in the database retains its exact textual equivalent. Only after executing the UPDATE queries – when we are sure that all data is using the new values – can we safely remove the old ones.

Property hooks provide a smart way to define what happens when you read from or write to object properties – and they're much cleaner and more efficient than the traditional magic methods __get/__set. Think of it as getting all the power of magic methods without any of their usual drawbacks.

Let's look at a real-world example that shows why property hooks are so valuable. Consider a common Person class with a public age property:

class Person
{
	public int $age = 0;
}

$person = new Person;
$person->age = 25;  // OK
$person->age = -5;  // OK, but that makes no sense!

While PHP ensures the age will be an integer thanks to the int type (available since PHP 7.4), what about that negative age? In the past, we'd need getters and setters, make the property private, and write a bunch of boilerplate code. With hooks, there's a much more elegant solution:

class Person
{
	public int $age = 0 {
		set => $value >= 0 ? $value : throw new InvalidArgumentException;
	}
}

$person->age = -5;  // Oops! InvalidArgumentException warns us about the invalid value

The beauty lies in its simplicity – from the outside, the property behaves exactly like before. You can read and write directly through $person->age, but now you have complete control over what happens during the write operation. And that's just scratching the surface!

We can take it further and create hooks for reading too. Hooks can have attributes, and they can contain complex logic beyond simple expressions. Check out this example of working with names:

class Person
{
	public string $first;
	public string $last;
	public string $fullName {
		get {
			return "$this->first $this->last";
		}
		set(string $value) {
			[$this->first, $this->last] = explode(' ', $value, 2);
		}
	}
}

$person = new Person;
$person->fullName = 'James Bond';
echo $person->first;  // outputs 'James'
echo $person->last;   // outputs 'Bond'

Here's something crucial to understand: hooks are always used whenever a property is accessed (even within the Person class itself). The only exception is when you directly access the actual variable inside the hook code.

A Blast from the Past: Lessons from SmartObject

For those familiar with Nette Framework, here's an interesting historical perspective. The framework offered similar functionality 17 years ago through SmartObject, which significantly enhanced object handling at a time when PHP was quite limited in this area.

I remember the initial wave of overwhelming enthusiasm where developers used properties everywhere, followed by a complete reversal where they avoided them entirely. Why? There weren't clear guidelines about when to use methods versus properties. But today's native solution is in a different league altogether. Property hooks and asymmetric visibility are fully-fledged tools that provide the same level of control as methods. This makes it much easier to determine when a property is truly the right choice.

Backed or Virtual? The Key Question!

Take a look at this code and try to answer quickly – it's a little quiz:

• Can we write to $age?
• What about $adult – can we both read and write to it?

class Person
{
	public int $age = 0 {
		set => $value >= 0 ? $value : throw new InvalidArgumentException;
	}

	public bool $adult {
		get => $this->age >= 18;
	}
}

As we discussed earlier, $age is both readable and writable. But surprise – $adult is read-only!

This brings us to the first tricky aspect of property hooks design. The property signature doesn't tell us whether we can read from or write to it!

The answer lies hidden in the hook implementation code. Properties come in two flavors: backed (with actual memory storage) and virtual (which only simulate a property's existence). What determines if a property is backed or virtual? It's whether we reference it in the hook code.

A property is backed (has its own storage) when:

• we reference it in the hook body using $this->propertyName
• or it has a shortened set, which implicitly means writing to $this->propertyName

Looking at our example:

• Property $age is backed because it uses the shortened set (which implicitly writes to $this->age)
• Property $adult is virtual because none of its hooks uses $this->adult

While this is a clever solution, it's not ideal. Such crucial information about whether a property is readable or writable should be immediately visible in the API and signature, not buried in the implementation details.

References: Playing it Safe

References have been a part of PHP since its early days. Using the & symbol, you can link two variables so they point to the same memory location. It's like having two remote controls for one TV – press either one, and you're controlling the same screen.

But what if someone could get a reference to a property with a set hook? They could modify its value directly, completely bypassing all validation. Here's what that might look like:

class Person
{
	public int $age = 0 {
		set => $value >= 0 ? $value : throw new InvalidArgumentException;
	}
}

$person = new Person;
$ref = &$person->age;    // Fatal error: This isn't allowed!
$ref = -5;               // If it worked, it would make our validation useless

PHP (or more specifically, Ilija Tovilo and Larry Garfield, the hook feature's authors) thought this through and came up with an elegant solution. It's simply impossible to get a reference to such a property (specifically, to a backed variable with a set hook). This makes perfect sense – property hooks ensure that only valid values can be stored, and references would provide a backdoor around this protection.

Arrays Meet Property Hooks – An Interesting Challenge!

Working with arrays in PHP is usually straightforward and intuitive. We can add elements to an array property in several ways:

class Person
{
	public array $phones = [];
}

$person = new Person;
$person->phones[] = '777 123 456';          // adds number to the end of array
$person->phones['bob'] = '777 123 456';     // adds number with specific key

Here's where we run into an interesting challenge with property hooks. Say we want to create a Person class that contains a list of phone numbers, and we want to automatically trim whitespace from the beginning and end of each number:

class Person
{
	public array $phones = [] {
		set => array_map('trim', $value);
	}
}

$person = new Person;
$person->phones[] = '777 123 456';  // Surprise! Error: Indirect modification of Person::$phones is not allowed

So why doesn't this work? The operation $person->phones[] in PHP actually happens in two steps:

1. First, it gets a reference to the array through get
2. Then it adds the new value to that array

This means the set hook never gets called. What's more, as we learned earlier, we can't get a reference to a backed variable with a set hook (that first step). That's why we get the error message.

Even creating a method like addPhone() that calls $this->phones[] = $phone won't help – remember, all property access (even within the class) goes through hooks.

So what's the solution? Let's explore our options. Here's the first approach that might come to mind:

$phones = $person->phones;    // read the array
$phones[] = ' 777 123 456 ';  // add a number
$person->phones = $phones;    // save it back

Sure, it works, but… imagine having an array with thousands of numbers. Our set hook would need to run trim() on every single number again, even though we only added one. Not exactly efficient, right?

There's a better way – we need to realize that if an array needs special handling of its elements (like trimming whitespace), that should be its responsibility, not the job of the class that just happens to hold it. While we can't teach new tricks to a basic array, we can “wrap” it in an object that implements ArrayAccess:

class Phones implements ArrayAccess
{
	private array $data = [];

	public function __construct(array $data = [])
	{
		$this->data = array_map('trim', $data);
	}

	public function offsetSet(mixed $offset, mixed $value): void
	{
		$value = trim($value);
		if ($offset === null) {
			$this->data[] = $value;
		} else {
			$this->data[$offset] = $value;
		}
	}

	// implementation of other ArrayAccess methods...
}

class Person
{
	function __construct(
		public Phones $phones = new Phones,
	) {}
}

$person = new Person;
$person->phones[] = ' 777 123 456 ';  // Perfect! The number is stored with whitespace trimmed

And here's the cherry on top – we can use a hook to allow writing a regular array to $person->phones:

class Person
{
	function __construct(
		public Phones $phones = new Phones {
			set(array|Phones $value) => is_array($value) ? new Phones($value) : $value;
		},
	) {}
}

$person = new Person;
$person->phones = ['  888 999 000  ', '777 888 999'];  // Automatically converts to Phones and trims strings

As you can see, hooks work with promoted properties too.

Let's look at another approach. Remember that besides backed properties, we also have virtual properties – those that don't use $this->propertyName in their hook body. This gives us another solution:

class Person
{
	private array $_phones = []; // actual storage for phone numbers

	public array $phones {  // virtual property for public access
		get => $this->_phones;
		set {
			$this->_phones = array_map('trim', $value);
		}
	}

	public function addPhone(string $phone): void
	{
		$this->_phones[] = trim($phone);
	}
}

$person = new Person;
$person->addPhone(' 777 123 456 ');  // Adds trimmed number
echo $person->phones[0];             // Shows "777 123 456"
$person->phones = ['  888 999 000  ']; // Sets new array with trimmed numbers

In this approach, we stick with a regular array but hide it behind a private variable. To the outside world, we offer a virtual property for reading the entire array and completely replacing it, plus a dedicated method for adding individual numbers.

Hooks and Inheritance: Passing the Torch

Children classes can not only add hooks to properties that didn't have them before but also redefine existing ones. Here's an example:

class Person
{
	public string $email;

	public int $age {
		set => $value >= 0
			? $value
			: throw new InvalidArgumentException('Age cannot be negative');
	}
}

class Employee extends Person
{
	// Adds hook to property that previously had none
	public string $email {
		set => strtolower($value);  // Always convert emails to lowercase
	}

	// Extends existing age validation
	public int $age {
		set {
			if ($value <= 130) {  // First check the original condition
				throw new InvalidArgumentException('130 years? Not buying it!');
			}
			parent::$age::set($value);
		}
	}
}

Notice that interesting syntax parent::$age::set($value). While it might look unusual at first, it makes perfect sense – we first reference the property in the parent class, then its hook. It's like saying “hey, call the set hook on my parent's age property”.

And there's more – we can mark hooks as final if we want to prevent children from overriding them. We can even mark the entire property as final – then children can't modify it in any way (neither add hooks nor extend its visibility).

class Person
{
	// No one can override this hook
	public int $age {
		final set => $value >= 0 ? $value : throw new InvalidArgumentException;
	}

	// And no one can modify this property at all
	final public string $id;
}

Properties in Interfaces: A Game Changer

One of the most exciting new features is support for properties in interfaces and abstract classes. Imagine you're creating an interface for entities that contain a name string. Previously, we had to write something like this:

interface Named
{
	public function getName(): string;
	public function setName(string $name): void;
}

Pretty tedious, right? With property hooks, we can be much more elegant! We can now declare properties directly in the interface, and even do it asymmetrically – specifying separately what should be

interface Named
{
	// We're declaring: "Any implementing class must provide a publicly readable name property"
	public string $name { get; }
}

Now here's the interesting part – how do we implement such an interface? We have several elegant options:

class Person implements Named
{
	public string $name;     // Simplest approach - a regular property
}

class Employee implements Named
{
	public string $name {    // More sophisticated - composite name
		get => $this->firstName . ' ' . $this->lastName;
	}
	private string $firstName;
	private string $lastName;
}

Notice something interesting – while the Named interface only requires a read-only property, the Person class provides one that's both readable and writable. This is perfectly fine – interfaces define minimum requirements. It's like ordering a car that “must drive forward” and getting one that can also reverse – it exceeds the minimum requirements in a useful way.

A technical note for the detail-oriented: In interfaces, we must use the public keyword with properties, even though it's redundant since everything in an interface is inherently public. While using public with methods would be redundant, it's required for properties to maintain syntax consistency.

Here's another interesting detail – did you notice that unusual { get; set; } syntax? While in a class we can simply write public string $name, interfaces require us to explicitly state which operations the property supports. Though it requires more typing, this makes sense – with interfaces, we want to be crystal clear about our requirements.

Properties in Abstract Classes: Getting the Best of Both Worlds

Abstract classes combine the best features of interfaces with their own special capabilities. They can not only declare properties but also provide default implementations for some hooks:

abstract class Person
{
	// Pure abstract property - child must implement
	abstract public string $name { get; }

	// Protected property supporting both operations
	abstract protected int $age { get; set; }

	// Here we provide ready-made email validation
	abstract public string $email {
		get; // this hook is abstract and must be implemented by child
		set => Nette\Utils\Validators::isEmail($value)
			? $value
			: throw new InvalidArgumentException('This doesn\'t look like a valid email...');
	}
}

Covariance and Contravariance: Not as Scary as They Sound!

These terms might sound intimidating, but the concept is actually quite straightforward. Let's look at an example:

class Animal {}
class Dog extends Animal {}

interface PetShop
{
	// Read-only property can return a more specific type
	public Animal $pet { get; }
}

class DogShop implements PetShop
{
	// Returns a dog instead of an animal - perfectly valid!
	public Dog $pet { get; }
}

When a property has only a get hook, it can return a more specific type in the child class (this is called covariance). Think of it this way: “I promised you an animal, and a dog is definitely an animal, right?”

On the flip side, a property with only a set hook can accept a more general type in the child (contravariance). This makes sense – if you can handle a specific type, you can handle its parent type too.

However, when a property has both get and set hooks, the type must stay the same. Why? Because it could lead to inconsistencies – we can't promise to return a dog when someone might try to set a cat through the setter!

Asymmetric Visibility: Fine-Tuned Access Control

Imagine you're building a Person class where you want everyone to be able to read the date of birth, but only the class itself should be able to change it. In the past, this meant getters and setters, but now we have an elegant solution:

class Person
{
	public private(set) DateTimeImmutable $dateOfBirth;
}

This elegant syntax says: “Anyone can read it, but only the class itself can write to it.” The first modifier public controls read access, while private(set) controls write access. Since public reading is the default, we can make it even simpler:

class Person
{
	private(set) DateTimeImmutable $dateOfBirth;
}

Naturally, there's a logical rule – write visibility can't be broader than read visibility. You can't use something like protected public(set) – that would be like saying “only descendants can read it, but anyone can write to it.” Doesn't make much sense, right?

What about inheritance? In PHP, a child class can either keep the same visibility or expand it from protected to public. The same principle applies to asymmetric visibility:

class Person
{
	public protected(set) string $name;  // Anyone can read, only descendants can write
}

class Employee extends Person
{
	public public(set) string $name;     // Child expands writing rights
}

An interesting case is private(set). Such a property is automatically final – when we say only the class itself can write to it, that logically means not even child classes can change this behavior.

Best of all, we can combine asymmetric visibility with hooks:

class Person
{
	private(set) DateTimeImmutable $birthDate {
		set => $value > new DateTimeImmutable
			? throw new InvalidArgumentException('Birth in the future? Nice sci-fi!')
			: $value;
	}
}

This property has it all: it's publicly readable, only the class itself can write to it, and it validates that the date isn't in the future. Hooks handle “what should happen,” while asymmetric visibility controls “who can do it.” A perfect combination!

Asymmetric Visibility and Arrays: A Smart Solution to an Old Problem

Remember our phone number challenge? Asymmetric visibility offers us another elegant solution:

class Person
{
	private(set) array $phones = [];

	public function addPhone(string $phone): void
	{
		$this->phones[] = trim($phone);
	}
}

$person = new Person;
var_dump($person->phones);     // OK: we can read the array
$person->addPhone('...');      // OK: we can add a number
$person->phones = [];          // ERROR: we can't overwrite the entire array

The array is publicly readable, but no one from outside can overwrite it. We provide a specialized method for adding new numbers. No complex array-simulating objects, no virtual properties – just clean, clear access control.

It's worth noting that you can't get a reference from outside to a property with restricted write access:

$ref = &$person->phones;    // Fatal error: Not allowed!

References are only allowed from scopes where the property is writable. This makes sense – a reference could bypass our write restrictions.

To summarize, we now have four solid approaches for working with arrays in properties:

1. Smart object simulating an array (offers more features but requires more code)
2. Backed property with hook (prevents direct array modification)
3. Virtual property with private storage (requires methods for modifications)
4. Asymmetric visibility (moves logic to methods)

Which approach should you choose? As with many things in programming – it depends on your specific needs. Try them out and see which API feels most natural for your use case.

Readonly and Asymmetric Visibility: Freedom at Last!

The readonly modifier actually combines two features: it prevents multiple writes and restricts writing to private scope. It's not really “readonly” – it's more like “writeonce” combined with private(set).

The second part always felt unnecessarily restrictive. Why shouldn't a readonly property be writable in child classes?

PHP 8.4 finally addresses this. Now readonly makes properties protected(set) by default, meaning they're writable in child classes too. And if we need different visibility? We can simply specify it:

class Person
{
	// Readonly accessible only inside the class (old behavior)
	public private(set) readonly string $name;

	// Readonly accessible in children (new default behavior)
	public readonly string $dateOfBirth;

	// Readonly writable anywhere (but only once!)
	public public(set) readonly string $id;

	public function rename(string $newName): void
	{
		$this->name = $newName;    // Inside class we can modify it
	}
}

class Employee extends Person
{
	public function setBirthDate(DateTimeImmutable $date): void
	{
		$this->dateOfBirth = $date;  // In child class we can modify it
	}
}

$person = new Person;
$person->id = 'abc123';     // This works
$person->id = 'xyz789';     // But this FAILS - it's readonly!

This gives us exactly the flexibility we need while maintaining safety.

When Terminology Clashes…

Let's examine an interesting inconsistency in PHP's terminology:

• We consistently talk about reading and writing properties
• We have the readonly modifier
• In phpDoc, we find @property-read and @property-write annotations
• Yet, in hooks and asymmetric visibility, we suddenly switch to get/set

Wouldn't using read and write terms make more logical sense?

For hooks, the use of get/set is somewhat understandable – they represent actions and align with the __get/__set magic methods. But for asymmetric visibility? That's an entirely different concept – it's not about “what should happen” like hooks, but rather “who has permission to do it”. This is why using the term write, as in private(write), would make much more sense:

class Person
{
	private(set) string $name;     // current syntax
	private(write) string $name;   // more intuitive syntax
}

The second version would feel more natural. Moreover, it would better align with the existing readonly modifier.

It appears that in PHP's pursuit of syntactic consistency between hooks and asymmetric visibility, they inadvertently sacrificed semantic consistency with the language's existing concepts.

A New Era in PHP: The Object Design Revolution

For years, the PHP world adhered to a single “correct” approach to object-oriented design: make all properties private and access them exclusively through getters and setters. This wasn't just developers being fussy – public properties came with genuine problems:

• They were completely exposed with no access control
• As part of the public API, any modification (like adding validation) would break backward compatibility
• In interfaces, they could only exist as comments

Anyone wanting to write robust code using interfaces and dependency injection had no choice but to fall back on getters and setters. It was the only path to maintaining full control over object behavior.

But PHP 8.4 ushers in a new era! Property hooks and asymmetric visibility finally give us the same level of control over properties that we've always had with methods. Properties now become first-class citizens in the public API because:

• We can introduce validation or value transformation whenever needed
• We have fine-grained control over access permissions
• We can properly declare them in interfaces

You can think of property hooks as an elegant, boilerplate-free replacement for getters and setters. Or perhaps more accurately – getters and setters were just a stopgap until PHP evolved to something better.

Speaking from extensive experience with Nette, where similar functionality has existed for 17 years, I can attest to how game-changing this approach is. Once you try it, there's no going back. Consider this comparison:

// Traditional approach
$this->getUser()->getIdentity()->getName()

// Modern approach
$this->user->identity->name

The second version isn't just more concise and readable – it feels more natural. It's like the difference between formally asking “Would you be so kind as to provide me with your name?” versus simply asking “What's your name?”

Sure, some might argue that direct property access could tempt developers to violate object-oriented principles, suggesting we should tell objects what to do rather than ask for data (Tell-Don't-Ask). That's valid – but primarily for objects with rich behavior implementing business logic. For data transfer objects, value objects, or configuration classes, direct data access makes perfect sense.

This does present an interesting challenge: what about existing projects? If your library or framework consistently uses getters and setters, suddenly introducing properties might create inconsistency. Users would need to guess whether to use a method or a property in each case.

Over time, new conventions will emerge. Some projects may stick with getters and setters, while others will embrace properties. The key is that we now have options.

Naming Matters

How should we name our properties? With boolean values especially, it's not as straightforward as you might think.

With methods, we commonly use prefixes like is or has:

class Article {
	public function isPublished(): bool { ... }
	public function hasComments(): bool { ... }
}

But for properties, these prefixes feel awkward and redundant. A better approach is to use adjectives or nouns:

class Article {
	public bool $published;     // better than $isPublished
	public bool $commented;     // better than $hasComments
	public bool $draft;         // better than $isDraft
}

if ($article->published) {      // reads naturally
	// ...
}

For quantities, plural forms work better:

class Article {
	public int $views;          // better than $viewCount
	public array $tags;         // clearly indicates a collection
}

The goal is to make your code read like natural language. When we write if ($article->published), it flows much more naturally than if ($article->isPublished). Properties should feel like attributes, not methods missing their parentheses.

When to Choose Properties vs Methods?

This is a crucial question! We can learn from languages like C# and Kotlin, which have years of experience with properties. Properties excel for:

Value objects and DTOs:

class Money {
	public readonly float $amount;
	public readonly string $currency;
}

Simple entities:

class Article {
	public string $title;
	public string $content;
	public DateTimeImmutable $publishedAt;
	public bool $published {
		get => $this->publishedAt <= new DateTimeImmutable;
	}
}

Computed values that depend on other properties:

class Rectangle {
	public float $width;
	public float $height;
	public float $area {
		get => $this->width * $this->height;
	}
}

Methods are better suited for:

• operations that work with multiple properties together
• operations with side effects (logging, notifications)
• actions that perform tasks (save, send, calculate…)
• complex validations or business logic
• operations that might fail for various reasons
• cases where you want a fluent interface

All these guidelines point to one fundamental principle: property access shouldn't hide complex processes or side effects. The complexity of the operation should match what we intuitively expect when reading or writing to a variable.

Though… consider innerHTML in JavaScript. When you write element.innerHTML = '<p>Hello</p>', it triggers a complex chain of events – HTML parsing, DOM tree creation, page reflow… Yet everyone finds this natural!

So perhaps what matters more than implementation complexity is whether the operation _conceptually_ feels like a property. It's similar to a car's start/stop button – it might trigger a complex sequence internally, but to the driver, it's simply “on/off”.

No More Variable Leaking from {foreach}

This has bugged me for years. You write {foreach $items as $item}, the loop ends, and $item happily lives on with the value of the last element. Worse, it can overwrite a variable you were counting on:

{var $name = 'Yay'}

{foreach $users as $name}
    ...
{/foreach}

{$name} {* oops, no longer 'Yay' *}

Latte has long warned you when foreach overwrote a variable passed to the template via parameters. But variables created directly in the template, e.g. via {var}, were overwritten silently. And that's the sneaky case.

Now you can fix it with a single setting:

$latte->setFeature(Latte\Feature::ScopedLoopVariables);

Variables from {foreach} now exist only inside the loop. After the loop ends, the original value is restored. And if the variable didn't exist before? It disappears completely.

{var $name = 'Yay'}

{foreach $users as $name}
    ...
{/foreach}

{$name} {* outputs 'Yay', yay! *}

And the old warning about overwritten parameters? It gets disabled with this feature, because it no longer makes sense – nothing gets overwritten anymore.

It works with destructuring {foreach $data as [$a, $b]} and of course with keys {foreach $arr as $k => $v} – everything is cleaned up after the loop. Nested loops have independent scopes.

The only exception: if you iterate by reference {foreach $arr as &$v}, scope doesn't apply – references directly modify the original array, so restoring values after the loop would break them. Makes sense.

Indent Your Templates However You Like

You know the drill: you have a <ul> with a {foreach} inside generating <li>. You naturally indent it for readability. But that indentation bleeds into the output. Either you have clean code and ugly HTML, or the other way around.

Unacceptable.

With Feature::Dedent, this dilemma disappears:

$latte->setFeature(Latte\Feature::Dedent);

Latte automatically removes the common indentation inside paired tags. So this:

<ul>
    {foreach $items as $item}
        <li>{$item}</li>
    {/foreach}
</ul>

generates:

<ul>
    <li>...</li>
    <li>...</li>
</ul>

The indentation is gone as if it was never there.

And since dedent is performed at template compilation time, not during each render, it has zero performance impact. It works for all paired tags – {if}, {block}, {capture}, {foreach} and more. Nested tags are dedented independently, each at its own level.

If the indentation is inconsistent – for instance, you mix tabs with spaces, or a line doesn't have sufficient indentation – Latte throws a CompileException with the exact line number. No silent swallowing of errors.

Filter |commas

Joining an array into a comma-separated string – easy. But what if you want “and” instead of a comma before the last element? That's exactly the kind of thing where you start writing conditions in the template and suddenly you have four lines of code instead of one. And all you wanted to say was “apple, pear and plum”.

{['apple', 'pear', 'plum']|commas}        {* apple, pear, plum *}
{['apple', 'pear', 'plum']|commas:' and '} {* apple, pear and plum *}
{['apple', 'pear', 'plum']|commas:', or '} {* apple, pear, or plum *}

Without a parameter, it joins with a comma and space. With a parameter, it uses the given string as the separator between the last two elements – the rest stays comma-separated. Natural language, not foreach.

Filter |column

You have an array of user records, say [['id' => 1, 'name' => 'John'], ['id' => 2, 'name' => 'Jane'], ...], and you need just the names? The |column filter extracts values from a single column – whether it's an array key or an object property:

{$users|column:'name'|commas}   {* John, Jane, Bob *}

It optionally accepts a second parameter for indexing the results:

{foreach ($users|column:'name':'id') as $id => $name}
    {$id}: {$name}
{/foreach}

It works with iterators too, not just arrays – however, the iterator is internally converted to an array, so don't expect any lazy magic.

Filter |slice for Iterators and New Filter |limit

The |slice filter extracts a portion of an array or string (with full UTF-8 support for strings). Until now, it only worked with arrays and strings. Now it also handles iterators and generators – it returns a generator that reads elements from the source one by one and stops once the limit is reached. The entire iterator is never loaded into memory:

{foreach ($generator|slice:0:10) as $item}
    {$item}
{/foreach}

On top of that, there's a new filter |limit – a more convenient variant for the typical case of “take the first N elements”. It works with arrays, iterators, and strings (with UTF-8 support):

{foreach ($items|limit:5) as $item}
    {$item}
{/foreach}

{$description|limit:100}

The difference from |slice is that |limit preserves the original keys by default.

How to Enable

The new features ScopedLoopVariables and Dedent are enabled via setFeature():

$latte = new Latte\Engine;
$latte->setFeature(Latte\Feature::ScopedLoopVariables);
$latte->setFeature(Latte\Feature::Dedent);

And if you're using Nette, just enable them in the configuration:

latte:
    scopedLoopVariables: true
    dedent: true

Five small things for life.

Chapter 1: The Perfect Crime

This case has been haunting me for fourteen years.

It started in 2012. Nette Tester had just unlocked the secret of multi-threaded testing. Eight threads working in perfect harmony by default, like a well-conducted orchestra. It was a pioneer—back when other libraries were running tests one by one like pensioners at the post office, Tester was already parallelizing. Sixty seconds of tests compressed into ten. Beautiful. Elegant.

But from day one, there was a shadow.

The first reports came from Windows users. Tests that flew on Linux were crawling on Windows. Not walking—crawling. On their bellies. Through broken glass.

Linux: 3 seconds. Windows: 21.6 seconds.

Someone was murdering parallelism. And they were doing it in broad daylight.

Chapter 2: The Suspects

I opened the case file and started from the basics.

When Tester runs a test, it spawns a new PHP process. This process runs independently and writes its results to standard output—stdout. But how does the main program get those results? Through a pipe. An invisible tube between processes, through which data flows like water.

On Linux, this pipe is smart. When it's empty, you say “give me data” and it replies “got nothing” and you move on. No waiting. No delays.

But on Windows?

I tried everything. First suspect was stream_set_blocking()—supposed to switch the pipe to non-blocking mode.

Didn't work.

Next up was stream_select()—should monitor multiple pipes at once and tell you which one has data.

Dead too.

Finally, I tried plain old fread(). On Linux, reading from an empty pipe returns nothing immediately. On Windows? It waits. Waits until something arrives. Could be forever.

Three functions. Three corpses. Someone had killed non-blocking I/O years ago. A crime so old, the chalk outline had long faded.

Chapter 3: The Blockade

Picture this:

Eight threads enter a bar. The first one orders — he overdoes it with shots and gives sleep(3). Nothing unusual. Even a test needs its beauty sleep sometimes.

But then it gets interesting.

You want to read the output from that first test. You reach into the pipe. But there's no output—the test is sleeping, not printing anything. And on Windows, when you read from an empty pipe…

You wait.

You wait until the test wakes up. Frozen mid-motion with your hand in the pipe. The other threads stare at you. “Hello? You okay?” But you've started reading and you can't stop. Seven threads poke at you: “Hey, can we go? We've got tests to run!” But you can't do anything. Inside, you're cursing yourself—if you'd picked a different test, you could be mingling with the others right now, working, being useful. But no. You picked the sleeper and now you're its hostage.

Three seconds of silence. Then the test wakes up, spits out its output, and you can finally let go.

Eight threads. One stuck. Seven shuffling and waiting.

Twenty-one point six seconds instead of three.

This wasn't murder. This was torture.

Chapter 4: Files

My job was to solve this problem.

Every detective has that moment. A flash of brilliance. The feeling that you've finally cracked it. Mine came at 2 AM over cold coffee and frozen code.

“Files,” I whispered. “We'll write to files.”

A pipe is like a phone line—you have to listen when someone's talking, or you miss it. But a file? A file is like an answering machine. The test writes what it needs, and you read it when you have time. No waiting. No freezing.

proc_open($cmd, [
    ['pipe', 'r'],
    ['file', $tempFile, 'w'],  // Here it is!
    ...
]);

No pipes. No blocking. The test writes to a file, we read it when it's done. Clean. Simple. Genius.

27 seconds.

Twenty. Seven. Seconds.

I measured everything:

• proc_open(): 2 ms. Innocent.
• proc_get_status(): 4 ms per thousand calls. Clean too.
• File read + delete: Under 10 ms. Nothing suspicious.

And yet the result was catastrophic.

I stared at those numbers until my eyes watered. Individual operations fine. The whole thing a disaster. How was this possible?

Then it hit me. Eighty-five tests. Eighty-five temp files. Eighty-five creates, writes, reads, and deletes. Each operation fast, but Windows filesystem works differently than Linux. NTFS journaling. Antivirus scanning every new file like a nervous border agent. And those milliseconds add up.

Death by a thousand cuts. Slow but certain.

Chapter 5: The Gamble

I was running out of ideas. And coffee.

Then something occurred to me. Something dangerous. The kind of idea that usually gets detectives killed in the third act.

What if we just didn't read the output right away?

The thought was simple: test is running, we leave it alone. Don't touch the pipe, don't wait, don't block. When the test finishes—when it *leaves the bar*—only then do we read what it wrote. Until then, we take care of the other threads. Work. Live.

if ($status['running']) {
    if (PHP_OS_FAMILY !== 'Windows') {
        // On Linux we read continuously, it works there
        $this->test->stdout .= stream_get_contents($this->stdout);
    }
    // On Windows? Don't read. Don't touch. Don't even breathe near the pipe.
    return true;
}

I implemented it. Held my breath. Ran the tests.

3 seconds.

Three. Seconds.

Just like Linux. Just like the good old days. I wanted to cry with joy. Dance. Run up to the roof and—

The phone rang.

“We have a problem,” said the voice. “Some tests just won't finish. Hanging there like laundry.”

My heart stopped.

“Which ones?”

“The ones with lots of output. Tons of echo statements. They write and write, and then—nothing. Silence. Forever.”

I closed my eyes. Of course. How could I forget.

The pipe buffer. Four kilobytes on Windows. A pipe isn't bottomless—it's a tube with limited capacity. When a test writes and writes and nobody reads, the buffer fills up. And when the buffer is full, the test freezes mid-write. Waiting for someone to make room. But we're not reading. We're waiting for the test to finish. It's waiting for us.

Deadlock.

A classic trap. Two people waiting for each other at a doorway: “After you.”—“No, after you.”—Forever.

We'd traded one killer for another.

Chapter 6: Last Attempts

The next forty-eight hours were a blur of caffeine and increasingly desperate ideas.

Timeout:

stream_set_timeout($this->stdout, 0, 1000); // 1ms timeout
$this->test->stdout .= fread($this->stdout, 8192);

Result: 18.5 seconds. Better. But still blocking. The timeout was just a polite request that Windows wiped its ass with.

Metadata check:

$meta = stream_get_meta_data($this->stdout);
if (!empty($meta['unread_bytes'])) {
    // Only read when there's something!
}

Result: unread_bytes was always zero. Always. Even when there was data. Even when there were megabytes. Windows was lying straight to our faces.

I slammed my fist on the desk.

Every lead hit a wall. Every piece of evidence crumbled in my hands. Every solution fixed one problem and created another. Like playing chess against an opponent who redraws the board after every move.

Chapter 7: The Truth

They don't teach you this in detective school:

Sometimes you don't catch the killer.

Sometimes the killer is the system itself. Hardcoded into the foundation. A decision someone made in Redmond twenty years ago. A person who never imagined PHP processes would want to communicate without waiting.

Windows simply doesn't support non-blocking I/O on anonymous pipes. Period. End of story. Case closed.

But then I found an informant. The kind who operates in the gray zone of documentation.

An undocumented socket descriptor. ['socket'] instead of ['pipe', 'w']. PHP can create a TCP socket pair instead of a pipe. And stream_select() works on sockets. Even on Windows.

proc_open($cmd, [
    ['pipe', 'r'],
    ['socket'],  // Secret weapon!
    ['socket'],
]);

I ran the tests. Held my breath.

Three seconds.

Three seconds on Windows. Just like Linux. I wanted to scream. All eight threads working simultaneously. No blocking. No waiting. Finally, I felt that “Linux feeling” on Windows.

But then I noticed something strange.

Some tests reported empty output. Where there should have been hundreds of lines, there was nothing. As if the witness had forgotten half their testimony.

I ran the tests again. And again. Out of a hundred runs, seventy were fine. Thirty had lost output. No pattern. No logic. Pure chance.

I found the answer on php.net. Comment #128252.

“Passing a socket handle for stdout/stderr on Windows causes the last chunk(s) of output to occasionally get lost…”

And then the sentence that finished me off:

“This is actually a known bug in Windows itself and Microsoft's response was that CreateProcess() only officially supports anonymous pipes and file handles… other handle types will produce ‘undefined behavior.’”

Undefined behavior. Police jargon for “not our jurisdiction.”

The socket was a witness with a leaky memory. Fast, willing, but sometimes just forgot what it saw. And I couldn't risk thirty percent of the evidence vanishing like tears in rain.

I closed that lead. Another dead end.

Epilogue: The Bitter End

I lit a cigarette I don't smoke and stared out the window at rain that wasn't falling.

The case file sits on my desk. Unsolved. The current implementation—don't read while running—is fast as lightning, but carries a bomb in its pocket. Any test that dares to output more than 4 KB will freeze forever. Trapped in a digital limbo of its own making.

I closed the file.

Not every case has a happy ending. Not every killer ends up behind bars. And some operating systems just are what they are —no matter how many nights you spend on Stack Overflow or how many Microsoft engineers you curse.

Parallelism on Windows is dead. Long live parallelism.

Case closed. The killer is still out there. Sleep well.

I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate. And I've seen PHP try to do non-blocking I/O on Windows pipes. All those moments will be lost in time. Like tears in rain.

— Roy Batty, if he'd been a PHP developer

Update: January 2026

The phone rang.

I'd filed the case away long ago. Unsolved cases. Sometimes I look at it, dust it off, shake my head. Some crimes just go unpunished.

“We have news,” said the voice. “PHP 8.5. Check out stream_select().”

I couldn't believe my eyes. Someone on the PHP core team—some Christoph from Germany—had fixed a twenty-year-old problem.

PeekNamedPipe(). Such a simple concept. Before you reach into the pipe, you peek first. Is something there? Yes—read it. No—move on. No waiting. No blocking.

// PHP 8.5+: stream_select() finally works on Windows pipes
while (stream_select($read, $w, $e, 0, 0) > 0) {
    $output .= fread($pipe, 8192);
}

I ran the tests.

Three seconds. No blocking. No deadlock. All data accounted for.

I pulled the file from the archive. On the cover I wrote: SOLVED. January 2026.

Twenty years. Twenty years that bug waited in the foundations of PHP, like a time bomb nobody knew how to defuse. And then someone came along who simply knew where to look.

Not every case ends in a dead end. Sometimes, just sometimes, a cold case heats up. And dead witnesses find their voice.

Case closed. For real this time.

In Nette Framework 3.2.9, a neat little feature was introduced: the #[TemplateVariable] attribute. Simply mark a presenter property with this attribute (it can't be private), and it automatically becomes available in your template under the same name:

<?php
declare(strict_types=1);

namespace App\Presentation\Article;

use Nette\Application\Attributes\TemplateVariable;
use Nette\Application\UI\Presenter;

final class ArticlePresenter extends Presenter
{
	#[TemplateVariable]
	public string $siteName = 'My blog';

	#[TemplateVariable]
	public ?Model\Article $article = null;

	public function actionShow(int $id): void
	{
		$this->article = $this->articleFacade->getById($id);
	}
}

In your template, you can then just use $siteName and $article directly—no extra wiring needed.

If you do assign a variable with the same name via $this->template->…, though, #[TemplateVariable] won't override it. In other words, when a variable already exists in the template, the attribute leaves it alone.

The Easiest Path to Typed Templates

Another nice thing about #[TemplateVariable] is that it naturally encourages using typed properties as your template's data source. Types are checked by PHP itself (and picked up by IDEs and static analysis), so instead of dynamically stuffing values into $this->template, you're working with proper, strongly-typed values (Article, bool, string…).

Nette offers a complete solution for type-safe templates through custom template classes, where variable types are explicitly defined and $this->template becomes a well-defined object instead of a generic container.

That said, #[TemplateVariable] can be a nice lightweight alternative for small to medium-sized use cases: you don't want the overhead of creating a dedicated template class, but you still want clean code with proper type safety. And when your project grows, you can always migrate to the full strictly-typed template approach.

While version 3.0 brought a completely new compiler and parser, version 3.1 focuses on semantics and code cleanliness. It comes with the concept of Smart HTML Attributes, which eliminates dozens of lines of unnecessary conditions and helpers.

Let's look at what Latte 3.1 does under the hood and why you'll want to use it.

Native mapping of PHP types to HTML attributes

Until now, the template was a passive string generator. If you sent null to <span title="{$title}">, you got an empty string title="". If you sent an array, you got title="Array". Latte 3.1 changes the rules of the game and introduces strict rendering logic based on data types.

Null means “attribute does not exist”

In the DOM, there is a difference between <div title=""> (empty title) and <div> (no title). Latte 3.1 respects this difference.

• Behavior: A null value in any HTML attribute results in its complete removal from the output.
• Impact: The end of n:attr or {if} conditions inside tags. You just pass data.

Boolean attributes without magic

Attributes like disabled, checked or required are binary. Either they are there, or not. Latte now accepts an expression directly in the attribute value.

• Behavior: Truthy expression ⇒ attribute is rendered. Falsey expression ⇒ attribute disappears.
• Advantage: n:attr is a great tool, but for this common use-case it was “overkill”. Now the syntax is clean and declarative:

<input disabled={$isDisabled}>

Arrays in class and style

Attributes that expect a list of values (class, rel, sandbox…) now natively accept arrays. Latte handles the intelligent rendering.

<div class={[
    btn,
    btn-primary => $isPrimary, // added only if true
]}></div>

<div style={[
	background => lightblue,
	display => $isVisible ? block : null,
	font-size => '16px',
]}></div>

Automatic JSON serialization

You can pass an array or object (stdClass) to data-* attributes. Latte detects the context and automatically performs json_encode.

WAI-ARIA compliance without effort

Accessibility is important, but the WAI-ARIA specification has its specifics. Unlike standard HTML boolean attributes, where mere presence decides, ARIA requires explicit text values "true" and "false".

Latte 3.1 solves this problem for you. It detects the aria- prefix and automatically ensures correct stringification.

<button aria-expanded={$isExpanded} aria-hidden={=false}>
{* <button aria-expanded="true" aria-hidden="false"> *}

Advantage: No more manual writing of ternary operators like {$val ? 'true' : 'false'}. Latte guarantees valid output.

Type safety in templates

Latte 3.1 is stricter. And that is good. Common templating systems allow you to print an array into href, generating a broken link <a href="Array">.

Latte 3.1 introduces Runtime Type Checking for attributes.

• Trying to print a boolean into href? Warning.
• Trying to print an object without __toString into title? Warning.

Thanks to this, you detect errors in presentation logic immediately during development, not when a user complains about broken UI. Moreover, the warning contains the exact line and column in the template.

Strict Types by Default

We are keeping up with the times. The PHP ecosystem has matured to strict_types=1 and Latte is not lagging behind. All templates in Latte 3.1 are compiled with this directive by default. This ensures consistent behavior with your backend code and prevents unwanted type casting in critical template logic.

Nullsafe filters: The Holy Grail for Strict Types

You might be wondering how filters, strict types, and HTML attributes are related. In Latte 3.1, very closely.

Imagine a situation where you want to print a title in uppercase, but the variable might be null.

<div title={$title|upper}>

If $title === null, you encounter two problems:

1. Strict types: If the upper filter expects a string but receives null, a silent conversion to an empty string would have occurred previously, but with active strict types, a TypeError occurs.
2. Loss of “Smart” behavior: Even if the filter accepts null, it returns an empty string "", which for Latte is no longer null. The result is <div title="">. The attribute does not disappear, it is just empty.

The solution is the new Nullsafe filter operator ?|.

It works exactly like ?-> in PHP. If the input value is null, the filter is not called at all (nor following filters) and the expression returns null.

<div title={$title?|upper}>

Result? No TypeError, because the filter is not called on null. And the Smart Attribute works, so title completely disappears from the HTML.

Syntactic sugar for cleaner code

We heard the community's call and added missing pieces of syntax:

• n:elseif: The missing link in chaining conditions using n:attributes is finally here.
• n:attributes: Alternative syntax <div n:if={$cond}>, thanks to which you can freely use single and double quotes inside {...}.

How to upgrade safely?

Changing the behavior of null and boolean attributes is a BC break, but we thought about that. Latte 3.1 includes a Migration Mode.

• Call $latte->setFeature(Latte\Feature::MigrationWarnings);.
• Click through the application. Latte will print exactly those places where the output differs from version 3.0 to Tracy/log.
• Use the temporary |accept filter to confirm that the new behavior (e.g. disappearance of an empty attribute) is desired, or modify the code.

Latte 3.1 is not just “another version”. It is a shift towards modern, type-safe, and semantic HTML generation. Try it out and see how much cleaner your templates can be.

👉 Complete migration guide and documentation

With the new HttpAssert class in Nette Tester 2.5.6, you can automate all these critical checks and never have to worry that a configuration change might break your website.

Imagine automatically verifying after every nginx configuration change:

// Critical paths are still accessible
HttpAssert::fetch('https://example.com/robots.txt')
    ->expectCode(200)
    ->expectHeader('Content-Type', contains: 'text/plain');

// Admin section is properly protected
HttpAssert::fetch('https://example.com/admin')
    ->expectCode(403);

// API endpoint works
HttpAssert::fetch('https://example.com/api/health')
    ->expectCode(200)
    ->expectBody(contains: '"status":"ok"');

All validation methods at your fingertips

HttpAssert allows you to easily perform HTTP requests and verify their status codes, headers, and response body content. The fetch() method returns an HttpAssert instance for subsequent verification using a fluent interface. You can use the same pattern matching you know from Assert::match().

HttpAssert::fetch('https://api.example.com/data')
    // Status codes
    ->expectCode(200)                                   // exact code

    // Headers in every way
    ->expectHeader('Content-Type')                      // header must exist
    ->expectHeader('Content-Type', 'application/json')  // exact value
    ->expectHeader('Content-Type', contains: 'json')    // contains text
    ->expectHeader('Server', matches: 'nginx %a%')      // pattern matching

    // Response body
    ->expectBody('OK')                                  // exact value
    ->expectBody(contains: '"success": true')           // contains text
    ->expectBody(matches: '%A%"users":[%a%]%A%');       // matches pattern

The deny* methods are also available and support the same options as their expect* counterparts:

HttpAssert::fetch('https://api.example.com/data')
    ->denyCode(200)                                   // must not be 200
    ->denyHeader('Content-Type')                      // header must not exist
    ->denyHeader('Content-Type', contains: 'json')    // does not contain text
    ->denyHeader('Server', matches: 'nginx %a%')      // does not match pattern
    ->denyBody('OK')                                  // body must not have value
    ->denyBody(contains: '"success": true')           // does not contain text
    ->denyBody(matches: '~exception|fatal~i');        // does not match pattern

Callback functions for advanced validation

Sometimes you need more than just simple comparisons. That's why HttpAssert supports callback functions in all verification methods. You can write your own validation logic while still using the elegant API:

HttpAssert::fetch('https://api.example.com/data')
    ->expectCode(fn($code) => $code === 200 || $code === 201)
    ->expectHeader('Content-Length', fn($length) => $length > 1000)
    ->expectBody(fn($body) => json_decode($body) !== null);

Intelligent redirect handling

You have full control over redirects – you can follow them or test them separately:

// Test redirect without following
HttpAssert::fetch('https://example.com/old-blog', follow: false)
    ->expectCode(301)
    ->expectHeader('Location', 'https://example.com/blog');

// Follow redirects to the end
HttpAssert::fetch('https://example.com/old-blog', follow: true)
    ->expectCode(200)
    ->expectBody(contains: 'Welcome to our new blog');

Flexible request configuration

Whether you're testing GET, POST, PUT, DELETE, or any other HTTP method, HttpAssert can handle it. And of course you can send a request body, headers, or cookies:

HttpAssert::fetch(
    'https://api.example.com/protected',
    method: 'POST',
    headers: [
        'Authorization' => 'Bearer ' . $token,  // associative array
        'Accept: application/json',              // or as string
    ],
    cookies: ['session' => $sessionId],
    body: json_encode($data)
)
    ->expectCode(201)
    ->expectBody(contains: 'created');

Clear error messages

When a test fails, HttpAssert tells you exactly what went wrong:

Expected HTTP status code 200 but got 404
Header 'Content-Type' should contain 'json' but was 'text/html'
Body should contain 'success'

What else is new in Tester 2.5.6?

Besides HttpAssert, version 2.5.6 also brings support for the upcoming PHP 8.5, which will be released at the end of the year. Nette Tester thus always stays one step ahead and ready for the latest PHP versions.

Try HttpAssert and let us know how you like it!

However, this flexibility can present one developer challenge: what happens when a single layout suddenly gets used by presenters that are at “different levels” in the directory structure?

For example, we have @layout.latte for administration, where we want navigation with links to various sections:

<nav>
    <a n:href="Dashboard:">Dashboard</a>
    <a n:href="Products:Overview:">Products</a>
    <a n:href="Users:list">Users</a>
</nav>

When this layout is used by the Admin:Dashboard presenter, the links will correctly lead to Admin:Dashboard:default, Admin:Users:list, etc. But what if the same layout is used by the Admin:Products:Detail presenter? Relative links will suddenly be derived from it and lead to non-existent targets (e.g., Admin:Products:Dashboard:default).

Previously, this was solved by writing all links as absolute paths (or using aliases):

{* Everything absolute *}
<nav>
    <a n:href=":Admin:Dashboard:">Dashboard</a>
    <a n:href=":Admin:Products:Overview:">Products</a>
    <a n:href=":Admin:Users:list">Users</a>
</nav>

This works, but has its drawbacks. Especially if you later decide to move the module elsewhere or rename it.

The solution: {linkBase}

Nette Application 3.2.7 introduces an elegant solution in the form of a new Latte tag {linkBase}. It defines the base from which all relative links in the template will be derived.

{linkBase Admin}

<nav>
    <a n:href="Dashboard:">Dashboard</a>
    <a n:href="Products:Overview:">Products</a>
    <a n:href="Users:list">Users</a>
</nav>

Now it doesn't matter which presenter calls the layout. All relative links will be derived from the Admin module:

• Dashboard: → Admin:Dashboard:default
• Products:Overview: → Admin:Products:Overview:default
• Users:list → Admin:Users:list

{linkBase} only affects relative links – those that don't start with a colon. Absolute links (:Admin:Dashboard) and links to the current presenter (this, show) remain unchanged.

The tag applies to the entire template and works with all ways of creating links: {link}, {plink}, n:href.

Bonus: |absoluteUrl filter

Nette Application 3.2.7 also brings another useful addition – the Latte filter |absoluteUrl. It normalizes URLs to absolute form, which is useful when you need a guaranteed absolute address:

<meta property="og:image" content={$imagePath|absoluteUrl}>

Update to Nette Application 3.2.7 and tell us what you think of the new features.

How many times have you found yourself writing code like this?

<link rel="stylesheet" href="{$baseUrl}/css/style.css?v=7">

<img src="{$baseUrl}/images/logo.png?v=1699123456" width="200" height="100" alt="Logo">

You've been manually constructing URLs, adding versioning parameters, determining and adding correct image dimensions and so on? Those days are over.

Through years of developing web applications, I was looking for a solution that would be very simple to use, yet infinitely open for extension. Something I could use across all my websites – from simple presentations to complex e-shops. After testing various approaches and validating numerous principles on real projects, Nette Assets was eventually born.

With Nette Assets, the same code changes to:

{asset 'css/style.css'}

<img n:asset="images/logo.png" alt="Logo">

And that's it! The library automatically:

✅ Detects image dimensions and inserts them into HTML
✅ Adds versioning parameters based on file modification time
✅ Has native Vite support with Hot Module Replacement

No configuration!

Let's start with the simplest scenario: you have a www/assets/ folder full of images, CSS and JS files. You want to include them in pages with proper versioning and automatic dimensions. Then you don't need to configure anything at all, just install Nette Assets:

composer require nette/assets

… and you can start using all the new Latte tags and they will work immediately:

{asset 'css/style.css'}
<img n:asset="images/logo.png">

I mainly use the {asset} tag for CSS and scripts, while preferring n:asset for images since I like having HTML elements like <img> explicitly visible in templates – but it's a matter of personal preference.

This generates code like:

<link rel="stylesheet" href="https://example.cz/assets/css/style.css?v=1670133401">
<img src="https://example.cz/assets/images/logo.png?v=1699123456" width="200" height="100">

Why the versioning? Browsers cache static files and when you change a file, the browser may still use the old version. So-called cache busting solves this problem by adding a parameter like ?v=1699123456, which changes with each file modification and forces the browser to download a new version. Versioning can be disabled in configuration.

Let's add some configuration

Do you prefer a different folder name than assets? In that case we need to add configuration to common.neon, but just three lines are enough:

assets:
	mapping:
		default: static  # files in /www/static/

Sometimes I put assets on a separate subdomain, like here on the Nette website. The configuration then looks like this:

assets:
	mapping:
		default:
			path: %rootDir%/www.files     # files in /www.files/
			url: https://files.nette.org

On the blog I wanted to keep things organized and divide assets logically into three categories: website design (logo, icons, styles), images in articles and recorded versions of articles. Each category has its own folder:

assets:
	mapping:
		default: assets       # regular files /www/assets/
		content: media/images # article images in /www/media/images/
		voice: media/audio    # audio files in /www/media/audio/

To access different categories we use colon notation category:file. If you don't specify a category, the default (default) is used. So in the template I have:

{* Article images *}
<img n:asset="content:hero-photo.jpg" alt="Hero image">

{* Audio version of article *}
<audio n:asset="voice:123.mp3" controls></audio>

In real templates we naturally work with dynamic data. You usually have an article in a variable, say $post, so I can't write voice:123.mp3, I simply write:

<audio n:asset="voice:{$post->id}.mp3" controls></audio>

To avoid worrying about audio formats in templates, I can add automatic extension completion to the configuration:

assets:
	mapping:
		voice:
			path: media/audio
			extension: mp3  # automatically adds .mp3

Then just write:

<audio n:asset="voice:{$post->id}" controls></audio>

When I later start using a better M4A format, I'll just need to modify the configuration. And since it doesn't make sense to convert old recordings, I'll specify an array of possible extensions – the system will try them in the given order and use the first one for which a file exists:

assets:
	mapping:
		audio:
			path: media/audio
			extension: [m4a, mp3]  # tries M4A first, then MP3

What if the file simply doesn't exist?

Not every article has a recorded version. I need to verify if the file exists at all, and if not, not render the <audio> element.

This is solved with a single character! Question mark in the attribute name n:asset?

{* Shows audio player only if recorded version exists *}
<audio n:asset?="voice:{$post->id}" controls></audio>

Similarly there's a question mark variant of the {asset?} tag. And if you need to wrap an asset in your own HTML structure or add conditional rendering logic, you can use the asset() function or its “question mark” variant tryAsset():

{var $voice = tryAsset("voice:{$post->id}")}
<div n:if="$voice" class="voice-version">
	<p>🎧 You can also listen to this article</p>
	<audio n:asset=$voice controls></audio>
</div>

The tryAsset() function returns an asset object or null if the file doesn't exist. The asset() function always returns an asset object or throws an exception. This enables various patterns, useful is for example this fallback trick when you want to show a replacement image:

{var $avatar = tryAsset("avatar:{$user->id}") ?? asset('avatar:default')}
<img n:asset=$avatar alt="Avatar">

And what objects do these functions actually return? Let's explore these objects.

Working with assets in PHP code

You work with assets not only in templates, but also in PHP code. The Registry class serves to access them, which is the main interface of the entire library. We have this service passed via dependency injection:

class ArticlePresenter extends Presenter
{
	public function __construct(
		private Nette\Assets\Registry $assets
	) {}
}

Registry provides getAsset() and tryGetAsset() methods for getting asset objects. Each object represents some resource. It doesn't have to be a physical file – it can be dynamically generated. Asset carries information about URL and metadata. In the Nette\Assets namespace you'll find these classes:

• ImageAsset – images (width, height)
• ScriptAsset – JavaScript files (type for modules)
• StyleAsset – CSS files (media queries)
• AudioAsset / VideoAsset – media (duration, dimensions)
• FontAsset – fonts (proper CORS headers)
• EntryAsset – entry points for Vite
• GenericAsset – other files (basic URL and metadata)

Each asset has readonly properties specific to its type:

// ImageAsset for images
$image = $this->assets->getAsset('photo.jpg');
echo $image->url;      // '/assets/photo.jpg?v=1699123456'
echo $image->width;    // 1920
echo $image->height;   // 1080
echo $image->mimeType; // 'image/jpeg'

// AudioAsset for audio files
$audio = $this->assets->getAsset('song.mp3');
echo $audio->duration;  // duration in seconds

// ScriptAsset for JavaScript
$script = $this->assets->getAsset('app.js');
echo $script->type;     // 'module' or null

Properties like image dimensions or audio file duration are loaded lazily (only when you first use them), so the system stays fast even with thousands of files.

First-class Vite integration

Nette Assets have native support for Vite. This modern tool handles the need to compile (build) frontend code, because:

• it's written in other languages (TypeScript, Sass)
• it's transpiled for older browsers
• it's bundled into one file
• it's minified for smaller size

To avoid repeating this entire process with every change in development mode, Vite serves files directly without bundling and minification. Every change is thus reflected immediately. And as a bonus it can even do it without page refresh – you edit CSS or JavaScript and the change is reflected in the browser within milliseconds, without losing form data or application state. This is called Hot Module Replacement.

For production, Vite then creates classic optimized builds – bundles, minifies, splits into chunks and adds versioned names for cache busting.

In today's JavaScript ecosystem, Vite is the de facto standard for modern frontend development. That's why it made sense to include support directly in Nette Assets. Thanks to the open architecture, you can easily write a mapper for any other bundler.

You might wonder: “Vite adapters for Nette already exist, what's different about this?” Yes, they exist, and I thank their authors for that. The difference is that Nette Assets is a complete system for managing all static files, and Vite is one component, but very elegantly integrated.

Just add two words to the common.neon configuration: type: vite.

assets:
	mapping:
		default:
			type: vite
			path: assets

Vite is known for working even without configuration or being very easy to configure. However, backend integration adds complexity. That's why I created @nette/vite-plugin, which makes the whole integration simple again.

In the vite.config.ts configuration file, just activate the plugin and specify the path to entry points:

import { defineConfig } from 'vite';
import nette from '@nette/vite-plugin';

export default defineConfig({
	plugins: [
		nette({
			entry: 'app.js',  // entry point
		}),
	],
});

And in the layout template we load the entry point:

<!doctype html>
<head>
	{asset 'app.js'}
</head>

And that's it! The system automatically takes care of the rest:

• In development mode loads files from Vite dev server with Hot Module Replacement
• In production uses compiled, optimized files

No configuration, no conditions in templates. It just works.

Power of custom mappers: Real examples

A mapper is a component that knows where to find files and how to create URLs for loading them. You can have multiple mappers for different purposes – local files, CDN, cloud storage or build tools. The Nette Assets system is completely open for creating custom mappers for anything.

Mapper for product images

On an e-shop you need product images in different sizes. You usually already have a service that handles resize and image optimization. Simply wrap it with a Nette Assets mapper.

The getAsset() method of your mapper must return the appropriate asset type. In our case ImageAsset. If we additionally give the constructor a file parameter with the path to the local file, it automatically loads image dimensions (width, height) and MIME type. If the requested file doesn't exist, we throw an AssetNotFoundException exception:

class ProductImageMapper implements Mapper
{
	public function getAsset(string $reference, array $options = []): Asset
	{
		// $reference is product ID
		$product = $this->database->getProduct((int) $reference);
		if (!$product) {
			throw new Nette\Assets\AssetNotFoundException("Product $reference not found");
		}

		$size = $options['size'] ?? 'medium'; // small, medium, large

		// We leverage our existing image service
		return new Nette\Assets\ImageAsset(
			url: $this->imageService->getProductUrl($product, $size),
			file: $this->imageService->getProductFile($product, $size)
		);
	}
}

Registration in configuration:

assets:
	mapping:
		product: App\ProductImageMapper()

Usage in templates:

{* Different product sizes *}
<img n:asset="product:{$product->id}, size: small" alt="Product thumbnail">
<img n:asset="product:{$product->id}, size: large" alt="Product detail">

Automatic OG image generation

OG (Open Graph) images are displayed when sharing on social networks. Instead of manual creation, you can have the system generate them automatically based on content type.

In this case, the $reference parameter determines the image context. For static pages (e.g. homepage, about) pre-prepared files are used. For articles, the image is generated dynamically based on the article title. The mapper first checks cache – if the image already exists, it returns it. Otherwise it generates it and saves it to cache for next use:

class OgImageMapper implements Mapper
{
	public function getAsset(string $reference, array $options = []): Asset
	{
		// For articles we generate dynamically based on title
		if ($reference === 'article') {
			$title = $options['title'] ?? throw new LogicException('Missing option title for article');
			$filename = '/generated/' . md5("article-{$title}") . '.png';
			$path = $this->staticDir . $filename;
			if (!file_exists($path)) {
				file_put_contents($path, $this->ogGenerator->createArticleImage($title));
			}

		} else { // For static pages we use pre-prepared files
			$filename = "/{$reference}.png";
			$path = $this->staticDir . $filename;
			if (!file_exists($path)) {
				throw new Nette\Assets\AssetNotFoundException("Static OG image '$reference' not found");
			}
		}

		return new Nette\Assets\ImageAsset($this->baseUrl . $filename, file: $path);
	}
}

Then in the template we add to the header:

{* For static page *}
{var $ogImage = asset('og:homepage')}

{* For article with dynamic generation *}
{var $ogImage = asset('og:article', title: $article->title)}
<meta property="og:image" content={$ogImage}>
<meta property="og:image:width" content={$ogImage->width}>
<meta property="og:image:height" content={$ogImage->height}>

Thanks to this approach you have automatically generated OG images for every article, which are created only once and then cached for further use.

Nette Assets: more elegant asset management

Nette Assets represent an elegant system that takes care of almost everything automatically.

• Eliminates boilerplate code – no more manual URL construction
• Supports modern workflow – Vite, TypeScript, code splitting
• Is flexible – custom mappers, various storage systems
• Works immediately – no complex configuration

Complete description can be found in documentation and code on GitHub.

You'll never write <img src="/images/photo.jpg?v=123456"> manually again!

Nette documentation brings a comprehensive guide to directory structure that offers answers to all these questions.

The quality of code organization significantly affects its readability. At first glance at a new project, you should quickly understand its purpose. Take a look at this app/Model/ directory:

app/Model/
├── Services/
├── Repositories/
└── Entities/

What does this structure tell you about the application? Almost nothing. Compare with this alternative:

app/Model/
├── Cart/
├── Payment/
├── Order/
└── Product/

It's immediately clear that this is an e-commerce application. That's the power of domain-oriented structure that the document presents.

The guide also shows how to naturally evolve the structure as your project grows. Whether you're starting a new project or want to improve an existing application, you'll find principles for making informed decisions about code organization.

Read the Application Directory Structure chapter in Nette documentation and blogpost Elegant Presenter Structuring.

What are lazy objects?

A lazy object is a special type of object that looks and behaves exactly like the actual service from your code's perspective, but in reality, it delays its initialization until it's actually needed. When we request a database service from the DI container, for example, we get an object that externally looks like a regular instance of Database, but it hasn't actually established a database connection yet. This happens only when we first actually use the service.

Example:

// We get an object that looks like Database but hasn't established a connection yet
$database = $container->getByType(Database::class);
// The database connection is created HERE, during first actual use
$database->query('SELECT * FROM users');

How to enable it?

In the new version of Nette DI 3.2.4, all you need is one line in configuration:

di:
    lazy: true

That's all! From now on, all services in the DI container will be created “lazily”.

We can also set lazy creation for individual services:

services:
    newsletter:
        create: Newsletter
        lazy: false   # this service will be created immediately, even if lazy is globally enabled
    database:
        create: Database
        lazy: true    # this service will be lazy, even if lazy is globally disabled

Benefits in practice

1. Faster application startup – only services you actually need are created
2. Lower memory consumption – unused services don't take up space
3. Simple implementation – just one line in configuration

It's important to note that lazy objects logically change how service configuration errors manifest themselves. For example, incorrect database credentials won't show up at application startup, but only during the first actual database connection.

Hidden Advantage – Solving Circular Dependencies

Lazy objects bring yet another interesting advantage – they elegantly solve circular dependencies between services. Imagine a situation where service A needs service B and service B simultaneously needs service A. The Nette DI container immediately detects such a loop and throws a “Circular reference detected” exception instead of letting PHP cycle in an infinite loop. With lazy objects, this problem practically disappears. Service A receives a lazy proxy of service B during creation, which is only initialized when actually used, at which point service A already exists and can be passed to service B as a dependency. Although circular dependencies aren't something we should deliberately create when designing an application, it's interesting to realize that with lazy objects, this problem disappears.

Limitations and recommendations

• Lazy objects work only for your own classes
• They cannot be used for internal PHP classes
• Requires PHP 8.4 or higher

Lazy objects represent a significant step forward in PHP application optimization. Thanks to them, your Nette applications can be faster and more efficient without changing a single line of your code.

Documentation That Packs a Punch

High-quality documentation is the Achilles' heel of many open-source projects. Not so with the Nette Framework. Nette boasts something that many competitors lack—precise, clear, and engaging documentation that guides developers from their first steps to advanced concepts. For example, the Dependency Injection documentation not only explains Nette DI itself but also provides an accessible theoretical introduction to the topic, enriched by contributions from Miško Hevery, the author of the Angular framework. The Latte documentation offers an interactive insight into escaping, explaining why it is the only safe templating system in PHP. Nette's commitment to its users is further demonstrated by the existence of a complete introduction to object-oriented programming.

No matter where in the world you’re coding, Nette speaks your language. All documentation is available in impressive 16 world languages: English, German, Spanish, French, Italian, Hungarian, Polish, Portuguese, Romanian, Slovenian, Turkish, Greek, Bulgarian, Russian, and Ukrainian, and Czech.

A New Era for Database Documentation

There were, however, two areas that slightly marred an otherwise perfect score—documentation for Nette Database and the Tracy debugger. This is now changing for the Database. Check out the revamped and expanded version of the new documentation.

The content is clearly divided into two logical sections based on approaches to working with databases:

• SQL Approach for developers who prefer direct control over their queries
• Explorer for those who value development speed and the convenience of automation

It includes numerous examples and code snippets that demonstrate the library's real capabilities and inspire effective use. Each concept is illustrated with practical use cases, enabling quick understanding and immediate application in your projects.

Security First (Because Your Sleep Depends on It)

In an age where database attacks are commonplace, the brand-new section of the documentation offers a thorough technical analysis of security risks. Here, you’ll find practical demonstrations of real-world threats and their prevention:

• A detailed explanation of SQL injection and its dangers
• Practical examples of safe parameterized queries
• A comprehensive approach to input data validation
• Proper use of dynamic identifiers

The new documentation combines function descriptions with a detailed explanation of security aspects and best practices. The result is a guide that helps you write not only functional but also secure code. Start reading today!