1. стварэнне праекта
2. канфігураванне сервера
3. канфігурацыя прыкладання
4. разгортванне канфігурацыі

У каментарах да папярэдняй артыкуле з'явілася прапанова пакрокава разабраць працэс распрацоўкі цэлага прыкладання на Yii2. Інструкцыя па стварэнні блога выкладзеная ў афіцыйным кіраўніцтве. Пакуль для першай частцы, але гэта, думаю, ненадоўга. Вядома ж, там не было раскрыта спецыфічных момантаў, але, тым не менш, кіраўніцтва мелася. Яно адкрыта для змен: кожны знаёмы з сістэмамі кантролю версій можа гэта кіраўніцтва і блог дапрацаваць.

Мне прыходзілі думкі аб апісанні распрацоўцы інтэрнэт-крамы, але гэта такая шырокая тэма, што хопіць на цэлую кнігу. Дарэчы, а ці не напісаць мне кнігу? Можа быць. Але пакуль не пра гэта.

Кожны які трапіў у інтэрнэт праграміст ў душы крыху SEO-шнік. Шмат у каго акрамя свайго блога маюцца якія-небудзь праекты для заробку на кантэкстнай рэкламе. І некаторыя нават удзельнічаюць у разнастайных марафонах і адкрываюць новыя.

Ўспамінаецца тое дзіўнае пачуццё, калі некалькі дзён збіраеш, прасейваць і разгруппировываешь па меркаваным артыкулах семантычнае ядро ​​з тысяч пошукавых фраз ... У выніку малюеш сайт, скідваюць групы запытаў у Excel-файл «Новыя».

Потым паслядоўна складаеш заданні для копірайтэр і заказваеш тэксты на біржы. Перакідаць гэтыя запыты ў «Замоўленыя». Па напісаных артыкулах перамяшчаліся ў «Змешчаныя». Потым для размешчаных ўказваць адрас старонкі і прыпісваеш ўваходзяць спасылкі з іншых сайтаў. Ня забываеш пры гэтым лічыць ўнутраныя спасылкі для перелинковки ...

Але, як я і казаў пры напісанні генератара твітаў , Праграміста хлебам не кармі - дай над чым небудзь затлуміць. І для сябе я вырашыў пакінуць у мінулым пакуты з Excel і напісаць сэрвіс для кіравання ключавымі фразамі ядра. У якасці фреймворка, адпаведна, выбраў новы Yii2.

стварэнне праекта

Yii2 даступны для хуткай устаноўкі з рэпазітара. Мы ўжо трохі пазнаёміліся з ім у адпаведнай артыкуле аб Composer . Там добрыя відэа-даклады. Яшчэ мы прыкольна правялі час на практыкуме па Git і Composer. Так што таксама набыць запіс пачаткоўцам раю :)

Файлавую структуру можна выбраць з стандартных шаблонаў yiisoft / yii2-app-basic і yiisoft / yii2-app-advanced. Першы зроблены па тыпу Yii1 для простых канфігурацый з адным даменам. Другі, наадварот, уладкованы для поўнага падзелу прыкладання на карыстацкую частка і модуль адміністравання.

Гэтыя шаблоны таксама даступныя для ўстаноўкі з рэпазітароў. Перад устаноўкай нам трэба зайсці ў тэрмінал і праверыць працу PHP у кансольным рэжыме, выканаўшы:

php -v

Калі вы выкарыстоўваеце Denwer ў Windows і гэты выклік не спрацуе, то трэба зайсці ва Ўласцівасці кампутара → Дадатковыя параметры сістэмы → Зменныя асяроддзя, знайсці сістэмную зменную Path і праз кропку з коскай дадаць туды ваш шлях Z: \ usr \ local \ php5, пасля чаго для прымянення параметраў перазагрузіць сістэму і запусціць сервер.

Цяпер трэба любым зручным спосабам загрузіць файл composer.phar. Гэта ні што іншае, як камплект PHP-скрыптоў, які распаўсюджваецца ў выглядзе PHAR-архіва. Запусціць яго можна ў кансолі як любы скрыпт.

