【PHP】Laravel【フレームワーク】 Part.6

**nobodyさん** · 2021/05/25(火) 20:01:01.50

Laravel
ウェブ職人のためのPHPフレームワーク

本家
https://laravel.com/

git
https://github.com/laravel

動画チュートリアル(英語)
https://laracasts.com/

和訳ドキュメント
http://laravel.jp/

※前スレ
【PHP】Laravel【フレームワーク】 Part.5
https://medaka.5ch.net/test/read.cgi/php/1618535648/

**nobodyさん** · 2021/06/18(金) 21:42:50.33

そんなこと一人しか言ってなかったぞ

**nobodyさん** · 2021/06/18(金) 21:43:43.75

>>662
きみ、相変わらずキモいね

**nobodyさん** · 2021/06/18(金) 21:45:04.79

Laravelでviewをbladeではなくtwigに変更するライブラリってありますか？
bladeは使っていて違和感を覚えるので変えたいです

**nobodyさん** · 2021/06/18(金) 21:46:18.07

>>662
違う
バッチ処理が必要なアプリ→モデルでバリデーションがベストプラクティス
バッチ処理が必要ないアプリ→FormRequestでバリデーションがベストプラクティス

アプリの構成によってベストプラクティスが変わるという結論だよ

**nobodyさん** · 2021/06/18(金) 21:51:41.54

すみません教えてください　laravelでプロジェクトを作成すると
プロジェクト直下にartisanというファイルがありこれを使ってコントローラ生成したりなど色々行うと思います。
本番環境にアプリを配置する場合このartisanというファイルは削除したほうがいいのでしょうか？
WEBブラウザからartisanファイルが実行されて変なことにならないか心配しています

**nobodyさん** · 2021/06/18(金) 21:55:34.25

>>667
そんなレベルでLaravel使うことのほうが心配だよ

**nobodyさん** · 2021/06/18(金) 21:56:23.91

荒らしはスルーで

**nobodyさん** · 2021/06/18(金) 21:59:25.19

すみません。別FWだと本番環境にモードを設定するコマンドが用意されており
そのコマンドを実行すると開発にしか使わないようなライブラリや開発専用コマンドなどのファイルを
自動削除してくれていたので今まで気にしたことはありませんでした。
laravelだとそのようなコマンドがないようだったので本番リリース時にどこまで削除すればいいのか
わからなくなって質問させていただきました。

**nobodyさん** · 2021/06/18(金) 22:03:06.71

普通はプロジェクトディレクトリ/publicがドキュメントルートなはずだから実行されないと思うけど
実際WEBサーバの脆弱性ついたらドキュメントルートより上にアクセスして実行できるのかな？

**nobodyさん** · 2021/06/18(金) 22:08:03.33

今開発しているアプリがテストデータ程度だと普通なんだけど本番データに近い件数入れたら
なんか一覧を表示する速度が遅いなって思ってたら数年ぶりにN+1を発生させてしまっていたぜ

N+1なんて回避して当然だから自分やらかしていることに気付かず調べてから判明するまで６時間費やした

**nobodyさん** · 2021/06/18(金) 23:07:00.42

eloquentのwithを知らない又は使ったことが無い人は案外いるのかな

**nobodyさん** · 2021/06/19(土) 00:33:52.61

お前らモハメドの話聞いてないのかよ

**nobodyさん** · 2021/06/19(土) 01:04:26.68

LaravelのEloquentにはupdateメソッドとsaveメソッドがありますが
どちらを使うのが一般的なんですか？

**nobodyさん** · 2021/06/19(土) 01:08:31.82

>>675
動作が違うので必要な場面で必要な方を使うのが一般的です

**nobodyさん** · 2021/06/19(土) 02:52:09.97

基本的にはモデルからfind()なりwhere()->first()なり１件取ってきてからsave()かと
複数行が対象とかで無い限りupdate()使ったりしない気がする

**nobodyさん** · 2021/06/19(土) 08:34:10.69

相変わらず、ワケワカラン実装してんなぁ…。
作ってる奴がアホなんだろうなぁ…。

**nobodyさん** · 2021/06/19(土) 09:09:10.30

>>678
ワケワカランてどういうところがそう思ったのか気になるなー。

**nobodyさん** · 2021/06/19(土) 12:41:17.93

