ヘルパー on ララジャパン

設定なしでカスタムログファイルを作成（２）

Sat, 17 Jun 2023 04:28:42 +0900

プログラムの中のどこからでもカスタムログを作成できるようにしたのは前回の話。今回はそのログを例えば３ヶ月ごとにローテーションしてみます。

前回のカスタムログの関数はこちらです。

ローテーションの目的

ログのファイルをローテーションする目的は、いくつかあります。１つのファイルにログを保存していると、ファイルが大きくなるのでオープンするのに時間がかかる、また、ファイルが大きくなるとディスクスペースも取られ、最悪はディスク使用率が100%となるかもしれません。ということで、ファイル名に年月を入れて必要な月数だけのファイルをキープするのがログローテーションです。

具体的な例として、現在ディレクトリに以下のようなログファイルがあるとします。

custom-2023-04.log
custom-2023-05.log
custom-2023-06.log

7/1になりログが保存されると、

custom-2023-05.log
custom-2023-06.log
custom-2023-07.log

４月のファイルが削除されて７月のファイルが作成されます。つまりいつも３ヶ月分のログファイルが存在します。

ローテーションするには

Laravelはログの管理には、phpではとても有名なMonologのパッケージを使っています。Monologはとてもフレキシブルに出来ていていろいろなカスタム化が可能です。今回はMonologのログローテーションのハンドラーを使い、月次のローテーションを設定します。

まず、RotatingFileHandlerのクラスを継承して、ファイルフォーマットの設定を、デフォルトの日次FILE_PER_DAYから、月次のFILE_PER_MONTHに設定します。

app/logging/MonthlyRotatingHandler.php

namespace App\Logging;

use Monolog\Handler\RotatingFileHandler;
use Monolog\Logger;

class MonthlyRotatingHandler extends RotatingFileHandler
{
    /**
     * @param  string  $filename　　ログファイル名
     * @param  int  $maxFiles       最高のローテーション数（0ならローテーションなし）
     * @param  string|int  $level   これがコールされる最低のログレベル（デフォルトはDEBUG）
     * @param  bool  $bubble        stackチャンネルが可能か（デフォルトはtrue）
     * @param  int|null  $filePermission ファイルの許可（デフォルトは0644）
     * @param  bool  $useLocking     書き込み中にログファイルをロックするか（デフォルトはfalse）
     */
    public function __construct(string $filename, int $maxFiles = 0, $level = Logger::DEBUG, bool $bubble = true, ?int $filePermission = null, bool $useLocking = false)
    {
        parent::__construct($filename, $maxFiles, $level, $bubble, $filePermission, $useLocking);

        $this->setFilenameFormat('{filename}-{date}', static::FILE_PER_MONTH); // デフォルトの'Y-m-d'から'Y-m'に変える
    }
}

簡単ですね。ちなみに、年次としたいなら、FILE_PER_YEARとしてください。

次に、このハンドラーを使い、前回作成したヘルパーを編集します。

app/helpers.php

use Illuminate\Support\Facades\Log;

if (! function_exists('custom_log')) {
    function custom_log($prefix, $message)
    {
        Log::build([
            'driver'     => 'monolog',
            'handler'    => App\Logging\MonthlyRotatingHandler::class,
            'with'       => [
                'filename'       => storage_path('logs/'.$prefix.'.log'),
                'filePermission' => 0666, //すべてで読み書き可能とする
                'maxFiles'       => 3, // ３ヶ月でローテーション
            ],
        ])->info($message);
    }
}

これだけです。早速テストしてみると、storage/logsには以下のようにファイルが作成されました。

$ ls -l
-rw-rw-rw- 1 kenji kenji 114 Jun 14 14:20 custom-2023-06.log
-rw-rw-rw- 1 kenji kenji   0 Jun 14 14:19 laravel.log

また、上のfilePermissionで指定したように、ファイルのパーミッションは0666となっています。

設定なしでカスタムログファイルを作成（１）

Wed, 07 Jun 2023 09:20:09 +0900

プログラムの中で必要なときにちょろっとある情報をログに残したい、しかもlaravel.logではなくカスタム（ここが大事）のログファイルを作成して残したい、というのが私の願いです。さて、どうプログラムするか？

通常は

以前にも紹介したように、カスタムのログファイルを使うには、config/logging.phpに以下のように追加して、

config/logging.php

