メモ > 技術 > CMS: ECCube > インストール後の設定
■インストール後の設定
■メール送信
メールを送信する場合は以下を編集する
以下は暗号化なしのSMTPを使う例
.env
25:- MAILER_URL=smtp://localhost:25
25:+ MAILER_URL=smtp://mail.example.com:587?username=example&password=XXXXXXXXXXXXXXXX
以下は465番ポートで送信する例
試した際は「encryption=ssl」のオプション指定をしないと接続できなかった
.env
25:- MAILER_URL=smtp://localhost:25
25:+ MAILER_URL=smtp://mail.example.com:465?username=example&password=XXXXXXXXXXXXXXXX&encryption=ssl
以下はGmailのSMTPを使う例
「encryption=ssl」に加えて「auth_mode=login」の指定も必要だった
.env
25:- MAILER_URL=smtp://localhost:25
25:+ MAILER_URL=smtp://smtp.gmail.com:465?username=example@gmail.com&password=XXXXXXXXXXXXXXXX&encryption=ssl&auth_mode=login
「正しいSMTP情報のはずなのに、ECCubeに組み込んでもメールが送信されない」
という場合、このファイルの「トラブル」の「.env の値に「#」を使用できない」を参照する
（「#」や「$」が含まれている場合の挙動が怪しい）
■コマンドラインインターフェイス
コマンドラインインターフェイス - < for EC-CUBE 4.0 Developers />
https://doc4.ec-cube.net/quickstart_cli
以下で実行できる
$ sudo su -s /bin/bash - apache
$ cd /var/www/main/html
$ php bin/console list
Symfony 3.4.26 (kernel: Eccube, env: prod, debug: false)
Usage:
command [options] [arguments]
XAMPP環境なら以下のようにして実行する
>C:\xampp\php\php.exe bin/console list
■認証キー
管理画面 → オーナーズストア → 認証キー設定
から、認証キーの新規発行と登録ができる
すでに案件用に発行したキーがあるなら、その値を登録する
オーナーズストアでメンバー登録＆ログインし、マイページで「登録サイト」にサイトを追加すると認証キーが発行される
基本的にはプラグイン購入後、その認証キーをECCubeに登録すればいい
以下はプラグイン購入後に案内されたページ
4系のプラグインをオーナーズストアで購入後、どのようにインストールするのかわかりません。 - よくあるご質問
https://support.ec-cube.net/hc/ja/articles/360038927991
認証キーが共通なら、以前に購入した有料プラグインを再度インストールしたりできるみたい
認証キーを登録しないと、プラグインの一覧など一部機能が使えない
上記手順で発行した認証キーを登録すると、composer.json に
"header": ["X-ECCUBE-KEY: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]
のように値が記録される
稼働後に認証キーを変更すると、プラグイン一覧で
「オーナーズストアへの接続に問題があるため、詳細な情報を取得できませんでした。」
と表示されることから考えても、
「最初に案件専用の認証キーを発行して、すべての環境でそのキーを使い回す」
とする必要がありそうな
■開発用モードに切り替え
.env を以下のように変更する
APP_ENV=prod
APP_DEBUG=0
↓
APP_ENV=dev
APP_DEBUG=1
変更後、以下のコマンドでキャッシュを削除しておく
$ php bin/console cache:clear --no-warmup
ただしこの設定にすると、キャッシュされない代わりに動作が重くなるので注意
なお、APP_ENV を使って公開サーバで「本番環境」「検収環境」のようなものは作らないほうがいいかもしれない
以下のページで
「サイトをインターネット上で公開される際は必ずプロダクションモードを利用してください。」
とある
環境設定 - < for EC-CUBE 4.0 Developers />
https://doc4.ec-cube.net/environmental_setting
よって「本番環境なら」「検収環境なら」のような分岐を作りたければ、別途独自に .env 内で判定用の変数を定義する方がいいかもしれない
具体的には、このファイル内にある「運用のためのメモ」の「環境による分岐」を参照
なお、開発者用モードならデバッグ用の dump 命令を使えるようになる
一例だが app\template\default\Product\detail.twig に以下を追加すると、データの内容が表示される
{{ dump(Product) }}
EC-CUBE4 突然の死!! 本番モードでdump関数を使うと死ぬ | seiyaan teck blog
https://seiyaan.com/2019/06/ec-cube4-dump-die/
■リポジトリへの登録
初回構築時なら、これくらいのタイミングでいったんリポジトリにコミット＆プッシュしておくといい
■店舗設定
管理画面 → 設定 → 店舗設定 → 基本設定
最低限、4つある各メールアドレスを設定しておく
注文メールやお問い合わせメールは「問い合わせ受付メールアドレス」に対してBccで送信される
■マイグレーション
SSHで接続して以下を実行する
（実行が必要なマイグレーションがあれば実行される）
$ sudo su -s /bin/bash - apache
$ cd /var/www/main/html
$ php bin/console doctrine:migrations:migrate
マイグレーションファイル内で
「trans('admin.product.analytic_csv.row.product_id')」
のような言語データを参照している場合、キャッシュによって正しくマイグレーションデータが保存されない可能性がある
（上記以外にも、必要なデータを参照できない可能性がある）
この場合、以下のように更新すると対応できる
$ sudo su -s /bin/bash - apache
$ cd /var/www/main/html
$ git pull origin main
$ php bin/console cache:clear --no-warmup … この時点でキャッシュをクリアしておく
$ php bin/console doctrine:migrations:migrate
$ php bin/console cache:clear --no-warmup
むしろ「キャッシュクリア → マイグレーション実行」という手順が正しくて、
マイグレーション実行直後のキャッシュクリアは不要か
もしくは、そもそも「trans」などの内容によってマイグレーション内容が変化する可能性がある方が好ましくないか
プログラムの内容によって、「本番環境だとAと登録されているが、検収環境だとBと登録されている」が起こり得る
それを調整するためにマイグレーションを作成したとしても、やはり環境によって登録内容が変わってしまう
意図しないデータが登録されてしまった場合、一例だが以下のようなSQLで内容を調整する
（「admin.product.analytic_csv.row.product_id」のような値が登録されている箇所を書き換える）
SELECT * FROM mtb_csv_type;
SELECT * FROM dtb_csv WHERE id > 230;
UPDATE mtb_csv_type SET name = '商品集計CSV' WHERE id = '8';
UPDATE dtb_csv SET disp_name = '商品ID' WHERE id = '236';
UPDATE dtb_csv SET disp_name = '商品名' WHERE id = '237';
UPDATE dtb_csv SET disp_name = '購入件数' WHERE id = '238';
■キャッシュクリア
SSHで接続して以下を実行する
管理画面からよりも確実みたい
$ sudo su -s /bin/bash - apache
$ cd /var/www/main/html
$ php bin/console cache:clear --no-warmup
以下により、Composerのキャッシュをクリアできる
現状必要になったことは無いが備忘録として
$ composer clear-cache
$ composer dump-autoload
composerについて初期学習まとめ - Qiita
https://qiita.com/eidera/items/3e0b2b41253e1563be46
入力項目を追加したい場合、Entityのカスタマイズを行うことになる
この作業を行った際は、トレイトを認識させるためのプロキシファイルを作成しなおす必要がある
$ php bin/console eccube:generate:proxies
またブランチ切り替えなどでプロキシファイルがおかしな状態になることがある
この場合、あらかじめ /app/proxy/entity/src/Eccube/Entity 内のファイルを削除したうえで、
以下を実行することで再生成ができる
$ php bin/console eccube:generate:proxies
EntityのカスタマイズとTraitの具体例については、「カスタマイズ: 会員情報に項目を追加」も参照
マイグレーションが絡む場合、このファイル内にある「インストール後の設定」の「マイグレーション」も参照
またキャッシュについては、このファイル内にある「カスタマイズ」の「キャッシュの扱い」も参照
まとめると、以下を実行することでキャッシュの完全クリアができる…はずだが、引き続き要検証
（「cache:clear --no-warmup」は「eccube:generate:proxies」の後に行うべきかも）
念のため、実行前にユーザ側＆管理側ともログアウトしておくといいかもしれない
また、var/log/prod 内にログファイルが出力されているはずなので、その内容を確認することで原因を特定できることもある
$ sudo su -s /bin/bash - apache
$ cd /var/www/main/html
$ rm -rf app/proxy/entity/src
$ composer clear-cache
$ composer dump-autoload
$ php bin/console cache:clear --no-warmup
$ php bin/console eccube:generate:proxies
この後で、もう一度キャッシュをクリアしておくといいかもしれない
$ php bin/console cache:clear --no-warmup
それでも一部のページでエラーになることがあった
経緯は
「一時的に本番環境の状態を確認するため、masterブランチに切り替えた。元に戻したが、トップページでのみシステムエラーが表示されるようになった」
というもの
このとき、ログには以下のエラーが記録されていた
[2022-08-30 11:18:17] front.ERROR [vhdde1qc9n71d7p8n7vsakqiou] [55901fc] [anon.] [Eccube\Log\Logger:log:66] - システムエラーが発生しました。
["Attempted to call an undefined method named \"getCacheRegion\" of class \"Doctrine\\ORM\\Persisters\\Entity\\BasicEntityPersister\".","/var/www/html/vendor/doctrine/orm/lib/Doctrine/ORM/Cache/DefaultQueryCache.php",348
「php bin/console list」で表示される doctrine の命令のうち、キャッシュをクリアしそうなものを色々実行し、
「app/proxy/entity/src/Eccube/Entity」内に差分ファイルが発生していたので元に戻し、
さらに通常のキャッシュクリアなどを何度か行う…ということをしていると解決した
どれが直接の原因だったのかは不明
それでも駄目なら、
「最近何らかのプラグインが追加されていて、それが有効になっている前提で作られている」
など他の要因が無いかも確認する
例えば「ベリトランス4G」のプラグインを導入している場合、
プラグインの設定画面で「登録」ボタンを押すことで必要データが作成され、
これによって問題が解消することがある