L8.x on ララジャパン

コマンドにプログレスバーを追加する

Wed, 29 Nov 2023 00:25:29 +0900

一度に大量のデータを更新する必要がある時などはArtisanコンソールコマンドでバッチを作成して実行します。その際に更新に時間が掛かって途中で何も出力が無いと処理が正常に進んでいるのか不安になってしまいます。そんな時はプログレスバーを表示すれば進捗が確認できて便利です。

演習コマンド

Laravelにデフォルトで用意されているusersテーブルを用いて演習用のコマンドを作成し、使い方を確認していきます。作成するのは登録されているemailからユーザー名部分を抜き出し、nameを上書きするコマンドです。コマンドの実行には更新対象となるusersのレコードが必要となるので先にダミーレコードを準備しましょう。DatabaseSeeder.phpのrun()を以下の様に編集してください。

database/seeders/DatabaseSeeder.php

namespace Database\Seeders;

use Illuminate\Database\Seeder;

class DatabaseSeeder extends Seeder
{
    /**
     * Seed the application's database.
     */
    public function run(): void
    {
        \App\Models\User::factory(1000)->create();
    }
}

そして以下を実行するとusersに1000件のダミーレコードが作成されます。

$ php artisan db:seed

続いて演習用のUserNameUpdateコマンドを作成します。

$ php artisan make:command UserNameUpdate

UserNameUpdateコマンドは以下の様にしました。まだプログレスバーを実装する前の状態です。

app/Console/Commands/UserNameUpdate.php

namespace App\Console\Commands;

use App\Models\User;
use Illuminate\Support\Str;
use Illuminate\Console\Command;

class UserNameUpdate extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'app:user-name-update';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'nameをemailのユーザー名に更新する';

    /**
     * Execute the console command.
     */
    public function handle()
    {
        $this->info('ユーザ名の更新を開始します。');

        $users = User::all();

        $users->each(function ($user) use (&$updated) {
            $user->name = Str::before($user->email, '@');
            $user->save();
            $updated++;
        });

        $this->info('ユーザ名の更新が完了しました。（更新件数：' . $updated . '）');
    }
}

以下を実行するとemailの’@‘より前の部分をnameに上書きします。

$ php artisan app:user-name-update
ユーザ名の更新を開始します。
ユーザ名の更新が完了しました。（更新件数：1000）

コマンド実行後にtinkerで以下を実行してみて下さい。ランダムにピックアップした２０件ですが、意図通りに更新されているのが確認できると思います。

> User::take(20)->inRandomOrder()->pluck('email', 'name');
= Illuminate\Support\Collection {#7081
    all: [
      "marjorie.hagenes" => "marjorie.hagenes@example.com",
      "owen.sipes" => "owen.sipes@example.org",
      "leann10" => "leann10@example.net",
      "amy21" => "amy21@example.net",
      "brooks.leffler" => "brooks.leffler@example.org",
      "arianna89" => "arianna89@example.com",
      "ledner.teagan" => "ledner.teagan@example.net",
      "axel17" => "axel17@example.org",
      "ykoepp" => "ykoepp@example.com",
      "rita19" => "rita19@example.net",
      "genevieve98" => "genevieve98@example.com",
      "nathen.goldner" => "nathen.goldner@example.net",
      "xjones" => "xjones@example.org",
      "assunta57" => "assunta57@example.com",
      "swift.vena" => "swift.vena@example.net",
      "senger.maybell" => "senger.maybell@example.org",
      "jace.willms" => "jace.willms@example.com",
      "stephanie.berge" => "stephanie.berge@example.org",
      "acremin" => "acremin@example.org",
      "yaufderhar" => "yaufderhar@example.org",
    ],
  }

一度コマンドを実行してnameが更新されてしまったので、以下を実行してダミーデータを作り直しておきましょう。

$ php artisan migrate:fresh --seed

withProgressBar()

それでは先ほどのコマンドを修正してプログレスバーを表示するようにしてみましょう。プログレスバーを表示するにはwithProgressBar()を使用します。withProgressBar()は第一引数にループ処理可能な値（iterable）を、第二引数にループ実行する処理をクロージャで指定します。UserNameUpdateコマンドに実装した例が以下になります。

app/Console/Commands/UserNameUpdate.php

...
    public function handle()
    {
        $this->info('ユーザ名の更新を開始します。');

        $users = $this->withProgressBar(User::all(), function (User $user) {
            $user->name = Str::before($user->email, '@');
            $user->save();
            usleep(10000);
        });

        $this->info('');    // 改行用
        $this->info('ユーザ名の更新が完了しました。（更新件数：' . $users->count() . '）');
    }
...

コマンドを実行するとバーが表示され、User::all()の総数である１０００件の処理が完了すると100%となるようにループ毎にゲージが溜まっていきます。

$ php artisan app:user-name-update
ユーザ名の更新を開始します。
1000/1000 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%
ユーザ名の更新が完了しました。（更新件数：1000）

今回ダミーデータを1000件用意しましたが、私の環境では処理が一瞬で終了してしまい、プログレスバーのゲージが蓄積していく様子が確認できなかったのでusleep()を挟みループ毎に0.01秒スリープするようにしました。また、プログレスバー表示後に改行コードが含まれておらず、続く「ユーザ名の更新が完了しました。・・・」の表示がプログレスバーと同じ行に表示されてしまう為、$this->info(’’)で改行を挟みました。

createProgressBar()

プログレスバーを表示するもう１つの方法としてcreateProgressBar()を使ってProgressBarインスタンスを生成する方法があります。こちらは前項のwithProgressBar()よりもバーを表示するタイミングやゲージを進めるタイミングを細かくコントロールできます。以下、UserNameUpdateコマンドに実装した例です。

app/Console/Commands/UserNameUpdate.php

...
    public function handle()
    {
        $this->info('ユーザ名の更新を開始します。');

        $users = User::all();

        $bar = $this->output->createProgressBar($users->count());
        $bar->start();

        foreach ($users as $user) {
            $user->name = Str::before($user->email, '@');
            $user->save();
            usleep(10000);
            $bar->advance();
        }

        $bar->finish();

        $this->info('');
        $this->info('ユーザ名の更新が完了しました。（更新件数：' . $users->count() . '）');
    }
...

今回のUserNameUpdateコマンドの様に取得したデータに対してループでシンプルな処理を実行するパターンでは前項で紹介したwithProgressBar()の方がコードが簡潔ですね。ループ内で実行する処理が複雑でクロージャに渡す変数が多くなってしまう様なケースではcreateProgressBar()を使用するのが良いかもしれません。因みにですが、withProgressBar()はLaravel8から追加された関数の様です。Laravel7以前はcreateProgressBar()のみでした。

名前付きエラーバッグによるエラー管理

Wed, 24 May 2023 08:56:03 +0900

１つのページに複数のフォームが存在する場合、エラーの管理が煩雑になりがちです。そんな時は名前付きエラーバッグを使ってフォーム毎にエラーを分けると管理しやすいです。

煩雑になってしまう例

複数のフォームがある場合にエラー管理が煩雑になる、とはどんな時でしょうか？例を用いて解説します。

以下の様な会員情報の編集ページがあったとします。

フォームが２つあり、それぞれ別のルートにPOSTされます。

ここでプランナーさんから

「バリデーションエラー発生時に警告文をフォーム毎に文言を変えて表示したい！」

とリクエストが来たとします。つまり、ユーザ情報フォームに関する何かしらのエラーがあれば以下を表示

そして、会社情報フォームに関する何かしらのエラーがあれば以下を表示

何かしらのエラーがあれば、、、と言う条件はフォームが１つであれば簡単で

@if ($errors->any())
... 警告文
@endif

とできますが、フォームが複数ある場合はどうすれば良いでしょうか？ sessionに判別用の値をセットする？それともリダイレクト元のルートで判別する？やり方は色々あると思いますが、名前付きエラーバッグを使うとスマートにできます。

名前付きエラーバッグとは？

その名の通り、エラーバッグに任意の名前を付けたものです。（ここで言うエラーバッグとは、blade側でエラーを参照する際に使う $errors です）

フォーム毎にエラーバッグの名前を分けて付けることで、エラーを分けて管理できるようになります。

エラーバッグに名前をつける

エラーバッグに名前を付けるにはバリデーション時にvalidateWithBag()を使用します。例えば、前項のフォームのバリデーションで以下のようにしています。

ユーザ情報フォーム側では、エラーバッグ名をuserとして第一引数に指定しています。

$validated = $request->validateWithBag(
    'user',                                       // ←エラーバッグ名
    ['name' => 'required'],
    ['name.required' => '名前を入力してください。']
);

会社情報フォーム側では、エラーバッグ名をcompanyとして指定しています。

$validated = $request->validateWithBag(
    'company',                                    // ←エラーバッグ名
    ['company_name' => 'required'],
    ['company_name.required' => '会社名を入力してください。']
);

また、withErrors()を使ってリダイレクトにエラーをセットする際は第二引数にエラーバッグ名を指定します。

return back()->withErrors($validator, 'user')->withInput();

名前付きエラーバッグからエラーを参照する

エラーバッグ名の指定ができたので、今度はblade側でエラーを参照してみましょう。任意の名前のエラーバッグからエラーを参照する際は、 $errors->エラーバッグ名->first(…)などとします。従って、

// ユーザ情報フォームのエラーを取得する場合、
{{ $errors->user->first('name') }}

// 会社情報フォームのエラーを取得する場合、
{{ $errors->company->first('name') }}

// errorディレクティブを使う場合は第二引数にエラーバッグ名を指定
@error('name', 'user')
    {{ $message }}
@enderror

また、前項の警告文の様に、ユーザ情報フォームに何かしらのエラーがあるか判別するには

@if ($errors->user->any())
...
@endif

が使えます。

EloquentとQuery Builderのvalue()の違い

Tue, 26 Jul 2022 23:31:57 +0900

Eloquentでクエリする際も内部的にはクエリビルダのメソッドをcallしている事が多いので、何も考えずにクエリビルダで出来ていた事をそのままEloquentで実行していたらハマってしまいました、落とし穴に。おかげで「なるほど、そういう事もあるのだな」位の心構えができるようになりました。今回はそんな気づきを与えてくれたvalue()についての解説です。

value()とは？

value()はクエリの最初の結果から特定の項目のみ取得して返してくれる便利なメソッドです。DBからfetchするレコードが１つだと分かっていて、且つ、特定の１項目のみが必要な場合などに重宝します。

例えば、ユーザの名前と生年月日の組み合わせがユニークであり、そのemailを取得したい場合は

$email = DB::table('user')
    ->where('name', '=', '山田太郎')
    ->where('birthday', '=', '1970-01-01')
    ->value('email');
>>> "y.taro@sample.com"

と書けば一発で取得できます。上記はクエリビルダでの取得ですが、Eloquentでも同様にvalue()を使うことが出来ます。

$email = User::query()
    ->where('name', '=', '山田太郎')
    ->where('birthday', '=', '1970-01-01')
    ->value('email');
>>> "y.taro@sample.com"

いずれも実行されるsqlは以下の通り、

select `email` from `member` where `name` = '山田太郎' and `birthday` = '1970-01-01' limit 1;

特定の項目のみselectしつつ、limitで取得する結果を１つに限定している点がポイントです。

こうしてみると、クエリビルダとEloquentのvalue()は一見同じ処理を行っているように見えますね。しかし、次の例では異なる結果を返します。

私がハマった落とし穴

以下ではとあるブログの投稿(post)に紐付いたタグ名(tag.name)を取得しGROUP_CONCATで連結して取得しました。

$tags = DB::table('post')
    ->join('tag', 'post.post_id', '=', 'tag.post_id')
    ->where('post.post_id', '=', 1)
    ->groupBy('post.post_id')
    ->value(DB::raw('GROUP_CONCAT(tag.name)'));
>> "Laravel,PHP,Eloquent"

クエリビルダではカンマで連結されたタグ名が取得できました。 Eloquentではどうでしょうか？

$tags = Post::query()
    ->join('tag', 'post.post_id', '=', 'tag.post_id')
    ->where('post.post_id', '=', 1)
    ->groupBy('post.post_id')
    ->value(DB::raw('GROUP_CONCAT(tag.name)'));
>> null

あれれ、どういう訳かnullが返されました。

ソースを解析

以下はEloquentのvalue()のソースコードです。

vendor/laravel/framework/src/Illuminate/Database/Eloquent/Builder.php

/**
 * Get a single column's value from the first result of a query.
 *
 * @param  string|\Illuminate\Database\Query\Expression  $column
 * @return mixed
 */
public function value($column)
{
    if ($result = $this->first([$column])) {
        return $result->{Str::afterLast($column, '.')};
    }
}

なるほど、first([$column])でクエリ結果を取得し、$columnで指定した値のコロン（’.’）以降をプロパティ名としてアクセスしています。

つまり先ほどの例だと、$columnはGROUP_CONCAT(tag.name)なので、コロン以降はname)となります。従って、Undefined propertyとして処理され、nullとなった訳です。

一方、結果が正しく取得できたクエリビルダはというと、

vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php

/**
 * Get a single column's value from the first result of a query.
 *
 * @param  string  $column
 * @return mixed
 */
public function value($column)
{
    $result = (array) $this->first([$column]);

    return count($result) > 0 ? reset($result) : null;
}

配列に変換した上で、reset()を使って１つ目の結果を取得していました。

回避策

回避策は色々ありそうですが、私の中では生クエリ（DB::raw）とvalue()を併用したい場合は一度selectRaw()などで別名を付けるルールを採用する事にしました。

$tags = Post::query()
    ->join('tag', 'post.post_id', '=', 'tag.post_id')
    ->where('post.post_id', '=', 1)
    ->groupBy('post.post_id')
    ->selectRaw('GROUP_CONCAT(tag.name) AS tag_names')
    ->value('tag_names');
>> "Laravel,PHP,Eloquent"

現場からは以上です。

チェックボックスの入力値 - mergeIfMissing()

Sat, 09 Jul 2022 00:21:25 +0900

以前の投稿「FormRequestで入力値を補正」でチェックボックスがオフのときの値の補正に関して説明しました。今度はFormRequestを使わないときの補正の仕方です。

このような入力画面があるとします。

それを受けるコントローラのメソッドを以下とすると、

...
    public function update(Request $request, Customer $customer)
    {
　　    $validated = $request->validate([
              'active_flag' => ['nullable'],
              'email'       => ['required', 'email', 'unique:customer,email'],
              'name'        => ['required'],
              'name_kana'   => ['required'],
　　　　]);

        dd($validated);
    }
...

このような配列が返ってきます。

[
    'active_flag' => 'Y',
    'email' => 'test@example.com',
    'name'  => 'テスト太郎',
    'name_kana' => 'てすとたろう',
]

しかし、先のチェックボックス「有効」がオフだとすると、

[
    'email' => 'test@example.com',
    'name'  => 'テスト太郎',
    'name_kana' => 'てすとたろう',
]

と、active_flagの項目はリクエストには存在しません。チェックボックスがオフだとブラウザはサーバーに何も返さないからです。

しかし、それをコントローラで判断してDBに無効（この場合N）を保存したいです。

そのような場合は、RequestのメソッドのmergeIfMissing()を使います。オフのときの値を引数として与えます。複数の項目の指定も可能です。

...
    public function update(Request $request, Customer $customer)
    {
        $request->mergeIfMissing(['active_flag' => 'N']); // デフォルトの値を設定！

        $validated = $request->validate([
              'active_flag' => ['required', 'In:Y,N'], // 必須と値を確認！
              'email'       => ['required', 'email', 'unique:customer,email'],
              'name'        => ['required'],
              'name_kana'   => ['required'],
　　　　]);

        dd($validated);
    }
...

値は補正されて、期待通りにNが入ってきます。上のバリデーションルールで見られるように、値が必須であること、値がYあるいはNであることもチェックできます。

[
    'active_flag' => 'N',
    'email' => 'test@example.com',
    'name'  => 'テスト太郎',
    'name_kana' => 'てすとたろう',
]

toArray()でcreated_at,updated_atのフォーマットが変わる

Tue, 28 Jun 2022 09:46:39 +0900

Eloquentモデルを配列に変換して渡す必要がある際にたまに使うtoArray()ですが。先日何気なく使用していて思わぬエラーに遭遇、原因を調べてみると実はLaravel 7.xから変更されていた仕様でした。Upgrade Guideには目を通していたつもりでしたが、どうしてなかなか行き当たりばったりなキャッチアップになってしまう、Lazy Loadingな私です。

$user->toArray()

まず、toArray()を使用していて遭遇したエラーについて説明します。 Laravelインストール後にデフォルトで存在するUserモデルをtoArray()で変換してみましょう。

// factory でダミーレコード生成
>>> $user = User::factory()->create();
=> App\Models\User {#3575
     name: "Mr. Buck Schinner MD",
     email: "waters.montana@example.com",
     email_verified_at: "2022-06-05 04:34:30",
     #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
     #remember_token: "wp5fKxXY7s",
     updated_at: "2022-06-05 04:34:30",
     created_at: "2022-06-05 04:34:30",
     id: 1,
   }

>>> $user->toArray();
=> [
     "name" => "Mr. Buck Schinner MD",
     "email" => "waters.montana@example.com",
     "email_verified_at" => "2022-06-05T04:34:30.000000Z",
     "updated_at" => "2022-06-05T04:34:30.000000Z",
     "created_at" => "2022-06-05T04:34:30.000000Z",
     "id" => 1,
   ]

お気づきでしょうか？ email_verified_at, updated_at, created_at の日付形式がY-m-d H:i:sからISO-8601に変換されています。

