Artisan on ララジャパン

artisan modelコマンド

Fri, 22 Mar 2024 09:30:22 +0900

artisan dbコマンドはLaravelのプロジェクトのデータベースの情報を表示してくれるコマンドでしたが、artisan modelはLaravelのModelのためのコマンドです。見てみましょう。

model:show

※初めての方は、まずartisan dbコマンド読んでください。準備が要ります。

すでに準備がされた方は、早速artisan modelを実行しましょう。

$ php artisan model:show User

と実行すると、

有用な情報がいっぱいありますが、説明が必要ですね。

Attributes

artisan db:table usersの実行においてもDBテーブルの項目やデータタイプが表示されますが、上ではそれらに加えて、fillable、hidden、castの属性もいくつかの項目で表示されています。

以下のModelの定義を見るとそれらの属性が上で表示されているがわかります。

app/Models/User.php

...

class User extends Authenticatable
{
    use HasApiTokens, HasFactory, Notifiable;

    /**
     * The attributes that are mass assignable.
     *
     * @var array<int, string>
     */
    protected $fillable = [
        'name',
        'email',
        'password',
    ];

    /**
     * The attributes that should be hidden for serialization.
     *
     * @var array<int, string>
     */
    protected $hidden = [
        'password',
        'remember_token',
    ];

    /**
     * The attributes that should be cast.
     *
     * @var array<string, string>
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
        'password' => 'hashed',
    ];
}

さらに、accessorの定義を加えてみましょう。

app/Models/Post.php

...
class User extends Authenticatable
{
...
    public function getNameAttribute()
    {
        return Str::upper($this->attributes['name']); // 大文字に変換
    }
}

再度実行すると、

表示されていますね。

Relations

上のRelationsのセクションでは、HasApiTokensとNotifiableのトレイトで定義されているRelationが表示されていますが、それでは少しわかりづらいので、PostsのModelを作成して、以下のようにUsersにRelationを定義します。

app/Models/Post.php

...
class User extends Authenticatable
{
...
   public function posts(): HasMany
    {
        return $this->hasMany(Post::class);
    }
}

再度実行すると、

しっかり表示されていますね。

Observers

これは、モデルに関連するDB処理イベントのメソッドを表示します。例えば、以下のようにDBレコード作成後の処理を定義して、

app/Models/Post.php

...
class User extends Authenticatable
{
...
   public static function booted()
    {
        static::created(function ($user) {
           // レコードが作成された後に実行する処理
        });

    }
}

再度実行すると、

最も便利なartisan dbコマンドの使い方

前回の説明において、このコマンドで一番大事なことを忘れていました。というか、最近になってたまたまオプションなしで実行して気づいたことです。

php artisan dbとオプションなしで実行すると、

$ php artisan db
mysql: [Warning] Using a password on the command line interface can be insecure.
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 369
Server version: 8.0.33 MySQL Community Server - GPL

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

そうなんです。mysqlのコマンドを.envで指定したログインとパスワードを使って実行してくれるのです。便利ですね。

最後に

artisanコマンドはLaravelを使う開発者にとってなくてはならない重要なツールですが、機能が多すぎてとてもオプションを覚えることができません。まして毎回バージョンごとに数が増えるし。

しかし、とても便利なサイト見つけました。

https://artisan.page/

ドロップダウンで、バージョンも変えることもできます。

artisan dbコマンド

Mon, 08 Jan 2024 02:33:53 +0900

Laravelの最新バージョンは10xでもうすぐに11xがリリースされます。しかし、Laravel 9xでartisan dbコマンドにオプションが増えていることについ最近気づいたので、忘れずにここで紹介します。

Laravel 9x以前から存在したdbコマンド

db:seed

まず、データベースにシードのレコードを作成するコマンドです。

$ php artisan db:seed

と実行すると、以下のDatabaseSeederがデフォルトで使用されます。

database/seeders/DatabaseSeeder.php

namespace Database\Seeders;

// use Illuminate\Database\Console\Seeds\WithoutModelEvents;
use Illuminate\Database\Seeder;

class DatabaseSeeder extends Seeder
{
    /**
     * Seed the application's database.
     */
    public function run(): void
    {
        \App\Models\User::factory(10)->create();　// 10個のusersのレコードが作成されます

        // \App\Models\User::factory()->create([
        //     'name' => 'Test User',
        //     'email' => 'test@example.com',
        // ]);
    }
}

