この記事には過去に筆者が試行錯誤してEC-CUBEをサーバに導入したことが書かれています。
まずはEC-CUBEと大手ECモールの違いについてお話していきます。
大手ECモールのショップシステムの場合
楽天市場・Yahoo!ショッピング・Amazonなど大手ECモールはどれも最初の導入は何かと手間はかかるものの（特に契約事項）しっかりとした販売プラットフォームが用意されておりマニュアルも沢山あるため、ホームページがあまりわからない人でもそれなりに使えるようになっています。
また、分からないことは電話やチャットでサポートが受けられること、
知識豊富なサポーターが多く丁寧に説明してくれるため安心です。
ただ、その分料金が高めとなっているのもありますが、Yahoo!ショッピングは売上から手数料を引く形なので比較的導入しやすいと思います。
Amazonも小口出品であれば１品売れたら100円の手数料が掛かるくらいなのでおすすめです。（大口出品の場合は月額4,900円(税抜)掛かります）
EC-CUBEの場合
EC-CUBEとは？
株式会社イーシーキューブ（旧：株式会社ロックオン）が開発するオープンソースのEC向けコンテンツ管理システム。
ASPと比べ拡張性に優れておりオープンソースのため無料で使うことができます。
契約の手間は殆どないが導入が大変
EC-CUBEの場合は契約云々の面倒くささは無いですしシステムそのものは無料なのでおサイフには優しいのですが、EC-CUBEが対応しているサーバが必要なのとドメイン取得やセキュリティ対策にSSL対応などかなりのウェブ知識が必要です。そのためEC-CUBE導入前に挫折される方も結構いらっしゃるかもしれません。
（最初はYahooやAmazonで販売してたほうが費用が安く済むかもしれません）
サーバがEC-CUBE対応していれば簡単インストール的なものがあるかもしれませんが、それ以外は基本的にダウンロードしてアップロードしてなど手間が掛かります。
（さくらインターネットはEC-CUBEが用意されているため導入しやすい）
一応コミュニティがあるのでわからないことは質問することもできますが、有志が対応しているので情報はさまざまです。
また、いざ導入ができたとしてもショップ機能に関しては大手ECモールのものと比べ、最小限な販売機能しか無いため色々足りないと感じると思います。
その場合はプラグインというもので機能を拡張することができます。（プラグインは無料有料色々あります、有料はギョッとなるほど高いものも；）
特に決済システムは最初は銀行振込くらいしかできないので、クレジットカード払いやコンビニ払いなどは別途決済プラグインを導入する必要があります。
さてここから先は、私が4年前に書いたことで文句言いながら執筆している記事なので読みにくく無駄に顔文字が多いのですが、一応EC-CUBE導入までの道のりが悪戦苦闘しつつも書いてます。
参考になるかは分かりませんが、EC-CUBEを導入検討されてる方や私と同じように行き詰まった方に読んで頂ければ幸いです。
EC-CUBEをインストールしようとするが・・・。
現在のさくらインターネットにはスタンダードプランでもEC-CUBEは標準で搭載しているのですが、この記事を書いていた頃は確かなかった（あったかもしれない）のでEC-CUBEの公式サイトからEC-CUBE3をダウンロードし直接サーバの中に入れて動かそうとしているのですが・・・。
過去記事ーーーーーーーーーーーーーーーーーーーー
今回一番問題なのが、「なんで標準でドメイン直下にインストールしてくれないの！？」ってとこですかね。
インストールするとわかるんですが、わざわざ追加でEC-CUBE用にディレクトリを追加する必要があって、その中にEC-CUBEがインストールされる形になるんですよね。。。
メインのウェブサイトとして運用するのにそれは変でしょ・・・。
とりあえず私の環境ではなんとかドメイン直下にインストールすることができているのですが、まだ完全に移行しきれておらず、一部の機能にエラーが出るという症状があります。
とりあえず注文処理や商品情報の変更などは問題ないんですが、ページ情報を更新すると毎回「システムエラーが発生しました。」と表示されるんですよね、ちゃんと反映されてるのに。
まぁそれだけなので全く動かないとかそういうのはないのでとりあえずそのままにしています；
まぁ、なんやかんやで運用できる状態にはなっているので後は自分なりに調整していこうかなと思います。
クレジット機能のプラグインは導入してもいいかもしれませんが、それ以外のプラグインで欲しい機能は自作しようかと思います、高いし。。。
色々ぐちぐち言ってますが、なんやかんや言ってもオリジナルのネットショップ立ち上げるツールとしては私的には無料にしてはしっかり出来てるなと思いますのでこれからもっと使いやすくなってくれればいいなと思います。
ーーーーーーーーーーーーーーーーーーーーーーーーー
ん？
過去の私は何が言いたいのか話がシッチャカメッチャカしていますが、恐らく
ドメイン直下にインストールしようとしても「/eccube/html」という形、eccube/htmlフォルダの中にショッピングシステムが入ってしまっている。本来は「https://www.ドメイン/」でEC-CUBE3を動かしたかったんだと思います。（この後の記事にその話はしています）
※ドメイン名は例です。
で、手動でドメイン直下に移動させたんだと思うのですが、上手く動かないということみたいです。（他人事）
EC-CUBE3の先日のエラー「システムエラーが発生しました。」解決策への道のり
EC-CUBE３をローカルサーバから本サーバに移行した際に発生していた以下の問題
「システムエラーが発生しました。
大変お手数ですが、サイト管理者までご連絡ください。」
通常のページでは注文とか会員ページとかで内容変更した所で特にエラー画面が表示されるということはありませんでしたが、管理ページでページを新規で追加したりなど何かアクションすると毎回エラー画面が表示されておりました。
恐らくeccube/htmlというディレクトリ構造からドメイン直下にデータを移動させてパス設定でどこか変更抜けがあったからなんだと思ってたのですが・・・
今までどこが悪いのか全然分かりませんでした。
エラーが発生してるならログ情報に記載されているはずなんですが、管理ページのログ確認ページにアクセスすると速攻上記のエラー画面が表示されてました。
管理ページからはエラー内容は見れませんがログ情報はありました。
皆さんのEC-CUBE3のディレクトリ構造はどうなっているのかわかりませんが、上位階層に「app」というディレクトリがあります。
その中の「log」という場所にきちんとログ情報が記録されています。
管理ページではそれを見やすい形にしているようですが、メモ帳などで直接ログファイル見ても内容が分かるようになっています。
www//app/log/” directory does not exist.
スラッシュが２つ重なってるのも変ですが、そもそもappフォルダの参照先が間違えています。
私が本サーバにEC-CUBE3を入れてる場所はドメイン直下のディレクトリにhtml内に入ってたものを移動させています。
それ以外のhtmlディレクトリよりも上位階層にあったデータは主にシステムデータとなりますので、wwwよりも下位階層に入れてしまうとセキュリティ的によくありません。
なので外部からアクセス出来ない上位階層のディレクトリに移動させています。
なぜwww内にあるappディレクトリを参照するようになってしまってるのかと言いますと、「app/config/eccube/」にある「path.yml」の「root_dir」のパスがwwwまで記入していたからです。
全体的にはディレクトリ階層を上げて設定していたつもりが、ルートディレクトリの設定を変更していなかったのが今回のシステムエラーの原因でした。
ルートディレクトリをwww外した状態でもう一度管理ページから操作してみたところ、エラーがすっかり無くなりました。
ただ、EC-CUBE3の場合、path.ymlを変更した所でパスが変更されない箇所があるので、一度システムデータを一通り確認する必要があります。
（所々直接パスを打ち込んでる箇所がありました；）
（不具合解決メモ）PHP5.4.45＋EC-CUBE3.0.10＋Amazon Payプラグイン（NIPPON Platform製）の組み合わせだとカートページ時に500エラーが発生する
無料でEC-CUBE用Amazon Payプラグインを提供していたNIPPON PAYが2019年8月2日にプラグインの新規申し込み受付を停止しておりました。
現在も受付していないのでEC-CUBE用Amazon Payプラグインはアイピーロジック製一択となりそうです。
ということでこの記事の内容は殆ど役立たないのですが、個人的なメモとして残しておきます↓
会社オリジナルのネットショッピングサイトがあるのですが、そのサイトでよりお客様が買い物しやすいようAmazon Payプラグイン（NIPPON Platform製）を導入を検討。
しかしAmazon Payプラグインをそのまま利用するとPHP5.4.45＋EC-CUBE3.0.10の構成にてカートページ遷移時に「500 Internal Server Error」が発生しました。
恐らくサーバのPHPバージョンが古いせいかもしれませんが、
以下の方法でカートページ遷移時のエラーは解決。
◎app/Plugin/FgAmazonPay/FgAmazonPayEvent.php 311行目
修正前：$elements[0]->parentNode->appendChild($template);
修正後：$elements->item(0)->parentNode->appendChild($template);
ちなみにエラー確認はindex_dev.phpを使用しました。
NIPPON PlatformのAmazon Payプラグインは月額費用もかからないためとても助かるプラグインなのですが、その分サポート対応がないためエラーが起きた時に厳しいです。
それを考えたらアイピーロジック製のほうが良いのかもしれませんが、月5,000円もかかるため駆け出しECショップには痛いです。
できるだけコストを抑えるためには自分でなんとかするしかないですね。。。
EC-CUBE3テンプレートが変更できない
ローカルサーバ上で作成したものを本サーバに適用させようとしたのですが、本サーバのEC-CUBE3を「eccube」ディレクトリからドメイン直下に移動させたせいかテンプレートが変更できなくなりました。
その他のことについてはpath.ymlで全体のパスを変更した際に正しく適用されましたが、テンプレートだけは上手くいきません。
path.ymlを変えればテンプレートの保存先パスも変わるんじゃないのか？
アップロードしても新たにhtml/templateディレクトリを作成しそこに保存しようとする。。。テンプレートデータのパスはどこで管理しているんだろうか？
【追記】
path.ymlだけ変更するだけでは上手く反映されないことが分かりました。
src/Eccubeの中にあるファイルもパス見てみるとディレクトリ直下になってない箇所がいくつかあったのでnotepad++で一括で修正しました。
とりあえずテンプレートの反映はできましたが、ローカルサーバで作ったデータ丸ごと移行できたらいいですね；
EC-CUBE3 規格名取得
{# 規格1 #}
{{ Product.className1 }}：
{{ form_widget(form.classcategory_id1) }} {{ form_errors(form.classcategory_id1) }}{{ Product.className1 }}で規格１の名前が取得できるようです。
Nameの後ろの数字を2にすると規格２の名前が取得できます。
Twigが全然わからなくてGitHubで調べてたら関数リストが乗っていたので参考にさせて頂きました。
Eccube\Entity\Product · yna