なぜでしょうか？

日付のフォーマット

これはLaravel 7から内部的にCarbonのtoJson()を使用するようになったためのようです。

https://laravel.com/docs/7.x/upgrade#date-serialization

確かに、CarbonでtoJson()を使用するとISO-8601形式で日付が出力されますね。

Carbon::today()->toJson();
=> "2022-06-05T00:00:00.000000Z"

とは言え、全てのdatetimeやtimestamp型の項目がフォーマットされるわけではなく、デフォルトではcreated_atとupdated_atのみです。その他の項目についてはemail_verified_atの様に、$castsにてdatetimeを指定すると同様にISO-8601形式でフォーマットされます。

デフォルトのフォーマットを変更する

今回私が遭遇したケースではcreated_atとupdated_atをY-m-d H:i:sの形式のまま配列に変換する必要がありました。 toArray()で変換する際に日付のフォーマットを指定するにはどうすれば良いでしょう？

$casts

１つはemail_verified_atの様に$castsにて個別に指定する方法です。以下の様に、datetime:に続いて出力したいフォーマットを指定することができます。

app/Models/User.php

...
    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
        'created_at'        => 'datetime:Y-m-d H:i:s',    // ←日付の形式を指定
        'updated_at'        => 'datetime:Y-m-d H:i:s',    // ←日付の形式を指定
    ];
...

tinkerで出力を確認してみましょう。

>>> $user->toArray();
=> [
     "id" => 1,
     "name" => "Dr. Wanda Gottlieb",
     "email" => "brenda39@example.com",
     "email_verified_at" => "2022-03-09T13:55:28.000000Z",
     "created_at" => "2022-03-09 13:55:28",
     "updated_at" => "2022-03-09 13:55:28",
   ]

正しく反映されていますね。

serializeDate

もう１つはserializeDate()をオーバーライドすることです。このメソッドはModelクラスがuseしているtraitのHasAttributesに定義されており、toArray()実行時に内部的に呼び出されています。このメソッドをオーバーライドすることでcreated_atとupdated_atを含めdatetimeにキャストしている項目のtoArray(), toJson()時のデフォルトのフォーマットを指定できます。フォーマットは以下の様にformat()で指定します。

app/Models/User.php

...
use DateTimeInterface;
...
    /**
     * Prepare a date for array / JSON serialization.
     *
     * @param  \DateTimeInterface  $date
     * @return string
     */
    protected function serializeDate(DateTimeInterface $date)
    {
        return $date->format('Y-m-d H:i:s');
    }
...

因みに、serializeDate()で指定しているのはデフォルトのフォーマットなので、$castsでのフォーマット指定と併用した場合は$casts側の指定が優先されます。以下は併用した例です。

app/Models/User.php

...
    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime:Y-m-d',    // 日付のみに指定してみる
    ];
...

toArray()すると、created_at, updated_atはY-m-d H:i:sですが、email_verified_atはY-m-dのみの出力となります。

>>> $user->toArray();
=> [
     "id" => 1,
     "name" => "Dr. Wanda Gottlieb",
     "email" => "brenda39@example.com",
     "email_verified_at" => "2022-03-09",    // Y-m-d のみ
     "created_at" => "2022-03-09 13:55:28",
     "updated_at" => "2022-03-09 13:55:28",
   ]

バリデーション後のRequestの処理

Mon, 20 Jun 2022 06:07:34 +0900

FormRequestのバリデーションを問題なくパスしたら、コントローラで$request->validatedで配列としてフォームの入力値を取得できます。取得後の値は安全なのでそのままDBに保存することも可能です。しかし、その配列から必要のない値を抜いたり、足りない値を追加したりとかの処理はどうするかという説明です。

会員登録のFormRequest

例として会員登録の画面を使います。画面はこんな感じです。

その画面の入力をチェックするFormRequestは以下と定義します。

namespace App\Http\Requests;

use App\Rules\CaptchaRule;
use App\Rules\CustomerPasswordRule;
use Illuminate\Foundation\Http\FormRequest;

class CustomerRequest extends FormRequest
{
    public function rules()
    {
        $rules = [
            'email'                => ['required', 'email', 'unique:customer,email'],
            'password'             => ['required', new CustomerPasswordRule, 'confirmed'],
            'name'                 => ['required'],
            'g-recaptcha-response' => ['required', new CaptchaRule],
        ];

        return $rules;
    }
}

CustomerPasswordRuleやCaptchaRuleは事前に用意したカスタムのバリデーションのクラスです。

CustomerRequestのバリデーションを問題なく通過したら、以下のようにコントローラでDBに保存します。

namespace App\Http\Controllers\User;

use App\Http\Controllers\Controller;
use App\Http\Requests\CustomerRequest;
use App\Models\Customer;
use Illuminate\Foundation\Auth\RegistersUsers;

class RegisterController extends Controller
{
    use RegistersUsers;

...
    /**
     * 会員の登録
     *
     * @param  \App\Http\Requests\CustomerRequest  $request
     * @return \Illuminate\Http\RedirectResponse
     */
    public function register(CustomerRequest $request)
    {
        $validated = $request->validated();

        Customer::create($validated);
        ...
    }
}

ここでのregister()メソッドの$validatedの値の中身を見てみましょう。

$validated = [
  "email" => "test@example.com",
  "password" => "Test1234567890!",
  "name" => "テスト太郎",
  "g-recaptcha-response" => "03AGdBq26f1ycQWiqz2OeBFz....",
]

DBに保存するのに必要なのは、email, password（暗号化する）、nameの３つだけで、キャプチャのg-recaptach-responseは必要でありませんので、先の配列値から抜く必要あります。また、会員が有効かどうかを指定するactive_flagが必要なので、その値を配列に加える必要あります。

このような処理を行うには、Laravelのバージョン8.x以降では、以下のようにvalidated()を使わずに、safe(), merge(), except()を使って可能です。

...
    $input = $request->safe()
        ->merge(['active_flag' => 'Y'])
        ->except(['g-recaptcha-response']);

    Customer::create($input);
...

safeは、バリデーションをパスした値を抽出し、mergeは値を追加、exceptは値を削除です。しかし、mergeとexceptの使用の順番には注意してください。これらを逆にするとエラーとなってしまいます。なぜなら、exceptは配列を返すのでその後にメソッドの連結ができません。

処理の結果の配列は、以下のようになります。

$input = [
  "email" => "test@example.com",
  "password" => "Test1234567890!",
  "name" => "テスト太郎",
  "active_flag" => "Y",
]

よりフレキシブルな処理を望むなら、以下のようにcollect()を通してCollectionのオブジェクトにすることです。

...
    $input = $request->safe()
        ->collect()
        ->except(['g-recaptcha-response'])
        ->merge(['active_flag' => 'Y'])
        ->all();

    Customer::create($input);
...

さて、safe()の対応がないLaravel 7.xではどう対応しましょう。こちらも、配列をCollectionにしてしまえば、問題ありません。