新規のプロジェクトでは、seedを実行する前には以下のようにmigrateを実行しましょう。

しかし、プロダクションではこんなに簡単に実行できると危ないと思いませんか？ちなみに、上の実行の環境では、.envでAPP_ENVはlocalで私の開発環境設定です。

.env

APP_NAME=Laravel
APP_ENV=local
...

この値が、productionのときには、上のコマンドを実行すると、

と警告してくれて実行してOKかどうか質問されます。しかし、それでも実行は可能です。注意しましょう。

db:wipe

db:seedは実行する環境によっては危険なコマンドでしたが、こちらはもっと危険です。以下は、APP_ENV=localでの実行ですが、有無も言わさずにDBのテーブルをすべて削除してしまいます。

もちろん、APP_ENV=productionのときには、db:seedと同様に警告と確認のステップがあります。

Laravel 9xで登場したdbコマンド

今度は、Laravel 9xで追加されたコマンドたちです。先のDB操作のコマンドとは違って今度はどれもDBの情報をすぐにチェックできる有用なコマンドです。

db:monitor

現在のDBの接続数を表示するコマンドです。

db:show

DBの情報を表示するコマンドですが、Doctrine DBAL (doctrine/dbal)のパッケージがインストールされていないと、インストールするかどうかが問われます。YESとすると、必要なパッケージがインストールされます。

インストール完了後、再度実行すると、

db:table

こちらは、DBテーブルの情報を表示するコマンドです。まず、どのテーブルの情報が必要か尋ねられます。

usersを選択してENTERすると、

DBテーブルの項目などテーブルの情報を表示してくれます。これはとても便利ですね。

Commandにbefore/after処理を追加する

Mon, 16 May 2022 07:56:30 +0900

今のプロジェクトでは独自に作成したコンソールコマンドが40~50個ほどあります。バッチ処理であったり、クロンで定期実行している処理であったりと様々です。システムが大きくなるとそれだけ必要な処理が増えるので致し方ありません。しかし時折、

このコマンドは何をやっているんだっけ？と見返した時にすぐ思い出せるようにコード量を少なく、シンプルに保っておきたいものです。

そう思いながら今まで作成したコマンドらを眺めていると、毎回決り文句のように記述している処理がいくつかある事に気づきました。気づいてしまったが故にDRYアレルギーが発症してしまい、どこか適切な場所に共通処理として切り出せないだろうか？と調べてみると、CommandにはEventが用意されていました。

CommandのEvent

公式ドキュメントの"Artisan Console"ページの最後に少しだけCommandのEventに関する説明があります。それによると、Commandが実行される際は以下の３つのイベントが発行されるそうです。

ArtisanStarting: artisan実行開始時
CommandStarting: Commandが実行される直前、つまりbefore処理
CommandFinished: Commandが実行された後、つまりafter処理

デフォルトでは上記のEventに対するListenerは用意されていないので、新たに作成し紐付ける必要があります。

before/after処理を追加

ここでは例として、CommandStartingイベントとCommandFinishedイベントを使いコマンド実行前と後に処理を追加してみましょう。まずはbefore処理から。

CommandStartingListener作成

before処理を実装する為のListenerクラスを作成します。以下のコマンドを実行。

php artisan make:listener CommandStartingListener

CommandStartingListenerクラスのhandle()にbefore処理を追加します。以下では開始ログを出力してみました。

app/Listeners/CommandStartingListener.php

