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 і модулі