前置き

今回は、(var_dump()、var_export()、print_r())は表示形式が少し異なるだけなので、var_export()とdd()を主に使います。

準備

テスト用にController,bladeを作成する。

Controller

SampleController.php

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class SampleController extends Controller
{
    public function sample(Request $request)
    {
        return view('sample');
    }
}

blade

中身空のsample.blade.phpを作成する。

routes/web.php

Route::get('/sample', 'SampleController@sample')->name('sample');

準備が完了しました。これで/sampleへアクセスすると、真っ白な画面が表示されます。

普通にvar_dump()、dd()を使ってみる。

var_dump()

SampleControllerの中身を変更する

public function sample(Request $request)
{
    $string = 'あいうえお';
    var_dump($string);

    $int = 1;
    var_dump($int);

    $array = ['name' => '太郎'];
    var_dump($array);

    $time = new Carbon();
    var_dump($time);

    return view('sample');
}

/sampleへアクセスすると、変数の中身の情報が表示されています。

dd()

SampleControllerの中身を変更する

public function sample(Request $request)
{
    $string = 'あいうえお';
    var_dump($string);

    $int = 1;
    var_dump($int);

    $array = ['name' => '太郎'];
    dd($array);

    $time = new Carbon();
    var_dump($time);

    return view('sample');
}

/sampleへアクセスすると、変数の中身の情報が表示されています。
dd()は実行された直後に処理が終了します。変数の中身が、複雑な配列な際や、そこまでの処理が正常に動作しているかの確認時に重宝します。

(本題)Laravelでは、もっといい方法がある。

Laravelには、デバッグ用にdump serverというものが用意されている。こちらを使う。
コマンドをたたく。

コマンド

root@75b98e12b61d:/var/www# php artisan dump-server

Laravel Var Dump Server
=======================


 [OK] Server listening on tcp://127.0.0.1:9912


 // Quit the server with CONTROL-C.

dump-serverが起動できました。dump-serverは、出力内容をサーバー側で受け取り、表示することが可能になります。

このままの状態で、先ほどのdd()入りのコードを実行してみます。/sampleへアクセスします。

GET http://192.168.99.100/sample
--------------------------------

 ------------ -------------------------------------------
  date         Thu, 22 Aug 2019 14:14:59 +0000
  controller   "SampleController"
  source       SampleController.php on line 19
  file         app/Http/Controllers/SampleController.php
 ------------ -------------------------------------------

array:1 [
  "name" => "太郎"
]

コマンドプロンプトでddの内容が表示されます。それ以外にも、日時やコントローラーの情報などが記述されています。ddとvar_dumpをdump()メソッドを使うように変えます。

public function sample(Request $request)
{
    $string = 'あいうえお';
    dump($string);

    $int = 1;
    dump($int);

    $array = ['name' => '太郎'];
    dump($array);

    $time = new Carbon();
    dump($time);

    return view('sample');
}

/sampleへアクセスします。

GET http://192.168.99.100/sample
--------------------------------

 ------------ -------------------------------------------
  date         Thu, 22 Aug 2019 14:18:14 +0000
  controller   "SampleController"
  source       SampleController.php on line 13
  file         app/Http/Controllers/SampleController.php
 ------------ -------------------------------------------

"あいうえお"

 ------------ -------------------------------------------
  date         Thu, 22 Aug 2019 14:18:14 +0000
  controller   "SampleController"
  source       SampleController.php on line 16
  file         app/Http/Controllers/SampleController.php
 ------------ -------------------------------------------

1

 ------------ -------------------------------------------
  date         Thu, 22 Aug 2019 14:18:14 +0000
  controller   "SampleController"
  source       SampleController.php on line 19
  file         app/Http/Controllers/SampleController.php
 ------------ -------------------------------------------

array:1 [
  "name" => "太郎"
]

 ------------ -------------------------------------------
  date         Thu, 22 Aug 2019 14:18:14 +0000
  controller   "SampleController"
  source       SampleController.php on line 22
  file         app/Http/Controllers/SampleController.php
 ------------ -------------------------------------------