saveを使う場合は
$user->fill($request->validated())->save()
というような感じで使えばいいですか？

**nobodyさん** · 2021/06/19(土) 13:01:08.11

初心者はまずドキュメントか本を読んで基礎を学べ

**nobodyさん** · 2021/06/19(土) 14:18:24.11

ずっとjavascriptマンやっていて再びphpに戻ってきたらなんかいろいろ苦しい

**nobodyさん** · 2021/06/19(土) 15:33:42.74

>>680
その使い方だとupdateでも同じでしょ？
自分はfillした後に何か処理挟むならsave、挟まないならupdateって使い分けしてる
あとコントローラー内限定だよね？その書き方

**nobodyさん** · 2021/06/19(土) 16:42:53.66

釣り針デカすぎ

**nobodyさん** · 2021/06/19(土) 16:52:11.13

>>684
>>683
「updateでも同じ」って部分を言ってるなら多分勘違いしてるぞ

**nobodyさん** · 2021/06/19(土) 19:37:14.74

>あとコントローラー内限定だよね？その書き方

はぁ？　場所によって書き方変わんの？
相変わらず、ワケワカラン実装してんなぁ…。
作ってる奴がアホなんだろうなぁ…。

**nobodyさん** · 2021/06/19(土) 19:40:36.23

>>686
お前はせめてPHP初心者卒業してからコメントしろよ
アホなんだからｗ

**nobodyさん** · 2021/06/19(土) 20:34:25.83

>>686
横だけど、requestオブジェクトからバリデートした値だけを受け取っている部分があるから、controller限定かどうか尋ねてるってことでしょ。Laravelのこと知らないなら黙ってたほうがいいよ。どうせお前bigintおじさんでしょ？

**nobodyさん** · 2021/06/19(土) 20:41:20.40

あえて煽る意味あるの？

**nobodyさん** · 2021/06/20(日) 02:25:33.79

Eloquentの更新だったらupdateを使うのが普通でしょ
あえてsaveを使う理由はない

**nobodyさん** · 2021/06/20(日) 03:29:17.83

>>690
そうなんだよね、結局updateの中身だってfillしてsaveしてるだけだから
あえて->save()分のコード量増やす意味ないと思う
それよりも震えるのはプロパティに値セットしてsaveしてる人ら

**nobodyさん** · 2021/06/20(日) 05:56:49.44

>>691
何故？ｗ
そっちが普通やろ
fill()とか常に使っている方が頭おかしい

**nobodyさん** · 2021/06/20(日) 08:14:01.06

マスアサインメント知らないアホがなんか言ってるな

**nobodyさん** · 2021/06/20(日) 08:28:52.53

このスレ見てるとphp使いとペチパーと揶揄される理由が分かるね

**nobodyさん** · 2021/06/20(日) 08:43:42.18

そうか？低レベルなエンジニアはどの言語にも一定いると思うぞ。

**nobodyさん** · 2021/06/20(日) 09:08:09.75

>>692
前提としてfillableかguardedをModelに設定してるよね
その値って更新可能なカラム名って感じがするけど
そうじゃなくてcreateとかupdateとかfillの引数で入力される連想配列が保存可能なカラムを定義してるのよ
なのでfillとかを使わないでセットした値はその影響を受けないのね
例えば更新なんかしちゃダメなprimaryKeyの値とかも変更可能なの
$user->id = 10 ;
$user->save();
ここまで書いたら分かると思うけど
こういう実装方法って重大なセキュリティホールの要因になりえるので
気を付けようねって意味を含めて「震える」って書いたの
別に俺はプロパティでセットしてsave呼び出してるからと言って頭おかしいとは思わんよ
上に書いた理由を知らなかったってだけだと思うし
実際、俺も使い始めの時プロパティにセットする実装してたから
こういった理由を知った上でそれでもプロパティで実装する方法を選択してるなら頭おかしいって思っちゃうかな

**nobodyさん** · 2021/06/20(日) 09:22:08.01

え、
$user->id = 10 ;
なんて誰が書くの？君の同僚？

**nobodyさん** · 2021/06/20(日) 09:56:24.11