...
    'channels' => [
        'single' => [
            'driver' => 'single',
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
        ],
...
       'custom' => [
            'driver' => 'single',
            'path' => storage_path('logs/custom.log'),
            'level' => 'info',
            'permission' => 0666,
        ],
    ],
];

と設定して、

use Illuminate\Support\Facades\Log;
...
Log::channel('custom')->info('テストだよ');

のようにコールすると、storage/logs/custom.logが作成されて渡した文字列が日時とともに記録されます。

しかし、ログファイル名を変えたいなら、いちいちconfig/logging.phpで設定しなればならないのが難点です。

オンデマンドログ

そこで登場するのがオンデマンドのログです。以下のように使います。

use Illuminate\Support\Facades\Log;
... 
Log::build([
    'driver' => 'single',
    'path' => storage_path('logs/custom.log'),
])->info('記録したいことをここに書く');
...

Logをコールするときに、どのファイルに書き込むかなどの設定もその場で指定してしまいます。しかし、今度はタイプする文字数が多いのが難点。

ヘルパーの作成

先の実行文をヘルパーにして、以下のようにコールするようにしたらシンプルになりますね。

custom_log('custom', '記録したいことをここに書く');
// storage/logs/customer.logに保存される
custom_log('invalid_email', '不正なメールアドレス：'.$request->email);
// storage/logs/invalid_email.logに保存される

このヘルパーの関数は、以下のように定義してapp/helpers.phpへ入れます。

app/helpers.php

<?php
use Illuminate\Support\Facades\Log;

if (! function_exists('custom_log')) {
    function custom_log($prefix, $message)
    {
        Log::build([
             'driver' => 'single',
             'path' => storage_path('logs/'.$prefix.'.log'),
        ])->info($message);
    }
}

そして、composer.jsonファイルを編集して、以下のようにautoloadにfilesとして含みます。

composer.json

...
    "autoload": {
        "files": [
            "app/helpers.php"
        ],
        "psr-4": {
            "App\\": "app/",
            "Database\\Factories\\": "database/factories/",
            "Database\\Seeders\\": "database/seeders/"
        }
    },
...

最後に以下を実行してローダーを更新します。

composer dump-autoload

これでLaravelのプログラムのどこでも、customer_log()を使用することができます。

request()ヘルパーが変？

Sun, 29 Aug 2021 05:37:09 +0900

以前に「ティンカーでリクエスト（Request）」で、ティンカーにおいてRequestのオブジェクトをシミュレートできることを紹介しました。あれから数年、ヘルパー関数のrequest()にもティンカーで値を追加できる技を取得しました。

request()に値がない

まず、以前のティンカーでのRequestオブジェクトの作成をここで再現します。

