最近これ便利だなっていう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オプションはよほど自信が無い限りは利用しないほうが良いと思います。

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

ECCUBEでは、商品の価格は税抜の本体価格を登録する仕様になっています。

しかし元々税込価格で管理していた場合、端数の処理を考慮しつつ税抜価格を計算して登録しなければなりません。

それならはじめから税込価格を登録したい、というケースで実施したカスタマイズ方法がこちらです。

内容としてはシンプルに、商品の税表示区分はすべて「税込」とし、外税額を求めるメソッドで必ず０を返すようにしてしまうというものです。（確認したECCUBEバージョンは4.2です。）

app/Customize/Service/OrderHelperExtension.php を作成し、OrderHelper の getTaxDisplayType を上書き宣言します

<?php

namespace Customize\Service;

use Eccube\Entity\Master\TaxDisplayType;

class OrderHelperExtension extends \Eccube\Service\OrderHelper
{
    /**
     * 税表示区分を取得する.
     * 価格を税込みで登録するため、常に"税込"を返す
     *
     * @param $OrderItemType
     *
     * @return TaxDisplayType
     */
    public function getTaxDisplayType($OrderItemType)
    {
        return $this->entityManager->find(TaxDisplayType::class, TaxDisplayType::INCLUDED);
    }
}

app/Customize/Service/TaxRuleServiceExtension.php を作成し、TaxRuleService の getTax を上書き宣言します

<?php

namespace Customize\Service;

class TaxRuleServiceExtension extends \Eccube\Service\TaxRuleService
{
    public function getTax($price, $product = null, $productClass = null, $pref = null, $country = null)
    {
        // 価格を税込みで登録するため、外税計算は常に0を返す
        return 0;
    }
}

app/Customize/Resource/config/services.yaml でサービスの上書きを設定します。

services:
  Customize\Service\OrderHelperExtension:
    autowire: true
    decorates: Eccube\Service\OrderHelper
  Customize\Service\TaxRuleServiceExtension:
    autowire: true
    decorates: Eccube\Service\TaxRuleService

以上で、商品に登録した価格を税込みとして扱うことができます。

【注意】プラグインや独自カスタマイズで、上記で上書きしたメソッドを使わずに税額・税込価格を計算している場合があります。動作確認を行い、適切な修正を施す必要があります。

 

 

プロジェクトが大規模になるにつれて、コードの複雑性や保守性の向上が課題となります。このような課題に対処する手段として、いろいろなツールがあると思いますが、今回はPHPStanをプロジェクトに組み込むことで、コードの品質向上させたいと思います。

PHPStanの導入

PHPStanをプロジェクトに導入するために、まずComposerを使用して必要なパッケージをインストールします。

composer require --dev phpstan/phpstan

場合によっては下記のエラーが出るかもしれません。

Generating optimized autoload files> Illuminate\Foundation\ComposerScripts::postAutoloadDump> @php artisan package:discover –ansi
In PackageManifest.php line 122: Undefined index: name

このエラーはcomposer v2を使用している場合に発生するようです。
なので、一旦composerのバージョンを下げることで解決できます。

composer self-update --1

インストールが完了したら、プロジェクトのルートディレクトリに .phpstan.neon という設定ファイルを作成します。このファイルには、PHPStanの静的解析のレベル設定や解析対象となるディレクトリを指定します。

