feat: EC-CUBE 4.4への対応

[ttokoro20240902]

概要

おすすめ商品管理プラグインを EC-CUBE 4.4（Symfony 7.4 / Doctrine ORM 3.0 / PHP 8.2+） に対応させ、コードを Recommend42 → Recommend44 に改名します。4.3 とは非互換（属性必須・ORM 3・PHP 8.2+）のため、新規 4.4 ブランチへの取り込みです。

参考: 4.3→4.4 マイグレーション手順 (doc #346) / 先行対応 eccube-api4 #186 / sample-payment-plugin #53

変更内容

1. EC-CUBE 4.4 対応（コア移行）

• Annotations → PHP 属性: Entity の @ORM\* → #[ORM\*]、Controller の @Route/@Template → #[Route]/#[Template]（Sensio 依存除去）
• 型宣言の明示: Entity プロパティの型付け（?int/?string/bool 等）、ゲッター/セッター・各メソッドの戻り値型
• Doctrine ORM 3.0: flush($entity) → flush()
• Symfony 7: Assert\Length を名前付き引数形式へ
• AbstractPluginManager: 全メソッドに : void、暗黙 nullable 引数の解消
• PHPUnit 11: phpunit.xml.dist を <source>/<extensions> 形式へ
• コード名: namespace / composer code / version: 4.4.0 / テンプレート参照を Recommend44 に統一

2. Docker Compose によるテスト環境

• docker-compose.yml + dev/mysql/pgsql オーバーレイ、dockerbuild/
• EC-CUBE 4.4 イメージ（ghcr.io/ec-cube/ec-cube-php:8.2-apache-4.4）でプラグインを自動導入・有効化し PHPUnit を実行可能
• 管理画面ログイン用に APP_ENV=dev 起動＋dev 用 Cookie 設定（cookie_secure:false/cookie_samesite:lax）を上書き

3. 静的解析・整形ツール

• phpstan.neon.dist（level 6）/ Resource/rector.php / Resource/.php-cs-fixer.dist.php を追加（.php 設定は本体の Plugin\: サービス検出で 500 を避けるため Resource/ 配下に配置）
• rector / php-cs-fixer を適用し、phpstan level 6 を baseline なしでエラーゼロまでクリア（Repository に @extends AbstractRepository<RecommendProduct> を付与する等）
• CLAUDE.md に開発・テスト手順、アーキテクチャ、移行・配置の注意を記載

4. CI（.github/workflows/main.yml ほか）

• マトリクスを EC-CUBE 4.4 / PHP 8.2-8.4 / MySQL8・PostgreSQL に更新、checkout@v4・$GITHUB_OUTPUT 化
• --ignore-platform-req=ext-redis: Symfony 7.4 の symfony/cache が古い php-redis と衝突して本体 composer install が失敗するのを回避（redis は未使用）
• phpunit 前に cache:warmup: 有効プラグインのルートはコンテナのコンパイル時に確定するため、phpunit プロセスの遅延コンパイルだと RouteNotFoundException が断続的に発生する問題を解消
• release.yml: 配布パッケージから開発・テスト用ファイル（docker-compose / dockerbuild / CLAUDE.md / phpstan / rector / php-cs-fixer）を除外

テスト

• EC-CUBE 4.4（8.2-apache-4.4）+ SQLite で PHPUnit 全 24 テスト パス（PHPUnit 11.5 / PHP 8.2）
• CI 全マトリクス green（4.4 × PHP 8.2/8.3/8.4 × MySQL8/PostgreSQL）
• phpstan level 6 エラーゼロ（baseline なし）/ php-cs-fixer 差分ゼロ
• Playwright で管理画面ログイン・「おすすめ管理」画面の表示を確認
• 配布パッケージ（release.yml 相当）が PharData で展開可能・code=Recommend44 を確認

🤖 Generated with Claude Code

[ttokoro20240902]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b605ad49-5a06-4ca1-ba46-8fe83462893f

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat-4.4

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ttokoro20240902]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[dotani1111]

4.4/Symfony7 対応をレビュー・実機検証しました。Recommend42→44 の移行（PluginManager シグネチャのコア親一致・flush() 引数除去・#[Route]/#[ORM]/#[Template] 属性化・namespace 全面統一）は正しく、CI 全マトリクス green。実機（install/enable・schema:validate 同期・管理画面描画）に加え、商品検索モーダルからおすすめ商品を登録→一覧表示まで確認しました。Blocker なし。LGTM 👍

