Yii2 Advanced Template in 2026: Still Relevant?

Last winter I spent two weeks doing nothing but answering one question: do we rebuild the wholesale platform of a mid-size Latvian distributor on the Yii2 advanced template, or do we chase something newer? The catalog had 30,000 SKUs, per-customer-group pricing, and an ERP that spoke only a custom XML dialect. Three developers. A hard deadline, because the licensing on the old system was expiring.

The "is Yii2 dead" thread comes up every year, usually written by people who last touched it in 2016. My answer after shipping that rebuild: the advanced template is not just still relevant — for a certain class of project it is still the most honest starting point you can pick. But the reasons are more boring than the internet debates suggest.

Four deployables, two applications

The template splits into frontend, backend, common and console. That split sounds like ceremony until you live with it. On the wholesale project it mapped directly onto reality: customers hit the storefront, staff hit the admin, and the two have completely different trust models. The backend runs behind a VPN with strict RBAC; the storefront is public and cached aggressively. Separate applications mean separate session configs, separate asset bundles, separate access rules — and nobody accidentally exposes an admin route because it sat in the same routing table as the shop.

Meanwhile everything that is genuinely shared — models, domain services, migrations — lives in common. When the ERP integration needed to reuse the same price-calculation service as the storefront, it was already there. No copying, no sync.

What has aged well

• ActiveRecord with restraint. AR gets criticized for encouraging anemic models with business logic smeared across controllers. That is a discipline problem, not a framework problem. We kept AR for persistence and pushed invariants into explicit service classes in common/services. Every multi-record write goes through a transaction there. It reads like boring, obvious code — which is the point.
• Migrations as a first-class workflow. Console migrations with safeUp(), applied identically to dev, staging and production. The schema history of the project is readable in one directory. I have come to value this more than any ORM feature.
• RBAC that is actually usable. Hierarchical roles with business rules took an afternoon to wire up, and staff permissions in the admin have not needed a rewrite since.
• The console tier. Queue workers, nightly ERP syncs, cache warmers — all just console controllers reusing the same models and services. No separate "worker app" to maintain.

What has not aged well

Frontend tooling is the honest weak spot. There is no Vite story; you assemble assets from npm packages through asset-packagist or commit prebuilt bundles. On this project we pull SortableJS and Quill as local npm assets and wire them into Yii asset bundles — it works, it is reproducible, but it is not "modern DX" by any stretch.

Packaged extensions are the second weak spot. Some are excellent and maintained; some have been abandoned for years. The rule I now apply: before adopting any extension, read the last six months of its commit history. If nothing has moved and the maintainer is unresponsive, vendor it in and own it. Treating extensions as rentable infrastructure is how Yii2 projects rot.

When to modularize

The recurring question: when does common become a composer package? My threshold is now concrete — the moment a second deployable needs the same business rules. One site plus one admin: keep it in common. Add a customer portal or a standalone API with independent release cycles: extract the shared domain into a package with its own versioning and tests. Extracting earlier buys you versioning overhead you do not yet need, and the extraction itself is mostly mechanical if the service boundaries are clean.

Verdict

The advanced template is a starting structure, not a strategy. What made the wholesale rebuild maintainable was not the template — it was transactional services, explicit ownership checks, normalized ordering and a strict "no business logic in views" rule. The template's contribution is that it makes those disciplines easy to practice: shared code has an obvious home, admin and public concerns stay separated, and the database schema evolves in a readable history.

If you are a small team shipping a monolith with an admin surface — which describes most real business software — it remains a pragmatic choice in 2026. Choose it deliberately, apply the discipline, and it will outlive the hype cycles that keep declaring it dead.