LaravelのDBのバックアップを取得するのに、パッケージ「Laravel Backup」が便利みたいなので、試してみました。
Introduction | laravel-backup | Spatie

ちなみに今回は、Windows 10、PHP 7.3、Laravel 5.8、MySQLの環境下で試しました。

Laravel Backupをインストール

早速ですが、composerを使用してパッケージをインストールします。
ちなみに「Laravel Backup」の現時点での最新バージョン6をインストールするためには、PHP 7.2以上、Laravel 5.8以上が必要となります。

> composer require spatie/laravel-backup

インストールが成功したら、次に以下のコマンドで設定ファイルを生成します。

> php artisan vendor:publish --provider="Spatie\Backup\BackupServiceProvider"

設定ファイル「…/config/backup.php」が作成されました。
設定ファイルを開き、通知メールの送信先を設定します。

'mail' => [
	'to' => （通知メールの送信先）,

また、APP_NAMEが日本語の場合、バックアップ出力先のフォルダ名が日本語になってしまうので、設定ファイルを調整します。

'backup' => [
//	'name' => env('APP_NAME', 'laravel-backup'),
	'name' => 'laravel-backup',

Laravelをバージョン5.8から6.xへアップグレードします。

Laravel 5.8はPHP 7.1.3以上が必要ですが、昨今、PHP 7.1も非奨励となっています。
そこで、セキュリティ面も考慮して、PHP 7.2以上が動作条件となっているLSTのLaravel 6.xへアップグレードしようと思います。

今回は、基本的に公式マニュアルに沿って作業します。
アップグレードガイド 6.x Laravel

まず、composer.jsonをテキストで開きます。

	"require": {
		"php": "^7.1.3",
		"laravel/framework": "5.8.*",

こちらを、以下のように書き換えます。

	"require": {
		"php": "^7.2",
		"laravel/framework": "^6.0",

コマンドラインからcomposerでアップデートを実行します。

> composer update

しばらく待てば、アップグレード完了です。
あっさりですね。。あっさり過ぎる。。本当に大丈夫？w

いろいろなパッケージを追加で組み込んでいるケースでは、アップグレードが途中で停止して、composer.jsonを見直すといったことを繰り返すこともあるようですが、私の場合は一切なかったです。
とりあえずは問題なさそうですが、時間をかけてじっくり細かいところをチェックしたいと思います。

フォームタグ「<input type=”file”>」で画像を選択したタイミングで、JavaScriptで画像のプレビュを表示する方法です。

これまで、フォームで選択した画像ファイルは、一度サーバにアップした後でないと、ブラウザ上でプレビュできないものだと考えておりました。
実際に任意のシステムでも、一度アップした画像を一時画像扱いでサーバに保存し、確認画面でプレビュして、戻るイベントで画像を削除、決定イベントでDBに本登録するといったような、めんどくさいロジックを組み立てていました。

それがJavaScriptだけで可能なことを最近知りました。。
セキュリティ的にどうとかの評価はひとまず置いておいて、その方法についてのメモです。

まず、ファイルタイプのフォームと画像プレビュ用のimgタグを用意します。

<input id="image" type="file" accept="image/*">
<img id="preview">

Laravelではメール処理に便利なMailableクラスが用意されており、この機能を利用してメールを送信します。

Mailableクラスを用意する

例えばSampleMailクラスを作成する場合、以下のコマンドを実行します。

> php artisan make:mail SampleMail

すると、以下の内容でファイル「…/app/Mail/SampleMail.php」が生成されます。

namespace App\Mail;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Mail\Mailable;
use Illuminate\Queue\SerializesModels;

class SampleMail extends Mailable
{
	use Queueable, SerializesModels;

	public function __construct()
	{
	}

	public function build()
	{
		return $this->view('view.name');
	}
}

LaravelでGate機能を使ってユーザ情報に権限情報を追加します。

ユーザ毎に管理者権限などを割り振りたい場合、Laravelに用意されているGate機能を利用すると便利です。
具体的にはユーザ毎に任意の数字を割り振り、その数字により権限を割り振ることにしたいのですが、デフォルトのuserテーブルにはそのカラムが存在しません。そこでカラムを追加するところから権限機能追加の手順について確認していきます。

ちなみに今回の環境はLaravel 5.8で、Auth機能は追加済みを想定しています。
また、追加したカラムの持つ数字の意味として、以下の権限を付与するものとします。
1 : 閲覧者
50 : 編集者
100 : 管理者

システム設計として、数字を連番にしてしまうと、いざ間に新しい権限を追加しようとしたときに困るので、数字の間に余裕を持たせるのが一般的です。

userテーブルに権限情報を追加する

userテーブルに権限情報カラム「role」を追加します。カラム追加にはmigrateファイルを作成します。

> php artisan make:migration add_column_to_users_table

Laravelで通知メールを送信するしくみとしてNotificationクラスがありますが、それでテキスト（平文）メールを送る方法です。

Notificationは非常に便利で、通知メールを送るための各機能が用意されています。
但し、基本的に送信するメールタイプはHTMLメールです。正しくは「HTMLメールが受け取れない環境の場合はテキストメールを送る」といった仕様のようでうすが、あまり理解できておりません。。
個人的には通知メールは確実に届けたいので、HTMLメールではなくテキストメールのみを送信するほうが良いと考えています。HTMLメールが崩れて読めない、メッセージが伝わらないでは困りますからね。

では、実際にテキストメールを送信する方法です。
例えば、新規Notificationクラス「SampleNotification」を作成する場合、artisanコマンドで作成することができます。

> php artisan make:notification SampleNotification 

コマンドを実行すると、ファイル「…/app/Notifications/SampleNotification.php」が生成されます。デフォルトの内容は以下です。（コメントなど要点以外は省略しています）

namespace App\Notifications;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Notifications\Messages\MailMessage;
use Illuminate\Notifications\Notification;

class SampleNotification extends Notification
{
	use Queueable;

	public function via($notifiable)
	{
		return ['mail'];
	}

	public function toMail($notifiable)
	{
		return (new MailMessage)
			->line('The introduction to the notification.')
			->action('Notification Action', url('/'))
			->line('Thank you for using our application!');
	}
}

Laravelでアプリ構築中に、画像をリサイズしたり、解像度を調整したりなど、画像加工処理を実装したかったのですが、Laravel本体にそのような機能はないようです。
少し調べてみたのですが、Laravelでは「Intervention Image」というパッケージとの相性がよさそうです。
Intervention Image – Introduction

今回はLaravel 5.8にパッケージ「Intervention Image」を組み込んでみます。

パッケージ「Intervention Image」をインストール

それでは早速パッケージ「Intervention Image」をインストールします。Laravelなので以下のようにcomposerで簡単にインストールできます。

> composer require intervention/image

パッケージのダウンロードに成功したら、以下のようにサービスプロバイダの設定「config/app.php」に追加してLaravelに組み込みます。

	'providers' => [
...
		Intervention\Image\ImageServiceProvider::class,
	],
...
	'aliases' => [
...
		'InterventionImage' => Intervention\Image\Facades\Image::class,
	],

最後に設定のキャッシュをクリアします。

> php artisan config:clear

例えば任意のフォルダ「/project/」に、Laravelで新規でプロジェクト作成すると、以下のようなフォルダが展開されます。

app
bootstrap
config
database
public
resouces
routes
...（略）

このうちフォルダ「public」が公開フォルダとなるので、ドキュメントルートに設定すればよいのですが、サーバ環境の都合上、別のフォルダを指定したい場合があります。
フレームワークであれば、1か所設定すれば解決しそうなお話ですが、Laravelではそうはいきません。

それでは、Laravel 5.8でデフォルトの公開フォルダ「/project/public/」を「/public_html/」に変更すると仮定して、設定手順を追ってみます。

ドキュメントルートの「index.php」を編集する

まず、ドキュメントルートに設置するインデックスファイル「/project/public/index.php」を「/publick_html/index.php」に移動して編集します。

...
require __DIR__.'/../vendor/autoload.php';
...
$app = require_once __DIR__.'/../bootstrap/app.php';
...

上の記述部分を、以下のようにLaravel本体へのパスに調整します。

...
require __DIR__.'/../../project/vendor/autoload.php';
...
$app = require_once __DIR__.'/../../project/bootstrap/app.php';
...

一見、この対応だけでLaravelが問題なく動作しているように見えます。
但し、Laravelのコアなプログラムで「public」はハードコーディングされており、このままではストレージやファイルへのアクセスなど、公開フォルダへのアクセスが伴う処理をしようとするとズレが発生してしまいます。
例えばヘルパ関数「public_path()」を使用しても正しいパスは取得できません。

そこで、以下の対応も必要となります。

Laravelのフォームリクエストを使ってバリデーション処理を管理します。

ある日、Laravel開発中にコントローラ内でフォームバリデーションの処理を記述していました。
「コントローラの処理が増えてきたなぁ」や「この処理、他のリクエストでも使いまわすよなぁ」と考えていました。
これらの問題を解決する方法「フォームリクエスト」があるんですね。

フォームリクエストは一連のバリデーション処理を、外部クラスにまとめることができます。
フォームリクエストを利用することで、任意のリクエストで処理を呼び出すことができますし、コントローラ内のコードもスッキリさせることができます。

フォームリクエスト作成

フォームリクエストを作成します。フォームリクエストは以下のようにartisanコマンドで作成できます。

> php artisan make:request SampleRequest

コマンドを実行すると「/app/Http/Requests/SampleRequest.php」が作成されます。内容は以下の通りです。

namespace App\Http\Requests;
use Illuminate\Foundation\Http\FormRequest;
class SampleRequest extends FormRequest
{
	public function authorize()
	{
		return false;
	}

	public function rules()
	{
		return [
		];
	}
}

最近、laravelやCakePHPなどcomposerを利用したPHPプロジェクトが増えてきました。
そこで、「composer.json」と「composer.lock」の違い、installやupdateの違いなど、運用方法についてのメモです。
間違っていたらご指摘ください。。

新規プロジェクト作成

新規でプロジェクトを作成する場合、ファイル「composer.json」を作成して必要なライブラリとバージョン情報を記述します。（今回「composer.json」の記述方法については割愛します）
以下のコマンドを実行すると、jsonファイルの情報を元にライブラリをインストールします。

composer install

この時、新規インストールになるのでファイル「composer.lock」が生成されます。「composer.lock」にはインストールされたライブラリ情報が出力されます。

両者の違いについて「composer.json」にはバージョンの範囲を指定することができます。指定範囲の中で最新のバージョンがインストールされます。
一方で「composer.lock」には、その時にインストールしたバージョンが出力されます。

プロジェクトインストール

例えば、先ほど作成したプロジェクトと同一のライブラリ環境を用意したい場合、先ほど生成された「composer.lock」をインストールディレクトリにコピーして、以下のコマンドを実行します。

composer install

この時「composer.json」は無視され、「composer.lock」の内容を元にライブラリがインストールされます。「composer.lock」は更新されません。

つまり「composer.lock」を利用してインストールを実行することで、別の開発者や環境で同じライブラリ環境を実現することができます。