toArray()でcreated_at,updated_atのフォーマットが変わる
Eloquentモデルを配列に変換して渡す必要がある際にたまに使うtoArray()ですが。先日何気なく使用していて思わぬエラーに遭遇、原因を調べてみると実はLaravel 7.xから変更されていた仕様でした。Upgrade Guideには目を通していたつもりでしたが、どうしてなかなか行き当たりばったりなキャッチアップになってしまう、Lazy Loadingな私です。
バリデーション後のRequestの処理
FormRequestのバリデーションを問題なくパスしたら、コントローラで$request->validatedで配列としてフォームの入力値を取得できます。取得後の値は安全なのでそのままDBに保存することも可能です。しかし、その配列から必要のない値を抜いたり、足りない値を追加したりとかの処理はどうするかという説明です。
isDirty() vs wasChanged()（更新）
３年前に書いた投稿の更新です（その投稿自体その４年前の投稿の更新です）。factoryからEloquentのインスタンスの作成も変わり、また新たな発見がありました。
フォルダーやサブフォルダ内のすべてのブレードファイル名の取得NEW！
あるプロジェクトで使用されているブレードファイル内のHTML文の置換が必要となりました。aritisanコマンドを作成して、resources/viewsのファイル１つずつオープンして上書きが必要です。さて、問題はサブフォルダーやサブサブフォルダーがあるフォルダーからどうやってファイル名を取得するか。
whereInが返す順番
whereIn()はLaravelではEloquentやQuery Builderで良く使われます。特にwith()メソッドでは自動的に。今までこのクエリが返すレコードの順番はたいして気にしていなかったのですが、これはどうしたものか、という状況にぶち当たりました。
Laravelはどの環境で実行されている？
Laravelの.envは、ご存知のように実行する環境により中身が違ってきます。その環境の種類を設定するのがAPP_ENVの環境変数です。今回はそのお話です。
【Under the hood】url.intendedはいつどこでセットされたのか？
前回の記事、ログイン後のリダイレクト先、その２では未ログインの状態でログインが必要なページにアクセスした場合、ログインページへ飛ばされ、ログインすると元々アクセスしたかったページへリダイレクトされる挙動について確認し、sessionのurl.intendedにセットされた値によってログイン後のリダイレクト先が決定する事が理解できました。しかし、url.intendedは一体いつどこでsessionにセットされたのでしょうか？気になったので処理を追ってみました。
ログイン後のリダイレクト先、その２
前回の記事ではログインボタンからログインした場合について解説しました。そちらのケースでは、RouteServiceProvider::HOMEを任意の値に変更する事でリダイレクト先を指定できました。今回はもう少し掘り下げ、ログインが必要なページにアクセスし強制的にログインページに飛ばされた場合について見てみましょう。
ログイン後のリダイレクト先、その１
ECサイトなど会員登録機能を備えたサイトは大きくなると利便性やマーケティング的な観点からページ遷移にとても気を使うようになります。ログイン後のリダイレクト先も重視される導線の一つですね。先の案件でそれらを見直す機会があったので挙動や設定方法について備忘録を兼ねてまとめます。