Psy Shell v0.10.8 (PHP 7.4.21 — cli) by Justin Hileman
>>>  $request = \Illuminate\Http\Request::create('http://localhost', 'GET', ['name' => 'test']);
=> Illuminate\Http\Request {#5238
     +attributes: Symfony\Component\HttpFoundation\ParameterBag {#5234},
     +request: Symfony\Component\HttpFoundation\InputBag {#5236},
     +query: Symfony\Component\HttpFoundation\InputBag {#5235},
     +server: Symfony\Component\HttpFoundation\ServerBag {#5231},
     +files: Symfony\Component\HttpFoundation\FileBag {#5232},
     +cookies: Symfony\Component\HttpFoundation\InputBag {#5233},
     +headers: Symfony\Component\HttpFoundation\HeaderBag {#5230},
   }
>>>  $request->all()
=> [
     "name" => "test",
   ]
>>> $request->name
=> "test"
>>>

そして、このRequestオブジェクトを利用して簡単にバリデーションのテストもできます。

>>> $request->validate(['name' => 'required|alpha'])
=> [
     "name" => "test",
   ]
>>> $request->validate(['name' => 'required|numeric'])
Illuminate\Validation\ValidationException with message 'The given data was invalid.'
>>>

しかし、このオブジェクトでは、ヘルバーを使うと期待した値が返ってきません。

>>> request('name')
=> null　// "test"と返ってきて欲しい！

どうしてでしょう？

グローバルのRequestオブジェクト

request()の定義を見ると、

vendor/laravel/framework/src/Illuminate/Foundation/helpers.php

...
    /**
     * Get an instance of the current request or an input item from the request.
     *
     * @param  array|string|null  $key
     * @param  mixed  $default
     * @return \Illuminate\Http\Request|string|array
     */
    function request($key = null, $default = null)
    {
        if (is_null($key)) {
            return app('request');
        }

        if (is_array($key)) {
            return app('request')->only($key);
        }

        $value = app('request')->__get($key);

        return is_null($value) ? value($default) : $value;
    }
...

app(‘request’)というのがヘルパーで使用しているRequestのオブジェクトのようです。ティンカーでタイプしてみると、

>>> app('request');
=> Illuminate\Http\Request {#77
     +attributes: Symfony\Component\HttpFoundation\ParameterBag {#68},
     +request: Symfony\Component\HttpFoundation\InputBag {#70},
     +query: Symfony\Component\HttpFoundation\InputBag {#65},
     +server: Symfony\Component\HttpFoundation\ServerBag {#69},
     +files: Symfony\Component\HttpFoundation\FileBag {#74},
     +cookies: Symfony\Component\HttpFoundation\InputBag {#73},
     +headers: Symfony\Component\HttpFoundation\HeaderBag {#76},
   }

先に作成したRequestのオブジェクトのIDは、#5238なのにこちらは#77で、Laravelのプログラムの実行（ティンカーの実行）のかなり初期に作成されたオブジェクトということがわかります。そして、そのオブジェクトはLaravelがサービスコンテナーとして管理するグローバルにアクセス可能なRequestのオブジェクトです。

そして、以下のようにこのオブジェクトに値を追加することも可能なのです。

>>> app('request')->all();
=> []
>>> app('request')->merge(['name' => 'test']);
=> Illuminate\Http\Request {#77
     +attributes: Symfony\Component\HttpFoundation\ParameterBag {#68},
     +request: Symfony\Component\HttpFoundation\InputBag {#70},
     +query: Symfony\Component\HttpFoundation\InputBag {#65},
     +server: Symfony\Component\HttpFoundation\ServerBag {#69},
     +files: Symfony\Component\HttpFoundation\FileBag {#74},
     +cookies: Symfony\Component\HttpFoundation\InputBag {#73},
     +headers: Symfony\Component\HttpFoundation\HeaderBag {#76},
   }
>>> app('request')->all();
=> [
     "name" => "test",
   ]
>>> app('request')->name
=> "test"

そして、ヘルパーでも値を取得できるようになります。

>>> request('name')
=> "test"

withInput(), withErrors(), with()

Sat, 03 Oct 2020 02:10:22 +0900

前回では、入力画面で投稿した入力値やバリデーションエラーを画面に表示するために、セッションを利用してそれらの値がキープされることを知りました。今回はそれらがどのようにコントローラで指示されるかを見てみます。

Laravelの認証パッケージで提供されるものは、より複雑なので簡単な会員登録のコントローラをここでは使います。

RegisterController.php

namespace App\Http\Controllers;

use App\User;

use Illuminate\Http\Request;

class RegisterController extends Controller
{
    /**
     * Create
     *
     * @return \Illuminate\View\View
     */
    public function create()
    {
        return view('auth.register');
    }

    /**
     * Store
     *
     * @param  \Illuminate\Http\Request $request
     * @return \Illuminate\Http\RedirectResponse
     */
    public function store(Request $request)
    {
        $rules = [
            'name'                  => 'required',
            'email'                 => 'required|email',
            'password'              => 'required|confirmed',
            'password_confirmation' => 'required',
        ];

        $request->validate($rules);

        User::create($request->all);

        return redirect()
            ->route('login')
            ->with('status', '新規作成完了');
    }
}

３４行目の$request->validate($rules)のコードが、バリデーションエラーが起こったときに、入力値やエラーをセッションに一時的に保存する作業をすべてやってくれるのですが、これではシンプルすぎ（もちろん良いことですが）で説明のしようがないので、以下のように拡張したコードに変えてみます。

...
        $validator = validator($request->all(), $rules); // バリデーションを実行

        if ($validator->fails()) { // バリデーションエラーがあるなら、
            return back()   // 前の画面にリダイレクト
                ->withInput() // セッション(_old_input)に入力値すべてを入れる
                ->withErrors($validator); // セッション(errors)にエラーの情報を入れる
        }
...

上でコメントを入れましたが、back()にチェーンされた、withInput()とwithErrors()の関数が入力値とエラーをセッションに保存してくれます。

withInput()の引数として、配列関数を指定することもできます。例えば、

...
            return back()
                ->withInput($request->except('email')) // email以外の入力値を保存
                ->withErrors($validator);
...

さらに、入力値やエラーと関係ない値も、with()でセッションに保存して、次の画面で使用も可能です。

...
            return back()
                ->withInput($request->except('email'))
                ->with('error', '入力エラーがあります')
                ->with(['more' => 'メッセージ', 'more2' => 'メッセージ2']);
...

デバッグバーで見ると、セッションに保存されていることがわかります。

with()で渡した値は、ブレードでは、session()ヘルパーを利用して、

@if (session('error')) 
    <div class="alert alert-danger">{{ session('error') }}</div>
@endif

のように使えます。

old()ヘルパー

Fri, 25 Sep 2020 23:42:41 +0900

Laravelのブレードファイルでよく見かける、old()ヘルパー。エラーが起こった時に入力した値をキープしてエラーとともに入力項目に残してくれる優れものです。今回はこの仕組みを見てみます。

ブレードファイル

old()ヘルパーはブレードファイルに使われます。以下は、Laravelのデフォルトの認証に使用されるブレードのファイルの一部をとってきました。

...
<div class="form-group row">
	<label for="email" class="col-md-4 col-form-label text-md-right">{{ __('E-Mail Address') }}</label>

	<div class="col-md-6">
		<input id="email" type="text" class="form-control @error('email') is-invalid @enderror" name="email" 
		    value="{{ old('email') }}" required autocomplete="email">

		@error('email')
			<span class="invalid-feedback" role="alert">
				<strong>{{ $message }}</strong>
			</span>
		@enderror
	</div>
</div>
...

inputのHTML文で、value="{{ old(’email’) }}"にヘルパーが使われていますね。

このために、以下のようにエラーが起こると、入力した値が再表示されます（ここでは、デモののためにtype=“email"ではなく、type=“text"としています）。

リクエストの流れ

エラーが出力するまでのリクエストの流れをたどってみると、以下の３つのリクエストとリスポンスからなります。

GETのリクエストで空の入力画面が表示されます。
次に、不正なEmailの値を入れて、「Register」のボタンを押すとPOSTのリクエストでサーバー、つまりLaravelのコントローラに送信されます。
そこのバリデーションでエラーが起こると（つまりメールアドレスのフォーマットではない）、入力した値とエラーを表示するためにGETのリクエストで以下の画面となります。

さて、どうやってLaravelはPOSTした入力値を次のGETで表示される画面に出力しているのでしょう？

Laravelはこの目的のためにセッションを利用しています。上の２番目のPOSTのリクエストでセッションに入力値を保存して、次のGETのリクエストのときに、セッションから取り出します。このセッションの保存は特別で、使用は次のリクエストのみです。それゆえに同じ画面を手動でリフレッシュすると上の１の空の入力の画面となります。

デバッグバー

ここ実際のセッションの状態がどう遷移するか見てみたいですね。

そこで登場するのがデバッグバーのパッケージです。

以下でインストールできます。

$ composer require barryvdh/laravel-debugbar --dev

デバッグバーをインストールして、同じ画面でエラーを発生させると、以下のように画面下で実行したDBクエリーやセッションなどの情報を見ることできます。

赤の矢印の部分をクリックすると、セッションの情報が表示されます。あれれ、old()の値となるセッション項目は空ですね。おかしいかなと思いきや、この画面は、流れの３番目の画面を表示後の段階で、もう保存した値はセッションにはないのです。その前のPOSTのの直後のセッションの値を見る必要あります。

POSTへ戻るには、青箱のフォルダーアイコンをクリックします。そこでポップアップ表示される以下のダイアログにおいて、POSTの行をクリックします。

以下がPOSTの直後でのセッションの値です。見ての通りに、_old_inputには入力された値、errorsにはエラーのデータが保存されています。さらに、_flashの配列には、oldとして_old_inputとerrorsがあり、これらは次のリクエストで利用できることを示しています。

route()ヘルパー

Sat, 19 Sep 2020 06:44:13 +0900

Laravelのヘルパーの関数は本当に便利なもので、日常よく使うものです。しかし、こんな使い方もあったのか、と知らない使い方を知って嬉しくなることあります。今回は私を嬉しくさせる、route()のヘルパーの紹介です。

私はrouteに名前を付けるのが好きで、プログラムのrouteにはすべて名前がついています。それゆえに、route()のヘルパーは欠かせないものです。

以下は、Laravel 7.xバージョンの新規プロジェクトを作成してユーザー認証もインストールしたプロジェクトのrouteです。

+----------+------------------------+------------------+------------------------------------------------------------------------+ | Method | URI | Name | Action | +----------+------------------------+------------------+------------------------------------------------------------------------+ | GET|HEAD | / | | Closure | | GET|HEAD | api/user | | Closure | | GET|HEAD | home | home | App\Http\Controllers\HomeController@index | | GET|HEAD | login | login | App\Http\Controllers\Auth\LoginController@showLoginForm | | POST | login | | App\Http\Controllers\Auth\LoginController@login | | POST | logout | logout | App\Http\Controllers\Auth\LoginController@logout | | GET|HEAD | password/confirm | password.confirm | App\Http\Controllers\Auth\ConfirmPasswordController@showConfirmForm | | POST | password/confirm | | App\Http\Controllers\Auth\ConfirmPasswordController@confirm | | POST | password/email | password.email | App\Http\Controllers\Auth\ForgotPasswordController@sendResetLinkEmail | | GET|HEAD | password/reset | password.request | App\Http\Controllers\Auth\ForgotPasswordController@showLinkRequestForm | | POST | password/reset | password.update | App\Http\Controllers\Auth\ResetPasswordController@reset | | GET|HEAD | password/reset/{token} | password.reset | App\Http\Controllers\Auth\ResetPasswordController@showResetForm | | GET|HEAD | register | register | App\Http\Controllers\Auth\RegisterController@showRegistrationForm | | POST | register | | App\Http\Controllers\Auth\RegisterController@register | +----------+------------------------+------------------+------------------------------------------------------------------------+
第３番目のNameの列がrouteの名前です。この値をもとにtinkerで、route()を使っていろいろなurlを作成してみます。まずは基本からで、route()の最初の引数に、route名を渡します。

>>> route('home'); => "http://localhost/home"
作成されたurlの、http://localhostの部分は、.envのAPP_URLの定義から来ています。 .envにおいて、

.env

... APP_URL=http://www.example.com ...
と定義すると、

>>> route('home'); => "http://www.example.com/home"
となります。

今度は、route()に２番目の引数を与えます。

>>> route('password.reset', ['token' => '1232457890']); => "http://www.example.com/password/reset/1232457890"
このtokenは上のrouteの表のURIで password/reset/{token}と定義されているので、与えた値に置き換わります。

しかし、定義されていない変数も渡すこと可能です。

>>> route('password.reset', ['token' => '1232457890', 'type' => 'user']); => "http://www.example.com/password/reset/1232457890?type=user"
この値は、コントローラの引数の$requestを使って、$request->typeとかで取得できますね。

さらに、‘type’ => ‘user’の配列の形でなくても、単に、‘user’とかでも与えることできます。

>>> route('password.reset', ['token' => '1232457890', 'user']); => "http://www.example.com/password/reset/1232457890?user"
この場合は、コントローラ側では、$request->has(‘user’)とかでブーリアン値で取得できます。

今度は、route()の第３の引数です。これはブーリアン値で、デフォルトがtrueでfalseを与えるとドメイン名がついた絶対URLではなくパス名だけを生成してくれます。

>>> route('home', null, false); => "/home"
最後に、redirect()にもroute()を使えます。

SomeController.php

] ... return redirect(route('home'));
でもOKですが、

... return redirect()->route('home');
とチェーンできます。

abort()を使ってリダイレクト

Sat, 25 Jul 2020 00:01:46 +0900

Laravelのコントローラにおいて、abort(404)のヘルパーをコールすることで簡単に予期しないアクセスを、Not Foundのエラーページの表示ができます。しかし、Not Foundページの代わりにリダイレクトして違うページに飛ばしたいときには、redirect()のヘルパーをabort()同様に好きな場所で使うことはできません。

そう書いても何を言っているかわからないと思いますので、まず、商品（Product）の情報を閲覧するコントローラを使って、abort()とredirect()の紹介から。

abort()は以下のように単独でコードに配置します。

namespace App\Http\Controllers; use App\Product; use App\Http\Controllers\Controller; class ProductController extends Controller { public function show(Product $product) { if ($product->active_flag == 'N') { // 無効な商品なら、 abort(404); // Not Foundページを表示 } return view('user.product.show')->with(compact('product')); // 商品のページを表示 } }
しかし、redirect()は、以下のようにreturnが必要です。

... class ProductController extends Controller { public function show(Product $product) { if ($product->active_flag == 'N') { // 無効な商品なら、 return redirect('home'); // ホームページにリダイレクト } return view('user.product.show')->with(compact('product')); // 商品のページを表示 } }
この違いは、abort()がHttp Exceptionをthrowするのに対して、redirect()は、\Illuminate\Http\RedirectResponseのオブジェクトを返すからです。

さて、上のコントローラを変更して、以下のように条件文を新規のメソッドに移します。現在の条件は簡単だけれど将来はたいそう複雑になるぞ、という仮定です。

... class ProductController extends Controller { public function show(Product $product) { $this->checkProduct($product); // 条件文が複雑になるので新規の関数を作成 return view('user.product.show')->with(compact('product')); // 商品のページを表示 } private function checkProduct($product) { if ($product->active_flag == 'N') { // 無効な商品なら、 return redirect('home'); // ホームページにリダイレクト } } }
一見たわいもない変更ですが、これを実行すると、なんと無効である商品の表示ページが表示されます。ホームページにリダイレクトはされません。問題は、checkProduct()がRedirectResponseを返すのに、コールした側でreturnが使用されていないからなのですね。

しかし、

... class ProductController extends Controller { public function show(Product $product) { return $this->checkProduct($product); return view('user.product.show')->with(compact('product')); // 商品のページを表示 ...
こうすると、商品が有効なときもそこでリターンするために商品のページが表示されずに問題です。さてさて、どうしたらよいでしょう？

ということで、あれこれ調べていたら、abort()を使用してリダイレクトが可能なことがわかりました。以下のように、abort()の引数に404のようなHttpステータスのコードの代わりにredirect()を渡すことが可能なのです。以下が変更後のコードです。素晴らしい！

... class ProductController extends Controller { public function show(Product $product) { $this->checkProduct($product); // 条件文が複雑になるので新規の関数を作成 return view('user.product.show')->with(compact('product')); // 商品のページを表示 } private function checkProduct($product) { if ($product->active_flag == 'N') { // 無効な商品なら、 abort(redirect('home')); // ホームページにリダイレクト } } }

ダウンロードファイル名禁止文字に対応

Sun, 14 Jun 2020 08:58:25 +0900

Windows 10では、ファイル名として使用してはいけない文字がいくつかあります。入力しようとすると、「ファイル名に次の文字は使えません」とエラーになります。さて、ダウンロードのファイルにこれらの禁止文字が使用されていたらどうしましょう？

例えば、サーバーにアップされているファイル名は「567.jpg」と商品ID.jpgのフォーマットとします。しかし、ユーザーがダウンロードする時には「世界一おいしい? りんご、4/1から販売.jpg」と商品名.jpgにしたいときです。しかし、商品名に含まれる、?（半角疑問符）や/（半角バックスラッシュ）が禁止文字なのです。

手っ取り早いのは、半角の禁止文字を皆全角に置き換えてしまえばよいです。

ということでヘルパーの関数を作成します。

app/Helpers/MyHelper.php

namespace App\Helpers; class MyHelper { /** * 禁止半角文字を全角に * @param string $value * @return string */ public static function convertToValidFilename($value) { $from = ['\\', '/', ':', '*', '?', '"', '>', '<', '|']; $to = ['￥', '／', '：', '＊', '？', '”', '＞', '＜', '｜']; $patterns = array_map(function($val) { return '#\\'.$val.'#'; }, $from); return preg_replace($patterns, $to, $value); } }
preg_replace()の最初の引数に、その前の行のarray_map()で作成された配列を与えているところに注意してください。

通常は、

>>> preg_replace('/123/', 'xyz', '01234'); => "0xyz4"
のように、パターンには/（半角スラッシュ）で囲んだ文字列を与えますが、配列を与えて複数の置き換えをすべて実行することもできます。

convertToValidFilename()では、$patternsが以下のような配列となり、

Array ( [0] => #\\# [1] => #\/# [2] => #\:# [3] => #\*# [4] => #\?# [5] => #\"# [6] => #\># [7] => #\<# [8] => #\|# )
これらは、以下の対応する$toに、

Array ( [0] => \ [1] => / [2] => : [3] => * [4] => ? [5] => " [6] => > [7] => < [8] => | )
に置き換えます。

パターンにおいて、通常使われる/（半角バックスラッシュ）の代わりに、#（半角シャープ）で囲まれているのは、/（半角バックスラッシュ）がパターン内の文字としてありエスケープ文字となってしまうからです。preg_replace()のパターンの境界文字は、そのように必要に応じて変えることができるのです。

早速、tinkerを使用して試してみましょう。

>>> use App\Helpers\MyHelper; >>> MyHelper::convertToValidFileName('世界一おいしい? りんご、4/1から販売.jpg'); => "世界一おいしい？りんご、4／1から販売.jpg"
禁止文字が半角から全角に置き換わりましたね。

最後に、これを用いたコントローラのダウンロードメソッドは、こんな感じとなります。

public function download(Product $product) { Storage::download(storage_path().'/'.$product->product-id.'.jpg', MyHelper::convertToValidFileName($product->name).'jpg'); }

ステージングサイトとアナリティクス

Mon, 15 Jul 2019 07:26:08 +0900

もちろんのことなのですが、私のお客さんのプロジェクトは皆パブリックでアクセスできる開発サイトがあります。そこで開発をするわけでなく、あくまでも本サイトにインストールする前に変更をお客さんに見てもらい使ってもらい、フィードバックをもらうためのサイトです。その意味では、ステージングサイトと言った方が正しいですね（お客さんとの間では開発サイトと呼んでいます）。

本サイトと違う部分
本サイトとステージングサイトの環境はシステムレベルではまったく同じで、OSもPHPもMySqlのバージョンなどすべて同じです。違うのは使用しているAWSのEC2のスケールで、ステージングにはもちろん安いインスタンスを使用しています。
プログラムレベルでは、Laravelの.envの中身。データベースの接続情報やメールの宛先とか、その他たくさん。しかし、この.envのおかげでステージングの設定は非常に簡単になりました。

それ以外にも、ずっと昔にどういうわけか間違ってステージングサイトで買い物をする本物のお客さんが出てきたので、サイトには必ず、ベーシック認証、そうあのポップアップの認証、をかけて保護しています。以下はサンプルですが、Laravelのための.htaccessを編集しています。

.htaccess

<IfModule mod_rewrite.c> # 以下4行はベーシック認証。ステージングのみ。パスワードは/etc/httpd/.htpasswdに保存。 AuthType Basic AuthName "Password Protected Area" AuthUserFile .htpasswd Require valid-user <IfModule mod_negotiation.c> Options -MultiViews </IfModule> RewriteEngine On # Redirect Trailing Slashes... RewriteRule ^(.*)/$ /$1 [L,R=301] # Handle Front Controller... RewriteCond %{REQUEST_FILENAME} !/assets RewriteCond %{REQUEST_FILENAME} !/server-status RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^ index.php [L] </IfModule>
アナリティクス

ステージングではもう１つ重要な違いがあります。ブレードに埋め込んでいるアナリティクスの情報です。

最近までは、以下のように、.envのAPP_ENV=productionの時だけレンダーするように、ブレードには @if (config(‘app.env’) == ‘production’)の条件文を使用していました。

... @if (config('app.env') == 'production')  <script async src="https://www.googletagmanager.com/gtag/js?id=UA-123456-1"></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-123456-1'); </script> @endif ...
しかし、アナリティクスも複雑になってきて、グーグルタグマネージャも使用し始めたので、アナリティクスも開発のために本サイトとは違うアカウントあるいはプロパティを作成して本サイトと分ける必要が出てきました。となると、トラッキングID（上では、UA-123456-1）が本サイトとステージングサイトでは異なることになります。

トラッキングIDの値は、以下のように.envで簡単に設定することにします。

.env

... GA=UA-123456-1 GTM=GTM-XYZ
GAはアナリティクスのトラッキングIDで、GTMはタグマネージャのコンテナIDです。

さらに、config/local.phpを作成します。

config/local.php

<?php return [ 'ga' => env('GA'), 'gtm' => env('GTM'), ];
そして、ブレードでは、

...  <script async src="https://www.googletagmanager.com/gtag/js?id={{ config('local.ga') }}"></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', '{{ config('local.ga') }}'); </script> ...
とします。もう、@ifの条件文はもう必要でないので削除されていることに注意してください。

これで、本サイトであろうとステージングサイトであろうと、.envによりアナリティクスのIDを変更することができます。

Laravel 5.8に更新

Mon, 24 Jun 2019 02:54:22 +0900

Laravel 5.7の更新を終えて、次は最新の5.8への更新です。こちらも私が経験したことをもとに、いくつかの重要な更新箇所をここで説明です。

ヘルパーの変更

以下は5.6の時点でのLaravelで使用できるヘルパーの一部です。

そして、以下が5.8(現時点の5.7でも）時点でのヘルパーです。

配列や文字列処理の関数が変わりましたね。

Psy Shell v0.9.9 (PHP 7.2.16 — cli) by Justin Hileman >>> $pen = ['color' => 'red']; => [ "color" => "red", ] >>> array_get($pen, 'color'); => "red" >>> Arr::get($pen, 'color'); => "red"
と今までのグローバルの関数ではなくネームスペース（Arr, Str）を使用しての関数に変わります。賛否両論があるようですが、幸いにも、5.8では両方の形態を対応しています。しかし、5.9からはArrやStrの関数に対応するグローバル関数は廃止となる予定です。

私は、Laravel Shiftのサービスをバージョン更新の最初のステップとして使用しているので、必要なクラスの宣言やヘルパーの変換はすべて、その更新サービス（有料）が行ってくれました。

変換した後に、１つ問題となったのは、エラーチェックに使用しているphanの出力です。phanはコード解析をして、プログラムにおいての疑わしい問題個所をリストしてくれます。変更後のコードでは、以下のような関数未定義のエラーがたくさん出ました。

... -app/Helpers/Lob.php:517 PhanUndeclaredStaticMethod Static call to undeclared method \Illuminate\Support\Arr::first -app/Helpers/Lob.php:691 PhanUndeclaredStaticMethod Static call to undeclared method \Illuminate\Support\Arr::get -app/Helpers/Lob.php:728 PhanUndeclaredStaticMethod Static call to undeclared method \Illuminate\Support\Arr::get ...
これは、phanをLaravelのプロジェクトで使用できるために使っている_ide helper.phpの問題のようです。

_ide_helper.php

... namespace Illuminate\Support { /** * * */ class Arr { } /** * * */ class Str { } } ...
の部分を削除すれば、上のようなエラーを余計な吐き出すことはないです（参照）。

Cacheの時間単位の変更

こちらの変更は、Cache関連の関数を使用している開発者には大ごとです。キャッシュの保持時間の単位が今までの分単位から、より細かい時間を指定するために秒単位に変わります。

// Laravel 5.7 - 30分データを保持から、 Cache::put('foo', 'bar', 30); // Laravel 5.8 - 30秒データ保持に変わる Cache::put('foo', 'bar', 30); // 30分をキープしたいなら、 Cache::put('foo', 'bar', 30 * 60);

未定義のキーや属性をチェック

Tue, 16 Oct 2018 03:01:51 +0900

開発をしていて、未定義のキーや属性でのアクセスエラーは誰しも経験します。

配列のキー(price)が未定義なら、

>>> $p1 = ['name' => 'apple']; => [ "name" => "apple", ] >>> $p1['name']; => "apple" >>> $p1['price']; PHP Notice: Undefined index: price in Psy Shell code on line 1
オブジェクトの属性(price)が未定義なら、

>>> $p2 = (object)['name' => 'apple']; => {#2318 +"name": "apple", } >>> $p2->name; => "apple" >>> $p2->price; PHP Notice: Undefined property: stdClass::$price in Psy Shell code on line 1
なんのことはない、このような場合は、未定義のpriceを初期化してあげればよいですね。

しかし、この初期化、都合によってはできないときあります。画面のフォームにおいて条件によりpriceの入力をするときと、しないときがあるとか。

そのときには、isset()の関数を使用して、キーや属性が定義されているかどうかをチェックします。

>>> isset($p1['name']); => true >>> isset($p1['price']); => false >>> isset($p2['name']); => true >>> isset($p2->price); => false
そして、未定義のエラーを出さずにデフォルトの値を割り当てたいなら、三項演算子を利用します。

>>> $name = isset($p1['name']) ? $p1['name'] : ''; => "apple" >>> $price = isset($p1['price']) ? $p1['price'] : 0; => 0 >>> $name = isset($p2->name) ? $p2->name : ''; => "apple" >>> $price = isset($p2->price) ? $p2->price : 0; => ""
繰り返しの記述が面倒なら、Laravelでは便利なヘルパーあります：array_get(), data_get()

>>> $name = array_get($p1, 'name', ''); => "apple" >>> $price = array_get($p1, 'price', 0); => 0 >>> $name = data_get($p2, 'name', ''); => "apple" >>> $price = data_get($p2, 'price', 0); => 0
そして、php7なら、Null合体演算子を利用しても同様なことができます。

>>> $name = $p1['name'] ?? ''; => "apple" >>> $price = $p1['price'] ?? 0; => 0 >>> $name = $p2->name ?? ''; => "apple" >>> $price = $p2->price ?? 0; => 0