πŸ“œ ⬆️ ⬇️

Yii discrete projects based on a common core


Good evening to all habrausers!

I want to share certain ideas and thoughts on the creation of separate projects in Yii based on one common core.

Some time ago, having passed from kohana to yii due to my working needs, I have long rejoiced at its simplicity and convenience, which, as it seemed to me, were many times more than Kohana’s (yes, the fans of this framework will forgive me), and then however, it was necessary to go deep into the architecture of Yii, and, in particular, into the possibility of distributing its projects from a single core.
')
Initially, what is called β€œout of the box”, Yii is already delivered in separate folders with the kernel itself and several demo projects on it, but this was not enough for me, since several other project management and control capabilities were needed, on the basis of which those ideas that I want to present.


Little reservations

Let's start with the fact that I will not bother with the fine settings of Apache, php, or other things right now, because I want to present just an idea and find out your, dear habrayusers, an opinion on whether to develop the proposed method further and how it can be modified. therefore, at once I will make a reservation that all the actions described below take place on the newly installed ubunt 11.10 and the traditional lamp from the box.
It is also assumed that the reader is already familiar with the basics of Yii, and at least roughly knows its directory structure.

Training

So, initially we have the easiest host with some of these settings:

<VirtualHost *:80> ServerName demo.lori ServerAlias demo.lori www.demo.lori DocumentRoot /home/lori/workspace/demo.lori/www ErrorLog /home/lori/workspace/demo.lori/logs/error.log CustomLog /home/lori/workspace/demo.lori/logs/access.log common </VirtualHost> 


ZY The .lori domain zone is selected for tests and of all the possible meanings of meaning bears in itself only the accepted alternative name of your humble servant.

Log folders were selected for faster access to them during the development process (I do not claim to be a guru in the field of Unix, and therefore, if someone tells me that this is not kosher, I’ll be happy to hear).

Additionally, in the workspace folder, we create a folder called yii , where we unpack the freshly archived archive in Yii, and more specifically, the framework folder from it (at the time of the article creation, the last stable version of the framework was 1.1.10). From now on, this will be our core, and (purely theoretically, of course), in the future we will touch it very rarely.

After that, in the /home/lori/workspace/demo.lori/www folder, we will organize the following structure (according to the recommendations Yii modified for this method):

- www /
β€”β€” index.php
β€”β€” .htaccess
β€”β€” config /
β€”β€”β€” devel /
β€”β€”β€”β€” <development location config files>
β€”β€”β€” stable /
β€”β€”β€”β€” <production location configuration files>
β€”β€” engine /
β€”β€”β€” <project project files>
β€”β€” themes /
β€”β€”β€” basic / (main theme name)
β€”β€”β€”β€” static /
β€”β€”β€”β€”β€” images /
β€”β€”β€”β€”β€” css /
β€”β€”β€”β€”β€” js /
β€”β€”β€”β€” views /
β€”β€”β€”β€”β€” <files of all our views by topic>

Now, according to the above organization, all project files (controllers, components, models, etc.) will be stored in the engine folder, the themes folder will not change, themes and other static content like CSS or JS files will be stored here. The config folder also remains canonical, however, its insides will change somewhat.

After all the folders and files have been created, it remains, as Yii experts have rightly noticed, to create the runtime and assets folders, however, the first significant changes begin here. These folders will be organized in a special way.

Immediately note: all further commands are executed through sudo, because I will not specify it, assuming that we already have all the rights.

We create a common warehouse for our projects:
 mkdir -p /home/projects/data/demo.lori cd /home/projects/data/demo.lori mkdir -p ./assets/stable mkdir -p ./runtime/stable mkdir -p ./upload/stable mkdir -p ./assets/devel mkdir -p ./runtime/devel mkdir -p ./upload/devel 

Now we need to allow our framework to create files in these folders, for this we execute:
 chown www-data -R /home/projects 

(There is also a small question for the experts * unix, are there any comments on the rights?)

Now all we have to do is create symlinks for these folders in our project:
 ln -s /home/projects/data/demo.lori/assets /home/lori/workspace/demo.lori/www/assets ln -s /home/projects/data/demo.lori/runtime /home/lori/workspace/demo.lori/www/runtime ln -s /home/projects/data/demo.lori/upload /home/lori/workspace/demo.lori/www/upload 


UPD1 (Based on Comments): Why use a similar directory structure ?
1) According to the theory of Yii, assets should store files that somehow join the project, for example, some third-party js scripts, css-files, pictures and other things, so if I use in all my projects, for example , trivial jQuery or CSS reset, it would be more logical to store them in one place outside of all projects.
2) Runtime did not make much sense, but theoretically it does not play a special role in development and is needed by Yii himself, because in order not to clutter up the project folder itself, this directory is moved beyond its limits.
3) Remote and centralized uploading is needed so that, for example, when there is some kind of environment on the local network, the files used in the projects are common for all developers, for example, if in some project there is an avatar download to the user, it is more logical to do so that if one person loads the picture, then all other developers should see it, if there is some link to it in the database.