Простае запампоўка файла composer.phar ў тэчку падыдзе, напрыклад, калі вы працуеце ў кансолі на хостынгу. Гэта зручна, калі хостынг дае доступ па SSH як, напрыклад, гэты .

А наогул, у Linux я аддаю перавагу ўсталёўваць Composer прама ў тэчку / bin:

php -r "readfile ( 'https://getcomposer.org/installer');" | php - --filename = composer --install-dir = / bin

Цяпер зайдём у тэрмінал і выканаем:

php composer.phar create-project --prefer-dist yiisoft / yii2-app-basic project

або ў Linux з устаноўленым у сістэму скрыптам:

composer create-project --prefer-dist yiisoft / yii2-app-basic project

Тут мы папрасілі мэнэджара залежнасцяў Composer спачатку ўсталяваць сабе убудова для працы з мэнэджарам Bower, а потым дадаць тэчку project і стварыць у ёй новы праект па шаблоне yiisoft / yii2-app-basic. Мы тут не сталі паказваць сцяг --stability = dev, бо не хочам спампоўваць нестабільныя версіі пакетаў.

Пры гэтым сам шаблон будзе разгорнуты ў корані, а ўсе патрэбныя залежнасці запампаваныя ў паддырэкторыю vendor. На экране мы ўбачым ўвесь гэты працэс:

Installing yiisoft / yii2-app-basic (2.0.3) - Installing yiisoft / yii2-app-basic (2.0.3) Downloading: 100% Created project in project Loading composer repositories with package information Installing dependencies (including require-dev) - Installing ezyang / htmlpurifier (v4.6.0) Downloading: 100% - Installing swiftmailer / swiftmailer (v5.3.1) Downloading: 100% - Installing yiisoft / yii2-debug (2.0.3) Downloading: 100% ... - Installing yiisoft / yii2-gii (2.0.3) Downloading: 100% - Installing fzaninotto / faker (v1.4.0) Downloading: 100% - Installing yiisoft / yii2-faker (2.0.3) Downloading: 100% Writing lock file Generating autoload files chmod ( 'runtime', 0777) ... done. chmod ( 'web / assets', 0777) ... done. chmod ( 'yii', 0755) ... done.

Каб назіраць гэтую прыгажосць у Windows і выкарыстоўваць каманды Linux, раю ўсталяваць эмулятар Cygwin і працаваць у ім замест стандартнага інтэрпрэтатара каманднага радка. Заадно прама ў ім можна ўсталяваць Git і SSH-кліент.

Праект мы стварылі. Цяпер прыступім да распрацоўкі прыкладання.

канфігураванне сервера

Зараз можна дадаць тэчку для новага праекта ў сваім Apache або Nginx сэрвэры і змясціць файлы туды. Гэта ўжо залежыць ад вашага сервера.

Перш за ўсё паглядзім, ці падыходзіць наш сервер. Запусціце ў кансолі:

php requirements.php

або скапіруйце гэты файл у тэчку па змаўчанні вашага сервера і адкрыйце ў браўзеры http: //localhost/requirements.php. Yii2 патрабуе PHP 5.4 і некалькі падлучаных пашырэнняў.

Калі Вы карыстаецеся Windows, то ў файле php.ini трэба паказаць правільныя шляхі:

include_path = ".; Z: \ usr \ local \ php5 \ includes" extension_dir = "Z: \ usr \ local \ php5 \ ext"

і раскоментировать радкі падлучэння неабходных пашырэнняў. Напрыклад, для працы толькі з MySQL-базамі можна акрамя Intl, MBString і MCrypt падключыць толькі звязаныя з MySQL пашырэння:

extension = php_intl.dll extension = php_mbstring.dll extension = php_mcrypt.dll extension = php_mysql.dll extension = php_mysqli.dll extension = php_pdo_mysql.dll

а PDO PostgreSQL не чапаць.

Далей на любой сістэме карысна выставіць часовую зону:

date.timezone = "Europe / Moscow"

бо па змаўчанні пасля ўсталёўкі PHP яна пустая і вывальваюцца памылкі пры выкарыстанні любой функцыі, звязанай з датай і часам.

У першай версіі Yii файл index.php размяшчаўся прама ў корані, а само PHP-прыкладанне ляжала там жа ў тэчцы protected. Гэта было не вельмі зручна, бо даводзілася зачыняць тэчку protected ад прамога доступу ў .htaccess або пераносіць вышэй. У Yii2 ўсё зроблена наадварот па прыкладзе іншых фреймворков: у корані цяпер знаходзіцца само прыкладанне, а index.php і ўсе даступныя для карыстальніка файлы змешчаныя ў тэчку web.

controllers / models / views / web / assets / css / index.php

У сувязі з гэтым трэба сканфігураваць хост на сэрвэры так, каб сайт працаваў не з кораня прыкладання, а з тэчкі web. Гэта калі вы не хочаце наладжваць baseUrl і бачыць тэчку web ў адраснай радку накшталт http: //localhost/web/index.php. На сваім кампутары гэта не крытычна, але на хостынгу тады будуць даступныя для адкрыцця ўсе файлы з кораня.

Калі ж вы на сваім кампутары або хостынгу не маеце магчымасці наладзіць працоўную тэчку хаста персанальна (напрыклад, калі вам даступная толькі тэчка public_html або www), то можна альбо «падняць» усе файлы уверх так, каб выкарыстоўваць сваю тэчку замест web:

controllers / models / views / public_html / assets / css / index.php

альбо (калі ёсць доступ па SSH або на хостынгу добры файлавы менеджэр) змясціць прыкладанне ў асобную тэчку і стварыць сімвалічную спасылку з public_html на тэчку web або наладзіць поўнае перанакіраваньне ў файле public_html / .htaccess:

app / controllers / models / views / web / assets / css / index.php public_html / -> app / web /

Першы варыянт менш пераважны тым, што даводзіцца пераназываць тэчку. Гэта не вельмі зручна ў выпадку выкарыстання сістэм кантролю версій.

Такім чынам, пасля гэтых няхітрых маніпуляцый з серверам па адрасе http: // localhost вас павінен сустрэць прывітальны экран новага прыкладання. Калі замест гэтага здадуцца памылкі аб немагчымасці запісу ў тэчкі web / assets і runtime, то ўсталюеце ім правільныя правы.

Дарэчы пра сістэмы кантролю версій. Калі вы збіраецеся выкарыстоўваць Git ў сваім праекце, то ўжо можна стварыць рэпазітар:

cd project git init git commit --allow-empty -m 'Initial commit'

Цяпер самае важнае. Трэба зрабіць так, каб лішнія файлы не патрапілі ў індэкс.

Як напішаш .gitignore, так праект і паплыве ...

Напрыклад, канстанты YII_DEBUG і YII_ENV задаюцца ў файлах yii, web / index.php і web / index-test.php. У іх жа пры жаданні можна ўключыць выснова ўсіх памылак:

error_reporting (- 1); ini_set (display_errors, on);

калі няма магчымасці зрабіць гэта ў php.ini.

Аналагічна на кампутары кожнага распрацоўніка можа быць (ці наогул не быць) свой файл web / .htaccess з асабістымі наладамі.

Дазволім кожнаму распрацоўніку змяняць гэтыя файлы самастойна. Дадамо іх у спіс ігнаруемых.

Адкрываем .gitignore у корані і дадаем радок:

/ yii

Ствараем файл config / .gitignore і паказваем ня індэксаваць пэрсанальныя ўстаноўкі:

/db.php /params.php

Ствараем файл web / .gitignore і ўпісваем выключаюцца файлы канкрэтна ў гэтай тэчцы:

/.htaccess /index.php /index-test.php

Зараз, уласна, ствараем файл web / .htaccess, калі не выкарыстоўваем Nginx + PHP-FPM:

Order Allow, Deny Allow from all AddDefaultCharset utf-8 RewriteEngine on RewriteCond% {REQUEST_FILENAME}! -F RewriteCond% {REQUEST_FILENAME}! -D RewriteRule. index.php

Калі ж у вас сервер Nginx, то яго можна наладзіць па прыкладзе лістынга ў кіраўніцтве .

Зараз пасля налады сервера трэба ад брыдкіх адрасоў http: //localhost/index.php? R = site% 2Flogin перайсці да зручным накшталт http: // localhost / site / login. Дадамо ў файлы config / console.php і config / web.php секцыю кампанента urlManager:

components => [... urlManager => [enablePrettyUrl => true, showScriptName => false, rules => [<_c: [\ w \ -] +> / <id: \ d +> => <_c> / view , <_c: [\ w \ -] +> => <_c> / index, <_c: [\ w \ -] +> / <_ a: [\ w \ -] +> / <id: \ d +> => <_c> / <_ a>,],], ...],

Непатрэбныя файлы ўжо выключаны з індэксавання, таму можна дадаць усё астатняе ў рэпазітар і зафіксаваць бягучы стан:

git add. git commit -m 'Created project'

Цяпер нам трэба разабрацца з наладамі самага прыкладання.

канфігурацыя прыкладання

Мы набудавалі сервер і ўбачылі старонку прывітання нашай будучыні сайта.

Але ёсць пара нюансаў. Першы складаецца ў тым, што ў файле config / params.php зараз ўказаны толькі адрас электроннай пошты па змаўчанні, а налад можа быць шмат. Пры гэтым частка параметраў будзе агульнай (напрыклад, колькасць артыкулаў на старонку ў стужцы блога), а частка будзе персанальнай (паролі доступу да розных сэрвісаў). Лагічна было б агульныя і асабістыя параметры трымаць у розных файлах.

У файлах config / web.php і config / console.php параметры ўключаюцца з аднаго файла:

$ Params = require (__DIR__. /Params.php); return [... params => $ params,];

Выдалім адрас з config / params.php і дадамо параметр supportEmail:

return [adminEmail =>, supportEmail =>,];

і перанясемся яго ў новы файл config / params-local.php:

return [adminEmail => [email protected], supportEmail => [email protected],];

Другі параметр нам спатрэбіцца для ўказанні ў поле From для адпраўляюцца з сайта лістоў. У кодзе кантактнай формы па змаўчанні туды падстаўляецца адрас адпраўніка, які піша паведамленне:

class ContactForm extends Model {... public function contact ($ email) {if ($ this -> validate ()) {Yii :: $ app -> mailer -> compose () -> setTo ($ email) -> setFrom ([$ this -> email => $ this -> name]) -> setSubject ($ this -> subject) -> setTextBody ($ this -> body) -> send (); return true; } Else {return false; }}}

Але пераборлівыя паштовыя сістэмы накшталт MailRu ніяк не прымаюць лісты з падменены імем адпраўніка. Адпаведна лепш у поле From падстаўляць фіксаваны адрас, а Email адпраўшчыка падстаўляць ў полі ReplyTo:

class ContactForm extends Model {... public function contact ($ email) {if ($ this -> validate ()) {Yii :: $ app -> mailer -> compose () -> setTo ($ email) -> setFrom ([Yii :: $ app -> params [supportEmail] => Yii :: $ app -> name]) -> setReplyTo ([$ this -> email => $ this -> name]) -> setSubject ($ this -> subject) -> setTextBody ($ this -> body) -> send (); return true; } Else {return false; }}}

Цяпер калі адміністратар націсне «Адказаць» ў лісце, то ў поле Каму падставілі менавіта арыгінальны адрас адпраўніка.

Адкрыем cofig / .gitignore і заменім яго змесціва на:

/db.php * -local.php

Файл params.php цяпер праіндэксуюць і патрапіць у агульны рэпазітар, а params-local.php застанецца толькі на вашым кампутары. Кожны распрацоўнік можа дадаць свой файл params-local.php з асабістымі параметрамі і ня перажываць за свае паролі.