<?php

namespace App\Listeners;

use Illuminate\Support\Facades\Log;

class CommandStartingListener
{
    /**
     * Handle the event.
     *
     * @param  object  $event
     * @return void
     */
    public function handle($event)
    {
        // 開始ログを出力
        Log::info($event->command."を開始しました。");
    }
}

EventとListenerを紐付け

作成したCommandStartingListenerはそのままでは発火されません。EventServiceProviderにてCommandStartingイベントに紐付けましょう。

app/Providers/EventServiceProvider.php

<?php

namespace App\Providers;

use Illuminate\Auth\Events\Registered;
use Illuminate\Auth\Listeners\SendEmailVerificationNotification;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;

class EventServiceProvider extends ServiceProvider
{
    /**
     * The event listener mappings for the application.
     *
     * @var array
     */
    protected $listen = [
        Registered::class => [
            SendEmailVerificationNotification::class,
        ],
        // CommandStartingイベントにリスナを紐付け
        \Illuminate\Console\Events\CommandStarting::class => [
            \App\Listeners\CommandStartingListener::class,
        ],
    ];

    /**
     * Register any events for your application.
     *
     * @return void
     */
    public function boot()
    {
        //
    }
}

同様の手順でCommandFinishedListenerを作成し、CommandFinishedイベントに紐付け、終了ログを出力してみましょう。EventServiceProviderは最終的に以下のようになります。

app/Providers/EventServiceProvider.php

...
    /**
     * The event listener mappings for the application.
     *
     * @var array
     */
    protected $listen = [
        Registered::class => [
            SendEmailVerificationNotification::class,
        ],
        // CommandStartingイベントにリスナを紐付け
        \Illuminate\Console\Events\CommandStarting::class => [
            \App\Listeners\CommandStartingListener::class,
        ],
        // CommandFinishedイベントにリスなを紐付け
        \Illuminate\Console\Events\CommandFinished::class => [
            \App\Listeners\CommandFinishedListener::class,
        ],
    ];
...

最後に

適当なコマンドを実行しログ出力されているか試してみましょう。以下ではルートのリストを出力するコマンドを実行しています。

php artisan route:list

laravel.logに開始と終了のログが出力されましたね。

storage/logs/laravel.log

[2022-05-08 08:21:18] local.INFO: route:listを開始しました。  
[2022-05-08 08:21:18] local.INFO: route:listを終了しました。

古いレコードをプルーンします

Sat, 19 Mar 2022 12:14:36 +0900

古くなってもう要らないDBレコードを削除することを、プルーン(prune)あるいはパージ(purge)などと言います。カスタムのArtisanのコマンドを書いて処理してもいいのだけれど、LaravelではこれがModelの中であるトレイトを使うだけで、組織的できてしまいます。

プルーンの対象は特定のDBモデルのレコードです。ここでは、会員ログインのレコードを貯めているuser_logsのテーブルのモデルUserLogを例とします。以下のようにPrunableのトレイトを追加して、削除したい対象のクエリーの条件をprunable()で定義するだけです。

app/Models/UserLog.php

namespace App\Models;
 
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Prunable;
 
class UserLog extends Model
{
    use HasFactory;
    use Prunable;

    const UPDATED_AT = null; // updated_atの項目はない
 
    /**
     * Get the prunable model query.
     *
     * @return \Illuminate\Database\Eloquent\Builder
     */
    public function prunable()
    {
        return static::where('created_at', '<=', now()->subYear()); // １年以上昔のレコードが対象
    }
}

そして、以下のコマンドの実行をクロンに設定にします。

$ php artisan model::prune

簡単でしょう。

削除する前に以下のように実際の削除なしの予行も可能です。

$ php artisan model:prune --pretend
8 [App\Models\UserLog] records will be pruned.

８個のレコードが削除されるよ、と知らせてくれます

tinkerで実際にプルーンを実行してみましょう。どのようなSQL文が実行されるか興味あります。

