Apart from having multiple kinds of configuration, we can have multiple entry points in advanced applications.
In advanced web applications, in fact, we also have a different approach in the development stage. We usually have two environments: development and production. In the first one, we make tests using fake users, data, and so on, while in the second one we must take care to guarantee the proper functioning of the project.
Therefore, we will have different sets of configuration files and parameters based on environments where we will work in.
We could wish, in fact, to test the application using the development database instead of the production database, or specific parameters available only in a specific environment.
Indeed, the init
command offers this capability to switch different configuration and parameters for different environments. Basically, there are two environments: development and production.
The init
command can be launched both in interactive mode as well as in noninteractive (silent) one.
In the interactive mode, starting from the yiiadv
folder:
$ php init
And in a noninteractive (silent) mode:
$ php init --env=Development --overwrite=All
In both modalities, we need to specify only the target environment if we want to overwrite all the current configuration files.
This command will simply copy the content of the chosen environment (according to the type of selected environment) in the respective application folder, with the same name starting from root.
For example, open the folder in environments/dev/backend
. We will see two folders: config
and web
, containing the first two configuration files and the other files index.php
and index-test.php
. These files will overwrite the corresponding files in the backend
folder starting from the root folder of the project.
So, if we launch the preceding command with parameters of init
, the content of the folders in environments/dev
(the backend
, common
, console
, and frontend
folders) will be copied in the backend
, common
, console
, and frontend
folders starting from the root folder of the project.
Also, with this command, other operations such as making some folders writable or applying specific values to configuration properties, are accomplished. However, the init
command is mainly used to switch different configurations and index.php
files.
Starting from any application of the project (backend, frontend, common, and console), configuration values and parameters taken from the top of any application's index.php
file (backend, frontend, common, or console) are read in the following sequence:
common/config/main.php
common/config/main-local.php
config/main.php
config/main-local.php
This means that the config
parameters are initially read firstly from common/config/main.php
then from common/config/main-local.php
, then again from application config/main.php
, and finally from application config/main-local.php
. The properties with same name will be overwritten during the reading of other configuration files.
Therefore, if the same configuration property is declared in all four configuration files, its value will be the same as config/main-local.php
, which is the last configuration file to be read.
Since, we locally have a last chance to apply differences towards a specific property of configuration with the -local
version of files, the content of environment subfolders will be only about the -local
version of a specific file. For example, if we open environments/dev/backend/config path
, we will see only main-local.php
and params-local.php
, practically the last two filenames that index.php
will read in sequence.
So if we change the database connection parameters in environments/dev/backend/config/main-local.php
and then apply init
with the dev
target environment, this file will overwrite backend/config/main-local.php
. This is the last configuration file that backend/web/index.php
will read during its bootstrap (if we browse /backend/web/index.php
).
Now that we have executed the init
command in the dev
environment, we can point the browser to http://hostname/yiiadv/frontend/web
and we should see the same congratulations page of the basic template.
In the same way, the backend entry point is also available pointing to http://hostname/yiiadv/backend/web
, where a login form is displayed by default (this is because it is a restricted area).
As we have seen, the frontend application is a reachable pointing browser to http://hostname/yiiadv/frontend/web
.
However, the first thing to set in the frontend access is URL-friendly customization; this is because it is important that our public website is well positioned in the search engine.
As we have done in the basic template, we can render pretty URLs in the advanced template too, following these two steps:
.htaccess
file in yiiadv/frontend/web
.urlManager
component in yiiadv/frontend/config/main.php
.In step 1, it is enough to create a file in yiiadv/frontend/web/.htaccess
with the following content:
RewriteEngine on # If a directory or a file exists, use it directly RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d # Otherwise forward it to index.php RewriteRule . index.php
This code will make the web server URL rewrite work, rewriting all requests to the index.php
file in yiiadv/frontend/web
.
While, in step 2, we must add the urlManager
property in yiiadv/frontend/config/main.php
:
'urlManager' => [ 'enablePrettyUrl' => true, 'showScriptName' => false, ],
Now we can refresh the web browser to http://hostname/yiiadv/frontend/web
and navigation to the URL link on the top, and we can see, for instance, that URL is in pretty form.
We can consider the frontend
folder as a Yii standalone application and we can create controllers, views, models, and so on.
18.223.172.252