Yii 3: What's New, Release History & EOL Status

What Is New in Yii 3

Yii3 is a ground-up rethinking of the framework -- not an incremental upgrade. The monolithic architecture is gone, replaced by a package ecosystem of 130+ independent components. Every major pain point from Yii 2.0 has been addressed: closed ecosystem, service locator anti-patterns, PHP standards incompatibility, and too much magic.

Why Did the Architecture Change So Drastically?

Yii 2.0 forced you into its ecosystem. General PHP packages were awkward to wire in. The built-in service locator made testing painful because dependencies were hidden behind static calls rather than being injected explicitly. These trade-offs were acceptable in 2014; they are not in 2025.

Yii3 solves this by making the DI container the core of everything. Every package is built around dependency injection from the ground up. The result is that you can swap almost any component -- logger, cache, HTTP client -- for any PSR-compliant alternative without touching application code.

In practice, this means a Yii3 project can pull in Symfony Mailer, a Monolog logger, and a Cycle ORM layer alongside native Yii packages, and the container wires them all together cleanly.

How Does the New DI Container and Configuration Work?

The container resolves dependencies at runtime based on type hints -- no code generation step, no compiled container files. You configure it with plain PHP arrays that map interfaces to concrete classes or factory closures.

return [
    // Interface to class mapping
    EngineInterface::class => EngineMarkOne::class,

    // Detailed configuration with constructor and setter injection
    MyServiceInterface::class => [
        'class' => MyService::class,
        '__construct()' => [42],
        'setDiscount()' => [10],
    ],

    // Factory closure
    'api' => static fn(ApiConfig $config) => new ApiClient($config),
];

// Dependencies injected automatically via type hints
final readonly class MyController
{
    public function __construct(
        private CacheInterface $cache
    ) {}
}

Configuration is split into two layers: DI container config (interface-to-class mapping) and parameters (values used to configure those classes). Application templates come with sensible defaults split between web, API, and console contexts -- plus a shared common config.

'yiisoft/yii-view-renderer' => [
    'viewPath' => null,
    'layout' => '@src/Web/Shared/Layout/Main/layout.php',
    'injections' => [
        Reference::to(CsrfViewInjection::class),
    ],
],

Because the configuration is just executed PHP, you can step-debug it with XDebug. There is no magic compilation phase to work around.

What Application Templates Are Available?

Three official templates ship with Yii3, each intentionally minimal. They wire together routing, DI, configuration, and environment handling -- but stop there. Database, auth, and other optional features are not included by default.

• Web (yiisoft/app) -- server-rendered applications with views, widgets, forms, and asset management.
• API (yiisoft/app-api) -- JSON API projects with data response handling and Swagger support.
• Console (yiisoft/app-console) -- background workers and CLI tooling.

This is a deliberate break from Yii 2.0's "advanced template" approach where you got a full application skeleton with everything preconfigured. The new templates give you a working foundation and let you grow it intentionally.

How Does Worker Mode Improve Performance?

Standard PHP re-bootstraps the entire framework on every HTTP request -- loading classes, opening database connections, parsing config. Worker mode skips all of that after the first request. The application initializes once, then handles subsequent requests in the same process.

Yii3 supports RoadRunner, Swoole, and FrankenPHP for this. The performance gains are significant, especially for high-throughput APIs where cold-start overhead adds up fast.

The trade-off is state isolation. Shared state between requests can cause subtle bugs or memory leaks. Yii3 packages are designed to either hold no state at all, or reset state cleanly at the start of each request-response cycle. This is one area where the package-level design pays off -- each component has explicit, testable lifecycle behavior.

What Changed in Database and Data Abstraction?

The database layer was extracted from Yii 2.0 into a standalone yiisoft/db package, then substantially redesigned. It covers schema management, a query builder, and Active Record. All five major drivers are supported: PostgreSQL, MySQL/MariaDB, MSSQL, Oracle, and SQLite.

$posts = $connection
    ->select(['id', 'title', 'created_at'])
    ->from('{{%posts}}')
    ->where(['status' => 'published'])
    ->andWhere(['>', 'views', 1000])
    ->orderBy(['created_at' => SORT_DESC])
    ->limit(10)
    ->all();

If yiisoft/db is not your preference, Yii3 integrates with Cycle ORM and Doctrine out of the box. PDO and native drivers are also options. The framework does not force a single ORM choice -- the DI container handles wiring whichever you pick.

On top of the database layer, yiisoft/data provides a higher-level abstraction with pagination, sorting, filtering, and data formatting -- particularly useful for building admin panels and data grids.

How Is Validation and Form Handling Different?

Yii3's validator is driven by PHP 8 attributes. You annotate model properties directly with rules rather than defining a separate rules() method. This keeps the constraint declaration close to the property it governs.

<?php

declare(strict_types=1);

namespace App\Web\Echo;

use Yiisoft\FormModel\FormModel;
use Yiisoft\Validator\Label;
use Yiisoft\Validator\Rule\Length;

final class Form extends FormModel
{
    #[Label('The message to be echoed')]
    #[Length(min: 2)]
    public string $message = '';
}

Input binding is handled by yiisoft/input-http, which populates form models directly from HTTP request data. This replaces the implicit load() magic from Yii 2.0 with an explicit, testable pipeline.

Understanding Yii3 Versioning -- Why There Is No "3.x.x"

This is the most common point of confusion for developers coming from Yii 2.0. Yii3 does not have a single framework version number. Each of the 130+ packages is versioned independently using SemVer. yiisoft/db is on its own version. yiisoft/router is on its own version. They do not stay in sync.

In practice, when people say "Yii3," they mean the ecosystem of packages designed to work together under the yiisoft namespace -- not a specific version number. The closest thing to a canonical reference point is the official release announcement of the framework in December 2025, which marks the ecosystem as production-ready.

If you need to track Yii3 releases for tooling or notifications, the most practical approach is:

• Track the application templates (yiisoft/app, yiisoft/app-api) as a proxy for "framework readiness." These are updated when the core package set is stable.
• Track individual packages you actually depend on -- most projects use 10-20 packages, not all 130.
• Follow the official news feed tagged yii3 for major ecosystem updates.

There is no equivalent of yiisoft/yii2 for Yii3. That single-repo model is intentionally gone.

What Security Features Are Built In?

Security was a design constraint at the package level, not an afterthought. CSRF protection, access control abstraction, RBAC, and JWT authentication are all available as dedicated packages. A proxy middleware handles X-Forwarded-For and related headers safely.

• yiisoft/access -- access control abstraction
• yiisoft/rbac -- role-based access control implementation
• yiisoft/auth-jwt -- JWT authentication
• yiisoft/csrf -- CSRF protection middleware
• yiisoft/user -- user abstraction for web applications

The official documentation includes a dedicated security guide covering both the available packages and the established security response process for reporting vulnerabilities.

How Does Error Handling Work in Yii3?

The error handler (yiisoft/error-handler) goes further than Yii 2.0's. It handles out-of-memory errors and fatal errors -- situations where most PHP error handlers give up. It can map exception types to custom exceptions and respond in different formats (HTML, JSON, plain text) depending on the request context.

In development mode, "friendly exceptions" are rendered with a block that explains why the error happened and what to try. The stack trace view highlights the exact line, collapses framework-internal frames by default (since those are heavily tested and rarely the culprit), and shows source code inline for each frame.

Sentry integration is available via yiisoft/yii-sentry for production error collection.