CakePHP3では、デバッグでログ出力するのに

use Cake\Log\Log;

LOG::debug(“出力したい内容”);

を使うことで、デバッグログファイルにログを出力することができます。

しかし、これを自分の開発環境で使ってみたところ、ログが出力されない現象が発生することがあり、困っていました。

調べたところ、出力できるようになったのですが、原因としては、

/config/app.php　内の

'debug' => [
            'className' => 'Cake\Log\Engine\FileLog',
            'path' => LOGS,
            'file' => date("Ymd").'_debug',
            'url' => env('LOG_DEBUG_URL', null),
            'scopes' => false,
            'levels' => ['notice', 'info', 'debug'],
        ],

で、scopes = true　になっていたのが原因でした。

これを scopes = false にすることで、ログが出力されるようになりました。

ぱっと見では、trueにすることで出力されるんではないかと思いますが、trueだと逆に出力されないということですね。

Laravel7をインストールするのに、エラーが出たりして微妙に苦労したのでメモ。

環境

CentOS

php7

以前別のプロジェクトで同じサーバにLaravelを入れていた(5系)

まずは、手順に従って、Laravelをインストールしようとした

composer global require laravel/installer

するとエラーが

SHA384 is not supported by your openssl extension, could not verify the phar file integrity

調べてみると、composerのバージョンが古いためにLaravel7系の場合は合わないらしい。

composerの最新のバージョンは1系、Laravelは7系。

これが駄目ってことか。

というわけで、composerのバージョンを最新版の2系にバージョンアップ。

この記事を参考にcomposerの再インストールを実施しました。

composerのダウンロードとインストールは、公式の記事を参考にしたらいいと思います。

結果、composerのバージョンは最新の2系になりました。

composer -V

Composer version 2.0.9

そして、再度Laravelのインストールコマンドを実行

すると、今度はまた別のエラーが

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

エラーの内容は、最初見てよくわからなかったのですが、最終的に分かったこととしては、今回実行しようとしている

composer global require laravel/installer

というコマンドは、Laravelのインストーラーを作成するコマンドであって、それが同じサーバにすでに作成していたLaravelのプロジェクト（5系）の作成時にすでに設置していたLaravelのインストーラーがあり、その設定ファイルのcomposer.jsonとcomposer.lockと内容が競合しているというような意味だったみたいです。

