EC-CUBE3.0.14がリリース、さくらのレンタルサーバでEC-CUBE3.0.14をインストールした時にhtmlをURLに付けさせない方法
3月14日にEC-CUBE3.0.14がリリースされました。
EC-CUBE3.0.14で特徴的なものとしては、
- PHP7.1 対応
があります。
さくらのレンタルサーバはphp7.1がサポートされているため、 EC-CUBE3.0.14から安心して利用できるようになります。
そこで、XSERVERに引き続きさくらのレンタルサーバでhtmlをURLにつけさせない方法を説明します。
基本はXSERVERの時と全く同じです。
EC-CUBE3.0.11をXSERVERにインストールした時にhtmlを付けさせない方法 - AmidaikeBlog
※すでにDBが作成されている前提です。
レンタルサーバでは公開ディレクトリは固定されている事が多く変更する事は出来ないのですが、さくらのレンタルサーバの公開ディレクトリは、
/home/hoge/www
とwww
が公開ディレクトリになっています。
※hoge
の部分は適宜ご自身の環境と読み替えてください。
過去に説明した記事であれば、.htaccess
を色々とごにょごにょする事で対応してきましたが今回も、
インストール時にURLからhtmlを無くす | EC-CUBE 開発ドキュメント
こちらを参考にhtml
を外す方法を説明していきます。
EC-CUBE3.0.14のアップロード
EC-CUBE3.0.14を
EC-CUBEダウンロード | ECサイト構築・リニューアルは「ECオープンプラットフォームEC-CUBE」
こちらからダウンロードし、
FTP等で/home/hoge
直下にアップロードします。
EC-CUBE3.0.14の解凍
さくらのレンタルサーバへSSHでログイン後、アップロードされたディレクトリからEC-CUBEを解凍します。
unzip eccube-3.0.14.zip
解凍したEC-CUBEをwww配下にコピーします。
cd eccube-3.0.14 cp -pr . ../www/
ファイル配置場所の変更
公開ディレクトリまでカレントディレクトリを移動し、html
ディレクトリに存在する必要なファイルを公開ディレクトリ直下に移動させます。
cd cd /home/hoge/www mv html/in* . mv html/.htaccess . mv html/robots.txt .
→今回はweb.configは不要なため移動させていません。
.htaccessの削除、.htaccess.sampleのリネーム
移動した.htaccess
を削除し、public_html直下に存在している.htaccess.sample
に置き換えます。
rm .htaccess mv .htaccess.sample .htaccess
index.php、install.phpの書き換え
- index.phpの書き換え
vi index.php
を実行し、27行目のコメントアウトされている箇所を変更し、26行目をコメントアウトます。
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える require __DIR__.'/../autoload.php'; //require __DIR__.'/autoload.php';
↓
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える //require __DIR__.'/../autoload.php'; require __DIR__.'/autoload.php';
- install.phpの書き換え
vi install.php
を実行し、31行目のコメントアウトされている箇所を変更し、30行目をコメントアウトします。
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える require __DIR__ . '/../autoload.php'; //require __DIR__ . '/autoload.php';
↓
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える //require __DIR__ . '/../autoload.php'; require __DIR__ . '/autoload.php';
autoload.phpの変更
- autoload.phpの書き換え
vi autoload.php
を実行し、36行目のコメントアウトされている箇所を変更し、35行目をコメントアウトします。
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える define("RELATIVE_PUBLIC_DIR_PATH", ''); //define("RELATIVE_PUBLIC_DIR_PATH", '/html');
↓
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える //define("RELATIVE_PUBLIC_DIR_PATH", ''); define("RELATIVE_PUBLIC_DIR_PATH", '/html');
.htaccessの追加
公開ディレクトリをEC-CUBEルート直下にしたため、このままだと見せる必要のないディレクトリまで見えてしまいます。
そのため、以下の.htaccessファイルを各ディレクトリ直下に配置してください。
- .htaccessの内容
order allow,deny deny from all
この内容を
src
、tests
、vendor
ティレクトリ直下に配置します。(appディレクトリ直下には既に存在)
EC-CUBEのインストール
http://hoge.sakura.ne.jp とアクセスし、インストール作業が出来れば対応完了です。
以上がhtml
をURLから付けさせない方法となります。
インストール後もhtmlディレクトリを削除する事は可能ですが、非常にめんどくさいためインストール前に設定するのがオススメです。
この方法で上手く動かないという方はコメントください。
EC-CUBE3の入力チェック時のエラーメッセージで項目名を表示させる方法
EC-CUBE3では入力チェック時のエラーメッセージ表示が標準のままだと項目名が表示されておらず、表示させるためには少々手を加える必要があります。
そこで今回は項目名を表示させたいけど分からないという方のために項目名を表示する方法を説明します。
現在のエラーメッセージの表示は標準ではこのようになっています。
キャプチャを確認してもらうと分かる通り項目名が表示されておらず、何が入力されていないのか分かりづらいです。このエラーメッセージ表示を、
このように項目名を表示させるにはどうするかというと、
ECCUBEROOT/src/Eccube/Resource/template/default/Form/form_layout.twig
の59行目にある
<p class="errormsg text-danger">{{ error.message |trans }}</p>
を
<p class="errormsg text-danger">{{ form.vars.name|trans }} : {{ error.message |trans }}</p
に修正します。
※ECCUBEROOT : EC-CUBE3がインストールされているディレクトリ
この修正だけだとまだ不完全で、
とinput属性のnameがそのまま表示されてしまいます。この部分を日本語に表示させるには、
ECCUBEROOT/src/Eccube/Resource/locale/message.ja.yml
ファイルに以下の設定を追加します。(追加する場所はどこでも可能)
name01: 姓 name02: 名 kana01: セイ kana02: メイ ・ ・ ・
この内容を追加することで項目名が日本語表示されます。
入力チェックエラー発生時に英語表記されたら他の項目に対してもmessage.ja.yml
に
画面上に表示された値: 日本語名
と追加していくことで日本語に対応可能です。
エラーメッセージに項目名を表示させたいという方は是非お試しください。
既に本番環境を運用されている方でこの方法を適用しても項目名が表示されないという方は、ECCUBEROOT/app/cache/translator
ディレクトリを削除後に再度お試しください。
EC-CUBE3の標準デザインについて
EC-CUBE Advent Calendar 2016 22日目の記事です。
公開がかなり遅くなりましたが、22日目はEC-CUBE3の標準デザインについて説明します。
EC-CUBE3で採用されているcssについて
EC-CUBE3からはフロント画面、管理画面ともに標準でレスポンシブ対応となっています。
このレスポンシブ対応を実現するにあたり、EC-CUBE3ではbootstrap3を採用してます。
Bootstrap · The world's most popular mobile-first and responsive front-end framework.
EC-CUBE3で利用されているbootstrap3のcssファイルですが、フロント画面のみカスタマイズが行われており利用するには注意が必要です。
- フロント画面で参照されるcssファイル
[ECCUBEROOT]/html/template/default/css
- 管理画面で参照されるcssファイル
[ECCUBEROOT]/html/template/admin/assets/css
上記のディレクトリにcssファイルが格納されているのですが、フロント画面のbootstrap.custom.min.css
ファイルにはbootstrap3のクラス定義は入っておりません。
また、フロント画面のhtmlタグを確認すると、
<link rel="stylesheet" href="/template/default/css/style.css?v=3.0.xx"> <link rel="stylesheet" href="/template/default/css/slick.css?v=3.0.xx"> <link rel="stylesheet" href="/template/default/css/default.css?v=3.0.xx">
というようにbootstrap3という文字が見当たりませんが、実際はstyle.css
内で
@import url("bootstrap.custom.min.css"); /* only Grid system CSS */
というようにimportされています。
EC-CUBE3ではbootstrap3のデザインをそのまま適用するのではなく、下記のcssファイルでbootstrap3の定義を上書きしています。
- フロント画面
[ECCUBEROOT]/html/template/default/css/default.css
- 管理画面
[ECCUBEROOT]/html/template/admin/assets/css/dashboard
もしbootstrap3をそのまま適用したいという場合、面倒ですが定義を削除する必要があります。
フロント画面ではbootstrap3を新たにダウンロードして上書きする必要があります。
EC-CUBE3のデザイン変更時の方法・注意点
EC-CUBE3のデザインを変更する場合、
があります。
それぞれ一長一短がありますが、標準デザインから全く別のデザインに変更するなら新たにcssファイルを定義しなおす方が楽です。
また、デザインを変更する点で気をつけなければいけない点ですが、
- JavaScriptでidやclass名を指定している画面もあるため、先にJavaScript内で指定している定義を確認
- プラグインを利用する場合、プラグインの種類によってidやclass名を指定して画面項目の表示を行っているものがあるため、利用するプラグインによって定義を確認
があります。それぞれよく忘れがちとなるためご注意ください。
今回はCSSファイルの扱い方について記述しましたが、次回は実際に画面を変更する方法を例を出して説明します。
EC-CUBE2系からEC-CUBE3へのバージョンアップについて
EC-CUBE Advent Calendar 2016 4日目の記事です。
4日目はEC-CUBE2系からEC-CUBE3へバージョンアップした時の内容を書きます。
EC-CUBE2系といっても2系には
- 2.4
- 2.11
- 2.12
- 2.13
というバージョンがあります。今回は2.4からバージョンアップした際に行った内容を書きます。
2.4から3系へバージョンアップする際に主な作業として、
- DBの移行
- プログラム移行
- デザイン移行
等があります。
DBの移行
3系のDBは2系を基本にしていますが、3系に合わせて色々と修正されており、3系から存在しなくった機能については該当するテーブル自体が存在していません。2系と3系のテーブル比較はこちら記事を参考にしてください。
EC-CUBE2とEC-CUBE3のテーブル比較 - AmidaikeBlog
2.4から3系にデーブルを移行するためには、
- マスタ類に関してはそのままデータ移行
- マスタ系以外は商品、受注、会員データについては大きく異なるため、移行用プログラムなどを作成して対応
- ポイントや商品レビュー機能など3系では標準で存在しない機能を利用していた場合、プラグインのテーブルに合わせて移行
を行います。また、当時PostgreSQLを採用していた場合、MySQLへ移行しても特に問題はありません。
移行ブログラムについては後日公開します。
デザイン移行
3系ではテンプレートがSmartyからTwigに変更されています。そのため、全ての画面をTwigに変更する作業が発生します。
DBのように移行プログラムなどを作成できれば作業の軽減ができますが、残念ながらそれができないため全て対応する必要があります。
デザインの移行にあたり、
- 全ファイルをTwigに変更
- 画像ファイルなどのリソースファイル移行
- 標準機能にない場合、プラグインをインストール後に適切なレイアウトに修正
が必要になります。
プログラム移行
デフォルトのまま2.4を利用していた場合、問題なくそのまま3系の機能を使えますが独自にカスタマイズをしていたら変更が必要です。
EC-CUBE3ではフレームワークにSilexを採用しているため、それに則って本体をカスタマイズする必要があります。プラグインで対応出来るのであればプラグインでも対応しても問題ありません。
その他
2系採用当時に最新のミドルウェアを採用していても、その後バージョンアップをしていなければ合わせて最新バージョンの採用を行います。
例として3系はバージョンアップ時に採用したのは、
- OS : CentOS7
- DB : MySQL5.7
- Webサーバ : Apache2.4
- php7
と構築当時で一番最新のバージョンを採用しています。
以上簡単にではありますが、2系(2.4)から3系にバージョンアップするための主な作業を書きました。
もしバージョンアップをお考えの方や悩んでいる方は個別にご相談にのりますのでご連絡ください。
[2017/12/15 追記] データ移行ツールを公開しました。 amidaike.hatenablog.com
EC-CUBE3.0.11をXSERVERにインストールした時にhtmlを付けさせない方法
これまでhtmlをURLに記事を付けさせない方法を書いてきました。
EC-CUBE3をさくらのレンタルサーバにインストールした時にhtmlを付けさせない方法 - AmidaikeBlog
前回 (EC-CUBE3.0.11がリリース、サーバ選定について - AmidaikeBlog) の記事でも書いた通り、EC-CUBE3.0.11からはhtml
をURLにつけさせない方法が提供されましたので、今回はXSERVERに対してhtml
を外す方法を説明します。
※すでにDBが作成されている前提です。
レンタルサーバでは公開ディレクトリは固定されている事が多く変更する事は出来ないのですが、XSERVERの公開ディレクトリは、
/home/hoge/hoge.xsrv.jp/public_html
とpublic_html
が公開ディレクトリになっています。
※hoge
の部分は適宜ご自身の環境と読み替えてください。
過去に説明した記事であれば、.htaccess
を色々とごにょごにょする事で対応してきましたが、
今回は、
インストール時にURLからhtmlを無くす | EC-CUBE 開発ドキュメント
こちらを参考にhtml
を外す方法を説明していきます。
EC-CUBE3.0.11のアップロード
EC-CUBE3.0.11を
EC-CUBEダウンロード / ECサイト構築・リニューアルは「ECオープンプラットフォームEC-CUBE」
こちらからダウンロードし、
FTPで/home/hoge/hoge.xsrv.jp
直下にアップロードします。
EC-CUBE3.0.11の解凍
ここからはsshを使った説明となりますが、XSERVERでsshを使う時は以下のサイトを参考にしてください。
https://www.xserver.ne.jp/manual/man_server_ssh.php
SSHでログイン後、解凍されたディレクトリまで移動しEC-CUBEを解凍します。
cd hoge.xsrv.jp unzip eccube-3.0.11.zip
解凍したEC-CUBEをpublic_html配下にコピーします。
cd eccube-3.0.11 cp -pr . ../public_html/
ファイル配置場所の変更
公開ディレクトリまでカレントディレクトリを移動し、html
ディレクトリに存在する必要なファイルを公開ディレクトリ直下に移動させます。
cd cd hoge.xsrv.jp/public_html mv html/in* . mv html/.htaccess . mv html/robots.txt .
→今回はweb.configは不要なため移動させていません。
.htaccessの削除、.htaccess.sampleのリネーム
移動した.htaccess
を削除し、public_html直下に存在している.htaccess.sample
に置き換えます。
rm .htaccess mv .htaccess.sample .htaccess
index.php、install.phpの書き換え
- index.phpの書き換え
vi index.php
を実行し、27行目のコメントアウトされている箇所を変更し、26行目をコメントアウトます。
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える require __DIR__.'/../autoload.php'; //require __DIR__.'/autoload.php';
↓
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える //require __DIR__.'/../autoload.php'; require __DIR__.'/autoload.php';
- install.phpの書き換え
vi install.php
を実行し、31行目のコメントアウトされている箇所を変更し、30行目をコメントアウトします。
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える require __DIR__ . '/../autoload.php'; //require __DIR__ . '/autoload.php';
↓
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える //require __DIR__ . '/../autoload.php'; require __DIR__ . '/autoload.php';
autoload.phpの変更
- autoload.phpの書き換え
vi autoload.php
を実行し、36行目のコメントアウトされている箇所を変更し、35行目をコメントアウトします。
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える define("RELATIVE_PUBLIC_DIR_PATH", ''); //define("RELATIVE_PUBLIC_DIR_PATH", '/html');
↓
//[INFO]index.php,install.phpをEC-CUBEルート直下に移動させる場合は、コメントアウトしている行に置き換える //define("RELATIVE_PUBLIC_DIR_PATH", ''); define("RELATIVE_PUBLIC_DIR_PATH", '/html');
.htaccessの追加
公開ディレクトリをEC-CUBEルート直下にしたため、このままだと見せる必要のないディレクトリまで見えてしまいます。
そのため、以下の.htaccessファイルを各ディレクトリ直下に配置してくだsだい。
- .htaccessの内容
order allow,deny deny from all
この内容を
src
、tests
、vendor
ティレクトリ直下に配置します。(appディレクトリ直下には既に存在)
EC-CUBEのインストール
http://hoge.xsrv.jp とアクセスし、インストール作業が出来れば対応完了です。
以上がhtml
をURLから付けさせない方法となります。
他のレンタルサーバでもドキュメントルート部分(public_html
)を読み替えて行えば同じ方法でURLからhtml
を付けなくする事は可能ですので是非お試しください。
インストール後もhtmlディレクトリを削除する事は可能ですが、非常にめんどくさいためインストール前に設定するのがオススメです。
この方法で上手く動かないという方はコメントください。
EC-CUBE3.0.11がリリース、サーバ選定について
9月28日にEC-CUBE3.0.11がリリースされました。
EC-CUBE3.0.11で特徴的なものとしては、
- PHP7 対応
- パフォーマンス向上
- URLからhtmlを取り除くことが可能
が大きな特徴となります。
このブログで度々URLからhtml
を削除する方法を書いてきましたが、
3.0.11から公式にhtml
の削除ができる方法が提供されるようになりました。
削除する方法はこちらのURLを参考にしてください。
インストール時にURLからhtmlを無くす | EC-CUBE 開発ドキュメント
3.0.11のパフォーマンス結果についてより詳しく知りたい方は、こちらのURLも参考にしてください。
サーバ選定について
今回のバージョンよりパフォーマンス向上及びPHP7に対応したということで、
EC-CUBE3を今後利用したいという方のためにどのサーバを選べば良いのか書かせてもらいます。
既にEC-CUBE3を利用されている方はお気付きのように、3系は2系に比べて動作がもっさりしており表示速度も芳しくありませんでした。
EC-CUBE3.0.11ではあれこれ手を加えてパフォーマンス向上を行いましたが、 さらにストレスなく動作させる上で重要となるのがサーバとなります。
EC-CUBEを利用するには必ず
等と契約する必要がありますが、インフラに詳しい方がいる場合、
先ずはこの基準で検討してもらって問題ありません。
次に必要となるのがサーバスペックとなります。 EC-CUBE3のパフォーマンスを色々と調査した結果、一番効果が期待できるサーバ要件としては、
- SSDを使う
- PHP7を使う
- OPcacheを使う
- apcuを使う
これらが適用できる環境であればストレスなく動作させる事が可能です。
クラウドやVPSを利用できる方は是非この組み合わせでサーバを構築してください。SSDは必須です。
レンタルサーバをご利用される方についてはレンタルサーバ会社によってスペックが異なりますが、 今ならPHP7が使えるレンタルサーバを是非ご利用ください。
代表的なところとしては、以下のレンタルサーバがPHP7に対応しておりレンタルサーバ選びに迷っている方は参考にしてください。
個人的には昔からさくらサーバを長年愛用していますので、早くさくらサーバもphp7に対応して欲しいところではありますが。
今回DBのパフォーマンスについて言及しませんでしたが、機会があればまた書きたいと思います。
データベースの型を変更したEC-CUBE3.0.10のリポジトリの作成
本日4月25日にec-cube3.0.10がリリースされました。
EC-CUBE3.0.10の修正点などはリリースノートを参照してもらうこととして、 現在、EC-CUBE3ではデータベースの型が全てtext型で定義されています。
このままだとmysqlの場合、longtext型になったり、Oracleでは利用できなかったりと非常に不便なためデータベースの型を変更したEC-CUBEを下記リポジトリに用意してみました。
https://github.com/k-yamamura/ec-cube3-modify-type-database
こちらの内容はtextをstringに変更したり、notnull条件の見直しなどしています。
インストールまでは確認していますが動作確認まではしていませんのでご利用の際はご注意ください。