GitHub の「master」と「main」
2020年末頃から GitHub のデフォルトブランチが「master」から「main」に変更になりました。GitHub をはじめた人がこの変更を知らない人が手順を間違えて「master」に push して放置していることがあります。
手動で master に push してしまうのが原因？
これは GitHub でリポジトリ作成すると「main」ブランチがデフォルトになったにもかからわず、手動コマンドで「master」に push してしまうことが多いようです。
% git push origin master
「main」と「master」の食い違いは最終的に、ブランチを移動する作業が必要ですが、ここでは割愛します。
master を checkout する
今回はデフォルトが「main」ブランチで、「master」ブランチで管理されたソースを pull/checkout してみます。
Git clone する
まずリポジトリをクローンして、プロジェクトフォルダに移動します。
% git clone https://github.com/アカウント名/リポジトリ名.git
% cd プロジェクト名
リモートブランチ（master）をローカルブランチ（master）に checkout
リモートブランチは「master」になっているので、ローカルブランチも「master」にあわせて checkout します。 -b は新しくブランチを作成してくれるオプションです。
% git checkout -b master origin/master
Branch 'master' set up to track remote branch 'master' from 'origin'.
Switched to a new branch 'master'
これでリモートブランチ「master」からソースもダウンロードされます。
ローカルブランチや origin の確認
ローカルブランチが「master」ブランチに変わったことを確認します。
% git branch
main
* master
また origin を確認するとメインが main でその他 master ブランチも追跡していることがわかります。
% git remote show origin
* remote origin
Fetch URL: https://github.com/アカウント名/リポジトリ名.git
Push URL: https://github.com/アカウント名/リポジトリ名.git
HEAD branch: main
Remote branches:
main tracked
master tracked
Local branches configured for 'git pull':
main merges with remote main
master merges with remote master
Local refs configured for 'git push':
main pushes to main (up to date)
master pushes to master (up to date)
Laravel では Auth や Jetstream で認証機能を実装できますが、マルチログインは結構面倒です。
例えば未認証のリダイレクト処理はミドルウェアの Authenticate->redirectTo() で処理していますが、シングルログイン（user）の記述です。
Authenticate のデフォルト設定
app/Http/Middleware/Authenticate.php
protected function redirectTo($request)
{
if (!$request->expectsJson()) {
return route('login');
}
}
ここで user、admin 2つのマルチドメイン認証で「/user/xxx」「/admin/xxx」にアクセスしたとき、上記のルーティングでは「/login」にリダイレクトされてしまいます。
また「/login」でなく「/user/login」「/admin/login」でルーティングすると当然ながら Routing エラーになります。
Symfony\Component\Routing\Exception\RouteNotFoundException
Route [login] not defined.
Authenticate の修正
2つの認証「user」「admin」が未承認時、「/user/login」「/admin/login」 にリダイレクトするよう修正します。今回は直接「user」「admin」と直接設定しましたが、ループ処理は guard の設定と連携してもよいかと思います。
protected function redirectTo($request)
{
if (!$request->expectsJson()) {
foreach (['user', 'admin'] as $user) {
if ($request->routeIs("{$user}.*)) {
return route("{$user}.login");
}
}
}
}
また、認証処理を user、admin の各コントローラーのコンストラクタやサービスなどで認証する場合は、 Authenticate->redirectTo() は無効にする必要があります。
Redis インストール
brew コマンドで redis をインストールします。
$ brew update
$ brew install redis
brew で redis サーバを起動します。
$ brew services start redis
redis サーバが起動しているか確認します。
$ brew services list
Name Status User Plist
mysql started yoo /Users/yoo/Library/LaunchAgents/homebrew.mxcl.mysql.plist
php@7.4 started yoo /Users/yoo/Library/LaunchAgents/homebrew.mxcl.php@7.4.plist
postgresql@12 started yoo /Users/yoo/Library/LaunchAgents/homebrew.mxcl.postgresql@12.plist
redis started yoo /Users/yoo/Library/LaunchAgents/homebrew.mxcl.redis.plist
redis-cli の確認
Redis クライアントでログインし、Redis コマンドで操作してみます。
redis-cli ログイン
$ redis-cli
データ登録
127.0.0.1:6379> set mykey "hello"
OK
データ取得
127.0.0.1:6379> get mykey
127.0.0.1:6379> keys *
1) "mykey"
全データ取得
127.0.0.1:6379> keys *
(empty array)
データ削除
127.0.0.1:6379> del mykey
(integer) 1
ログアウト
127.0.0.1:6379> exit
phpredis のインストールと設定
macOS の PHP で Redis を利用するには、PECL で Redis をインストールと設定する必要があります。
$ pecl install redis
php.ini で redis.so を読み込む
php.ini ファイルをパスを確認します。 以下は /usr/local/etc/php/7.4/php.ini になっていますが、各環境で確認してください。
$ php -r "echo phpinfo();" | grep "php.ini"
Configuration File (php.ini) Path => /usr/local/etc/php/7.4
Loaded Configuration File => /usr/local/etc/php/7.4/php.ini
確認した php.ini を修正し redis.so を読み込むよう設定します。
extension="redis.so"
PHP 再起動
PHP を再起動します。以下は php@7.4 をインストールして有効にしている場合です。 （インストールしているパッケージにあわせてください）
$ brew services restart php@7.4
$ php -i | grep Redis
以前は、jQuery や JavaScript でスムーズスクロールをいろいろ実装していましたが、CSS3 で1行書くだけで対応可能です。
html{
scroll-behavior: smooth;
}
ただ 2021/02 時点で IE はもとより Safari に対応していないので、実際には JavaScript での記述も必要になります。
EC-CUBE4 で Gmail の smtp の設定方法は、.env の MAILER_URL に記述します。
前提として、Googleセキュリティでの2段階認証が必要になります。
- smtp: smtp.gmail.com
- port: 465
- encryption: ssl
- auth_mode: login
- username: Gmail アカウント（Gmail アドレス）
- password: Google セキュリティの2段階認証で作成したパスワード（Gmail アカウントのパスワードではありません）
EC-CUBE の.env
EC-CUBE4 から Swift Mailer を利用しますが、smtpプロトコルの URLをパラメータ方式で設定します。
MAILER_URL=smtp://smtp.gmail.com:465?encryption=ssl&auth_mode=login&username=xxxxx@gmail.com&password=xxxxxx
amazon-linux-extras とは
AWS EC2 の AMI（マシンイメージ） で Amazon Linux 2 を選択してサーバ構築すると amazon-linux-extras コマンドが利用できます。
amazon-linux-extras は Amazon Linux 用のパッケージツールで、主要なソフトウェアをまとめてインストールできます。
ただし、amazon-linux-extras パッケージに含まれないソフトウェアは別途インストールする必要があります。
amazon-linux-extras のコマンドは単純で、以下の4つのコマンドが用意されています。
- help：ヘルプ
- info：パッケージ詳細
- install：パッケージインストール
- list：パッケージ一覧
トピック一覧確認
amazon-linux-extras でトピック一覧（パッケージ情報）を確認できます。 amazon-linux-extras list でも同様の動作をします。
$ amazon-linux-extras
...
33 java-openjdk11 available [ =11 =stable ]
34 lynis available [ =stable ]
35 kernel-ng available [ =stable ]
36 BCC available [ =0.x =stable ]
37 mono available [ =5.x =stable ]
38 nginx1 available [ =stable ]
...
42 php7.4=latest enabled [ =stable ]
...
数字の次にの項目が amazon-linux-extras のトピック名（パッケージ名）です。実際にインストールする Linux のパッケージ名とは違うので注意が必要です。
available はインストール可能な状態、enabled は実際にインストールされた状態です。
パッケージの詳細を確認
また、amazon-linux-extras info でパッケージ内容を確認できます。例えば、php7.4 のパッケージを確認してみます。
$ amazon-linux-extras info php7.4
php7.4 recommends php-cli # yum install php-cli
php7.4 recommends php-pdo # yum install php-pdo
php7.4 recommends php-fpm # yum install php-fpm
php7.4 recommends php-json # yum install php-json
php7.4 recommends php-mysqlnd # yum install php-mysqlnd
Amazon Linux 2 の Linux のディストリビューションは RHEL7 / CentOS7 を採用しています。よって、実際のパッケージインストールコマンドは yum install が実行されます。
amazon-linux-extras でインストール
amazon-linux-extras install でパッケージを管理者権限でインストールします。
$ sudo amazon-linux-extras install トピック名
トピック名 php7.4 をインストールする例です。
$ sudo amazon-linux-extras install php7.4
パッケージを無効にする
ヘルプにはありませんが amazon-linux-extras disable でパッケージの動作を無効にすることもできます。
$ sudo amazon-linux-extras disable トピック名
実際にパッケージが削除されるわけでなく yum remove などで削除すると、パッケージ依存の問題が発生する可能性があるので注意が必要です。
amazon-linux-extras はよく利用するパッケージのインストールを少しだけ楽にしてくれるツールであることがわかりました。
UNIQUE（重複）を含むデータの更新で、FormRequest や Validate で単純に unique を設定してしまうと、自分自身を更新できません。
code がユニークの場合
以下は、FormRequest の rulde() で items.code を UNIQUE 制約している例です。
配列の場合
'code' => ['required', 'string', 'unique:items'],
パイプの場合
'code' => 'required|string|unique:items',
この設定だと SQL の WHERE で更新しようとしてしまいます。
WHERE code = 'xxxx';
id を除外して code をユニークにする
よって items テーブルのプライマリーキー items.id を除外して更新するのがよいでしょう。
配列の場合
'code' => ['required', 'string', Rule::unique('items')->ignore($this->id)],
パイプの場合
'code' => "required|string|unique:items,code,{$this->id},id",
SQL の WHERE は以下のようになります。
WHERE code = 'xxxx' AND id <> 'xxxx'
Laravelでは、csrf フォーム画面で放置した場合、セッションが異なる Token エラーで Page Expired ページが表示されるようになっています。
App\Exceptions\Handler
Laravel ではエラーが発生すると、App\Exceptions\Handler が実行され最終的に render() でエラー画面を表示します。ExceptionHandler の詳細に関しては Laravel 8.x エラー処理 を参考にしてください。
ただ、フォーム有効期限切れで Page Expired ページを表示するのは、UI/UX 的に好ましくないのでリダイレクトしてみます。
App\Exceptions\Handler の render() で処理を振り分けてダイレクトしますが、今回は Tokenエラー TokenMismatchException クラスを判別します。
public function render($request, Throwable $exception)
{
$class = get_class($exception);
if ($class == 'Illuminate\Session\TokenMismatchException') {
return back()->withInput();
}
return parent::render($request, $exception);
}
フォームリクエストの場合は、 back()->withInput() で前の画面にリダイレクトするとよいでしょう。
またログインセッションの場合は Exception で振り分けず、Authenticate ミドルウェアなどで処理した方がわかりやすいでしょう。
ログのクリア
Laravel のログファイルをクリアします。
デフォルトでは storage/logs/laravel.log に記載されています。
echo で削除
ターミナルで Laravel プロジェクトのホームに移動し、echo で空にします。
% echo "" > storage/logs/laravel.log
truncate で削除
Mac の場合 truncate が入っていないので、Homebrew でインストールします。
% brew install truncate
truncate でログをクリアします。
% truncate -s 0 storage/logs/laravel.log
ログを日付ごとローテーション
ログの設定は、.env ファイルで簡単に設定できます。 デフォルトでは stack （複数のログチャンネルを一つのログチャンネルへ集結）になっています。
LOG_CHANNEL=daily
config/logging.php でも設定が可能で、デフォルトの設定は stack になっています。
'default' => env('LOG_CHANNEL', 'stack'),
利用可能なチャンネルドライバ
Laravel のログ設定に関しては公式を参考にしてください
- stack: 「マルチチャンネル」チャンネルを作成するためのラッパー機能
- single: シングルファイル／パスベースのロガーチャンネル（StreamHandler）
- daily: RotatingFileHandlerベースの毎日ファイルを切り替えるMonologドライバ
- slack: SlackWebhookHandlerベースのMonologドライバ
- syslog: SyslogHandlerベースのMonologドライバ
- errorlog: ErrorLogHandlerベースのMonologドライバ
- monolog サポートしているMonologハンドラをどれでも使用できる、Monologファクトリドライバ
- custom チャンネルを生成するため、指定したファクトリを呼び出すドライバ
ログの保存日数を設定
ログファイルが増えた時にローテートしますが、config/logging.php でログの保存日数を指定できます。
cron などでログローテートする場合、パーミッションも設定しておきます。
'daily' => [
'driver' => 'daily',
'path' => storage_path('logs/laravel.log'),
'level' => 'debug',
'days' => 7,
'permission' => 0666,
],
brew upgrade をしてしまい、PHP8.0 にアップグレードしてしまいました。
Homebrew でインストール済みの PHP バージョンを確認します。
% brew search php
==> Formulae
brew-php-switcher php-cs-fixer php@7.4 phpmyadmin ✔
php ✔ php@7.2 phplint phpstan
php-code-sniffer php@7.3 ✔ phpmd phpunit
PHP7.4 をインストールしていなかったのでインストールします。
% brew install php@7.4
パスを通す
PHP7.4 のパスを通します。 Zsh を利用しているので .zshrc にパスを記述します。（Bash 利用の人は .bashrc）
export PATH="/usr/local/opt/php@7.4/sbin:$PATH"
export PATH="/usr/local/opt/php@7.4/bin:$PATH"
brew services で PHP7.4 を有効にする
brew services で PHP7.4 を再起動して有効にします。
% brew services start php@7.4
ターミナルを再起動してバージョン確認
ターミナルを再起動して、PHP のバージョンを確認します。
% php -v
PHP 7.4.13 (cli) (built: Nov 30 2020 14:57:43) ( NTS )
