EC-CUBE4.3 PHP PHPエラー Twig

EC-CUBE 4.3はPHP 8.5で動くか — Twigで2回つまずいた記録

検証用のデモ環境を立てようとしたサーバーにはPHP 8.5.1しか入っていませんでした。EC-CUBE 4.3の公式対応はPHP 8.1〜8.3。それでも設置してみたところ、インストールは素通りし、最初のページ表示で500エラーになりました。つまずきの原因はすべてTwigで、Twigの更新と本体2ファイルの修正で「画面が立ち上がる」ところまでは到達できました。全機能を検証したわけではありません（未検証の範囲は文末に書きます）。EC-CUBE 4.3.1-p1とPHP 8.5.1、MariaDB 10.5で確認した記録です。

インストールは通ってしまう — 要件表とcomposer制約は別物

EC-CUBE 4.3のcomposer.jsonのPHP制約は^8.1です。これは「8.1以上9未満」の意味なので、公式対応表にない8.5でもcomposerは止めてくれません。

$ composer create-project ec-cube/ec-cube ec-demo "4.3.1-p1"
（略）
PHP Deprecated:  Twig\Extra\Intl\IntlExtension::formatDate(): Implicitly marking
parameter $locale as nullable is deprecated, ...
  > Finished Successful!
Executing script cache:warmup --no-optional-warmers [OK]

Deprecated警告は大量に出ますが、インストールもbin/console eccube:installも正常終了します。問題はブラウザで開いた瞬間で、フロントも管理画面も「システムエラーが発生しました。」の500になりました。

エラー1: コンパイル済みTwigテンプレートがPHPの構文エラーになる

ログ（var/log/prod/）に残っていたのはTwigの例外ですが、掘るとPHPのParseErrorに行き着きます。

