Memo

メモ > 技術 > CMS: ECCube > 運用のためのメモ

■運用のためのメモ
■基本設定 「設定 → 店舗設定 → 基本設定」 店名は、titleタグの内容などに使われる 会社名、住所、電話番号、店舗営業時間、取り扱い商品説明文、店舗からのメッセージは、 ユーザ側のフッタにある「当サイトについて」のリンク先ページに表示される ■商品規格 商品ごとに「この色でこの大きさなら○円で在庫は○円」を登録できる ただし規格は1商品に対して2つまでしか紐付けられないので注意 以下のプラグインを使えばある程度柔軟に対応できるかもしれないが、 注文内容の商品に対するオプション内容を、管理画面から変更できないので注意 (開発元に確認済み。いったん商品を削除しての再追加はできる) 4.0系|商品オプションプラグイン for EC-CUBE4|株式会社ブラテック https://www.ec-cube.net/products/detail.php?product_id=1787 また、規格は例えば 1. 商品登録時に商品コードを入力する 2. 1の商品に商品規格を登録し、商品コードを入力する として商品を登録すると、1の商品コードはECCube上で使われなくなる(規格の商品コードが使われるため)が、データベース上には残ったままとなる ただし2で登録した規格を初期化(全削除)すると再度1の商品コードが使われるようになるので、これは「初期化のことを想定したECCubeの仕様」だと思われる これは「初期化のことを想定したECCubeの仕様」だと思われるが、 1. 商品登録時に商品コードを入力する 2. 1の商品に商品規格を登録し、商品コードを入力する 3. 商品規格の商品コードを変更する 4. しばらく運用したあと、商品規格を削除する(規格なしで運用する) という手順で、古い商品コード(意図しない値)が現れる可能性はある。 気持ち悪ければ、データベースの値を直接編集することはできる 恐らく問題無いと思われるが、独自カスタマイズした部分に影響しないかも含めて検証が必要 以下は実際に商品情報を登録して検証したときのメモ 商品を登録すると、以下のようになった
> SELECT id, product_id, price01, price02, product_code, stock, visible FROM dtb_product_class WHERE product_id = 363; +------+------------+---------+---------+--------------+-------+---------+ | id | product_id | price01 | price02 | product_code | stock | visible | +------+------------+---------+---------+--------------+-------+---------+ | 1089 | 363 | NULL | 1000.00 | TEST | 10 | 1 | +------+------------+---------+---------+--------------+-------+---------+
商品に規格を登録すると、以下のようになった
> SELECT id, product_id, price01, price02, product_code, stock, visible FROM dtb_product_class WHERE product_id = 363; +------+------------+---------+---------+--------------+-------+---------+ | id | product_id | price01 | price02 | product_code | stock | visible | +------+------------+---------+---------+--------------+-------+---------+ | 1089 | 363 | NULL | 1000.00 | TEST | 10 | 0 | | 1090 | 363 | NULL | 2000.00 | TEST-S | 20 | 1 | | 1091 | 363 | NULL | 3000.00 | TEST-M | 30 | 1 | | 1092 | 363 | NULL | 4000.00 | TEST-L | 40 | 1 | +------+------------+---------+---------+--------------+-------+---------+
商品規格を初期化すると、以下のようになった
> SELECT id, product_id, price01, price02, product_code, stock, visible FROM dtb_product_class WHERE product_id = 363; +------+------------+---------+---------+--------------+-------+---------+ | id | product_id | price01 | price02 | product_code | stock | visible | +------+------------+---------+---------+--------------+-------+---------+ | 1089 | 363 | NULL | 1000.00 | TEST | 10 | 1 | | 1090 | 363 | NULL | 2000.00 | TEST-S | 20 | 0 | | 1091 | 363 | NULL | 3000.00 | TEST-M | 30 | 0 | | 1092 | 363 | NULL | 4000.00 | TEST-L | 40 | 0 | +------+------------+---------+---------+--------------+-------+---------+
■ページ管理 「コンテンツ管理 → ページ管理」 各ページの表示内容を管理できる 「ページ名」を変更すれば、そのページのtitleタグの内容が変わる ただしここからページ名などを変更すると、「コード」の内容を変更していなくても差分が発生する(ファイルの最終行の改行が削除されてしまう) ECCubeの仕様かもしれないが、ファイルをGit管理していると差分が発生するので注意(差分の取り消しを行うなどの作業が必要) また、例えば「当サイトについて」や「プライバシーポリシー」ページの見出し文字は上記ではなく以下に記述されている src\Eccube\Resource\locale\messages.ja.yaml 上記ファイルの内容をもとに、以下に新たなタイトルを定義することで、見出し文字を変更できる app\Customize\Resource\locale\messages.ja.yaml 入門:EC-CUBE 4のデフォルトページを編集する - 眠るシーラカンスと水底のプログラマー http://coelacanth.jp.net/eccube4_change_page_html/ ■CSS管理 「コンテンツ管理 → CSS管理」 コードを登録すると以下のファイルに反映され、ユーザ側で読み込まれる user_data\assets\css\customize.css ■JavaScript管理 「コンテンツ管理 → JavaScript管理」 コードを登録すると以下のファイルに反映され、ユーザ側で読み込まれる user_data\assets\js\customize.js ■送料設定 標準の挙動は ・配送方法ごとに、「都道府県ごとの送料」を設定できる(◯◯業者なら大阪への配送は800円、東京への配送は1000円、など) ・特定商品に対して、↑に上乗せの送料を設定できる(◯◯商品は送料1,000円上乗せ、など) ・購入金額が一定以上なら、送料無料とできる ・購入個数が一定以上なら、送料無料とできる となっている 以下、標準の挙動を調査したときのメモ 「設定 → 店舗設定 → 配送方法設定 → サンプル業者」では、配送料は全国一律で「1000円」となっている 「設定 → 店舗設定 → 基本設定 → 送料設定」で「商品ごとの送料設定」を有効にしてみる そうすると、商品登録画面に「商品送料」の項目が現れた 規格がある商品の場合、商品規格登録画面に「商品送料」の項目が現れた 「商品送料」が「500円」の商品を登録してみる 「商品送料」が「500円」「1000円」「1500円」の規格商品を登録してみる 「商品送料」が無い商品を購入してみる 全国一律の「1000円」が送料として登録された 送料は「商品情報」から編集できる 「商品送料」が無い規格商品を購入してみる 全国一律の「1000円」が送料として登録された 送料は「商品情報」から編集できる 「商品送料」がある(500円)商品を購入してみる 全国一律の「1000円」に上記が追加され、「1500円」が送料として登録された 送料は「商品情報」から編集できる 「商品送料」がある(500円)規格商品を購入してみる 全国一律の「1000円」に上記が追加され、「1500円」が送料として登録された 送料は「商品情報」から編集できる 上記のことから、「商品ごとの送料設定」は上乗せ料金の設定となっている なお管理画面から受注登録する場合「商品ごとの送料設定」は自動に受注明細に登録されないみたい 具体的には注文登録の際に「その他の明細を追加」ボタンから送料を追加し、金額を手入力する必要があるみたい 運用上問題無いかは検討してから導入したい また「商品ごとの送料設定」を有効にして商品ごとの送料を登録した場合でも、 受注情報として記録されるのは「合計の送料」のみとなっている 「その時点での商品ごとの送料」を求めるのは、データベースの構造上不可能のようなので注意 ECCubeでの送料計算については以下も参照 EC-CUBE4系で送料がどのように計算されるのか解説します | (株)カジヤ https://cajiya.co.jp/column/6827 ■メール設定 「設定 → 店舗設定 → メール設定」 以下のメール設定が用意されている ・注文受付メール ・会員仮登録メール ・会員本登録メール ・会員退会メール ・問合受付メール ・パスワードリセット ・パスワードリマインダー ・出荷通知メール 「会員退会メール」「パスワードリセット」「パスワードリマインダー」はテキストメールのみ、 それ以外はHTMLメールとテキストメールの内容を設定する 「パスワードリマインダー」は現行バージョンでは使われていない 旧バージョンのなごりらしい EC-CUBE 開発コミュニティ - フォーラム https://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=24938&forum=11 例えば「注文受け付けメール」の「テキスト」と「HTML」を編集すると、以下のファイルが編集される 件名はデータベースで管理されているが、本文はファイルとして管理されている app\template\default\Mail\order.html.twig app\template\default\Mail\order.twig 「パスワードリマインダー」メールは送信されないらしい ■CSV出力項目設定 「設定 → 店舗設定 → CSV出力項目設定」 ただし、書き出したCSVでそのまま一括登録はできないようだが、一括登録用に項目を合わせば対応はできるみたい また、ダウンロードできるCSVファイルはShift-JISで、一括登録もShift-JISで行う必要があるみたい UTF-8など他の文字コードにすると、正しく登録できないようなので注意(規格品が重複して登録されるような挙動になった) 項目の調整は、以下のプラグインを導入するなどして対応できるみたい 4.0系|商品CSV登録拡張プラグイン for EC-CUBE4|株式会社ブラテック https://www.ec-cube.net/products/detail.php?product_id=1802 ■権限設定 「設定 → システム設定 → マスターデータ管理 → mtb_authority」 初期状態で「システム管理者」が登録されているが、ここで「店舗オーナー」「販売管理部」などのような権限を追加できる 「設定 → システム設定 → 権限管理」 例えば「拒否URL」に「/setting/system/authority」と登録すると、権限管理ページにのみアクセスできなくなる 例えば「拒否URL」に「/setting」と登録すると、「/setting」以下のページにアクセスできなくなる 左メニューからも項目が非表示になる 「/setting」を登録した場合、「設定」の親メニューごと非表示になる これを踏まえて、一例だが以下のように設定する 例えば「拒否URL」に以下を登録すると、店舗オーナー用にシステムページ全般にアクセスできないアカウントを作れる /content/css /content/js /content/block /content/cache /content/maintenance /setting/system /store 例えば「拒否URL」に以下を登録すると、販売管理部用に「商品管理」「受注管理」「会員管理」のみにアクセスできるアカウントを作れる /content /setting /store 例えば「拒否URL」に以下を登録すると、商品登録用に「商品一覧」「商品登録」「規格管理」のみにアクセスできるアカウントを作れる /product/category /product/tag /product/product_csv_upload /product/category_csv_upload /order /customer /content /setting /store ■管理画面URLを変更 「設定 → システム設定 → セキュリティ管理」 「管理画面URL」を変更して「登録」をクリック 強制的にログイン画面へ遷移し、「管理画面のURLを変更しました。再度ログインを行ってください。」と表示された キャッシュが再作成されるのか重い この内容はデータベースではなく .env に記録される 具体的には以下のように記録されている
ECCUBE_ADMIN_ROUTE=system
※.env を .htaccess に移行すると、この設定内容は管理画面から変更できなくなる ■管理画面のIP制限 「設定 → システム設定 → セキュリティ管理」 「IP制限」に開業区切りでIPアドレスを入力して「登録」をクリック 例えば以下を入力した場合、192.168.33.1 と 192.168.33.2 からのアクセスのみが許可される
192.168.33.1 192.168.33.2
この内容はデータベースではなく .env に記録される 例えば上記設定を行った場合、.env が以下のように変更される
ECCUBE_ADMIN_ALLOW_HOSTS=[] ↓ ECCUBE_ADMIN_ALLOW_HOSTS='["192.168.33.1","192.168.33.2"]'
ロードバランサーのある環境なら、この機能は使いづらいかもしれない もしくは管理画面にはサーバを直接指定してアクセスするか ※.env を .htaccess に移行すると、この設定内容は管理画面から変更できなくなる ■環境による分岐 「検収環境では専用の表示を行いたい」「本番環境でのみアクセス解析タグを挿入したい」のような分岐を行う方法 まずは準備として eccube.yaml 内で html\app\config\eccube\packages\eccube.yaml
env(ECCUBE_PACKAGE_API_URL): 'https://package-api.ec-cube.net' env(ECCUBE_OWNERS_STORE_URL): 'https://www.ec-cube.net' env(ECCUBE_MAINTENANCE_FILE_PATH): '%kernel.project_dir%/.maintenance' env(ECCUBE_ENV): 'local' … 環境判定用に追加 〜中略〜 eccube_result_cache_lifetime: 3600 # doctrineのresult cacheのlifetime. eccube_result_cache_lifetime_short: 10 # doctrineのresult cacheのlifetime. 商品一覧画面など長期間キャッシュできない箇所で使用する. eccube_content_maintenance_file_path: '%env(ECCUBE_MAINTENANCE_FILE_PATH)%' eccube_env: '%env(ECCUBE_ENV)%' # 環境判定用 … 環境判定用に追加
このように定義しておく これで例えば本番環境の .env に
ECCUBE_ENV=production
と追加することにより、テンプレート内で以下のような分岐を行うことができる
{% if eccube_config.eccube_env == 'production' %} 〜本番環境〜 {% elseif eccube_config.eccube_env == 'staging' %} 〜検収環境〜 {% endif %}
つまり 「ECCUBE_ENV=production」が定義されていれば本番環境、 「ECCUBE_ENV=staging」が定義されていれば検収環境、 何も定義されていなければローカル開発環境、 という分岐ができる 上記のとおり app/config/eccube/packages/eccube.yaml で定義できるが、 app/config/eccube/packages/customize.yaml で定義することにより、本体更新の際に上書きしてしまうリスクを無くすことができるみたい(未検証) EC-CUBE4 独自の定数を定義 - PukiWiki https://yassu.jp/pukiwiki/index.php?EC-CUBE4%20%C6%C8%BC%AB%A4%CE%C4%EA%BF%F4%A4%F2%C4%EA%B5%C1 ■商品の公開状態 各商品には、公開状態として「公開」「非公開」「廃止」があり、「削除」も含めると合計4つの状態がある 外部キー制約から商品を削除できないことが多いので、管理画面上で閲覧不要な場合は「廃止」にするといい 商品管理での商品の取扱操作のラベルの見直し - Issue #4375 - EC-CUBE/ec-cube https://github.com/EC-CUBE/ec-cube/issues/4375 上記ページより、以下のようなマトリクスになっているとのこと 商品一覧・詳細 マイページ購入履歴 商品管理 受注管理 備考 公開 ○ ○ ○ ○ 非公開 × ○ ○ ○ 廃止 × ○ ×(※) ○ ※商品管理では検索条件に指定することで閲覧可 削除 × × × × DBから物理削除 上記のように、廃止の商品でも管理画面の受注登録からは選択できてしまう 選択できないと、商品の編集時などに問題があるためだと思われる ただし運用時の選択ミスを防ぐため、 ・運用ルールとして、廃止にした商品名の先頭には必ず「【廃止】」と付ける ・プログラムを調整し、廃止にした商品は商品名の先頭に「【廃止】」を自動付加して表示する のいずれかの対応を行うと良さそう ■商品の販売種別 商品登録時に「販売種別」を登録できる これは「通常販売」「ダウンロード販売」など販売方法を分けるための機能 種別が変わるとカート内で区別され、種別ごとに「レジに進む」ボタンが表示される(同時購入できなくなる) また購入が完了すると「購入を続ける」ボタンが表示され、引き続きカートに残っている商品の購入が促される 販売種別はマスターデータとして管理されているので、 「設定 → システム設定 → マスターデータ管理 → mtb_sale_type」 から値を追加できる 配送方法が設定されていない販売種別をカートに入れようとすると、以下のメッセージが表示される 「◯◯◯」はまだ配送の準備ができておりません。恐れ入りますがお問い合わせページよりお問い合わせください。 ■商品の在庫数 内部的には、在庫数は2ヶ所で管理されている EC-CUBE 開発コミュニティ - フォーラム https://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=17797&forum=2 上記ページにて、以下の説明がされている
1. 商品詳細にて、在庫有無を表示する→ dtb_product_class.stock 2. 商品購入時、在庫有無をチェックする → dtb_product_stock.stock となっています。 商品購入時は、排他制御が必要になる(同時に購入されないように厳密に制御する)ため、dtb_product_stock.stock を使用しますが、 この情報を商品詳細でも参照すると、とても処理が遅くなってしまうので、 商品詳細では在庫数の目安として dtb_product_class.stock を使用するようになっています。
在庫に関する処理は、以下の理由で調整が大変なので注意 ・在庫数はWeb注文・社内受注・受注編集・注文取消し・注文取消し解除など、様々なシーンで増減する ・在庫数を増減する際、テーブルロックによる排他制御の考え方が必要 ・ECCubeではPurchaseFlowという仕組みで在庫数の増減を実現しているが、ECCubeのとてもコアな部分でソースコードが難解 以下にも調査内容がある C:\Users\Yamano\Dropbox\技術\ECCube\調査.txt ■お届け先の登録件数上限について お届け先を20件登録すると、お届け先一覧に 「お届け先登録の上限の20件に達しています。お届け先を入力したい場合は、削除か変更を行ってください。」 と表示される この件数は app\config\eccube\packages\eccube.yaml にある
eccube_deliv_addr_max: 20
この部分を編集すれば増減できる ただしあまり多くすることは想定されていないような作りには見えるので注意 (どれだけお届け先を増やしても、改ページが表示されたりはしないなど) EC-CUBE 開発コミュニティ - フォーラム https://xoops.ec-cube.net/modules/newbb/viewtopic.php?viewmode=flat&order=DESC&topic_id=2498... なお、上記設定の下にある
eccube_deliv_date_end_max: 21
これはお届け日のプルダウンの選択肢の数を制御しているもの EC-CUBE 開発コミュニティ - フォーラム https://xoops.ec-cube.net/modules/newbb/viewtopic.php?viewmode=flat&order=DESC&topic_id=2450... ■お届け先の追加と、対応状況の「発送済み」と出荷情報の「出荷済みにする」について 以下の注文があるとする 対応状況: 入金済み 支払方法: クレジットカード決済 「対応状況」を「発送済み」にすると「出荷日」が記録された この際「商品出荷のお知らせ」というメールは送信されなかった(送信確認も無い) 「出荷情報の追加」から「出荷メール送信」をクリックすると「商品出荷のお知らせ」というメールが送信された このメールは何度でも送信できる 「対応状況」や「出荷情報」には影響しない 「出荷情報の追加」から「出荷済みにする」をクリックすると「出荷日」が記録された 必要なら、同時に「商品出荷のお知らせ」というメールを送信することもできる(送信確認される) 対応状況は「発送済み」になった 「出荷情報の追加」は何のためにあるのか、の考察 複数の商品を注文する場合、商品ごとにお届け先を設定できる また注文済みの商品に対して、管理画面からさらに商品をお届け先を追加できる これらは別々に出荷情報を管理できるが、対応状況や支払情報は「受注」単位で共通となる つまり、「同じ注文で複数のお届け先がある」という場合に別々に管理できるようにしたのが「出荷情報」だと思われる ■ログ表示 「設定 → システム設定 → ログ表示」 複数台構成でログを同期しないなら、そのときアクセスしているサーバのログだけが表示される スティッキーセッションを設定しておけば、再読み込みごとに変わることはないが、ロードバランサーの設定を確認しておく ■マスターデータ管理 「設定 → システム設定 → マスターデータ管理」 実際に権限を追加してみる mtb_authorityを選択して以下を登録して「保存」をクリック ID: 2 Name: テスト これで「メンバー管理」や「権限管理」に反映される ■テンプレートをダウンロード 「オーナーズストア → テンプレート → テンプレート一覧」 「デフォルト」のダウンロードボタンを押すと、以下の内容をダウンロードできる app/template/default ■ログイン時間を伸ばす EC-CUBE4カスタマイズ - 4系でログイン・カートのセッション持続時間を伸ばす方法 https://umebius.com/eccube/eccube4-session-lifetime-logout/ app\config\eccube\packages\eccube.yaml でセッション持続時間が以下のように定義されている デフォルトの「1440」は「60 * 24」の計算結果。つまり24分
env(ECCUBE_COOKIE_LIFETIME): 0 env(ECCUBE_GC_MAXLIFETIME): 1440
例えば3時間にする場合、.env の最後に以下を追加する 「10800」は「60 * 60 * 3」の計算結果。つまり3時間
ECCUBE_COOKIE_LIFETIME=10800 ECCUBE_GC_MAXLIFETIME=10800
なお、ALB(AWSのロードバランサー)でスティッキーセッションを使用している場合、 上記設定を行っても24分でログアウトされた(ロードバランサー側の時点でセッションが切れるためだと思われる) この場合、ALB側の設定でもセッションの持続時間を伸ばしておく(対象のターゲットグループで「維持設定の期間」を変更する) ■セッションをデータベースに保存する ※未検証 EC-CUBE4カスタマイズ - セッションをファイルではなくデータベースに保存する方法 PdoSessionHandler https://umebius.com/eccube/eccube4-db-session/ ■セキュリティチェック 以下のプラグインを導入して実行するといい 4.0系|EC-CUBEセキュリティチェックプラグイン(4.0系)|株式会社イーシーキューブ https://www.ec-cube.net/products/detail.php?product_id=2040 ただし本体やプラグインを改造している場合、改造内容が先祖返りする可能性があるみたい また、データベース定義を変更しているとチェック途中で落ちることがあるみたい 実行する場合、これらには気を付ける ■受注データの一覧 一例だが、以下のようにして受注データを一覧できる
SELECT id, order_no, name01, name02, kana01, kana02, email, phone_number, postal_code, addr01, addr02, payment_total, payment_method FROM dtb_order WHERE pref_id = 13 # 一例として東京都の受注データを指定 ORDER BY id DESC ;
■受注データのお問い合わせ番号 受注一覧や受注詳細にある「お問い合わせ番号」を入力すると、送信されるメールに記載される 自動で何かと連動するのではなく、単に番号を表示するだけみたい? ■受注データの注文番号 注文番号は「注文時に自動で採番される管理番号」と説明されている ただ、受注データは「注文完了時に登録される」のではなく 1. カート 2. お客様情報入力 3. ご注文手続き(支払い方法の選択がある画面) 4. ご注文内容確認画面 5. 完了 画面遷移のうち「2→3」のタイミングで作成されるが、4のタイミングなどで離脱すると、このデータは残り続ける またこのとき、対応状況は「購入処理中」となっている よって受注一覧のみを見ていると、注文番号に歯抜けがあるように見える 歯抜けデータは、受注一覧で「購入処理中」の対応状況で絞り込むと表示される 同様に「決済処理中」という対応状況もあり、カード決済画面まで進んで止めるとここに表示されると思われる(要検証 / カード決済を導入した場合のみ?) ■受注データのステータス order_status_id の値は、mtb_order_status テーブルに格納されている ECCubeインストール直後は、以下が登録されている 1 ... 新規受付 3 ... 注文取消し 4 ... 対応中 5 ... 発送済み 6 ... 入金済み 7 ... 決済処理中 8 ... 購入処理中 9 ... 返品 プログラムでの扱いについては、このファイル内の「対応状況の遷移を変更」を参照 ■受注データの取消し 以下はID「12345」の注文を取消しにする場合の例 UPDATE dtb_order SET order_status_id = 3 WHERE id = 12345; ■受注データの削除 外部キー制約のため、単純に削除したりはできない 以下は「WHERE id = 12345」の注文を削除する場合のSQL例(実際の仕事案件で改造されたECCubeに対し作業) 未検証なので注意
DELETE FROM plg_vt4g_order_payment WHERE order_id IN (SELECT id FROM dtb_order WHERE id = 12345); DELETE FROM plg_vt4g_order_log WHERE order_id IN (SELECT id FROM dtb_order WHERE id = 12345); DELETE FROM dtb_mail_history WHERE order_id IN (SELECT id FROM dtb_order WHERE id = 12345); DELETE FROM dtb_url_token WHERE order_id IN (SELECT id FROM dtb_order WHERE id = 12345); DELETE FROM dtb_order_item_cst WHERE order_item_id IN (SELECT id FROM dtb_order_item WHERE order_id IN (SELECT id FROM dtb_order WHERE id = 12345)); DELETE FROM dtb_order_item WHERE order_id IN (SELECT id FROM dtb_order WHERE id = 12345); DELETE FROM dtb_shipping WHERE order_id IN (SELECT id FROM dtb_order WHERE id = 12345); DELETE FROM dtb_order_cst WHERE order_id IN (SELECT id FROM dtb_order WHERE id = 12345); DELETE FROM dtb_order WHERE id = 12345;
■受注データの初期化 外部キー制約のため、単純に削除したりはできない EC-CUBE4データ移行:受注データ(MySQL) | ITOBEN STYLE Blog https://itoben.com/blog/4279.html 上のページによると、以下の手順で削除できるみたい ただしカスタマイズでテーブルが増えている場合などは対応できなかった
ALTER TABLE dtb_shipping DROP FOREIGN KEY `FK_2EBD22CE8D9F6D38`; ALTER TABLE dtb_mail_history DROP FOREIGN KEY `FK_4870AB118D9F6D38`; ALTER TABLE dtb_order_item DROP FOREIGN KEY `FK_A0C8C3ED8D9F6D38`; DELETE FROM dtb_shipping WHERE order_id NOT IN( SELECT id FROM dtb_order ); DELETE FROM dtb_mail_history WHERE order_id NOT IN( SELECT id FROM dtb_order ); DELETE FROM dtb_order_item WHERE order_id NOT IN( SELECT id FROM dtb_order ); ALTER TABLE dtb_shipping ADD CONSTRAINT FK_2EBD22CE8D9F6D38 FOREIGN KEY (order_id) REFERENCES dtb_order (id) ON DELETE RESTRICT ON UPDATE RESTRICT; ALTER TABLE dtb_mail_history ADD CONSTRAINT FK_4870AB118D9F6D38 FOREIGN KEY (order_id) REFERENCES dtb_order (id) ON DELETE RESTRICT ON UPDATE RESTRICT; ALTER TABLE dtb_order_item ADD CONSTRAINT FK_A0C8C3ED8D9F6D38 FOREIGN KEY (order_id) REFERENCES dtb_order (id) ON DELETE RESTRICT ON UPDATE RESTRICT; ALTER TABLE dtb_order_item DROP FOREIGN KEY `FK_A0C8C3ED4887F3F8`; DELETE FROM dtb_order_item WHERE shipping_id NOT IN( SELECT id FROM dtb_shipping ); ALTER TABLE dtb_order_item ADD CONSTRAINT FK_A0C8C3ED4887F3F8 FOREIGN KEY (shipping_id) REFERENCES dtb_shipping (id) ON DELETE RESTRICT ON UPDATE RESTRICT; ALTER TABLE dtb_order_item DROP FOREIGN KEY `FK_A0C8C3ED4887F3F8`; DELETE FROM dtb_order_item WHERE shipping_id NOT IN( SELECT id FROM dtb_shipping ); ALTER TABLE dtb_order_item ADD CONSTRAINT FK_A0C8C3ED4887F3F8 FOREIGN KEY (shipping_id) REFERENCES dtb_shipping (id) ON DELETE RESTRICT ON UPDATE RESTRICT;
以下は参考までに、実際の案件で受注データを削除したときのコード FOREIGN_KEY_CHECKS を操作することにより、データの削除を可能としている 先頭に「plg_」が付いたテーブルは、プラグインが独自に作成したテーブル 末尾に「_cst」が付いたテーブルは、カスタマイズのため独自に作成したテーブル なので、必要に応じて省く必要がある
TRUNCATE TABLE dtb_mail_history; TRUNCATE TABLE dtb_order_cst; TRUNCATE TABLE dtb_order_item_cst; TRUNCATE TABLE dtb_order_pdf; TRUNCATE TABLE dtb_url_token; TRUNCATE TABLE plg_productset_order_item; TRUNCATE TABLE plg_vt4g_order_log; TRUNCATE TABLE plg_vt4g_order_payment; TRUNCATE TABLE plg_productoption_dtb_order_item_option_category; SET FOREIGN_KEY_CHECKS = 0; TRUNCATE TABLE plg_productoption_dtb_order_item_option; TRUNCATE TABLE dtb_order_item; TRUNCATE TABLE dtb_shipping; TRUNCATE TABLE dtb_order; SET FOREIGN_KEY_CHECKS = 1;
データベースをバックアップ&リストアする際に、リストア時に外部キーエラーになったとき、 SQLの最初と最後に以下のSQLを追加すると大丈夫だった 場合によるかもしれないので、あくまでも参考程度に
SET FOREIGN_KEY_CHECKS = 0; SET FOREIGN_KEY_CHECKS = 1;
なお、データベースの内容は即座に反映されないことがあるので注意 コンソールからキャッシュの削除をすると反映されることがある ■データベースの日時 データベース内の日時は、実際の日時より9時間前の時間が記録されている(UTCで記録されているので時差がある) ECCubeの仕様らしいが、SQLで直接データを集計するような場合に注意が必要 タイムゾーン - < for EC-CUBE 4.0 Developers /> https://doc4.ec-cube.net/i18n_timezone EC-CUBE 開発コミュニティ - フォーラム https://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=22997&forum=17 一例だが、以下のようにすると9時間前の状態で日時を扱うことができる
DATE_FORMAT(o.order_date, '%Y-%m-%d') ↓ DATE_FORMAT(DATE_ADD(o.order_date, INTERVAL 9 HOUR),'%Y-%m-%d')
■Git管理の考察 ※要検証&要検討 CSS管理、JavaScript管理、メール設定 などにより、サーバ上のファイルが編集される GitからのPULLによりプログラムをサーバ上に反映している場合、コンフリクトが発生する可能性がある Git管理をどうするかは検討が必要 管理画面からファイルを編集すると、最終行の改行を削除されてしまう エディタ内で改行を追加しても削除されてしまう そうでなくてもコンフリクトの原因になるので、管理画面からの編集は禁止しておくべきか ただし、それはそれで利便性を損なっている GitHubなら、サーバ上から定期的に自動コミットさせるという手はありそう 加えて、専用画面から任意のタイミングでもコミットできるツールや、 サーバ上のファイルに変更があったものを一覧&詳細表示するツールもあると良さそう それなら、Gitを扱う開発者が気を付けておけば、管理画面からはGitの知識がなくても操作できそう デプロイキーに書き込み権限を設定できない環境用には、サーバ上での差分一覧を表示するツールを作って手動で取り込むか ただしテスト環境(先方確認用環境)など他環境も作るなら、そこでの変更を取り込むのは問題がある 例えばdevelopブランチやreleaseブランチの内容をテスト環境に反映したとして、テストで変更された内容を取り込んでmasterにマージしてしまうことになる Git.txt の「独自ブランチモデルの考察」のブランチモデルをもとにした運用とし、testブランチの内容をテスト環境に反映するか テスト環境での変更は定期的にtestブランチに取り込むが、testブランチ自体を他ブランチにマージすることは無いため、何とかなりそう 例えば本番環境で差分の発生したファイルをダウンロードして、そのままmasterにコミット&プッシュして、そのまま本番環境にデプロイできるかは要検証 競合エラーになるとして、強制的にデプロイできるかも要検証 何かしら対応はできそうだが gitでリモートのブランチにローカルを強制一致させたい時 - Qiita https://qiita.com/ms2sato/items/72b48c1b1923beb1e186 git pull を強制し、リモートでローカルを上書きする方法 | WWWクリエイターズ http://www-creators.com/archives/1097 上記の考察を経て、いったんは ・デプロイの際に競合があれば、その内容をエラメッセージに表示できるようにデプロイツールを調整 ・競合ファイルとその内容を一覧表示できるツールを別途作成。ツール上から、ファイルごとにリセットもできるように ・リセットしていい変更ならリセットしてデプロイ、そうでなければ差分をGitに取り込んでからリセットしてデプロイ のように、ツールの改良と運用によって対応している ■バージョンの確認 管理画面では「設定 → システム設定 → システム情報」で確認できる ソースコードでは、Ver3系と同じく、src/Eccube/Common/Constant.php で定義されている EC-CUBE バージョン確認方法 - PukiWiki https://yassu.jp/pukiwiki/index.php?EC-CUBE%20%A5%D0%A1%BC%A5%B8%A5%E7%A5%F3%B3%CE%C7%A7%CA%FD%CB%A1 なお、ECCube4.0.4からPHP7.4に対応しているとのこと 最新版「EC-CUBE 4.0.4」をリリース。HTTP クッキーをより安全にする SameSite 属性やPHP7.4への対応と多数の機能改善。|ECサイト構築・リニューアルは「ECオープンプラットフォームEC-CUBE」 https://www.ec-cube.net/news/detail.php?news_id=356

Advertisement