任意の軽微点: Resource/rector.php のライセンスヘッダが http のまま／FormType の未使用 getName()。

[nanasess]

4.4 環境（PHP 8.5.4 / Symfony 7.4.13 / Doctrine ORM 3.6.2 / DBAL 4.4.3）へ本 PR のブランチをインストールし、実機で動作確認したうえでレビューしました。

一覧・新規登録・編集・削除・フロント表示のすべてが正常に動作しました。移行の品質は高く、fatal 化しうる箇所（AbstractPluginManager の新シグネチャ、EccubeNav::getNav(): array、ORM 3 の flush() 引数削除、Routing\Attribute\Route、@ORM → #[ORM] の options / JoinColumn）はすべて正しく追従できていることを本体 4.4 のソースと突き合わせて確認しています。

blocker はありません。

実機動作検証の結果

検証項目	結果
おすすめ商品一覧	✅ 表示・件数カウント
新規登録（商品検索モーダル → 選択 → 保存）	✅ 「おすすめ商品を登録しました。」
編集	✅ 「おすすめ商品を修正しました。」
削除（DELETE + CSRF）	✅ 「おすすめ商品を削除しました。」
フロント表示（ブロック）	✅ 下層ページ（レイアウト 2 / MAIN_BOTTOM）に描画
XSS 対策	✅ 説明文は |raw|purify|nl2br を通す

別 PR での対応をご検討ください（差分範囲外）

