search

EC-CUBE / ec-cube

EC-CUBE is the most popular e-commerce solution in Japan
https://www.ec-cube.net
Other
735 stars 645 forks source link

ディレクトリ構造の見直し #201

Closed Yangsin closed 9 years ago

Yangsin commented 9 years ago

サブディレクトリへの設置、DocumentRoot以上に設置できない環境での動作を想定し、 html/index.php ではなく index.php と.htaccessを、RootDirにおく構成を検討中

186 や #191 のような環境を考慮。

構成イメージ

細かなものは省略しますが、以下のようなイメージです。

[EC-CUBE ROOT DIR] （Document Rootや、サブディレクトリになるフォルダ)
├──app  （主に環境によって変更が入るものを配置）
|  ├── Cache/  
|  ├── Config/
|  ├──  Plugin/ （プラグイン）
|  ├──  template/ （デザインテンプレートが配置される）
|  |    ├──  Admin/
|  |    └──  Default/
|  ├──  upload/
|  └──  .htaccess
|
├── html/  （外部から直接参照する必要のあるもののみ配置）
|   ├──  css/
|   ├── js/
|   └── upload/
|
├── src/ 
|   └── Eccube/ （EC-CUBEのCOREとなるソースを配置、アップデート時上書き）
|       └── Application.php
|
├── vendor/
├── .htaccess （web.config ） （リライトルールが記載されている）
├── index.php （ルーティング）
└── robots.txt （万が一のクローラー被害に備えて、uploadや他のディレクトリをクローラから除外）

合わせて必要と思われる機能

2.13までのinstallファイルのチェック・警告のように、外部からの参照を想定しないフォルダがアクセス可能である場合の警告。
インストーラーでもチェックする。
サーバーが自分のGIPで自分を探せない環境を想定し、PHPではなく、JSを利用してブラウザ側からチェックを行うイメージ。

ttsuru commented 9 years ago

@Yangsin ご参考までにSilexを使ったCMSです。 https://github.com/bolt/bolt

template と plugin は直下においてはどうでしょうか。

Yangsin commented 9 years ago

@ttsuru
ありがとうございます。 templateとpluginを切り出す上での利点ってなにかありますか？ あまりEC-CUBE ROOTの下にディレクトリを増やすより ・サイトごとにいじるところ ・アップデートで入れ替わるCORE ・お外に公開してもいいもの くらいシンプルな構成にしておくほうが、扱いが容易かなとおもってまして。

ttsuru commented 9 years ago

@Yangsin たしかに直下を増やさない方がいいとも思いますが、今までインストールが非常に難しかたので、簡単にする意味でも直下においた方が作業がしやすいと思います。 とくに、非エンジニア層が操作するのは template と plugin のみなので、簡単にインストールできた方がと思いました。

Silex を代表するproductの bolt でもそのような構造になっており、ファイルをアップロードするだけでインストールできるようにするのであれば、plugin と template は分離した方がよいと思いました。

Yangsin commented 9 years ago

今までのインストールが難しかったというのはどういった点でしょうか。
非エンジニアのインストールの難易度は、ディレクトリ構成よりも、Webインストーラーやeccube_install.shでいかに解決するかが一番のポイントかと思います。

何かご懸念があるとおもうのですが、ちょっと私のほうでイメージがしきれておらず、、、app/config があやまって上書きされて事故るのでとかでしょうか。 だとすると、TemplateやPluginを外に出ししたときの、appディレクトリの性格はどういったユーザーやシステムで扱われる性格のものになるイメージでしょうか。

Rootをシンプルにしておく良さとしては、他のアプリケーションと同居するときなども扱いやすいとおもっているので、できるだけEC-CUBEで必要なものはまとめておければと思ってます。

一度、 #118 や PR197 をうけて以下のようにすこしテンプレートの場所を見なおしてみましたが、いかがでしょうか。

src/Eccube の下の構成から、他の構成が連想しやすいように、Pluginの仕様はすでにそうなってますが、
テンプレートも、 src/Eccube/View/[TPL_CODE] と app/Eccube/View/[TPL_CODE] のような形で対比しやすいくらいにしておければと思っています。