>>697
申し訳ない、俺の例がわかりにくかったみたいだね
こんな例が考えられるけどどうかな？
たとえば悪意のあるユーザーがリクエストでis_adminパラメータを送信して
そのパラメーターがモデルのcreateメソッドに渡されてユーザーが自分自身を管理者に格上げする
みたいなケースが考えられるでしょ？
あと、少し慣れてくるとプロパティにセットする事が手間になってきて
foreachで回して値をセットしたりしがち
そうなると完全にやばいよね

**nobodyさん** · 2021/06/20(日) 10:23:31.57

> foreachで回して値をセットしたりしがち

すまん、俺はそんな場面に出くわしたことないが、君の職場ではしがちなのかい？

**nobodyさん** · 2021/06/20(日) 10:25:45.61

Eloquent式は受け取ったリクエストのタイプによって保存する内容が大幅に違う場合とかには重宝するけどね

**nobodyさん** · 2021/06/20(日) 10:28:58.58

>>696
そもそもマスアサインメント知らないLaravel初心者にそんな具体的な説明しても無駄では？

**nobodyさん** · 2021/06/20(日) 10:30:07.55

idって基本的にauto_increment入れる為のものだから
$user = User::find($request['id']);
とはやっても
$user->idの値を書き換えるとかちょっとあり得ん

**nobodyさん** · 2021/06/20(日) 10:49:54.07

だからそれは例だっつーの
アホなの？

**nobodyさん** · 2021/06/20(日) 10:51:16.05

fill厨はどんな場合でも使ってそうw

**nobodyさん** · 2021/06/20(日) 11:14:16.81

例にある意味予約語みたいなワードを書くとか根本的に常識がない

**nobodyさん** · 2021/06/20(日) 11:22:09.98

>>705
予約語ってis_adminの事言ってるよね
https://readouble.com/laravel/8.x/en/eloquent.html#mass-assignment
https://readouble.com/laravel/8.x/jp/eloquent.html#mass-assignment
ここ読んでみたらわかると思う、君が書き込みをするべきなのは
https://github.com/laravel/framework/issues
こっちだと思うよ

**nobodyさん** · 2021/06/20(日) 11:24:44.54

>>705
リンクおかしいな
https://readouble.com/laravel/8.x/ja/eloquent.html#mass-assignment

**nobodyさん** · 2021/06/20(日) 11:58:24.08

おまえらっていつもマウントの取り合いしてるな

**nobodyさん** · 2021/06/20(日) 12:09:40.58

例だからとかいって言い訳しているけど
idって基本的にauto_increment入れる為のものだから
$user = User::find($request['id']);
とはやっても
$user->idの値を書き換えるとかちょっとあり得ん

**nobodyさん** · 2021/06/20(日) 12:12:46.30

しつこい
アホだ
アホは書き込み禁止

**nobodyさん** · 2021/06/20(日) 12:26:55.34

>>704
どんな時でも使うべきだぞ。じゃないとリクエストからモデルに渡してよいフィールドが、コントローラー側で決定されるメソッドが生まれてしまうぞ。

**nobodyさん** · 2021/06/20(日) 12:41:55.52

fillを必ず使え代入は危ないって言ってる人は、fillableじゃない値をどうやって入れるの？

**nobodyさん** · 2021/06/20(日) 12:44:44.49

このスレ見てるとレベル低い奴が何故か威張っていて、これが今の日本のIT技術が低い理由、そして国が衰えてる理由に繋がってる気がする。
要は反知性主義なんだよね。真面目に科学的に考える奴のことを軽視している。
これって地動説否定とかトランプ支持者など外国でも見られた傾向だけど、日本は特にひどいね。教育が悪いんだろうか。

**nobodyさん** · 2021/06/20(日) 12:57:28.34

IDのないスレをいつまで本スレとして使うつもりなのか？

**nobodyさん** · 2021/06/20(日) 13:08:15.94

>>712
質問を質問で返すなよ　お砂糖が知れるぞ

**nobodyさん** · 2021/06/20(日) 13:31:17.12

>>713
コイツが1番偉そうっていうね。

**nobodyさん** · 2021/06/20(日) 13:31:50.81

お前ら>>696の例に対して文句があるんだったら自分が例を提示しろよ

**nobodyさん** · 2021/06/20(日) 13:50:15.46

>>691
fillを必ず使え代入は危ないって言ってる人は、fillableじゃない値をどうやって入れるの？

