🧑🏼‍💻技術ブログ

Laravel Project 作成後、最初に行う設定

  1. TOP
    2. ›
  2. Laravel
    3. ›
  3. Laravel Project 作成後、最初に行う設定

既存プロジェクトを clone する場合ではなく、 composer create-project を使用してプロジェクトを開始する場合に、最初にやっておいたほうが良い設定の備忘。

タイムゾーン

デフォルトでは UTC になっているため、 Asia/Tokyo に直す。

config/app.php の設定が一番重要で、make:migration で生成されるファイルに付与される日時や データベースの Timestamp型に挿入される日時は、ここの設定を正しくしておかないと9時間前の日時になってしまう。

config/app.php
    'timezone' => 'Asia/Tokyo', // UTC から変更

config/database.php にもタイムゾーンの設定がある。しかし、こちらはMySQL側の設定を UTC のまま運用する場合にのみ必要なもので、MySQL側をJST に修正して運用するならば、むしろやる必要はない。

config/database.php
        'mysql' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            (...略...)
            'timezone' => 'Asia/Tokyo', // MySQL側の設定により必要か不要かが異なる
        ],

つまり、 Laravel側に設定を追加するか、それともMySQL側の修正をするか、どちらか片方のみを取ることになる。どちらが良いかは、インフラでできる設定はなるべくインフラでやるべきか、それともアプリケーションでできる設定はなるべくアプリケーションでやるべきか、自分もしくはプロジェクトがどちらの考え方を取るかで決めれば良い。

言語

デフォルトではバリデーションエラーのメッセージなどが英語で表示されるようになっているので、これを日本語に変更する。

config/app.php
    'locale' => 'ja',

    (...略...)

    'fallback_locale' => 'ja',

    (...略...)

    'faker_locale' => 'ja_JP',
  • locale: アプリケーション全般に影響する
  • fallback_locale: locale に記載した言語や、処理の中で動的に言語を変える場合に選択した言語が、存在しないものであるならばここで指定した言語が使用される
  • faker_locale: Faker により生成されるダミーデータの氏名や住所の形式に影響する

上記の通り、デフォルトでは app/config.php に言語設定がベタ書きとなっている。しかし、多言語対応を前提にするならば、この設定を .env 経由で呼び出すように修正して環境ごとに言語を変更できるようにしたり、あえて en および en_US のままにしておいて ユーザの操作によって動的に切り替えができるように実装したり、ということも視野に入れても良いのかもしれない。

エラーページの雛形の作成

ほとんどのWebアプリケーション開発において、エラー発生時に備えてデザインされたエラーページを用意するので、その雛形を作成する。

$ php artisan vendor:publish --tag=laravel-errors

これにより resources/views/errors およびその内部に各種エラーページの雛形が作成される。

Method Not Found エラーの隠蔽

Laravel では .env 内 の APP_ENV の値によって、例外発生時のレスポンスが次のように変化する。

  • local ならば stack trace を返す
  • production ならば 500 error を返す

つまり、 .env にて本番環境と指定しならば、 Exception の内容を詳細にユーザに知らせないようにしてくれる。

しかし、Laravel の一部のバージョンでは、存在しないメソッドのルーティングにアクセスした場合に、APP_ENV=production にしていたとしても Action Facade\Ignition\Http\Controllers\ShareReportController not defined という Exception の stack trace を返してしまうバグがある。これはセキュリティ的に宜しくない（URLを手当たり次第スキャンするような攻撃を受けた場合、メソッドを変えれば有効なURLであるという情報を与えてしまう）ため、Exceptionではなく 404エラー（などの無難なエラーページ）を返すようにしておいた方が良い。

ちなみにこのエラーは Laravel 9.x では The server returned a "405 Method Not Allowed". というシンプルな表示に変わり、 stack trace が表示されることがなくなった。それでもメソッドを変えれば有効なURLであるという情報を与えてしまうことに変わりはないため、結局は404エラーなどを返すようにしておくに越したことはないはず。

具体的な手順

まず、下記コマンドで、エラーページの雛形を作成する。（エラーページの雛形の作成 の項で既に実施済みであれば、このコマンドの実行は不要）

$ php artisan vendor:publish --tag=laravel-errors

次に、 app/Exceptions/Handler.php に次の関数を追加する。

app/Exceptions/Handler.php
public function render($request, Throwable $e)
    {
        if ($e instanceof \Symfony\Component\HttpKernel\Exception\MethodNotAllowedHttpException) {
            return abort(404, 'MethodNotAllowedHttpException');
        }
        return parent::render($request, $e);
    }

動作確認

routes/web.php に次のルーティングを追記した上で、普通にブラウザから /post にアクセスする。この状態で404エラー画面が表示されていれば、正しく隠蔽できている、ということになる。

routes/web.php
// post only のルーティングを行い、ここに get でアクセスする
Route::post('post',  function () {});

VSCode用：構文解析の精度向上用ヘルパーを作成

VSCode を使用し PHP Intelephense を利用する場合に、以下手順でへルパーを作成しておく。

$ composer require --dev barryvdh/laravel-ide-helper`
$ php artisan ide-helper:generate

これにより、 以下のメリットを得ることができる。

  • （エラーでは無いにもかかわらず）Syntax Error と表示されてしまう箇所でエラー表示が消える
  • コーディング時の補完機能がより強化される
執筆日：
本記事のタグ