上記の過去プロジェクトはもうすでに更新してないサイトだったのもあり、過去に作成したインストーラーを、一旦リネーム(削除するのは何か怖かったのでリネーム）することで、上手く設置することができました。

Laravelのインストーラーは、サーバの設定により異なりますが、自分の環境の場合は

/home/.config/

以下がそうだった（それ以下にLaravelのインストーラーが入っていた）ので、上記フォルダをリネーム後にサイド実行することで、上記ディレクトリが新しく作成され、そこにLarvel7に必要だったcomposer.json、composer.lockも新しく作られました。

そして、Laravelのインストールを実行

laravel new プロジェクト名

しかし、以下のエラーが・・・

bash: laravel: コマンドが見つかりません

調べてみると、Laravelのインストーラーへのパスが通ってないみたいで、ホームディレクトリの.bash_profileにパスを設定しないといけないらしい。

しかし、確認するとすでにパスの記述がある・・・。だとするとなぜ？

source .bash_profile

をすることで読み込まれたみたいで、無事Laravelのプロジェクトを作成することができました。

Laravelのドキュメントルートにアクセスするとエラーが

The stream or file “/storage/logs/laravel.log” could not be opened in append mode: failed to open stream: Permission denied

調べるとアクセス権がないとかうことみたいで、

chmod -R 777 storage

で解決。755でいけるとか書いてたけどどうにもならず、777にしたらいけました。

Cakephp3のValidationとBuildRulesについての記事です。

Cakephp3ではフォームのバリデーション（エラーチェック）はモデルで行われますが、エラーチェックの方法に、validationと、BuildRulesの２パターンがあります。

この違いについて解説したいと思います。

まずvalidationについてですが、基本的にmodelのvalidationDefaultメソッドの定義していきます。一般的なエラーチェックはこちらに定義していくパターンが多いと思います。

BuildRulesは、validationメソッドとは別に定義していきます。

通常のvalidationとは記述方法が微妙に違うので、そこは公式サイトを見て確認してください。

それで、この２つの何が違うのかについてですが、バリデーションが実行されるタイミングです。

通常のvalidationは、Controller側でnewEntityやpatchEntityを実行するタイミングで行われます。

これに対して、BuildRulesは、モデルからsaveメソッドを実行するタイミングで行われます。

この２つのどう使い分けるかというと微妙なところがあって私も完全には理解してないのですが、例えば日付を比較するようなエラーチェックを入れる場合、Build Rulesのほうに追加すると便利です。

なぜなら、日付を比較するようなエラーチェックの場合、そもそも入力値が日付でなかったりする場合、エラーチェックの処理の途中で日付でないのでエラーになってしまったりして、データが「日付である」という前提を担保することが難しいわけです。

これを、Validationのほうに日付のエラーチェックを定義しておいて、日付データの比較はBuiled Rulesのほうに定義しておけば、日付でない場合はpatchEntityのタイミングでエラーになってsave時のBuild Rulesまで処理が進まないので、内部的な処理で日付がどうこうみたいな処理を書く必要がなくなります。

他にもあるかもしれませんが、私の理解ではそんなところです。

関わっていた案件で、PostgresSQLのTriggerを使って、Insertする特定のカラム値を、TriggerのInsert Beforeを使って計算して挿入するというケースがありました。

Qiitaの以下の記事がわかりやすかったです。

PostgreSQLでトリガを作成し、同一テーブル内に値を追加する

https://qiita.com/grassfield/items/60fad9c1d4a8d205bff3

CREATE OR REPLACE FUNCTION culc_totalworktime() RETURNS trigger AS $BODY$
BEGIN
  NEW.勤務時間 := NEW.終了時刻-NEW.開始時刻-NEW.休憩時間; -- 解説
  RETURN NEW;
END;
$BODY$ LANGUAGE plpgsql VOLATILE COST 100;
ALTER FUNCTION culc_totalworktime() OWNER TO postgres;

上記のようなかんじで値を返すトリガを作成して

CREATE TRIGGER totalworktime_trg
BEFORE INSERT OR UPDATE ON 勤務実績
FOR EACH ROW EXECUTE PROCEDURE culc_totalworktime();

上記のようにINSERT BEFOREでトリガを呼び出してやれば、カラムに計算された値が挿入されました。

kusanagiのWordPress実行環境で、all-in-one wp migrationを使ってサイトのインポートをしていたところ、100%まで進んだところで止まってしまい、それ以上進まなくなるという状況になってしまいました。

原因について調べてみたのですが、まずはサーバのエラーログを見てみたところ、以下のようなエラーが出ていました

client intended to send too large body: 65213411 bytes, client

これは、postしたデータサイズが設定を超えていたのではじかれているという内容みたいです。

サーバはnginxを使っていたので、以下のように設定を変更しました

該当のサーバのnginxの設定ファイル〇〇.confを編集します

client_max_body_size 16M;

調べたところ、デフォルトでは自分が使っているサーバでは上記の設定だったので、ひっかかってエラーになっていたみたいです。

client_max_body_size 100M;

上記のように上限を変更し、nginxを再起動することで無事インポートできるようになりました。

CakePHPのFlashComponentについての解説です。

公式サイトでは以下のページに解説があります。

フラッシュ

公式サイトの解説が分かりにくいので、自分流の解釈ですが、FlashComponentは、特定のメッセージをサイトで表示するのに使います。

Sessionに表示するデータを保存して、画面遷移後に表示することが可能です。

普通にエラーメッセージを表示する場合と比較すると、表示するメッセージを保存して、画面遷移後の表示に使う事ができる特徴があります。

使い方

Controllerで以下の定義

public function initialize() {

parent::initialize();
$this->loadComponent(‘Flash’); // Include the FlashComponent

}

表示したいデータを以下のように使う。

//成功した場合出力。リダイレクト後のページで表示される

successやerrorなどのテンプレートは、/sec/Template/Element/Flash以下にあるので追加や編集も可能。

$this->Flash->success(__(‘Your article has been saved.’));

$this->Flash->error(__(‘Unable to add your article.’));

テンプレートの以下の記述の場所にFlashメッセージが表示される

<?= $this->Flash->render() ?>

CakePHPのLoadComponentについての解説です。

LoadComponentメソッドは、Controller内で実行することができ、あらかじめCakePHPの準備されているComponentを呼び出すことができます。

Componentとは、機能のようなもので、メソッドのかたまりのようなものです。

一般的なプログラムでのライブラリ読み込みのようなものと考えればよいでしょう。

Componentをコントローラで使用する場合は、initializeメソッドの中でLoadComponentを使って該当のComponentを呼び出します。

読み込むことができるComponentには以下の種類があるので、詳細は以下のそれぞれの記事を参照とのことです。

• AuthComponent (4.0.0で撤廃。プラグインに置き換えられる。)
• クッキー (3.5.0で撤廃。ServerRequestで利用できる)
• クロスサイトリクエストフォージェリ (3.5.0で撤廃。ミドルウェアに置き換えられる)
• フラッシュ
• セキュリティ (FormHelperを使う必要あり)
• ページネーション
• リクエストハンドリング

CakePHPのaddBehaviorメソッドについての解説です。

CakePHPのチュートリアルを進めていると、Tableクラスで以下のような記述があります。

class ArticlesTable extends Table
{
    public function initialize(array $config)
    {
        $this->addBehavior('Timestamp');
    }
}

上記の意味がわからなかったのですが、調べてみると以下のような記述がありました。

デフォルトの設定は以下のようになっています:

• 新しく Entity を保存するとき、 created と modified に現在の日時を設定します。
• Entity を更新したとき、 modified に現在の日時を設定します。

上記のように宣言することで、対象のテーブルの項目「created」と「modified」が、データが作成されたときにタイムスタンプが更新されるようになる他、データが更新されたときにmodifiedの項目が自動で更新されるようになるということです。

AWSの試用期間中で無料期間中にいろいろと試しているのですが、インスタンスを使用後に削除したのに、請求で料金がチャージされているのが謎でした。

ダッシュボードで利用状況を確認しても、利用しているEC2インスタンスは存在していないのに、EC2インスタンスに対して料金がチャージされていっているのです。

原因について調べていたところ、原因が判明しました。

AWSのダッシュボードの右上で、AWSのロケーション(米国東部とかいろいろある)を変更できますが、現在のロケーションでなく、別のロケーションに存在していました。

そのため、現在のダッシュボードに利用しているリソースが存在していないけど料金がチャージされているという場合、ロケーションを１つずつ変更しつつチェックして確認することで見つかる場合もあると思います。

Vue.jsで、Vueオブジェクトのデータをループさせるときに、v-forディレクティブを使用します。

<li :v-for=”変数 in Vueオブジェクトのデータ名”>{{ 変数.データ名 }}</li>

上記のような感じで使いますが、いろいろなサイトでコードのサンプルを見ていて、上記のような書き方だけのときもあれば

<li :v-for=”変数 in Vueオブジェクトのデータ名” :key=”変数.id”>{{ 変数.データ名 }}</li>

のように、:keyがついている場合とついていない場合があります。

何のために :key がついているのか調べてみたのですが、Vueの機能でDOMを書き換えた時に、keyを指定していないと、順番が変わってしまうことがあるそうで、つけておくことで並び順を保持できるそうです。

ajaxについての勉強メモです。

ajaxとは

ajaxとは、javascritを使って、ページを非同期に更新する仕組みのことです。

とはいえ、ajaxという言葉を使わなくても、javascriptは、普通にスクリプトを実行することで、イベント発生時（マウスオーバーやクリック時など）、ページの内容を書き換えることは可能です。

では、ajaxとはその通常のjavascriptの仕組みと何が違うのでしょうか。

それは、ウェブページから、動的に現在のページでない他のページからのリソースを要求し、その結果をページに反映できるという点です。

たとえば特定の要素をマウスでクリックしたときに、ajaxの仕組みを使って、phpファイルを実行し、その帰ってきた結果を解析してページ内に反映させることができます。

この仕組みを実現するためにjavascirptに実装されているAPIの機能がajaxです。

そのことを、例えばフォームをサブミットしたりページをリロードしたりせずに実行できる仕組みと考えればよいでしょう。

javascriptのソースコードを見ていると、よく以下のような記述があります。

$(function(){})

これを、javascript初心者の人が見ると

???

となりますが、この意味について解説したいと思います。

まず、javascriptでは、関数をオブジェクトとして定義することができ、そのまま関数名を定義せずに変数に代入してオブジェクトにすることができる。

この事は知っている人が多いと思います。

また、javascriptは、即時関数という機能があって、定義した関数をその場ですぐに実行することができます。

これは、

(function() { 実行内容 } ())

このような書き方をします。

上記のような書き方をすることで、実行内容をその場で実行することができるわけです。

しかし、 タイトルにある

$(function(){ 実行内容 })

は、上記の記述とも微妙に違います。

これは、jQueryを使用している場合の記述です。

ページのDOMツリーの読み込みが完了した後に、実行内容を実行するということで、javascirptの通常の即時関数と似ていますが、JQuery使用時固有のものです。

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