Цяпер у config / web.php і config / console.php дадамо механізм злепвання файлаў:

use yii \ helpers \ ArrayHelper; ... $ params = ArrayHelper :: merge (require (__DIR__. /Params.php), require (__DIR__. /Params-local.php)); ...

Аналагічна зробім магчымасць перавызначаць налады кампанентаў прыкладання. Але спачатку другі нюанс.

Аднолькавую секцыю urlManager мы дадалі ў абодва файла config / console.php і config / web.php. Вядома ж можна яе вынесці ў urlManager.php і падключаць праз require па аналогіі з db.php. Але што калі трэба будзе аднолькава наладзіць дзясятак агульных кампанентаў?

Мы ўжо ўмеем зліваць масівы параметраў. Паступім таксама. На прыкладзе больш «прасунутага» advanced-шаблону створым файл config / common.php з агульнымі наладамі:

use yii \ helpers \ ArrayHelper; $ Params = ArrayHelper :: merge (require (__DIR__. /Params.php), require (__DIR__. /Params-local.php)); return [basePath => dirname (__DIR__), bootstrap => [log], aliases => [@bower => @ vendor / bower-asset, @npm => @ vendor / npm-asset,], components => [db => [class => yii \ db \ Connection, charset => utf8,], urlManager => [class => yii \ web \ UrlManager, enablePrettyUrl => true, showScriptName => false, rules => [<_c: [ \ w \ -] +> / <id: \ d +> => <_c> / view, <_c: [\ w \ -] +> => <_c> / index, <_c: [\ w \ -] +> / <_ a: [\ w \ -] +> / <id: \ d +> => <_c> / <_ a>,],], mailer => [class => yii \ swiftmailer \ Mailer,], cache => [class => yii \ caching \ DummyCache,], log => [class => yii \ log \ Dispatcher,],], params => $ params,];

Побач пакладзем config / common-local.php з якія адсутнічаюць асабістымі параметрамі для адпаведных кампанентаў:

return [components => [db => [dsn => mysql: host = localhost; dbname = seokeys, username => root, password =>, tablePrefix => keys_,], mailer => [useFileTransport => true,], cache => [class => yii \ caching \ FileCache,],],];

Пры зліцці канфігурацый нашы лакальныя налады перавызначыць агульныя. Другі файл не патрапіць у рэпазітар сістэмы кантролю версій, бо ён таксама названы ў выглядзе * -local.php.

Заменім змесціва config / .gitignore на:

* -local.php

Гэта значыць, мы прыбралі ігнараванне файла config / db.php. Ён нам больш не патрэбны. Выдалім яго:

rm config / db.php

Зараз з config / console.php і config / web.php мы можам прыбраць усе агульныя налады. Пакінем там толькі індывідуальныя.

Спецыфічныя параметры web-прыкладання config / web.php:

$ Config = [id => app, components => [user => [identityClass => app \ models \ User, enableAutoLogin => true,], errorHandler => [errorAction => site / error,], log => [ traceLevel => YII_DEBUG? 3: 0,],],]; if (YII_ENV_DEV) {$ config [bootstrap] [] = debug; $ Config [modules] [debug] = [class => yii \ debug \ Module,]; $ Config [bootstrap] [] = gii; $ Config [modules] [gii] = [class => yii \ gii \ Module,]; } Return $ config;

Параметры кансольнага рэжыму config / console.php:

$ Config = [id => app-console, controllerNamespace => app \ commands,]; if (YII_ENV_DEV) {$ config [bootstrap] [] = gii; $ Config [modules] [gii] = [class => yii \ gii \ Module,]; } Return $ config;

І дадаткова дадамо магчымасць лакальнага пераазначэння кожнага варыянту. Напрыклад, дапрацаваўшы адзін з рэцэптаў з Yii Application Development Cookbook для Yii1 зробім лагаванне ў паасобныя файлы:

