Yii 2.0.11

    Состоялся релиз PHP фреймворка Yii версии 2.0.11. Инструкции по обновлению и установке можно найти на официальном сайте. Версия 2.0.11 содержит более 110 улучшений и исправлений.


    Четыре небольших изменения могут затронуть существующие приложения, так что стоит обратить внимание на UPGRADE.md.


    Огромное спасибо нашему замечательному сообществу. Мы сделали это вместе!


    За процессом разработки Yii 2 можно следить поставив звёздочку на GitHub. Также у нас есть Twitter и Facebook.


    Так как уже ведутся работы над Yii 2.1, убедитесь, что версия фреймворка в composer.json прописана как ~2.0.11. В противном случае после релиза 2.1 проект может поломаться.


    Далее мы рассмотрим самые интересные изменения и улучшения, вошедшие в релиз. Полный список доступен в CHANGELOG.


    Покрытие тестами


    Мы решили не принимать pull request-ы без тестов за редким исключением. Это должно улучшить качество кода и уменьшить время, затрачиваемое на его проверку. Более половины pull request-ов для 2.0.11 были приняты согласно этому решению.


    Некоторые тесты, такие как тесты для менеджера URL, подверглись значительному рефакторингу. Методы стали меньше, читать их стало проще.


    Алексей Рогачёв проделал значительную работу по рефакторингу, исправлению и покрытию тестами JavaScript-части фреймворка.


    Консоль


    В консоли Bash и Zsh стало довольно просто организовать дополнение для команды ./yii. Настройка описана в руководстве.


    Кроме того, при описках консоль подсказывает существующие команды с похожим написанием.


    Кеш


    Стало возможным выставить глобально длительность хранения данных в кеше через yii\caching\Cache::$defaultDuration.


    Появился удобный синтаксис:


    $data = $cache->getOrSet($key, function () {
        return $this->calculateSomething();
    });

    Код выше делает то же, что и:


    $data = $cache->get($key);
    if ($data === false) {
        $data = $this->calculateSomething();
        $cache->set($key, $data);
    }

    Конфигурация


    После продолжительных обсуждений было решено добавить возможность настраивать контейнер зависимостей через основную конфигурацию приложения:


    $config = [
        'id' => 'basic',
        // ...
        'container' => [
            'definitions' => [
                'yii\widgets\LinkPager' => ['maxButtonCount' => 5]
            ],
            'singletons' => [
            ],
        ],
    ];

    Подробнее об этой возможности можно прочитать в разделе «application configurations» официального руководства.


    Ещё немного удобства и синтаксиса


    С каждым релизом, чтобы сделать разработку приятней, мы пытаемся сделать ошибки всё более полезными и точными. 2.0.11 не исключение. Теперь ошибка при попытке обратиться к несуществующему компоненту сообщает, что именно это и случилось. Ранее фреймворк ругался на невозможность автоматической загрузки класса.


    В контроллер добавлены два метода: asJson() и asXml(). Служат они для отдачи данных в формате JSON и XML соответственно.


    Производительность


    • Yii избавился от запросов с условиями вида 0=1, которые использовались для связей в AR.
    • RBAC научился пропускать рекурсивные проверки если роли не присвоены какие-либо разрешения.
    • Валидатор unique теперь выбирает только первичные ключи, а не полный набор данных.

    Ещё одно улучшение напрямую не влияет на производительность, но определённо поможет её увеличить в приложениях. Мы начали логировать использование памяти и процесс сопоставления роутов. Ожидайте соответствующих панелей в следующем релизе модуля debug.


    Базы данных


    В yii\db\Query добавлены три новых метода: filterHaving(), andFilterHaving() и orFilterHaving(). Они похожи на остальные методы filter*, которые добавляют условие только если значение не пусто и обычно используются для различных фильтров.


    Класс yii\db\Connection стало приятнее использовать в случае с конфигурациями master-slave:


    • Добавлена опция shuffleMasters, при помощи которой можно отключить случайный выбор master-соединения.
    • Добавлен метод getMaster() и свойство master. Они позволяют получить текущее активное master-соединение.

    \yii\db\Query теперь можно передавать в insert() как напрямую вторым аргументом, так и в качестве значения одного из параметров:


    $db = Yii::$app->db;
    
    // вставляем query
    
    $sourceQuery = new \yii\db\Query()
        ->select([
            'title',
            'content',
        ])->from('{{post_queue}}');
    
    $command = $db->createCommand();
    $command->insert('{{post}}', $sourceQuery);
    
    // используем query как значение
    
    $titleQuery = new \yii\db\Query()
        ->select('title')->from('{{titles}}')->limit(1);
    
    $command = $db->createCommand();
    $command->insert('{{post}}', [
        'title' => $titleQuery,
        'content' => 'Привет!',
    ]);

    Совместимость с PHP 7


    Мы постоянно проверяем фреймворк на совместимость с PHP 7. К 2.0.11 мы нашли и исправили проблему, связанную с обработкой ошибок и Throwable.


    Менеджер URL


    При генерации URL через UrlManager::createAbsoluteUrl(), Url::to() или Url::toRoute() теперь можно указать схему как пустую для создания протоколо-независимых URL:


    echo Url::to('@web/images/logo.gif', '');
    // //www.example.com/images/logo.gif

    Также при генерации URL стали не обязательными параметры, для которых существуют значения по умолчанию:


    echo Url::to(['post/index', 'page' => 1, 'tag' => '']);
    
    // теперь можно так:
    
    echo Url::to(['post/index', 'page' => 1]);

    Виджеты


    Расширяемость виджетов была значительно улучшена. Добавлены события при инициализации, перед стартом рендеринга и после его завершения. Примеры применения смотрите в описании issue.


    Безопасность


    В фреймворк было включен фильтр HostControl, при помощи которого можно предотвратить атаку через подмену хоста. В идеале её лучше не допускать правильной конфигурацией веб-сервера, но так как поступило довольно много запросов от тех, кто не имеет доступа к настройке
    сервера, решили всё-таки включить данный фильтр в фреймворк. Детально о настройке данного фильтра можно прочитать в руководстве.


    Также была найдена и исправлена проблема с экранированием данных на странице ошибки в режиме отладки. Так как проблема не затрагивает рабочие сервера, мы не стали выпускать отдельный патч-релиз.


    Инсталлятор Composer


    Вместе с релизом фреймворка мы выпускаем новую версию 2.0.5 инсталлера Composer. Этот плагин для Composer отвечает за установку расширений и позволяет обходиться без конфигурации в процессе бутстрапинга. Также он выполняет разные задачи при создании нового проекта. Благодаря Robert Korulczyk, стало возможно выполнять задачи и при composer install, что особенно важно для обработки локальных файлов конфигурации, которые теперь можно копировать при помощи нового метода copyFiles. Более детально можете почитать в README.


    Также плагин начал при обновлении пакета yiisoft/yii2 уведомлять о важных изменениях из UPGRADE.md.


    Подписанные коммиты и теги


    Это первый релиз, с подписанным GPG тегом, что позволяет проверить, что он сделан командой Yii. Позже мы опубликуем детальные инструкции по проверке.


    На GitHub подписанные теги можно отличить по надписи "verified": https://github.com/yiisoft/yii2-framework/releases/tag/2.0.11.

    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 112
    • +5
      Спасибо. И за фреймворк и за новость.
      • 0
        Дякую за проведену роботу, буде що підучити:)
        • +1
          Отличная новость!) Какие дальнейшие планы?
          • +1

            Релизы расширений, новый сайт, yiipowered, 2.1.

            • 0
              Что такое yiipowered?
              • +2
                Yii powered websites showcase
                https://github.com/samdark/yiipowered
                • 0
                  А каков собственно функционал этого добра?
                  • +1

                    Будет принимать от всех желающих информацию о проектах, сделанных на Yii, и показывать её.

          • 0
            А когда откажетесь от поддержки php 5.4? Я понимаю что это круто (старые версии и шаред хостинги), но все же…
            • +1

              В 2.1.

              • 0
                В сторону php 5.6?
                • 0
                  А смысл, если уже есть производительный 7?
                  • 0

                    Фреймворк и сейчас работает отлично на семёрке. И да, быстрее. Рекомендую обновиться, если ещё нет.

                    • 0
                      На семерке был замечен баг, когда выключение режима отладки увеличивало общее время генерации страницы и ответа сервера.
                      проверено было на двух хостингах и двух разных проектах, это было поправлено или не обращали на это внимания?
                      • 0

                        Это ожидаемо. В режиме отладки пишутся для этой самой отладки дополнительные данные.

                        • 0
                          выключение режима отладки увеличивало общее время

                          Либо Вы не поняли, либо человек опечатался.
                          Но если опечатался, то это да, капитанство получается.
                          • 0

                            А если не опечатался, то я не в курсе и надо это на github...

                            • 0
                              нет, не опечатался :) в том то и дело
                              • 0

                                Интересно. Ждём на github с замерами и способом воспроизвести...

                                • 0
                                  хорошо, посмотрю :)
                                  я замерял давно уже. проверю еще раз
                                  до этого были примерно такие показатели на PHP 7.0.X
                                                YII_DEBUG(TRUE)      YII_DEBUG(FALSE)
                                  Проект1       45 Мсек                   50 Мсек
                                  
                                  
                                  Проект2      700 Мсек                  750 Мсек
                                  
                                  
                      • +1
                        сразу на 7? вроде нижнюю планку обсуждали. Клиенты с простыми сайтами не всегда готовы идти на VPS
                        • 0
                          5.6 уже на security support, т.е. всё.
                          • +1

                            И? Это не наша проблема. Если технически фреймворк работает с 5.4 и проблем ни в поддержке ни в работе с PHP 7 это не вызывает, зачем завышать требования?

                            • –1
                              я не про завышение, а про неразумность выбирать в качестве нового минимума версию, уже снимаемую с поддержки. А повышать или не повышать — дело команды.
                              • 0

                                Если бы вопрос выбора сопровождался бы написанием тучи polyfill-ов для этой версии, повышали бы до семёрки не задумываясь. А так как уже всё написано, покрыто тестами и работает, смысла нет.

                                • –1
                                  Александр, ты продолжаешь о чем-то своем рассуждать. Речь идет о выборе минимально поддерживаемой версии во время предполагаемого перехода в одной из мажорных версий фреймворка. Ни полифиллы ни тесты здесь не причем.
                                  Переход должен быть потому, что 5.4-5.5 уже не поддерживаются даже фиксами безопасности, что создает брешь и в вашем продукте. По этой же причине следующая минимальная версия должна быть поддерживаемой (5.6 на излете).
                                  • +3
                                    А зачем? Выбор версии софта на сервере это не ответственность фреймворка.
                                    Если он МОЖЕТ работать на старом, то он должен на нем работать.
                                    Допустим у человека сервер завязан на 5.4 и он не может его проапгрейдить потому что на сервере есть другой софт со своими зависимостями. Но прикладного кода не много, и он тривиален, поэтому совместимость с прошлой версией фреймворка сохраняется или легко апдейтится. Разработчик хочет перейти с 2.0 на 2.1. Но тут мы ему такие специально подляну всунули — код может работать на 5.4., но мы решили подумать за него и всунуть ему в композер зависимость на пхп7. Вот с какого перепуга?
                                    • –1
                                      поддержка определенной версии — это не столько вопрос плюшек новых версий, сколько вопрос уверенности пользователя (т.е. разработчика/заказчика) в стабильной его работе на данной версии. Заявляя поддержку версии, которая уже не получает фиксов безопасности, ты подставляешь своих пользователей, т.к. не обеспечиваешь эту самую стабильную работу. Поэтому каждая мажорная версия должна поднимать минимально поддерживаемую фреймворком версию вслед за минимальной поддерживаемой версией php его разработчиком.
                                      • +3
                                        Это не ответственность фреймворка.
                                        Обновление версии пхп это ответственность админа, хостера, кого угодно, но не фреймворка. Может сервер живет настолько глубоко, что при всем желании и возможности туда не достучаться злому дяде. Но на нем стоит кастомная сборка пхп5.4, с кастомным расширением в виде бинарника, и выпуск этого расширения под пхп7 неизвестно когда будет. При этом юии2.0 будет менее безопасен чем 2.1 (ну возьмем экзотический случай, что мы дожили до снятия с поддержки 2.0, но еще хотим пхп5.4, ну вот сферический конь в вакууме, но мало ли какие будут комбинации). И вы вынуждаете использовать устаревший софт, просто потому что «так нада».
                                        одно дело писать в документации что мол настоятельно рекомендуем обновить пхп, что скоро мы можем прекратить его поддержку и т.п. Но… писать в требованиях не то что надо, а то что кажется верным по религиозным соображениям — моветон.
                                        • 0
                                          Это не ответственность фреймворка.
                                          это отвественность создателей продукта — поддерживать минимально безопасную экосистему
                                          Но… писать в требованиях не то что надо, а то что кажется верным по религиозным соображениям
                                          вот такой вот уровень дискуссии — представить мнение, которого придерживается большинство мейнетейнеров фреймворков, религиозным, т. е. маргинальным.
                                          • 0

                                            Безопасность тут не при чём. Смотрите: http://php.net/supported-versions.php


                                            5.6 в плане безопасности поддерживаться будет дольше, чем 7.0.

                                            • –1
                                              именно. поэтому и выбирать в качестве минимальной можно не 5.6 и 7.0, а 7.1. но с учетом распространения версий и функциональных изменений разумнее будет выбрать 7.0, которую в качестве минимальной выбирают все зарелизенные в последние полгода популярные в комьюнити библиотеки (от symfony/laravel до phpunit). А мы кстати говорим о 2.1, релиз которого вряд ли произойдет ранее второй половины года, а то и вообще не в 2017, судя по прошлой динамике.
                                              • 0

                                                Ну чем разумнее-то? У неё поддержка по времени меньше, чем у 5.6. 7.1 — да, разумно выбрать с точки зрения поддержки, но не разумно потому как никто его ещё не использует и массового перехода в ближайший год не будет.

                                                • –1
                                                  одинаковая у нее подержка. разница в 3 недели.
                                                  • 0

                                                    Ну тогда почему обязательно 7, а не 5.6?

                                                    • –1
                                                      для стимулирования комьюнити. если бы не было 2.0, то комьюнити до сих пор не знало бы что такое неймспейсы (на форуме и сейчас, в 2017 вылазят люди и говорят, что за неймспейсы вы придумали).
                                                      • 0

                                                        Для стимулирования мы уже написали в гайде "runs best with PHP 7.0+" и на сайте на главной напишем большими буквами. Но требовать это через composer.json, всё-таки, не стоит.

                                                • 0

                                                  То, что трендово и модно — не отрицаю. Рационально — нет.

                                                  • –1
                                                    yii2 — не про энтерпрайз. не стоит поддерживать все старье в новых мажорных версиях.
                                                    • 0

                                                      Ну, если IBM, Facebook, Альфа-групп, мэрия Москвы, минфин Украины, РТРС, FIFA — это всё не enterprise, то хорошо...

                                                      • –1
                                                        а) смешно (уверен в этом списке нет ничего кроме визиток и небольших личных кабинетов — про фейсбук например я точно помню, что там было.)
                                                        б) никто не говорит о миграциях старых продуктов на новые мажорные версии
                                                        • 0

                                                          а) Есть. IBM — сеть моллов в Китае. Альфа-групп — биржа. РТРС — весь интранет с внутренними процессами. FIFA — часть интранета. Facebook, мэрия Москвы, минфин Украины — да, по сути CMS.
                                                          б) И как их поддерживать?

                                                          • –1
                                                            вы и не будете их поддерживать, т.к. вы не энтерпрайз. поэтому когда к вам в issue прибегут с проблемой взломов сайтов на yii2, использующих 5.4.*, вы разведете руками — поддержка 5.4 кончилась. Поэтому в ваших же интересах указывать версии php с более долгим сроком поддержки. Проблема в php, а репутация пострадает ваша.
                                                            • 0

                                                              Если у нас в требованиях будет 5.4, руками мы не будем разводить, а решим проблему, если она решаема PHP-кодом, или поднимем минимальные требования, если нет.

                                                              • 0
                                                                и сломаете обратную совместимость
                                                                • 0

                                                                  Ну а какие ещё варианты есть, если её нельзя не сломать?


                                                                  1. Сломать.
                                                                  2. Выпустить новую мажорную версию и задепрекейтить текущую.

                                                                  По сути это одно и то же. Версионирование только отличается.

                                                                  • 0
                                                                    Ну а какие ещё варианты есть, если её нельзя не сломать?
                                                                    при разработке новой мажорной версии выбрать в качестве минимума не 5.6/7.0, а 7.1/7.2.
                                                                    ломать совместимость — это почти то же самое что ничего не делать, т.к. формально вы предлагаете переписать приложение написанное под одну версию php на другую. У кого-то опытного заработает без допилки, а у кого-то весь код в задепрекейченных в новой версии php функциях. В прицнипе звучит достаточно просто, но формально неправильно.
                                                                    • 0

                                                                      Формальное несоблюдение SemVer да, в этом случае будет. Согласен.


                                                                      С другой стороны, какова вероятность того, что 2.1 с 5.6 проработает до начала 2019 без проблем? Как по мне, довольно высокая. Выбирать сейчас 7.1, как по мне — отбить охоту использовать фреймворк у тяжеловесов вроде IBM. Согласование мажорные версии у них проходит с большим скрипом как раз под конец официальной поддержки (знаю по Oracle и Siemens). Выбирать 7.0, если отбросить генерацию хайпа и рассматривать только проблемы с безопасностью, бессмысленно.

                                                                      • 0
                                                                        Выбирать сейчас 7.1
                                                                        ну когда вы собираетесь 2.1 выкатывать? далеко не сейчас же.
                                                                        отбить охоту использовать фреймворк у тяжеловесов вроде IBM
                                                                        ну что они, на шаредах что ли сайты пилят?) сейчас докер очень популярен в т.ч. и у монстров рынка, а через год и того больше.

                                                                        С другой стороны, какова вероятность того, что 2.1 с 5.6 проработает до начала 2019 без проблем? Как по мне, довольно высокая
                                                                        ну по мне вероятность довольно высокая чуть ли не на любой версии проработать стабильно разумное кол-во лет. Хоть на 5.4. Но в то же время то одно то другое — curl, openssl, а это все связано.
                                                                        • 0

                                                                          Когда соберёмся выкатывать, тогда пересмотрим этот вопрос ещё раз.

                                              • +1
                                                Религиозное это значит «дело вкуса» а не маргинальное.
                                                Про SOLID слышали?)
                                                Шучу, шучу. Понятно что слышали, и вопрос не без сарказма.
                                                Я намекаю на то, что не нужно смешивать ответственности.
                                                У каждого инструмента своя ответственность. И если фреймворк сообщает (в автоматическом виде например композеру или текстом в документации, не суть) что его технические ТРЕБОВАНИЯ такие-то, то этот инструмент предназначен для информирования о технических ТРЕБОВАНИЯХ. Можно отдельно писать рекомендации. Можно делать секьюрети-рассылки. Но не нужно навязывать одному инструменту две функции. В требованиях указывается требование. Всё. Если мы будем засовывать в требования пожелания по безопасности, то мы вернемся к лапше девяностых. Во всём.

                                                ПС: я бы допустил разговор о завышенных требованиях в шаблонах приложений, но точно не во фреймворке.
                                                Ну и комментарий, да. Мол требуем больше чем надо ибо вы ребятки обновляйтесь а не спите.
                                                • 0
                                                  У каждого инструмента своя ответственность. И если фреймворк сообщает (в автоматическом виде например композеру или текстом в документации, не суть) что его технические ТРЕБОВАНИЯ такие-то, то этот инструмент предназначен для информирования о технических ТРЕБОВАНИЯХ. Можно отдельно писать рекомендации. Можно делать секьюрети-рассылки. Но не нужно навязывать одному инструменту две функции.
                                                  если я правильно понял, вы против того, чтобы указывать в composer.json зависимости библиотеки — их надо «рекомендовать» в отдельном месте. Либо же вы отделяете зависимости в виде библиотек от зависимости в виде интерпретатора, как будто бы мейнтейнеры должны требовать установки определенных версий библиотек, на которых гарантируется стабильная работа фреймворка, но не должны требовать версию интерпретатора, потому что что-то.
                                                  • +1

                                                    Если свежая версия интерпретатора по факту не требуется для работы кода, зачем указывать её в composer.json?

                                                    • 0
                                                      для стабильной работы. вы не поддерживаете php и сторонние либы, поэтому указываете те версии, на которых гарантируете стабильную работу фреймворка. Либо сами пишите патчи для зависимостей. Вы не энтерпрайз, поэтому непонятно почему вы не можете более свободно относиться к зависимостям, не ломая совместимости в рамках семвера.
                                                      Если сейчас было бы уместно указать 5.6/7.0, то к моменту выхода 2.1 до конца поддержки останутся месяцы, дай бог год.
                                                      • 0

                                                        Именно. Не требуется 7.0 для стабильной работы. Мы гарантируем, что 2.1 работает прекрасно на 5.6. Если в процессе разработки 2.1 потребуется технически 7.0 или найдут фатальный недостаток в 5.6, выставим в зависимостях 7.0.

                                                        • 0
                                                          поэтому сообщество зенда, симфони, ларавела будет всегда профессионально развитее, а сообщество yii2 будет состоять из динозавров.
                                                          Симфони/Ларавел УЖЕ на 7.0. Зенд УЖЕ на 5.6. PhpUnit6 уже на 7.0. Большинство библиотек из обзора php-новостей на хабре УЖЕ на 7.0. А мы обсуждаем с кор девелопером yii 5.6 или 7.0 выбрать ЧЕРЕЗ ГОД.
                                                          • 0

                                                            Ну как уже, когда Laravel только собирается, Symfony — не ранее ноября. PHPUnit поднял версию ради поднятия версии. Просто потому что все прыгают и я прыгну. Технически в этом необходимости не было. Теперь будут поддерживать несколько веток.


                                                            Профессионально развитее потому что фреймворк не работает на 5.6 и при этом не использует ничего из 7.0? Да ладно вам. Я бы ещё понял если бы аргументом была большая степень абстракции или меньшая связанность, но не это...

                                                            • 0
                                                              Ну как уже, когда Laravel только собирается, Symfony — не ранее ноября.
                                                              да, ок был не прав. казалось, 3.3 уже вышла. Но тенденция ясна.

                                                              Технически в этом необходимости не было
                                                              да и не должно быть. Вы не энтерпрайз. Вам надо хайп ловить, привлекать новых членов комьюнити за счет трендов и баззвордов.
                                                              • +2

                                                                Мне очень не хотелось бы в PHP видеть ту же картину, что и в JavaScript: новый тренд каждые два месяца. Начинаем делать проект на трендовом фреймворке, к релизу он уже безбожно "устарел" и не поддерживается официально. Одно дело программировать ради фана и просто забивать на любую поддержку, и совсем другое — делать основу, на которой строятся и поддерживаются годами отличные проекты.

                                                                • +1
                                                                  Новые тренды ради новых трендов и академичность ради академичности. Главные болячки мейнстрима среди проф.решений.
                                                                  В этом же контексте выплывает другая проблема — меняющиеся как кадры фильма версии без обратной совместимости не дают полноценно вырасти стабильной экосистеме.

                                                                  Не поймите меня превратно. Вордпресс безнадежно устарел, и да, я никогда не считал его фреймворком в отличии от многих ВПфилов. Но его устаревание и его популярность это две стороны одного явления — преемственности. При всем желании ВП не может перейти на ООП, MVC и т.п. Он потеряет совместимость и перестанет быть ВП. Не ратую за то, чтобы застревать в девяностых как ВП, но понимать чего стоит гонка за модой тоже нужно.
                                                    • 0
                                                      В зависимостях должны указываться зависимости. Это понятно?
                                                      Юии зависим от 5.4, значит надо указать его зависимость — 5.4.
                                                      Библиотеки тянутся с гитхаба одинаково хорошо, что старые, что новые, так что мешать не стоит. Плюс опять таки — минорную версию лучше указывать ту которая реальная зависимость, ведь компостер сам подтянет тебе посвежее из совместимого и стабильного.
                                                      Нет, хотите строгости и паранойи? Я вас понимаю. Глядя как в первом Юии (со вторым плотно не работал, только в уже готовое что-то дописывал, так что не слежу) половина вечно забывала включить проверку XSRF у себя я делаю такие вещи по умолчанию, а если хочешь без них, то отдельно отключай. Хотите паранойю — сделайте отдельную библиотеку, назовите ее например секьюритиТест или секьюритиПак, туда пристройте все зависимости, все строгости, все проверки и замечания. Так будет ок, так будет СОЛИДно. :)
                                        • +2
                                          Полностью поддерживаю. Сам в свое время перешел на 5.4 только потому что задолбался с array(). По факту конечно скорее всего есть и другие зависимости от 5.4., но когда требование на 5.4 уже есть, то дальше уже не смотришь. А всё остальное (почти всё) некритично, и стараешься писать слишком не злоупотребляя свежатиной, а когда основной костяк уже написан, то и поддерживать обратную совместимость не приходится особо. Старый код УЖЕ есть. Чисто под проект можно вводить более свежие зависимости, но ядро то зачем?
                        • +1

                          Очень классная новость!

                          • 0
                            Я долго ждал конфигурации DI через config и вот, наконец-то, дождался. Спасибо! ))
                            • +1
                              Как я с Вами солидарен, сударь. Это, пожалуй, самая приятная новость)
                            • +1
                              Только queue модуля не хватает для полного счастья.
                              • 0

                                Когда-нибудь и его допилим.

                                • +1
                                  Я уже себе допилил github.
                                  Могу помочь или просто перенести в официальный пакет если есть интерес.
                                  • 0

                                    Да так много кто сделал. В issue https://github.com/yiisoft/yii2-queue есть ссылки.

                                  • +1

                                    Неплохая реализация, кстати. Эх, скоординироваться бы вам всем...

                                    • 0
                                      Объяви официальную инициативу :)
                                      Придётся конечно помучаться, но по другому как правило это не происходит :)
                                      • 0
                                        А что скажете про https://github.com/urbanindo/yii2-queue

                                        Мне гораздо больше понравилось.
                                        Ещё бы глянуть примеры реальных реализаций где-нибудь.
                                        • 0

                                          Не очень понравилось, что воркеры реализованы контроллерами. А так примерно то же.

                                          • 0
                                            Я может непонятливый, потому что новайс. Но не понял как у Журавлёва сделать чтобы в случае если задание не отработало нормально, оно не удалилось из очереди. Вот у этого Urbanindo можно явно вернуть false из метода — и всё.
                                            • 0

                                              Застревать ли заданию в очереди, перекидываться в другой воркер или что-то исправлять зависит от ситуации и должно реализовываться в воркере.

                                              • +1

                                                Повторно отправить задание в очередь из Job-объекта можно так:


                                                class SomeJob implements Job
                                                {
                                                    public function run()
                                                    {
                                                        Yii::$app->queue->push($this); // <--
                                                    }
                                                }
                                                • 0
                                                  А почему так правильней?
                                                  • +1

                                                    Потому что не убирать из очереди при фейле — далеко не единственный вариант.

                                                    • 0

                                                      Не могу сказать однозначно что правильно, а что — нет. Вариант, который вы озвучили, вполне имеет право на жизнь на ряду с прочими. Только я бы не на return ориентировался, а на перехват исключения брошенного в процессе выполнения задания. С ним проще. Его можно положить в лог, чтобы потом разобраться в причине отказа. Ну и кол-во попыток должно быть фиксированным. Потому что ошибки бывают разные. При одних действительно стоит повторить попытку, а вторые — просто ложить в лог по тихому. В общем, нужно думать и обсуждать.


                                                      А так, стоит понимать, что отправленное в очередь задание — это неотъемлемая часть логики реализованной в рамках основного процесса, но, по причине своей ресурсоемкости, вынесенная в отдельный процесс. То есть, код должен быть организован так же, как если бы вы его делали в рамках основного процесса. Если нужно перехватывать какие-то ошибки и перезапускать, то лучше делать это в коде самого job-а индивидуально.

                                                      • 0
                                                        Ну вот я добрался до реализации когда, пришлось городить менеджмент очереди, с проверкой количества попыток, и отложенным запуском.
                                                        Имхо это всё же не должно быть в коде задания. Это дело очереди, заниматься его запуском, и всему к этому относящемся. Ну да, возможно придется сделать несколько разных типов очередей, который по разному себя ведут при невыполнении задания. Но все же по моему так логичнее.

                                                        Потому что сейчас получается что если я сделаю queue/listen у меня будет запускаться задание по миллиону раз в секунду, и тут же выходить, потому что таймаут очередной попытки его выполнения не прошел ещё.

                                                        А если запускать гранулярно через крон и queue/run то сложно будет подобрать интервал запуска, не слишком частый и не слишком редкий.

                                                        Разве что делать по собственной очереди на каждый тип заданий.
                                                        • +1

                                                          Обычно как раз и делается по собственной очереди на каждый тип заданий.

                                                          • +1
                                                            Мда. Видимо это просто два разных подхода. И мне нужен прямо противоположный этому :)
                                    • 0
                                      Пожалуйста прокомментируйте этот код
                                      $data = $cache->getOrSet($key, function () {
                                          return $this->calculateSomething();
                                      });
                                      

                                      Почему вы считаете передачу методу параметром анонимной функции обратного вызова
                                      Появился удобный синтаксис
                                      • +2
                                        Меньше буковок печатать.
                                        Код выше делает то же, что и:
                                        $data = $cache->get($key);
                                        if ($data === false) {
                                            $data = $this->calculateSomething();
                                            $cache->set($key, $data);
                                        }
                                        

                                        А чем вас смущает новый синтаксис? Никто не запрещает по-старинке расписать все явно.
                                      • –2
                                        Меня не смущает и абсолютно не интересует, что делает код.
                                        Я спрашиваю где здесь удобство синтаксиса
                                        Как по мне удобство синтаксиса
                                        $data = $cache->getOrSet($key);
                                        
                                        • +1

                                          А данные откуда брать, если в кеше их не оказалось?

                                          • –2
                                            если в кеше их не оказалось

                                            null, false
                                            и это к реализации
                                            вы же привели пример в качестве удобного синтаксиса
                                            вот про синтаксис и говорим
                                            • +2

                                              Вы привели совсем не эквивалент. То, что у вас — это обычный $cache->get, который в таком виде уже давно существует. То, что в релизе — это getOrSet. То есть попробовать получить из кеша и, в случае отсутствия, вычислить и сунуть в кеш.

                                        • 0
                                          Вы можете написать реализацию без callback
                                          Код будет читабельный, редактор будет воспринимать
                                          Вы же привели частный случай и описали как некое удобство.
                                          Нет здесь удобства, функция анонимная вместо именной. Обратный вызов без которого легко обойтись.

                                          • +2

                                            Как обойтись без обратного вызова?
                                            Если


                                            $data = $cache->getOrSet($key, $this->calculateSomething());

                                            То эквивалентом будет


                                            $default = $this->calculateSomething();
                                            $data = $cache->get($key);
                                            if ($data === false) {
                                                $data = $default;
                                                $cache->set($key, $data);
                                            }

                                            Только в таком случае кеш бесполезен

                                            • 0
                                              Как обойтись без обратного вызова?

                                              Просто
                                              class Cache
                                              {
                                                  private $storage = [];
                                              
                                                  public function get($key)
                                                  {
                                                      return $this->storage[$key] ?? null;
                                                  }
                                              
                                                  public function set($key, $value)
                                                  {
                                                      $this->storage[$key] = $value;
                                                      return $value;
                                                  }
                                              }
                                              $cache = new Cache();
                                              $result = $cache->get('Igor') ??  $cache->set('Igor', 20);
                                              var_dump($result);
                                              

                                              Вы опять про реализацию, а я про синтаксис спрашивал
                                              • +1
                                                <irony> хоспади, люди просто добавили сахара, чего ж вы к синтаксису приклепались?)) </irony>
                                                • +1

                                                  А что не так с синтаксисом? Самый удобный вариант. Вы приводите пример с готовым значением 20. А где и как вы его будете получать? Вот именно этим и будет заниматься колбэк, если в кеше еще нет готового значения.


                                                  Наиболее распространенный кейс использования кэша:


                                                  if (($value = $cache->get($key)) === false) {
                                                      // Тут код ресурсоемкой операции, результат которой нужно закэшировать
                                                      $value = 123; 
                                                      $cache->set($key, $value);
                                                  }

                                                  Теперь можно так:


                                                  $value = $cache->getOrSet($key, function () {
                                                      // Код операции, результат которой нужно закешировать
                                                      return 123;
                                                  });
                                                  • 0
                                                    А что не так с синтаксисом?

                                                    Хорошая манера вопросом на вопрос отвечать
                                                    Вы приводите пример с готовым значением 20
                                                    $value = $cache->get($key)?? $cache->set($key, $this->calculateSomething());
                                                    Считаю, что код в одну строку, лучше читаем и понятен

                                                    • 0
                                                      В кеше вполне может быть значение null и в этом случае ваш код будет всегда перекешировывать этот null. В «удобном» же варианте такого не должно происходить. Да и set метод скорее всего возвращает void.
                                                      • 0
                                                        В кеше вполне может быть значение null

                                                        И что? Внимательно читайте посты пожалуйста.
                                                        Вы уже второй человек который у меня спрашивает про реализацию.
                                                        Вопрос был
                                                        Я спрашиваю где здесь удобство синтаксиса

                                                        За минусы спасибо. Прикольно когда за спрос бъют
                                                        • +1

                                                          Вам объясняют что, тот вариант, в одну строку, который вы предлагаете, не рабочий. И, чтобы его рабочим сделать, одной строки не хватит. get() может вернуть null, а set() возвращает результат записи в кэш, а не значение, которое вы туда пишите.


                                                          Удобство в том, что \yii\caching\Cache::getOrSet универсальный метод, который корректно покрывает наиболее распространенный кейс.


                                                          Единственное, если бы параметр \Closure $closure не стали бы делать типизированным, было бы проще. Тогда вариант в одну строку с вашей функцией мог бы выглядеть так:


                                                          $value = $cache->getOrSet($key, [$this, 'calculateSomething']);

                                                          Но и с анонимной функцией вполне удобно:


                                                          $value = $cache->getOrSet($key, function () {
                                                              return this->calculateSomething();
                                                          });

                                                          С читабельностью все в порядке. Не пойму что именно вас смущает? Анонимные функции?


                                                          Минусы не мои.

                                                          • 0
                                                            в вашем варианте тогда get при false считается невалидным, что если результат надо закешировать false. Почему я выбрал null
                                                            ей еще не было присвоено никакого значения

                                                            Почему set вернул значение, да потому, что это удобно в синтаксисе. Не только возвращать this для вызовов цепочкой, но и value иногда в set пример от fatfree
                                                            Чтоб не говорили, что мой код не рабочий. (php7)

                                                            Песочница 1
                                                            $result = $cache->get('Igor') ??  $cache->set('Igor', query());
                                                            

                                                            Песочница 2
                                                            $result = $cache->get('Igor',  $cache->set('Igor', query()));
                                                            

                                                            set() возвращает результат записи в кэш

                                                            В примере приведенном в статье автором set ничего не возвращает

                                                            И теперь о главном, мой вопрос звучал о синтаксисе, а не о реализации.
                                                            • 0

                                                              Второй вариант не работает

                                                              • 0
                                                                Переписал немного
                                                                $result = $cache->getOrSet('Petr', $query);
                                                                

                                                                Закругляюсь всем спасибо за диалог
                                                                • +1

                                                                  Собственно, вы пришли к варианту, описанному в посте

                                                              • +1

                                                                Вы сейчас про альтернативную реализацию кэша. А причем тут Yii2?

                                                                • +1
                                                                  вы про абстрактный кеш в вакууме, а мы про кеш в yii2. сдается мне, что вы не до конца разглядели как и что возвращает кеш в yii. Ваши примеры имеют право на жизнь и они даже местами приятны взору, но разговор опять же о yii2
                                                • 0
                                                  За дефолтные параметры при генерации урлов отдельное спасибо. Еще бы DI в вызов экшенов (в крайнем случае в конструктор контроллеров).
                                                  • +1

                                                    В конструкторе есть.

                                                  • 0
                                                    Уберите наконец bower assets :) 2017 год на дворе…
                                                    • +1

                                                      А что нынче популярно в мире JS?

                                                      • 0
                                                        Да все то же самое, bower, npm, yarn вот новый. Да только 1) что делают фронтенд пакеты в коре, нафиг они нужны, если делать Rest API, 2) плагин надо ставить непонятный, да ещё и глобальный, 3) плагин отвратительно ищет в Bower, кучу времени занимает это. Я как бы понимаю, зачем все это, типа, чтоб ассеты пачкой тащить и бакенд и фронтенд, формы там валидировать, аяксы слать. Но в базовой поставке все это — лишнее.
                                                        • +1

                                                          Этот вопрос уже много раз поднимался и много раз был дан ответ, что в 2.1 мы постепенно выпиливаем frontend-зависимости из ядра.


                                                          Про плюсы и минусы медленного SAT-солвера для PHP и JS сразу мы, естественно знаем.

                                                          • 0
                                                            Да-да, я даже видел тред где говорилось, что это было большой ошибкой включать подобное в ядро. Однако вчера я смотрел в ветку 2.1 и там пока все присутствует… очень ждём :)

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.