▼テンプレート
[EC-CUBE]4.0.6
[レンタルサーバ]さくらのレンタルサーバー

4.0.6→4.1.0のアップデートをプラグインで行ったところエラーが表示されてサイトが開けなくなってしまいました。

アップデート操作を行う前のファイルチェックなどには問題は無く、そのままアップデートを実行したところ以下のとおりエラーが表示されています。

何かのファイルが無いと言われているようなのですが、他にも何か関係しているのかなど、ご存じの方いらっしゃいましたらご教授いただけないでしょうか。

関係あるかどうかはわかりませんが、管理画面から削除できなかったプラグインをデータベースから直接削除したことがあります。

https://xoops.ec-cube.net/modules/newbb/viewtopic.php?viewmode=flat&order=ASC&topic_id=26643&forum=16

どうぞよろしくお願いいたします。


エラー内容


Fatal error: Uncaught Symfony\Component\DependencyInjection\Exception\RuntimeException: Cannot autowire service "Plugin\ASJPayment\ASJPaymentEvent": argument "$session" of method "__construct()" references class "Symfony\Component\HttpFoundation\Session\Session" but no such service exists. Try changing the type-hint to "Symfony\Component\HttpFoundation\Session\SessionInterface" instead. in /home/MyHP/www/testweb/files/vendor/symfony/dependency-injection/Compiler/DefinitionErrorExceptionPass.php:54 Stack trace: #0 /home/MyHP/www/testweb/files/vendor/symfony/dependency-injection/Compiler/AbstractRecursivePass.php(82): Symfony\Component\DependencyInjection\Compiler\DefinitionErrorExceptionPass->processValue(Object(Symfony\Component\DependencyInjection\Definition), true) #1 /home/MyHP/www/testweb/files/vendor/symfony/dependency-injection/Compiler/DefinitionErrorExceptionPass.php(32): Symfony\Component\DependencyInjection\Compiler\AbstractRecursivePass->processValue(Array, true) #2 /home/MyHP/www/testweb/files/vendor/s in /home/MyHP/www/testweb/files/vendor/symfony/dependency-injection/Compiler/DefinitionErrorExceptionPass.php on line 54

別スレッドでプラグインが何か邪魔をしているのではというご指摘をいただきましたので、該当すると思われるプラグインを削除して再度アップデートを行ってみましたがまた別のエラーが出ました。


Fatal error: Uncaught Symfony\Component\DependencyInjection\Exception\RuntimeException: Cannot autowire service "Plugin\SimpleMaintenance\Repository\SimpleMConfigRepository": argument "$registry" of method "__construct()" references class "Symfony\Bridge\Doctrine\ManagerRegistry" but no such service exists. Try changing the type-hint to "Doctrine\Persistence\ManagerRegistry" instead. in /home/home/www/testweb/files/vendor/symfony/dependency-injection/Compiler/DefinitionErrorExceptionPass.php:54 Stack trace: #0 /home/home/www/testweb/files/vendor/symfony/dependency-injection/Compiler/AbstractRecursivePass.php(82): Symfony\Component\DependencyInjection\Compiler\DefinitionErrorExceptionPass->processValue(Object(Symfony\Component\DependencyInjection\Definition), true) #1 /home/home/www/testweb/files/vendor/symfony/dependency-injection/Compiler/DefinitionErrorExceptionPass.php(32): Symfony\Component\DependencyInjection\Compiler\AbstractRecursivePass->processValue(Array, true) #2 /home/home/www/testweb/files/vendor/symf in /home/home/www/testweb/files/vendor/symfony/dependency-injection/Compiler/DefinitionErrorExceptionPass.php on line 54



ページのURLは
/eccube_updater_406_to_410/complete
となっているので完了の時点で何かエラーが出ているのかなと思うのですが良く分かりません。

プラグイン実行前のファイルの確認の時点では問題ないと出るので実行するのに何故毎回エラーになるのでしょうか？
アップデート作業の前にバックアップを取る以外で、エラーを未然に察知する？気づけるような何か手順のようなものはあるのでしょうか。

プラグインでエラーが出る場合は手動でアップデートするしかないのでしょうか。
以前別のバージョンの時にもエラーが出て結局手動でアップデートしたという経緯があるのですが、手動でのアップデートでは問題なくアップデートできるのにプラグインだとエラーが出る原因は何なのでしょうか。

その他にもそもそもこういった作業を誰かに委託したいと思った時にどこに相談したら良いのか等の情報をご存じでしたらこちらも併せて教えていただければ幸いです。

どうぞよろしくお願いいたします。

ASJPaymentが４．１に対応してないのではないでしょうか。。

----------------
EC-CUBEのカスタマイズ、トラブル解決承ります
お気軽にお問い合わせ下さい
https://www.ec-cube.net/integrate/partner/partner.php?partner_id=690

ご返信いただきありがとうございます。

こちら最初にエラーが出た際に別スレッドにて同様のご指摘をいただきましたので
2回目の作業の際には干渉を避けようと該当プラグインを管理画面から一旦アンインストールして作業を行ったのですが
アンインストールだけでなく、アンインストール後にそもそもファイルごとサーバー上から削除する必要があるということでしょうか。

アップデートの際の順番も気になっていて
本体アップデートの前に、アップデート予定のバージョンに対応しているプラグインはアップデートを済ませておく
対応していない場合はアンインストール（削除）してから本体アップデートを行う
という感じで行う必要があるということでしょうか？

本体アップデートの前に、アップデート予定のバージョンに対応しているプラグインはアップデートを済ませておく
対応していない場合はアンインストール（削除）してから本体アップデートを行う

