EC-CUBE3になって大きく変わった事というと
やはりフレームワークが採用されたという事でしょうか？
フレームワークを採用する事で
ある程度、ソースの記述や実装方法を統一する事ができる為、
実装されたソースの再利用しやすさ等のメリットがあります。
ただ、自分にとって、EC-CUBE3を色々カスタマイズする上で
一番苦労している点でもあります。
フレームワークを採用した場合、
他のプロジェクトでもそうでしたが、
だいたいそのプログラムに精通している技術者ほど、
ハマる傾向があるように思われます。
あくまで個人的な見解ですが、
EC-CUBE2の技術者はPHPをバリバリ利用されていた方が多いのではないでしょうか？
私は色々ハマる原因と思われる点に、エラーメッセージがあると考えています。
通常、PHP本体の開発であれば、記述ミスがあった場合、
そのソースの行までエラーメッセージが教えてくれますが、
フレームワークを利用している場合、
実際に記述ミスしている箇所では無く、全く異なる箇所でエラーメッセージが表示されます。
これはフレームワーク本体が、各々のソースを読み込んで（インスタンス等で）メソッド等を実行する為、
仕方ないと思いますが、
かなり原因を突き止めるのに苦労します。
フレームワークにある程度、慣れてくれば、
このあたりが怪しいなど目星をつける事が出来ますが、
さわり始めの頃はストレスで頭がおかしくなりそうになります。
ここで挫折してしまう人もいるのでは無いでしょうか？
（VisualStadioに.netが出てきた時にオブジェクト指向はよく分からん！！と
言っていた人の話を思い出します。）
なので、このブログではしばらく私の開発中に/app/log/site*****.logに出力されたログとエラー原因、
対応した内容を紹介していきたいと思います。
因みにEC-CUBE3で多いエラーとしては、
画面にいきなり「システムエラーが発生しました。」と表示される場合と、
画面が真っ白になる場合があると思います。
画面が真っ白になる場合は、上記エラーログも出力されていない事が多いと思いますが、
ExceptionとしてキャッチできないPHP自身のエラーが出力されており、
WebServerのエラーログには何か出力されていると思います。
この場合、.htaccessやphp.iniで「display_errors」を変更される方もいらっしゃると思いますが、
EC-CUBEの場合、それだけではエラーは画面に表示されません。
原因は、/html/index.php 29行目に以下の記述があり、「display_errors」を無効にしています。
ini_set(‘display_errors’, ‘Off’);
その為、
ini_set(‘display_errors’, ‘On’);
に変更すれば、PHPエラーは画面に表示されるようになります。
本番運用している環境での表示はNG化と思いますが、
開発中に画面が真っ白になってお困りの方は、この設定を変更してみてください。
それでは、以下、エラーの紹介となります。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
Twig_Error_Loader: Template “******.twig” is not defined. (uncaught exception) at /var/www/html/eccube/vendor/twig/twig/lib/Twig/Loader/Chain.php line 63
こちらは******.twigが見つからないというエラーになります。
コントローラークラスを定義しているPHPファイルの
$app->renderの第1引数に渡しているパスを確認してください。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
Symfony\Component\Validator\Exception\MissingOptionsException: Either option “min” or “max” must be given for constraint Symfony\Component\Validator\Constraints\Length (uncaught exception) at /var/www/html/eccube/vendor/symfony/validator/Constraints/Length.php line 53
こちらはFormType関連のクラスを定義するPHPファイルで
FormBuilderInterfaceに入力項目の制限を指定する際のmin、maxに空文字を渡した場合に発生しました。
以下の記述の場合、$app[‘stext_len’]が$app[‘config’][‘stext_len’]で記述する必要がありました。
$builder->add(‘hogehoge’, ‘text’, array(
‘label’ => ‘ほげほげ’,
‘constraints’ => array(
new Assert\Length(array(
‘max’ => $app[‘stext_len’],
)),
),
))
今回はLength制約の箇所のエラーでしたが、
Symfony\Component\Validator\Exception\に続きエラーログの場合、
FormTypeにかかわるエラーの可能性が高いと思います。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
InvalidArgumentException: Class “\Plugin\******\Controller\RequestAController” does not exist. (uncaught exception) at /var/www/html/eccube/vendor/symfony/http-kernel/Controller/ControllerResolver.php line 171
ServiceProviderルーティングに追加したコントローラーへのパスに誤りがある場合に
発生したエラーになります。
以下のRequestAControllerが存在しないファイル名になっていました。
app->match(‘/plugin/******/Request ‘,
‘\Plugin\******\Controller\RequestAController::index’)
->value(‘id’, null)->assert(‘id’, ‘\d+|’)
->bind(‘******_request’);
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
::indexのメソッド名が間違っている場合は、以下のようなエラーが出力されます。
InvalidArgumentException: Controller “\Plugin\******\Controller\RequestController::index2” for URI “/admin/plugin/******/Request” is not callable. (uncaught exception) at /var/www/html/eccube/vendor/symfony/http-kernel/Controller/ControllerResolver.php line 90
以上、いくつか実際に開発中に表示されたエラーメッセージと
その原因の紹介になります。
今後も発生したエラーメッセージとそれに対応する方法を紹介していきたいと思います。
