こんにちは！
今回はネットショップ運営を考えている方、または今のECサイトに満足していない方に向けて、
日本生まれのECプラットフォーム「EC-CUBE（イーシーキューブ）」をご紹介します。
無料で始められて、しかも柔軟にカスタマイズできるとあって、実は中小企業から大手企業まで幅広く使われているんです。

そもそもEC-CUBEって？

EC-CUBEは、日本発のオープンソースECプラットフォーム。
言い換えれば、「自分で自由に作れるネットショップの土台」です。
無料でダウンロード・利用できて、自社に合ったショップを思い通りに作れるのが最大の魅力！
デザインの変更も、機能追加も、まるでブロックのパーツのように組み立て自由自在なのです。

EC-CUBEでできること

✅ 商品の登録やカテゴリ分け
✅ 受注〜発送までの一元管理
✅ 会員登録・購入履歴・ポイント機能
✅ HTML/CSSでの自由なデザイン編集
✅ プラグインで機能拡張（クーポンやSNS連携）
つまり、「これがあればネットショップとして十分」な機能が、はじめからそろっています。

これは便利！知っておきたいおすすめ機能

💡 スマホ表示に自動対応
　スマートフォンでも見やすく、購入しやすいUIになっています。
💡 会員ランクやポイント制度もカンタン導入
　リピーター獲得の施策もばっちり。
💡 越境ECも視野に（多言語・多通貨対応）
　必要に応じて、海外販売の足がかりにもなります。
💡 エンジニアにはうれしい構造
　開発やカスタマイズがしやすい設計、開発コミュニティやドキュメントも充実。
💡 管理画面がわかりやすい！
　日本語で操作に迷わず、誰でもショップ運営をスタートできます。

EC-CUBEはこんな人におすすめ！

* これから本格的にネットショップを始めたい方
* 自由にカスタマイズして差別化したい方
* ShopifyやBASEでは物足りなくなってきた方
* 自社独自の販売スタイルに合わせて構築したい方

自分で作りたい人にも、プロに頼んで構築する人にも使いやすいのがEC-CUBEの魅力。
まずは一度、公式サイトやデモで触ってみてはいかがでしょうか？

EC-CUBEは、アイデア次第でショップの可能性がどんどん広がる柔軟なプラットフォームです。
「やってみたいけど、どこから手を付けたらいいかわからない」「自社向けにカスタマイズしたい」など、
導入や運用でお悩みがあれば、ぜひお気軽にご相談ください。
お問い合わせはこちら

最近これ便利だなっていうjavascriptプラグインを見つけたので紹介したいと思います。
開発者が嬉しいというより使っていただくユーザさんに便利なプラグインです。
名前を入力する場合は大抵フリガナも入力する欄が設置されていると思いますが同じことを2回入力するのって地味にめんどくさいと思うんです。
そんな手間を少しでも楽にしたい時はぜひ使ってみてください。
ECCUBEのバージョンには依存しないので、2系〜4系どこでも使用できるかと思います。
※今回は4系に実装します

https://github.com/harisenbon/autokana

こちら日本語入力に対するフリガナを自動的に別フィールドに記入するJQueryプラグインになります。
注意点も少しあります。
・keydownで発火するためコピペなどでは使えません
・入力されている文字を読み取ってカナに変換しているわけではないのでタイポした場合はカナに文字が残ってしまう

ここからは設置方法を説明します。とっても簡単です。

まず↑のリンクから.jsをダウンロードしhtml/user_data/jsに設置

Twigファイルを修正

app/template/default/Entry/index.twig

これだけです！

とってもかんたんですね♪

では実際に名前を入力してみましょう。

ちゃんとカナに入力されているのがわかりますね！

すぐできますのでぜひお試しください

EC-CUBE4 の Docker環境で環境変数を設定する際に、思わぬ壁にぶち当たりました。

services.yaml に記述されている設定内容を、環境ごとに分けるため、環境変数から取得するようにしたかったのです。
クレジット決済の3Dセキュアに関する設定なので、3D_SECURE_SETTING といった感じの名前で環境変数を登録し、設定として取得するようにしました。

docker-compose を使用する環境で環境変数を登録するには、docker-compose.dev.yml の environment に記述します。

services:
  ec-cube:
    environment:
      3D_SECURE_SETTING: "my_value"

環境変数を設定ファイル services.yaml で取得するには、’%env(環境変数名)%’ とします。

parameters:
  my_setting: '%env(3D_SECURE_SETTING)%'

以上で、コントローラー等で

$this->eccubeConfig['my_setting']

とすれば、”my_value”が読み取れるはず、が、以下のエラーが発生しました。

Environment variable not found: “3D_SECURE_SETTING”

何度も設定方法を確認し、コンテナの再起動とキャッシュクリアを繰り返すも虚しく時間がすぎるだけでしたが、ふと、「この変数名…？」と気づきました。
数字で始まる変数名は、多くのプログラミング言語で許可されていません。
また環境変数の命名規則も同様なようです。
PHPのコーディングをしている時はほぼ無意識的に避けて命名していたのですが、設定ファイル内でのこととあってか、頭から抜けていました。

英字から始まる環境変数名にすることで、無事取得できました！
イージーなミスですが、油断してるとハマりますね。

eccubeでenumを使いたい！

ECcubeでは固定値などはMasterにレコードを追加して、
使いたい場合は都度DBからレコードを検索して使用しているかと思います。