At this basic training completed, go directly to setting up the project.

Configure entry point

Let's start with the index.php file, it is almost no different from the standard Yii entry point, with the exception of corrections for splitting locations into production and production:
 <?php date_default_timezone_set('Europe/Moscow'); error_reporting(E_ALL); ini_set('display_errors', 1); //  Yii $yii = dirname(__FILE__).'/../../yii/yii.php'; /* ,      .    ,     ,   .     ,       . */ define('DEVELOP_LOCATION', (gethostname() == 'lori-desktop' ? 'devel' : 'stable')); /*     ,    .    . */ if (array_key_exists('HTTP_LORI_DEBUG', $_SERVER) and $_SERVER['HTTP_LORI_DEBUG'] == 'DEBUG IT, DEBUG!') { defined('YII_DEBUG') or define('YII_DEBUG',true); defined('YII_TRACE_LEVEL') or define('YII_TRACE_LEVEL', 10); } /*       .htaccess.      ,  ,    . */ if ($_SERVER['REQUEST_URI'] != $_SERVER['REDIRECT_URL']) $_SERVER['REQUEST_URI'] = $_SERVER['REDIRECT_URL']; //        $config = dirname(__FILE__).'/config/'.DEVELOP_LOCATION.'/main.php'; require_once($yii); Yii::createWebApplication($config)->run(); 

.Htaccess itself looks like this at the moment:
 AddDefaultCharset UTF-8 RewriteEngine on RewriteBase / RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^upload/(.*)$ /forbidden [L] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^assets/(.*)$ /forbidden [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^assets/(.*)$ /nofile [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^upload/(.*)$ /nofile [L] RewriteCond %{REQUEST_URI} !^/assets RewriteCond %{REQUEST_URI} !^/upload RewriteRule ^(.*)$ index.php [L] 

Entry points are ready, now you need to configure configs for them.

Setting options :)

I will not paint the creation of settings for each of the locations, and I will describe the actions for the devel-location, since all changes will take place on it, and the creation of a config for the production-location occurs identically.

To begin with, in the folder config / devel / create the file main.php . It will look like the usual main.php from the config of any project on Yii, but we will add some additions to it according to our file organization:
 <? return array( //          engine 'basePath' => dirname(__FILE__).'/../../engine/', 'name' => 'Demo project', //     runtime    'runtimePath' => dirname(__FILE__).'/../../runtime/devel', //        /themes 'theme' => 'basic', 'preload' => ..., 'import' => ..., 'defaultController' => 'default', //         'components' => array( 'assetManager' => array( 'basePath' => dirname(__FILE__).'/../../assets/devel', ), 'user' => ..., 'db' => ..., 'errorHandler' => ..., 'urlManager' => array( 'urlFormat' => 'path', 'rules' => require_once dirname(__FILE__).'/routes.php', ), 'log' => ... ), 'params' => require(dirname(__FILE__).'/params.php'), ); 

In the above configuration, the three-dot numbers replace the standard blocks of code that are not affected by the current changes in the file organization and which therefore do not need to be described.
Additionally, it is worth mentioning the urlManager setting:
I don’t like that the classical routing is confused with the config, so I always put it in a separate routes.php file in the same folder as main.php , and it contains the usual structure of the form
 <? return array( 'var1' => 'value1' ); 

Afterword

This, in principle, the entire basic project setup is completed - the project is set up.

Advantages of this approach:
- The separation of projects from each other
- One engine for all projects, which allows you to update it or supplement it once and for all projects at once
- Presence of division into development and production locations, with own configs and included files
- Convenience when working with version control systems like Git
- To some extent, the theme catalog separated from the project

Minuses:
- not yet detected

I like this approach with my flexibility, because, if you look at it, you can seriously expand it, operating with htaccess locations, creating separate configs for different environments, and much more, while not worrying about some kind of buns into the core, transfer changes in all your projects (after all, the core, like any project, is a project in itself, which can also be changed to dev-location and unloaded to production.

If someone has any comments or questions, I will be glad to hear and, if possible, to answer or correct some places in the given example.

Also, I would like to ask the public about the need to create a series of articles devoted to the full cycle of creating a project on Yii, because, frankly, I did not find similar articles on the web, basically there are a lot of articles on certain topics like caching or validation, and the original guide, presented by the developers, also does not give a full perception of the project on Yii as a whole.

Thanks to everyone who read the article to the end!

UPD: Some nevertheless expressed that the course of articles is not such a bad proposal, then I would like to ask: if you make a cycle on the subject of OT and DL, then what is not a trivial (like the proposed blog or address book) site you would like to see ?

Source: https://habr.com/ru/post/141695/


All Articles