【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/ >>727
ある議論で荒れて収まったと思ったら、同じ質問をするやつが現れるってことが何回も起きてるからね。>>719に書いた通り。 >>732
そもそも複合主キーのどこに荒れる要素あるんだよｗｗ >>733
>>140からの流れ見てもらえればわかるけど、サローゲートキーにオートインクリメント絶許マンが現れて荒れたんだ・・・。 複合主キーも設定できないなんて、Laravelってポンコツなんですね。
ガッカリしました。 質問なんですが、/var/www/htdocsをドキュメントルートとして
/var/www/projectでlaravelをインストールした場合、
http://sample.comでフロント側を動かし
http://sample.com/mngで管理画面を動かしたいです。
そのような場合、htdocsにmngというシンボリックリンクを張って、
（ln -s /var/www/project/public mng）
あと、フロント側はどうすればいいのでしょうか？
この方針だとまずい場合、どうするのが一般的でしょうか。 フロントは何で動いてるの？Laravel使うのはあくまで管理画面？ フロントもLaravel、管理画面もLaravel？プロジェクトはフロントと管理画面で別ってことかな？同じなら、別にシンボリックリンク要らんからね。 １つのプロジェクトでルーティングや処理を分けたいと思ってます。
同じプロくジェクトならシンボリックリンク不要でしょうか…？
ドキュメントルートの配下にプロジェクトを置くということでしょうか？
どういうディレクトリ構成にすればいいのか分かりません。。 というか、CMS付きのホームページをLaravelで作る場合、
どうやるのが一般的なんでしょうかね？ 同じドメインで1プロジェクトなら特に何も考えなくても良いのでは？
ルーティングでどうにでもなるでしょ？ これまでは
/var/www/htdocsにmngというプロジェクトでLaravelをインストール
↓
/mng/.htaccessに
RewriteCond %{REQUEST_URI} (\.\w+$) [NC]
RewriteRule ^(.*)$ public/$1
でリライトして管理画面を作ってました。
http://sample.com/mng
へアクセスして、
Route::get('/', function () {
return redirect('/login');
});
というルーティングでログイン画面へ、といった具合です。
「何も考えなくても」ということなので、私が何でもない所で悩んでいるような気は
するんですが、できれば具体例で「こうすればOK」というのを教えて欲しいです。。 あ、ちなみに最初のシンボリックリンクのくだりは、上記の方法で行き詰ったので
方法を変えたがまた行き詰った…という経緯です。 普通はドキュメントルート指定して、あとはroute/web.phpで、ユーザー用のURLと管理用のURLを定義するだけだと思うけど。なぜ上のような設定にしたのか意図がわからぬ。 特に意図してやったというわけではなく、URLで/mngにアクセスした際に
/mng/public/index.phpを実行させるためにこうしないと、と思っただけです…
「ドキュメントルート指定して、あとはroute/web.phpで、
ユーザー用のURLと管理用のURLを定義」の部分を具体的に教えて欲しいですm(_ _)m
http://sample.comでフロントのトップページ
http://sample.com/mngで管理画面のトップページ
としたい場合、
・プロジェクト名
・ドキュメントルート
・web.phpをどう記載するか
を教えて欲しいです。。
ルーティングのアクションは適当な例示で構いません。
質問ばかりですいません… これまでで管理画面（社内向けシステム的なもの）しか作ったことなかったので
ある意味上記の方法で悩むことはありませんでしが、根本的にやり方は良くなかった
のでしょうかね。そんな気がすごくしてきました。 そんなところで詰まってたら永遠に完成しないと思うぞ
ルーティングの基礎の基礎なんだから、ちゃんとドキュメントみてしっかり考えようや
https://readouble.com/laravel/8.x/ja/routing.html ドキュメントルート直下に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、自社アプリすべて常にバージョンアップを続けてる
多少の不具合は許される環境だから出来ることだと思うが
少しでも手を休めたら逆につらい そらそんな必要ないからな
客が納得して納品したら終わりや ■ このスレッドは過去ログ倉庫に格納されています