ParseError {
  #message: "syntax error, unexpected token ":""
  #file: "/var/www/ec-demo/var/cache/prod/twig/43/43cb6ae3....php"
  › $context["Categories"] = twig_get_attribute($this->env, $this->source,
      $this->extensions['Eccube\Twig\Extension\RepositoryExtension']
      ->{closure:Eccube\Twig\Extension\RepositoryExtension::getFunctions():35}("Eccube\\Entity\\Category"), ...

注目は->{closure:...getFunctions():35}の部分です。PHP 8.4からクロージャの内部名が{closure}から{closure:クラス::メソッド():行番号}という形式に変わりました。EC-CUBE 4.3同梱のTwig 3.8はテンプレートをPHPコードにコンパイルする際、クロージャで定義されたTwig関数の呼び出しにこの内部名をそのまま埋め込みます。名前にコロンが入るようになったため、生成されたPHPコードが構文エラーになる——古いTwigをPHP 8.4以降で動かすと起きる非互換です。

対処はTwig本体の更新です。新しいTwigはコード生成がこの名前変更に対応しています。

$ composer update twig/twig twig/extra-bundle twig/intl-extra --with-all-dependencies
  - Upgrading twig/twig (v3.8.0 => v3.28.0)

ひとつ補足すると、最初は変更幅を抑えようとtwig/twig:~3.11.0を指定したのですが、composerのセキュリティ監査（audit）に「既知の脆弱性がある」と弾かれました。中途半端に古いバージョンへは上げられず、実質的に最新の3.28一択でした。

エラー2: Twigを上げると今度はEC-CUBE本体が非互換になる

Twig 3.28でキャッシュを作り直すと、次はEC-CUBE本体のクラスがFatal errorになりました。

PHP Fatal error:  Declaration of Eccube\Twig\Template::getTemplateName() must be
compatible with Twig\Template::getTemplateName(): string
in /var/www/ec-demo/src/Eccube/Twig/Template.php on line 48

新しいTwigはTwig\Templateの抽象メソッドに戻り値型が付き、さらに描画がgenerator方式になってdoDisplay()はiterableを返す設計に変わっています。EC-CUBEがこれを継承しているsrc/Eccube/Twig/Template.phpのシグネチャを親に合わせます。

public function display(array $context, array $blocks = []): void
{ /* 中身は変更なし */ }

public function getTemplateName(): string
{
    return '';
}

public function getDebugInfo(): array
{
    return [];
}

protected function doDisplay(array $context, array $blocks = []): iterable
{
    return [];   // Twig 3.12以降のgenerator方式に合わせてiterableを返す
}

public function getSourceContext(): Source
{
    return new Source('', $this->getTemplateName(), '');
}

削除された \twig_include() を呼ぶ箇所が1つ残っている

Twigは3.12でtwig_include()などのグローバル関数を削除し、CoreExtensionのメソッドに移しました。EC-CUBE本体がこの旧関数を呼んでいないかgrepすると、1箇所だけ見つかります。

$ grep -rn "\\\\twig_include" src/Eccube --include="*.php"
src/Eccube/Twig/Extension/IgnoreTwigSandboxErrorExtension.php:59:
            return \twig_include($env, $context, $template, ...);

ここはエラーが出るのを待たず、新旧どちらのTwigでも動くフォールバックにしておきました。

// Twig 3.12でグローバル関数 \twig_include() が削除され
// CoreExtension::include() に移動したため、両対応にしている。
if (\function_exists('twig_include')) {
    return \twig_include($env, $context, $template, $variables,
        $withContext, $ignoreMissing, $sandboxed);
}

return \Twig\Extension\CoreExtension::include($env, $context, $template,
    $variables, $withContext, $ignoreMissing, $sandboxed);

結果: 立ち上がりはした — 確認できたのはここまで

以上の3点（Twig更新＋本体2ファイル修正）でキャッシュのwarmupが通りました。実際に確認できたのは、フロントのトップページと商品詳細ページの表示、管理画面へのログイン、ダッシュボードの表示までです。

PHP 8.5.1で立ち上がったEC-CUBE 4.3.1-p1の管理画面ダッシュボード
PHP 8.5.1で立ち上がったEC-CUBE 4.3.1-p1の管理画面

未検証の範囲と、本番でこの構成を選ぶべきかどうか

強調しておきたいのは、これは「とりあえず立ち上がった」報告であって「PHP 8.5で問題なく動く」という報告ではないことです。受注フロー・決済・メール送信・会員登録・プラグインの動作は検証していません。特にTwigを3.8から3.28まで一気に上げているので、テンプレートまわりの細かい挙動やプラグインとの相性は、実際に使う機能ごとに確かめる必要があります。

加えて、今回の修正はEC-CUBE本体のファイルを直接書き換えているため、本体のバージョンアップで消えますし、公式対応外のPHPで起きた不具合はサポートやプラグイン互換の保証範囲外です。本番環境は公式対応のPHP 8.1〜8.3で組むのが正解です。

それでも、検証環境やデモのように「そのサーバーにはPHP 8.5しか入っていない」場面で立ち上げたいときには、この記録がそのまま使えるはずです。つまずきどころがTwigに集中していることが分かっていれば、エラーログに{closure:やmust be compatibleが出た時点で原因の見当が付きます。

日本発！ECオープンプラットフォーム「EC-CUBE」 EC-CUBEゴールドパートナー EC-CUBEは株式会社イーシーキューブの商標です
ECCUBE制作トップへ

EC-CUBEに関するお問い合わせ


    [重要]現在公式にセキュリティサポートが切れていないPHPは8.1以上、MySQLは8.0以上で、対応しているEC-CUBEバージョンは4.2以上です。古いEC-CUBEを使っている方は適切なタイミングでバージョンアップをご検討ください。

    EC-CUBEバージョンアップ

    関連するカスタマイズ

    1. プラグインの新規アップロードができない場合の対処法 プラグインの新規アップロードができず、何のエラーも出ず分かりにくいなぁと思ったので情報シェアします。 せめてインストール失敗しましたというメッセージぐらいは欲しかった・・・。 サーバーのエラーログを確認すると次のようなエ […]...
    2. 受注マスターに項目追加・メニュー追加 EC-CUBE3の受注マスターにはもともと受注日、名前、注文番号などが一覧表示されています。 メニューには編集や削除などが並んでいますが、この部分をカスタマイズして業務効率化したいというご要望は多いです。 受注関係は毎日 […]...
    3. オリジナルの404、403エラーページを表示する方法 EC-CUBE３では.htaccessにて実際にファイルが存在しない場合全てindex.phpへリライトを行っているため、基本的に404エラーが発生しません。 しかし想定していないURLへのアクセスには404 Not F […]...