>>> Artisan::call('model:prune');
=> 0
>>> sql();
=> [
     [
       "query" => "select count(*) as aggregate from `user_logs` where `created_at` <= ?",
       "bindings" => [
         Illuminate\Support\Carbon @1616039564 {#3572
           date: 2021-03-18 03:52:44.536379 UTC (+00:00),
         },
       ],
       "time" => 4.94,
     ],
     [
       "query" => "select * from `user_logs` where `created_at` <= ? order by `id` asc limit 1000",
       "bindings" => [
         Illuminate\Support\Carbon @1616039586 {#3546
           date: 2021-03-18 03:53:06.837232 UTC (+00:00),
         },
       ],
       "time" => 1.36,
     ],
     [
       "query" => "delete from `user_logs` where `id` = ?",
       "bindings" => [
         1,
       ],
       "time" => 7.25,
     ],
     [
       "query" => "delete from `user_logs` where `id` = ?",
       "bindings" => [
         2,
       ],
       "time" => 3.11,
     ],
...

なるほど、１個１個レコードは削除されるのですね。これは、モデルのdeletingやdeletedのイベント処理を可能にするためです。

そのイベント処理が必要でないなら、一括実行も可能です。トレイトをPrunableからMassPrunableにするだけです。

app/Models/UserLog.php

namespace App\Models;
 
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\MassPrunable;
 
class UserLog extends Model
{
    use HasFactory;
    use MassPrunable;

    const UPDATED_AT = null;
 
    /**
     * Get the prunable model query.
     *
     * @return \Illuminate\Database\Eloquent\Builder
     */
    public function prunable()
    {
        return static::where('created_at', '<=', now()->subYear()); // １年以上昔のレコードが対象
    }
}

再度、tinkerでSQL文をチェックすると、

>>> Artisan::call('model:prune');
=> 0
>>> sql();
=> [
     [
       "query" => "delete from `user_logs` where `created_at` <= ? limit 1000",
       "bindings" => [
         Illuminate\Support\Carbon @1616039978 {#3567
           date: 2021-03-18 03:59:38.916448 UTC (+00:00),
         },
       ],
       "time" => 5.61,
     ],
   ]
>>>

削除のSQL文１つだけになっていました。いたれりつくせりです。

Laravel 8.x更新で変わったこと（１）メンテナンス中のアクセス

Sun, 31 Oct 2021 12:48:59 +0900

Laravel 7.xから8.xに更新して変わったことを紹介していきます。最初は、メンテナンスモードに関して。

Laravel 7.xのメンテナンスモードに関して書いたのは、たった１年前のことです。メンテナンス画面：php artisan up & downでは、

Laravelの経験が長くなると、つまり初期のバージョンから使用していると、昔のやり方しか知らずに過ごしていることがあります。... ということでやり方学びなおします

なんて書いていましたが、Laravel 8.xの更新でまたもや学びなおしです。

php artisan downのコマンドはそのままですが、それに追加するオプションが変わりました。

まず、比較してみましょう。

Laravel 7.xにおいて、

$ php artisan down --help

を実行すると、以下のようのなオプションがあります。英語のヘルプは日本語に私が訳しています。

Usage:
  down [options]

Options:
      --message[=MESSAGE]  メンテナンス画面に表示するメッセージ
      --retry[=RETRY]      HTTPヘッダーのRetry-Afterの秒数を設定
      --allow[=ALLOW]      メンテナンスモードでもアクセスできるIPアドレスを指定

同じコマンドラインをLaravel 8.xで実行すると、

Usage:
  down [options]

Options:
      --redirect[=REDIRECT]  メンテナンス中は指定のURLに皆リダイレクト<strong>
      --render[=RENDER]      メンテナンス中に表示する画面を指定
      --retry[=RETRY]        HTTPヘッダーのRetry-Afterの秒数を設定
      --refresh[=REFRESH]    HTTPヘッダーのRefreshの秒数を設定
      --secret[=SECRET]      メンテンナンスをバイパスするシークレットコードを指定
      --status[=STATUS]      メンテナンス中に返すHTTPのステータスコードを指定（デフォルト503）

オプションの数が増えただけでなく、–messageとか–allowとかが無くなってしまいました。

これは問題です。　–allowなしにどうやって開発者あるいは関係者だけがメンテナンス中のサイトにアクセスできるのでしょうか？

Laravel 8.xはそれを、–secretのオプションで解決します。実行は、例えば

$ php artisan down --secret=secret-code

としてメンテンナンスに入り、ブラウザーで以下のURLでアクセスすると、あたかもメンテナンスなしの状態で画面にアクセスできます。

https://example.com/secret-code

これはとても素晴らしいです。今まで自宅のIPが変わったりしていちいち調べて–allowにIPアドレスを指定していましたが、その必要がなくなります。

仕組みとしては、いたって簡単で上のようにシークレットコードでアクセスしたら、larave_maintenanceというクッキーにその値を暗号化して入れて、それが正しいかをチェックしているようです。

もちろん、先の例のようにsecret-codeではあまりにも簡単すぎるので実際には以下のようにtinkerで値を作成することを勧めます。

>>> Str::random()
=> "mdcSOnkB5fT2rGAC"
>>> (string) Str::uuid()
=> "fe3a8010-bdda-4972-a0bb-ab96c17841a6"
>>>

Laravelでログファイルの作成（３）コマンドログファイル自動ネーミング

Mon, 26 Apr 2021 00:00:32 +0900

Artisanコマンドはコマンドラインで手動で実行するだけでなく、クロンジョブでの実行でも使用します。時間を設定して自動的に実行されるゆえに、実際に実行されたのか、どれだけ時間かかったのか、いくつのレコードを処理したのかなどをログに記録しておきたいです。そして、わかりやすいようにコマンドごとに違うログファイルを作成したいです。となると、config/logging.phpでそれぞれのコマンドのチャンネルを作成することになるのでしょうか？　つまり５０個コマンドあれば５０個のチャンネルの作成です。それは面倒だな、ということで良いアイデアを思いつきました。

要は、コマンドごとにログファイル名を変えれば良いことなので、前回の月次ごとのログの作成をベースとして変更します。

まず、config/logging.phpに新しいチャンネルcliを追加します。

config/logging.php

...
   'channels' => [
...
        'monthly' => [
            'driver' => 'daily', // use RotatingHandler
            'tap' => [App\Logging\MonthlyFileNameForRotatingHandler::class],
            'path' => storage_path('logs/laravel.log'),
            'level' => 'info',
            'permission' => 0666,
            'days' => 12, // １２ヶ月でローテーション
        ],

        'cli' => [
            'driver' => 'daily', // use RotatingHandler
            'tap' => [App\Logging\CommandFileNameForRotatingHandler::class],
            'path' => storage_path('logs/cli.log'),
            'level' => 'info',
            'permission' => 0666,
            'days' => 12, // １２ヶ月でローテーション
        ],
...

前回のmonthlyのチャンネルの設定と比較すると、変わっているのはtapで指定したクラス名とpathのログファイル名だけです。

そして、以下の新規のクラスの定義は、これまた前回のMonthlyFileNameForRotatingHandlerクラスとほとんど変わりません。

app/Logging/CommandFileNameForRotatingHandler.php

namespace App\Logging;

class CommandFileNameForRotatingHandler
{
    /**
     * Customize the given logger instance.
     *
     * @param  \Illuminate\Log\Logger  $logger
     * @return void
     */
    public function __invoke($logger)
    {
        foreach ($logger->getHandlers() as $handler) {
       	    $name = $_SERVER['argv'][1]; //実行されるArtisanのコマンド名を取得して、以下でそれを使用
            $handler->setFilenameFormat("{filename}-$name-{date}", 'Y-m');
        }
    }
}

変更した部分は、ファイル名の作成の部分だけです。そして、この設定により以下のようなコマンドラインを実行するなら、

$ php artisan command:log

作成されるログファイル名は、cli-command:log-2021-04.logのようになります。

違うコマンドを実行するなら、

$ php artisan task:something

ログファイル名は、cli-task:something-2021-04.logとなります。

もちろんArtisanのコマンドでは以下の例のように、Logの関数のコールが必要です。

app/Console/Commands/LogCommand.php

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Illuminate\Support\Facades\Log;

class LogCommand extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'command:log {action} {--option=}';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Command description';

    /**
     * Create a new command instance.
     *
     * @return void
     */
    public function __construct()
    {
        parent::__construct();
    }

    /**
     * Execute the console command.
     *
     * @return int
     */
    public function handle()
    {
        Log::channel('cli')->info('start', $_SERVER['argv']); // ここでcliのチャンネルを使用してコール

        return 0;
    }
}

上のコマンドを実行すると、cli-command:log-2021-04.logの中身は、以下のようになります。 info()の２番目の引数には配列を渡すことが可能です。ここではコマンドラインの引数を記録します。

$ php artisan command:log run --option=x
$ cat storage/logs/cli-command:log-2021-04.log
[2021-04-24 23:45:46] local.INFO: start ["artisan","command:log","run","--option=x"]

→ ログに関しての他の記事

tinkerでartisanを実行

Mon, 18 Jan 2021 04:23:35 +0900

debugbarを使うとコントローラでのDB処理に使用されるSQL文をブラウザ画面でデバッグ文をわざわざ挿入することなしに見ることができます。しかし、php artisanのコマンドラインの実行では同様なことできません。さて、どうしたらよいでしょうか？

まず、テストコマンドの作成から、

$ php artisan make:command TestCommand

この実行で、TestCommand.php が作成されます。これを以下のように編集します。

app/Console/Commands/TestCommand.php

namespace App\Console\Commands;

use App\User;
use Illuminate\Console\Command;

class TestCommand extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'command:test';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'テストコマンド';

    /**
     * Create a new command instance.
     *
     * @return void
     */
    public function __construct()
    {
        parent::__construct();
    }

    /**
     * Execute the console command.
     *
     * @return int
     */
    public function handle()
    {
        $count = User::count();

        echo "会員の数：$count\n";

        return 0;
    }
}

