【PHP】Laravel【フレームワーク】 Part.8
■ このスレッドは過去ログ倉庫に格納されています
>>272
それな。日本語分からないの?て笑ってしまうわ。 >>271
config/auth.php直接編集はダメじゃないか?
config/auth_local.phpファイルを作ってそっちを編集したほうがいい 元あるファイルを修正するのではなくそれをオーバーライドした
XXX_local.phpを作るのはPHPのフレームワークでは常識のテクニックだろ・・・ >>277
煽るぐらい自信満々に回答したのに、バカにされたからって話を変な方に持ってくのはやめとけ。恥の上塗りだぞ。 サービスプロバイダでmergeConfigFromメソッドとか使ったことないんかね・・・
vendor内書き換えたいとか思わないくらい色々便利な機能あるのにもったいない Taylor Otwellはよく講演でvendor直下直接修正しているけどあれ何で何だろう
vendor直下なんて書き換えないというのがお約束というのはわかっているはずだが >>281
講演見たことないから正確にはわからんけど
俺の場合パッケージ開発の場合vendor以下を作業領域にするよ >>281
> あれ何で何だろう
Laravelが「変」だから、vendorを修正しないと対応出来ない。 >>285
自分の知識が浅いのをLaravelのせいにするなよwww どうしても触るにしてもcomposer.json使ってオーバーライドするくらいにした方がいい
直接触るのはさすがにない >>281
ざっと探したんだけどvendor修正してる動画ないなぁ
viewとか言語ファイルなんかをvendor:publishすると
resources/view/vendor/パッケージ名
以下に配置されるんだけど、それ修正してるとか?
きっと意味があってそうしてて普通に開発するよりもメリットがあるからそうしてるはずで
その恩恵を受けられないのは損だから動画とかあるならマジで教えてほしい
それで開発時間5%短縮できるならやらない理由ないし サービスプロバイダやクラスのオーバーライドを理解しているなら、日常的にvendor配下をいじる必要性なんてゼロだって分かりそうだけど。 >>289
そう、パッケージ開発以外でvendor以下を触るなんてありえないってのが俺の認識なんだけど
明らかに自分より能力の高い人物でlaravelの開発者がやってるなら
それなりの理由があってメリットがあるはずだから知りたいんだよね >>290
まぁ>>288の前半部の仮説が正しいのかなって思ってる。 確かにまじでvendorフォルダ直接修正しているね
しかも「composerのバージョン2を使っている方以外はマネしないでください」という意味不明な発言もしている
俺の認識だと別にcomposerのバージョンに関わらずvendorは修正しないのが原則だと思ったんだけど
composerのバージョン2だと何かメリットがあるのか? 自分で作ったものなら意味も分かってる訳だし動作確認とかで修正するのもありなんじゃね?
ただ一般的にはいじらないだろうが >>295
何もそんな言い方しなくても・・・
公開されてる動画で確認したのかなと思ったのでそうであればURLが欲しいって意味だったんで
公開されてないデータであれば大丈夫です >>292
俺も294と同じくtaylorがvendorいじってるところを確認できる動画のurl知りたいわ。 url出せないなら、どのメディアやSNS見りゃ良いのか教えてくれると助かる。 >>298
別に俺は話の真偽を確かめたいから言ってるんじゃないのよ
Laravelをガチでやるって決めたから
知らない手法があるのが嫌なだけ、だからいつくらいの動画かだけでも教えて欲しい
「Taylor Otwellはよく講演でvendor直下直接修正している」って>>281で書かれてるから
v7以降の話だよね?
最後の手段は英検初段の実力をフルに使って本人に直接聞いてみるから
本当はlivewireのdiscordで怖い目にあったから英語で会話したくないけど >>301
草Taylorにdiscordでボコボコにされたのかよw 仕事でLaravel使ってる人って、公式サポート切れた後どうしてるの? >>304
その分の費用請求するの?バージョンアップの間隔短いから納得しない気がするんだが いやうち自社サービスだから請求なんて概念無いけど
つかそんなの客との契約次第だろ
どんな契約してんだよ >>303
バージョンアップするだけ。内製だからな。外注の場合は金払ってバージョンアップするでしょ。他のFWはそうだったし。
あと、Laravelが殊更バージョンアップの周期短いのは事実だけど、サポート期間はそうではない。
LTSならバグフィックスは2年、セキュリティフィックスのサポート切れまで3年ある。これはPHPのサポート期間と同等。PHPは2年間のアクティブサポート、そこから1年間のセキュリティサポート。 バージョンアップって機能が追加される訳でもないから、費用かかるの嫌がるってのもわかる
フリーでやってた時本当に嫌だった 外注だと一度運用にのせたらFWバージョンアップなんて無理だわな
どうせそのうちリプレイスになるから放置ですよ FWに限らず、別の作り方するだけでリスクが高くなるからな
ポータルサイトなんかもずっと古い技術のサイト多いだろ FormRequestのattributesに
age => '年齢'みたいな感じでユーザにわかりやすい名称に変更可能だけど
多言語化するときってどうするんだ?age => __('age')みたいな感じにして
messages.phpでage => '年齢'って定義するのか? >>311
FormRequestはコントローラの関数の引数にいるんですよね?
public function store(HogeHogeRequest $request)みたいな感じで
だとしたら多分できないと思われます。
うろ覚えですがHogeHogeRequestの処理が行われる時点ではまだmessages.phpは読み込まれていないので
HogeHogeRequestのattributesで__('age')が'age'として解釈されてしまい
画面上にそのままageとして表示されると思われます >>311
エラーメッセージのカラム名翻訳の話だよね?
いくつかやり方あったはず、検証してないから間違ってたら申し訳ないけど
1. validation.phpに
'attributes' => [
'short_comment' => 'ひとこと'
],
って指定する方法
Custom Validation Attributesってコメントに書いてあるはず
2. resources/lang/{locale}.jsonに
"attributes":{
"translation":"多言語化"
}
って指定する方法 >>311
すでに回答している内容と被るけども、langディレクトリ直下にja.jsonてファイル作って、"hoge":"ほげ"とか定義しておくと、__('hoge')てなってる箇所が、ほげ で出力される。
ただしこの方法は、view上の出力を置き換える場合に使うものであって、vallidationメッセージの多言語化はlang/jaの下のphpファイルで達成するのが望ましい。
ちなみに、jetstreamはちょっとだめなとこがあって、後者だと一部のバリデーションメッセージが英語のままになってしまい、ja.jsonで変換かけてあげないとダメだったりする。 >>314
何でlang直下の多言語化ファイルがphpじゃなくてjsonなんだろうって謎が解けたわ
今日もまた一つ賢くなってしまったありがとう いまいち本番環境へのデプロイがイメージわかないんだけど
node_modulesやvendorフォルダってそのまま本番環境にコピーしていいの?
それとも本番環境でnpmやcomposer等のinstallコマンドを実行しないとだめなの? >>313
1のやり方だと多言語化できなくない?
それだと日本語オンリーになる >>317
どうしてそう思ったんだろう
resources/lang/en/validation.php
を変更してるって事なのかな
だとしたらenってディレクトリ名のenってどういう意味か考えたらすぐわかると思う
resources/lang/{locale}/validation.php
こう考えたら日本語オンリーにはならないよね >>316
環境によるから何とも言えないけど
基本的にvendorとかnode_module辺りはコピーしないでやってる 今までlaravelできますって言われてちゃんと使えてる人にあった事ないんだけど
みんな自己評価高すぎじゃない? >>316
どういうデプロイの仕組みを使うにせよ、composer installやnpm run productionを実行してから本番と同期とるような処理を書いてる。 >>320
俺もその認識。たぶんconfig/app.phpのローカライズ用の設定変更などせずに開発してるんじゃね? 別にvendorファイルをコピーしても害はない気がする vendor以下をコピーして受けられるメリットがあんまりないのよね
環境がWindowsかMacかLinuxで少しだけbinに入るファイルが違ってくるし 自分が居なくなっても別の人に保守してもらうことを考えたらWindowsは選択肢として有り composerやnpmは環境次第で高確率でトラブるから使わないようにしてる
レン鯖だとそもそも使えないしな WindowsとMac使わないって開発環境もLinuxって事なの?
そうでないならどこのvendorをコピーする想定なんだろうか 開発環境はWindows上のLinuxだろDockerか何かの
Windows用のVendorが必要になることなんてないが composerやnpm使ってデメリットになることはほとんどないな 【悲報】Laravel9でまたModelsディレクトリが消失してしまう モデルの置き場を強制されることを嫌う奴が開発陣にいるの?
決まっている方が使いやすいと思うし従来のでも結局Models作って
そこに置くからどっちでもいいんだけどw リポジトリには来てないけどな。情報源はどこだろう?公式のdiscordでもなさそうだし。 皆さんはlaravelを使っていると思いますが
この機能が欲しいとかここ直してほしいとかそういう要望って何かありますか? Eloquentの100ループ問題を早く修正してほしい Eloquentって使ったことないなそういえば いつもクエリビルダ使ってるけど
Eloquentって何かメリットあるのかな >>336
bladeをWordPressみたいにWeb上で更新できるようにしたい
ローカルでいちいちエディタ使わないといけないのが面倒だ laravelはsymfonyと比べると使いづらい >>340
自分もあったら良いなと思ってたんですよね
自作するとしてエディタは何がいいと思いますか? それならFTPなどの同期でも利用すればローカルのbladeファイルを保存したらアップロードされたりするしそれで良さそうな
まぁ本来ならgitで管理して最低でもサーバーでgit pullするとかだろうけど 使う場面が想定できんな
だったらWordPressでええやん、ってなる
bladeの処理をエディタの部分だけ切り離すのも大変そうだし
作るにしてもちょっと割に合わない 詳細な要件は不明だけど、今どきはgithubリポジトリでピリオド打鍵したらすぐwebエディタ起動するじゃん?それでbladeファイル編集して、保存時にgithubアクションでデプロイする仕組みにしとけば、希望は叶うんじゃないの?プレビューしたいとかなら、話は変わってくるかもだが。 >>345-347
やりたい事はかなりシンプルで
デザイナー?HTMLコーダー?の人から上がってきた
HTMLをbladeファイルにする作業から逃げたいってだけなんだよね
結構github何それ?って人とかいてそういう人にどうやって直接触ってもらおうか悩んでるのよね
ヘッドレスCMSとかも考えたんだけど不評でさ デザイナレベルならGitHubたたき込んだ方が早い
メインブランチには触らせないようにしとけばいいし
てか、Larabelで更新させたらbladeの履歴管理はどうなるん? >>348
そういう奴はjigsaw使え。それ使って作らせたらbladeファイルで納品させられるぞ。
https://jigsaw.tighten.co >>349
直接触れるんだから更新履歴とか知った事か
そっちで管理してねって感じ
それが嫌ならgit覚えて下さいかな file_get_contentsでbladeの中身を取得して、それを書き換えるってことはできないの? まあ、どうにせよ需要がニッチで開発する人はいなさそうだ WordPressに実装されてるって、素人にも編集させるためだろ?
なのにニッチ(需要が少ない)と決めつけて良いのか? WordPressでできないからLaravelで一から作ろうとしてるんだろ そろそろLaravel始めてみようと思うんだがそれぞれ一言ずつください そんなに需要があると思ってるなら自分で作って公開すれば良いと思いますわ
みんな喜んで使ってくれたら嬉しいでしょ >>359
複合主キーはLaravel(Eloquent)では扱えない >>363
それならLaravelも十分使えると思うよ
昔は日本だとCakeばかりだったけど最近はLaravelばかりという気がするし PHPのできないHTMLコーダーにビュー作らせるためにbladeとかtwigみたいなテンプレートエンジンがあるんだろ?
それもできないからCMS作るって斬新だな 普通はwebデザイナーにHTMLを作って貰ってそれをプログラマが
bladeにするみたいな感じが普通じゃね?
そりゃデザイナがbladeまで作れたら楽だけどそんなところ少ないんじゃね デザイナーはモック作ってお前らがphpでマークアップするんだろ
何で他人にやらせてるんだよ
どうせ、cssをまともに作れなくてデザイナーが指定したとおりに作れないんだろうが 別会社が作ったHTMLを組み込む場合は自分でbladeにするけど、社内で全部作る場合はデザイナーがblade書くよ
ただし@なんちゃらの部分はこっちで付け加える、修正時はそこをいじらないようにしてもらう ■ このスレッドは過去ログ倉庫に格納されています