...
    $input = collect($request->validated())
        ->except(['g-recaptcha-response'])
        ->merge(['active_flag' => 'Y']
        ->all();

    Customer::create($input);
...

私としては、Collectionを使用した方が好きです。以下のように、ケースにより配列の中身を変えることも簡単です。

       $input = collect($request->validated())
            ->when(! $request->active_flag, function ($collection) {
                return $collection->put('active_flag', 'N'); // 値がないときはNとする
            })
            ->when(! $request->paymethod_id, function ($collection) {
                $collection->forget([ // 値がないときは、以下の設定は必要ではない
                    'paymethod_id',
                    'card_number',
                    'card_exp',
                    'card_holder',
                ]);

                return $collection;
            })
            ->all();

isDirty() vs wasChanged()（更新）

Mon, 13 Jun 2022 05:46:58 +0900

３年前に書いた投稿の更新です（その投稿自体その４年前の投稿の更新です）。factoryからEloquentのインスタンスの作成も変わり、また新たな発見がありました。

まず、tinkerを使用して、isDirty()の復習です。 factory()を使って、１つレコードを作成します。

>>> User::factory()->create();
=> App\Models\User {#3632
     name: "村山 涼平",
     email: "ekoda.asuka@example.com",
     email_verified_at: "2022-06-12 20:18:11",
     #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
     #remember_token: "h7d19XhYd4",
     updated_at: "2022-06-12 20:18:11",
     created_at: "2022-06-12 20:18:11",
     id: 1,
   }

作成したレコードの名前を更新しますが、DBでなくオブジェクトのみの更新のために、fill()を使用します。

>>> $user = User::find(1);
=> App\Models\User {#3949
     id: 1,
     name: "村山 涼平",
     email: "ekoda.asuka@example.com",
     email_verified_at: "2022-06-12 20:18:11",
     #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
     #remember_token: "h7d19XhYd4",
     created_at: "2022-06-12 20:18:11",
     updated_at: "2022-06-12 20:18:11",
   }
>>> $user->fill(['name' => '山田太郎']);
=> App\Models\User {#3949
     id: 1,
     name: "山田太郎",
     email: "ekoda.asuka@example.com",
     email_verified_at: "2022-06-12 20:18:11",
     #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
     #remember_token: "h7d19XhYd4",
     created_at: "2022-06-12 20:18:11",
     updated_at: "2022-06-12 20:18:11",
   }

nameが変わりましたね。実際、オブジェクトが更新したかどうかは、isDirty()を使います。

>>> $user->isDirty();
=> true

変更していますね。項目ごとはどうでしょう？

>>> $user->isDirty('name');
=> true
>>> $user->isDirty('email');
=> false

nameの変更がありますが、emailの変更はなしです。正しいです。

ここで、変更したオブジェクトをもとに対応するレコードをDBに保存します。

>>> $user->save();
=> true

さて、この時点でのisDirty()の返り値は？

>>> $user->isDirty();
=> false
>>> $user->isDirty('name');
=> false

もう、isDirty()では、変更があったかどうかの判断はできません、何もDirtyではありません。

この時点、つまりオブジェクトの更新をDBに反映した時点でレコードが更新したかどうかを判断するには、isDirty()ではなく、wasChanged()を使用します。

>>> $user->wasChanged();
=> true
>>> $user->wasChanged('name');
=> true
>>> $user->wasChanged('email');
=> false

save()前のisDirty()の結果とまったく同じです。

実際には、こんなコードでwasChanged()は使われます。

...
$user->fill(['name' => '山田太郎']);

if ($user->isDirty()) {
    $user->save();
    if ($user->wasChagned('name')) {
        //nameが更新されたときのみ、以下のコードを実行
        ...
    }
}
...

さてさて、上の話は既存にあるレコードを更新したときの話です。新規のレコード作成のときもチェックしてみます。

>>> $user = User::factory()->make();
=> App\Models\User {#4588
     name: "浜田 京助",
     email: "tsubasa.saito@example.org",
     email_verified_at: "2022-06-12 20:21:59",
     #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
     #remember_token: "ZzZh0fHqJA",
   }

先ほどと違うのは、create()の代わりにmake()が使用されているところです。create()と違ってまだDBレコードは作成されていません。この時点では、

>>> $user->isDirty();
=> true

更新と同じですね。 DBにレコードを保存してみます。

>>> $user->save();
=> true

さて、この時点でのisDirty()の返り値は？

>>> $user->isDirty();
=> false

期待通りです。しかし、

>>> $user->wasChanged();
=> false

こちらは、更新時と違ってtrueとはなりません。wasChangedは訳せば更新したかという意味であり、作成されたかではないとすればfalseになるのは正しいのでしょう。

しかし、$userのようなインスタンスが既存のレコードを更新したのか、新規に作成されたのかが前もってわからないときの判断としてwasChanged()を使用できません。とかいってwasCreated()というメソッドもないのです。滅多に直面するケースは少ないですが、注意しましょう。

Commandにbefore/after処理を追加する

Mon, 16 May 2022 07:56:30 +0900

今のプロジェクトでは独自に作成したコンソールコマンドが40~50個ほどあります。バッチ処理であったり、クロンで定期実行している処理であったりと様々です。システムが大きくなるとそれだけ必要な処理が増えるので致し方ありません。しかし時折、

このコマンドは何をやっているんだっけ？と見返した時にすぐ思い出せるようにコード量を少なく、シンプルに保っておきたいものです。

そう思いながら今まで作成したコマンドらを眺めていると、毎回決り文句のように記述している処理がいくつかある事に気づきました。気づいてしまったが故にDRYアレルギーが発症してしまい、どこか適切な場所に共通処理として切り出せないだろうか？と調べてみると、CommandにはEventが用意されていました。

CommandのEvent

公式ドキュメントの"Artisan Console"ページの最後に少しだけCommandのEventに関する説明があります。それによると、Commandが実行される際は以下の３つのイベントが発行されるそうです。

ArtisanStarting: artisan実行開始時
CommandStarting: Commandが実行される直前、つまりbefore処理
CommandFinished: Commandが実行された後、つまりafter処理

デフォルトでは上記のEventに対するListenerは用意されていないので、新たに作成し紐付ける必要があります。

before/after処理を追加

ここでは例として、CommandStartingイベントとCommandFinishedイベントを使いコマンド実行前と後に処理を追加してみましょう。まずはbefore処理から。

CommandStartingListener作成

before処理を実装する為のListenerクラスを作成します。以下のコマンドを実行。

php artisan make:listener CommandStartingListener

CommandStartingListenerクラスのhandle()にbefore処理を追加します。以下では開始ログを出力してみました。

app/Listeners/CommandStartingListener.php

<?php

namespace App\Listeners;

use Illuminate\Support\Facades\Log;

class CommandStartingListener
{
    /**
     * Handle the event.
     *
     * @param  object  $event
     * @return void
     */
    public function handle($event)
    {
        // 開始ログを出力
        Log::info($event->command."を開始しました。");
    }
}

EventとListenerを紐付け

作成したCommandStartingListenerはそのままでは発火されません。EventServiceProviderにてCommandStartingイベントに紐付けましょう。

app/Providers/EventServiceProvider.php

<?php

namespace App\Providers;

use Illuminate\Auth\Events\Registered;
use Illuminate\Auth\Listeners\SendEmailVerificationNotification;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;

class EventServiceProvider extends ServiceProvider
{
    /**
     * The event listener mappings for the application.
     *
     * @var array
     */
    protected $listen = [
        Registered::class => [
            SendEmailVerificationNotification::class,
        ],
        // CommandStartingイベントにリスナを紐付け
        \Illuminate\Console\Events\CommandStarting::class => [
            \App\Listeners\CommandStartingListener::class,
        ],
    ];

    /**
     * Register any events for your application.
     *
     * @return void
     */
    public function boot()
    {
        //
    }
}

同様の手順でCommandFinishedListenerを作成し、CommandFinishedイベントに紐付け、終了ログを出力してみましょう。EventServiceProviderは最終的に以下のようになります。

app/Providers/EventServiceProvider.php

...
    /**
     * The event listener mappings for the application.
     *
     * @var array
     */
    protected $listen = [
        Registered::class => [
            SendEmailVerificationNotification::class,
        ],
        // CommandStartingイベントにリスナを紐付け
        \Illuminate\Console\Events\CommandStarting::class => [
            \App\Listeners\CommandStartingListener::class,
        ],
        // CommandFinishedイベントにリスなを紐付け
        \Illuminate\Console\Events\CommandFinished::class => [
            \App\Listeners\CommandFinishedListener::class,
        ],
    ];
...

最後に

適当なコマンドを実行しログ出力されているか試してみましょう。以下ではルートのリストを出力するコマンドを実行しています。

php artisan route:list

laravel.logに開始と終了のログが出力されましたね。

storage/logs/laravel.log

[2022-05-08 08:21:18] local.INFO: route:listを開始しました。  
[2022-05-08 08:21:18] local.INFO: route:listを終了しました。

Laravelはどの環境で実行されている？

Mon, 09 May 2022 02:45:59 +0900

Laravelの.envは、ご存知のように実行する環境により中身が違ってきます。その環境の種類を設定するのがAPP_ENVの環境変数です。今回はそのお話です。

設定値

Laravel以下のように.envファイル内でいろいろな環境変数の設定ができます。

.env

APP_NAME=Laravel
APP_ENV=local　# これが今回の主人公
APP_KEY=
APP_DEBUG=true
..

その中で、APP_ENVの値はどの環境であるかを設定します。既存値としては、local あるいは production の２つあります。ローカルの開発環境あるいはライブの環境です。しかし、必要ならば自分で好きな値で設定しています。私らのステージングサーバでは、stagingの値を使用しています。

また、.envでは指定しないですが、ユニットテスト実行のときに自動的に testing という値が設定されます。これは、phpunit.xmlの以下で設定しています。

phpunit.xml

...
  <php>
    <env name="APP_ENV" value="testing"/>
    <env name="APP_URL" value="https://localhost"/>
...

どの環境か判断

さて、プログラムの中でどの環境で現在実行されているかを、どのように判断するかというと、これ意外とバリエーションあります。

最近まで私が使用していたのは、

if (config('app.env') === 'production') {
    //
}

config()のヘルバーは他の環境変数でも使えるので重宝します。

しかし、マニュアルを見ると、以下のようにAppのファサードのメソッドを使っています。

if (App::environment('production')) {
    //
}

これ知らなかったなあ。しかも、複数の環境のテストも可能です。stagingあるいはproductionなら、

if (App::environment(['staging', 'production'])) {
    //
}

さらに、こんなのもありです。

if (App::isProduction()) {
    //
}

このバリエーションには、ローカル環境のチェックもあります。

if (App::isLocal()) {
    //
}

さて、テスト環境はなんだと思いますか？

if (App::runningUnitTests()) {
    //
}

残念、App::isTesting()ではなかったですね。

それから、Appのファサードを使用しなくても、app()のヘルパーを使用しても同様です。例えば、

if (app()->isProduction()) {
    //
}

最後に

環境変数と関係ないですが、コマンドラインでLaravelを実行しているときは、以下でチェックできます。

if (App::runningInConsole()) {
    //
}

tinkerで実行したら、

>>> App::runningInConsole()
=> true

【Under the hood】url.intendedはいつどこでセットされたのか？

Wed, 04 May 2022 07:59:30 +0900

前回の記事、ログイン後のリダイレクト先、その２では未ログインの状態でログインが必要なページにアクセスした場合、ログインページへ飛ばされ、ログインすると元々アクセスしたかったページへリダイレクトされる挙動について確認し、sessionのurl.intendedにセットされた値によってログイン後のリダイレクト先が決定する事が理解できました。しかし、url.intendedは一体いつどこでsessionにセットされたのでしょうか？気になったので処理を追ってみました。

注意

今回の記事に掲載しているソースコードはLaravel8から引用しました。Laravel9ではPHP8.0の記法が導入され一部異なりますが行っている処理は同じなのでそちらを使う場合でも参考になるかと思います。

Illuminate\Auth\Middleware\Authenticate.php

ルートのmiddlewareにauthを指定すると、そのページにリクエストが投げられた際にこのクラスのauthenticate()が実行されます。まずはここから見ていきましょう。このメソッドでは$this->auth->guard($guard)->check()にてユーザがログイン済みか否かを確認し、未ログインであればその後の$this->unauthenticated($request, $guards);が実行されます。unauthenticatedはAuthenticationExceptionをスローします。

vendor/laravel/framework/src/Illuminate/Auth/Middleware/Authenticate.php

    /**
     * Determine if the user is logged in to any of the given guards.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  array  $guards
     * @return void
     *
     * @throws \Illuminate\Auth\AuthenticationException
     */
    protected function authenticate($request, array $guards)
    {
        if (empty($guards)) {
            $guards = [null];
        }

        foreach ($guards as $guard) {
            if ($this->auth->guard($guard)->check()) {    // ログイン済みかチェック
                return $this->auth->shouldUse($guard);
            }
        }
        $this->unauthenticated($request, $guards);    // 未ログインならこちらを実行
    }

    /**
     * Handle an unauthenticated user.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  array  $guards
     * @return void
     *
     * @throws \Illuminate\Auth\AuthenticationException
     */
    protected function unauthenticated($request, array $guards)
    {
        throw new AuthenticationException(    // 専用の例外をスロー
            'Unauthenticated.', $guards, $this->redirectTo($request)
        );
    }

Illuminate/Foundation/Exceptions/Handler.php

Laravelの全ての例外はApp\Exceptions\Handlerクラスにて処理されます。実際に実行される処理は親クラスである、Illuminate\Foundation\Exceptions\Handlerクラスに定義されています。例外をHTTPレスポンスに変換するrender()を見てみると、AuthenticationExceptionが投げられた場合の処理が記述されています。

vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php

    /**
     * Render an exception into an HTTP response.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Throwable  $e
     * @return \Symfony\Component\HttpFoundation\Response
     *
     * @throws \Throwable
     */
    public function render($request, Throwable $e)
    {
        ...

        if ($e instanceof HttpResponseException) {
            return $e->getResponse();
        } elseif ($e instanceof AuthenticationException) {
            return $this->unauthenticated($request, $e);    // ←AuthenticationExceptionが投げられた場合の処理
        } elseif ($e instanceof ValidationException) {
            return $this->convertValidationExceptionToResponse($e, $request);
        }

        ...
    }

そして、同じクラス内のunauthenticated()を呼び出しています。

vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php

    ...

    /**
     * Convert an authentication exception into a response.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Illuminate\Auth\AuthenticationException  $exception
     * @return \Symfony\Component\HttpFoundation\Response
     */
    protected function unauthenticated($request, AuthenticationException $exception)
    {
        return $this->shouldReturnJson($request, $exception)
                    ? response()->json(['message' => $exception->getMessage()], 401)
                    : redirect()->guest($exception->redirectTo() ?? route('login'));
    }

    ...

ajaxリクエストの場合はjsonレスポンスを返し、そうでない場合は、redirect()->guest(…)が実行されます。

Illuminate\Routing\Redirector

guest()はコメントにある通り、カレントのURLをセッションにセットしリダイレクトレスポンスを作成します。このカレントのURLというのがアクセスしようとしていたURLの事であり、setIntendedUrl()によってsessionのurl.intendedにセットされるのです。

vendor/laravel/framework/src/Illuminate/Routing/Redirector.php

    /**
     * Create a new redirect response, while putting the current URL in the session.
     *
     * @param  string  $path
     * @param  int  $status
     * @param  array  $headers
     * @param  bool|null  $secure
     * @return \Illuminate\Http\RedirectResponse
     */
    public function guest($path, $status = 302, $headers = [], $secure = null)
    {
        $request = $this->generator->getRequest();

        $intended = $request->method() === 'GET' && $request->route() && ! $request->expectsJson()    // ←カレントURLを取得
                        ? $this->generator->full()
                        : $this->generator->previous();

        if ($intended) {
            $this->setIntendedUrl($intended);
        }

        return $this->to($path, $status, $headers, $secure);
    }

    ...
    /**
     * Set the intended url.
     *
     * @param  string  $url
     * @return void
     */
    public function setIntendedUrl($url)
    {
        $this->session->put('url.intended', $url);    // sessionのurl.intendedにセット
    }

url.intendedは色々なクラスの色々なメソッドを介して最終的にセットされているため、少し複雑でしたが処理の流れを把握できてスッキリしました。お疲れさまでした。

ログイン後のリダイレクト先、その２

Tue, 03 May 2022 07:55:47 +0900

前回の記事ではログインボタンからログインした場合について解説しました。そちらのケースでは、RouteServiceProvider::HOMEを任意の値に変更する事でリダイレクト先を指定できました。今回はもう少し掘り下げ、ログインが必要なページにアクセスし強制的にログインページに飛ばされた場合について見てみましょう。

ログインページへ強制リダイレクト、からのログイン

未ログインの状態でログインが必要なページに遷移するとアクセスがガードされログインフォームに飛ばされますが、そこからログインした場合はどこにリダイレクトするでしょうか？前回の記事でRouteServiceProvider::HOMEに設定したトップページ（’/’）でしょうか？確認してみましょう。

以下のようにweb.phpを編集して’sayhi’というrouteを追加します。

routes/web.php

<?php

use Illuminate\Support\Facades\Route;

/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/

Route::get('/', function () {
    return view('welcome');
});

Route::get('/dashboard', function () {
    return view('dashboard');
})->middleware(['auth'])->name('dashboard');

// ルート sayhi を追加
Route::get('/sayhi', function () {
    return sprintf('<h1>Hi, %s</h1>', auth()->user()->name);
})->middleware(['auth'])->name('sayhi');

require __DIR__.'/auth.php';

未ログインの状態でsayhiページを開いてみましょう。php artisan serveでwebサーバを起動しているならhttp://localhost:8000/sayhiから開けます。アクセスがガードされログインページに飛ばされるはずです。そしてログインすると。。。

sayhiページが表示されました。

redirect()->intended(...)、再び

認証が必要なページにアクセスしログインページに飛ばされた場合、ログイン後は元々アクセスしようとしていたページにリダイレクトされるようです。これはどういうプロセスでそうなっているのでしょうか？

以下、AuthenticatedSessionControllerのstore()を再掲します。

app/Http/Controllers/AuthenticatedSessionController.php

/**
 * Handle an incoming authentication request.
 *
 * @param  \App\Http\Requests\Auth\LoginRequest  $request
 * @return \Illuminate\Http\RedirectResponse
 */
public function store(LoginRequest $request)
{
    $request->authenticate();
 
    $request->session()->regenerate();
 
    return redirect()->intended(RouteServiceProvider::HOME);
}

前回は掘り下げなかった、redirect()->intended(…) の処理を追ってみましょう。 intended()は以下のように定義されています。

vendor/laravel/framework/src/Illuminate/Routing/Redirector.php

/**
 * Create a new redirect response to the previously intended location.
 *
 * @param  string  $default
 * @param  int  $status
 * @param  array  $headers
 * @param  bool|null  $secure
 * @return \Illuminate\Http\RedirectResponse
 */
public function intended($default = '/', $status = 302, $headers = [], $secure = null)
{
    $path = $this->session->pull('url.intended', $default);

    return $this->to($path, $status, $headers, $secure);
}

ここでの処理のポイントは３つです。

sessionにurl.intendedがセットされていればその値をリダイレクト先とする
url.intendedがセットされていなければ、引数で渡されたパスをリダイレクト先とする（ここではRouteServiceProvider::HOME）
url.intendedも引数もセットされていない場合、引数のデフォルト値である'/'をリダイレクト先とする

ログインページに飛ばされた際、debugbarのsessionタブを開くとurl.intendedに元々アクセスしようとしていたURLがセットされているのが確認できます。

尚、sessionのpull()はセッションから値を取得し削除する為、ログイン後url.intendedはセッションに残っていません。

ログイン後のリダイレクト先、その１

Mon, 02 May 2022 07:55:30 +0900

ECサイトなど会員登録機能を備えたサイトは大きくなると利便性やマーケティング的な観点からページ遷移にとても気を使うようになります。ログイン後のリダイレクト先も重視される導線の一つですね。先の案件でそれらを見直す機会があったので挙動や設定方法について備忘録を兼ねてまとめます。

事前準備

以降の解説はLaravel Breezeがインストールされている状態から進めます。一緒に手を動かしながら進める方は過去の記事、Laravel 8.xのインストールを参考にインストールして下さい。

途中、debugbarでsessionの状態を確認します。必要であればそちらもインストールを、

composer require barryvdh/laravel-debugbar --dev

ログインボタンからログインした際のリダイレクト先

まずは通常のログイン遷移を確認してみましょう。新規のプロジェクトにLaravel Breezeをインストールした状態だと、トップページ右上のLog inからログインからログインできますね。

そして、ログイン後はdashboardページへ遷移しました。

これを任意のURL、例えば、トップページ（’/’）に変更したい場合はどうすれば良いでしょうか？

ログイン時に実行されているのはAuthenticatedSessionControllerのstore()ですので、そちらを確認してみましょう。

app/Http/Controllers/AuthenticatedSessionController.php

/**
 * Handle an incoming authentication request.
 *
 * @param  \App\Http\Requests\Auth\LoginRequest  $request
 * @return \Illuminate\Http\RedirectResponse
 */
public function store(LoginRequest $request)
{
    $request->authenticate();

    $request->session()->regenerate();

    return redirect()->intended(RouteServiceProvider::HOME);
}

リダイレクト先は、redirect()->intended(RouteServiceProvider::HOME);によって決まっているようです。こちらのメソッドの詳しい解析は後に回して、引数のRouteserviceProvider::HOMEという定数に注目です。

RouteServiceProviderを確認するとHOMEは現在のリダイレクト先である’/dashboard’となっていました。この値をトップページ（’/’）に変更してみましょう。

app/Providers/RouteServiceProvider.php

class RouteServiceProvider extends ServiceProvider
{
    /**
     * The path to the "home" route for your application.
     *
     * This is used by Laravel authentication to redirect users after login.
     *
     * @var string
     */
    public const HOME = '/';    // '/dashboard' から変更
...

一旦ログアウトしてから再ログインすると、今度はトップページ（’/’）にリダイレクトされましたね。続きます。

Laravel Collection（１０）mapとtransformの違い

Mon, 04 Apr 2022 03:09:52 +0900

Collectionでのmap()とtransform()のメソッドは似ているようで大きな違いがあります。

まず、テストデータのレコードをtinkerで３つ作成します。

>>> User::factory(3)->create();

=> Illuminate\Database\Eloquent\Collection {#4463
     all: [
       App\Models\User {#4464
         id: 1,
         name: "坂本 知実",
         email: "tfujimoto@example.net",
         email_verified_at: "2022-04-03 02:36:03",
         #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
         #remember_token: "mBZjRiwtp2",
         created_at: "2022-04-03 02:36:03",
         updated_at: "2022-04-03 02:36:03",
       },
       App\Models\User {#4465
         id: 2,
         name: "高橋 知実",
         email: "kazuya.miyazawa@example.net",
         email_verified_at: "2022-04-03 02:36:03",
         #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
         #remember_token: "2ERHaySLEo",
         created_at: "2022-04-03 02:36:03",
         updated_at: "2022-04-03 02:36:03",
       },
       App\Models\User {#4466
         id: 3,
         name: "藤本 修平",
         email: "mkiriyama@example.net",
         email_verified_at: "2022-04-03 02:36:03",
         #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
         #remember_token: "JpPxv9yr0d",
         created_at: "2022-04-03 02:36:03",
         updated_at: "2022-04-03 02:36:03",
       },
     ],
   }

作成されたレコードを$usersの変数に入れます。

>>> $users = User::all();

map()もtransform()もCollectionの中のそれぞれのアイテムを処理してCollectionの値を返すのは同じです。

まず、mapから、

>>> $users->map(function ($user) {
        return $user->only(['id', 'name']);
    })

=> Illuminate\Support\Collection {#4473
     all: [
       [
         "id" => 1,
         "name" => "坂本 知実",
       ],
       [
         "id" => 2,
         "name" => "高橋 知実",
       ],
       [
         "id" => 3,
         "name" => "藤本 修平",
       ],
     ],
   }

この後に$usersの中身を見てみましょう。

>>> $users

=> Illuminate\Database\Eloquent\Collection {#4463
     all: [
       App\Models\User {#4464
         id: 1,
         name: "坂本 知実",
         email: "tfujimoto@example.net",
         email_verified_at: "2022-04-03 02:36:03",
         #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
         #remember_token: "mBZjRiwtp2",
         birth_date: "1988-03-20",
         created_at: "2022-04-03 02:36:03",
         updated_at: "2022-04-03 02:36:03",
       },
       App\Models\User {#4465
         id: 2,
         name: "高橋 知実",
         email: "kazuya.miyazawa@example.net",
         email_verified_at: "2022-04-03 02:36:03",
         #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
         #remember_token: "2ERHaySLEo",
         birth_date: "1975-06-25",
         created_at: "2022-04-03 02:36:03",
         updated_at: "2022-04-03 02:36:03",
       },
       App\Models\User {#4466
         id: 3,
         name: "藤本 修平",
         email: "mkiriyama@example.net",
         email_verified_at: "2022-04-03 02:36:03",
         #password: "$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi",
         #remember_token: "JpPxv9yr0d",
         birth_date: "2011-06-17",
         created_at: "2022-04-03 02:36:03",
         updated_at: "2022-04-03 02:36:03",
       },
     ],
   }

何も変わっていませんね。今度は、transformです。

>>> $users->transform(function($user) {
        return $user->only(['id', 'name']);
})

=> Illuminate\Database\Eloquent\Collection {#4463
     all: [
       [
         "id" => 1,
         "name" => "坂本 知実",
       ],
       [
         "id" => 2,
         "name" => "高橋 知実",
       ],
       [
         "id" => 3,
         "name" => "藤本 修平",
       ],
     ],
   }

ここまではmapの結果とまったく同じですね。しかし、もとの変数の中身を見ると、

>>> $users

=> Illuminate\Database\Eloquent\Collection {#4463
     all: [
       [
         "id" => 1,
         "name" => "坂本 知実",
       ],
       [
         "id" => 2,
         "name" => "高橋 知実",
       ],
       [
         "id" => 3,
         "name" => "藤本 修平",
       ],
     ],
   }

中身が返り値と同じ値で上書きとなっているのです。transformという名前はそれゆえにです。

古いレコードをプルーンします

Sat, 19 Mar 2022 12:14:36 +0900

古くなってもう要らないDBレコードを削除することを、プルーン(prune)あるいはパージ(purge)などと言います。カスタムのArtisanのコマンドを書いて処理してもいいのだけれど、LaravelではこれがModelの中であるトレイトを使うだけで、組織的できてしまいます。

プルーンの対象は特定のDBモデルのレコードです。ここでは、会員ログインのレコードを貯めているuser_logsのテーブルのモデルUserLogを例とします。以下のようにPrunableのトレイトを追加して、削除したい対象のクエリーの条件をprunable()で定義するだけです。

app/Models/UserLog.php

namespace App\Models;
 
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Prunable;
 
class UserLog extends Model
{
    use HasFactory;
    use Prunable;

    const UPDATED_AT = null; // updated_atの項目はない
 
    /**
     * Get the prunable model query.
     *
     * @return \Illuminate\Database\Eloquent\Builder
     */
    public function prunable()
    {
        return static::where('created_at', '<=', now()->subYear()); // １年以上昔のレコードが対象
    }
}

そして、以下のコマンドの実行をクロンに設定にします。

$ php artisan model::prune

簡単でしょう。

削除する前に以下のように実際の削除なしの予行も可能です。

$ php artisan model:prune --pretend
8 [App\Models\UserLog] records will be pruned.

８個のレコードが削除されるよ、と知らせてくれます

tinkerで実際にプルーンを実行してみましょう。どのようなSQL文が実行されるか興味あります。

>>> Artisan::call('model:prune');
=> 0
>>> sql();
=> [
     [
       "query" => "select count(*) as aggregate from `user_logs` where `created_at` <= ?",
       "bindings" => [
         Illuminate\Support\Carbon @1616039564 {#3572
           date: 2021-03-18 03:52:44.536379 UTC (+00:00),
         },
       ],
       "time" => 4.94,
     ],
     [
       "query" => "select * from `user_logs` where `created_at` <= ? order by `id` asc limit 1000",
       "bindings" => [
         Illuminate\Support\Carbon @1616039586 {#3546
           date: 2021-03-18 03:53:06.837232 UTC (+00:00),
         },
       ],
       "time" => 1.36,
     ],
     [
       "query" => "delete from `user_logs` where `id` = ?",
       "bindings" => [
         1,
       ],
       "time" => 7.25,
     ],
     [
       "query" => "delete from `user_logs` where `id` = ?",
       "bindings" => [
         2,
       ],
       "time" => 3.11,
     ],
...

なるほど、１個１個レコードは削除されるのですね。これは、モデルのdeletingやdeletedのイベント処理を可能にするためです。

そのイベント処理が必要でないなら、一括実行も可能です。トレイトをPrunableからMassPrunableにするだけです。

app/Models/UserLog.php

namespace App\Models;
 
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\MassPrunable;
 
class UserLog extends Model
{
    use HasFactory;
    use MassPrunable;

    const UPDATED_AT = null;
 
    /**
     * Get the prunable model query.
     *
     * @return \Illuminate\Database\Eloquent\Builder
     */
    public function prunable()
    {
        return static::where('created_at', '<=', now()->subYear()); // １年以上昔のレコードが対象
    }
}

再度、tinkerでSQL文をチェックすると、

>>> Artisan::call('model:prune');
=> 0
>>> sql();
=> [
     [
       "query" => "delete from `user_logs` where `created_at` <= ? limit 1000",
       "bindings" => [
         Illuminate\Support\Carbon @1616039978 {#3567
           date: 2021-03-18 03:59:38.916448 UTC (+00:00),
         },
       ],
       "time" => 5.61,
     ],
   ]
>>>

削除のSQL文１つだけになっていました。いたれりつくせりです。

Laraスターター - Bootstrap 5

Mon, 14 Mar 2022 04:10:32 +0900

以前に「Laravelへの移行」と称してLaravelのスターターパッケージを２つ紹介しました。スターターパッケージとはすでにある程度デザインや機能が揃っていて、時間がかかる最初のプロジェクトの立ち上げをかなり減少してくれるものです。そからまだ２年も経過していないのですが、その間Bootstrapは4から5になるし、Tailwindが知られてくるようになりつつあり、フロントエンドのフレームワークの更新の時期となりました。今回は、それらを簡単にインストールできるLaraスターターの紹介です。

Laraスターターのインストール

早速インストールしてみます。

Laravelのプロジェクトをインストールします。以下でLaravel 8.x、Laravel 9.xのインストールの説明あります。認証のパッケージのインストールはLaraスターターに含まれているのでインストールの必要はないです。
Laravel 9.xのインストール
Laravel 8.xのインストール
Laraスターターのパッケージをインストールします。
```
$ composer require laraveldaily/larastarters --dev
```
Laraスターターのインストールを実行します。
```
$  php artisan larastarters:install
```
この実行では以下のような選択が問われます。最初の質問は、「どのスターターキットを使用しますか？」今回は手堅くLaravel UI (Bootstrap)を選択します。次の質問は、「どのテーマーを使用しますか？」 Bootstrap 5使用のvoltを選びます。
npmのパッケージをインストールします。
```
$ npm install && npm run dev
```

Volt

インストールが完了したらブラウザで見てみます。

なかなかいいデザインですね。

Laraスターターで使用されているのは以下の無料版です。スターターのためにこれをLaravelのブレードとしてくれました。感謝です。

https://github.com/themesberg/volt-bootstrap-5-dashboard

有料版は以下で69ドルで販売されています。

https://demo.themesberg.com/volt-pro/index.html

無料版と有料版は何が違うというと、

コンポーネントの数が1000でなく100ですね。しかしたいていはそれくらい事足ります。

最後に

Laraスターターを作成したお方は、Laravel業界では誰でも御存知のLaravel DailyのYouTuberです。

https://www.youtube.com/c/LaravelDaily

昔はLaravelのブログを毎日書くことから始め、現在は毎日You Tubeのビデオを作成しています。１週間に１回ブログを書けるかどうかの私にはとても真似ができません。ちなみに、彼（Povilas Korop）はリトアニア (Lithuania)の人です。昔はドイツやロシアに占領されたもののソビエトの崩壊後民主主義のEU加盟国です。

検索結果をページネーション

Mon, 07 Mar 2022 07:04:03 +0900

「ページネーションのデータを変える」の続きです。検索画面を用意して検索結果をページネーションします。

検索画面のページネーション

まず、こんな検索画面を作りたいです。

検索項目に値を入れると、値により絞り込まれた検索結果が表示されます。ごく普通の検索画面です。画面の右下にはページネーションも表示されます。ここでは１画面に２レコードだけ表示です。

routeの定義は、GETだけで十分です。そう、検索条件はすべてURLに入れます。

routes/web.php

...
Route::get('/search', [SearchController::class, 'index'])->name('search');
..

コントローラの作成も簡単です。あまりにも短いのでカットせずにすべて見せてしまいます。

app/Controllers/SearchController.php

namespace App\Http\Controllers;

use App\Models\User;
use Illuminate\Http\Request;

class SearchController extends Controller
{
    public function index(Request $request)
    {
        $query = User::query();

        if ($value = $request->name) {
            $query->where('name', 'like', "%{$value}%");
        }

        if ($value = $request->email) {
            $query->where('email', 'like', "%{$value}%");
        }

        $users = $query->paginate(2);

        return view('user.search', compact('users'));
    }
}

しかし、このコード大いに問題ありです。先の画面でページネーションの２ページをクリックすると、

検索結果３件だったのに１０件になっているし、ページネーションも２ページから５ページに。２ページ目なら表示するのは１件のみでは。おかしいところだらけです。一番の問題はGETだから、ブラウザのURLには入力した値が追加されるのに、?page=2だけです。

この問題の解決はとても簡単です。

上のコントローラのコードで、withQueryString()を以下のように追加するだけなのです。

app/Controllers/SearchController.php

...
    public function index(Request $request)
    {
        $query = User::query();

        if ($value = $request->name) {
            $query->where('name', 'like', "%{$value}%");
        }

        if ($value = $request->email) {
            $query->where('email', 'like', "%{$value}%");
        }

        $users = $query->paginate(2)->withQueryString(); //ここに追加

        return view('user.search', compact('users'));
    }
...

修正した２ページ目の画面です。

URLに?email=example.com&page=2とクエリーの文字列が入っていますね。

クエリーをリファクター

上のコントローラのコードでは条件文のifを使い検索のクエリーを作成しています。それ自体は問題は何もありません。すでに十分わかりやすいです。しかし、Laravel風にすると以下のようにも書くことができます。

app/Controllers/SearchController.php

...
class SearchController extends Controller
{
    public function index(Request $request)
    {
        $query = User::query()
            ->when($request->name, function($query, $value) {
                    return $query->where('name', 'like', "%{$value}%");
            })
            ->when($request->email, function($query, $value) {
                return $query->where('email', 'like', "%{$value}%");
            });

        $users = $query->paginate(2)->withQueryString();

        return view('user.search', compact('users', 'request'));
    }
}
...

whereでなくwhenの関数となっているところに注意してください。最初の引数の値が存在するなら次で定義する匿名関数を実行です。

ページネーションのデータを変える

Sat, 12 Feb 2022 12:41:41 +0900

例えば、User::paginate(5)で返されるデータは、@foreachでループできるゆえにコレクションと思いきや、そうでありません。

ページネーション

ページネーションは、以下の画面のように複数のレコードをページごと閲覧できるために使われます。

上の表示に使われるコントローラは、以下のように簡単なコードです。

namespace App\Http\Controllers;

use App\Models\User;

class UserController extends Controller
{
    public function index()
    {
        $users = User::paginate(2); //１ページ２個表示の設定
        return view('users.index', compact('users'));
    }
}

ブレードも簡単です。

@extends('layouts.app')

@section('content')
    <div class="main py-4">
        <div class="card card-body border-0 shadow table-wrapper table-responsive">
            <h2 class="mb-4 h5">会員名</h2>

            <table class="table table-hover">
                <thead>
                    <tr>
                        <th class="border-gray-200">名前</th>
                        <th class="border-gray-200">メールアドレス</th>
                    </tr>
                </thead>
                <tbody>
                    @foreach ($users as $user)
                        <tr>
                            <td><span class="fw-normal">{{ $user->name }}</span></td>
                            <td><span class="fw-normal">{{ $user->email }}</span></td>
                        </tr>
                    @endforeach
                </tbody>
            </table>
            <div
                class="card-footer px-3 border-0 d-flex flex-column flex-lg-row align-items-center justify-content-between">
                {{ $users->links() }}
            </div>
        </div>
    </div>
@endsection

表示するレコードを変える

さて、画面１で表示されるコードに会員IDを追加して、以下のように表示したいです。

ブレードを以下のようにすれば簡単に表示を変更できます。

...
<td><span class="fw-normal">{{ $user->id }} : {{ $user->name }}</span></td>
...

しかし、ブレードを変更せずに、$user->nameに会員ID + 名前の値としたいなら、どうしましょうか？先のコントローラの定義において、

...
   $users = User::paginate(2);

   $users->each(function($user) {
       $user->name = $user->id.' : '.$user->name;
   });
...

と変更すればよいです。transform()を使用してもよいです。

...
   $users = User::paginate(2);

   $users->transform(function($user) {
       $user->name = $user->id.' : '.$user->name;
       return $user;
   });
...

され、これらをみて、誰しも思うのは、以下のようにメソッドをチェーンすることです。わかりやすいし、Laravelらしい。

...
   $users = User::paginate(2)->each(function($user) {
       $user->name = $user->id.' : '.$user->name;
   });
...

しかし、そうするとエラーとなってしまいます。

そこで気が付くのは、User::paginate(2)が返すのはCollectionではない、ということです。

通常は、以下のようにCollectionを返します。

>>> get_class(User::all());
=> "Illuminate\Database\Eloquent\Collection"

しかし、ページネーションだと、

>>> get_class(User::paginate(2));
=> "Illuminate\Pagination\LengthAwarePaginator"

返すのは、Collectionではなく、LengthAwarePaginatorです。これには、ページに表示するレコードだけでなく、何番目のページとか、他のページに移動するためのリンクとか、など他にもたくさんデータが詰まっています。

>>> User::paginate(2)->toArray();
[!] Aliasing 'User' to 'App\Models\User' for this Tinker session.
=> [
     "current_page" => 1,
     "data" => [
       [
         "id" => 1,
         "name" => "村山 涼平",
         "email" => "kenichi.yoshida@example.org",
         "email_verified_at" => "2022-02-11T02:11:12.000000Z",
         "created_at" => "2022-02-11T02:11:12.000000Z",
         "updated_at" => "2022-02-11T02:11:12.000000Z",
       ],
       [
         "id" => 2,
         "name" => "笹田 裕樹",
         "email" => "shuhei99@example.com",
         "email_verified_at" => "2022-02-11T02:11:12.000000Z",
         "created_at" => "2022-02-11T02:11:12.000000Z",
         "updated_at" => "2022-02-11T02:11:12.000000Z",
       ],
     ],
     "first_page_url" => "http://localhost?page=1",
     "from" => 1,
     "last_page" => 2,
     "last_page_url" => "http://localhost?page=2",
     "links" => [
       [
         "url" => null,
         "label" => "&laquo; Previous",
         "active" => false,
       ],
       [
         "url" => "http://localhost?page=1",
         "label" => "1",
         "active" => true,
       ],
       [
         "url" => "http://localhost?page=2",
         "label" => "2",
         "active" => false,
       ],
       [
         "url" => "http://localhost?page=2",
         "label" => "Next &raquo;",
         "active" => false,
       ],
     ],
     "next_page_url" => "http://localhost?page=2",
     "path" => "http://localhost",
     "per_page" => 2,
     "prev_page_url" => null,
     "to" => 2,
     "total" => 3,
   ]

それゆえに、先ほどのようにメソッドのチェーンをしてデータの変更をすると、これらのデータが失われエラーとなってしまうのです。それでは、どのようにメソッドをチェーンできるのでしょう？

paginate()にチェーン

そのためのメソッドがあるのです。

...
    $users = User::paginate(2)->through(function($user) {
        $user->name = $user->id.' : '.$user->name;
        return $user;
    });
...

through()は、Collectionのtransform()のようなもので、ページネーションのオブジェクトのdataの部分だけの編集が可能です。

ちなみに、以下のようにtap()を使用しても同様なことができます。（参照：https://stackoverflow.com/questions/37102841/laravel-change-pagination-data）

...
  $users = tap(User::paginate(2), function($page) {
        return $page->each( function($user) {
            $user->name = $user->id.' : '.$user->name;
        });
  });
...

なるほど、tap()はこのようなときに使うのですね。paginate()が返すLengthAwarePaginatorのオブジェクトはキープして、その中身を操作することが可能なのです。

SQL文をフォーマット

Mon, 07 Feb 2022 03:20:25 +0900

先日に作成した生SQL文の実行クエリの機能を使用しています。重宝していますが、SQL文が複雑になってくると括弧が多くなってきたりして、わかりづらくなってきます。PHPのコードやHTMLソースと同じようなもので、SQL文の整形の機能が必要です。探したらまさにそのパッケージありました。

まず、私が使用している機能とはこちらのことです。 SQL文を画面で入力して安全に実行して結果を返す

そこで掲載されているSQL文の例はごく簡単なのですが、例えばこんなのは、どうでしょう。

サブクエリーがあるし少々複雑。このSQL文にあるパッケージを適用すると、このようになります。

とても見やすい！

そのパッケージとは、以下のSQLフォーマッターです。

https://github.com/doctrine/sql-formatter

インストールはとても簡単。

$ composer require doctrine/sql-formatter

使用もとても簡単です。

...
use Doctrine\SqlFormatter\SqlFormatter;
...
class QueryController extends Controller
{
    /**
     * 表示
     *
     * @param  \App\Models\Query $query
     * @return \Illuminate\Contracts\View\View
     */
    public function show(Query $query)
    {
        $query->sql = (new SqlFormatter)->format($query->sql); // ここで整形

        return view('admin.query_show')
            ->with(compact('page', 'query'));
    }
...
}

表示では、先に掲載したようにSQL文の整形だけでなく、selectやfromなどのSQLのリザーブワードを太文字にするなどのシンタックスハイライトもしてくれます。また、SQL文が間違っているなら、赤文字で表示もしてくれます。以下は最後の閉める括弧が足りないときです。

HTMLタグを伴う出力が要らずに、SQL文の整形のみが必要なら（保存のときに便利）、

...
use Doctrine\SqlFormatter\NullHighlighter;
use Doctrine\SqlFormatter\SqlFormatter;
...
 echo (new SqlFormatter(new NullHighlighter()))->format($query->sql);
...

とコードします。その出力は以下のようになります。

select
  invoice_id,
  invoice_status,
  invoice_date
from
  invoice
where
  invoice_status = 5
  and invoice_date between '2019-01-01'
  and '2022-02-01'
  and invoice_id not in (
    select
      invoice.invoice_id
    from
      invoice_member
      inner join invoice on invoice_member.invoice_id = invoice.invoice_id
    where
      invoice_status = 5
      and invoice_date between '2019-01-01'
      and '2022-02-01'
  )

存在を知らなかったchunkById()

Sun, 30 Jan 2022 12:45:32 +0900

以前にEloquentの出力のチャンキングを紹介しました。処理中のメモリーの使用量を減らすためのチャンキングですが、実行速度が遅いということでそれを改善する対策もこしらえました。３年前以上のことです。しかし、そのためのメソッドがすでにEloquentのメソッドに存在することに最近気づきました。

まず、以前のポストのリンクを再掲載（読んでね）。チャンキングで使用メモリを抑えるチャンキングは遅い

後者の「チャンキングは遅い」での対策は、対象のテーブルのプライマリIDを指定してクエリーを実行して、チャンキングの速度の改善を図りました。ここで再掲載します。

...
        $max = User::max('id');
        $unit = 1000;

        for ($i = 0; $i < intval(ceil($max/$unit)); $i++) {
            $from = $i * $unit + 1;
            $to = ($i + 1) * $unit;

            $rows = User::where('id', '>=', $from)
                ->where('id', '<=', $to)
                ->get();

            foreach ($rows as $row) {
                $values = [
                    $row->id,
                    $row->created_at,
                    $row->name,
                    $row->email
                ];
 
                fputcsv($fh, $values);
           }
       }
...

単にループしているだけで、毎回毎回これをコードするのはちょっと面倒ですね。

ところが、最近、新人のプログラマーが書いたコードをレビューしていたら、

...
User::chunkById(1000, function($rows) use($fh) {
    foreach ($rows as $row) {
        $values = [
            $row->id,
            $row->created_at,
            $row->name,
            $row->email
        ];
 
        fputcsv($fh, $values);
    }
});
...

chunkById()というメソッドを使いすっきりしたコードになっているではないですか。

そんなメソッドあったかなあと思いつつ、tinkerを使って実行されたsql文を見てみると、

>>> User::chunkbyId(1000, function($rows) {})
=> true

>>> sql()
=> [
     [
       "query" => "select * from `users` order by `id` asc limit 1000",
       "bindings" => [],
       "time" => 3.86,
     ],
     [
       "query" => "select * from `users` where `id` > ? order by `id` asc limit 1000",
       "bindings" => [
         1000,
       ],
       "time" => 2.03,
     ],
     [
       "query" => "select * from `users` where `id` > ? order by `id` asc limit 1000",
       "bindings" => [
         2000,
       ],
       "time" => 1.85,
     ],
...

私の解決策では上限と下限のidを指定してレコードを取得しているところ、chunkId()では、idで並べ替えして、開始のidを指定してそこからチャンクの数（ここでは、1000）を指定しています。なるほど。実行速度も測定したところ私の解決策と同様にchunk()に比べて確実に速い。

さて、この便利もののchunkById()ですが、ひとつ注意が必要です。

例えば、以下のように２つのテーブルをjoinしてchunkById()を適用するとき、

>>> Shop::join('product', 'shop.shop_id', '=', 'product.shop_id')
　　->chunkbyId(1000, function($row) { /* nothing */ });

Illuminate\Database\QueryException with message 'SQLSTATE[23000]: Integrity constraint violation: 1052 Column 'shop_id' in where clause is ambiguous (SQL: select `shop`.`shop_id`, `product`.`product_id` from `shop` inner join `product` on `shop`.`shop_id` = `product`.`shop_id` where `shop_id` > 1913 order by `shop_id` asc limit 1000)'

shop_idが曖昧というエラーになってしまいます。

使用されている、sql文を見ると、

>>> sql()
=> [
     [
       "query" => "select `shop`.`shop_id`, `product`.`product_id` from `shop` inner join `product` on `shop`.`shop_id` = `product`.`shop_id` order by `shop_id` asc limit 1000",
       "bindings" => [],
       "time" => 5.26,
     ],
   ]

order By shop_idのshop_idがshopのテーブルの項目か、productのテーブルの項目かわらかないのです。

これを解決するには、

>>> Shop::join('product', 'shop.shop_id', '=', 'product.shop_id')
    ->chunkbyId(1000, function($row) { /* nothing */ }, 'shop.shop_id', 'shop_id');

chunkById()の第３番目の引数に、明確に使用する項目名(shop.shop_id)を、第４番目にそれに取り替わる元の項目名(shop_id)を指定する必要があります。

実行するsql文は以下のようになり、エラーがなくなります。

>>> sql()
=> [
     [
       "query" => "select * from `shop` inner join `product` on `shop`.`shop_id` = `product`.`shop_id` order by `shop`.`shop_id` asc limit 1000",
       "bindings" => [],
       "time" => 27.81,
     ],
     [
       "query" => "select * from `shop` inner join `product` on `shop`.`shop_id` = `product`.`shop_id` where `shop`.`shop_id` > ? order by `shop`.`shop_id` asc limit 1000",
       "bindings" => [
         1913,
       ],
       "time" => 22.15,
     ],
...

Laravel Collection（９）foreachの代わりにeach

Mon, 24 Jan 2022 03:42:16 +0900

phpでは配列のデータをループするならforeachを使います。LaravelのCollectionでもforeachを使ってループできます。しかし、Collectionならeach()を使いましょう。

foreachからeachへ

まず、tinkerでCollectionのデータを作成します。

>>> use Illuminate\Support\Collection;
>>> $c = Collection::times(5);
=> Illuminate\Support\Collection {#3500
     all: [
       1,
       2,
       3,
       4,
       5,
     ],
   }

foreachを使ってループします。

>>> foreach($c as $item) {
        echo $item." ";
    }

1 2 3 4 5

これと同じことが、Collectionのメソッドのeach()で可能です。

>>> $c->each(function($item) {
        echo $item." ";
    })

1 2 3 4 5

continue, break

foreachでは、ループの途中である条件でスキップ(continue)、あるいはループから抜け出す(break)ことができます。each()でも同様なことができますが、ちょっと違うやり方です。

continueの代わりに、return true（あるいは returnだけ）とします。

>>> foreach($c as $item) {
        if ($item > 2) continue;
        echo $item." ";
    }

1 2 

>>> $c->each(function($item) {
        if ($item > 2) return true;
        echo $item." ";
    })

1 2

breakの代わりに、return falseとします。

>>> foreach($c as $item) {
        if ($item > 2) break;
        echo $item." ";
    }

1 2

>>> $c->each(function($item) {
        if ($item > 2) return false;
        echo $item." ";
    })

1 2

変数のスコープ

foreachでは以下のようなことは簡単です。

>>> $sum = 0
>>> foreach($c as $item) {
        $sum += $item;
    }

>>> echo $sum

15

しかし、eachでは、

>>> $sum = 0
>>> $c->each(function($item) {
        $sum += $item;
    })

<warning>PHP Notice:  Undefined variable: sum in Psy Shell code on line 2</warning>
<warning>PHP Notice:  Undefined variable: sum in Psy Shell code on line 2</warning>
<warning>PHP Notice:  Undefined variable: sum in Psy Shell code on line 2</warning>
<warning>PHP Notice:  Undefined variable: sum in Psy Shell code on line 2</warning>
<warning>PHP Notice:  Undefined variable: sum in Psy Shell code on line 2</warning>

>>> echo $sum

0

foreachではOkなのに、each()のループの中では、$sumは未定義となりループの外では値が初期値のままです。警告もでていますね。

これを正しく行うには、each()のコールバックの関数に$sumの変数をポインターで渡す必要あります。この手のuse()の使用はよくあります。

>>> $c->each(function($item) use(&$sum) {
        $sum += $item;
    })

>>> echo $sum;

15

まあ、この例ではそんなことしなくても、sum()を使えば、

>>> $c->sum()

15

で済みますけれど。

しかし、each()を使えば、こんなことも可能です。

>>> $sum = $c->each(function($item) {
        echo $item." ";
    })->sum()

1 2 3 4 5

>>> echo $sum

15

これは、each()がCollectionを返すので、それをsum()にチェーンできるからです。

セッションのストレージにredisを使う

Mon, 17 Jan 2022 12:20:40 +0900

サイトのアクセスが増えてくると、ロードバランスを導入して複数の仮想マシンでウェブサーバーを立ち上げる必要性が出てきます。となると、必要になるのは例えば認証したユーザーのセッション情報を複数のマシンで共有すること。そこでredisの登場です。

セッションのデータはどこにある

Laravelのプログラムにアクセスすると、すぐに以下のようなセッションのためのクッキーがブラウザに作成されます。クッキーの名前は、.envのAPP_NAMEの値＋'_session'です。

そしてサーバー側でも、storage/framework/sessionsのディレクトリに以下のようにファイルが作成されます。

$ ls -l
...
-rw-r--r-- 1 www-data www-data 179 Jan 15 11:07 JursZgi5bCURHOze0BmxxKne8EEn0EObDAVT5dBn

セッションのファイルの中身は、serialize()されたデータです。

$ cat JursZgi5bCURHOze0BmxxKne8EEn0EObDAVT5dBn
a:3:{s:6:"_token";s:40:"0s8g4C7pDtn1HMgoR5KHzeuBUBEYeo8kOSq4YdpH";s:9:"_previous";a:1:{s:3:"url";s:21:"http://repos.test/l8x";}s:6:"_flash";a:2:{s:3:"old";a:0:{}s:3:"new";a:0:{}}}%

以上がデフォルトのセッションの設定です。

さて、ロードバランスを導入して、１つのウェブサイトのアクセスを複数のマシンで処理するとなると、アクセスするユーザーが実際にどのマシンにアクセスするかは、毎回のアクセスごとに変わります。最初のアクセスはマシン１のウェブサーバーだけれど、次はマシン２のウェブサーバーとか。セッションがファイルに保管されるなら、セッションがそれぞれのマシンのファイルで作成されることになり、もしマシン１でログインしたなら、その認証情報を含むセッションはマシン１のみに存在し、マシン２にアクセスすると認証されていないという問題が起こります。

この問題を解決するには、セッションの情報を複数のマシンで共有する要があります。セッションのデータを違うサーバーで一元管理して、どのマシンのLaravelも同じセッションにアクセスすることができるようにするのです。それを実現するのが、redisサーバーです。

ローカル環境でredisを立ち上げる

ライブの環境では、awsのelasticcacheなどのサービスを使用しますが、ここではローカル環境でredisサーバーを立ち上げます。

以下は私のWindowsのWSLのUbuntuの環境でのredisサーバーのインストールです。

$ sudo apt install redis-server

/etc/redis/redis.confの以下の部分の設定が、

/etc/redis/redis.conf

...
# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
#   supervised no      - no supervision interaction
#   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
#   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
#   supervised auto    - detect upstart or systemd method based on
#                        UPSTART_JOB or NOTIFY_SOCKET environment variables
# Note: these supervision methods only signal "process is ready."
#       They do not enable continuous liveness pings back to your supervisor.
supervised systemd
...

supervised systemd となるように確認あるいは編集してから、以下を実行してredisサーバーをスタートさせます。

$ sudo service redis-server start

Laravelでredisの設定

Laravelでredisを使用するには、まず、以下のパッケージのインストールが必要です。

$ composer require predis/predis

また、以下でRedisのファサードのエイリアスが定義されていることを確認してください。コメントされているかもしれません。

config/app.php

...
    'aliases' => [
...
        'Redis' => Illuminate\Support\Facades\Redis::class,
...

次に、.envで以下の環境変数を設定します。

.env

...
SESSION_DRIVER=redis #　デフォルトではこれはfile
REDIS_CLIENT=predis
REDIS_URL="tcp://127.0.0.1:6379?database=2" # ローカル環境のredisサーバー用
REDIS_PASSWORD=

# aws elastic cacheを使用すると以下のような設定
# REDIS_URL="tls://master.xxxx.cache.amazonaws.com:6379?database=2"
# REDIS_PASSWORD="xxxxx"
...

REDIS関連の環境変数は、データベースの設定ファイルで定義されています。

config/database.php

...
   'redis' => [

        'client' => env('REDIS_CLIENT', 'phpredis'),

        'options' => [
            'cluster' => env('REDIS_CLUSTER', 'redis'),
            'prefix' => env('REDIS_PREFIX', Str::slug(env('APP_NAME', 'laravel'), '_').'_database_'),
        ],

        'default' => [
            'url' => env('REDIS_URL'),
            'host' => env('REDIS_HOST', '127.0.0.1'),
            'password' => env('REDIS_PASSWORD', null),
            'port' => env('REDIS_PORT', '6379'),
            'database' => env('REDIS_DB', '0'),
        ],
...

redisのセッションにアクセスする

さて、設定が完了したところで、ブラウザでサイトにアクセスしてみます。その後、tinkerでセッションの値が作成されるか見てみましょう。

>>> Redis::keys('*')
=> [
     "laravel_database_laravel_cache:Z6UYF4Af706mB1WGJJwQZRXLvPF7b8ffTy70HTe6",
   ]

ローカル環境では、私一人しかアクセスしていないので、セッションのキーは１つしかありません。そのキーに対応する値を見るには、REDIS_PREFIXで指定されている、laravel_database_以降の文字列をReids::get()の引数に指定する必要あります。

>>> Redis::get('laravel_cache:Z6UYF4Af706mB1WGJJwQZRXLvPF7b8ffTy70HTe6')
=> "s:179:"a:3:{s:6:"_token";s:40:"h3xxEGjtBqajmdLG8LjcP1UKBTiCtfqmGSGlyiDL";s:9:"_previous";a:1:{s:3:"url";s:21:"http://repos.test/l8x";}s:6:"_flash";a:2:{s:3:"old";a:0:{}s:3:"new";a:0:{}}}";"
>>>

セッションの値が見えましたね。

DNSを使ってメールアドレスをチェック

Sun, 09 Jan 2022 01:43:32 +0900

「お客さんにメールが届かないのでどうかして？」というＣＳからの質問。見てみるとexample@yahoo.comであるところ、example@yahpo.comになっていたりします。たった１文字違いですが、会員登録してもこのためにメールが届かないばかりか、次回からは多分ログインもできません。もちろんお客さんの間違いですが、登録時にこれが通ってしまうというのは問題です。これをどうかしたいです。

緩いメールアドレスのバリデーション

Laravelのデフォルトのメールアドレスのバリデーションemailは、結構緩いです。どれだけ緩いが実例見てみましょう。以下は、tinkerを使って、test@gmailという不正なメールアドレスチェックします。

>>> $v = validator(['email' => 'test@gmail'], ['email' => 'required|email'])
=> Illuminate\Validation\Validator {#3534
     +customMessages: [],
     +fallbackMessages: [],
     +customAttributes: [],
     +customValues: [],
     +excludeUnvalidatedArrayKeys: null,
     +extensions: [],
     +replacers: [],
   }
>>> $v->passes()
=> true

あっさり、通ってしまいます。

また、example.comとかのドメイン名は実在しないのに、これも通ります。

>>> $v = validator(['email' => 'test@example.com'], ['email' => 'required|email'])
...
>>> $v->passes()
=> true

email:dnsの登場

メールアドレスの＠マークの後ろの部分、例えば、test@example.comなら、example.comの部分、はドメイン名と言ってインターネットでは非常に重要なデータなのですが、このドメインが実在するかどうか、そしてメールを受け取るかどうかがわかれば、少なくともメールアドレスのタイポは登録時に警告できますね。

それを利用したのが、email:dnsのバリデーションルールです。早速、tinkerで試してみましょう。

>>> $v = validator(['email' => 'test@gmail'], ['email' => 'required|email:dns'])
...
>>> $v->passes()
=> false

>>> $v = validator(['email' => 'test@example.com'], ['email' => 'required|email:dns'])
...
>>> $v->passes()
=> false

>>> $v = validator(['email' => 'test@yahpo.com'], ['email' => 'required|email:dns'])
...
>>> $v->passes()
=> false

素晴らしいです、みな通りません！

email:dnsの使用において注意が必要なのは、それを利用するには、以下の国際化関数、intlのライブラリが必要です。 https://www.php.net/manual/ja/book.intl.php

dns_get_record()

ちょっとemail:dnsの仕組みを探ってみましょう。Laravelのマニュアルによると、egulias/email-validatorのパッケージを使用しているそうな。そこから関心のコードの一部を掲載します。

https://github.com/egulias/EmailValidator/blob/3.x/src/Validation/DNSCheckValidation.php

...
class DNSCheckValidation implements EmailValidation
{
    /**
     * @var int
     */
    protected const DNS_RECORD_TYPES_TO_CHECK = DNS_MX + DNS_A + DNS_AAAA;

    /**
     * Reserved Top Level DNS Names (https://tools.ietf.org/html/rfc2606#section-2),
     * mDNS and private DNS Namespaces (https://tools.ietf.org/html/rfc6762#appendix-G)
     */
    const RESERVED_DNS_TOP_LEVEL_NAMES = [ //これらのドメイン名はみなエラーとなります
        // Reserved Top Level DNS Names
        'test',
        'example',
        'invalid',
        'localhost',

        // mDNS
        'local',

        // Private DNS Namespaces
        'intranet',
        'internal',
        'private',
        'corp',
        'home',
        'lan',
    ];
   ...

 private function validateDnsRecords($host) : bool
    {
        // A workaround to fix https://bugs.php.net/bug.php?id=73149
        /** @psalm-suppress InvalidArgument */
        set_error_handler(
            static function (int $errorLevel, string $errorMessage): ?bool {
                throw new \RuntimeException("Unable to get DNS record for the host: $errorMessage");
            }
        );

        try {
            // Get all MX, A and AAAA DNS records for host
            $dnsRecords = dns_get_record($host, static::DNS_RECORD_TYPES_TO_CHECK);
        } catch (\RuntimeException $exception) {
            $this->error = new InvalidEmail(new UnableToGetDNSRecord(), '');

            return false;
        } finally {
            restore_error_handler();
        }
...

上の４５行目見てください。dns_get_record()なるphp関数があったのですね。 https://www.php.net/manual/ja/function.dns-get-record.php

上の説明によると、こんなしてドメイン情報取得できるようです。

>>> dns_get_record("yahpo.com", DNS_MX);
=> [
     [
       "host" => "yahpo.com",
       "class" => "IN",
       "ttl" => 0,
       "type" => "MX",
       "pri" => 0,
       "target" => "",
     ],
   ]
>>> dns_get_record("yahoo.com", DNS_MX);
=> [
     [
       "host" => "yahoo.com",
       "class" => "IN",
       "ttl" => 0,
       "type" => "MX",
       "pri" => 1,
       "target" => "mta5.am0.yahoodns.net",
     ],
     [
       "host" => "yahoo.com",
       "class" => "IN",
       "ttl" => 0,
       "type" => "MX",
       "pri" => 1,
       "target" => "mta6.am0.yahoodns.net",
     ],
     [
       "host" => "yahoo.com",
       "class" => "IN",
       "ttl" => 0,
       "type" => "MX",
       "pri" => 1,
       "target" => "mta7.am0.yahoodns.net",
     ],
   ]

最初のタイポのドメイン名のtargetは存在しないけれど、正式なドメインは３つtargetを返しています。Laravelのemail:dnsはこれを利用しているのですね。

最後に

メールのバリデーションには、email:dnsの他にもrfcとかstrictとかspoofとかあります。 emailとemail:rfcは同じです。また、email:rfc,dnsとように合わせての使用も可能です。

あと大事なのは、バリデーションでは必ず弾かれてしまうが、test.@docomo.ne.jpのようにドットが不正な場所にあるにもかかわらず実在するメールアドレスの対応です。docomo.ne.jpやezweb.ne.jpではその不正を許す必要あります。まだ使っている人いるんですよ。

SQL文を画面で入力して安全に実行して結果を返す

Tue, 14 Dec 2021 07:46:54 +0900

Laravelのようなフレームワークが登場する以前は、誰しもSQL文を作成してmysqli_query()のような関数に引数として渡して実行していたものです。QueryBuilderやEloquentのORMなぞ聞いたこともない時代でした。その過去に戻るわけではないですが、それと同じこと、つまりSQL文を管理画面に直接入力して実行できないかと考えた次第です。

こんなものが欲しい

以下の画面のように、SQL文を入力してその実行ボタンを押すと結果を画面で表示してくれるものが欲しいのです。この画面では、テスト１とテスト２の２つサイトがあり、それぞれのサイトで使用されているDBに対してSQL文を実行しています。

なぜこのような機能が欲しいかというと、お客さんのビジネスでは今月の売り上げなどの定型のレポートだけでなく、例えば、ある時期にこの商品を購入したお客さんの中で何人が違う時期（最初の時期以降）で同じ商品を買ったのか、とかアドホックのリクエストが結構あるからです。

また、お客さんだけでなくシステム管理者は特定のDBテーブルのidの最大値が使用DBタイプの最大値に近づいていないか、など定期的に実行するクエリーも必要です。

しかし、これらのためにいちいち画面を伴うコントローラを作成するのは面倒であるし、そのときだけに必要で後には要らなくなることも多々です。それらのときに、上のようにカスタムのSQLを入力するだけで実行でき結果を見れる、さらにクエリと結果を保存し後に必要なときにも実行できる、としたら素晴らしいと思いませんか！

管理画面でSQL文を直接入力して実行するホラー

さて、欲しい機能は素晴らしいのだけれど、直接のSQL文入力・実行でホラーとなる状況はいくつかあります。特に以下の２点。

私の目的はあくまでもクエリーでありSELECTのSQL文だけの実行です。しかし、INSERTやUPDATEさらにDELETEもSQL文なので入力されて実行されたら、完全なホラーです。これらのSQL文が入力させないようにするか、入力しても実行を避ける方法が必要です。

次は、クエリーの実行時間がやたらに長くなりシステムの負荷となることです。入力するクエリーの実行に要する時間は、クエリーが複雑となると実行する前にわかるものではありません。もし、クエリーの実行時間が指定した実行所要時間以上となったら実行を自動的に打ち切りにしたいです。

ということで、これらを避ける対策を前もって考えます。

LaravelでどうSQL文を実行する？

ホラーの対策を考える前に、まず、LaravelでSQL文を実行してみましょう。tinkerで試してみます。

>>> DB::select("select count(*) as '会員数' from users");
=> [
     {#3514
       +"会員数": 2,
     },
   ]

簡単ですね。項目名にもUTF8なら日本語でエイリアスとできます。

しかし、恐ろしいのは先に述べたように、こういうこともできてしまいます。

>>> DB::select("delete from users");
=> []

>>> User::all();
=> Illuminate\Database\Eloquent\Collection {#3529
     all: [],
   }

DBテーブルは空になってしまいました。

DB更新のSQL文の実行を防ぐ

SQL文を簡単に実行できることがわかったところで、ホラーの対策を考えてみます。いくつかあります。

その１

簡単なのはSQL文にinsert, update, deleteなどが含まれていたら、プログラムで実行させない。preg_matchとか使用してバリデーションです。しかし、updated_atとかの項目がSQL文にあったら、それもマッチしてしまうので、updateの前後にスペースがあるかなどのマッチのパターンの調整が必要です。

その２

DBのユーザーを読み込み専用とする。これがベストですがいちいちそのために読み込み専用のDBユーザー作成する必要があります。ホストするプロバイダーによっては読み込み専用と読み書きのユーザーを分けて提供してくれるところもあります。.envあるいはconf/database.phpでの設定に工夫も必要となります。

その３

DBの読み込みセッションを使う。私が使用しているMySQL5.7では以下のようにたとえDBユーザーの権限に書き込みがあっても、以下のような読み込みセッションでDB更新の句クエリーを実行不可とできます。以下のDB::statement('SET SESSION TRANSACTION READ ONLY')の実行後は、レコード削除のSQL文のはエラーとなります。

>>> DB::select('select count(*) from users')
=> [
     {#3436
       +"count(*)": 1,
     },
   ]

>>> DB::statement('SET SESSION TRANSACTION READ ONLY')
=> true

>>> DB::select('delete from users')
Illuminate\Database\QueryException with message 'SQLSTATE[25006]: Read only sql transaction: 1792 Cannot execute statement in a READ ONLY transaction. (SQL: delete from users)'

>>> DB::select('select count(*) from users')
=> [
     {#3441
       +"count(*)": 1,
     },
   ]

クエリーの実行所有時間の制限

こちらは、DBセッションにおける最大実行時間を設定することで、制限をかけることが可能です。以下は、最大実行時間を1000ミリ秒、つまり１秒としました。２秒のスリープの実行では１秒を超えたときにエラーとなります。

>>> DB::statement('SET SESSION MAX_EXECUTION_TIME=1000')
=> true

>>> DB::select('select sleep(1) from users')
=> [
     {#3438
       +"sleep(1)": 0,
     },
   ]

>>> DB::select('select sleep(2) from users')
Illuminate\Database\QueryException with message 'SQLSTATE[HY000]: General error: 3024 Query execution was interrupted, maximum statement execution time exceeded (SQL: select sleep(2) from users)'

最後に

安全にクエリのSQL文の実行の仕方が解ったところで、実行したときにクエリーの実際の所有時間も知りたいですね。それは以下のように、前もってDB::listen()を実行すれば、実行後に取得できます。ここでも時間単位はミリ秒です。

>>> $time = 0
=> 0

>>> DB::listen(function($query) use (&$time) { $time = $query->time; })
=> null

>>> DB::select('select count(*) from users')
=> [
     {#3438
       +"count(*)": 1,
     },
   ]

>>> $time
=> 0.48

HTTPテストでURLに日本語が含まれている場合の意図せぬ挙動

Mon, 06 Dec 2021 12:01:33 +0900

LaravelではFeatureテストが簡単に行えるように、便利なテスト用メソッドが用意されています。今回はそちらを使っていてハマってしまった意図せぬ挙動について紹介します。

HTTPテスト

例えば特定のURLにリクエストを投げ、正しいレスポンスが返されるか？などのFeatureテストをする際に、Laravelでは以下のようなテストが書けます。

tests/Feature/ExampleTest.php

<?php

namespace Tests\Feature;

use Illuminate\Foundation\Testing\WithoutMiddleware;
use Tests\TestCase;

class ExampleTest extends TestCase
{
    public function test_a_basic_request()
    {
        $response = $this->get('/'); // HTTPリクエストをシミュレート

        $response->assertStatus(200); // レスポンスのステータスコードテスト

        $response->assertSee('Laravel'); // レスポンスに指定した文字列が含まれているかテスト
    }
}

上のテストでは/にGETリクエストを投げ、リクエストが正常に処理されたかステータスコード200をチェック、そして返されたレスポンスにLaravelという文字列が含まれているかをテストします。

インストール直後の状態では/にアクセスすると以下のページを返しますので、テストは成功するはずです。

URLに日本語が含まれている場合の挙動

さて、ここからが本題です。私がハマったのはURLに日本語が含まれている場合のテストです。 他の開発者のwindows環境ではパスするテストが、私のmacOS環境では必ず失敗してしまう、 という状況が発生しました。

どんなテストかを説明する為に例を用意しました。以下のようなページがあるとします。

入力した検索ワードをそのまま出力するシンプルなページです。

viewはこんな感じ。

resources/views/search.blade.php

<!DOCTYPE html>
<html lang="en">
<head>
    <title>Search</title>
</head>
<body>
    <form action="/search" method="get">
        <input type="text" name="word" value="">
        <input type="submit" value="検索">
    </form>

    <h1>{{ $word }}</h1>
</body>
</html>

routeはこんな感じ。

routes/web.php

<?php

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Route;

Route::get('/search', function(Request $request) {
    $word = $request->get('word', '');

    return view('search', compact('word'));
});

前項のExampleTestをこのページに関するテストに書き換えてみましょう。

tests/Feature/ExampleTest.php

<?php

namespace Tests\Feature;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

class ExampleTest extends TestCase
{

    public function test_search_page()
    {
        $response = $this->get('/search?word=ほげ');

        $response->assertStatus(200);

        $response->assertSee('ほげ');
    }
}

“ほげ"というワードで検索した場合をシミュレートする為、/search?word=ほげにリクエストを投げ、レスポンスに文字列「ほげ」が含まれているかテストしています。

テストを実行してみましょう。

vendor/bin/phpunit --filter ExampleTest

PHPUnit 9.5.10 by Sebastian Bergmann and contributors.

.F                                                                  2 / 2 (100%)

Time: 00:00.138, Memory: 20.00 MB

There was 1 failure:

1) Tests\Feature\ExampleTest::test_search_page
Failed asserting that '<!DOCTYPE html>\n

~~省略~~

    <h1></h1>\n
</body>\n
</html>' contains "ほげ".

レスポンスに「ほげ」が含まれていない、との事でテストが失敗してしまいました。確かに、レスポンス内で検索ワードが表示される箇所が

    <h1></h1>\n

となっています。

ちなみに、検索文字列を「hoge」にした場合はパスします。

~~~
    public function test_search_page()
    {
        $response = $this->get('/search?word=hoge'); // hoge に変更

        $response->assertStatus(200);

        $response->assertSee('hoge'); // hoge に変更
    }
~~~

vendor/bin/phpunit --filter ExampleTest
PHPUnit 9.5.10 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 00:00.138, Memory: 20.00 MB

OK (2 tests, 3 assertions)

なぜでしょう？

parse_url()のバグ

$this->get()のソースを解析してみると、 vendor/symfony/http-foundation/Request.php 355行目のparse_url()にてURLからパースしたクエリ文字列が文字化けしていました。

以下はtinkerで同じコードを実行した際の結果です。

parse_url('http://127.0.0.1:8000/search?word=ほげ');
=> [
     "scheme" => "http",
     "host" => "127.0.0.1",
     "port" => 8000,
     "path" => "/search",
     "query" => b"word=ã_»ã__",
   ]

文字化けしていますね。ググってみるとGitHubで以下のIssueを見つけました。

UTF-8 URIs are broken by parse_url when locale is set

parse_url()はplatform(macなど)やlocaleの設定によってパースした文字列が壊れる場合があるとのこと。2010年から報告されているこちらのPHPのバグのようです。

urlencode()で解決

回避策として予め日本語部分をurlencode()でエンコードすれば良さそうです。 ExampleTestを以下のように修正しました。

tests/Feature/ExampleTest.php

~~~
    public function test_search_page()
    {
        $word = urlencode('ほげ');  // 予めURLエンコード

        $response = $this->get('/search?word='.$word);

        $response->assertStatus(200);

        $response->assertSee('ほげ');
    }
~~~

テストが通るようになりました。

vendor/bin/phpunit --filter ExampleTest
PHPUnit 9.5.10 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 00:00.136, Memory: 20.00 MB

OK (2 tests, 3 assertions)

まとめ

HTTPテストで日本語を含むURLにリクエストを投げる際は、日本語部分をURLエンコードするのが良さそうです。

Laravelのブレードでの {{ }} と {!! !!} の違い

Wed, 24 Nov 2021 07:19:05 +0900

ブレードで変数の値を表示するのによく使う括弧。{{ }} と {!! !!}２種類あります。これらに関しての話です。

{{ }} と {!! !!}の違い

{{ }} と {!! !!}の違いは、いたって簡単です。前者はhtmlをエスケープして、後者はエスケープしません。と言っても？？なので、具体的に以下のようなブレードを作成して、違いを見てみましょう。

resources/views/test.blade.php

{{ $x }}
{!! $x !!}

tinkerでこの$xに値を入れてブレードをビューすると、以下のようなHTML文が出力されます。

>>> view('test')->with(['x' => '<h1>hello</h1>'])->render();
=> """
   &lt;h1&gt;hello&lt;/h1&gt;\n
   <h1>hello</h1>\n
   """

前者の表示は、HTMLのタグが見事にエスケープされていますが、後者はHTMLのタグがそのまま残っています。ブラウザでこれらを閲覧すると、

と表示の違いがはっきりします。

PHPにコンパイルされたブレード

先の例で使用したtest.blade.phpは、サーバーから表示される前にphpにコンパイルされてstorage/framework/viewsにキャッシュされます。コンパイルされたブレードの中身を見ると、

storage/framework/views/4ad4f1be91eef212ba8e4b67c67ee18a0f640a9a.php

<?php echo e($x); ?>

<?php echo $x; ?>

<?php /**PATH /var/www/repos/l8x/resources/views/test.blade.php ENDPATH**/ ?>

お馴染みのphpファイルです（ブレードはphpファイル拡張子ですがphpファイルではありません）。なるほど単に標準のPHP関数のecho()を使用しています。しかし、前者において、e()という関数は標準のPHP関数ではありません。調べてみると、これはLaravelのヘルパーです。以下にその定義を掲載します。

vendor/laravel/framework/src/Illuminate/Support/helpers.php

...
   /**
     * Encode HTML special characters in a string.
     *
     * @param  \Illuminate\Contracts\Support\DeferringDisplayableValue|\Illuminate\Contracts\Support\Htmlable|string|null  $value
     * @param  bool  $doubleEncode
     * @return string
     */
    function e($value, $doubleEncode = true)
    {
        if ($value instanceof DeferringDisplayableValue) {
            $value = $value->resolveDisplayableValue();
        }

        if ($value instanceof Htmlable) {
            return $value->toHtml();
        }

        return htmlspecialchars($value ?? '', ENT_QUOTES, 'UTF-8', $doubleEncode);
    }
...

標準関数のhtmlspecialchars()が最終的にはHTMLタグをエスケープしていることわかります。

HtmlString

さて、ブレードで使用されている括弧の意味が解ったところで、先のtest.blade.phpを以下のように編集します。csrf_field()は、LaravelのCSRFトークンのためのヘルパー関数です。

resources/views/test.blade.php

{{ csrf_field() }}

これをtinkerで先と同様にレンダリングします。今回は変数の渡しなしです。

>>> view('test')->render()
=> "<input type="hidden" name="_token" value="">\n"

おかしいですね。二重波括弧なのに、HTMLタグがエスケープされていません。どうしてでしょう？

csrf_field()の定義を見てみましょう。

vendor/laravel/framework/src/Illuminate/Support/helpers.php

...
    /**
     * Generate a CSRF token form field.
     *
     * @return \Illuminate\Support\HtmlString
     */
    function csrf_field()
    {
        return new HtmlString('<input type="hidden" name="_token" value="'.csrf_token().'">');
    }
...

この関数が返しているのは、文字列ではなくHtmlStringのオブジェクトです。このオブジェクトがブレードでの括弧の変数の値とすると、エスケープ処理がされないのです。tinkerで試してみましょう。

>>> use Illuminate\Support\HtmlString;
>>> $x = new HtmlString('<h1>hello</h1>');
=> Illuminate\Support\HtmlString {#3517
     html: "<h1>hello</h1>",
   }
>>> e($x)
=> "<h1>hello</h1>"

HtmlStringを使う意味

表示される値にHTMLタグが含まれるかどうか前もってわかっていれば、{{ }} と {!! !!}の使いわけできますが、たいていはブレードを作成するのは開発者ではなくデザイナーさんです。HTML文を含むときに文字列ではなく、HtmlStringのオブジェクトとすれば、迷わずにいつも{{ }}の使用となります。

Laravel 8.x更新で変わったこと（４）php-cs-fixer

Wed, 17 Nov 2021 13:00:34 +0900

Laravel 8とは直接は関係ないのですが、以前ここで紹介したコード整形プログラムのphp-cs-fixerもバージョンアップとなりました。それにより使用していたその設定ファイルも変更の必要あります。

php-cs-fixerはコードを整形するプログラムで、開発者がひとりでももちろんですが複数となったときに特にコードのスタイルの統一に便利です。スタイルの指定、例えばインデントをタブでなく４つの空白文字とする、とかの指定は、すべてphp-cs-fixerの設定ファイルで行います。

まず、バージョン3となって、その設定ファイルとキャッシュファイル名が以下のように変更となりました。

バージョン２では、

.php-cs
.php-cs.cache

がバージョン３では、

.php-cs-fixer.php
.php-cs-fixer.cache

また、スタイル指定のルールも少し変更があります。Laravelのプロジェクトのために、以前と同様に以下のスレッドから取得して

https://gist.github.com/laravel-shift/cab527923ed2a109dda047b97d53c200

私のgistとしました。この記事の最後に掲載したのでフリーで使用してください！

設定のルールに関しては以下に説明あります。調査が必要なら参考に。

https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/master/doc/rules/index.rst

php-cs-fixerの使用はいたって簡単です。

新規に使用するなら、まず

$ composer require friendsofphp/php-cs-fixer --dev

を実行してインストールし、設定ファイル.php-cs-fixer.phpを私のgistから作成して、Laravelのプロジェクトのルートディレクトリから以下を実行すれば、必要な整形を自動でしてくれます。

$ vendor/bin/php-cs-fixer fix

以下がLaravelのプロジェクト用の設定ファイルです。

アクセサを無視して値を取得する

Sat, 13 Nov 2021 22:46:26 +0900

DBから取得した値を自動で加工してくれる便利な機能のアクセサですが、時としてアクセサを無視してDBから取得した素の値が欲しいケースがあります。そんな時に使える方法を３つ紹介します。

どういうケース？

例えば、公式ドキュメントの「アクセサの定義」には例として以下のコードが紹介されています。

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    /**
     * ユーザーのファーストネームを取得
     *
     * @param  string  $value
     * @return string
     */
    public function getFirstNameAttribute($value)
    {
        return ucfirst($value);
    }
}

そして、定義したアクセサにより名前の出力は頭文字が大文字となります。

$user->first_name;    // DBに保存されている素の値は"hikaru"
>> "Hikaru"

今回はこのようにアクセサを定義したものの、例外的にDBに保存されている素の値である"hikaru"が欲しくなった、という時に使える方法の解説です。

1. $attributes

まず１つ目に、アクセサを定義したクラス内で使える方法です。DBから取得した素の値は$attributesというprotectedプロパティに格納されているため、Modelクラス内からアクセス可能です。例えば前項のUserクラスにgetPlainFirstName()を追加してみましょう。

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    /**
     * ユーザーのファーストネームを取得
     *
     * @param  string  $value
     * @return string
     */
    public function getFirstNameAttribute($value)
    {
        return ucfirst($value);
    }

    public function getPlainFirstName()
    {
        return $this->attributes['first_name'];
    }
}

メソッドを呼び出すと素の値が取得できます。

$user->getPlainFirstName();
>> "hikaru"

因みに、$attributesはvendor/laravel/framework/src/Illuminate/Database/Eloquent/Concerns/HasAttributes.phpにて定義されています。

2. getRawOriginal()

続いて、Userクラス外から素の値にアクセスする方法として、getRawOriginal()が使えます。

$user->getRawOriginal('first_name');
>> "hikaru"

１点注意が必要なのは、このメソッドは$originalというプロパティから値を取得しています。$originalにはDBから取得した時点の値を保持する配列が格納されており、getDirty()などで変更が加わった項目を判別する際などに使われています。

つまり、DBから取得した後に変更した値は取得できません。

$user->first_name = 'kenji';    // 名前を"hikaru"から"kenji"に変更
$user->getRawOriginal('first_name');    // $originalから値を取得するので"hikaru"のまま
>> "hikaru"

こちらのメソッドもHasAttributes.phpに定義されているのでソースを確認してみてください。

3. getAttributes()

最後に紹介するgetAttributes()は$attributesを返すメソッドです。Userクラス外からアクセスでき、DBから取得した後に値を変更しても変更後の値が取得できます。getRawOriginal()とは異なり引数でキーを指定できない（$attributesそのものを返す）為、取得後に項目を指定する必要があります。

$user->getAttributes()['first_name'];
>> "hikaru"

$user->first_name = "kenji";
$user->getAttributes()['first_name'];    // 変更後の値が取得できる
>> "kenji"

まとめ

以上、アクセサを無視してDBから取得した素の値を取得する方法３つの紹介でした。紹介しておいてなのですが、アクセサを無視しなければならない箇所がいくつもある場合は今回紹介した方法で置き換えるよりも、本当にそのアクセサが必要なのか？見直す方が良いかと思います。

Laravel 8.x更新で変わったこと（３）factoryがクラス化される

Fri, 05 Nov 2021 11:22:00 +0900

さらに引き続いて、最新のバージョンのLaravel 8.xの話です。今回はfactoryの話です。

結構変わりました。これもL7.xと比較してみましょう。

L7.xでは、namespaceがありません。

app/database/factories/UserFactory.php

/** @var \Illuminate\Database\Eloquent\Factory $factory */

use App\User;
use Faker\Generator as Faker;
use Illuminate\Support\Str;

/*
|--------------------------------------------------------------------------
| Model Factories
|--------------------------------------------------------------------------
|
| This directory should contain each of the model factory definitions for
| your application. Factories provide a convenient way to generate new
| model instances for testing / seeding your application's database.
|
*/

$factory->define(User::class, function (Faker $faker) {
    return [
        'name' => $faker->name,
        'email' => $faker->unique()->safeEmail,
        'email_verified_at' => now(),
        'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
        'remember_token' => Str::random(10),
    ];
});

L8.xでは、以下のようにnamespaceが入り、Factoryを継承したクラスとなりました。

app/database/factories/UserFactory.php

namespace Database\Factories;

use App\Models\User;
use Illuminate\Database\Eloquent\Factories\Factory;
use Illuminate\Support\Str;

class UserFactory extends Factory
{
    /**
     * The name of the factory's corresponding model.
     *
     * @var string
     */
    protected $model = User::class;

    /**
     * Define the model's default state.
     *
     * @return array
     */
    public function definition()
    {
        return [
            'name' => $this->faker->name(),
            'email' => $this->faker->unique()->safeEmail(),
            'email_verified_at' => now(),
            'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
            'remember_token' => Str::random(10),
        ];
    }

    /**
     * Indicate that the model's email address should be unverified.
     *
     * @return \Illuminate\Database\Eloquent\Factories\Factory
     */
    public function unverified()
    {
        return $this->state(function (array $attributes) {
            return [
                'email_verified_at' => null,
            ];
        });
    }
}

使用の方は、

L7.xでは、以下のようにクラスのないphp関数だったのが、

factory(App\User::class, 50)->create(); // Userのレコードを50作成

L8.xでは、

User::factory()->count(50)->create();

クラスメソッドとなります。

User::factory()として使えるのは、以下のようにUserモデルにおいてHasFactoryのトレイトを使用しているからです。

app/Models/User.php

namespace App\Models;

use Illuminate\Contracts\Auth\MustVerifyEmail;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable
{
    use HasApiTokens, HasFactory, Notifiable;
..

最後に、これもLaravel ShiftのアップグレードサービスですべてのFactoryの定義の変換とモデルのクラスの定義にuse HasFactory;を追加してくれるところまで自動変換してくれます。

Laravel 8.x更新で変わったこと（２）Route関連の変更

Wed, 03 Nov 2021 12:00:43 +0900

引き続いて、Laravel 8.x更新で変わったことです。今回はRoute関連の話です。

Laravel 8.x以前では、routes/web.phpの中身はこんな感じでした。

routes/web.php

Route::namespace('Auth')->middleware('guest')->group(function () {

    // Authentication Routes...
    Route::get('', 'LoginController@showLoginForm');
    Route::get('login', 'LoginController@showLoginForm')->name('login');
    Route::post('login', 'LoginController@login')->name('login-post');

    // Password Reset Routes...
    Route::get('password/reset', 'ForgotPasswordController@showLinkRequestForm')->name('password.forgot');
    Route::post('password/email', 'ForgotPasswordController@sendResetLinkEmail')->name('password.email');
    Route::get('password/reset/{token}', 'ResetPasswordController@showResetForm')->name('password.reset');
    Route::post('password/reset', 'ResetPasswordController@reset')->name('password.reset-post');
});

これが、Laravel 8.xでは、

routes/web.php

use App\Http\Controllers\Admin;
use App\Http\Controllers\Auth;
use App\Http\Controllers\User;
use Illuminate\Support\Facades\Route;

Route::middleware('guest')->group(function () {

    // Authentication Routes...
    Route::get('', [Auth\LoginController::class, 'showLoginForm']);
    Route::get('login', [Auth\LoginController::class, 'showLoginForm'])->name('login');
    Route::post('login', [Auth\LoginController::class, 'login'])->name('login-post');

    // Password Reset Routes...
    Route::get('password/reset', [Auth\ForgotPasswordController::class, 'showLinkRequestForm'])->name('password.forgot');
    Route::post('password/email', [Auth\ForgotPasswordController::class, 'sendResetLinkEmail'])->name('password.email');
    Route::get('password/reset/{token}', [Auth\ResetPasswordController::class, 'showResetForm'])->name('password.reset');
    Route::post('password/reset', [Auth\ResetPasswordController::class, 'reset'])->name('password.reset-post');

});

となります。

何が変わったかというと、今までのコントローラクラス名＠メソッド名（例：‘LoginController@showLoginForm’）が、コントローラクラスパスとメソッド名の配列（[Auth\LoginController::class, ‘showLoginForm’]）となりました。

この変更が動作するためには、RouteServiceProvider.phpのファイルの編集も必要です。 L7.xのバージョンでは、以下のように$namespaceがありますが、

app/Providers/RouteServiceProvider.php

namespace App\Providers;

use Illuminate\Foundation\Support\Providers\RouteServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Route;

class RouteServiceProvider extends ServiceProvider
{
    /**
     * This namespace is applied to your controller routes.
     *
     * In addition, it is set as the URL generator's root namespace.
     *
     * @var string
     */
    protected $namespace = 'App\Http\Controllers';

...
    /**
     * Define the "web" routes for the application.
     *
     * These routes all receive session state, CSRF protection, etc.
     *
     * @return void
     */
    protected function mapWebRoutes()
    {
        Route::middleware('web')
            ->namespace($this->namespace)
            ->group(base_path('routes/web.php'));
    }

    /**
     * Define the "api" routes for the application.
     *
     * These routes are typically stateless.
     *
     * @return void
     */
    protected function mapApiRoutes()
    {
        Route::prefix('api')
            ->middleware('api')
            ->namespace($this->namespace)
            ->group(base_path('routes/api.php'));
    }
}

L8.xのバージョンでは、それを削除します。mapWebRoute()とmapApiRoute()からもnamespace()を削除します。

app/Providers/RouteServiceProvider.php

namespace App\Providers;

use Illuminate\Foundation\Support\Providers\RouteServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Route;

class RouteServiceProvider extends ServiceProvider
{

...
    /**
     * Define the "web" routes for the application.
     *
     * These routes all receive session state, CSRF protection, etc.
     *
     * @return void
     */
    protected function mapWebRoutes()
    {
        Route::middleware('web')
            ->group(base_path('routes/web.php'));
    }

    /**
     * Define the "api" routes for the application.
     *
     * These routes are typically stateless.
     *
     * @return void
     */
    protected function mapApiRoutes()
    {
        Route::prefix('api')
            ->middleware('api')
            ->group(base_path('routes/api.php'));
    }
}

さて、上の変更によりプログラムの実行が速くなったとかのメリットはないと思いますが、この形式になることにより改善されたのは、vscodeのようなエディターにおいてweb.phpのファイル内から簡単にコントローラクラスの定義にジャンプできることです。エディターあるいはエディターのプラグインがクラスを認識できるようになったためです。

とは言え、このコード変更を手動でやるのはとても面倒ですね。私の大きいプロジェクトでrouteがたくさんあり、242箇所も変更が必要な部分があります。このようなときには、Laravel Shiftのサービスを使用することを勧めます。以前に、ここで紹介していますが、あれから数年、サイトのデザインとか変わっていますが基本的には同じサービスです。

最後に、上で編集したweb.phpやRouteServiceProvider.phpを何も編集せずにしておくことも可能です。それでも問題なくL8.xで動作します。

Laravel 8.x更新で変わったこと（１）メンテナンス中のアクセス

Sun, 31 Oct 2021 12:48:59 +0900

Laravel 7.xから8.xに更新して変わったことを紹介していきます。最初は、メンテナンスモードに関して。

Laravel 7.xのメンテナンスモードに関して書いたのは、たった１年前のことです。メンテナンス画面：php artisan up & downでは、

Laravelの経験が長くなると、つまり初期のバージョンから使用していると、昔のやり方しか知らずに過ごしていることがあります。... ということでやり方学びなおします

なんて書いていましたが、Laravel 8.xの更新でまたもや学びなおしです。

php artisan downのコマンドはそのままですが、それに追加するオプションが変わりました。

まず、比較してみましょう。

Laravel 7.xにおいて、

$ php artisan down --help

を実行すると、以下のようのなオプションがあります。英語のヘルプは日本語に私が訳しています。

Usage:
  down [options]

Options:
      --message[=MESSAGE]  メンテナンス画面に表示するメッセージ
      --retry[=RETRY]      HTTPヘッダーのRetry-Afterの秒数を設定
      --allow[=ALLOW]      メンテナンスモードでもアクセスできるIPアドレスを指定

同じコマンドラインをLaravel 8.xで実行すると、

Usage:
  down [options]

Options:
      --redirect[=REDIRECT]  メンテナンス中は指定のURLに皆リダイレクト<strong>
      --render[=RENDER]      メンテナンス中に表示する画面を指定
      --retry[=RETRY]        HTTPヘッダーのRetry-Afterの秒数を設定
      --refresh[=REFRESH]    HTTPヘッダーのRefreshの秒数を設定
      --secret[=SECRET]      メンテンナンスをバイパスするシークレットコードを指定
      --status[=STATUS]      メンテナンス中に返すHTTPのステータスコードを指定（デフォルト503）

オプションの数が増えただけでなく、–messageとか–allowとかが無くなってしまいました。

これは問題です。　–allowなしにどうやって開発者あるいは関係者だけがメンテナンス中のサイトにアクセスできるのでしょうか？

Laravel 8.xはそれを、–secretのオプションで解決します。実行は、例えば

$ php artisan down --secret=secret-code

としてメンテンナンスに入り、ブラウザーで以下のURLでアクセスすると、あたかもメンテナンスなしの状態で画面にアクセスできます。

https://example.com/secret-code

これはとても素晴らしいです。今まで自宅のIPが変わったりしていちいち調べて–allowにIPアドレスを指定していましたが、その必要がなくなります。

仕組みとしては、いたって簡単で上のようにシークレットコードでアクセスしたら、larave_maintenanceというクッキーにその値を暗号化して入れて、それが正しいかをチェックしているようです。

もちろん、先の例のようにsecret-codeではあまりにも簡単すぎるので実際には以下のようにtinkerで値を作成することを勧めます。

>>> Str::random()
=> "mdcSOnkB5fT2rGAC"
>>> (string) Str::uuid()
=> "fe3a8010-bdda-4972-a0bb-ab96c17841a6"
>>>

Laravel 8.xのインストール

Mon, 04 Oct 2021 06:11:14 +0900

もしかして、最新のLaravelのバージョンを紹介できるのは初めて？いつも遅れて現在のひとつ前のバージョンを紹介してきたのですが、半年に１回のリリースが年に１回となり、さらに次のバージョンのリリースが遅れて、ついに私に追いつかれてしまったのです。

バージョン

毎回のように、まずサポートのスケジュールを見てみましょう。

なるほど次のバージョン９がLTS（長期サポート）となりますね。

新規プロジェクト

composerはすでにシステムにインストールされていると仮定して、以下のコマンドがl8xのディレクトリ名でLaravelをインストールします。ちなみに、phpは最低7.3のバージョンが必要です。私の環境ではすでに7.4なので大丈夫。

$ composer create-project --prefer-dist laravel/laravel:^8.0 l8x

ウェブサーバーなどが書き込みを行うディレクトリにはパーミッションが必要です。

$ cd l8x
$ chmod -R a+w storage bootstrap/cache

以下を実行して、

$ php artisan serve

ブラウザでhttp://localhost:8000にアクセスすると、ページを見ることができます。

前の7.xのバージョンとは変わりましたね。TailWind CSSの使用のためかな。

これ以降の変更をみるために、この時点でパージョン管理をしておきましょう。

$ cd l8x
$ git init
$ git add .
$ git commit -am "init"

ユーザー認証のパッケージ

さて、ここからが前のバージョンと大幅に変わったところです。Laravelは基本的にいわゆるバックエンド、サーバーアプリなのですが、使用するフロントエンドにも好みがあり、TailWind、VueJS, LivewireをLaravelの認証のパッケージを積極的に採用しています。今までのLaravel UIパッケージの代わりに、Laravel Breezeの登場です。そよ風のように優しく（易しく？）インストールということでしょうか。

まず、必要なパッケージのインストールから、

$ composer require laravel/breeze --dev

次に、以下を実行して会員登録画面やログイン画面などを作成します。bladeだけでなく、vueやreactの指定も可能です。

$ php artisan breeze:install blade

これにより以下のファイルが追加あるいは編集されています。

        new file:   app/Http/Controllers/Auth/AuthenticatedSessionController.php
        new file:   app/Http/Controllers/Auth/ConfirmablePasswordController.php
        new file:   app/Http/Controllers/Auth/EmailVerificationNotificationController.php
        new file:   app/Http/Controllers/Auth/EmailVerificationPromptController.php
        new file:   app/Http/Controllers/Auth/NewPasswordController.php
        new file:   app/Http/Controllers/Auth/PasswordResetLinkController.php
        new file:   app/Http/Controllers/Auth/RegisteredUserController.php
        new file:   app/Http/Controllers/Auth/VerifyEmailController.php
        new file:   app/Http/Requests/Auth/LoginRequest.php
        modified:   app/Providers/RouteServiceProvider.php
        new file:   app/View/Components/AppLayout.php
        new file:   app/View/Components/GuestLayout.php
        modified:   composer.json
        modified:   composer.lock
        modified:   package.json
        modified:   resources/css/app.css
        modified:   resources/js/app.js
        new file:   resources/views/auth/confirm-password.blade.php
        new file:   resources/views/auth/forgot-password.blade.php
        new file:   resources/views/auth/login.blade.php
        new file:   resources/views/auth/register.blade.php
        new file:   resources/views/auth/reset-password.blade.php
        new file:   resources/views/auth/verify-email.blade.php
        new file:   resources/views/components/application-logo.blade.php
        new file:   resources/views/components/auth-card.blade.php
        new file:   resources/views/components/auth-session-status.blade.php
        new file:   resources/views/components/auth-validation-errors.blade.php
        new file:   resources/views/components/button.blade.php
        new file:   resources/views/components/dropdown-link.blade.php
        new file:   resources/views/components/dropdown.blade.php
        new file:   resources/views/components/input.blade.php
        new file:   resources/views/components/label.blade.php
        new file:   resources/views/components/nav-link.blade.php
        new file:   resources/views/components/responsive-nav-link.blade.php
        new file:   resources/views/dashboard.blade.php
        new file:   resources/views/layouts/app.blade.php
        new file:   resources/views/layouts/guest.blade.php
        new file:   resources/views/layouts/navigation.blade.php
        modified:   resources/views/welcome.blade.php
        new file:   routes/auth.php
        modified:   routes/web.php
        new file:   tailwind.config.js
        new file:   tests/Feature/Auth/AuthenticationTest.php
        new file:   tests/Feature/Auth/EmailVerificationTest.php
        new file:   tests/Feature/Auth/PasswordConfirmationTest.php
        new file:   tests/Feature/Auth/PasswordResetTest.php
        new file:   tests/Feature/Auth/RegistrationTest.php
        modified:   webpack.mix.js

前バージョンよりインストールされるファイルの数が倍以上になっています。これは、ブレードのコンポーネント（ressources/views/components/*）を多用しているからです。コンポーネントはまだ実際に使用したことないですが、将来その日がやってきそうです。

今度は、javascriptやcssのトランスパイルのために、nodeのパッケージのインストールとwebpackの実行です。

$ npm install && npm run dev

次はDBの設定です。mysqlのコマンドを実行して、l8xのデータベースを作成します。

$ mysql -u root -p
mysql> create database l8x;

.envファイルを次のように編集してDB情報を入れます。

DB_DATABASE=l8x DB_USERNAME=DBユーザー名 DB_PASSWORD=DBパスワード

以下のコマンドを実行してDBテーブルを作成します。

$ php artisan migrate

以下のように、５つのテーブルが作成されます。

mysql> show tables;
+------------------------+
| Tables_in_l8x          |
+------------------------+
| failed_jobs            |
| migrations             |
| password_resets        |
| personal_access_tokens |
| users                  |
+------------------------+
5 rows in set (0.00 sec)

L7.xと比べて１つテーブルが増えていますね。personal_access_tokensのテーブルです。これはLaravel Sanctumで使用されるトークンのためらしい。楽しい将来の調査とします。

再度、ブラウザでhttp://localhost:8000/registerにアクセスします。

と入力して、「Register」ボタンをクリックすると、

新規会員登録成功です。

Laravel UIパッケージはどこへ？

さて、前バージョンまで使用していた、Laravel UIパッケージはもう使えないのでしょうか？そんなことはないです。L8.xを対応しています。

しかし、残念なことにレガシー扱いになってしまいました。シンプルさが私には良かったのですが。

This legacy package is a very simple authentication scaffolding built on the Bootstrap CSS framework. While it continues to work with the latest version of Laravel, you should consider using Laravel Breeze for new projects. Or, for something more robust, consider Laravel Jetstream.

ちなみにパッケージのインストールは以下となります。もちろん、Laravel Breezeを削除してからのインストールとなりますので注意を。

$ composer require laravel/ui "^3.0"

$ php artisan ui bootstrap --auth

この後の手順は、上と同じです。

Laravel Collection（６）複数のキーでソート

Mon, 12 Jul 2021 00:00:42 +0900

前回に続き、Collectionのsortメソッドについて解説していきます。今回は複数の項目を使ったソートについてです。

前回同様、以下のサンプルデータを使いますのでコピペして手を動かしつつ読み進めていただけると幸いです。

// 再掲
$houses = collect([
    ['id' => 1, 'price' => 3000, 'size' => 100, 'age' => 20, 'station_distance' => 0.6],
    ['id' => 10, 'price' => 3000, 'size' => 70, 'age' => 3, 'station_distance' => 1.1],
    ['id' => 23, 'price' => 1600, 'size' => 60, 'age' => 13],
    ['id' => 3, 'price' => 1600, 'size' => 50, 'age' => 11, 'station_distance' => 2.0],
]);

複数の項目によるソート

前回は物件情報を例にsort, sortBy, sortKeysを使い、広さや築年数など１つの項目をピックアップして並び替える方法について解説しました。しかし、時としてある項目で並び替えた後に値が同じであるならば、別の項目によって並び替えたいケースがあります。

例えば、物件情報を価格の安い順に並び替えた後、同じ価格の物件が複数あるならそれらを築年数が浅い順に並び替えたい、などの場合です。このような複雑な並び替えは、sort()の引数に比較ロジックをcallback関数で指定します。

sort($callback)

Laravel公式のドキュメントにはsort()にcallback関数を渡す場合について、実例が載っていませんが、

If your sorting needs are more advanced, you may pass a callback to sort with your own algorithm. Refer to the PHP documentation on uasort, which is what the collection's sort method calls under the hood.

と書かれています。ので、PHPのuasortのドキュメントを確認しましょう。そちらの例1 基本的な uasort() の例にてcallback関数の例が示されています。

<?php
// 比較用の関数
function cmp($a, $b) {
    if ($a == $b) {
        return 0;
    }
    return ($a < $b) ? -1 : 1;
}

なるほど、$aと$bを引数に取り大小を比較する関数ですね。$a < $b なら１、$a > $b なら−１、$a = $b なら０が返されます。

例を参考に、まずは価格（昇順）で並び替えるcallback関数を書いてみましょう。

>>> function cmpPrice($a, $b) {
        if ($a['price'] == $b['price']) {
            return 0;
        }
 
        return ($a['price'] < $b['price']) ? -1 : 1;
    }

そして、それをsort()に指定してみましょう。

>>> $houses->sort('cmpPrice');
=> Illuminate\Support\Collection {#3397
     all: [
       2 => [
         "id" => 23,
         "price" => 1600,
         "size" => 60,
         "age" => 13,
       ],
       3 => [
         "id" => 3,
         "price" => 1600,
         "size" => 50,
         "age" => 11,
         "station_distance" => 2.0,
       ],
       0 => [
         "id" => 1,
         "price" => 3000,
         "size" => 100,
         "age" => 20,
         "station_distance" => 0.6,
       ],
       1 => [
         "id" => 10,
         "price" => 3000,
         "size" => 70,
         "age" => 3,
         "station_distance" => 1.1,
       ],
     ],
   }

価格が安い順にソートされましたね。正しくソートされているか不安な場合は前回紹介したsortBy()を使って確認してみましょう。

>>> $houses->sort('cmpPrice') == $houses->sortBy('price');
=> true

因みに、cmpPriceは昇順にソートされますが、

return ($a['price'] < $b['price']) ? -1 : 1;

この部分を

return ($a['price'] < $b['price']) ? 1 : -1;

とプラスマイナスを逆にすれば、降順にする事もできます。

続いて、価格が同じだった場合に築年数で比較するロジックを追加してみましょう。価格の比較では名前付き関数を用意しましたが、次のコードではsort()内で無名関数で指定しています。laravelではこちらが一般的です。コードは以下のようになります。

>>> $houses->sort(function ($a, $b) {
        if ($a['price'] == $b['price']) {
            if ($a['age'] == $b['age']) {
                return 0;
            }
    
            return ($a['age'] < $b['age']) ? -1 : 1;
        }
    
        return ($a['price'] < $b['price']) ? -1 : 1;
    });
=> Illuminate\Support\Collection {#3397
     all: [
       3 => [
         "id" => 3,
         "price" => 1600,
         "size" => 50,
         "age" => 11,
         "station_distance" => 2.0,
       ],
       2 => [
         "id" => 23,
         "price" => 1600,
         "size" => 60,
         "age" => 13,
       ],
       1 => [
         "id" => 10,
         "price" => 3000,
         "size" => 70,
         "age" => 3,
         "station_distance" => 1.1,
       ],
       0 => [
         "id" => 1,
         "price" => 3000,
         "size" => 100,
         "age" => 20,
         "station_distance" => 0.6,
       ],
     ],
   }

価格だけで並び替えた際と見比べてください、同じ価格の場合に築浅順に並び替えられていますね。

今回は価格と築年数のみを考慮しましたが、同様に比較ロジックを追加していけば更に細かく並び順を指定できます。しかし、上記のコードではifの入れ子が増え、とても読み辛いコードになってしまいます。でも安心して下さい、次に紹介する宇宙船演算子とエルビス演算子の合せ技でとてもスッキリさせることができます！

宇宙船演算子(<=>)とエルビス演算子(?:)の合せ技

２つの演算子について軽くおさらいしておきましょう。

宇宙船演算子

宇宙演算子はPHP7から追加された比較演算子で以下のように記述します。

$a <=> $b;

$aと$bを比較し、$a > $bなら１、$a = $bなら0、 $a < $bなら-1を返します。

お気づきかと思いますが、まさに前項で作成したcallback関数と同じ結果を返してくれます。

それにしても面白い名前ですね。初めてこの演算子を見た時は、使い方よりもまず名前の由来を検索してしまいました。諸説色々あるみたいですが、中でもStar Warsのダースベーダー専用タイファイターに似ている！というのが有力なのだとか。。。気になる人はググってみて下さい！

エルビス演算子

もう１つキーとなるのがエルビス演算子です。こちらはPHP5.3からあるので馴染みのある演算子かと思います。

$a ?: $b;

$aがtrueなら$aを返し、falseなら$bを返します。

エルビス演算子の由来は、歌手のエルヴィス・プレスリーの顔文字だそうです。。。どこが？っとなりますが、確かにハテナマークがリーゼントに見えなくも無いかも・・・。私はよくNULL合体演算子と混同してしまうのですが、こちらも名前の由来を知ってから忘れなくなりました。

宇宙船演算子とエルビス演算子を組み合わせると前項のコードは以下のように書き換えられます。

>>> $houses->sort(function ($a, $b) {
        return $a['price'] <=> $b['price']
            ?: $a['age'] <=> $b['age'];
    });

とてもスッキリしましたね！価格が同じ場合は $a[‘price’] <=> $b[‘price’]の結果が0となり、booleanに変換するとfalseなのでエルビス演算子により築年数の比較に進む、というわけです。

さらに築年数が同じなら広さ、広さが同じなら駅からの距離、と並び替えたい場合は以下のように２行加えるだけです。

 
>>> $houses->sort(function ($a, $b) {
        return $a['price'] <=> $b['price']
            ?: $a['age'] <=> $b['age']
            ?: ($a['size'] <=> $b['size']) * -1
            ?: ($a['station_distance'] <=> $b['station_distance']) * -1;
    });

簡単ですね！

sizeとstation_distanceは降順に並び替えたいので-1を掛けています、ご注意を。

Laravel8のsortBy()

ここまでLaravel7を前提に複数の項目で並び替える方法を紹介してきました。しかし実はこれ、Laravel8ではsortBy()でもっと簡単に同じことができます。

公式ドキュメントを見ると、sortBy()に並べ替える属性と目的の並べ替えの方向で構成される配列が指定できる旨が書いてあります。よって、Laravel8では以下で同じことが出来ます。

$houses->sortBy([
    ['price', 'asc'],
    ['age', 'asc'],
    ['size', 'desc'],
    ['station_distance', 'desc'],
]);

こちらの方が分かりやすいですね、Laravel8にアップグレードした際はこちらを使っていきたいと思います。

npmからパッケージを追加

Sun, 10 Nov 2019 04:38:19 +0900

laravel-mixでフロントエンドを開発で、Laravelのプロジェクトにおいてのフロントエンドの開発の流れを説明しました。今回は、その続きとしてnpmから新規のパッケージをプロジェクトに追加する過程を説明します。

訂正（7/17/2022）

最近、読者からの以下のコードの間違いの指摘をいただきましたので修正しました。読んでいただいて、しかも間違いを指摘をしてくれる。大変光栄です。kazooさんありがとう。

resources/js/bootstrap.js

...
require('jquery-ui/ui/widgets/dialog.js'); // dialog.jsでなくdatepicker.jsが正しい！

上のコードにおいての、dialog.jsはdatepicker.jsであるべきです。

以降の文中のコードで修正されています。投稿時のL5.8でなく現在の私のL8.xの環境で確認しました。

jquery-uiのパッケージを検索

例として、jquery-uiのdate pickerを使います。会員登録フォームにおいて以下のように誕生日の日付の入力をカレンダーの選択としたいからです。

まず、パッケージとして登録されているかどうか、https://www.npmjs.comのサイトへ行き検索します。画面の検索窓に、jquery-uiと入れます。

検索結果として、774ありますが完全マッチ（exact match）は１つです。オリジナルのパッケージであることを確認してそれを使用します。

次にコマンドラインで、このパッケージをLaravelのプロジェクトにインストールします。

$ npm install jquery-ui --save-dev

これを実行すると、package.jsonが更新されて、以下のようにjquery-uiの行が追加されます。

{
...
    "devDependencies": {
        "axios": "^0.18",
        "bootstrap": "^4.1.0",
        "cross-env": "^5.1",
        "jquery": "^3.2",
        "jquery-ui": "^1.12.1",
        "laravel-mix": "^4.0.7",
        "lodash": "^4.17.5",
        "popper.js": "^1.12",
        "resolve-url-loader": "^2.3.1",
        "sass": "^1.15.2",
        "sass-loader": "^7.1.0",
        "vue": "^2.5.17",
        "vue-template-compiler": "^2.6.10"
    }
}

–save-devの引数を指定したので、上のようにdevのセクションに追加されます。フロントエンドの開発なので開発時にしかパッケージは使用しないためです。

また、node_modulesのディレクトリにjquery-uiのソースがダウンロードされていることは、以下のコマンドの実行で確認できます。

$ npm list --depth=0
├── axios@0.18.1
├── bootstrap@4.3.1
├── cross-env@5.2.1
├── jquery@3.4.1
├── jquery-ui@1.12.1
├── laravel-mix@4.1.4
├── lodash@4.17.15
├── popper.js@1.15.0
├── resolve-url-loader@2.3.2
├── sass@1.22.12
├── sass-loader@7.3.1
├── vue@2.6.10
└── vue-template-compiler@2.6.10

bootstrap.jsの編集

次に、bootstrap.jsに以下の行を追加して、このパッケージをロードします。

resources/js/bootstrap.js

...
require('jquery-ui/ui/widgets/datepicker.js');

jquery-uiにはいろいろなウィジットがあるので、他も指定したい場合は以下のように指定します。

...
require('jquery-ui/ui/widgets/datepicker.js');
require('jquery-ui/ui/widgets/dialog.js');
require('jquery-ui/ui/widgets/sortable.js');
require('jquery-ui/ui/widgets/tooltip.js');

app.scssの編集

jquery-uiにはcssの設定も必要です。app.scssを編集します。

resources/sass/app.scss

// Fonts                                                                                                                                                                                                           
@import url('https://fonts.googleapis.com/css?family=Nunito');                                                                                                                                                     
                                                                                                                                                                                                                   
// Variables                                                                                                                                                                                                       
@import 'variables';                                                                                                                                                                                               
                                                                                                                                                                                                                   
// Bootstrap                                                                                                                                                                                                       
@import '~bootstrap/scss/bootstrap';                                                                                                                                                                               
                                                                                                                                                                                                                   
// jquery -ui                                                                                                                                                                                                      
@import '~jquery-ui/themes/base/all.css';

bladeの編集

今度はテンプレートの変更です。ここでは、Laravelのプロジェクトについてくる会員登録ページにお誕生日の項目を追加します。

resources/views/auth/register.blade.php

...
                        <div class="form-group row">                                                                                                                                                               
                            <label for="birthdate" class="col-md-4 col-form-label text-md-right">お誕生日</label>                                                                                                  
                                                                                                                                                                                                                   
                            <div class="col-md-6">                                                                                                                                                                 
                                <input id="birthdate" type="text" class="form-control datepicker @error('birthdate') is-invalid @enderror" name="birthdate" value="{{ old('birthdate') }}" required autocomplete="\
birthdate">                                                                                                                                                                                                        
                                                                                                                                                                                                                   
                                @error('birthdate')                                                                                                                                                                
                                    <span class="invalid-feedback" role="alert">                                                                                                                                   
                                        <strong>{{ $message }}</strong>                                                                                                                                            
                                    </span>                                                                                                                                                                        
                                @enderror                                                                                                                                                                          
                            </div>                                                                                                                                                                                 
                        </div>                                                                                                                                                                                     
                                                                                                                                                                                                                   
                        <div class="form-group row mb-0">                                                                                                                                                          
                            <div class="col-md-6 offset-md-4">                                                                                                                                                     
                                <button type="submit" class="btn btn-primary">                                                                                                                                     
                                    {{ __('Register') }}                                                                                                                                                           
                                </button>                                                                                                                                                                          
                            </div>                                                                                                                                                                                 
                        </div>                                                                                                                                                                                     
                    </form>               
...

class=“form-control datepickerの部分に注意してください。

app.jsの編集

ブレードで使用したクラス名、datepickerとjquery-uiのdatepickerを繋げるために、以下の定義をapp.jsに加えます。

resources/js/app.js

require('./bootstrap');   
...
$(".datepicker").datepicker({                                                                                                                                                                                      
    dateFormat: 'yy-mm-dd'                                                                                                                                                                                         
});

コンパイル

いろいろなソースファイルの編集を完了して、以下でコンパイルして、all.jsとall.cssを作成します。

$ npm run dev

プロダクションには、

$ npm run prod

これで完了ですが、最後にカレンダーを日本語にしてみましょう。そのためには、bootstrap.jsにおいて、以下のように日本語版のカレンダーに代えます。

resources/js/bootstrap.js

...
//require('jquery-ui/ui/widgets/datepicker.js');
require('jquery-ui/ui/i18n/datepicker-ja.js');

これでコンパイルすると以下のような画面となります。

誕生日の項目なので年も選択できるようにしました。そのためには、app.jsでの定義は以下のようになります。

resources/js/app.js

...
$(".datepicker").datepicker({                                                                                                                                                                                      
    dateFormat: 'yy-mm-dd',
    changeMonth: true,                                                                                                                                                                                             
    changeYear: true,                                                                                                                                                                                              
    yearRange: '1901:'                                                                                                                                                                                     
});