ですがいちいちDBに接続&検索をして使うのは…という場合にこんなやり方もあります。
enumの追加＆使用方法を簡単ですがご紹介したいと思います。

まず、Customize配下にEnumディレクトリを追加

下記のようなファイルを作成

<?php

namespace Customize\Enum;

/**

* 会員ランク

*/

enum CustomerRankType: string

{

　　case ROOKIE = ‘1’;

　　case BRONZE = ‘2’;

　　case SILVER = ‘3’;

　　case GOLD = ‘4’;

　　case PLATINUM = ‘5’;

　　case DIAMOND = ‘6’;

　　case MASTER = ‘7’;

　　public function getLabel(): string

　　{

　　　return match ($this) {

　　　　　self::ROOKIE => ‘ルーキー’,

　　　　　self::BRONZE => ‘ブロンズ’,

　　　　　self::SILVER => ‘シルバー’,

　　　　　self::GOLD => ‘ゴールド’,

　　　　　self::PLATINUM => ‘プラチナム’,

　　　　　self::DIAMOND => ‘ダイアモンド’,

　　　　　self::MASTER => ‘マスター’,

　　　　};

　　}

　　public static function getTypeList()

　　{

　　　$allList = [];

　　　foreach (self::cases() as $item) {

　　　　　$allList[$item->getLabel()] = $item->value;

　　　}

　　　return $allList;

　　}

}

使用方法ですが、例えばFormTypeで使用する場合は下記のようにすれば使用できます。

->add(‘customer_rank’, ChoiceType::class, [
‘required’ => false,
expanded’ => false,
‘multiple’ => false,
‘placeholder’ => ‘選択してください’,
‘choices’ => CustomerRankType::typeList(),
])

Twigにはこんな感じです

こんな感じで表示することができました。

ぜひ機会があればですが、検討してみてください。

EccubeではtwigやDoctrieで使用されているキャッシュをクリアする方法が、大きく２つあります。

1. 管理画面でキャッシュクリア
   • コンテンツ管理のキャッシュ管理 で削除対象をチェックしてクリア
2. キャッシュクリアコマンドでクリア
   • ３系だと下記コマンドですね
     • php app/console cache:clear
     • ※このコマンドを実行する際は、適切なユーザーで行う必要があります

私の参画していた案件ではコードがデプロイされると自動的にキャッシュクリアコマンドが実行されたので、（２）の方法でキャッシュクリアをしていたことになるのですが、それだとPluginのキャッシュがクリアされませんでした。

ということでキャッシュクリアコマンドでPluginのキャッシュもクリアさせる方法です。

• 参考
  • https://github.com/EC-CUBE/ec-cube3/blob/3.0/src/Eccube/Util/Cache.php

/src/Eccube/Util/Cache.php



public static function clear($app, $isAll, $isTwig = false)
{
    $cacheDir = $app['config']['root_dir'].'/app/cache';

    $filesystem = new Filesystem();
    if ($isAll) {
        $finder = Finder::create()->in($cacheDir)->notName('.gitkeep');
        $filesystem->remove($finder);
    } elseif ($isTwig) {
        if (is_dir($cacheDir.'/twig')) {
            $finder = Finder::create()->in($cacheDir.'/twig');
            $filesystem->remove($finder);
        }
    } else {
        if (is_dir($cacheDir.'/doctrine')) {
            $finder = Finder::create()->in($cacheDir.'/doctrine');
            $filesystem->remove($finder);
        }
        if (is_dir($cacheDir.'/profiler')) {
            $finder = Finder::create()->in($cacheDir.'/profiler');
            $filesystem->remove($finder);
        }
        if (is_dir($cacheDir.'/twig')) {
            $finder = Finder::create()->in($cacheDir.'/twig');
            $filesystem->remove($finder);
        }
        if (is_dir($cacheDir.'/translator')) {
            $finder = Finder::create()->in($cacheDir.'/translator');
            $filesystem->remove($finder);
        }
        // pluginディレクトリを対象に追加ここから
        if (is_dir($cacheDir . '/plugin')) {
            $finder = Finder::create()->in($cacheDir . '/plugin');
            $filesystem->remove($finder);
        }
        // pluginディレクトリを対象に追加ここまで

    }

    if (function_exists('opcache_reset')) {
        opcache_reset();
    }

    if (function_exists('apc_clear_cache')) {
        apc_clear_cache('user');
        apc_clear_cache();
    }

    if (function_exists('wincache_ucache_clear')) {
        wincache_ucache_clear();
    }

    return true;
}

カスタマイズ箇所は「pluginディレクトリを対象に追加ここから」「pluginディレクトリを対象に追加ここまで」とコメントしている間の４行のみです。（コメント含めると６行）

「キャッシュクリアコマンドで全てのキャッシュファイルは削除される」と思い込んでいましたが、デフォルトではPluginは対象外のようです。

ちなみに、--allをつけてphp app/console cache:clear --allで実行するとapp/cache配下全てがクリアされるので、Pluginのキャッシュファイルも削除されますが、これは稼働中のサーバでは実行してはいけません。
デフォルトではapp/cache配下にセッションファイルも格納しているためです。

cacheというディレクト名なので削除可能なファイルが置かれている印象を受けますが、実はセッションのようなファイルが入っている、特にカスタマイズしている場合はセッション以外にも削除不可なファイルが配置されている可能性もありますので、allオプションはよほど自信が無い限りは利用しないほうが良いと思います。

以上、「キャッシュクリアコマンドで全てのキャッシュファイルは削除されると思ったらプラグインは別だった」でした。