すべてのhabrayuzeryへこんばんは！
1つの共通のコアに基づいてYiiで個別のプロジェクトを作成するというトピックに関する特定のアイデアとアイデアを共有したいと思います。
少し前に、必要に応じてkohanaからyiiに切り替えて、私は長い間、そのシンプルさと利便性に満足していました。それは私には思えたが、kokhana（恋人がこのフレームワークを許してくれた）の何倍もありました同じ作業上のニーズがあり、Yiiのアーキテクチャを掘り下げなければなりませんでした。特に、1つの独立したカーネルからプロジェクトを配布する可能性がありました。
当初、「箱から出してすぐに」と呼ばれるものは、Yiiには既にカーネル自体といくつかのデモプロジェクトが含まれた個別のフォルダーがありますが、作成に基づいて他のプロジェクト管理および制御機能が必要だったため、これでは十分ではありませんでした私が述べたいアイデア。
少し予約
そもそも、Apacheやphpなどの細かい設定に煩わされることはありません。アイデアを提案し、あなたの意見、親愛なるhabrayuzers、提案された方法をさらに開発する価値があるかどうか、修正する方法を知りたいからです。したがって、私はすぐに、新しくインストールしたubunt 11.10と箱から出して従来のランプで以下に説明するすべてのアクションが発生することを予約します。
また、読者はすでにYiiの基本に精通しており、少なくともそのディレクトリ構造を大体知っていると想定されています。
準備する
そのため、最初はおおよそ次の設定を持つ最も単純なホストがあります。
<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>
Z.Y. .loriドメインゾーンは 、テストのために選択され、考えられるすべての有効なオプションから選択されます。これは、人々に受け入れられた謙虚な使用人の代替名のみを保持します。
ログフォルダーは、開発プロセス中にそれらにすばやくアクセスするために選択されました（Unix領域の第一人者のふりをすることはありません。したがって、誰かがこれがコーシャーではないと言ったら、喜んで聞きます）。
さらに、ワークスペースフォルダーにyiiというフォルダーを作成します。ここで、Yiiに新しくダウンロードしたアーカイブ、具体的にはそこからフレームワークフォルダーを解凍します（記事の作成時点では、フレームワークの最後の安定バージョンは1.1.10でした）。 これからは、これが私たちの中核になり、（もちろん理論的にはもちろん）将来的にはめったに触れません。
その後、/ home / lori / workspace / demo.lori / wwwフォルダーで、次の構造を整理します（このメソッド用に変更されたYiiの推奨事項に従って）。
-www /
-index.php
-.htaccess
-config /
——— devel /
———— <開発場所の構成ファイル>
——— 安定した/
———— <生産場所の設定ファイル>
- エンジン/
——— <プロジェクトプロジェクトファイル>
- テーマ/
——— 基本/ （メイントピックのタイトル）
———— 静的/
————— 画像/
————— css /
————— js /
———— ビュー/
————— <<トピックごとのすべてのビューのファイル>
これで、上記の組織によると、すべてのプロジェクトファイル（コントローラー、コンポーネント、モデルなど）はエンジンフォルダーに保存され、 テーマフォルダーの保存先は変更されず、テーマやCSSやJSファイルなどの他の静的コンテンツがここに保存されます。 configフォルダーも標準のままですが、内部は多少変更されます。
すべてのフォルダーとファイルが作成された後、Yiiの専門家が正しく認識しているように、ランタイムフォルダーとアセットフォルダーを作成しますが、ここで最初の重要な変更が始まります。 これらのフォルダは特別な方法で整理されます。
ただ注意：それ以降のコマンドはすべてsudoを介して実行されるため、既にすべての権限を持っていると仮定して、それを示しません。
プロジェクト用の共通の倉庫を作成します。
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
ここで、フレームワークがこれらのフォルダーにファイルを作成できるようにする必要があります。これを実行するには、次のようにします。
chown www-data -R /home/projects
（* unixの愛好家のための小さな質問もあります。権利についてのコメントはありますか？）
あとは、プロジェクトのこれらのフォルダーへのシンボリックリンクを作成するだけです。
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（コメントに基づく）：同様のディレクトリ構造を使用する理由
1）Yii理論によれば、ファイルは何らかの方法でプロジェクトにアタッチするアセット、たとえばサードパーティのjsスクリプト、cssファイル、写真などに保存する必要があります。たとえば、すべてのプロジェクトで使用する場合は、 、ささいなjQueryまたはCSSリセットの場合、すべてのプロジェクトの外部の1つの場所に保存する方が論理的です。
2）ランタイムはあまり意味がありませんでしたが、純粋に理論的には開発では特別な役割を果たさず、Yii自身が必要とします。プロジェクト自体のフォルダを乱雑にしないために、このディレクトリはその外に移動されたためです。
3）たとえば、開発環境がローカルネットワークに展開されている場合、プロジェクトで使用されるファイルがすべての開発者に共通するように、たとえば、アバターがユーザーのプロジェクトにロードされる場合、ある人が写真をロードした場合、他のすべての開発者がデータベースにリンクがあればそれを見ることができるようにするのがより論理的です。
これで、基本的な準備が完了し、プロジェクトのセットアップに直接進みます。
エントリーポイント設定
index.phpファイルから始めましょう。場所を開発者と本番に分割するための修正を除き、標準のYiiエントリポイントとほとんど変わりません。
<?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自体は現在、次のようになっています。
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]
エントリポイントの準備ができました。次に、エントリポイントの構成を構成する必要があります。
設定の設定:)
各場所の設定の作成はスケジュールしません。すべての変更がその場所で行われ、本番の場所の構成の作成は同じであるため、開発の場所のアクションを説明します。
最初に、 config / devel /フォルダーにmain.phpファイルを作成します。 Yiiのプロジェクトの設定からは通常のmain.phpのように見えますが、ファイルの構成に応じて追加します。
<? 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'), );
上記の構成では、ファイル構成の現在の変更の影響を受けないため、説明を必要としない標準のコードブロックを楕円で置き換えます。
さらに、 urlManagerのセットアップについて言及する価値があります 。
古典的なスキームでは、ルーティングが設定と混同されることはあまり好きではありません。常にmain.phpと同じフォルダー内の別のroutes.phpファイルに配置し、フォームの通常の構造が含まれているためです。
<? return array( 'var1' => 'value1' );
あとがき
これで、原則として、プロジェクトの基本的なセットアップ全体が完了し、プロジェクトが構成されます。
このアプローチの利点：
-プロジェクトの相互分離
-すべてのプロジェクトに1つのエンジン。これにより、すべてのプロジェクトを一度に更新または補足できます。
-独自の構成とインクルードファイルを使用した、開発場所と実稼働場所での分離の存在
-Gitのようなバージョン管理システムを使用する際の利便性
-ある程度、プロジェクトとは別のテーマカタログ
短所：
-まだ発見されていない
私はこのアプローチが柔軟性のために好きです。それを見ると、htaccess経由で場所を操作したり、さまざまな環境の個別の構成を作成したりすることで、真剣に拡張できるため、追加するたびに心配することなくカーネルのいくつかの利点、すべてのプロジェクト間で変更を転送します（結局、カーネルはプロジェクトと同様に、開発場所で変更し、本番環境にアップロードすることもできます。
誰かがコメントや質問を持っている場合、私は聞いて喜んで、可能であれば、上記の例のいくつかの場所に答えるか、修正します。
また、率直に言って、私はネットワーク上でそのような記事を見つけられなかったので、Yiiでプロジェクトを作成する全サイクルに捧げられた一連の記事を作成する必要性について一般に尋ねたいと思います。検証、および開発者によって提示された元のガイドも、Yiiプロジェクト全体の完全な認識を与えません。
記事を最後まで読んでくださった皆さんに感謝します！
UPD：記事の流れはそれほど悪い提案ではないという意見もありましたが、OTとTOの開発にサイクルをかけるのであれば、見たいと思う（提案されているブログやアドレス帳のような）サイトではありません？