Carbon\Carbon @1566483494^ {#446
  date: 2019-08-22 14:18:14.934425 UTC (+00:00)
}

ddを使うと、そこまでの内容を表示し処理を終了してくれます。

まとめ

var_dump()を使うと、viewのほうで場合によって、エラーが出ることがあったりしたり、見にくかったりするけど、dump-serverを使うと、きれいにわかりやすく簡単に変数の値を見ることができた。

Laravelでコマンドを使っていろいろなことをするときに、「コマンドラインで」って言われることが多いのだけれども、具体的にWindowsのコマンドプロンプトなの？sshでつないでlinux上で動かすの？ってちょっとわからない時が多すぎる気がする。
いつかまた泣きそうになる気がするので、泣く前に見られる情報を書いておく。
尚、環境は以下の通り。
・ホストOS：Windows10
・開発環境：Homestead→Vagrant上でLinuxが起動
　　　　　　　　　　　 DBはMySQL

関係ないけど、VSCodeが使いやすくてびっくりだよ。

簡単に言っておくと

vagrantのコマンド→Windowsのコマンドプロンプトで実行
プロジェクトに対して実行するコマンド→linuxのコンソールで実行

各論

Vagrantの起動(Vagrant up）

さすがにこれはWindowsのコマンドプロンプトから起動ってわかるね。
Homesteadをインストールしたフォルダーに移動してからコマンド実行してください。

C:{Homesteadをインストールしたフォルダ}>vagrant up

Vagrantの終了(Vagrant halt）

当然起動と同じ、Windowsのコマンドプロンプトです。Homesteadをインストールしたフォルダに移動してコマンド実行してください。

C:{Homesteadをインストールしたフォルダ}>vagrant halt

Laravelプロジェクトの作成(composer)

これはVagrant上のlinuxから実行します。
Vagrant上のLinuxにアクセスするには、Vagrant sshでVagrant上のlinuxのコンソールを開きます。
Vagrant sshはWindows10のコマンドプロンプトから入れます。

C:{Homesteadをインストールしたフォルダ}>vagrant ssh

そうするとあら不思議、今までWindows10のコマンドプロンプトだった画面がlinuxのコンソール画面に早変わり！

linux上でコマンドを入力する場合は、vagrant sshでlinuxに接続してからコマンド実行する。

尚、laravelプロジェクトを作成するときはlinux上でプロジェクトを作成するディレクトリに移動してからコマンドを実行する。
Homesteadのデフォルトの開発ディレクトリはcodeなので、通常はcodeディレクトリに移動してからプロジェクトを作成する。

※note
Homesteadでは、VagrantでホストOS（ここではWindows10）とゲストOS(ここではlinux Ubuntu)で共有する共有フォルダーが設定される。
[設定される共有フォルダー]
home_vagrabt_code C:¥{ユーザーフォルダ}¥code
vagrant C:¥{ユーザーフォルダ}¥Homestead
これらのフォルダーはホストOSからもゲストOSからも参照・更新することができる。

【コマンド例】

vagrant@homestead:~$ cd code
vagrant@homestead:~code$ composer create-project laraavel/laravel testProject

artisanコマンド

linuxのコンソール画面で実行する。
プロジェクトのフォルダに移動してから実行する。実行した結果は移動したプロジェクト内に反映される。

【コマンド例】

vagrant@homestead:~/code/myProject$ php artisan make:test testCode

MySQLを立ち上げる

linuxコンソールで実行する。
MySQLコマンドはどのディレクトリにいても実行できます。

【コマンド例：homesteadのhomeディレクトリで実行】

vagrant@homestead:~$ mysql -u homestead -p

デフォルトの設定値では、ユーザーは「homestead」、パスワードは「secret」です。
変更する場合は、プロジェクト内の.envファイル内の「DB_USERNAME」、「DB_PASSWORD」の設定値を変更してみ。

概要

PHPのフレームワークLaravelは、開発者が意識していなくても内部で複数キャッシュしてくれています。
その心遣いは素晴らしく！時に、鬱陶しいのです！（笑）
開発時に使えるスクリプトをご紹介します。

環境

• Laravel 5.7

キャッシュクリアコマンド

以下の１コマンドで一気にクリアできます。スクリプト向けの書き方ですね。

php artisan cache:clear &&
php artisan config:clear &&
php artisan config:cache &&
php artisan route:clear &&
php artisan view:clear &&
php artisan clear-compiled &&
php artisan optimize &&
composer dump-autoload &&
rm -f bootstrap/cache/config.php

Docker環境の場合

docker×Laravel環境構築参考

• Docker version 19.03.1, build 74b1e89
• docker-compose version 1.24.1, build 4667896b

キャッシュクリアをまとめたスクリプト

上記のdocker環境の場合以下のようなスクリプトを用意していると開発が楽です。

clear_cache.sh

#!/bin/sh
docker-compose exec php bash -c "
php artisan cache:clear &&
php artisan config:clear &&
php artisan config:cache &&
php artisan route:clear &&
php artisan view:clear &&
php artisan clear-compiled &&
php artisan optimize &&
composer dump-autoload &&
rm -f bootstrap/cache/config.php"

• 上記はphpという名前のコンテナに対して実行することを想定しているスクリプトです。
• Docker環境では、docker-compose.ymlと同じ階層のディレクトリに配置することを想定しています。

参考サイト

• Artisanコマンド（キャッシュクリア系・最適化）まとめ

まずはじめに

デプロイ先用のアカウントをつくってSSH接続するのがめんどくさかったので手っ取り早くHTTP通信で自動デプロイしようとしたら
謎の挙動をされハマったのでメモ。
ちなみにここではgitlab-ci.ymlのこまかい書き方とかは触れません。違う記事を参照してください。
そして、もっと正統派なやり方があるはずなので、あまり参考にはならないかもしれません。。。

環境

AWS　EC2
　1つ目・・・WEBサーバ(centos)
　2つ目・・・gitサーバ(gitlab)
　これらは同一セキュリティグループ(同一ネットワーク)内に存在している

今回の自動デプロイの全体図

今回はgitlab-ci初めてですし、
ただただWEBサーバが常にdevelopブランチの最新状態になってほしいのでコードのテストとかはこの手順の中でやってません。
（しかしこの方法だと使われていない古いファイルなどが残ってしまうので、rsyncでやったほうが良いと思いました）

単純なgitlab-ci.ymlを用意したがなぜかcloneできない

ymlにcloneを書いたときに認証とおすのどうしたら良いのかわからず無駄にシェルにしてみる

gitlab-ci.yml

build:
  stage: deploy
  script:
    - bash .gitlab-deploy.sh 
  environment:
    name: staging
    url: http://{パブリックIP}/staging
  when: on_success
  only:
    - develop

最初のエラーは、同一ネットワークに存在するのにgitlabの画面で表示されているままにcloneURLのIP部分をパブリックIPにしていたからでした。
しかし、プライベートIPに修正するも延々とfaildするJobたち。。。

Running with gitlab-runner 11.7.0 (8bb608ff)
  on test mrx2efNr
Using Shell executor...
Running on ip-10-2-1-10.ap-northeast-1.compute.internal...
Cloning repository...
Cloning into '/home/gitlab-runner/builds/mrx2efNr/0/hoge-dev/hoge-project'...
fatal: repository 'http://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@10.2.1.20/hoge-dev01/hoge-project.git/hoge-dev01/hoge-project.git/' not found
bash: 66 行: cd: /home/gitlab-runner/builds/mrx2efNr/0/hoge-dev01/hoge-project: そのようなファイルやディレクトリはありません
ERROR: Job failed: exit status 1

gitlab-ci-tokenなんてymlに書いた覚えはないが、なんかそれをつかって勝手に知らない場所にcloneしている模様。
cloneできないなら、clone用ディレクトリを最初にgit initしとけばとりあえずpullできるかなーと思い修正。

gitlab-ci.yml

stages:
  - deploy

deploy_develop:
  stage: deploy
  script:
    - cd /var/www/hoge-project
    - git pull origin develop
  only:
    - develop

しかし、ymlにpullしか書かないで実行してもなぜか勝手にcloneして失敗、
そしてその後の処理ができないという具合になっている。

最後のディレクトリがないというエラーだが、/home/gitlab-runner/builds/mrx2efNr/0/このパスは存在するし
リポジトリは確実に存在しているので、cloneできてないということっぽい。

そこで勝手にcloneしている処理で使われているgitlab-ci-tokenについて調べてみることにしました。

gitlab-ci-tokenについて

ぐぐってみると、こいつはgitlab8.12からの機能らしいが、結構な人数の人がcloneできない！と嘆いていることが判明。
https://gitlab.com/gitlab-org/gitlab-ce/issues/22723

結局解決方法とかのってないのかよ～～とおもっていたら発見！
https://gitlab.com/gitlab-org/gitlab-runner/issues/1884#note_18695580
・gitlabCI側で勝手にgit cloneしてしまうのをまず無効にする(GIT_STRATEGY: noneと書くと無効にできる)
・cloneとかしたいならbefore_scriptで自分で書く
とのことでした。GIT_STRATEGYとはなんぞ？？とということでこちらを発見。
https://docs.gitlab.com/ee/ci/yaml/#git-strategy
「If left unspecified, the default from project settings will be used.」ということで、デフォルトはきっとcloneすることになっていたんでしょう。

ということで、ymlにGIT_STRATEGY: noneを追加。

しかし、pullをするにはアカウント情報とかが必要・・・。
入力を求められたタイミングでパスワードを入力する等の処理が複雑で対応できなかったのと
アカウント作ってSSH Keyを作成したり登録したりするのも面倒だったので、HTTP通信でデプロイできる方法を探すことにしました。
なんか便利なものないのかなーとgitlabの設定周りを見ていたら、便利そうなものを見つけました。
その名もdeploy-tokenです！

deploy-tokenについて

Setting > Repository に存在する機能です。
「Deploy tokens allow read-only access to your repository and registry images.」
なるほど、このトークンを発行するとリポジトリへの読み取り専用アクセスができるらしい。
作成すると、デプロイトークンのユーザ名とパスワードが発行されました。（Expires atは設定しなくても作成できます。）
パスワードに関してはもう見られなくなるそうなので、この時点でしっかりキャプチャ撮ったりコピって保存したりしておきましょう。

実際に使うときは、こんな感じで使います。
git clone -b develop http://{gitlab+deploy-token-N}:{発行されたパスワード}@{IP}/{リポジトリのグループ}/{プロジェクト名}.git {クローンしたいディレクトリ(書かない場合はカレントディレクトリになる)}

結論: deploy-tokenを使ってクローンできました！

色々面倒くさがってしまいましたが、なんやかんやでこんな感じでできました！

gitlab-ci.yml

variables:
  GIT_STRATEGY: none

before_script:
  ## clean the working directory
  - CLONE_DIR="/var/www/clone_dir/"
  - sudo rm -rf $CLONE_DIR
  - sudo mkdir -p $CLONE_DIR

  ## clone the project each time (inefficient, consider performing fetch instead if it already exists)
  - git clone -b develop http://{user}:{pass}@{IP}/hoge-dev/hoge-prjct.git $CLONE_DIR
  - cd $CLONE_DIR
  - ls -l

stages:
  - deploy

deploy_develop:
  stage: deploy
  script:
    - cd /var/www/
    - sudo cp -rf $CLONE_DIR* /var/www/hoge-prjct/
    - cd /var/www/hoge-prjct/
    - chmod -R 777 .
    - composer dump-autoload
    - composer install
    - php artisan migrate:refresh --seed
    - ls -l
  only:
    - develop

deploy-tokenは参照用のみでリポジトリにアクセスできるものなので
CI以外の場面でも使ったりできます、割と便利！
という話でした。

同じDBを参照する、2つのLaravelアプリをdocker-composeで立ち上げる方法について書いていきます。一つのWebサーバー上で2つのLaravelアプリが動いていて、それぞれが同じDBを見ている、といった構成です。

ググったらいくらでも出てくるかな？と思ったら、Laradocを使った方法しかなかったので意外でした。

コンテナの構成

コンテナ関連のディレクトリ構成は、以下の記事を参考にしています。今回やることは、以下の記事のゴールの状態から、立ち上げるLaravelアプリを1つ追加する、みたいなイメージです。

Laravelの開発環境をDockerを使って構築する

docker-compose.ymlを変更

webサーバーにnginxを使っている場合、docker-compose.ymlは以下のような記述になっているかと思います。

docker-compose.yml

version: "3"
services:
  app:
    context: ./docker/php
    // アプリコンテナの記述

  web:
    image: nginx:1.17-alpine
    depends_on:
      app
    // portsなどの記述

別のLaravelアプリを立ち上げる場合は、起動するアプリコンテナを一つ増やします。記述例としてはこんな感じ。

docker-compose.yml

version: "3"
services:
  app:
    context: ./docker/php
    // アプリコンテナの記述

  other:
    context: ./docker/php
    // アプリコンテナの記述

  web:
    image: nginx:1.17-alpine
    depends_on:
      app
      other
    ports:
      3500:80
      3501:79
    volumes:
      - ./app:/work/app
      - ./other:/work/other
      - ./logs:/var/log/nginx
      - ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf

これにより、docker-compose upを実行すると、otherコンテナが立ち上がります。参照するDockerfileは、appと同じものをにするか、新しく定義するかはお好みで。

また、nginxコンテナのdepends_onにotherコンテナを指定し、加えてportsの設定を一つ増やします。これにより、「localhost:3500」でサーバーコンテナの80番ポートに、「localhost:3501」で79番ポートにアクセスできるようになります。

あと、volumesにも変更を加えています。docker-compose.ymlがあるディレクトリの、app/配下がwebサーバーコンテナの/work/appに、other/配下が/work/otherに配置されるようにしています。

default.confの変更

次に、nginxの設定ファイルを変更しています。変更前はこんな感じになっているはず。

default.conf

server {
    listen 80;
    root /work/app/public;
    index index.php;
    charset utf-8;

    location / {
        root /work/app/public;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass app:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /work/app/public/index.php;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

80番ポートにアクセスが来るとnginxがそれに対応する、みたいな標準的な設定です。80番ポートはapp/に配置されているLaravelアプリに対応するようになっています。

今回、otherコンテナに配置するLaravelアプリは79番ポートで受け付けられるようにするので、以下のように記述を追加します。

default.conf

server {
  // 80番ポートの設定
}

server {
    listen 79;
    root /work/other/public;
    index index.php;
    charset utf-8;

    location / {
        root /work/other/public;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass other:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /work/other/public/index.php;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

listenを79番に、rootを/work/other/publicに変更しています。docker-compose.ymlのvolumesに対応するようにrootを設定しましょう。（publicはLaravelの公開ディレクトリです）。

webサーバーコンテナの中が、/work/other/(Laravelのディレクトリ群)のような構成になることを想定した記述ですね。

また、「location ~ .php」の中の記述も少し変更しています。

まず、「fastcgi_pass」がapp:9000から、other:9000になっています。app、otherはアプリコンテナのことで、PHP-FPMとの通信ポートをそれぞれ指定しています。

あと、「fastcgi_param SCRIPT_FILENAME」以下の記述も変更しており、Laravelアプリのpublicフォルダ内のindex.phpを参照するようにしています。ここがズレているとphpファイルが正しく読み込まれず、「File not Found」と表示されて悲しい気持ちになるので忘れずに変更しておいてください。

今回は直接パスを記述していますが、「\$document_root/index.php」みたいな書き方もあります。（$document_rootにはrootで指定したパスが入る）

これで、app/配下、other配下にLaravelをインストールし、.envやディレクトリの権限変更を正しく行えば、localhost:10080、localhost:10079にアクセスするとそれぞれLaravelのWelcomeページが表示されるはずです。

今回は、それぞれのアプリが同じDBを参照するようにしたいので、.envを変更して参照先が同じになるよう設定しておきましょう。

ページが表示されねぇ！みたいなときは、./logs配下のaccess.logやerror.logをヒントに対応してください。

まとめ

docker-composeでバシッと環境が整うと気持ちいいですよね。nginxの設定は基本的なものだけしか記述していないので、勉強がてらいろいろイジり倒そうと思います。

TL;DR

フォームリクエストを利用したバリデーションを行う時、validationDataメソッドをオーバーライドすることで、バリデーションの直前にリクエストパラメータを加工することができます。

今回は、validationDataメソッドを利用して、URLに含まれるパラメータのバリデーションを行います。

環境

• Laravel 5.5

フォームリクエストとは

Laravelでバリデーションを行う為の機能の1つです。
他には、Validatorファサードを利用する方法や、Request::validate()を利用する方法がありますが、フォームリクエストはバリデーションに関する記述を、Controllerから完全に分離することができ、可読性を高く維持できる点で優れています。

より詳しく知りたい方は、以下のページを参考にしてください。

• Laravel 5.5 バリデーション
• Laravelのバリデーションにはフォームリクエストを使おう

FormRequestによるバリデーション

説明の為に、簡単なToDoアプリを作りました。
最終的なコードはこちらにあがっています。

以下、ToDoリストに関するCRUD処理は実装したと仮定して話を進めていきます。

TodoRequestクラスを作成する

フォームリクエストによるバリデーションを機能を利用する為に、次のコマンドを叩いてTodoRequestクラスを作成します。

php artisan make:request TodoRequest

すると、app/Http/Requests/TodoRequest.phpに自動生成されるので、それを次のように書き換えます。

app/Http/Requests/TodoRequest.php

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class TodoRequest extends FormRequest
{
    public function authorize()
    {
        return true;
    }

    public function rules()
    {
        return [
            'title' => 'required',
        ];
    }

    public function messages()
    {
        return [
            'title.required' => ':attributeは入力必須の項目です。',
        ];
    }
}

TodoRequestクラスを使ったバリデーション

実際にバリデーションを行うには、コントローラのメソッドの引数にタイプヒンティングしてあげれば、自動でバリデーションを行ってくれます。

例として、TodoController@storeの引数にTodoRequestクラスをタイプヒンティングしたとします。

app/Http/Controllers/TodoController.php

<?php

namespace App\Http\Controllers;

use App\Http\Requests\TodoRequest;
use App\Models\Todo;

class TodoController extends Controller
{
    private $todo;

    public function __construct(Todo $todo)
    {
        $this->todo = $todo;
    }

    ...

    public function store(TodoRequest $request)
    {
        ... (ToDo作成処理)
    }

そして、新規作成画面で何も入力せずに「作成」ボタンを押下すると、バリデーションが掛かっていることが確認できます?

URLに含まれるパラメータもバリデーションする

さて、ここからが本題です。
次のようなルーティング設定があるとします。

routes/web.php

Route::get('todos/edit/{id}', 'TodoController@edit');

これによって、todos/edit/1やtodos/edit/10等でアクセスすると、{id}部分に対応したidを持つToDoリストの編集フォームが表示されます。

では、todos/edit/hogeのような{id}部分に全く関係の無い値を入れてアクセスしたらどうなるでしょうか？

はい、バグりましたね?

これを防ぐ為には、URLに含まれるパラメータについても、きちんとバリデーションを掛けてあげなければいけません。

先ほど作成したTodoRequestクラスを次のように書き換えてください。

app/Http/Requests/TodoRequest.php

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class TodoRequest extends FormRequest
{
    public function authorize()
    {
        return true;
    }

    public function rules()
    {
        return [
            'id'    => 'exists:todos,id',
            'title' => 'sometimes|required',
        ];
    }

    public function messages()
    {
        return [
            'title.required' => ':attributeは入力必須の項目です。',
        ];
    }

    public function validationData()
    {
        $data = $this->all();
        if (isset($this->id)) {
            $data['id'] = $this->id;
        }

        return $data;
    }
}

先ほどと違い、validationDataというメソッドをオーバーライドしています。

validationDataは、バリデーションが行われる直前に呼ばれるメソッドで、バリデーションするパラメータを追加したい時や、パラメータを加工したい時はここで処理して連想配列を返してあげることで、加工済みの値をバリデーションさせることができます。

今回は、URLの{id}部分のパラメータをバリデーションしたいので、そのパラメータが存在する場合にidキーに値を格納して返しています。
そして、rulesメソッドでidに関するバリデーションを追加してあげれば、URLパラメータに関するバリデーション処理の完成です。

実際に、先ほどと同じようにtodos/edit/hogeにアクセスすると、バリデーションに掛かるので、エラー画面が表示されることなく、直前のページにリダイレクトされるようになります。

まとめ

• フォームリクエストを使うことで、バリデーション処理をスッキリ書くことができます。
• validationDataメソッドをオーバーライドすることで、バリデーション直前にリクエストパラメータを加工することができます。

参考

• Laravel 5.5 バリデーション
• Laravelのバリデーションにはフォームリクエストを使おう
• 【Laravel】URLに指定したidなどをフォームリクエストでバリデーションする方法

Laravel のプロジェクトを clone してきて、SQLite3 に接続して、ブラウザで表示する方法は意外とまとまっていなかったので記事にしました。

推奨環境

• MacOS Mojave バージョン10.14.2
• Laravel Framework 5.8.31
• sqlite3 3.24.0

やり方

1. 対象の Laravel プロジェクトを clone してくる

$ git clone リポジトリ URL

2. プロジェクトのリポジトリに移動し、vendor ディレクトリがないことを確認

$ cd projectName
$ ls

3. Composer がインストールされていなかったら

$ brew install composer

4. ライブラリインストール

$ composer install

vendor ディレクトリが作成されるはず。

5. ディレクトリ下の.env.exampleの内容を.envにコピー

$ cp .env.example .env

clone してきた Laravel プロジェクトは .env ではなく .env.example というファイル名になっているので変更する必要がある。

6. アプリケーションキー(APP_KEY)を設定する

$ php artisan key:generate

.env ファイルの中身を見ると、APP_KEY の内容が APP_KEY=SomeRandomString となっているため、変更する必要がある。

7. SQLite3 の準備

$ touch database/database.sqlite

database ディレクトリに database.sqlite が作られる。

8. .env ファイルの設定

エディタや vim などで .env ファイルの該当箇所を以下のように書き換える

~略~
DB_CONNECTION=sqlite
# DB_HOST=127.0.0.1
# DB_PORT=3306
# DB_DATABASE=homestead
# DB_USERNAME=homestead
# DB_PASSWORD=secret
~略~

DB_HOST以下はいらないのでコメントアウト。
SQLite3 の配置場所やファイル名を変更する場合は、DB_DATABASE に絶対パスで指定しましょう。

9. migrate 実行

$ php artisan migrate

10. いつものようにサーバーを立ち上げる

$ php artisan serve

http://127.0.0.1:8000 にアクセス

環境：mac
初laravelのため、備忘録です。

phpのバージョンを確認

$ php -v

こんな風に出てきます。

composerの用意

• https://getcomposer.org/download/ で最新のcomposerをダウンロードします。

composerを移動、パーミッション設定

##ダウンロードしたcomposer.pharが入っているフォルダに移動します。
$ cd /Users/ユーザー名/Downloads 
※ユーザー名には自分のユーザー名を入れてください。

##composer.pharをbinに移動します
$ sudo mv composer.phar /usr/local/bin/composer
※binがなかったら作成しましょう。
$ sudo mkdir /usr/local/bin

##パーミッション設定
$ chmod a+x /usr/local/bin/composer

Laravelをインストール

$ composer global require "laravel/installer"

環境変数を設定

$ echo export PATH=\"$HOME/.composer/vendor/bin:\$PATH\" >> ~/.bash_profile

環境変数を読み込み

$ source ~/.bash_profile

プロジェクトのテンプレートを生成

$ laravel new app

ディレクトリ移動

$ cd app

ローカルサーバーを起動

$ php artisan serve

ブラウザで開く

http://127.0.0.1:8000
へアクセスし、この画面が表示されれば成功です。