Interested developers are welcome to try Yii 2.1 branch, which is already available for early access. It brings many new features and embraces PSR standards. However, it also brings significant backwards compatibility break. While it is not yet finished, it is already prepared for usage as a development platform.
Warning: Yii 2.1 branch is unstable and can be broken anytime, its current code may change dramatically before actual release. Do NOT attempt ot use it for the actual projects in 'production' stage, unless you are ready to deal with the consequences!
You can browse Yii 2.1 code at GitHub and install it using "2.1.x-dev" version for "yiisoft/yii2" Composer package.
Composer
In order to install Yii 2.1, you should specify version "2.1.x-dev" for "yiisoft/yii2" package in your 'composer.json' file:
"require": {
"yiisoft/yii2": "2.1.x-dev",
...
}
Attention: since 2.1 Yii dropped its own PHP class autoloader in favor of the one provided by Composer. Thus you will need to configure "autoload" for your project at 'composer.json' otherwise PHP script will be unable to find classes declared at your project.
For example:
{
"autoload": {
"psr-4": {"app\\": ""}
},
"autoload-dev": {
"psr-4": {"tests\\": "tests"}
},
...
}
In case autoload for the project files is missing web application will trigger Yii application error like "Unable to resolve request 'site/error'".
Note that in 2.1 some former "yiisoft/yii2" package classes have been moved into separate repositories:
- yiisoft/yii2-captcha: provides an implementation for the CAPTCHA protection.
- yiisoft/yii2-jquery: provides an integration of JQuery and a set of widget behaviors for client side.
- yiisoft/yii2-rest: provides the support for REST API server side creation.
- yiisoft/yii2-mssql: provides support for MSSQL Server database usage.
- yiisoft/yii2-oracle: provides support for Oracle database usage.
- yiisoft/yii2-maskedinput: provides support for masked input JQuery plugin.
In case your project requires one of these, you should add corresponding packages to
your composer.json
. So in order get full equivalent of Yii 2.0 for 2.1, composer configuration should be the following:
"require": {
"yiisoft/yii2": "2.1.x-dev",
"yiisoft/yii2-jquery": "1.0.x-dev",
"yiisoft/yii2-captcha": "1.0.x-dev",
"yiisoft/yii2-rest": "1.0.x-dev",
"yiisoft/yii2-mssql": "1.0.x-dev",
"yiisoft/yii2-oracle": "1.0.x-dev",
"yiisoft/yii2-maskedinput": "1.0.x-dev",
...
}
Most of the official extensions also have development branches compatible with Yii 2.1. The following composer configuration example will install all extensions available for 2.1:
"require": {
"yiisoft/yii2": "2.1.x-dev",
...
"yiisoft/yii2-debug": "2.1.x-dev",
"yiisoft/yii2-gii": "2.1.x-dev",
"yiisoft/yii2-swiftmailer": "2.2.x-dev",
"yiisoft/yii2-bootstrap": "2.2.x-dev",
"yiisoft/yii2-jui": "2.1.x-dev",
"yiisoft/yii2-httpclient": "2.1.x-dev",
"yiisoft/yii2-authclient": "2.2.x-dev",
"yiisoft/yii2-mongodb": "2.2.x-dev",
"yiisoft/yii2-sphinx": "2.2.x-dev",
"yiisoft/yii2-imagine": "2.2.x-dev",
"yiisoft/yii2-faker": "2.1.x-dev"
}
Basic code upgrade
Ensure that you code does not use any deprecated constructions like following:
- Invocation of
className()
, e.g.SomeClass::className()
. It should be replaced by native PHP::class
construction - Throwing or catching
yii\base\InvalidParamException
. It should be replaced byyii\base\InvalidArgumentException
- Usage of
yii\console\Controller
constants, e.g.EXIT_CODE_NORMAL
orEXIT_CODE_ERROR
, for exit code. They should be replaced by constants provided viayii\console\ExitCode
class.
Any DI object configuration should use '__class' keyword instead of 'class' for the class name specification.
This affects DI container, Yii::createObject()
and thus any application component specification.
So former Yii application config like following:
return [
'components' = [
'mailer' => [
'class' => yii\swiftmailer\Mailer::class,
],
'mutex' => [
'class' => yii\mutex\FileMutex::class
],
'db' => [
'class' => yii\db\Connection::class,
'dsn' => 'mysql:host=localhost;dbname=myproject',
'username' => '???',
'password' => '???',
],
]
];
now should look like this:
return [
'components' = [
'mailer' => [
'__class' => yii\swiftmailer\Mailer::class,
],
'mutex' => [
'__class' => yii\mutex\FileMutex::class
],
'db' => [
'__class' => yii\db\Connection::class,
'dsn' => 'mysql:host=localhost;dbname=myproject',
'username' => '???',
'password' => '???',
],
// ...
],
// ...
];
Logging
At 2.1 logging has been rewritten according to PSR-3, which in particular allows you to use Monolog
as logger for your project.
Application component 'log' does not exist anymore. You should configure logger directly via Yii::setLogger()
or using Application::setLogger()
, e.g. 'logger' key in application config.
So former Yii log config like following:
return [
'bootstrap' => [
'log', // should be removed for 2.1
],
'components' = [
// should be converted to 'logger' for 2.1
'log' => [
'traceLevel' => YII_DEBUG ? 3 : 0,
'targets' => [
[
'class' => yii\log\FileTarget::class,
'levels' => ['error', 'warning'],
],
],
],
// ...
],
// ...
];
now should look like this:
return [
// no bootstrap
'logger' => [
'traceLevel' => YII_DEBUG ? 3 : 0,
'targets' => [
[
'__class' => yii\log\FileTarget::class,
'levels' => ['error', 'warning'],
],
],
],
'components' = [
// no 'log' component
// ...
],
// ...
];
Caching
At 2.1 caching has been rewritten according to PSR-16, which allows your usage of 3rd party cache providers easily.
In order to keep 'cache dependency' feature cache specification has been changed.
Now any cache component should use yii\caching\Cache
class (or implement yii\caching\CacheInterface
), while
actual cache storage is determined via Cache::$handler
.
So former Yii cache config like following:
return [
'components' = [
'cache' => [
'class' => yii\caching\DbCache::class,
'cacheTable' => 'my_cache',
],
// ...
],
// ...
];
now should look like this:
return [
'components' = [
'cache' => [
'__class' => yii\caching\Cache::class,
'handler' => [
'__class' => yii\caching\DbCache::class,
'cacheTable' => 'my_cache',
],
],
// ...
],
// ...
];
Be careful: it may happen, that in case of incorrect cache configuration (e.g. using old one), you will not receive an immediate error, but just some latent incorrect behavior.
JQuery
As it was already said all JQuery related code has been moved to "yiisoft/yii2-jquery" package.
This, in particular, includes yii.js
, client-side validation for ActiveForm
and filter handler for GridView
.
Without extra adjustments simple usage of ActiveForm
or GridView
widget will no longer provide any
JavaScript code registration, and thus no 'fancy' client-side effects.
You will need to attach 'clientScript' behavior to the widget in order to make it behave like before.
ActiveForm example:
<?php $form = ActiveForm::begin([
'id' => 'login-form',
'as clientScript' => yii\jquery\ActiveFormClientScript::class, // attach JQuery client script, enabling client-side validation:
]); ?>
...
<?php ActiveForm::end(); ?>
GridView example:
<?= GridView::widget([
'as clientScript' => yii\jquery\GridViewClientScript::class, // attach JQuery client script, enabling filter auto-submit
'dataProvider' => $dataProvider,
// ...
]); ?>
Live example
In order to get more clear impression on Yii 2.1 usage, you may refer to the working project template, which has been already updated to 2.1 - ii2tech/project-template
Install via composer:
composer create-project --prefer-dist --stability=dev yii2tech/project-template yii-test 2.0.x-dev
Install via git:
# clone repo:
git clone git@github.com:yii2tech/project-template.git yii-test
# go to project:
cd yii-test
# get 2.0 branch:
git fetch
git checkout 2.0
In order to configure project and make it running run 'install.php' file:
cd yii-test
php install.php
Using two words as keys is not a good idea - instead of "as clientScript" could be simply "clientScript" or just "script" perhaps? Attaching JS scripts to each element - well, we have hundreds of ActiveForm elements ... would it be possible to configure globally attached library scripts? Otherwise it would take a lot of additional scripting comparing to 2.0 - simplicity fading away ...
Also what's the reasong to use underscored "__class" instead of previous "class" ? Is there conflict somewhere with PHP reserved word?
@lubosdz, I think it's fine to do a DI hack:
It is like that for beahviors since the very first 2.0 version. Noone complained so far :)
Being able to configure a component with a property named
class
which is quite common.Ради нескольких людей, кто использует свойство class вы сломали конфиги у тысяч проектов. Приложу мнение мудрого человека по этому вопросу https://github.com/yiisoft/yii2/issues/2871
@vyachin, that was for a change within 2.0 which is meant not to break backwards compatibiltiy intentionally. 2.1 is meant to be compatibility breaking release where we have a chance to clean things up without looking at existing code too much.
@samdark я Вас полностью поддерживаю в движении вперед. Однако конкретно это изменение сделано в угоду "очень узкого круга лиц" и отрицательно сказывается на всем сообществе. Конечно два символа не сильно скажутся на объеме кода, но сделают его менее читабельным, а кривую обучения более сложной.
Почему Вы решили, что свойство $class используется чаще чем $class? Те кто использовал название $class были готовы к ограничениям и как-то его обходили. Однако возможно были те кто использовал $class. Теперь обоим группа придется вносить изменения.
Мне очень нравится, все что делает команда Yii, однако я очень надеюсь, вы не станете развивать yii согласно требованиям или видению некоторых членов или компаний.
От этого изменения ниодин проект сам по себе не сломается. Правку нужно вносить только если вы переходите с версии 2.0.х на 2.1.х, а это делается осознанно.
Старые версии у вас никто не отнял. Если переход на новый синтаксис вызывает у вас такой большой стрэсс, но оставайтесь на старых версиях, где ничего не ломается.
Использование двойного подчеркивая (
__
) является распрастраненной практикой в PHP для обозначение специальный конструкций и методов например:__FILE__
__DIR__
__construct()
__set()/__get()
Странно, что в то время, как все эти конструкции не вызывают у вас негодования, использование
__class
превратилось для вас в трагедию...Конструкция
__class
теперь ясно отмечена как специальная, при этом ее назначение угадать не сложно.Кроме того такая конструкция хорошо гармонирует с заданием параметров конструктора -
__construct()
. Например:Когда я обновлял шаблон yii2tech/project-template на исправление конфигурации (она там сравнительно сложная) у меня ушло около 5 минут.
Если у вас достаточно свободного времени чтобы подыскивать мудрые изречения из интренета, то наверняка найдется время и дня внесения таких правок, если хорошенько поискать.
@klimov-paul Оставим в стороне язык PHP.
Никто не скажет что это выглядит гармонично
вот эти варианты логичны, понятны и "гармоничны".
А первый вариант знаком любому, кто знаком с yii начиная с первой версии.
Я не делаю из этого трагедию. Мне кажется изменение названий параметров не есть движение вперед.
Я не вижу принципиальной разницы каким ключевым словом обозначено имя класса в конфигурации будь то
class
или__class
. Как уже было сказано, изменение вызвано необходимостью дать возможность разработчикам свободно объявлять поля или свойства с названиемclass
и задавать для них конфигурацию, например:Тем временем ваши контр-аргументы сводятся к тому, что новая нотация оскорбляет ваши эстетические чувства. Но тут уж ничего не поделаешь. Как говориться "на вкус и цвет товарищей нет".
Some guys cannot understand russian :-)
@lubosdz
That's why I'm replying in English. Short version is that @vyachin doesn't like
class
→__class
change because it's breaking existing app and Paul explains why the choice was made (repeating nearly same words as I've used above).@samdark
OK, thank you.
Since there will be many BC & design changes in 2.1, it might be better to set version 3+ rather than 2.1 to avoid confusions in composer.json.
BTW we are in a difficult situation - we are working (30% done) on a long-term project which should live for 10+ years, we have put lots of efforts into it already ... Now new version with many BC changes is coming out ... should we stick with version 2.0 or wait & rework for 2.1/3.0 with longer life cycle ... What would you do ? :-)
I'd extract more into domain layer that doesn't depend on the framework much i.e. separate classes that do not inherit from anything and cover these w/ tests. These will work regardless of Yii version.
Hi, at first place, this looks great and I can't wait to give it a try :)
Anyway, there is one typo issue in example
There is missin ' at the begining of __class.
Yes. Fixed it. Thanks.
Скажи, какая судьба ждет PJAX в Yii2.1?
Никакой. Не будет его.
Сейчас он крайне удобен. Что будет вместо него? Как будет обновление данных GridView без перезагрузки страницы?
Ничего не будет. Если удобен - берите и используйте, но в самом фреймворке его не будет.
Александр, у вас странная политика. Сначала вы говорите, что Yii очень помогает ускорять разработку из-за многих встроенных плюшек. Но сначала в Yii2 выпилили кучу удобных вещей из JS (например, beforeValidate для формы), потом в 2.1 еще больше выпилите. Под дивизом "Сейчас так модно, поэтому мы разделяем фронсайд и серверсайд", вы убираете из Yii его главное достоинство: быстрота разработки. Зачем выпиливать Pjax, которые крутой, удобный да и еще интегрирован в стандартные компонены только из-за того, что "так не модно"?
Все, что вы делаете с каждой версии, приводит к увеличению кода, а не к уменьшению, это факт. То, как подключать JQuery для формы или GridView в 2.1 (в этой статье), это вообще нонсенс какой-то. Да, придется через контейнер глобально переопределять. Вы правда гонитесь только за модой?
Только не говорите, что это цена за кастомизацию. Я много кастомизировал и Yii1 и Yii2 на больших проектах: все прекрасно правится под себя, этим и крут Yii.
У нас нет возможности его поддерживать. Если есть желание — сделайте удобное расширение. Различаться, если сделаете хорошо, будут только одной строкой в
composer.json
.Спасибо, что ответили. Я понимаю, вы главные разработчики + тратите кучу времени на поддержку.
Остался один вопрос: сообщество согласно с тем, что из "кучи готовых и мощных компонентов, в которых легко все кастомизируется под свои нужды" Yii перерастает в "сильно раздробленную систему, которую нужно собирать"?
Ведь ActiveForm и GridView без встроенного мощного JS используется, я уверен, гораздо реже (я вообще не сталкивался с такми случаями). Поэтому, логичнее иметь мощный встроенный компонент, как сейчас в Yii2. Если нужно кому-то, то может все поотключать.
Пока это первая яркая жалоба на выпил PJAX.
Вот для возможности отключения всё и затевается.
Вот в этом yii\jquery\GridViewClientScript::class будем возможность обновлять GridView без перезагрузки страницы?
Нет, не будет.
Алесандр, зачем выпиливать то, что работает прекрасно? Просто скажите, ради чего стоит теперь тратить больше времени на разработку на Yii? Вы серьезно считаете, что тех, кто хочет сильно кастомизировать тот же GridView больше, чем тех, кто использует в Yii2.0 всю мощь GridView из коробки и что эти, которым нужна кастомизация, не могут ее сделать в 2.0?
Я не хочу вас обидеть, вы делаете огромную работу в Yii, но, правда, не понимаю, ваш странный путь к 2.1, не понимаю логику.
Мне кажется вы не открываете все карты, зачем вы все это делаете. Такое ощущение, что вас ругают тролли, что вы смешиваете JS, HTML и PHP, а вы ведетесь: хотите выпустить модную штуку, забыв о практичности. GridView прекрасно кастомизируется и сейчас, я думаю вы прекрасно это знаете.
Эм... $('#form-id').on('beforeValidate'... вполне себе работает.
Странный вопрос, вы не использовали Yii1? https://yiiframework.ru/forum/viewtopic.php?t=19932
Делаем мы это потому как не хотим жёстко форсировать какой-то один подход к клиентсайду и завязываться на jQuery. Мы не эксперты по тому, как строить фронтенд приложений, поэтому дадим возможность легче работать с AngularJS, React или vue, билдить всё webpack-ом и так далее. Фронтенд развивается сейчас быстрее, чем мы успеваем за ним следить.
@shastox
А, вот вы о чём. В том виде в котором вам хочется пользовались ей раз пять за все годы. Я каждый раз с руганью вспоминал, что для её работы нужно врубить аяксовую и клиентскую валидацию (или какую-то одну из них?).
Соглашусь с тем, что никакого смысла убирать её из Yii2 не было, а утверждения что эта фишка "запутывает" выглядят сомнительными. Даже если поддаться панической истерике фронтовиков "удаляй жиквери, ставь веб-с рак" - переписать на чистый JS достаточно просто.
@batyrmastyr про это и разговор, зачем выпиливать то, что прекрасно работает и многими используется (мощный GridView из коробки), видимо тут идет частичный сход с пути "...разработан практиками для практиков...".
Александр так и не смог ответить, зачем выпиливать крутую вещь, его аргументы сводятся к тому, что "так не модно". Если кому-то так не модно и он хочет использовать что-то стороннее из фронтенда, то пусть использут что угодно. Его в этом ничего не ограничивает.
В любом случае писать здесь что-то бесполезно, котрибьюторы сами решают путь фреймворка.
@shastox Выпиливают потому что он мало кому нужен. Но выше указали что при желании его можно будет подключить через composer, а пакет, уверен, появится сразу, и для пользвоателя pjax ничего особо не изменится.
Примером тут является Symfony, компоненты которой стали своеобразным стандартом.
Нет, они выпиливают его по другой причине:) Чтобы держать его в актуальном состоянии, нужны силы, которых нет. Поэтому лучше выпилить, чтобы их не упрекали "какой у вас PJAX отсталый".
Ну и само выражение "мало кому нужен" спорно, конечно. "Мало кому" так про много чего можно сказать в Yii2, но не выпиливать же это:)
@shastox ну, PJAX-то ни от чего особо не зависит и легко заменяется десятком строчек «наколеночного» кода. Вряд ли в PJAX есть что исправлять, кроме лени тех, кто его исползует ))
Проблема скорее в том, что многие свежие js-библиотеки идут в непригодны для использования без обработки их вебпаком или гульпом, а с ними, в свою очередь, фигово сочетаются механизмы сборки самой yii2.
"Вебпак" и "гульп" - они как-то по особенному работают? Я сжимал CSS и JS теми штуками, что в оф. доке: "yuicompressor.jar" и "compiler.jar" - все работает обалденно.
1) Сейчас модно писать используя новейшие возможности js, некоторые из которых не работают даже в новейших браузерах. Без преобразования в понятный браузерам вид никуда, а с этим нормально справляется только js библиотека babel, насколько я знаю. Если кто ткнёт в альтернативу на php - буду рад.
2) Webpack собирает так, чтобы все нужные зависимости были в наличии. Ему не объяснить, что jquery уже идёт в составе Yii, поэтому приходится костылями отрубать загрузку стандартных скриптов.
Вот мы и пришли к тому, что здесь просто что-то "модно". Именно из-за этого слова и выпилывается Pjax, а то, что он работает отлично, удобен, да встроен по сути - на это всем все равно.
Отрубить же Jquery в Yii2 - там же пара строк. Хотя стойте, опять, не модно:)
И вообще, сейчас куча штук новых появляется: и на сервер-сайде и клиент-сайде. Штуки хорошие, разнообразные, удобные. Но что-то становится популярным, а что-то нет. Главное, чтобы можно было полностью вырубить JQuery и подобные вещи парой строчек кода, что Yii2 и позволяет, а постоянно гнаться за модой... Да ее просто не догнать.
On the one hand, the separation of parts of the backend and the frontend is a good solution and now unnecessary movements are not needed to turn off jQuery to use something else and it will become easier to manipulate the internal and external parts.
However, it is not very pleasant for compatibility with previous versions, you will have to change a lot in projects.
It is not customary to use
`
php __classinstead of
php class`
, and as far as I understood from the example, this should also be used now throughout the project. And this is how much I understood from the example, for the sake of the opportunity to declare a property called`
php class`
. But in what particular situation and for the solution of which problem can this be applied? It was embarrassing to use the`
php as clientScriptparameter instead of making the
php script`
just easier for perception and memorization.I saw a speech here about PJAX, a useful thing, for example, for the same GridView or some commenting system is very convenient. If you cut it like everything else, then with the possibility of using a separately connected package compatible with the new version.
And what is the fate of form validation in ActiveForm? I understand that when you connect using the new method, validation will still work and nothing will fall off?
@condor-bird, that's major version that may break compatibility and will break it for the sake of progress. You don't have to upgrade all your projects, 2.0 is still there.
The
class
property is common if we're talking about scheduling, or classification of something (birds, cars etc.).About cutting PJAX... of course, you will be able to get PJAX as JS library and use it and I'm pretty sure there will be community-maintained wrapper-extensions. The difference is that we aren't going to support these.
Validation will work as it worked before except that for JS one you'll have to use Yii's JS package.
Hi, since 3-4 weeks ago, I am constantly receiving notification like this:
It's getting a little bothering - so how can I cancel receiving feedback notifications from this site? There si no such an option in my profile. Or should I delete all my comments on this page?
Oh, sorry about that. I'll see what I can do. Was busy with Yii 2 release and it was tagged just some minutes ago.