Resource/template/admin/index.twig の冒頭で読み込んでいる assets/js/vendor/jquery.ui/*.min.js 4 本は、本体 4.2.0 の時点で削除済みで 4.4 のツリーに存在しません。実機で /admin/plugin/recommend を開くと 404 が 4 件出ます。

404 /html/template/admin/assets/js/vendor/jquery.ui/jquery.ui.core.min.js
404 /html/template/admin/assets/js/vendor/jquery.ui/jquery.ui.widget.min.js
404 /html/template/admin/assets/js/vendor/jquery.ui/jquery.ui.mouse.min.js
404 /html/template/admin/assets/js/vendor/jquery.ui/jquery.ui.sortable.min.js

機能退行はありません。 jQuery UI sortable は本体の admin.bundle.js が同梱しており、default_frame.twig の <head> で読み込まれるため、読み込み順の面でも問題ありません。本 PR の差分には含まれない 4.2 からの持ち越しなので、別 PR での削除をご検討ください。

良い点

• 削除が methods: ['DELETE'] + CSRF トークン検証で保護されている
• 説明文の出力が |raw|purify|nl2br で XSS 対策済み
• Resource/rector.php / Resource/.php-cs-fixer.dist.php を Resource/ 配下に置く配置が、4.4 の app/config/eccube/services.php の exclude と整合している
• RecommendService が RecommendProduct $data に対して $data['id'] で配列アクセスしている点は、Eccube\Entity\AbstractEntity implements \ArrayAccess のため問題なし

[nanasess]

[minor] methods 指定と CSRF トークン検証がありません

同じコントローラの delete() は methods: ['DELETE'] + $this->isTokenValid() で保護されていますが、並び替えの moveRank() にはどちらもありません。

本体 4.4 の同型エンドポイントは 6 本すべて（CategoryController / ClassCategoryController / ClassNameController / TagController / PaymentController / DeliveryController）が

1. methods: ['POST']
2. if (!$request->isXmlHttpRequest()) throw new BadRequestHttpException();
3. if ($this->isTokenValid())

の 3 点セットになっており、本実装だけがこの規約から外れています。

実害の度合いは限定的です（$request->isXmlHttpRequest() を通しており、X-Requested-With は CORS のセーフリストヘッダではないため、クロスサイトからの単純フォーム POST は成立しません）。ただし修正コストはほぼゼロで、テンプレート側の変更も不要です。

修正案: 本体 CategoryController::moveSortNo() と同じ形に揃える。

#[Route(path: '/%eccube_admin_route%/plugin/recommend/sort_no/move', name: 'plugin_recommend_rank_move', methods: ['POST'])]
public function moveRank(Request $request): Response
{
    if (!$request->isXmlHttpRequest()) {
        throw new BadRequestHttpException();
    }
    if ($this->isTokenValid()) {
        ...
    }
}

[ttokoro20240902]

ご指摘のとおり、本体の 3 点セットに揃えました（78dde65）。

#[Route(..., name: 'plugin_recommend_rank_move', methods: ['POST'])]
public function moveRank(Request $request): Response
{
    if (!$request->isXmlHttpRequest()) {
        throw new BadRequestHttpException();
    }
    if ($this->isTokenValid()) { ... return new Response('OK'); }
    throw new BadRequestHttpException();
}

ご指摘どおりテンプレートの変更は不要でした。本体 default_frame.twig の $.ajaxSetup が ECCUBE-CSRF-TOKEN ヘッダを全 Ajax に付与し、isTokenValid() がそれを読むためです。実機で並び替えを行い、リクエストヘッダに同トークンが乗って 200 が返ること、リロード後も順序が保持されることを確認しました。

ガードの動作も確認済みです: トークンなし → 403 / GET → 405 / X-Requested-With なし → 400 / 正常 → 200。

[nanasess]

[minor] CI の DB イメージが、同じ PR で追加した docker-compose とも本体 4.4 とも食い違っています

場所	MySQL	PostgreSQL
.github/workflows/main.yml	mysql:8	postgres:14
docker-compose.mysql.yml（本 PR で追加）	mysql:8.4	—
docker-compose.pgsql.yml（本 PR で追加）	—	postgres:18
本体 unit-test.yml	8.4	18 / 13

本 PR 自身が追加した docker-compose は本体に揃えているのに、CI の service コンテナだけ 4.2 ブランチから持ち越した設定のままで、ローカル開発と CI でテストする DB バージョンが食い違っています。

なお database_server_version は本体 4.4 も MySQL 8.4 に対して 8 を指定しているので、現状のままで問題ありません。

[ttokoro20240902]

mysql:8.4 / postgres:18 に更新し、pgsql の database_server_version も 18 に合わせました（92b0834）。ご指摘のとおり MySQL 側の 8 は本体と同じなので据え置いています。

開発環境が SQLite のためローカルでは検証できておらず、CI の結果で確認します。MySQL 8.4 は mysql_native_password が既定で無効なので、接続まわりで落ちるようなら追って調整します。

[nanasess]

[nit] find() の戻り値の null チェックがありません

$this->find($recommendId) は RecommendProduct|null を返しますが、直後に $Recommend->getSortno() を呼んでいます。存在しない ID を含む配列を渡すと Error: Call to a member function getSortno() on null になり、catch (\Exception $e) は \Error を捕捉しないため beginTransaction() したまま 500 になります。

ただし 本体 4.4 の CategoryController::moveSortNo() も同一パターンのため、移行 PR での退行でも規約違反でもありません。上記の moveRank() を修正される際に、ついでにガードを入れておくと堅くなる、という程度です。

$Recommend = $this->find($recommendId);
if (!$Recommend) {
    continue;
}

[ttokoro20240902]

①と同じ経路なので、ついでに入れました（78dde65）。

1 点補足で、直前の /** @var RecommendProduct $Recommend */ も削除しています。@extends AbstractRepository<RecommendProduct> で find() は RecommendProduct|null に解決されますが、@var が残っていると非 null に絞り込まれ、追加したガードが booleanNot.alwaysFalse として phpstan に検出されるためです。level 6 エラーゼロは維持しています。

[nanasess]

[nit] getName() は Symfony 3 以降どこからも呼ばれないデッドコードです

FormTypeInterface（Symfony 7.4）に getName() は存在せず、AbstractType にも実装がありません。フォーム名は AbstractType::getBlockPrefix() の既定実装が返す recommend_product で決まります。

実際、テンプレートの #recommend_product_Product は getName() が返す admin_recommend ではなく recommend_product を前提にしており、admin_recommend という文字列はリポジトリ内でこの 1 箇所にしか現れません。

属性化・型付けを一通り行ったこのタイミングで削除してしまうのが良さそうです。

[ttokoro20240902]

削除しました（92b0834）。dotani1111 さんからも同じご指摘をいただいていました。

削除後に実機のフォームを確認したところ、フィールド名は recommend_product[_token] / recommend_product[Product] / recommend_product[comment] のままで、getBlockPrefix() 由来の名前で決まっていることが裏取りできました。テンプレートの #recommend_product_Product とも整合しています。