parameters:
    level: 8
    paths: src/Eccube/
    excludePaths: src/Eccube/Command/GeneratorCommand/*

これで準備が整ったので、一度PHPStanを実行してみましょう！

vendor/bin/phpstan analyze

すると、大量にエラーが…！

PHPDoc tag @param has invalid value \\(\\$value\\)\\: Unexpected token \”\\$value\”, expected type at offset 102$PHPDoc tag @param has invalid value \\(\\$value\\)\\: Unexpected token \”\\$value\”, expected type at offset 18PHPDoc tag @param has invalid value \\(\\$value\\)\\: Unexpected token \”\\$value\”, expected type at offset 57Parameter \\#1 \\$str of function trim expects string, string\\|null given\\.

8000件くらいエラーが出てしまいました。。既存のプロジェクトに途中から導入しているので仕方ないですね。
こういう時のために、PHPStanでbaselineというものを作成できます。baselineに含めたエラーは一旦無視できます。

vendor/bin/phpstan analyze --generate-baseline

`phpstan-baseline.neon`が自動生成されますので、こちら`phpstan.neon`に記載し読み込んでもらいましょう。

phpstan.neon
includes:
    - phpstan-baseline.neon

parameters:
    level: 8
    paths: src/Eccube/
    excludePaths: src/Eccube/Command/GeneratorCommand/*

これで大量のエラーは一旦無視できました！

型注釈の追加

エンティティやそれに関連するメソッドに型注釈を追加します。これにより、PHPStanはコードの型整合性を確認しやすくなります。

// src/Entity/YourEntity.php

class YourEntity
{
    /**
     * @var string
     */
    private $name;
    
    // ...

    /**
    * @param string
    * @return string
    ** /
    public function test(string $message)
    {
        return message;
    }
}

 

いかがでしたでしょうか？

PHPStanはコードの静的解析を行い、型の整合性や潜在的な問題を見つけてくれます。これにより、コードの品質向上や開発プロセスの効率化が期待できます。

PHPStanを導入することで、より安全で信頼性の高いコードを構築することができます。是非一度試してみて、プロジェクトのメンテナンス性や開発速度の向上を実感してください。

前回、phinxをインストールしたところまでを説明しましたので、
今回は実際に使用してDBを更新してみたいと思います。

マイグレーションファイルを作成したり、実行する場合は下記のディレクトリで行います。

cd {dataのパス}/vendor/bin

まずはマイグレーションファイルを作成してみましょう！
ファイル名は見た感じわかりやすい方がいいですね。

今回はメンバーに誕生日カラムを追加してみましょう！

php phinx create AddDtbMember

下記のようなものが表示されればOKです。

Phinx by CakePHP – https://phinx.org. version 0.10.8

using config file ./phinx.yml
using config parser yaml
using migration paths
– {dataパス}/data/db/migrations
using seed paths
– {dataパス}/data/db/seeds
using migration base class Phinx\Migration\AbstractMigration
using default template
created {dataパス}/db/migrations/20231030045812_add_dtb_member.php

{dataパス}/db/migrationsディレクトリにファイルができているはずです。

change()メソッドが生成されているので、下記のソースを追加しましょう。

$this->execute(“alter table dtb_member add birth datetime null comment ‘誕生日’;”);

changeメソッド以外にも色々メソッドはあるので、こちらを参考に使い分けてもらってもいいと思います！
https://book.cakephp.org/3/ja/phinx/migrations.html

マイグレーションの実行をしてみましょう！

php phinx migrate -e development

マイグレーションが実行されていれば下記の表示がされます！

Phinx by CakePHP – https://phinx.org. version 0.10.8

using config file ./phinx.yml
using config parser yaml
using migration paths
– {dataパス}/db/migrations
using seed paths
– {dataパス}/db/seeds
using environment development
using adapter mysql
using database eccube2_db

== 20231030045812 AddDtbMember: migrating
== 20231030045812 AddDtbMember: migrated 0.2129s

All Done. Took 0.2522s

ちなみに、、、
下記のコマンドで実行前のSQLの確認もできますが、初回実行前に試したらphinxlogができておらずエラーになってしまいました。。。

php phinx migrate -e development –dry-run

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table ‘{DB名}.phinxlog’ doesn’t exist in {dataのパス}/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:194

phinxlogはマイグレーションファイルを管理しているテーブルになります。

CREATE TABLE `phinxlog` (
`version` bigint(20) NOT NULL,
`migration_name` varchar(100) DEFAULT NULL,
`start_time` timestamp NULL DEFAULT NULL,
`end_time` timestamp NULL DEFAULT NULL,
`breakpoint` tinyint(1) NOT NULL DEFAULT ‘0’,
PRIMARY KEY (`version`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

ちなみに今回実行したマイグレーションの情報はこんな感じで保存されていました。

version,migration_name,start_time,end_time,breakpoint
20231030045812,AddDtbMember,2023-10-30 14:25:13,2023-10-30 14:25:14,0

実際に私が担当した案件でphinxを導入したら格段にマイグレーションの管理がしやすくなりました！！

ぜひ2系を触る場合は初期構築時に導入することをお勧めします！！

 

eccube2系を複数人で開発しているときに思うこと。

「3系とか4系みたいにマイグレーション機能があればいいのに！！」

無くてもできるとは思いますが、他メンバーが作ったSQLを自分でいちいち叩くのは面倒。
しかもどのSQL叩いたかどこかにメモしておかないと忘れちゃう…

なんてことありますよね。

それを解消するために今回は2系にマイグレーションツールの「Phinx」を導入したいと思います。

まず、ローカル環境でdocker+eccube2を用意してください。

ここからphinxの導入をしたいと思います。

（１）composerからphinxをインストールする

composer require robmorgan/phinx

しかしエラーが発生。。

Cannot use robmorgan/phinx’s latest version 0.15.2 as it requires php-64bit >=8.1 which is not satisfied by your platform.
Using version ^0.14.0 for robmorgan/phinx
./composer.json has been updated
Running composer update robmorgan/phinx
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

Problem 1
– Root composer.json requires robmorgan/phinx ^0.14.0 -> satisfiable by robmorgan/phinx[0.14.0].
– robmorgan/phinx 0.14.0 requires symfony/console ^3.4|^4.0|^5.0|^6.0 -> found symfony/console[v3.4.0, …, v3.4.47, v4.0.0, …, v4.4.49, v5.0.0, …, v5.4.28, v6.0.0, …, v6.3.4] but the package is fixed to v2.8.52 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

Use the option –with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, e.g. “composer require robmorgan/phinx:*” to figure out if any version is installable, or “composer require robmorgan/phinx:^2.1” if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.
# php composer require robmorgan/phinx
Could not open input file: composer

ふむふむ。。
phpとバージョンが合わないから使えないよー。
明示的にphinxのバージョンを指定してね的なことを言われました。
なので下記で再実行

composer require robmorgan/phinx:*

ちゃんとインストールされました！

（２）Phinxの設定ファイルを生成するためvendor/bin配下に移動

cd {dataのパス}/vendor/bin
php phinx init

そうすると /var/www/data/vendor/bin/phinx.php（Phinxの設定ファイル）が生成されます。

（３）Phinxの設定ファイルを編集する。

①migrationsを変更→{dataパス}/db/migrations
②seedsを変更→{dataパス}/db/seeds
③developmentもローカル環境に合わせて修正
※data/config/config.phpを参考

paths:
migrations: ①
seeds: ②

environments:
default_migration_table: phinxlog
default_database: development
production:
adapter: mysql
host: localhost
name: production_db
user: root
pass: ”
port: 3306
charset: utf8

development:③
adapter: mysql
host: localhost
name: development_db
user: root
pass: ”
port: 3306
charset: utf8

testing:
adapter: mysql
host: localhost
name: testing_db
user: root
pass: ”
port: 3306
charset: utf8

version_order: creation

（４）ディレクトリを作成する

mkdir {dataパス}/db
mkdir {dataパス}/db/migrations
mkdir {dataパス}/db/seeds

これで構築完了です。

一旦ここで終わりです。

次はマイグレーションファイルを実際に作って実行してみましょう。

今日はECCUBE4系の管理画面の操作で、お客様から1番頂く質問について書いていこうと思います。

1番多い質問。。。それは、支払方法設定について！！！

「管理画面の支払方法設定画面で、支払方法を追加したのですが、フロント側で商品の購入手続き画面に出てこないのですが、不具合でしょうか。。。？」
そうですよね、そう見えますよね。。。

ですが、それは不具合ではないのです！
ECCUBE4系の立派な（？）仕様なのです！

まず、下記スクショがデフォルトの状態の支払方法設定画面ですね。

ここに、新しい支払方法を追加します。

ちゃんと表示で登録できていることが確認できました。ではフロント側の購入手続き画面の支払方法を確認してみましょう！

あれ。。。出てこない。。。

登録したはずの支払方法「後払い」が出てこない。。。

これは。。。不具合！？

いえいえ、不具合ではございません！

配送設定画面というのが、管理画面に存在するのはご存知でしょうか？

はい、「取り扱う支払方法」の項目に、新しく追加した「後払い」が選択できるようになっていますが、設定がされていないことにお気づきでしょうか？

ここで、購入手続き画面をもう1度見てみましょう。

「配送方法」の項目はサンプル業者が選択されていますね。

ですが、サンプル業者の設定では、支払方法に「後払い」が設定されていないのです。

そのため、購入手続き画面でお支払方法に追加した「後払い」が選択できないという事象が起こったのです。

サンプル宅配を選択してみると、「銀行振込」しか出力されていないですね。

これは、管理画面の配送方法設定のサンプル宅配が、「銀行振込」しか設定されていないためです。

このように、配送業者によって支払方法を設定できるため、支払方法設定画面で支払方法の追加を行っただけでは、購入手続き画面の「お支払方法」に出力されないというわけです。

支払方法設定画面は、支払方法の選択肢の設定が行える画面

配送方法設定画面は、配送方法ごとに詳細を設定できるので、支払方法の設定も行える画面

と、覚えておくと良いかもしれません。

なんでこうなるのかな〜？がわかっていないと、意外とハマってしまう支払方法設定の解説でした。

支払方法設定で困っている方のお役に少しでも立てれば幸いです。