From df44626c39608aab22617a28ef9e82637f81c279 Mon Sep 17 00:00:00 2001 From: Mark Date: Sun, 5 Jan 2014 06:15:42 +0400 Subject: [PATCH] docs added, guide style added. --- docs/guide/README.md | 8 + docs/guide/console-fixture.md | 105 +++++++++++++ docs/guide/console-migrate.md | 333 ++++++++++++++++++++++++++++++++++++++++++ docs/guide/debugger.md | 38 ----- docs/guide/migration.md | 333 ------------------------------------------ docs/guide/module-debug.md | 38 +++++ 6 files changed, 484 insertions(+), 371 deletions(-) create mode 100644 docs/guide/README.md create mode 100644 docs/guide/console-fixture.md create mode 100644 docs/guide/console-migrate.md delete mode 100644 docs/guide/debugger.md delete mode 100644 docs/guide/migration.md create mode 100644 docs/guide/module-debug.md diff --git a/docs/guide/README.md b/docs/guide/README.md new file mode 100644 index 0000000..5717e71 --- /dev/null +++ b/docs/guide/README.md @@ -0,0 +1,8 @@ +This folder contains official Yii 2 guides documentation. + +To add new guide, take the following steps: + +1. Create `guide-name` and put there relevant documentation; +2. If guide has more then one word in name, then it should be with dashes, like: `console-fixture.md`, `module-debug.md` +3. If your guide is for console commands, than its name should follow convention: `console-{command}.md` +4. If your guide is for custom modules, than its name should follow convention: `module-{moduleName}.md` diff --git a/docs/guide/console-fixture.md b/docs/guide/console-fixture.md new file mode 100644 index 0000000..0ec7401 --- /dev/null +++ b/docs/guide/console-fixture.md @@ -0,0 +1,105 @@ +Database Fixtures +================= + +Fixtures are important part of testing. Their main purpose is to populate you with data that needed by testing +different cases. With this data using your tests becoming more efficient and useful. + +Yii supports database fixtures via the `yii fixture` command line tool. This tool supports: + +* Applying new fixtures to database tables; +* Clearing, database tables (with sequences); +* Auto-generating fixtures and populating it with random data. + +Fixtures format +--------------- + +Fixtures are just plain php files returning array, as follows: + +``` +#users.php file under fixtures path + +return [ + [ + 'name' => 'Chase', + 'login' => 'lmayert', + 'email' => 'strosin.vernice@jerde.com', + 'auth_key' => 'K3nF70it7tzNsHddEiq0BZ0i-OU8S3xV', + 'password' => '$2y$13$WSyE5hHsG1rWN2jV8LRHzubilrCLI5Ev/iK0r3jRuwQEs2ldRu.a2', + ], + [ + 'name' => 'Celestine', + 'login' => 'napoleon69', + 'email' => 'aileen.barton@heaneyschumm.com', + 'auth_key' => 'dZlXsVnIDgIzFgX4EduAqkEPuphhOh9q', + 'password' => '$2y$13$kkgpvJ8lnjKo8RuoR30ay.RjDf15bMcHIF7Vz1zz/6viYG5xJExU6', + ], +]; +``` + +This data will be loaded to the `users`, but before it will be loaded table `users` will be cleared: all data deleted, sequence reseted. +Above fixture example was auto-generated by `yii2-faker` extension, read more about it in these [section](#auto-generating-fixtures). + +Applying fixtures +----------------- + +To apply fixture to the table, run the following command: + +``` +yii fixture/apply +``` + +The required `tbl_name` parameter specifies a database table to which data will be loaded. You can load data to several tables at once. +Below are correct formats of this command: + +``` +// apply fixtures to the "users" table of database +yii fixture/apply users + +// same as above, because default action of "fixture" command is "apply" +yii fixture users + +// apply several fixtures to several tables. Note that there should not be any whitespace between ",", it should be one string. +yii fixture users,users_profiles + +// apply fixtures to the table users, but fixtures will be taken from different path. +yii fixture users --fixturePath='@app/my/custom/path/to/fixtures' + +// apply fixtures to the table users, but for other database connection. +yii fixtures users --db='customDbConnectionId' +``` + +Clearing tables +--------------- + +To clear table, run the following command: + +``` +// clear given table: delete all data and reset sequence. +yii fixture/clear users + +// clear several tables. Note that there should not be any whitespace between ",", it should be one string. +yii fixture/clear users,users_profile +``` + +Configure Command Globally +-------------------------- +While command line options allow us to configure the migration command +on-the-fly, sometimes we may want to configure the command once for all. For example you can configure +different migration path as follows: + +``` +'controllerMap' => [ + 'fixture' => [ + 'class' => 'yii\console\FixtureController', + 'fixturePath' => '@app/my/custom/path/to/fixtures', + 'db' => 'customDbConnectionId', + ], +] +``` + +Auto-generating fixtures +------------------------ + +Yii also can auto-generate fixtures for you based on some template. You can generate your fixtures with different data on different languages and formats. +These feature is done by [Faker](https://github.com/fzaninotto/Faker) library and `yii2-faker` extension. +See extension [guide](https://github.com/yiisoft/yii2/tree/master/extensions/yii/faker) for more docs. diff --git a/docs/guide/console-migrate.md b/docs/guide/console-migrate.md new file mode 100644 index 0000000..7d31ca5 --- /dev/null +++ b/docs/guide/console-migrate.md @@ -0,0 +1,333 @@ +Database Migration +================== + +Like source code, the structure of a database evolves as a database-driven application is developed and maintained. For example, during development, a new table may be added; Or, after the application goes live, it may be discovered that an additional index is required. It is important to keep track of these structural database changes (called **migration**), just as changes to the source code is tracked using version control. If the source code and the database become out of sync, bugs will occur, or the whole application might break. For this reason, Yii provides a database migration +tool that can keep track of database migration history, apply new migrations, or revert existing ones. + +The following steps show how database migration is used by a team during development: + +1. Tim creates a new migration (e.g. creates a new table, changes a column definition, etc.). +2. Tim commits the new migration into the source control system (e.g. Git, Mercurial). +3. Doug updates his repository from the source control system and receives the new migration. +4. Doug applies the migration to his local development database, thereby syncing his database to reflect the changes Tim made. + +Yii supports database migration via the `yii migrate` command line tool. This tool supports: + +* Creating new migrations +* Applying, reverting, and redoing migrations +* Showing migration history and new migrations + +Creating Migrations +------------------- + +To create a new migration, run the following command: + +``` +yii migrate/create +``` + +The required `name` parameter specifies a very brief description of the migration. For example, if the migration creates a new table named *news*, you'd use the command: + +``` +yii migrate/create create_news_table +``` + +As you'll shortly see, the `name` parameter +is used as part of a PHP class name in the migration. Therefore, it should only contain letters, +digits and/or underscore characters. + +The above command will create a new +file named `m101129_185401_create_news_table.php`. This file will be created within the `protected/migrations` directory. Initially, the migration file will be generated with the following code: + +```php +class m101129_185401_create_news_table extends \yii\db\Migration +{ + public function up() + { + } + + public function down() + { + echo "m101129_185401_create_news_table cannot be reverted.\n"; + return false; + } +} +``` + +Notice that the class name is the same as the file name, and follows the pattern +`m_`, where: + +* `` refers to the UTC timestamp (in the +format of `yymmdd_hhmmss`) when the migration is created, +* `` is taken from the command's `name` parameter. + +In the class, the `up()` method should contain the code implementing the actual database +migration. In other words, the `up()` method executes code that actually changes the database. The `down()` method may contain code that reverts the changes made by `up()`. + +Sometimes, it is impossible for the `down()` to undo the database migration. For example, if the migration deletes +table rows or an entire table, that data cannot be recovered in the `down()` method. In such +cases, the migration is called irreversible, meaning the database cannot be rolled back to +a previous state. When a migration is irreversible, as in the above generated code, the `down()` +method returns `false` to indicate that the migration cannot be reverted. + +As an example, let's show the migration about creating a news table. + +```php + +use yii\db\Schema; + +class m101129_185401_create_news_table extends \yii\db\Migration +{ + public function up() + { + $this->createTable('tbl_news', [ + 'id' => 'pk', + 'title' => Schema::TYPE_STRING . ' NOT NULL', + 'content' => Schema::TYPE_TEXT, + ]); + } + + public function down() + { + $this->dropTable('tbl_news'); + } + +} +``` + +The base class [\yii\db\Migration] exposes a database connection via `db` +property. You can use it for manipulating data and schema of a database. + +The column types used in this example are abstract types that will be replaced +by Yii with the corresponding types depended on your database management system. +You can use them to write database independent migrations. +For example `pk` will be replaced by `int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY` +for MySQL and `integer PRIMARY KEY AUTOINCREMENT NOT NULL` for sqlite. +See documentation of [[QueryBuilder::getColumnType()]] for more details and a list +of available types. You may also use the constants defined in [[\yii\db\Schema]] to +define column types. + + +Transactional Migrations +------------------------ + +While performing complex DB migrations, we usually want to make sure that each +migration succeed or fail as a whole so that the database maintains the +consistency and integrity. In order to achieve this goal, we can exploit +DB transactions. We could use special methods `safeUp` and `safeDown` for these purposes. + +```php + +use yii\db\Schema; + +class m101129_185401_create_news_table extends \yii\db\Migration +{ + public function safeUp() + { + $this->createTable('tbl_news', [ + 'id' => 'pk', + 'title' => Schema::TYPE_STRING . ' NOT NULL', + 'content' => Schema::TYPE_TEXT, + ]); + + $this->createTable('tbl_user', [ + 'id' => 'pk', + 'login' => Schema::TYPE_STRING . ' NOT NULL', + 'password' => Schema::TYPE_STRING . ' NOT NULL', + ]); + } + + public function safeDown() + { + $this->dropTable('tbl_news); + $this->dropTable('tbl_user'); + } + +} +``` + +When your code uses more then one query it is recommended to use `safeUp` and `safeDown`. + +> Note: Not all DBMS support transactions. And some DB queries cannot be put +> into a transaction. In this case, you will have to implement `up()` and +> `down()`, instead. And for MySQL, some SQL statements may cause +> [implicit commit](http://dev.mysql.com/doc/refman/5.1/en/implicit-commit.html). + + +Applying Migrations +------------------- + +To apply all available new migrations (i.e., make the local database up-to-date), +run the following command: + +``` +yii migrate +``` + +The command will show the list of all new migrations. If you confirm to apply +the migrations, it will run the `up()` method in every new migration class, one +after another, in the order of the timestamp value in the class name. + +After applying a migration, the migration tool will keep a record in a database +table named `tbl_migration`. This allows the tool to identify which migrations +have been applied and which are not. If the `tbl_migration` table does not exist, +the tool will automatically create it in the database specified by the `db` +application component. + +Sometimes, we may only want to apply one or a few new migrations. We can use the +following command: + +``` +yii migrate/up 3 +``` + +This command will apply the 3 new migrations. Changing the value 3 will allow +us to change the number of migrations to be applied. + +We can also migrate the database to a specific version with the following command: + +``` +yii migrate/to 101129_185401 +``` + +That is, we use the timestamp part of a migration name to specify the version +that we want to migrate the database to. If there are multiple migrations between +the last applied migration and the specified migration, all these migrations +will be applied. If the specified migration has been applied before, then all +migrations applied after it will be reverted (to be described in the next section). + + +Reverting Migrations +-------------------- + +To revert the last one or several applied migrations, we can use the following +command: + +``` +yii migrate/down [step] +``` + +where the optional `step` parameter specifies how many migrations to be reverted +back. It defaults to 1, meaning reverting back the last applied migration. + +As we described before, not all migrations can be reverted. Trying to revert +such migrations will throw an exception and stop the whole reverting process. + + +Redoing Migrations +------------------ + +Redoing migrations means first reverting and then applying the specified migrations. +This can be done with the following command: + +``` +yii migrate/redo [step] +``` + +where the optional `step` parameter specifies how many migrations to be redone. +It defaults to 1, meaning redoing the last migration. + + +Showing Migration Information +----------------------------- + +Besides applying and reverting migrations, the migration tool can also display +the migration history and the new migrations to be applied. + +``` +yii migrate/history [limit] +yii migrate/new [limit] +``` + +where the optional parameter `limit` specifies the number of migrations to be +displayed. If `limit` is not specified, all available migrations will be displayed. + +The first command shows the migrations that have been applied, while the second +command shows the migrations that have not been applied. + + +Modifying Migration History +--------------------------- + +Sometimes, we may want to modify the migration history to a specific migration +version without actually applying or reverting the relevant migrations. This +often happens when developing a new migration. We can use the following command +to achieve this goal. + +``` +yii migrate/mark 101129_185401 +``` + +This command is very similar to `yii migrate/to` command, except that it only +modifies the migration history table to the specified version without applying +or reverting the migrations. + + +Customizing Migration Command +----------------------------- + +There are several ways to customize the migration command. + +### Use Command Line Options + +The migration command comes with four options that can be specified in command +line: + +* `interactive`: boolean, specifies whether to perform migrations in an + interactive mode. Defaults to true, meaning the user will be prompted when + performing a specific migration. You may set this to false should the + migrations be done in a background process. + +* `migrationPath`: string, specifies the directory storing all migration class + files. This must be specified in terms of a path alias, and the corresponding + directory must exist. If not specified, it will use the `migrations` + sub-directory under the application base path. + +* `migrationTable`: string, specifies the name of the database table for storing + migration history information. It defaults to `tbl_migration`. The table + structure is `version varchar(255) primary key, apply_time integer`. + +* `connectionID`: string, specifies the ID of the database application component. + Defaults to 'db'. + +* `templateFile`: string, specifies the path of the file to be served as the code + template for generating the migration classes. This must be specified in terms + of a path alias (e.g. `application.migrations.template`). If not set, an + internal template will be used. Inside the template, the token `{ClassName}` + will be replaced with the actual migration class name. + +To specify these options, execute the migrate command using the following format + +``` +yii migrate/up --option1=value1 --option2=value2 ... +``` + +For example, if we want to migrate for a `forum` module whose migration files +are located within the module's `migrations` directory, we can use the following +command: + +``` +yii migrate/up --migrationPath=@app/modules/forum/migrations +``` + + +### Configure Command Globally + +While command line options allow us to configure the migration command +on-the-fly, sometimes we may want to configure the command once for all. +For example, we may want to use a different table to store the migration history, +or we may want to use a customized migration template. We can do so by modifying +the console application's configuration file like the following, + +```php +'controllerMap' => [ + 'migrate' => [ + 'class' => 'yii\console\MigrateController', + 'migrationTable' => 'my_custom_migrate_table', + ], +] +``` + +Now if we run the `migrate` command, the above configurations will take effect +without requiring us to enter the command line options every time. Other command options +can be also configured this way. diff --git a/docs/guide/debugger.md b/docs/guide/debugger.md deleted file mode 100644 index 710f7a3..0000000 --- a/docs/guide/debugger.md +++ /dev/null @@ -1,38 +0,0 @@ -Debug toolbar and debugger -========================== - -Yii2 includes a handy toolbar to aid faster development and debugging as well as debugger. Toolbar displays information -about currently opened page while using debugger you can analyze data collected before. - -Installing and configuring --------------------------- - -Add these lines to your config file: - -``` -'preload' => ['debug'], -'modules' => [ - 'debug' => ['yii\debug\Module'] -] -``` - -**Watch out: by default the debug module only works when browsing the website from the localhost. If you want to use it -on a remote (staging) server, add the parameter allowedIPs to the config to whitelist your IP, e.g. :** - -``` -'preload' => ['debug'], -'modules' => [ - 'debug' => [ - 'class'=>'yii\debug\Module', - 'allowedIPs'=>['1.2.3.4', '127.0.0.1', '::1'] - ] -] -``` - -How to use it -------------- - - -Creating your own panels ------------------------- - diff --git a/docs/guide/migration.md b/docs/guide/migration.md deleted file mode 100644 index 7d31ca5..0000000 --- a/docs/guide/migration.md +++ /dev/null @@ -1,333 +0,0 @@ -Database Migration -================== - -Like source code, the structure of a database evolves as a database-driven application is developed and maintained. For example, during development, a new table may be added; Or, after the application goes live, it may be discovered that an additional index is required. It is important to keep track of these structural database changes (called **migration**), just as changes to the source code is tracked using version control. If the source code and the database become out of sync, bugs will occur, or the whole application might break. For this reason, Yii provides a database migration -tool that can keep track of database migration history, apply new migrations, or revert existing ones. - -The following steps show how database migration is used by a team during development: - -1. Tim creates a new migration (e.g. creates a new table, changes a column definition, etc.). -2. Tim commits the new migration into the source control system (e.g. Git, Mercurial). -3. Doug updates his repository from the source control system and receives the new migration. -4. Doug applies the migration to his local development database, thereby syncing his database to reflect the changes Tim made. - -Yii supports database migration via the `yii migrate` command line tool. This tool supports: - -* Creating new migrations -* Applying, reverting, and redoing migrations -* Showing migration history and new migrations - -Creating Migrations -------------------- - -To create a new migration, run the following command: - -``` -yii migrate/create -``` - -The required `name` parameter specifies a very brief description of the migration. For example, if the migration creates a new table named *news*, you'd use the command: - -``` -yii migrate/create create_news_table -``` - -As you'll shortly see, the `name` parameter -is used as part of a PHP class name in the migration. Therefore, it should only contain letters, -digits and/or underscore characters. - -The above command will create a new -file named `m101129_185401_create_news_table.php`. This file will be created within the `protected/migrations` directory. Initially, the migration file will be generated with the following code: - -```php -class m101129_185401_create_news_table extends \yii\db\Migration -{ - public function up() - { - } - - public function down() - { - echo "m101129_185401_create_news_table cannot be reverted.\n"; - return false; - } -} -``` - -Notice that the class name is the same as the file name, and follows the pattern -`m_`, where: - -* `` refers to the UTC timestamp (in the -format of `yymmdd_hhmmss`) when the migration is created, -* `` is taken from the command's `name` parameter. - -In the class, the `up()` method should contain the code implementing the actual database -migration. In other words, the `up()` method executes code that actually changes the database. The `down()` method may contain code that reverts the changes made by `up()`. - -Sometimes, it is impossible for the `down()` to undo the database migration. For example, if the migration deletes -table rows or an entire table, that data cannot be recovered in the `down()` method. In such -cases, the migration is called irreversible, meaning the database cannot be rolled back to -a previous state. When a migration is irreversible, as in the above generated code, the `down()` -method returns `false` to indicate that the migration cannot be reverted. - -As an example, let's show the migration about creating a news table. - -```php - -use yii\db\Schema; - -class m101129_185401_create_news_table extends \yii\db\Migration -{ - public function up() - { - $this->createTable('tbl_news', [ - 'id' => 'pk', - 'title' => Schema::TYPE_STRING . ' NOT NULL', - 'content' => Schema::TYPE_TEXT, - ]); - } - - public function down() - { - $this->dropTable('tbl_news'); - } - -} -``` - -The base class [\yii\db\Migration] exposes a database connection via `db` -property. You can use it for manipulating data and schema of a database. - -The column types used in this example are abstract types that will be replaced -by Yii with the corresponding types depended on your database management system. -You can use them to write database independent migrations. -For example `pk` will be replaced by `int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY` -for MySQL and `integer PRIMARY KEY AUTOINCREMENT NOT NULL` for sqlite. -See documentation of [[QueryBuilder::getColumnType()]] for more details and a list -of available types. You may also use the constants defined in [[\yii\db\Schema]] to -define column types. - - -Transactional Migrations ------------------------- - -While performing complex DB migrations, we usually want to make sure that each -migration succeed or fail as a whole so that the database maintains the -consistency and integrity. In order to achieve this goal, we can exploit -DB transactions. We could use special methods `safeUp` and `safeDown` for these purposes. - -```php - -use yii\db\Schema; - -class m101129_185401_create_news_table extends \yii\db\Migration -{ - public function safeUp() - { - $this->createTable('tbl_news', [ - 'id' => 'pk', - 'title' => Schema::TYPE_STRING . ' NOT NULL', - 'content' => Schema::TYPE_TEXT, - ]); - - $this->createTable('tbl_user', [ - 'id' => 'pk', - 'login' => Schema::TYPE_STRING . ' NOT NULL', - 'password' => Schema::TYPE_STRING . ' NOT NULL', - ]); - } - - public function safeDown() - { - $this->dropTable('tbl_news); - $this->dropTable('tbl_user'); - } - -} -``` - -When your code uses more then one query it is recommended to use `safeUp` and `safeDown`. - -> Note: Not all DBMS support transactions. And some DB queries cannot be put -> into a transaction. In this case, you will have to implement `up()` and -> `down()`, instead. And for MySQL, some SQL statements may cause -> [implicit commit](http://dev.mysql.com/doc/refman/5.1/en/implicit-commit.html). - - -Applying Migrations -------------------- - -To apply all available new migrations (i.e., make the local database up-to-date), -run the following command: - -``` -yii migrate -``` - -The command will show the list of all new migrations. If you confirm to apply -the migrations, it will run the `up()` method in every new migration class, one -after another, in the order of the timestamp value in the class name. - -After applying a migration, the migration tool will keep a record in a database -table named `tbl_migration`. This allows the tool to identify which migrations -have been applied and which are not. If the `tbl_migration` table does not exist, -the tool will automatically create it in the database specified by the `db` -application component. - -Sometimes, we may only want to apply one or a few new migrations. We can use the -following command: - -``` -yii migrate/up 3 -``` - -This command will apply the 3 new migrations. Changing the value 3 will allow -us to change the number of migrations to be applied. - -We can also migrate the database to a specific version with the following command: - -``` -yii migrate/to 101129_185401 -``` - -That is, we use the timestamp part of a migration name to specify the version -that we want to migrate the database to. If there are multiple migrations between -the last applied migration and the specified migration, all these migrations -will be applied. If the specified migration has been applied before, then all -migrations applied after it will be reverted (to be described in the next section). - - -Reverting Migrations --------------------- - -To revert the last one or several applied migrations, we can use the following -command: - -``` -yii migrate/down [step] -``` - -where the optional `step` parameter specifies how many migrations to be reverted -back. It defaults to 1, meaning reverting back the last applied migration. - -As we described before, not all migrations can be reverted. Trying to revert -such migrations will throw an exception and stop the whole reverting process. - - -Redoing Migrations ------------------- - -Redoing migrations means first reverting and then applying the specified migrations. -This can be done with the following command: - -``` -yii migrate/redo [step] -``` - -where the optional `step` parameter specifies how many migrations to be redone. -It defaults to 1, meaning redoing the last migration. - - -Showing Migration Information ------------------------------ - -Besides applying and reverting migrations, the migration tool can also display -the migration history and the new migrations to be applied. - -``` -yii migrate/history [limit] -yii migrate/new [limit] -``` - -where the optional parameter `limit` specifies the number of migrations to be -displayed. If `limit` is not specified, all available migrations will be displayed. - -The first command shows the migrations that have been applied, while the second -command shows the migrations that have not been applied. - - -Modifying Migration History ---------------------------- - -Sometimes, we may want to modify the migration history to a specific migration -version without actually applying or reverting the relevant migrations. This -often happens when developing a new migration. We can use the following command -to achieve this goal. - -``` -yii migrate/mark 101129_185401 -``` - -This command is very similar to `yii migrate/to` command, except that it only -modifies the migration history table to the specified version without applying -or reverting the migrations. - - -Customizing Migration Command ------------------------------ - -There are several ways to customize the migration command. - -### Use Command Line Options - -The migration command comes with four options that can be specified in command -line: - -* `interactive`: boolean, specifies whether to perform migrations in an - interactive mode. Defaults to true, meaning the user will be prompted when - performing a specific migration. You may set this to false should the - migrations be done in a background process. - -* `migrationPath`: string, specifies the directory storing all migration class - files. This must be specified in terms of a path alias, and the corresponding - directory must exist. If not specified, it will use the `migrations` - sub-directory under the application base path. - -* `migrationTable`: string, specifies the name of the database table for storing - migration history information. It defaults to `tbl_migration`. The table - structure is `version varchar(255) primary key, apply_time integer`. - -* `connectionID`: string, specifies the ID of the database application component. - Defaults to 'db'. - -* `templateFile`: string, specifies the path of the file to be served as the code - template for generating the migration classes. This must be specified in terms - of a path alias (e.g. `application.migrations.template`). If not set, an - internal template will be used. Inside the template, the token `{ClassName}` - will be replaced with the actual migration class name. - -To specify these options, execute the migrate command using the following format - -``` -yii migrate/up --option1=value1 --option2=value2 ... -``` - -For example, if we want to migrate for a `forum` module whose migration files -are located within the module's `migrations` directory, we can use the following -command: - -``` -yii migrate/up --migrationPath=@app/modules/forum/migrations -``` - - -### Configure Command Globally - -While command line options allow us to configure the migration command -on-the-fly, sometimes we may want to configure the command once for all. -For example, we may want to use a different table to store the migration history, -or we may want to use a customized migration template. We can do so by modifying -the console application's configuration file like the following, - -```php -'controllerMap' => [ - 'migrate' => [ - 'class' => 'yii\console\MigrateController', - 'migrationTable' => 'my_custom_migrate_table', - ], -] -``` - -Now if we run the `migrate` command, the above configurations will take effect -without requiring us to enter the command line options every time. Other command options -can be also configured this way. diff --git a/docs/guide/module-debug.md b/docs/guide/module-debug.md new file mode 100644 index 0000000..710f7a3 --- /dev/null +++ b/docs/guide/module-debug.md @@ -0,0 +1,38 @@ +Debug toolbar and debugger +========================== + +Yii2 includes a handy toolbar to aid faster development and debugging as well as debugger. Toolbar displays information +about currently opened page while using debugger you can analyze data collected before. + +Installing and configuring +-------------------------- + +Add these lines to your config file: + +``` +'preload' => ['debug'], +'modules' => [ + 'debug' => ['yii\debug\Module'] +] +``` + +**Watch out: by default the debug module only works when browsing the website from the localhost. If you want to use it +on a remote (staging) server, add the parameter allowedIPs to the config to whitelist your IP, e.g. :** + +``` +'preload' => ['debug'], +'modules' => [ + 'debug' => [ + 'class'=>'yii\debug\Module', + 'allowedIPs'=>['1.2.3.4', '127.0.0.1', '::1'] + ] +] +``` + +How to use it +------------- + + +Creating your own panels +------------------------ +