まず、通常のコマンドラインからの実行で動作確認です。

$ php artisan command:test
会員の数：1

大丈夫ですね。

さて、その実行でどのようなSQL文が実行されているかをチェックするには、そう、tinkerの登場です。以下はtinkerの１セッションですが、説明のために分割されているので注意を。

$ php artisan tinker
Psy Shell v0.10.4 (PHP 7.3.14 — cli) by Justin Hileman

まず、DBクエリのログ機能をオンにします。

>>> DB::enableQueryLog();
=> null

次に、コマンドの実行です。そうです、Artisan::call()の関数の引数にコマンド名を指定するだけなのです。

>>> Artisan::call('command:test');
会員の数：1
=> 0

次に、貯めたログを出力します。

>>> DB::getQueryLog();
=> [
     [
       "query" => "select count(*) as aggregate from `users`",
       "bindings" => [],
       "time" => 14.32,
     ],
   ]
>>>

SQL文が見れましたね。

DB::enableQueryLog()などを毎回毎回tinkerのセッションでタイプするのが面倒なら、以前のこの記事のようにブートストラップのファイルを作成しておくと、

$ php artisan tinker ~/tinker.php
>>> Artisan::call('command:test');
会員の数：1
=> 0
>>> sql()
=> [
     [
       "query" => "select count(*) as aggregate from `users`",
       "bindings" => [],
       "time" => 14.29,
     ],
   ]