[nanasess]

[nit] rector の対象に Tests/ が入っておらず、PHPUnit 用のセットも未適用です

withPaths() は Controller / Entity / Form / Repository / Service / PluginManager.php / Nav.php のみで Tests/ が対象外、withSets() にも PHPUnitSetList::PHPUNIT_CODE_QUALITY / PHPUNIT_110 がありません（本体 4.4 の rector.php は両方入れています）。

本 PR のテストコード自体は静的データプロバイダも withConsecutive() も使っていないため現時点で問題はありませんが、Resource/.php-cs-fixer.dist.php と phpstan.neon.dist はいずれも Tests/ を見ているので、rector だけ穴が空いている状態です。

[ttokoro20240902]

Tests/ を withPaths() に追加し、PHPUnitSetList::PHPUNIT_CODE_QUALITY / PHPUNIT_110 を有効にしました（92b0834）。

「現時点で問題はない」とのことでしたが、実際に有効化したところ rector が差分を出しました。CI が rector --dry-run をゲートにしているため適用しています:

• declare(strict_types=1) の付与
• テストクラスの final 化
• 'POST' → Request::METHOD_POST
• assertInstanceOf() の追加

いずれも本体 4.4 の tests/Eccube/Tests/ が既に同じ形になっていることを確認したうえで取り込みました。PHPUnit は 24/24 のままパスしています。

Tests/bootstrap.php のみ withSkip() に追加しました。名前空間を持たないスクリプトのため、import 整理で use ...\Dotenv; がライセンスヘッダより上に移動し、その結果 php-cs-fixer の header_comment がヘッダを二重に付与する事象が実際に発生したためです。phpstan も同ファイルを除外しているので、扱いを揃えた形になります。

[nanasess]

[nit] CLI 実行ガードがありません

本 PR で追加した Resource/.php-cs-fixer.dist.php にはガードがあり、本体 4.4 の rector.php にも同等のガードがありますが、このファイルにだけありません。

app/Plugin/ はドキュメントルート外で、かつ release.yml で配布物からも除去されるため実害はありませんが、多層防御として揃えておくのが無難です。

if (PHP_SAPI !== 'cli') {
    http_response_code(403);
    exit;
}

[ttokoro20240902]

本体 4.4 と同じガードを追加しました（92b0834）。多層防御として揃えておくべき、というご指摘に同意です。

[nanasess]

[nit] このファイルだけ runs-on: ubuntu-22.04 のまま残っています（8 行目）

main.yml は 2 ジョブとも ubuntu-24.04 に更新されていますが、release.yml は 22.04 のままです。配布パッケージ生成は tar と rm しか使わないため今すぐ壊れはしませんが、ランナーイメージの世代を揃えておかないと将来 22.04 の提供終了時にリリースだけ落ちます。

（8 行目は差分範囲外のため、本 PR で触っているこの行にコメントしています。別 PR での対応でも構いません。）

[ttokoro20240902]

別 PR でも構わないとのことでしたが、main.yml を 24.04 にしたのが本 PR なので、こちらで ubuntu-24.04 に揃えました（92b0834）。

[ttokoro20240902]

@nanasess 詳細な実機検証とレビューをありがとうございます。いただいた指摘 7 件はすべて対応し、各スレッドに個別に返信しました（78dde65 / 92b0834）。

jQuery UI の 404 について

別 PR をご提案いただきましたが、4 行の削除で本 PR の CHANGES_REQUESTED をまとめて解消できるため、こちらに含めさせていただきました（92b0834）。差分範囲外への越境になりますので、不適切であれば切り出します。

削除にあたって、ご指摘の裏取りをしています:

• 本体の html/template/admin/assets/js/vendor/jquery.ui/ は 4.1 には存在しますが 4.4 のツリーには存在しない
• admin.bundle.js のエントリ（html/template/admin/assets/js/bundle.js）が jquery-ui/ui/widgets/sortable / widget / mouse / position を require しており、default_frame.twig の <head> で読み込まれる
• 削除後の実機で jquery.ui へのリクエストが消え、typeof $.fn.sortable === 'function'、ドラッグ&ドロップでの並び替えも正常動作

