Laravelで、フォームを作る時に、例えば選択ボックスがあって、そこから値を取り出したい場合があります。

例えば、性別[男、女]とか、都道府県[北海道〜沖縄]とか、カテゴリ[〜、〜]とか色々と考えられます。

それらのデータは、しょっちゅう変更があるもので、複雑なものであればデータベースにテーブルを作ってそこから引っ張ってくる方法もあるのですが、例えば男、女のような小さいデータセットであれば、わざわざそれをするほどでもないというか、いちいちテーブルを追加してデータをセットするというのが、Laravelの場合マイグレーションを通さないといけなかったりと色々と面倒です。

その場合に便利なやり方ですが、configに追加するのが楽です。

以下のページにやり方が書いてありました。

Laravelで都道府県のプルダウンメニューを作ってみる

一応手順についてメモしておきます

１．config以下に好きなファイル名で作成

都道府県であれば、per.phpのようなファイル名をconfig以下に作成して保存します。

return array(
  '1' => '北海道', 
  '2' => '青森県', 
省略
  '46' => '鹿児島県', 
  '47' => '沖縄県'
);

ちなみに、configのキャッシュが残っていると反映されないので、ファイルアップ後は以下のコマンドが実行必要です。

php artisan config:cache

上記の例では、pref.phpには一つしか配列が定義されていないですが、
複数定義したい場合は以下のように多次元配列でも設定が可能です。

return [
    "sex" => [
        "1" => "男",
        "2" => "女",
    ]
];

上記のように設定しても、後で問題なくアクセスできます。

コントローラーで取得→テンプレートに表示、または直接bladeに表示

作成したファイルは、config(ファイル名)で、いつでも参照して取得可能です。

コントローラーで取得してからテンプレートに表示する方法

public function sample() {
  $prefs = config('pref');
  return view('sample')->with(['prefs' => $prefs]);
}
  @foreach($prefs as $index => $name)
$name
  @endforeach

直接テンプレートに記述する

以下のように直接取得することも可能です。

<select name="_pref">
  @foreach(config('pref') as $index => $name)
    <option value="{{ $index }}" @if(old('_pref') == $index) selected @endif>$name</option>
  @endforeach
</select>

多次元配列の場合は以下のようなかんじです。

例えば、config/common.phpに

return [
    "sex" => [
        "1" => "男",
        "2" => "女",
    ]
];

上記のような定義を例えばcommon.phpにした場合、以下のように記述できます。

<select name="sex">
    @foreach(config('common.sex') as $index => $value)
        <option value='{{ $index }}' @if(old('sex') == $index) selected @endif >{{ $value }}</option>
    @endforeach
</select>

Javascriptのクロージャについての解説です。

Javascirptのクロージャとは何か

Javascriptのクロージャとは何か。

私の理解では

関数の中で関数を定義したもの

という理解です。
(あくまで私の理解です)

まず、基本的なところで

・　関数を定義すると、関数内で定義した変数は関数外部から参照できない

という性質があります。
これはほとんどの人が知っていると思います。

例えば

function func() {
  var value = 1;
  console.log(value);
}
func(); // 1
console.log(value); // undefined

上記のようなプログラムの場合、関数を実行した場合、実行結果は
1になりますが、関数内の変数を出力した場合、
参照できていません。

function func() {
  var value = 1;

  function innerFunc() {
    value++;
  }
  innerFunc();
  console.log(value); // 2
}
func();

上記のようなプログラムの場合、関数の内部でinnerFuncという関数を定義して関数内で実行しています。
このinnerFUncをクロージャといいます。

innerFunc内では、外側の関数（エンクロージャ）で定義している
変数valueを呼び出していますが、その値を参照できているだけでなく、
更新することができます。

つまり、javascriptでは、関数の中で定義された関数の仕様は通常の
関数と、その外側の領域と違い、その関数内部で変数を参照したり、更新
したりできるのです。

このような仕組みを利用して、関数を定義する際に使用することがありますので、
性質として覚えておくと良いでしょう。

どのようなときに使うのか？

上記のクロージャの仕組みを使うと、関数内の変数の値を維持したまま、
その関数内の値を更新するプログラムをかけたりします。

例えば、関数内で定義した変数を、その関数内の関数を定義して返すような
関数にすることで、関数の外で変数を定義して更新したりしなくても、
関数を実行する度に関数を実行できたりするわけです。

書き方によってはクロージャを使わなくても実装できる場合もありますが、
コードがよりシンプルになったり、便利なケースがあるようです。
（未だにそういう場面に遭遇したことがないので分からない・・・）

JavascrotのSymbol機能は、もともとJavascriptに存在していた機能ではありません。

ECMAScript6 (ES6, ES2015) で導入された機能です。

使い方

var a = Symbol();

このように使うことができます。

こうすることで、aには他の値を被らない値(具体的な数値ではない)が、自動生成されて代入されます。

例えば

var a = Symbol();
var b = Symbol();

上記のように定義しても、aとbの値は異なった値になります。

値の型はtypeofをすると「symbol」と表示される、独自の型となっています。

何のために存在しているのか

何故このような機能が追加されたのかというと、
自分でユニークな値を設定したつもりでも、他の値と予期しない形で衝突することが
あるため、そのような状況を防ぐためです。

PHPの無名関数(クロージャ)についてのまとめです。

無名関数とは

無名関数とは、関数規則に沿って命名を必要とせず定義できる関数です。

function(引数) {
処理内容;
}

といった形で使用できます。

例えば

$func = function(引数) {
処理内容
}

といった形で定義した場合、この$funcは、ラムダ関数とも呼ばれます。

$a = $func(引数);

このような形式で、使用する場所で呼んで使用できます。

無名関数を使用するメリット

無名関数は概念的には関数と同じなので、無名関数にせず関数として定義して呼び出しても同じなのですが、
普通の関数を定義無名関数を使用することにより、その場限りで呼び出す処理の場合は、関数名を他の関数名と衝突しないで済む、プログラム全体が複雑にならないといったメリットがあります。

無名関数内の処理に外部の変数を使用したい場合

プログラムによっては、無名関数の中で使用するプログラムに、無名関数の外の変数を使用したい場合があります。

無名関数は関数なので、引数にしている変数以外の外部の変数は内部の処理には適用されません。

しかし、use文を使うことでその問題は解決できます。

$func = function(引数A) use(変数B) {
処理内容;
}

このように無名関数を使用することで、処理内容で引数Aだけでなく外部の変数Bも使用できます。