**nobodyさん** · 2021/06/20(日) 13:57:05.67

>>718
できない訳ないじゃない
自分が知らないから無いだろうって決めつけると恥晒すよ
https://laravel.com/api/8.x/Illuminate/Database/Eloquent/Model.html#method_forceFill

**nobodyさん** · 2021/06/20(日) 14:00:15.21

>>719
いやforceFillというメソッドは分かるよ。
それを使えば解決するよって回答でいいのかな？

**nobodyさん** · 2021/06/20(日) 14:12:25.97

>>720
まず何を解決したいのかな？
それを聞かないで全て解決するなんて事は言えない
できれば具体例上げて欲しい
状況によって使うメソッドや方法も変えてるから

**nobodyさん** · 2021/06/20(日) 14:20:38.12

逆にコントローラーでfillableじゃない値をセットしている奴は、コントローラーの責務をどう規定しているのか詳しく聞いてみたい。

**nobodyさん** · 2021/06/20(日) 14:24:09.06

>>720
質問しといて申し訳ないけど
俺もfill使ってない事思い出したわ、すまんな
プロパティに入れてfillableガン無視で最後saveしてる人だったって事にしといてください
ここで言い争いしてコスト使うのが1番頭おかしいってふと気付いたわ

**nobodyさん** · 2021/06/20(日) 14:35:38.78

laravelはなんでN+1問題が発生するんですか？
N+1って有名な問題だからFW設計時にそれを強制的にFW側で回避するようにできなかったのかな
いまだとwithとか明示的に使わないと回避できないよね？

**nobodyさん** · 2021/06/20(日) 14:39:23.50

N+1問題を回避できるFWなんてないし、理論上つくれない

**718** · 2021/06/20(日) 14:43:21.94

>>723
いや別に喧嘩腰になったつもりは無くて、単なる興味から聞きたかっただけなんだけどな。
答えたくないなら残念。

>>721
例を挙げるならユーザーのパスワードのセットする時とかだね。

**nobodyさん** · 2021/06/20(日) 14:44:31.24

>>725
CodeIgniter4はFW側で回避してるぞ

**nobodyさん** · 2021/06/20(日) 14:45:04.87

>>725
そうなんですか？となるとやっぱりFWを使う人側で回避しないといけないというわけですね

**nobodyさん** · 2021/06/20(日) 14:46:07.26

>>726
だからfillableじゃない値はforceFill使えよ
プロパティに直接セットするとか素人ですら珍しいぞ

**nobodyさん** · 2021/06/20(日) 14:47:57.78

N+1をFW側で回避することは非常に難しいですよ
その実装をできた人は世界中で表彰されるだろうと言われるぐらい難しいことなんです

**718** · 2021/06/20(日) 14:58:11.63

>>729
なるほど、>>723さんと同じ人か分からないですがありがとうございます。
例えばですが

$user->password = $hashedPassword;
$user->last_password_changed = $now;
$user->fill(request()->all())->save();

こんなコードを書きたい時は

$user->fill(request()->all());
->forcefill([
'password' => $hashedPassword,
'last_password_changed' => $now
]);
->save();

こうしたほうが良いってことですよね？

必ず fill を通す必要がある理由が前述の
「例えば更新なんかしちゃダメなprimaryKeyの値とかも変更可能なの」
「こういう実装方法って重大なセキュリティホールの要因になりえるので」
という理由だと思ってたんですが、forceFill 使っちゃうと id とか変更しちゃダメな値を更新しかねないという点でやはり一緒ではないですか？
この理由だと forceFill も使うべきではないと思ったんですが、実は forceFill を使うとこの問題を克服できるのでしょうか？

**nobodyさん** · 2021/06/20(日) 15:56:55.52

シーダーにforceFill使うならわかるけど
他の用途では使わないほうがいい気がする
laravelは入門程度だから実際に業務で使っている人の意見聞きたいな

**nobodyさん** · 2021/06/20(日) 16:03:57.30