>>>

と簡単になります。

私は、シェルのエイリアスとして、.zshrcファイルに入れています。

...
alias tinker='php artisan tinker ~/tinker.php'
...

メンテナンス画面：php artisan up & down

Sun, 08 Nov 2020 05:10:45 +0900

Laravelの経験が長くなると、つまり初期のバージョンから使用していると、昔のやり方しか知らずに過ごしていることがあります。以前にメンテナンス画面の裏口のポストがありますが、それはバージョン5.1の話で、大昔です。ということでやり方学びなおします。

メンテンナンス画面

プログラムの更新をインストールしたり、データベースに変更をしたりするときは、誰にも作業中にアクセスしてもらいたくありません。そのときに、以下を実行します。

$ php artisan down

これを実行すると、アクセスしてきたら、以下のような画面が表示されます。それで安心して、プログラムを更新したり、データベースを変更したり、など好き勝手なことできます。

メンテナンスが完了したら、

$ php artisan up

を実行して、皆にアクセスできるようにします。

メンテンナンス画面にメッセージを表示したいなら、

$ php artisan down --message="メンテナンス中です。午前３時に終了します。"

と実行すると以下のように、メッセージが表示されます。

便利ですね。

私がアクセスしたい

メンテナンスの間、好き勝手なことをするのはいいのですが、私自身がサイトにアクセスできないと困ります。プログラムの更新をテストすることなどができません。

