refirio.org

インストール後の設定

■メール送信 メールを送信する場合は以下を編集する。 以下は暗号化なしのSMTPを使う例。 .env 以下は465番ポートで送信する例。 試した際は「encryption=ssl」のオプション指定をしないと接続できなかった。 .env 以下はGmailのSMTPを使う例。 「encryption=ssl」に加えて「auth_mode=login」の指定も必要だった。 .env 「正しいSMTP情報のはずなのに、ECCubeに組み込んでもメールが送信されない」 という場合、このファイルの「トラブル」の「.env の値に「#」を使用できない」を参照する。 （「#」や「$」が含まれている場合の挙動が怪しい。） ■コマンドラインインターフェイス コマンドラインインターフェイス - < for EC-CUBE 4.0 Developers /> https://doc4.ec-cube.net/quickstart_cli 以下で実行できる。 XAMPP環境なら以下のようにして実行する。 ■認証キー 管理画面 → オーナーズストア → 認証キー設定 から、認証キーの新規発行と登録ができる。 すでに案件用に発行したキーがあるなら、その値を登録する。 オーナーズストアでメンバー登録＆ログインし、マイページで「登録サイト」にサイトを追加すると認証キーが発行される。 基本的にはプラグイン購入後、その認証キーをECCubeに登録すればいい。 以下はプラグイン購入後に案内されたページ。 4系のプラグインをオーナーズストアで購入後、どのようにインストールするのかわかりません。 - よくあるご質問 https://support.ec-cube.net/hc/ja/articles/360038927991 認証キーが共通なら、以前に購入した有料プラグインを再度インストールしたりできるみたい。 認証キーを登録しないと、プラグインの一覧など一部機能が使えない。 上記手順で発行した認証キーを登録すると、composer.json に のように値が記録される。 稼働後に認証キーを変更すると、プラグイン一覧で 「オーナーズストアへの接続に問題があるため、詳細な情報を取得できませんでした。」 と表示されることから考えても、 「最初に案件専用の認証キーを発行して、すべての環境でそのキーを使い回す」 とする必要がありそうな。 ■開発用モードに切り替え .env を以下のように変更する。 変更後、以下のコマンドでキャッシュを削除しておく。 ただしこの設定にすると、キャッシュされない代わりに動作が重くなるので注意。 なお、APP_ENV を使って公開サーバで「本番環境」「検収環境」のようなものは作らないほうがいいかもしれない。 以下のページで 「サイトをインターネット上で公開される際は必ずプロダクションモードを利用してください。」 とある。 環境設定 - < for EC-CUBE 4.0 Developers /> https://doc4.ec-cube.net/environmental_setting よって「本番環境なら」「検収環境なら」のような分岐を作りたければ、別途独自に .env 内で判定用の変数を定義する方がいいかもしれない。 具体的には、このファイル内にある「運用のためのメモ」の「環境による分岐」を参照。 なお、開発者用モードならテンプレートでデバッグ用の dump 命令を使えるようになる。 一例だが app\template\default\Product\detail.twig に以下を追加すると、データの内容が表示される。 テンプレートで dump を使うには上記のとおり .env の調整が必要だが、コントローラー無いなら以下のようにしていつでも使えるみたい。 ただし「デバッグモードで無ければ即座に表示され、デバッグモードならデバッグバーから表示できる」という違いがあるみたい。 EC-CUBE4 突然の死!! 本番モードでdump関数を使うと死ぬ | seiyaan teck blog https://seiyaan.com/2019/06/ec-cube4-dump-die/ デバッグモード - < for EC-CUBE 4 Developers /> https://doc4.ec-cube.net/debug_mode ■リポジトリへの登録 初回構築時なら、これくらいのタイミングでいったんリポジトリにコミット＆プッシュしておくといい。 ■店舗設定 管理画面 → 設定 → 店舗設定 → 基本設定 最低限、4つある各メールアドレスを設定しておく。 注文メールやお問い合わせメールは「問い合わせ受付メールアドレス」に対してBccで送信される。 ■マイグレーション SSHで接続して以下を実行する。 （実行が必要なマイグレーションがあれば実行される。） マイグレーションファイル内で 「trans('admin.product.analytic_csv.row.product_id')」 のような言語データを参照している場合、キャッシュによって正しくマイグレーションデータが保存されない可能性がある。 （上記以外にも、必要なデータを参照できない可能性がある。） この場合、以下のように更新すると対応できる。 むしろ「キャッシュクリア → マイグレーション実行」という手順が正しくて、 マイグレーション実行直後のキャッシュクリアは不要か。 もしくは、そもそも「trans」などの内容によってマイグレーション内容が変化する可能性がある方が好ましくないか。 プログラムの内容によって、「本番環境だとAと登録されているが、検収環境だとBと登録されている」が起こり得る。 それを調整するためにマイグレーションを作成したとしても、やはり環境によって登録内容が変わってしまう。 意図しないデータが登録されてしまった場合、一例だが以下のようなSQLで内容を調整する。 （「admin.product.analytic_csv.row.product_id」のような値が登録されている箇所を書き換える。） ■キャッシュクリア SSHで接続して以下を実行する。 管理画面からよりも確実みたい。 以下により、Composerのキャッシュをクリアできる。 現状必要になったことは無いが備忘録として。 composerについて初期学習まとめ - Qiita https://qiita.com/eidera/items/3e0b2b41253e1563be46 入力項目を追加したい場合、Entityのカスタマイズを行うことになる。 この作業を行った際は、トレイトを認識させるためのプロキシファイルを作成しなおす必要がある。 またブランチ切り替えなどでプロキシファイルがおかしな状態になることがある。 この場合、あらかじめ /app/proxy/entity/src/Eccube/Entity 内のファイルを削除したうえで、 以下を実行することで再生成ができる。 EntityのカスタマイズとTraitの具体例については、「カスタマイズ: 会員情報に項目を追加」も参照。 マイグレーションが絡む場合、このファイル内にある「インストール後の設定」の「マイグレーション」も参照。 またキャッシュについては、このファイル内にある「カスタマイズ」の「キャッシュの扱い」も参照。 まとめると、以下を実行することでキャッシュの完全クリアができる…はずだが、引き続き要検証。 （「cache:clear --no-warmup」は「eccube:generate:proxies」の後に行うべきかも。） 念のため、実行前にユーザ側＆管理側ともログアウトしておくといいかもしれない。 また、var/log/prod 内にログファイルが出力されているはずなので、その内容を確認することで原因を特定できることもある。 この後で、もう一度キャッシュをクリアしておくといいかもしれない。 それでも一部のページでエラーになることがあった。 経緯は 「一時的に本番環境の状態を確認するため、masterブランチに切り替えた。元に戻したが、トップページでのみシステムエラーが表示されるようになった」 というもの。 このとき、ログには以下のエラーが記録されていた。 「php bin/console list」で表示される doctrine の命令のうち、キャッシュをクリアしそうなものを色々実行し、 「app/proxy/entity/src/Eccube/Entity」内に差分ファイルが発生していたので元に戻し、 さらに通常のキャッシュクリアなどを何度か行う…ということをしていると解決した。 どれが直接の原因だったのかは不明。 それでも駄目なら、 「最近何らかのプラグインが追加されていて、それが有効になっている前提で作られている」 など他の要因が無いかも確認する。 例えば「ベリトランス4G」のプラグインを導入している場合、 プラグインの設定画面で「登録」ボタンを押すことで必要データが作成され、 これによって問題が解消することがある。