>>731
理解する気が無い人なのかと思ったので諦めてしまいました、ごめんなさい
パスワードとかfillableに含めない項目って基本的に含めない方がいい理由があると思うんですね
その「含めない方がいい理由」ってのは独立した機能として切り出して通常の流れから切り離す必要があると思うんです
特にパスワードに関しては更新後にメール送ったり仮パスワード発行するとか周辺機能も多くなりがちなので
機能として切り出してコントローラではない所で更新した方が良いと考えています
書いていただいた処理の流れでパスワードを更新するのであれば
fillableに含めない事で得られる効果(複数代入で更新されない)の意味がなくなってしまっているように感じます
forceFillで更新したら一緒だよねって問題に関してはご指摘の通り一緒です
ですが、機能として切り出されていればテスト時に更新すべきでない項目を更新していることを見つけることができますし
責任範囲が明確になってメンテナンスコストが抑えられると考えています

例えばlaravelのパスワード更新はこの様にforceFillで更新しています
https://github.com/laravel/framework/blob/8.x/src/Illuminate/Auth/SessionGuard.php#L662
こちらはメール認証でemail_verified_atカラムを更新しています
https://github.com/laravel/framework/blob/8.x/src/Illuminate/Auth/MustVerifyEmail.php#L24

**nobodyさん** · 2021/06/20(日) 16:20:43.33

>>733
読み返してみたのですが

> コントローラではない所で更新

この表現は適切じゃなかったですね

> 独立した処理として更新

が適切かもしれません

**nobodyさん** · 2021/06/20(日) 17:43:02.03

N+1問題、Laravel8の最新バージョンだと回避できるようになってる。N+1になる処理を実行しようとすると例外を発生させられるようになった。

**nobodyさん** · 2021/06/20(日) 19:14:58.36

お前ら、マジで何やってんの？

**nobodyさん** · 2021/06/20(日) 19:20:55.26

>>735
マジで？それはドキュメントのどこに書いてあるの？

**nobodyさん** · 2021/06/20(日) 19:34:42.48

>>737
マニュアルにはないかもしれないけど
この辺じゃないかな？
https://twitter.com/taylorotwell/status/1395087054254526474?s=21
https://github.com/laravel/framework/pull/37363
https://twitter.com/5chan_nel (5ch newer account)

**nobodyさん** · 2021/06/20(日) 19:46:37.88

>>737
すでに上で出てるけど、こっちの方が分かりやすいかな。
https://laravel-news.com/disable-eloquent-lazy-loading-during-development

**nobodyさん** · 2021/06/20(日) 19:47:49.94

マニュアルだとこれ
https://laravel.com/docs/8.x/eloquent-relationships#preventing-lazy-loading

**nobodyさん** · 2021/06/20(日) 21:16:40.26

>>725
速攻論破されて草 >>738-740の内容知らなかったのかな？

**nobodyさん** · 2021/06/20(日) 21:42:57.75

俺はまだ論破されていない　>>738-740はN+1の回避策を提示しただけであって
FW側で回避できるという証明にはならない

**nobodyさん** · 2021/06/20(日) 21:52:49.79

ちょっと言っている意味がわからないです

**nobodyさん** · 2021/06/20(日) 21:53:07.92

>>598
いや、別に論破とかどうでも良いんだが。N+1の実装したら例外出て便利になったっていう情報知らないぽいから教えてあげたかっただけ。

あとFW側で回避したいなら、modelのwithプロパティ使っとけば確実だと思うけどね。ただこれ使うと余計なテーブルアクセス増えてしまいがちだから、不要な時はwithoutとかのメソッド入れなきゃダメで、それはそれでだるい。

**nobodyさん** · 2021/06/21(月) 00:54:44.77

だからモハメドの話をちゃんと聞けって
Laravel使っててモハメドの話聞いてないとかありえないぞ
https://youtu.be/213aEudaumk

**nobodyさん** · 2021/06/21(月) 09:50:26.59

N+1問題とか、何やってんだろうなぁって思ったら
エロなんたらがActiveRecord型だからっつう事か？

アホな事やってんなぁ…。

ActiveRecord型はJOINが表現しずらいから使わんのよね。
無駄な努力をご苦労さん。

**nobodyさん** · 2021/06/21(月) 10:19:15.52

近頃のFWはだいたいがActiveRecord型だし、特に無駄な努力なんてしてないけどな？DataMapper型しか使ったことないアンチオートインクリメントおじさんは、いつまでLaravelスレで粘着するのかね？

**nobodyさん** · 2021/06/21(月) 10:48:42.22