特定のIPアドレスからアクセスできるようにする、つまり裏口を作る必要あります。

ここが以前（古いLaravelのバージョン）と最近のバージョンが違うところです。

$ php artisan down --message="メンテナンス中です。午前３時に終了します。" --allow=192.168.56.1

のように、–allowの引数で自分のIPアドレスを指定するだけで、私にとってはアクセス可能となります。

さらに、毎回毎回コマンドラインで指定するのが面倒なら、以前のように

app/Http/Middleware/CheckForMaintenanceMode.php

namespace App\Http\Middleware;

use Closure;
use Symfony\Component\HttpFoundation\IpUtils;

use Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode as Middleware;

class CheckForMaintenanceMode extends Middleware
{
    /**
     * The URIs that should be reachable while maintenance mode is enabled.
     *
     * @var array
     */
    protected $except = [
    	//
    ];

    protected $allowed = [
    	'192.168.56.1'　// ここで許可するIPを登録
    ];

    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     *
     * @throws \Symfony\Component\HttpKernel\Exception\HttpException
     * @throws \Illuminate\Foundation\Http\Exceptions\MaintenanceModeException
     */
    public function handle($request, Closure $next)
    {
        if ($this->app->isDownForMaintenance()) {

            if (IpUtils::checkIp($request->ip(), (array) $this->allowed)) {
                return $next($request);
            }
        }

        return parent::handle($request, $next);　// ここで親の関数を呼ぶ
    }
}

と編集します。

メンテナンス画面をカスタマイズしたいなら

メンテナンス画面をカスタマイズしたいなら、まず、以下を実行してブレードを作成します。

$ php artisan vendor:publish --tag=laravel-errors

resources/viewsのディレクトリにerrorsサブディレクトリが作成されて以下のファイルがコピーされます。

errors
├── 401.blade.php
├── 403.blade.php
├── 404.blade.php
├── 419.blade.php
├── 429.blade.php
├── 500.blade.php
├── 503.blade.php
├── illustrated-layout.blade.php
├── layout.blade.php
└── minimal.blade.php

メンテナンス画面のカスタマイズのために編集するファイル、503.blade.phpです。503は、Service Unavailable、つまり「サービスは利用できません」のウェブステータスです。

artisanのコマンドは実行できる？

最後に、メンテナンス中に、クロンで設定されているphp artisanのコマンドは実行されるかどうかですが、php aritsan upが実行できるのだからもちろん実行可能です。ということは、メンテナンス中においてクロンのサービスをいったん止めることも必要かもしれません。ご注意を。