はい、そうです。

----------------
EC-CUBEのカスタマイズ、トラブル解決承ります
お気軽にお問い合わせ下さい
https://www.ec-cube.net/integrate/partner/partner.php?partner_id=690

ご返信いただきありがとうございます。
以前からずっとモヤモヤしていたのでスッキリしました。

しかしそうなるとアップデートに対応されていないプラグインを使用していた場合、アップデート後はそれが使えなくなってしまうということになりますね。
脆弱性の問題などの緊急時を除いて、できるだけ使っているプラグインがアップデートに対応してくれてからアップデートを行いたいと思いました。

そして本体アップデートの件なのですが、あの後またテスト環境を再構築しなおしてプラグインでのアップデートを行おうとしたところ、今度は管理画面には406to410のプラグインはインストール済みと出ているのに、データベースにもファイルにもプラグインが存在しない、ということが起こっています。

自分でひとつ気になったのは、テスト環境用にオーナーズストアで認証キーを発行しており、それをテスト環境でずっと使いまわしていたことです。

前回のテスト（プラグインでのアップデート失敗）の際に使っていたのもその認証キーなので、ファイルにもデータベースにも在していないのにインストール済になっているのかと思ったのですが、この認識であっているでしょうか。

そもそもの話なのですが、認証キーの位置づけが良く分かっていないのですが、テスト環境を用意した時に本番環境とは違う認証キーが入力されているように思うのですが、あれをそのまま使ってテストするのが正しいのでしょうか。

またご教授いただければ幸いです。
どうぞよろしくお願いいたします。

> しかしそうなるとアップデートに対応されていないプラグインを使用していた場合、アップデート後はそれが使えなくなってしまうということになりますね。

もちろんそうです。
4.0と4.1は非互換な部分がありますので、対応していないものがあれば動きません

> そして本体アップデートの件なのですが、あの後またテスト環境を再構築しなおしてプラグインでのアップデートを行おうとしたところ、今度は管理画面には406to410のプラグインはインストール済みと出ているのに、データベースにもファイルにもプラグインが存在しない、ということが起こっています。

データベース、もしくはcomposerを使いまわしているとそのようなことになります

> 前回のテスト（プラグインでのアップデート失敗）の際に使っていたのもその認証キーなので、ファイルにもデータベースにも在していないのにインストール済になっているのかと思ったのですが、この認識であっているでしょうか。

間違っています


> そもそもの話なのですが、認証キーの位置づけが良く分かっていないのですが、テスト環境を用意した時に本番環境とは違う認証キーが入力されているように思うのですが、あれをそのまま使ってテストするのが正しいのでしょうか。

認証キーは任意に入力可能なので本番環境と同じもののほうがいいと思います

----------------
EC-CUBEのカスタマイズ、トラブル解決承ります
お気軽にお問い合わせ下さい
https://www.ec-cube.net/integrate/partner/partner.php?partner_id=690

ご返信いただきありがとうございます。

＞データベース、もしくはcomposerを使いまわしているとそのようなことになります

使いまわす、ということが良く分からないのですが、テスト環境は本番環境をコピーして別のサーバーで作り直しているのですが、これが使いまわしということになるのですか？
テスト環境を再現するのにコピー以外の方法が思いつかないのですが、これが問題であるとしたらこの「使いまわし」を避けるにはどうしたら良いのでしょうか。
また、現在のこのファイルもないしインストールもされていないプラグインがインストールされている、という不具合を解消する方法はありますか？

＞認証キーは任意に入力可能なので本番環境と同じもののほうがいいと思います

認証キーによってプラグインの状態を管理しているものかと思っていたので別にしていたのですが、そうではないということなのですね。

教えていただいた通り本番環境と同じものを入力してみましたが、本番環境とインストールされているプラグインの状態も数も違うという結果になっています。
これが使いまわしの影響なのでしょうか。

本体をプラグインでアップデートしたかったのですが、テスト環境でそれが用意できそうもないので（インストール済みになっているのにファイルが無いので）諦めて手動でアップデートすることも考えているのですが、このような状態でテストを行ったところでちゃんとした結果？が出るのかどうかも心配になりました。

よろしければまたご教授いただければ幸いです。
どうぞよろしくお願いいたします。

> テスト環境を再現するのにコピー以外の方法が思いつかないのですが、これが問題であるとしたらこの「使いまわし」を避けるにはどうしたら良いのでしょうか。

テスト環境を作るのに、本番を完全にコピーすれば本番と違った状態になるということはないと思います。
まずそこが出来ていないのではないでしょうか

----------------
EC-CUBEのカスタマイズ、トラブル解決承ります
お気軽にお問い合わせ下さい
https://www.ec-cube.net/integrate/partner/partner.php?partner_id=690

ご返信いただきありがとうございます。

ご指摘いただいて確認したところ、本番環境とテスト環境でデータベースのサイズに違いが出ていました。
データベースのコピーにつきましてはMySQLのエクスポートとインポートの機能を利用しており、エクスポートしたSQLはそのままだと大きすぎてインポートできないので圧縮してインポートしているのですが、以前分割してインポートした際に、圧縮せずにインポートしたテーブルのサイズは変わらないのに圧縮してインポートしたテーブルのみサイズが大きくなるということが起こっていたので、今回についても同じことが起こっているのかと思っています。

しかし原因が分からないのでそれについて現在調べているところです。
こちらまた環境を整えられ次第ご相談させてください。
どうぞよろしくお願いいたします。