Laravelのbladeテンプレートで、配列をforeachなどの構文でループで回すことはよくありますが、配列の要素が存在するかどうかをテンプレート上に記述したい場合があります。

その場合、以下のように記述できます。

@if(!$posts->isEmpty())

        


        @foreach ($posts as $post)
            
{{ $post->title }}
        @endforeach

        

        @else

            
検索条件に合致する内容がありませんでした

        @endif

上記の場合は、配列postsが空かどうかを判定し、空出ない場合はループ処理を記載しています。

配列にない場合はelse後の処理に記載しています。

Bootstrap4で、横長のtableにtable-responsiveクラスを適用して、はみ出させずに横スクロールさせようと思っていたのですが、何故かtable-responsiveを適用してもtableが横に飛び出したままで横スクロールが出現しませんでした。

書いていたコードは以下のような内容です。

-----

これで行けるはずなのですが・・・・

そしていろいろ試してみたのですが、原因がわかりました。

　←　親要素のこれが原因


-----

原因としては、div class=”table-responsive”の親要素に、class=”row”が入っていました。

これを削除することで動作するようになりました。

修正後

　←　class="row"を削除


-----

TinyMCEを、特定のフォームに対して無効にする方法についての解説です。

TinyMCEは、簡単に入力欄にWYSIWYGを導入できるので便利ですが、
デフォルトの設定だと全てのtextareaにWYSIWYGが導入されてしまうため、WYSIWYGがついてほしくない
textareaはどうしたらいいのか分からず少し調べました。

TinyMCEのバージョンによって設定方法が異なると思うので、自分が使っているバージョン（4系）についてです。

TinyMCEを導入する際に、ヘッダの部分に以下のような記述があると思います。