[EC-CUBE ROOT DIR] （Document Rootや、サブディレクトリになるフォルダ)
├──app  （利用者によって変更が入るものを配置）
|  ├── Cache/ 
|  ├── Config/
|  ├── Plugin/ （プラグイン）
|  |    └──  SmaplePlugin/  (プラグインの構成はsrc/Eccube の下に準拠する）
|  ├── View/ （デザインテンプレートが配置される）
|  |    ├──  Admin/ 
|  |    ├──  [DesignTemplate] 
|  |    └──  Default/
|  ├──  upload/
|  └──  .htaccess
|
├── html/  （外部から直接参照する必要のあるもののみ配置）
|   ├──  css/
|   ├── js/
|   ├── user_data/
|    |     └─ templates/[DesignTemplate]/ {css, img, js}  （テンプレートの静的ファイル）
|   └── upload/
|
├── src/ 
|   └── Eccube/ （EC-CUBEのCOREとなるソースを配置、アップデート時上書き）
|      ├── View/ 
|      |     ├── Admin/  （EC-CUBE標準管理画面）
|      |     └── Default/  （EC-CUBEデフォルトテンプレート）
|      └── Application.php
|
├── vendor/
├── .htaccess （web.config ） （リライトルールが記載されている）
├── index.php （ルーティング）
└── robots.txt （万が一のクローラー被害に備えて、uploadや他のディレクトリをクローラから除外）
ttsuru commented 9 years ago

とくに、非エンジニア層が操作するのは template と plugin のみなので、簡単にインストールできた方がと思いました。

こちらの部分はインストールというよりもファイルの更新などがアップロードでも簡単にできるようにという意味です。 EC-CUBE自体のインストールに言及した話ではありません。 GUIからのテンプレート更新よりもFTPアップの方がデザイナーにとっても慣れれば負荷が少ないといった声からです。 このあたりはboltでも同様な歴史的経緯をたどっていて、app以下にあった extentions/ theme/ がroot直下に移動しています。 WPなどでも似たような構造になっていると思います。 このあたりはroot 直下に置いて、 htmlからは /template/default/img/... などと直接ファイルを参照させる手もあると思います。 このあたりはpluginなどの自動インストールなども想定した提案です。

View についてはできるだけResouceの中に入れた方がよいかとおもいます。 また、template という名前で今後も同様の名前でいくのでしたらViewよりもtemplateの方が適切な名前なのではとおもいます。

また、デザインテンプレートのstaticファイルはどこに置くことを想定していますか？ こちらもsrc内に原本を置くことを想定した方が良いと思います。 template/[template_name]/css や template/[template_name]/img などです。

何かご懸念があるとおもうのですが、ちょっと私のほうでイメージがしきれておらず、、、app/config があやまって上書きされて事故るのでとかでしょうか。 だとすると、TemplateやPluginを外に出ししたときの、appディレクトリの性格はどういったユーザーやシステムで扱われる性格のものになるイメージでしょうか。

appについては symfony と同じように設定やキャッシュ、ログなどのデータを置く場所でよいとおもいます。また、このあたりは通常小文字のみでよいと思います。 src 以下の path名が大文字から始まるのはPSRによるNamespaceとの一致を目的としており、それ以外は大文字にする必要はないと思います。

app/Eccube/View/[TPL_CODE] については階層が無駄に深くなるのでお勧めしません。 PHPのautoloadはPSR-1ではなく、PSR-4が主流になっています。

また、#186 や #191 についてば実装されていない環境変数の問題で、整備すればhtml以下のみを公開ディレクトリとしても問題は起きないと思います。

186 や #191 はrootにindex.phpを置いたことで解決する問題ではないと思います。

どちらにせよ、最終的には vendor/autoload.php のパスさえっていれば動作するようになると思います。

Yangsin commented 9 years ago

ありがとうございます。

具体的にapp/ 以下でなくなる理由は、FTPでアクセスしたときに潜らなくていいから手間が楽ということなのか、app/ をさわらせなくないからなのか。で、いうと前者ということでしょうか？

こちらについては、Symfony2 のお作法てきなところでしょうか？

結局のところ、app/ 以下をどういう性格として決めるかによって、判断ができそうです。

186 や #191 に言及しているのは、インスールが上手くいかない問題ではなく、

すでに他のアプリやサイトが稼働しているサーバーのサブディレクトリとして設置が容易なように、root にindex.php を置くとうことです。 [EC-CUBE ROOT DIR] /html/index.php だと、http://SITE_URL/[EC-CUBE ROOT DIR]/html/index.php がデフォルトになってしまうので、htmlを除くためにちょっと面倒な事や、他のアプリと混在しやすい作りがデフォルトになるので、フォルダ数も増えるのであれば、なおさらかなと思ってます。

補足として、ファイルをアップロードするだけでプラグインをインストールとするというような要件は現状ありませんが、そういったところも配慮いただいているという事はわかりました。ありがとうございます。

Yangsin commented 9 years ago

追記：

また、デザインテンプレートのstaticファイルはどこに置くことを想定していますか？

こちらは、現行と同じようにhtml の下で考えています。
HTTPで直接アクセスされるようなファイルはすべてhtml以下ですね。
2個まえの投稿をすこし更新しております。

ttsuru commented 9 years ago

@Yangsin

こちらについては、Symfony2 のお作法てきなところでしょうか？

はい、srcの中だけは全体がautoloadの対象なのでResourceに入れた方が良いと思います。

index.php の件

こちらはそういった意図なのであれば、以下の方がオススメです。 現状はドキュメントなどが整備されていないのでわかりにくいので整備すればよいと思います。 web_root直下にsrcやvendorを入れて他のプログラムと共有は考えてはいけないと思います。 結局、vendor以下は共有で今後のphp界ではほぼ必ず必要なります。 そのため、 サブの方法として、以下でセットアップできるようにすれば良いと思います

[EC-CUBE ROOT DIR] （Document Rootや、サブディレクトリになるフォルダ)
├── eccube/ 
|     ├──app  （利用者によって変更が入るものを配置）
|     |  ├── cache/ 
|     |  ├── config/
|     |  ├── plugin/ （プラグイン）
|     |  |    └──  SmaplePlugin/  (プラグインの構成はsrc/Eccube の下に準拠する）
|     |  ├── template/ （デザインテンプレートが配置される）
|     |  |    ├──  Admin/ 
|     |  |    ├──  [DesignTemplate] 
|     |  |    └──  Default/
|     |  ├──  upload/
|     |  └──  .htaccess
|     |
|     ├── src/ 
|     |   └── Eccube/ （EC-CUBEのCOREとなるソースを配置、アップデート時上書き）
|     |      ├── Resource/template/ 
|     |      |     ├── Admin/  （EC-CUBE標準管理画面）
|     |      |     └── Default/  （EC-CUBEデフォルトテンプレート）
|     |      └── Application.php
|     |
|     └── vendor/
|
├── css/
├── js/
├── template/[DesignTemplate]/ {css, img, js}  （テンプレートの静的ファイル）
├── upload/
├── .htaccess （web.config ） （リライトルールが記載されている）
├── index.php （ルーティング）
└── robots.txt （万が一のクローラー被害に備えて、uploadや他のディレクトリをクローラから除外）
ttsuru commented 9 years ago

・template と plugin をRootに置きたい件 具体的にapp/ 以下でなくなる理由は、FTPでアクセスしたときに潜らなくていいから手間が楽ということなのか、app/ をさわらせなくないからなのか。で、いうと前者ということでしょうか？

前者です。他のCMSでもplguinとtheme系は浅いディレクトリに置いてあることが多く、その方が一般的かつわかりやすいと思います。 今までは data/Smarty/templates/[template_name] という深いディレクトリにあり、デザイナーが実際にどのファイルかがわかりにくかったとおもいます。 Wordpressでもブラウザからも編集できますが、実際にはファイル直での編集がテーマ開発者の間では一般的です。

また、上記のような構成になればrootがシンプルになり、置きやすいとおもいます。

Yangsin commented 9 years ago

結局、vendor以下は共有で今後のphp界ではほぼ必ず必要なります。

他のアプリとの共存する環境も、同じ階層で共存ではなく、どちらか一方を下位のディレクトリに入れるので、vendorがぶつかる事はないので、そこまで意識しなくてもいいような気がしてます。

ご提案いただいた階層だと開発中の状況からもかなり変わるので、難しいなと思ってます。 Resourceの件はお作法として、採用させていただきたいと思ってます。

その他、Pluginが公開ディレクトリ側になにかを配置する事、CSS, JSについてはテンプレートに依存関係があるため、テンプレートが内包する事を基本とする形として、以下ではいかがでしょうか。

[EC-CUBE ROOT DIR] （Document Rootや、サブディレクトリになるフォルダ)
├───app  （利用者によって変更が入るものを配置）
|  ├─ Cache/ 
|  ├─ Config/
|  ├─ Plugin/ （プラグイン）
|  |    └──  SmaplePlugin/  (プラグインの構成はsrc/Eccube の下に準拠する）
|  ├─ template/ （デザインテンプレートが配置される）
|  |    ├──  Admin/ 
|  |    ├──  [DesignTemplate] 
|  |    └──  Default/
|  |
|  ├─  upload/
|  └─  .htaccess
|
├── html/  （外部から直接参照する必要のあるもののみ配置）
|  ├─ template （各テンプレートの静的ファイル）
|  |    ├─  Admin/ {css, img, js}  
|  |    ├─  Default/ {css, img, js}  
|  |    └─  [DesignTemplate]/ {css, img, js} 
|  |   
|  ├─ plugin/ （外部から直接参照する必要のあるPluginのファイルのみ配置）
|  |    └─  SamplePlugin/ {css, img, js} 
|  |   
|  ├─ user_data （管理画面のファイル管理から利用するフォルダ。ユーザーがよしなに。）
|  |   
|  └─ upload/ （商品画像等、EC-CUBEの機能により外部公開でアップされるファイル）
|
├── src/ 
|  └── Eccube/ （EC-CUBEのCOREとなるソースを配置、アップデート時上書き）
|    ├── Resource/template/ 
|    |     ├── Admin/  （EC-CUBE標準管理画面）
|    |     └── Default/  （EC-CUBEデフォルトテンプレート）
|    └── Application.php
|
├── vendor/
├── .htaccess （web.config ） （リライトルールが記載されている）
├── index.php （ルーティング）
└── robots.txt （万が一のクローラー被害に備えて、uploadや他のディレクトリをクローラから除外）

20150514 09:02 テンプレートのディレクトリ名がちょっと間違えていたので修正

Yangsin commented 9 years ago

リライトが可能な環境というのが、動作環境になってくるので、Rootに.htaccess だけ置いて、index.php もhtmlに置くという方法で少し考えてみました。

[EC-CUBE ROOT DIR] （Document Rootや、サブディレクトリになるフォルダ)
├───app  （利用者によって変更が入るものを配置）
|  ├─ cache/ 
|  ├─ config/
|  ├─ plugin/ （プラグイン）
|  |    └──  SmaplePlugin/  (プラグインの構成はsrc/Eccube の下に準拠する）
|  ├─ template/ （デザインテンプレートが配置される）
|  |    ├──  Admin/ 
|  |    ├──  [DesignTemplate] 
|  |    └──  Default/
|  |
|  ├─  upload/
|  └─  .htaccess
|
├── src/ 
|  └── Eccube/ （EC-CUBEのCOREとなるソースを配置、アップデート時上書き）
|    ├── Resource/template/ 
|    |     ├── Admin/  （EC-CUBE標準管理画面）
|    |     └── Default/  （EC-CUBEデフォルトテンプレート）
|    ├── Resource/doctrine/ 
|    |     └── migration /  （DBマイグレーション用のソース設置配置）
|    └── Application.php
|
├── html/  （外部から直接参照する必要のあるもののみ配置）
|  ├─index.php （ルーティング）
|  |   
|  ├─ template （各テンプレートの静的ファイル）
|  |    ├─  Admin/ {css, img, js}  
|  |    ├─  Default/ {css, img, js}  
|  |    └─  [DesignTemplate]/ {css, img, js} 
|  |   
|  ├─ plugin/ （外部から直接参照する必要のあるPluginのファイルのみ配置）
|  |    └─  SamplePlugin/ {css, img, js} 
|  |   
|  ├─ user_data （管理画面のファイル管理から利用するフォルダ。ユーザーがよしなに。）
|  |   
|  └─ upload/ （商品画像等、EC-CUBEの機能により外部公開でアップされるファイル）
|
├── vendor/
├── .htaccess （web.config ） （リライトルールが記載されており、html以下が参照される）
└── robots.txt （万が一のクローラー被害に備えて、uploadや他のディレクトリをクローラから除外）
seasoftjapan commented 9 years ago

この際、ドキュメントルートを / にしても /html/ にしても動作するとかできないですかね。 無理なくできるならって程度の要望ですが。

Yangsin commented 9 years ago

@seasoftjapan うーん。デフォルトで設置されるパスをあまり複雑に考えすぎると逆にセキュリティの穴をつくりそうですので、PHPでそこらへんを担保するような実装は怖いですね。

seasoftjapan commented 9 years ago

怖い実装となるなら不要ですね。