ActiveRecord型は表現が冗長でミスを誘引しやすい
特に初心者にとっては記述する動機になりづらく成長の阻害要因

JOINで書くよりN+1で書いたほうが表現がスマートなのが問題なんだよ

**nobodyさん** · 2021/06/21(月) 10:50:58.39

Laravel以前はCakeしか使ったことないからN+1なんて知らんかったわ
ここ数日初めてこのスレで勉強になった

**nobodyさん** · 2021/06/21(月) 11:28:23.03

JOINで書くってDBファサードからjsonメソッド使って書くって事？
生のSQLでjson使って書くって事？

**nobodyさん** · 2021/06/21(月) 11:30:35.35

ベテランRailsエンジニアたちがN＋1でハマってるのみて何をもがいているのか不明だった
そしたらLaravelでもハマる奴らも続出していたんだな

**nobodyさん** · 2021/06/21(月) 11:35:51.07

いや、ベテランはハマらないぞ。さすがに。DBアクセスのロジック書いたら、普通に生成されるSQL確認するから、そこで気づく。

**nobodyさん** · 2021/06/21(月) 11:37:18.75

あとjoinガーて言ってる人、雑魚はinner joinとouter joinを使い分けられないという点に気づいていないと思う。

**nobodyさん** · 2021/06/21(月) 12:33:16.81

生SQLとかDBの仕組み的なことを知らないとハマるんだろうね
たしかにFWがうまくやってくれるもんだと思ってたらそこまで考えない
SQLを作るための仕組みっていうのを知ってたら中間出力であるSQLはどうなってるのか気になるんだろうけど
意識しなくて済むような仕組みだからね

**nobodyさん** · 2021/06/21(月) 14:13:34.84

>>750

DataMapper型でクエリビルディングして書くって事

正直、Railsで失敗してんのに敢えてActiveRecord型を選ぶとか、頭おかしいとしか思えん。
だからプライマリキーはidのオートインクリメントです、
復号プライマリキーは設定できません、みたいなトチ狂った設計になっちゃうんだよ。

10年以上、全く成長しないよな世間の奴らって。

**nobodyさん** · 2021/06/21(月) 14:14:32.66

なんだこりゃ？　脳みそ腐ってんじゃね？　こいつ

753nobodyさん2021/06/21(月) 11:37:18.75ID:???
あとjoinガーて言ってる人、雑魚はinner joinとouter joinを使い分けられないという点に気づいていないと思う。

**nobodyさん** · 2021/06/21(月) 14:19:54.78

いや、お前らがActiveRecord型しか知らないんだろｗｗｗ
DaoもActiveRecordも同じ『JOINがたマトモに表現出来ません』問題で失敗してんのに、
なんで敢えてActiveRecord型選んじゃうっすか？ｗｗｗ

学習しましょうよ、せんぱーいｗ

747nobodyさん2021/06/21(月) 10:19:15.52ID:???
近頃のFWはだいたいがActiveRecord型だし、特に無駄な努力なんてしてないけどな？DataMapper型しか使ったことないアンチオートインクリメントおじさんは、いつまでLaravelスレで粘着するのかね？

**nobodyさん** · 2021/06/21(月) 14:21:17.36

アンチオートインクリメントおじさんが荒ぶってらっしゃる

**nobodyさん** · 2021/06/21(月) 14:21:18.84

やべぇ、流石に草生えまくり過ぎて、誤字・誤変換だらけになってるし。

**nobodyさん** · 2021/06/21(月) 14:27:07.58

アホはトレードオフって言葉を知らないので、ある側面だけをみてActiveRecordは失敗とか言っちゃうんだよなー。
そういえば前に、ActiveRecord自体知らなくて、1テーブル1モデルなんてありえねーとか言ってた恥ずかしい奴がいたな。

**nobodyさん** · 2021/06/21(月) 14:32:26.85

>>760

何言ってんだろうね、このバカは相変わらず。

じゃ、他のORMに比べて、他にどんなメリットがある？
お前、マジでActiveRecordしか知らないんじゃん。

**nobodyさん** · 2021/06/21(月) 14:33:53.71

>>760

ってか、『1テーブル1モデル』って、なんすか？ｗｗｗ

もしかして『1テーブル1クラス』の間違いっすか？ｗｗｗ