Пэрсанальныя ўстаноўкі config / web-local.php:

return [components => [request => [cookieValidationKey => jshd3qjaxp,], assetManager => [linkAssets => true,], log => [targets => [[class => yii \ log \ FileTarget, levels => [ error], logFile => @ app / runtime / logs / web-error.log], [class => yii \ log \ FileTarget, levels => [warning], logFile => @ app / runtime / logs / web-warning .log],],],],];

Тут мы ад сябе ўсталявалі параметр linkAssets кампанента assetManager ў true, каб фреймворк ня капіяваў тэчкі ў web / assets, а рабіў сімвалічныя спасылкі. Гэта і эканоміць месца, і дазваляе не выдаляць і перегенерировать тэчкі пры кожным абнаўленні вендараў.

Пэрсанальныя ўстаноўкі config / console-local.php:

return [components => [log => [targets => [[class => yii \ log \ FileTarget, levels => [error], logFile => @ app / runtime / logs / console-error.log], [class => yii \ log \ FileTarget, levels => [warning], logFile => @ app / runtime / logs / console-warning.log],],],],];

Атрымалася гнуткая сістэма канфігурацыі.

Звярніце ўвагу, што пры зліцці метадам merge ў асацыятыўных масівах значэння перавызначаць, а ў неассоциативных - дапаўняюцца.

Калі ў двух канфігурацыйных масівах маюцца трохі розныя налады:

log => [traceLevel => 0, targets => [[class => yii \ log \ FileTarget],],], log => [traceLevel => 3, targets => [[class => yii \ log \ WebTarget ],],],

То пры зліцці параметр з ключом traceLevel перазапіша, а значэння targets зліюцца:

log => [traceLevel => 3, targets => [0 => [class => yii \ log \ FileTarget], 1 => [class => yii \ log \ WebTarget],],],

Так што пажадана не дадаваць значэнні па змаўчанні ў выглядзе простых масіваў у агульныя файлы канфігурацыі.

У выніку ў нас атрымаўся цэлы набор файлаў:

config / common.php common-local.php console.php console-local.php web.php web-local.php params.php params-local.php

То ёсць агульныя параметры падключаюцца да web і console з common і params, а ўсе асабістыя налады можна спакойна перавызначаць ў * -local файлах.

Засталося толькі правільна зліць усе фрагменты.

Адкрыем файл web / index.php, знойдзем радок загрузкі канфігурацыі:

$ Config = require (__DIR__. /../Config/web.php);

і заменім яе на канструкцыю:

$ Config = yii \ helpers \ ArrayHelper :: merge (require (__DIR__. /../Config/common.php), require (__DIR__. /../Config/common-local.php), require (__DIR__. /. ./config/web.php), require (__DIR__. /../config/web-local.php));

Аналагічна для кансольных каманд зменім файл yii ў корані. замест:

$ Config = require (__DIR__. /Config/console.php);

уставім:

$ Config = yii \ helpers \ ArrayHelper :: merge (require (__DIR__. /Config/common.php), require (__DIR__. /Config/common-local.php), require (__DIR__. /Config/console.php), require (__DIR__. /config/console-local.php));

Цяпер проиндексируем ўсе змены і зробім яшчэ адну адзнаку ў сістэме кантролю версій:

git add. git commit -m 'Extended config system'

На гэтым ўстаноўка і першапачатковае канфігураванне прыкладання завершана.

разгортванне канфігурацыі

Мы зрабілі файлы лакальнай канфігурацыі config / * - local.php і пакінулі змянянымі файлы web / index.php і yii і наладзілі іх ігнараванне сістэмай кантролю версій.

Лакальныя файлы пазначаны ў .gitignore, таму ў рэпазітар яны не трапяць. Іх прыйдзецца кожны раз ствараць наўздагад ўручную. Гэта нязручна.

Можна зрабіць асобную тэчку examples, у якую скапіяваць гэтыя файлы для прыкладу:

config ├── common.php ├── console.php ├── params.php └── web.php ... examples ├── config │ ├── common-local.php │ ├── console-local. php │ ├── params-local.php │ └── web-local.php ├── web │ ├── index.php │ └── index-test.php └── yii

Гэтыя нарыхтоўкі мы ўжо ў .gitignore ня ўпісваем. Зараз для разгортвання праекта праграмісту дастаткова скапіяваць гэтыя нарыхтоўкі з examples наверх і запоўніць іх сваімі наладамі.

Але гэтыя файлы трохі адрозніваюцца для dev і для prod рэжыму. Каб яшчэ больш аблегчыць працу можна прыкласці да праекта два пачкі файлаў для розных асяроддзяў:

environments ├── dev │ ├── config │ │ ├── common-local.php │ │ ├── console-local.php │ │ ├── params-local.php │ │ └── web-local.php │ ├── web │ │ ├── index.php │ │ └── index-test.php │ └── yii └── prod ├── config │ ├── common-local.php │ ├── console -local.php │ ├── params-local.php │ └── web-local.php ├── web │ └── index.php └── yii

Заадно тэчку examples мы перайменавалі ў environments.

Ці можна зараз неяк аўтаматызаваць працэдуру разгортвання лакальнай канфігурацыі? Напрыклад, напісаць кансольны скрыпт, які будзе капіяваць файлы з патрэбнай нам тэчкі ў праект.

На самай справе можна. Больш за тое, такі скрыпт ўжо ёсць. У yii2-app-advanced ўжо ёсць такая ж татка environments з канфігурацыяй environments / index.php і файлы init, init.bat ў корані. Нам дастаткова скапіяваць гэтыя файлы:

environments ├── dev │ └── ... ├── prod │ └── ... └── index.php init init.bat

і пераналадзіць environments / index.php на працу з yii2-app-basic`:

return [Development => [path => dev, setWritable => [runtime, web / assets,], setExecutable => [yii, tests / codeception / bin / yii,], setCookieValidationKey => [config / web-local.php ,],], Production => [path => prod, setWritable => [runtime, web / assets,], setExecutable => [yii,], setCookieValidationKey => [config / web-local.php,],], ];

Цяпер у свежым праекце досыць запусціць

php init

і паказаць яму атачэнне dev. Ён разгорне лакальныя файлы і заадно выставіць правільныя правы доступу на папкі runtime і web / assets.

У стандартным yii2-app-basic расстанвкой правоў займаецца скрыпт yii \\ composer \\ Installer. Пасля пераходу на каманду init мы можам знайсці секцыю са скрыптамі ўстаноўкі ў composer.json:

"Scripts": { "post-install-cmd": [ "yii \\ composer \\ Installer :: postInstall"], "post-create-project-cmd": [ "yii \\ composer \\ Installer :: postCreateProject "," yii \\ composer \\ Installer :: postInstall "]}," extra ": {" yii \\ composer \\ Installer :: postCreateProject ": {" setPermission ": [{" runtime ":" 0777 ", "web / assets": "0777", "yii": "0755"}]}, "yii \\ composer \\ Installer :: postInstall": { "generateCookieValidationKey": [ "config / web.php"]}} ,

і цалкам яе выдаліць.

На гэтым інтэграванне гнуткай сістэмы канфігурацыі з app-advanced ў app-basic завершана.

Можна адправіць усё ў свой рэпазітар на GitHub:

рэпазітар праекта

PS За час напісання артыкула (і пасля) адбылося некалькі змен у ядры фреймворка. У рэальным часе яны выкладваюцца ў файле UPGRADE і некаторыя абмяркоўваюцца ў каментарах тут. Адпаведна, гэты артыкул паступова абнаўляецца.

У сваім жа праекце час ад часу абнаўляць змесціва тэчкі vendor камандай:

composer update

і сочыце за зменамі шаблону yii2-app-basic.

Калі нешта не вельмі зразумела ў артыкуле, то напішыце ў каментарах. І да сустрэчы ў наступных частках:

Частка 2: Налады IDE і модулі