なお 4.2 ブランチにも同じ 4 行が残っています（git show origin/4.2:Resource/template/admin/index.twig）。4.2 は EC-CUBE 4.2/4.3 の両対応で、両バージョンでの bundle 同梱状況を別途確認する必要があるため、そちらは本 PR では触っていません。

検証結果

phpstan level 6 エラーゼロ（baseline なし）/ php-cs-fixer 差分ゼロ / rector dry-run クリーン / PHPUnit 24 テストパス。実機は EC-CUBE 4.4 + PHP 8.2 + SQLite で、一覧・登録・編集・削除・並び替えを確認しました。

CI の DB イメージ更新（mysql:8.4 / postgres:18）のみローカル未検証です。開発環境が SQLite のため、CI の結果で確認します。

[ttokoro20240902]

@dotani1111 レビューと実機検証をありがとうございます。ご指摘の任意 2 点はどちらも対応しました。

• Resource/rector.php のライセンスヘッダを https:// に修正（92b0834）。プラグイン内の他の PHP ファイルおよび Resource/.php-cs-fixer.dist.php の $header が https なのに対し、このファイルだけ http でした。Resource/ 配下は cs-fixer の exclude に入っているため自動検出されない箇所でした。
• RecommendProductType::getName() を削除（92b0834）。nanasess さんからも同じご指摘をいただいています。削除後、フォームのフィールド名が recommend_product[...] のままであることを実機で確認しています。

[ttokoro20240902]

CI 追加修正のご報告（5817ef4）

レビュー指摘対応（78dde65 / 92b0834）をプッシュしたところ、Static Analysis ジョブが失敗しました。調査の結果、本 PR の変更が原因ではなく、本体 4.4 側の依存解決の変化によるものでしたので、併せて修正しています。

失敗内容

Setup EC-CUBE ステップ（SQLite）で以下により中断していました。

Could not create database var/eccube.db for connection named default
Operation "Doctrine\DBAL\Platforms\SQLitePlatform::getCreateDatabaseSQL" is not supported by platform.

本 PR 起因でない根拠

• 同じステップは 2026-06-25 の実行（db885ec）では success、ワークフローのコードもその後変更していません（本 PR の main.yml の差分は DB イメージのタグと database_server_version のみ）
• 静的解析ジョブは SQLite 固定でサービスコンテナを使わないため、今回の mysql:8.4 / postgres:18 更新の影響を受けません
• 原因は本体 4.4 が doctrine/dbal 4 系を解決するようになったことです。DBAL 4 の SQLitePlatform は getCreateDatabaseSQL() をサポートしません

修正内容

SQLite では DB ファイルを doctrine:schema:create が生成するため、doctrine:database:create を実行しないようにしました。本体 4.4 の unit-test.yml も sqlite3 の場合は同コマンドをスキップしており、その扱いに合わせています。MySQL / PostgreSQL のマトリクスジョブでは引き続き実行します。

レビュー範囲外の修正になりますので、別 PR に切り出すべきであればご指示ください（単一コミットなので分離は容易です）。

補足: 開発用 Docker イメージと CI で DBAL のバージョンが異なります

調査の過程で判明した点です。

	開発用イメージ (8.2-apache-4.4)	CI (fresh install)
doctrine/dbal	3.10.5	4.4.4
doctrine/orm	3.6.2	3.6.2
symfony/framework-bundle	v7.4.8	v7.4.8

ORM と Symfony は一致していますが DBAL だけ差があり、ローカルでは doctrine:database:create が成功してしまうため CI の失敗を再現できませんでした。本 PR の範囲では対応していませんが、ローカル検証と CI で挙動が食い違う要因になり得るため共有します。

最終確認結果

CI 全 19 チェック green

• PHPUnit マトリクス: 4.4 × PHP 8.2/8.3/8.4/8.5 × MySQL 8.4 / PostgreSQL 18 — 全 8 構成 pass
• Static Analysis: php-cs-fixer 差分ゼロ / rector dry-run クリーン（Tests/ を対象に追加した状態）/ phpstan level 6 エラーゼロ（baseline なし）
• CodeRabbit: pass

実機確認（EC-CUBE 4.4 + PHP 8.2 + SQLite）: 一覧・登録・編集・削除・並び替え、および並び替えエンドポイントのガード（トークンなし 403 / GET 405 / X-Requested-With なし 400 / 正常 200）。