【PHP】Laravel【フレームワーク】 Part.5
■ このスレッドは過去ログ倉庫に格納されています
テンプレ追加修正お願いします
Laravel
ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
日本語
http://laravel.jp/
書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)
※前スレ
【PHP】Laravel【フレームワーク】 Part.4
https://medaka.5ch.net/test/read.cgi/php/1613209188/ ドキュメントルート直下にmngという名前でLaravelをインストールして、
mng配下の中身をルート直下に移動→.htaccessで
RewriteCond %{REQUEST_URI} (\.\w+$) [NC]
RewriteRule ^(.*)$ public/$1
とすることで
Route::get('/', function () {
return view('welcome');
});
Route::get('/mng', function () {
echo 'test';
});
とすることで、フロントと管理画面を分けられそうです。
これが一般的な方法でしょうか…？ viewはpublic似ないのに何故そんなよくわからないことをするの？ 起点となるのは/public/index.phpなので、publicをURLから省くための
何らかの処理がいると思うんですが。。 シンボリックリンクとルーティングだけで普通にできないかね？
まあ、何したいかもよく分からんし、それで動くならそれでええやん ルーティング難しいよなぁ
htaccessが絡むと余計にわからなくなる 何度もすいませんが、その場合ドキュメントルートを/publicに指定するということでしょうか？
シンボリックリンクはどこからどこへ張ればいいのでしょうか。 >>737
Alias使った方が良いんじゃないの？
考え方としては別ドメインと同じなのでLaravelを2つインストールする。
https://www.javadrive.jp/apache/ini/index12.html 俺がヒマだったら予約システムぐらい、Laravelでさくっと作ってやるのに 日本のITオンチっぷりがシャレになってない感じだから、自分の技術力で何とかしてやりたいと思うことはある すいません。こちらいかがでしょうか…？
>>755 うちにもcomposer使えない環境へのデプロイ必要な案件来てしまった
しょうがないからvendorコミットしたわ 俺みたいな古い人間は、composer使うと抜けがあるのではないかと心配してしまう composerが使えない環境って
社内LANみたいな感じで外部と一切つながってないって事？
まぁ、社内システムなら社内のネットワークだけで閉じるというのはありそうだけど >>766
その通りです。社内のネットワークしか繋がっていない環境です。 >>750
そもそもドキュメントルート直下にインストールすることを想定したフレームワークではない
管理画面もフロントだと思うんだけどこのあたりしっかり説明してもらわないと
求めている回答が付かないと思います >>771
あなただけじゃないと思うけど、php自体やその他の更新頻度を見ると、現実的に仕方ないかなぁとも思う >>770
広い意味では管理画面もフロントですが、私の言うフロントは
公開側という画面と言う意味です。
たしかに、公式のドキュメントにもそのように記載されている
のは承知していますが、管理画面とフロント側をどのように
分ければいいのかが分かりません。
公式の推奨に従ってhtdocs（Webルート）と同階層にインストール
したとして、
http://sample.com/mng
というアクセスでLaravelアプリケーションを動かそうと思うと
htdocsに「mng」というシンボリックリンクを張ればいいと思いますが、
（ln -s /var/www/project/public mng）
http://sample.com
というアクセスで同じ「project」というアプリケーションを
動かすにはどうすればいいのでしょうか？
そこさえクリアできれば、あとはルーティングでどうにでもできると
思うのですが。。 teratailだと切れた常連エンジニアに説教食らいそう。 rewriteのルール(ドキュメントルートの.htaccess)はLaravelのデフォルトのままで良くて
そもそもシンボリックリンクなんて使う必要も無く単にルーティングで分ければ良いだけでは？
rewriteもフレームワークを使わず直接phpを動かす場合はURLのパスの部分がそのまま
ドキュメントルートからのサブフォルダの階層にはなるが 出来の悪いコロナ予約システムにLaravel使ってる噂 むしろ何で分からんのや。マーソて受託した会社の採用ページみたり、ソースみりゃ分かる。 inputタグの属性でcakePHPてはっきりわかんだね。 NGワードひっかかってURLが貼れないわ
見様見真似でcakephp使ってるらしいな
https://i.imgur.com/nLDH7s5.png
2019年に書かれたブログ記事 マーソの話題はスレチなのでcakePHPスレでやって >>773
だからAlias使えばいいじゃん。Apacheじゃないの？ 案の定、NginxでもAlias使えるし。
人の話、ちゃんと聞きなよ。上の方で一回言ったよ？ 入力された電話番号が正しいものかどうかって判定するには実際どうすればいいんだ？
入力された電話番号にショートメールで認証番号を送信して
それを再度入力しないと登録が完了させないようにするとかになるのかな >>791
SMSを使って確認する方法も微妙に穴があるけど、それぐらいしかないのも事実 新しくlaravel始めることになりました。
COBOLからの乗り換えなんで爺さんには大変です。 自分の環境だとGNOME40になってからEloquentが動かなくなった
GNOME40とEloquentはまったく関係がないはずなんだけど・・・・・ >>795
海外だと勘定系がLaravelはあるんだぜ・・・ >>774
>>770の方法でやろうと思う理由ですが、Laravelを2回インストールしたくないからです。
回答が遅くなりました。 勘定系をPHPのシステムでって、端数丸め対応が大変そうだな。 6月からLaravel勉強しようと思ってるんだけど、
ちょうど6月に販売される本って高いね。4000円超える・・・
みなさんはやっぱりオンラインマニュアルで覚えたんですか？ >>801
あなたの今の知識次第だと思いますよ
PHPとインフラ/ミドルウェアに対しての知識が十分であれば、公式が最も適したドキュメントになります ググる時間がもったいない
本1冊を一気通貫でやるのが最短
4000円なんて技術者１〜２時間の人件費でしょ？
本で節約できる金額考えたらおつりがくるよ Laravelの本のターゲット
・MVCが初めて
・PHPが初めて
・Laravelが初めて
・お金をケチらない
一個でも外れてるなら買わないでドキュメント読んだほうが良いと思うよ
というか全分当てはまってる状態でLaravel始めても尚更訳分からんと思うからやっぱり個別に覚えたほうが良いと思うけど >>804
全部外れてるけど、「ドキュメントがわかりづらい・理解できない」ですよね・・・ >>801の本の詳細説明みてからコメントしてる奴おりゅ？
あの本はLaravel8の解説書ではなく、Laravel8に対応した「ぼくのかんがえたさいきょうのせっけい」を読まされるだけじゃね？ADRとか言ってる時点で論外。中級者以上なら参考になるかもしれないが。
それよか、ちょうどドットインストールがLaravel8の入門公開してたからそっち見たほうが良いと思う。 >>806
そうなんですか・・・危うく買ってしまうところでした
今の時期は本屋にも行きにくいし、中身確認できないですからねぇ Laravelに関しては本と公式だと完全に公式の勝ち
まだ出てない本は知らんけど、余程じゃないと勝てんぞ Laravelの公式リファレンスはある程度の技量がないと読み解けないと思う
職人のためのフレームワークだからそれでなんの問題もないけどね
あれを読み解けないなら本を買うのは普通にありだと思うよ
分かりやすいわかりにくいはあるけど、だいたいは公式リファレンスよりかみ砕いて書いてある
ただ、今月出るやつは2回目の改訂だと思うが、ADRとか書いてあるし、
書いてる人がアンチFacadeだしで初心者向けではない感はある 昔よくあった掲示板の作り方のように
何か作りながら機能説明してくれる方がわかりやすいと思う >>811
時間があったらそういうのを１から作るというのを解説したブログとかを書いてみたいんだけどね
今ならyoutubeで解説したら見てくれる人はいそうだけど
そんなの作ってる時間ないな Youtubeは逆に難しいと思うぞ
動画を再生したり停止したりって動作が面倒すぎる 自社パッケージをLaravelで作っているがバージョンアップ多いので辛そう。
LTSで作って次のLTSでバージョンアップっていうのが王道なのかな？
メンテナンスとか保守とかが辛くなってきそうだ。
ライセンス問題が解決したCodeigniter使った方が良いのかなって思い始めてる。 確かにバージョンアップ頻発するとつらいね
そういう点でうちはCakeのままのがあるわ >>806
ドットインストールのお兄さんの声ってイケメンだよね >>814
王道は「バージョンアップなどしない」だぞ
テストやらのコスト考えると3年やそこらでメジャーバージョンアップとか却下 Laravelはlaravel-shiftて有償のバージョンアップ支援するサービスがあるので、それ使えって話で終わる。LTS→LTSなら7000円ぐらいでできるはず。 お前らの蔵なら作ったらほったらかしが基本だろ？
10年前に作ったCake1のシステム、CentOS6のPHP5で元気に稼働中 いや普通にバージョンアップ計画立てるが。趣味のサービスでさえ、6→8にしようと進めてる。 >>820
でもその毛髪をカウントするWEBアプリってバージョンアップする意味あるの？ 普通はわざわざLaravelのバージョン上げることもないよね
よっぽど重要なシステムなら運用中もそれなりに人材いるだろうけど大抵は運用中はそもそも開発した会社は完全にノータッチの事も多いだろうしね >>821
ハゲのお前には、バージョンアップのメリットは理解できないかもしれんな。 >>822
Laravel、今年だけですでに3回も深刻な脆弱性みつかってるから。
ignition由来のやつはまぁいいけど、バインド変数のマッピングの脆弱性は6より前のバージョンだと修正されずに放置はされてるはず。
作って納品して終わりみたいな人達はバージョンアップに縁は無いんだろうけど、運用している奴らはバージョンアップしないと自分のこと首を絞めることに。 脆弱性って言っても、コロナ予約システム並みじゃなければ
そうそうデータが盗まれるとかはないんじゃね？ >>817
なるほどです。
>>818
shiftの存在は知っているけど、その後にshiftでマイグレーションされたパッケージを全機能とかチェックするテスト工数は省けないわけで。 >>814
PHP、Laravel、自社アプリすべて常にバージョンアップを続けてる
多少の不具合は許される環境だから出来ることだと思うが
少しでも手を休めたら逆につらい そらそんな必要ないからな
客が納得して納品したら終わりや 今までの経験だと自社サービス開発、受託開発問わず、ほぼ確実にエンハンス開発はあるんだけど、このスレでは納品して一切触らないケースがほとんどなの？ 一切触らないケースが多いな
中小零細だと継続依頼ってなかなかないぞ >>831
受託開発した後に納品先に切られて別の開発会社に乗り換えられてる説 >>831
触らないケースが多いね
顧客がバージョンアップや新機能追加などの開発費出す余裕がないから エンハンス開発が無い = 作ったシステムがビジネスとして成功しなかった
だからね、ビジネスとして軌道に乗るなら改良もするが、軌道に乗らないきゃ改良なんてしない どの世界でも当然の話しなんだが、金出さないと成功しないからな
初期投資だけで成功すると思ったら大間違いだ >>831
そもそも完成するまでの依頼でその後依頼された事なんて無いからね
メンテなんて安い所に頼めばいいとでも思ってそうだけど
他人のコードを理解する方がよっぽど高度なのにね・・・ >>838
それ、冗談抜きでめちゃくちゃあるよな
あれだけ作る前にやりとりしてたのはなんだったのかと言いたくなる >>838
社内システムとかクローズドなシステムの開発が割と多いからそもそも納品した後で稼働しているか確認する術も無いけどね >>840
>>841
うちもB2Bばかりなんだけど客の担当がノリノリでも、現場が新しいもの使いたがらなくてなかなか移行できない…みたいに見える、想像だけど
納品後も客が管理者IDとPASS変えないから入れちゃうのでたまに見ると、データ増えてない あ、そう言えば納品してサヨナラじゃなかった今思い出した
SSL証明書の更新だけは毎年依頼されるｗ >>842
え、それちゃんと許可貰って覗いてんのか？ >>842
納品したシステムに勝手に入ってデータ監視とか終わってるなLaravelはｗ >>846
laravelは関係ないけど842の頭はヤバいな クエリビルダしか使わない場合、モデルは書かなくても良いでしょうか？ >>848
普通はLaravelのドキュメントに書かれているような
DB::table('tests')->where(条件)->get()
みたいなやり方よりはTestモデルを定義して
Test::where(条件)->get()
みたいに書く方が良い気がするんだけどね
テーブルが複数名でプライマリーキーがidならモデルのクラス作っておけばいいだけだし
（実際にはguardedなどは定義した方がいいけどひとまず置いておいて）
モデルを全く定義しないプロジェクトなんてやったこと無いから分からないがｗ DB::table('tests')->where(可変)->where(固定)->where(固定)->orderBy(固定)->get()
みたいなのがコントローラに延々並んでいるよりはモデル作って
Test::getSomething(可変)
みたいにした方がスッキリするんちゃう ■ このスレッドは過去ログ倉庫に格納されています
