EC-CUBE3 分室もこれで4回目です。
最初の投稿から4週目と云う事ですが、社内のEC-CUBE3担当との間に差をつけられてばかりの為「これはまずい・・・」と云う焦りもあります。
まぁ直接の業務に直結していない分、じっくりと基礎研究?を重視して行きたいと思います。
さて今回は 2系で開発している時にも頻繁に発生していた内容を事前に確認して置きたいと思います。
内容は「EC-CUBEのインストール先について」です。
自社環境のサーバーなど、サーバーの設定を自由に変更できる場合には無用な心配です。
しかし、レンタルサーバーなど DocumentRoot を変更が出来ない場合や、DocumentRoot より上位階層にファイルを置けない場合があります。
2系の場合には、私が EC-CUBE に出会うよりも前に設定方法が確立していました。
今回の3系はどうなのか調べて行きたいと思います。
場合によってはリダイレクトで何とかする必要があるなぁ・・・
・
・
・
お~、EC-CUBE3 に関しては公式に対応されているみたいですね。
インストール時にURLからhtmlを無くす手順
ただし「EC-CUBE 3.0.11 以降」とのことです。
まぁ、3.0.11 より前のバージョンをあえて新規インストールをすることは無いはずです。
特に大きなデメリットは無いと考えていいのではないでしょうか。
しかしながら以下の注意文は記載されているため、プラグインを使用・作成する際には注意は必要です。
下記の手順を行うことで、通常のEC-CUBEとは異なるファイル構成になります。 そのため、一部のプラグインなどが正常に動作しない可能性があることをご理解ください。 また、この方法でのインストールを行う前に、まずはDocumentRootの変更などサーバー設定での対応をご検討ください。
それでは一度試してみたいと思います。
インストール前に行う作業は以下の作業の様です。
1. ファイル配置場所の変更
2. .htaccess / web.config の置き換え
3. index.php / index_dev.php / install.php の変更
4. autoload.php の変更
5. EC-CUBEのインストール
■1. ファイル配置場所の変更
まずは EC-CUBE3 を展開しないと話になりません。
展開した後に「html」内の6ファイルを1階層上に移動します。
index.php
index_dev.php
install.php
robots.txt
.htaccess
web.config
※展開した直後はの状況で行うと「.htaccess」はファイルの上書きを確認されます。
■2. .htaccess / web.config の置き換え
次に設定ファイルの置き換えですね。
以下のファイルを一旦削除してsampleファイルから作り直します。
.htaccess.sample → .htaccess
web.config.sample → web.config
・・・これ「1.」の時に、対象の2ファイルは移動では無く、削除で良い様な気がしますね(笑)
■3. index.php / index_dev.php / install.php の変更
今回は2系とは異なり、事前に切り替えようの記述もされているようです。
ここまで対応頂いているのであれば対応も楽ですね。
require __DIR__.'/../autoload.php'; //require __DIR__.'/autoload.php';
↑ を ↓ へ変更する。
//require __DIR__.'/../autoload.php'; require __DIR__.'/autoload.php';
■4. autoload.php の変更
これも記述内容自体は異なりますが「3.」と同じでファイルの切り替え処理ですね。
define("RELATIVE_PUBLIC_DIR_PATH", ''); //define("RELATIVE_PUBLIC_DIR_PATH", '/html');
↑ を ↓ へ3ファイルとも変更する。
//define("RELATIVE_PUBLIC_DIR_PATH", ''); define("RELATIVE_PUBLIC_DIR_PATH", '/html');
■5. EC-CUBEのインストール
これで基本的な対応は完了です。
あとは標準と同じ手順にてインストールが出来れば完了です。
ちなみに、この時点で画面が大きく崩れていれば上記の手順を再度行うなどの確認を行う方が無難なようです。
・・・個人で初めて導入する人にもわかるほど画面が崩れるのでしょうか。
一度試してみたい気もします(笑)
さて、実際に試したところ見事に「html」の階層を無くすことが出来ました。
2系の時に同じことするよりは多少手間は掛かるようですが公式に対応されるということは喜ばしい事です。
まぁ、プラグインの対応に関して不安が無いわけではありませんが、3.0.11 にバージョンアップする際にプラグインの仕様も変わっています。
今後は「特に問題が出ないといいなぁ」と思いながら使用して行きます(笑)