2016-05-03 8 views
0

私はスリムなフレームワークで開発しています。デバッグを有効にしていますが、エラーが発生した場合はいつでも有効にしています。アプリケーションはhttp 500の内部エラー発生状態に入りますが、実際にエラーが発生した原因と原因を表示しません。エラーの原因を確認するにはどうすればよいですか?ここでスリムアプリケーションは、デバッグを有効にしても500エラーを表示します

は私のコードです:

require 'lib/vendor/PHPMailer/PHPMailerAutoload.php'; 
require 'lib/init.php'; 
require 'lib/Slim/Slim.php'; 

date_default_timezone_set('UTC'); 

use lib\Slim\Middleware\SessionCookie; 

\Slim\Slim::registerAutoloader(); 
$app = new \Slim\Slim([ 
    // cookie encryption (strongly recommend) 
     'log.level' => \Slim\Log::DEBUG, 
    'cookies.encrypt' => true, 
    'cookies.secret_key' => 'put your secret key', 
    // session config 
    'sessions.driver' => 'database', // or database 
    //'sessions.files' => __DIR__ . '/../sessions', // require mkdir 
    'sessions.table' => 'sessions', // require create table# 
     'debug' => true, 
]); 


$app->run(); 

任意の提案?

+0

すべてのエラーメッセージを表示するように開発ボックスを設定したことを確認してください。 PHPコードの実行に失敗した場合は、Slimを使用して報告することはできません。 –

+1

Webサーバーのログファイルを確認してください。私はそれがそこにあるだろうという気持ちを持っています...私はそれがあなたのセッションクッキーの使用と関係があると推測しています。 – geggleto

+0

Slimフレームワークから何かを使用する前に**オートローダーを登録してはいけませんか? – Pevara

答えて

0

スリムでデバッグを有効にすると、致命的な解析エラーは表示されません。この構成では、例外のエラーハンドラが有効になります。したがって、あなたのライブラリの1つが例外をスローすると、スリムはそれらをWeb用の読みやすい方法でレンダリングします。プロダクションシステムで、デバッグを無効にしたい場合は、例外のスタックトレースによって潜在的なセキュリティリークが明らかになる可能性があります。

コードを見ると、ライブラリの自動読み込みと管理にhttps://getcomposer.org/を使用することをおすすめします。スリム3の拡張機能を管理することは、確かに少ないです。

エラー500erについては、useが間違っていると思います。しかし、サーバーのエラーログを調べると、エラーの場所が明らかになるはずです。

コマンドラインで、簡単な解析エラーを見つけるためにphp -l filename.phpを試すことができます。

関連する問題