tinymce.init({
            selector: "textarea",
            branding: false,

この箇所を、以下のように書き換えます

tinymce.init({
            selector: "textarea#mce",
            branding: false,

こうすることで、「textarea id=”mce”」となっているtextareaのみがTinyMCEの対象になります。

ちなみに、classでもいけます。

tinymce.init({
            selector: "textarea.mce",
            branding: false,

idだと、１つのテキストエリアしか対象にできないので、複数のテキストエリアを対象にしたい場合は、クラスで定義するのが有効です。

Laravelのマイグレーションで、カラム変更の機能を使う場合に、以下のエラーが発生しました

Changing columns for table “table” requires Doctrine DBAL; install “doctrine/dbal”.

テーブルのカラム変更をするにはdoctrine/dbalをインストールしろということ
公式サイトを確認したところ

composer require doctrine/dbal

をしないとエラーになるということで、実行。

すると、ここでもエラー

Installation failed, reverting ./composer.json to its original content.

インストールに失敗したので、composer.jsonを元に戻しましたということ。
もうちょっとエラーの内容を詳細に見てみます。

Your requirements could not be resolved to an installable set of packages.
あなたの要求は、インストール可能なパッケージのセットに対して解決できません

Problem 1
– The requested package laravel/framework (locked at v5.8.2, required as 5.7.*) is satisfiable by laravel/framework[v5.8.2] but these conflict with your requirements or minimum-stability.

要求されたパッケージはLaravel5.8.2系を必要としているので、あなたのLaravelのバージョンに対しては対応できません

ということ。

というわけで、Laravelｎバージョンを5.8系にアップすることで解決できました。

まずは、composer.jsonを編集します。

“require”: {
“php”: “^7.1.3”,
“doctrine/dbal”: “^2.9”,
“fideloper/proxy”: “^4.0”,
//ここを変更
“laravel/framework”: “5.7.*”,→”laravel/framework”: “5.8.*”,
“laravel/tinker”: “^1.0”
},

ここが5.7系になっていたので、5.8系に変更します。

その後、composer update

これで、Laravelのバージョンが5.8系に変更され、その後

composer require doctrine/dbal

これで無事インストールできました。

Laravel5のフォームを作っていて、textareaの入力欄にWYSIWYGエディタを導入してWordPressっぽくするというのを
試していたのですが、以下の記事を参考にして実装することができました。

Laravel5にWYSIWYGエディタを実装する方法 | Qiita

詳しくは上記の記事を参考にしていただければ簡単に実装できます。

手順としては、

１・TinyMCE をダウンロードして、サーバへアップロード

２・jbimages をダウンロードして、TinyMCEのpluginsフォルダへアップロード
(configファイルの画像の保存パスの変更と、該当フォルダに書き込み権限をつける必要あり)

３・実装するサイトのヘッダにjsファイルのincludeと、javascriptのコードを追記する

これだけで、至って簡単に実装することができました。

ただ、上記のQiitaの記事が若干古くなっていました。

この記事執筆時点（2019年3月）では、TinyMCEの最新バージョンが5系となっていたのですが、jbimagesは4系にしか対応していないので、TinyMCEの4系をサイトからダウンロードして使用する必要があります。（5系では動作しませんでしたが、将来的には対応しているかもしれません）

4系での設定方法は、以下のページに解説がありました。

JustBoil.me TinyMCE Images Plugin — A simple solution for uploading images in TinyMCE

Bootstrap4で、テーブルのtdの横幅を設定する方法についての解説です。

Bootstrap3までは、テーブルのtdに、グリッドのクラスをつけることで横幅がグリッドシステムを使って設定できていたのですが、Bootstrap4からはできなくなったみたいです。

bootstrap3でできていた

これが、bootstrap4ではできなくなっているので、スタイルで横幅を指定する必要があるようです。

参考
How to set up fixed width for td? | strackoverflow

何故Bootstrap4でできなくなってしまったのか分かりませんが、直書きで指定するっていうのも嫌ですが、仕方ないですね。
もっとシンプルに書けるいい方法がないもんなのでしょうか。

Laravelの認証機能で、ユーザ登録をできなくする方法についての解説です。

Laravelには、標準でAuth(認証機能)がついているので、標準で入っている認証機能を導入するのは非常に簡単です。

しかし、この標準のAuth機能は、Authをかけているページをログインページにリダイレクトし、そこでメールアドレスとパスワードを入力すればログインすることがでできるのですが、新規登録への導線がついているので、管理者だけログインできればよくて、それ以外のユーザの新規登録を受け付けていない場合があると思います。

そのような場合でも、routesの設定を変更することで簡単に対応することが可能です。

php artisan:make auth

をすることで、routesのweb.phpに以下の２行が追加されていると思います。

Auth::routes();

Route::get('/home', '[email protected]')->name('home');

これを、以下のように変更すればOKです。

//ここを変更
Auth::routes(['register' => false]);

Route::get('/home', '[email protected]')->name('home');

これをすることで、ログイン画面にRegisterと表示されている部分が消え、登録ができなくなる他、登録URLにアクセスしても404 not foundになります。

合わせてRegisterControllerを削除するように、Laravel公式サイトには書いてありますが、特にその対応をしなくても機能しなくなっていたので問題ありませんでしたが、一応削除しておくと良いと思います。

boostrrap４で、h1のフォントサイズを変更する方法についての解説です。

何故h1のフォントサイズ変更が必要か

boostrap4で、h1のフォントサイズがデフォルトでh1のままだと大きすぎると思っていました。

大きすぎる

これを調整する方法なのですが、クラス名のh1からh6を指定することで調整できるのです。

クラスでh6を指定してやるとだいぶ小さくできました。

大きすぎる
h1で指定されているけど大きさはh6の大きさ

クラスはh1からh6まで指定できるので、好みの大きさを指定すると良いです。

Laravelのファイルとフォルダのパーミッション設定についてです。

下記の記事が参考になりました。

Laravelのパーミッションを適切に設定 | Qiita

ディレクトリに対して権限を変更
sudo find laravel-root-directory -type d -exec chmod 750 {} \;

ディレクトリは750なので、所有者は全部可能、グループは読み実行可能、その他はできない設定

ファイルに対して権限を変更
sudo find laravel-root-directory -type f -exec chmod 640 {} \;

ファイルは640なので、所有者は読み、上書き可能、グループは読みのみ可能、その他はできない設定

最後にストレージとキャッシュの権限を変更
sudo chmod -R 770 laravel-root-directory/storage/ laravel-root-directory/bootstrap/cache/

ストレージ、キャッシュフォルダは所有者、グループは全部可能。その他はできない設定。

webサーバーのApacheをインストールすると作成されるwww-dataをグループに追加する
sudo chown -R myusername:www-data laravel-root-directory

これは、上記はwww-dataグループになっていますが、自分の環境（CentOS、nginx）では、httpdのグループがwwwだったので、以下の設定で上手くいきました。

sudo chown -R myusername:www laravel-root-directory

グループ「www」がphpを自分の環境の場合実行しているので、phpファイルは読み出しのみの設定で問題ありませんでした。
phpファイルの実行権限は、所有者、グループとも読みのみで問題ないんですね。
実行権限が必要なのかなとイメージ的には思っていたのですが。

例えばPerlなんかはCGIで755にするのが一般的でしたが、755ってのは所有者は全部できて、グループユーザが読み、実行権限があるということですもんね・・・。

使っているPHPはPHP-ｆｐｍなので、モジュール版ではなくてCGI版なのですが、同じCGIでもPerlとPHP-FPMではパーミッションが違うと、これはややこしい話です・・・。

LaravelをCentOS、nginx環境にインストールしたのですが、初期設定完了後にサイトへアクセスすると、404エラーが発生しました。

エラーログを確認すると

permisson denied

が発生

phpファイルへのアクセスが拒否されているようです。

該当のエラーが起きているファイルやディレクトリを

chmod 777 エラーが起きているファイル

にしています。

結果、そこから先のファイルがさらにエラー

プロジェクトフォルダとファイルを全て777にしたらいけるんでしょうけど、それはそれでセキュリティに不安が残ります。

そもそも、nginx環境のphpのサイトで、プロセスを実行しているユーザってどのユーザなのでしょうか。

ps　コマンドでプロセスを監視してみます。

すると

httpd php-fpm

となっていたので、ユーザ「httpd」が実行しているようです。

ユーザ「http」が属しているグループはどこなのでしょうか。

groups httpd

httpd : www

ということで、httpdユーザは、グループ「www」に所属していました。

プロジェクトフォルダのオーナーをwwwに変更してみます。

chown -R ユーザ名:www プロジェクトフォルダ名

これで、該当のフォルダのオーナーのグループが「www」になりました。

これで、サイトにアクセスするとエラーが消えて無事にサイトが表示されました。

サーバはkusanagiを利用しているのですが、

phpinfo();

で表示されるphpのバージョンは7系なのに、

サーバにログインして、コマンドラインで

php -v

で表示されるのは、5系というよくわからない事象に遭遇して困ってしまいました。

これで何故困るかというと、Composerをアップデートしたときに、以下のようなエラーが出たからです

このComposerのアップデートには、phpの7系が必要だよ

みたいなエラーです。

しかし、phpinfo()で確認すると使っているPHPのバージョンは7系で、サーバにログインしてコマンドラインで実行している
Composerは5系のPHPを見ているようだという謎です。

調べてみると、KusanagiのPHPは、Webサーバで実行しているのはPHP-fpmというCGI版のPHPで、コマンドラインで実行しているのは、apache経由でモジュール版のphp5系で実行しているとかとういったかんじの現象のようでした。

Kusanagiのサーバでは、rootでサーバにログインして

kuasanagi php7

を実行することでphp7の実行環境に切り替わるようですが、apacheのモジュール版はphp7になっていない？？

というよく分からない感じです。

さらに調べると、Kusanagiではサーバにログインして

yum update

で、モジュール版もPHP7に切り替わるといったことが書いてあったので、試してみると、

yum updateでエラー

で、これはサーバのPythonのバージョンを3系に上げていたので、Python2系で書かれているyumがエラーを起こしている様子
これは、いろいろとぐぐることで対応方法が出てきたので、yumのソースで、Pythonのパスが書いてあるところを、
サーバに残っているPython2系へのパスに何箇所か変更します。

これで yum update　が実行できました。

これで、満を持して

php -v

を実行。すると、またも

php 5.6〜〜〜

と。え、php7に変わってない・・・？

いったん諦めてから翌日サーバにログインして

php -v

をもう一度実行してみると

PHP 7.3.1 (cli)

と、無事アップデートしてました。

よく分からないですが、yum updateしてからサーバに反映されるのに
時間が必要だった？みたいで、apacheを再起動することで反映されたのか、
よく分かりませんが、何にせよ時間経過で反映されました。

よく分かりませんが、Composerで実行していたPHPは、モジュール版というよりも、CLI版
というPHPのようで、確かにphp -vをすると

PHP バージョン(cli)

と、cliを後についています。
ここのCLI版のバージョンが影響していたようですが、何にせよ今回のケースでは
yum update　で無事解決したようです。

この後、

Composer update

を実行すると、無事エラーにならずアップデートを行うことができました。

CentOSで、suコマンド(ユーザの変更)を実行した際に、以下のエラーメッセージが表示されました。

実行しようとしたコマンド
su ユーザ名

表示結果
bash: /home/ユーザのホームディレクトリ/.bashrc: 許可がありません

原因と対処

いろいろと調べてみたところ、該当のユーザのホームディレクトリに、そのユーザのアクセス権限がなかったことが原因でした。
何かの作業中に、間違ってそのディレクトリのオーナー権限を変更していたが原因だったみたいです。

以下の対応で解決しました。

cd /home/

chown ユーザ名:ユーザ名 ./ユーザのホームディレクトリ

これは、該当のディレクトリのオーナーとグループをそのユーザにするということです。

この後に再度suコマンドで該当のユーザに変更したところ、問題なく実行できるようになりました。

Linux系のサーバにrootユーザでログインして、Composerを実行しようとすると、以下の警告メッセージが表示されます

Do not run Composer as root/super user! See https://getcomposer.org/root for details

https://getcomposer.org/root　を見ろということなのでアクセスしてみると、説明がありました。

How do I install untrusted packages safely? Is it safe to run Composer as superuser or root?

どうやって信頼されてないパッケージを安全にインストールできますか？
Composerをスーパーユーザやルートユーザで安全に実行できますか？

Certain Composer commands, including exec, install, and update allow third party code to execute on your system. This is from its “plugins” and “scripts” features. Plugins and scripts have full access to the user account which runs Composer. For this reason, it is strongly advised to avoid running Composer as super-user/root.

Composerのコマンドには、実行、インストール、アップデートが含まれていて、システムに影響するコードを実行することをサードパーティに許可します。
これは、プラグインとスクリプトの特徴に由来しています。プラグインとスクリプトはComposerを実行するユーザアカウントに完全にアクセスします。
この理由により、Composerをrootユーザで実行しないことを強く推奨します。

You can disable plugins and scripts during package installation or updates with the following syntax so only Composer’s code, and no third party code, will execute:

あなたはプラグインとスクリプトを、パッケージをインストールかアップデート時に以下のコードを追加することで無効にすることができます。
サードパーティのコードは実行できなくなります。

composer install –no-plugins –no-scripts …
composer update –no-plugins –no-scripts …

The exec command will always run third party code as the user which runs composer.

In some cases, like in CI systems or such where you want to install untrusted dependencies, the safest way to do it is to run the above command.

execコマンドはサードパーティのコードをcomposerを実行するユーザと同じように実行します。

いくつかのケースで、CIシステムまたは信頼されていない依存関係をインストールするときに、最も安全なのは上記のようなコマンドで実行することです。

ComposerはPHPのパッケージ管理ツールですが、Composerを使用する前に、まず環境にComposerがインストールされているかの確認が必要になります。

CentOSでの確認方法についてですが、導入が完了されている状況であれば、コマンドラインで

composer

と打てば、下記のようなコマンドが表示されます。
インストールされている場合は、現在の入っているComposerのバージョンも確認できます。

Composerのインストールは、公式サイトからインストーラーをダウンロードしてセットアップ後、作成されたcomposer.pharを、

/usr/local/bin/composer

へ移動させることで実行可能になるので、ここまでができていれば上記の様な画面が表示されます。

なければcomposerコマンドが実行できないはずです。

インストールの手順は以下の通りです。

php -r “copy(‘https://getcomposer.org/installer’, ‘composer-setup.php’);”

php composer-setup.php

php -r “unlink(‘composer-setup.php’);”

mv composer.phar /usr/local/bin/composer

Laravel Homesteadで、2つ目のサイトを追加する手順についてです。

Homesteadに２つ目のサイトを追加する手順についてですが、メインマシンのHomesteadディレクトリにある、Homesteadディレクトリにサイト構成を追記します。

Homestead.yml

sites:
– map: homestead.test
to: /home/vagrant/code/project1/Laravel/public

– map: homestead.test2
to: /home/vagrant/code/project2/public

databases:
– homestead

– site2

サイトと、データベースに必要なデータを追加します。

その後、Vagrantを再起動します

vagrant reload –provision

メインマシンのhostsファイルに、2つ目のサイトの設定を追記します。

192.168.10.10 homestead.test2

これで、homestead.site2にアクセスすると、

no input file specified

となります。

2つ目のサイトにLaravelがインストールされていないためです。

メインマシンから

vagrant ssh

で仮想マシンにログインします。

Laravelをプロジェクトフォルダにインストールします。

cd /home/vagrant/code/
composer create-project –prefer-dist laravel/laravel project2

この後、

homestead.site2

にアクセスして、Laravelの初期サイトが表示されたら初期設定完了となります。

Ubuntuのサーバで、特定のディレクトリを削除しようとしたところ、エラーが発生して削除できませんでした。

実行しようとしたコマンド
rmdir ./directory

発生したエラー
rmdir: failed to remove ‘./diectory’: Device or resource busy

このエラーについて調べてみたのですが、削除しようとしたディレクトリが、マウントディレクトリになっているということで、削除できないようです。

以下の対処をすることで削除できるようになりました。

sudo umount ./directory

上記コマンド(ディレクトリのマウントを解除)実行後、

rmdir ./directory

これで問題なく削除できるようになりました。

Laravelで認証機能を使う方法についての解説です。

Laravelには認証に必要な機能が最初から準備されているので、必要であれば使用することができます。

ちなみに、普通にベーシック認証を行うのであれば、.htaccessを使えばいいのですが、ここで言っている認証とは、ユーザIDとPWを入力してログインし、ログインしていなければログインページに飛ばされるというやつです。

あまりカスタマイズしないのであれば簡単に実装できます。

artisanでauth機能を準備する

コマンドラインで、Laraｖelのプロジェクトフォルダに移動し、

php artisan make:auth

このコマンドを実行します。

これを準備することで、必要なファイルがLaravelディレクトリに生成されます。

rouesファイルに追記されている

routesのweb.phpに、さきほどのコマンドを実行することで、下の２行の記述が追加されています。

Auth::routes();

Route::get(‘/home’, ‘[email protected]’)->name(‘home’);

上記は、homeディレクトリにアクセスしたときに、ログイン画面が表示される記述です。

あとは、ルートファイルの認証をかけたいページに、以下の記述を追加することで、該当するページに認証がかかります。

Route::get(‘/admin’, ‘[email protected]’)->middleware(‘auth’);

基本認証

ログイン画面を通した認証でなく、基本認証をしたい場合も簡単に実装できます。

auth.basicミドルウェアを使用します。

Route::get(‘/admin’, ‘[email protected]’)->middleware(‘auth.basic’);

基本認証を使用した場合に求められるID/PWは、laravelでプロジェクトを作成後にmigrateで作成される、userテーブルに登録されているユーザemailとパスワードと同じになります。

Laravelをインストール後に、初期設定で変えておく場所についてのメモ書きです。

.envファイル

.envファイルは、Laravelをインストールにしたフォルダにあります。

ここに、プロジェクトが接続するデータベースに関する設定などの情報が保存してあるので、必要に応じて変更する必要があります。

.envファイルを変更した後に反映させるには、

php artisan config:clear

を実行する必要があります。

app.php

/config/ディレクトリにある「app.php」ファイルに、いくつか設定に関する項目があります。

timezoneの設定です。日本のサイトの場合は、Asia/Tokyoにしておくとよいでしょう。

‘timezone’ => ‘Asia/Tokyo’,

デフォルトでは、en になっていますが、これは英語ということなので、日本語に設定します。

‘locale’ => ‘ja’,

ただし、これだけでは英語のままでに保護になりません。

/resources/lang/en

このフォルダとその中のファイル群を

/resources/kang/en

にまるっとコピーします。

あとは、それ以下にエラーメッセージの文章が全部英語で書いてあるので、それを
地道に日本語に変更します。

全部変更すると大変なので、使っているぶんだけ変更することでも問題ないと思います。

以下に翻訳版が上がっていました。
5.1のだそうですが・・・。

Laravel 5.1 日本語バリデーションメッセージファイル

また、これだけでは attributeが英語で出力されるので

さきほどの validation.phpの

‘attributes’ => [],

このようにすることで、対応するattributeが日本語で出力されます。

‘attributes’ => [
‘title’ => ‘タイトル’,
‘body’ => ‘本文’,
]

Laravel5.7で、フォームを作っていてエラー発生時に入力のフォームの値を保持する方法についてです。

結論からいうと、bladeテンプレートに　{{ old(‘項目名’) }}　の値をもたせることで入力前の値を保持できます。

こんなかんじです。

 <table class="table table-striped">

            <tr>
                <td>タイトル</td>
                <td><input type="text" name="title" value="{{ old('title') }}" placeholder="タイトルが入ります" /></td>
            </tr>

            <tr>
                <td>本文</td>
                <td><textarea name="body">{{ old('body') }}</textarea></td>
            </tr>

これは、入力値のフォームなので、はじめは空欄なので、入力前の値だけ保持できていればいいですが、これが編集する場合だと

初期）　編集前の値を持っている
エラー時）　入力エラーの値を持っている

の２つの状態を持っている必要があります。

これは以下のように記述することで解決できます。

<table class="table table-striped">

            <tr>
                <td>タイトル</td>
                <td><input type="text" name="title" value="{{ old('title' , $post->title) }}" /></td>
            </tr>

            <tr>
                <td>本文</td>
                <td><textarea name="body">{{ old('body', $post->body) }}</textarea></td>
            </tr>

oldの２つ目にデフォルト値を持たせることができます。

Laravelで簡単なフォームを作るのは基礎中の基礎ですが、慣れないうちは何箇所かつまづいたので記録に残しておきます。

フォームの仕様

記事を投稿してデータベースに保存する

件名(タイトル)と本文を入力し、データベースへ保存する。

サイトへアクセスすることで保存された記事一覧と、

ただこれだけのシンプルな仕様。

まずは環境構築

環境構築にはhomesteadを利用しました。

手順はこちらの記事に書いているので割愛します。

Laravel Homestead導入時の悪戦苦闘メモ

最初にやったのは古いバージョン(Laravel4系)だったので、再度やりなおしてLaravel5系でやってみました。

Laravel HomesteadをPHP7で動作させる

環境構築に手間取りましたが、ようやく動作したのでフォームの制作

１．マイグレーションでデータベースを作成

まずは、Homesteadの環境にログイン後、Artisanコマンドでテーブルを作成します
今回は、記事を投稿するので、postsというテーブルを作成

php artisan make:migration create_posts_table –create=posts

public function up()
    {
        Schema::create('posts', function (Blueprint $table) {
            $table->increments('id');
            $table->string('title');
            $table->text('body');
            $table->boolean('delete_flg')->default(0);
            $table->timestamps();
        });
    }

ファイルを作成した後、

php artisan migrate

でテーブルを作成します。

モデル作成

テーブルを作成後、テーブルに対応したモデルを作成します。

php artisan make:model Post

これで、

/App/Post.php

が作成されました。
これで、テーブルに対応したオブジェクトを呼び出すことができるようになります。

このモデルはあとで使います。

管理画面を作る

まずは、記事を投稿する管理画面を作ります。

まずは管理画面の処理に対応するコントローラーを作成します。

php artisan make:controller AdminEntryController

これで、/Http/Controllers/AdminEntryController.phpが作成されました。

このファイルには管理画面の処理に対応する記述を追加していきます。

この時点では雛形が作られただけで処理は何も入っていません。

ルーティングを記述する

/admin/entry にアクセスしたとき、管理画面の投稿画面を表示するようにします。

ルーティングを記述ファイルは、/routes/web.phpにあります。

これに以下を追記します。

Route::get(‘/admin/entry’, ‘[email protected]’);

これでは、url「/admin」にアクセスしたときに、コントローラAdminEntryControllerの「top」メソッドにアクセスするということです。

最初は、とりあえずテンプレートを単純に表示するだけにしてみます。

public function top()
    {
        return view('admin.entry');
    }

これは、このメソッドが実行されたときに

/resources/views/admin/index.blade.phpを表示するという処理です。

まだテンプレートを作成してないので、URLにアクセスしてもエラーになります。

テンプレートを作成します。

bladeテンプレートの作成

bladeテンプレートは、laravelで使われているテンプレートで固有の記法があります。

CMSやフレームワークを使ったことがある人であればテンプレートという説明を聞くと大体イメージがつかめると思いますが、基本的には同じです。

ただ、bladeテンプレートの特徴としては、親と子の継承というものが特徴です。

大体のサイトは、基本となる共通部分があって、後はコンテンツ部分やタイトルなど、一部異なる部分があります。

Laravelのbladeテンプレートでは、共通している部分をまず、親のテンプレートとして作成します。

あとは、それぞれのページは、親のテンプレートを継承することで、異なる部分だけ作成するというようなイメージです。

この特徴により、子のテンプレートは最小限の記述で、また必要なテンプレートも最小限ですみます。

これで、bladeテンプレートの作成が完了したら、/admin/へアクセスすると、エラーがなければサイトが表示されます。

フォームを作成する

とりあえず、作成したフォームの雛形のテンプレートは以下の通りです。

注意が必要な点としては、フォームは、デフォルトの設定では、クロスサイトリクエストフォージェリ対策に、@csrfをテンプレートに埋め込んで置く必要があります。
これを書いていないと投稿時にエラーになります。

@extends('admin.parent')

@section('title', '投稿管理(入力画面)')

@section('content')
    <form action="/admin/entry/" method="post" id="formid" enctype="multipart/form-data">

        @csrf

        <table class="table table-striped">

            <tr>
                <td>タイトル</td>
                <td><input type="text" name="title" value="" placeholder="タイトルが入ります" /></td>
            </tr>

            <tr>
                <td>本文</td>
                <td><textarea name="body"></textarea></td>
            </tr>

            <tr>
                <td colspan="2" class="text-center">
                    <input type="submit" name="submit22" value="登録" class="btn btn-primary">
                    　<input type="hidden" name="action" value="ok">
                </td>

            </tr>

        </table>

    </form>
@endsection

これを、実行したときに登録する処理を追加する必要があります。

まずは、ルーティングに以下を追加します。

Route::post(‘/admin/entry’, ‘[email protected]’);

最初のルーティングは、getで書いてましたが、投稿の処理はpostで渡すことで処理を分岐できます。

postでURLにアクセスしたときには、同じコントローラーでも異なるメソッドを実行するようにしています。

上記の処理ではcompleteメソッドを実行します。

completeメソッドの定義

completeメソッドを以下のように定義しました。

    public function complete(Request $request)
    {
        $post = new Post();

        $post->title = $request->input('title');
        $post->body = $request->input('body');

        //セーブメソッドは、継承している親クラスのモデルオブジェクトに定義されている
        $post->save();

        return view('admin.complete');
    }

$post = new Post();

で、最初に作成したPostモデルのオブジェクトを呼び出しています。

この記述で行うには、ファイルの先頭に

use App\Post;

を追記しておく必要があります。

この追記がない場合

$post = new App\Post();

になります。

その変数にポストで投げられた値をリクエストから取得して、saveメソッドでデータベースへ保存します。

その後は、完了画面のテンプレートを表示します。

この処理はかなりシンプルですが、Laravel独特の記法なので、覚えておく必要があります。

エラーがなければ、これでフォームの保存が実行できます。

投稿のサイトへの表示

今度はサイトに表示する処理を書いてみます。

一覧画面と詳細画面に分けて作成します。

まずはルーティングに必要な処理を追加します。

//トップページで一覧表示
Route::get(‘/’, ‘[email protected]’);

//詳細ページの表示
Route::get(‘/post/{id}’, ‘[email protected]’);

この例では、ページの表示処理を、PostsControllerというクラスを作成して行います。

トップページに一覧を表示する（indexメソッドの実行）処理、詳細ページを表示する処理（detailメソッドの実行）に分けています。

PostControllerは、最初と同じく

php artisan make:controller PostController

で作成しておきます。

以下が、PostsControllerクラスに定義した、トップページと詳細ページの表示のメソッドです。

use App\Post;

class PostsController extends Controller
{
    //トップページを表示する
    public function index(Request $request) {

        $posts = Post::where('delete_flg' , '<>', '1')
            ->get();

        return view('index', compact('posts'));

    }


    //ブログ詳細記事を表示する
    public function detail(Request $request, $id) {

        $post = Post::find($id);

        return view('post', compact('post'));

    }
}

indexメソッドでは、削除フラグが1でなく記事を取得するような処理を行っています。

detailメソッドでは、URLから取得したユーザIDに該当する記事を取得して、テンプレートに表示しています。

bladeテンプレートはそれぞれ以下のように定義しています。

@extends('layout')

@section('title', "新着記事")

@section('content')

    <ul>

    @foreach ($posts as $post)
        <li><a href="/post/{{ $post->id }}">{{ $post->title }}({{ $post->created_at->format('Y年m月d日') }})</a></li>
    @endforeach

    </ul>

@endsection

@extends('layout')

@section('title', $post->title)

@section('content')

    <p class="text-right">{{ $post->created_at->format('Y年m月d日') }}</p>

    <div class="contents">
    {!! nl2br(e($post->body)) !!}
    </div>

@endsection

記事の編集、削除

最後に、管理画面から記事の編集と削除を行えるような処理を追加します。

今回のケースでは、ルートファイルにまず以下のような処理を追記しました。

Route::get('/admin/edit/{id}', '[email protected]');

Route::post('/admin/edit/{id}', '[email protected]');

Route::get('/admin/delete/{id}', '[email protected]');

編集画面は、同じURLでアクセスしますが、最初はgetでアクセスし、編集完了処理はpostでアクセスすることで実行するメソッドを分けています。

//記事を編集する
    public function edit(Request $request, $id) {

        $post = Post::find($id);

        return view('admin.edit', compact('post'));

    }

    //記事の修正を完了する
    public function store(Request $request , $id)
    {
        $post = Post::find($id);

        $post->title = $request->input('title');
        $post->body = $request->input('body');

        //セーブメソッドは、継承している親クラスのモデルオブジェクトに定義されている
        $post->save();

        return view('admin.complete');
    }

    //記事の削除を完了する
    public function delete(Request $request , $id)
    {
        $post = Post::find($id);

        $post->delete_flg = 1;

        //セーブメソッドは、継承している親クラスのモデルオブジェクトに定義されている
        $post->save();

        return view('admin.delete');
    }

削除処理は、delete処理を使うのではなく、一応データベースには残しておきたいので、delete_flgを１にするアップデート処理にしています。

管理画面のトップページのbledeテンプレートも、記事一覧を表示するように変更しておきました。

@extends('admin.parent')

@section('title', '投稿管理')

@section('content')
<div class="text-right">
    <input type="submit" name="submit" value="新規登録" class="btn btn-primary" onclick="location.href='/admin/entry/'" />
</div>

    <div class="content">

        <table>
            @foreach ($posts as $post)
                <tr><td><a href="/post/{{ $post->id }}">{{ $post->title }}</a></td><td><input type="submit" value="編集" onclick="location.href='/admin/edit/{{ $post->id }}'" ></td><td><input type="submit" value="削除" onclick="location.href='/admin/delete/{{ $post->id }}'" ></td></tr>
            @endforeach
        </table>

    </div>

@endsection

ヘルパーを使ってテンプレートの記述を簡素化する

上記の例では、テンプレートの記述がややごちゃごちゃしていますが、
ヘルパーを導入することで、テンプレートの記述をすっきりすることができます。

詳しくは、以下のサイトに解説があります。

初めてのLaravel 5.6 : (16) Formの作成 – ララ帳

composer require “laravelcollective/html”:”^5.7.0″

これでヘルパーが導入できるので、これで以下のように記述することができます。

@extends('layout')
 
@section('content')
    
Write a New Article
 
    

 
    {!! Form::open() !!}
        

            {!! Form::label('title', 'Title:') !!}
            {!! Form::text('title', null, ['class' => 'form-control']) !!}
        
        

            {!! Form::label('body', 'Body:') !!}
            {!! Form::textarea('body', null, ['class' => 'form-control']) !!}
        
        

            {!! Form::label('published_at', 'Publish On:') !!}
            {!! Form::input('date', 'published_at', date('Y-m-d'), ['class' => 'form-control']) !!}
        
    
        

            {!! Form::submit('Add Article', ['class' => 'btn btn-primary form-control']) !!}
        
    {!! Form::close() !!}
@endsection

Laravelでサイトを構築するのに、仮想環境でHomesteadを利用していたのですが、サイトへアクセスすると、最初だけ「502 Bad Gateway」というエラーが表示される状況に遭遇しました。

しかも、ずっと表示されるわけでなく、何回か再読込をすると解消するという謎の状況。

とりあえず、nginxのエラーログを見てみると、以下のエラーが。

[error] 2276#2276: *472 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.10.1, server: homestead.test, request: “GET / HTTP/1.1”, upstream: “fastcgi://unix:/var/run/php/php7.3-fpm.sock:”, host: “homestead.test”

このエラーで対処法をググっていろいろ調べていたところ、対処法が見つかりました

New Laravel (Homestead) installation: 502 Bad Gateway – *Refresh* – the website is displayed correctly | stackoverflow

以下の通りにすることで治りました。

まずは、/etc/php/7.3/mods-available/xdebug.iniを編集します

sudo vim /etc/php/7.3/mods-available/xdebug.ini

上記ファイルの行の頭に「;」を全てつけてコメントアウトします。

nginxと、php7.3-fpmを再起動します

sudo service nginx restart
sudo service php7.3-fpm restart

これで、502 bad gatewayのエラーは出なくなりました。

xdebugというのが、phpのエラーを詳細に追いかけるツールだそうで、それが有効になっていることの副作用的なかんじでしょうか？

何にせよ上記を無効にすることで治りました。

Homesteadのlaravelで、artisan migrateでデータベースを作成しようとしたところ、エラーが起きました。

実行したコマンド
php artisan migrate

エラーの内容
SQLSTATE[HY000] [1045] Access denied for user ‘homestead’@’localhost’ (usin
g password: YES) (SQL: select * from information_schema.tables where table_
schema = homestead and table_name = migrations)

原因についてですが、laravelの実行ディレクトリで、「.env」ファイルを編集する必要があるということなので、編集してみましたが、結局同じエラーが出て接続できません。

さらに原因を調べてみたのですが、「.env」ファイルを変更してもそれを反映させるためにコマンドを実行する必要がありました。

laravelの実行ディレクトリで、以下のコマンドを実行します。

php artisan config:clear

これで、再度マイグレーションを実行したところ、問題なく実行され、データベースにも反映されました。

Laravel HomesteadをPHP7で動作させる方法についてです。

Laravelの仮想環境のLaravel Homesteadについて検証していたのですが、公式サイトのチュートリアルに沿って導入していると、何故かLaravelと、対応するPHPが5系でした。

最新のPHP7に対応させるための方法を探していたのですが、調べると何のことはなく、公式サイトのHomesteadのチュートリアルにはPHP5系に対応する記事と、PHP7に対応する記事でそれぞれチュートリアルがあるだけでした。

前の記事で紹介していたのは、4.2なのでphp5系に対応してました

Laravel 4.2 Homestead (PHP5対応)

Laravel 5.7 Homestead (PHP7系対応)

後者のチュートリアルに従ってやっていれば問題なくPHP7系のHomestead環境が整いました。

前者はHomesteadコマンドベースになっていて、後者はVagrantコマンドがベースになっているので、やり方の違いに若干戸惑いましたが・・・。

laravelの勉強をしていて、環境構築用にlaravel homesteadを導入してみたのですが、かなり苦戦したのでメモを残しておきます。

laravel homesteadとは

laravelをローカル環境に導入するときに、環境構築の手間を省くために公式に準備された仮想環境構築ツールです。

laravel homesteadの仮想環境の構築には、Virtual Box+Vagrantを利用するのですが、Vagrantの設定をlaravelの仮想環境に特化するように準備してくれるツールです。

公式サイトには、laravel homesteadを使うことでローカルへの環境構築が楽ちんになると書いてあったのですが、思わずはまってしまったのでメモとして残しておきます。

導入の手順

１・Virtual BoxとVagrantをダウンロードします。

homesteadは基本Virtual BoxとVagrantを使うだけなので、何はともあれこの２つをインストールします。

２・Composerが導入されていない場合はComposerを導入します

Composerは、phpのパッケージ管理ツールです。
Composerは、Laravelを導入するのにあたってほぼ必須となるツールです。
入ってない場合は入れておきます。

３・Homsteadの設定を行います

公式サイトの手順に従います

HomesteadのCLIツールのインストール

composer global require “laravel/homestead=~2.0”

bashプロファイル ~/.bash_profileを編集してコマンド実行パスを追加

export PATH=$PATH:~/.composer/vendor/bin

ymlファイル（Vagrant用の設定ファイル）の初期化

homestead init

SSHキーの設定

ssh-keygen -t rsa -C “[email protected]”

homesteadの仮想環境生成

homestead up

それで、以下のエラーが出ました。

Bringing machine ‘default’ up with ‘virtualbox’ provider…
There are errors in the configuration of this machine. Please fix
the following errors and try again:

vm:
* The host path of the shared folder is missing: ~/Code

これは、要するに、ホームディレクトリに Codeというフォルダがないということです。

cd ~
mkdir ./Code

これで再度

homestead up

これでエラーが解消され、問題が解決しました

これで、仮想環境が作成されたのでSSHでアクセスしてみます

homestead ssh

無事仮想環境にログインできました。

メインマシンのhostsファイルに、以下を追加します。

192.168.10.10 homestead.app

公式サイトによると、この時点でサイト(homestead.app)へアクセスできるはずなのですが

http://homestead.app

上記URLへアクセスすると、エラー。

No input file specified

これは、ファイルが存在していないということらしい。

調べて見ると、 ymlファイルに設定されているのが以下の通りなのですが

sites:
– map: homestead.app
to: /home/vagrant/Code/Laravel/public

これは、上記のドメインが、/home/vagrant/Code/Laravel/publicに紐付けられているということなのですが、仮想マシンにログインして確認したところ、「/home/vagrant/Code/」以下に、Laravelのディレクトリが存在していない。

これには相当ハマってしまい、調べても原因がよく分かりませんでした。

とりあえず、メインマシンのcomposerのバージョンが少し古かったみたいなので、メインマシンのcomposerのバージョンを最新に更新。

homestead destroy

これで一旦仮想環境を削除して

homestead provision

これで再度作り直してみます。

これで再度サイトへアクセスすると、表示されました。

しかし、今度は別のエラーが・・・

autoload.phpがないとかそういうことらしく、調べれてみると、必要なファイルが存在してないのがあるようなので、これはComposerをアップデートしたらいいということなので、アップデートしてみます。

composer update

すると、途中でエラー。

proc_open(): fork failed – Cannot allocate memory in phar:///usr/local/bin/composer/vendor/symfony/console/Application.php

メモリが足りていないというエラーです。

php.iniを編集して、memory_limitを編集してみるも、駄目。
調べると、swap メモリの設定を追加したらいけるということ。

仮想マシン内で、以下のコマンドをスーパーユーザ権限で実行

sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
sudo /sbin/mkswap /var/swap.1
sudo /sbin/swapon /var/swap.1

これで再度Composerをアップデートしたところ、通りました・・・！

Laravelの初期画面。ついに起動！ここまで長かった・・・

雑感

簡単に仮想環境が構築できるといいつつ、やってみると何箇所かはまるポイントがあって大変でした。

ぶっちゃけ、ローカルの仮想環境って、homesteadなんか使わなくてもMAMPやXAMPで十分じゃね・・・という気もしますが、何故Vagrant+Virtual Boxを使うのが良いのかよくわかりません。

また、仮想環境にデフォルトの設定で2GBのメモリが割り当てられるようなので、仮想環境にメインマシンのメモリも圧迫されます。

とりあえず、こういうものもあるということで、引き続き色々使って試してみようとは思います。

その後

Homestead環境のセットアップが終わってからですが、まずは、Laravelのデフォルトのサイトが表示されています。

その後どうやってサイトを作り込んでいくかですが、メインマシンの

~/Code

フォルダが仮想マシンのエイリアスになっているようなので、そこを作業フォルダにしていけばその後の仮想環境の作業をメインマシンで進めていけます。

作ったサイトはhostsファイルにドメインと仮想マシンのIPアドレスを紐付けることで、仮想マシンでの表示が確認できます。

Homesteadの仮想環境はメモリを圧迫するので、使い終わったら、コマンドラインで

homestead halt

で停止することができ

homestead up

で再度起動できます。

homestead環境の削除

vagrant box remove laravel/homestead –all

ymlファイルの更新後の仮想環境への反映

vagrant reload –provision

Laravelのバージョンアップ

公式のLaravel5.7のHomestead導入ガイドに従ってHomestead環境をセットアップしたのに、デフォルトのLaravelのバージョンが5.4で最新の5.7ではなかった。

5.4から5.7へのバージョンアップは、仮想環境のLaravelフォルダまで移動して、個別に行った。

手順としては、Laravelフォルダにある composer.jsonファイルを編集して、設定内容の変更を行った後に、

composer update

で適用される。
（このあたりはググったら色々でてくるので詳細は割愛）

laravelで、homesteadを導入時に、以下のエラーに遭遇しました

コマンド

homestead up

を実行

それで、以下のエラーが出ました。

Bringing machine ‘default’ up with ‘virtualbox’ provider…
There are errors in the configuration of this machine. Please fix
the following errors and try again:

vm:
* The host path of the shared folder is missing: ~/Code

これは、要するに、ホームディレクトリに Codeというフォルダがないということです。

cd ~
mkdir ./Code

これで再度

homestead up

これでエラーが解消され、問題が解決しました

サーバでいろいろ設定をしていると、パスを通すという言葉が、ときどきあります。

この、パスを通すというのがどういう意味についてなのですが、サーバやコンピュータでコマンドを実行する際に、そのコマンドの実行ファイルがどこにあるかということです。

ユーザはコマンドラインで様々なコマンドを実行していますが、それは、結局コンピュータやそのサーバの中で、そのコマンドに対応する実行ファイルがどこかにあるのです。

linux系のサーバやコンピュータであれば

/bin/
/sbin/

といったディレクトリ以下に、それらの実行ファイルがあります。

そのディレクトリを開いてみると、多くの実行ファイルがあり、慣れ親しんだ ls や cd といった実行ファイルも存在しています。

これは、linux系であれば、/bin/や/sbin/は、はじめから定義されているのでその場所はわかり、また、bash_profileでは

/usr/bin/
/usr/sbin/

といった場所にははじめからパスが通してあります。

コンピュータでコマンドを実行した際に、コンピュータは、そのパスが通っている場所以下の、コマンドに該当する実行ファイルを探しているわけです。

もしコンピュータ全体から実行ファイルを探そうとすると、膨大な時間がかかっているため、パスを通すことで実行ファイルの場所を絞っているわけです。

特定のソフトウェアをインストールした場合、そのソフトに対応するコマンドが利用できるようになる場合がありますが、ソフトをインストールしただけでは、コマンドのパスが通っていないため、実行ができないことがあります。

これができるようにするためにパスを通す必要があるのです。

パスを追加することで、パスが通された以下にあるディレクトリに実行ファイルがないかどうかを検索対象に追加されます。

パスの変更の仕方

.bash_profileを編集します。

.bash_profileは、ホームディレクトリにあります。
ない場合は作成するとよいです。

編集後、

source ~/.bash_profile

で反映されます。