What's New Qiita

20200820のlaravelに関する記事は6件です。

  • 投稿日：2020-08-20T21:55:00+09:00

DockerでGD Libraryのエラー対応

LaravelをローカルのDockerで動かしていて、
画像の圧縮しようとしたときにつまずいたのでメモ。

エラー

GD Library extension not available with this PHP installation.

PHPのGDライブラリが使用できないらしい。
早速Dockerfileを編集

結論だけ言うと、このようなDockerfileになりました

FROM php:7.4-fpm
COPY php.ini /usr/local/etc/php/

RUN apt-get update \
  && apt-get install -y wget git unzip libzip-dev libpq-dev libfreetype6-dev libjpeg62-turbo-dev libpng-dev \
  && docker-php-ext-install zip pdo_mysql \
  && docker-php-ext-configure gd --with-freetype --with-jpeg \
  && docker-php-ext-install -j$(nproc) gd

#Composer install
COPY --from=composer /usr/bin/composer /usr/bin/composer

ENV COMPOSER_ALLOW_SUPERUSER 1

ENV COMPOSER_HOME /composer

ENV PATH $PATH:/composer/vendor/bin


WORKDIR /var/www

RUN composer global require "laravel/installer"

Dockerfileの変更を反映

イメージ：再構築の必要あり：docker-compose build
コンテナ：再構築の必要あり：docker-compose up -d

無事にエラーが出なくなりました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-20T15:16:05+09:00

Laravelのpaginationで取得したcollectionデータの更新方法

Laravelのpaginationで取得したデータは特殊なcollectionクラスであるため、
新しいcollectionクラスを返すfilterやmapのような操作では要素が更新できません。

$articles->getCollection()->transform(
            function ($article, $key) {
                 //操作
               return $article;
            }
        );

のようにgetCollectionを使ってからtransformで変形することが必要です。

ここで、注意しなくてはいけないのは、articleの下にさらにcollectionがネストしている場合[1]も、
新しいcollectionクラスを返す操作ではそのcollectionクラスが更新できないという点です。

その場合はgetCollectionなしのtransformで更新できますが、
要素を削除する場合はunset等の新しいcollectionを返さないで削除できる手段を用いる必要があります。

ただこれネストしているのでもっといい方法あるかもしれないけど

//articleの下にhashtagがネストしている
$articles->getCollection()->transform(
            function ($article, $key) {
                $article["tags"]->transform(function($tag,$key){
                        //タグ更新の場合。ちなみにここで何もreturnしなかった場合、nullが代入される。
                        return $tag;
                }

                //要素削除の場合
                foreach($article["tags"] as $key=>$tag){
                    //条件を入れる。ここは例えばタグの名前がtestの場合
                    if(($tag["name"]==='test')){
                        //条件に合致したものをunset
                        unset($article["hashtags"][$key]);
                    }
                }

                return $article;
            }
        );

[1]元データがModelでwith等を使ってクエリを作っている場合等。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-20T14:37:27+09:00

Herokuを使って開発アプリを本番環境へデプロイする

開発環境

  • PHP 7.2
  • Laravel 5.6
  • MySQL 5.7
  • Docker
  • Nginx

おさえておきたい料金体系

基本無料。
クレカ登録をすると稼働時間の増加以外にもアドオンの追加が可能になる。

Freeプランではいくつか機能制限があります。

アカウント毎に、アプリケーションは月に550時間までの稼働時間が割り当てられる
アカウントにクレジットカードを紐付けると1000時間に増える
公開しているアプリケーションに30分間アクセスがないと、スリープモードに移行する

有料プランになると上記制限がすべてなくなる（$25/月〜）

詳細はこちら

デプロイ方法

イメージ：gitのherokuリポジトリを本番環境へデプロイするだけ

0. Herokuアカウントの登録

（アカウントをもっていればスルーで）
以下ページよりアカウントを作成する
Heroku公式より

1.HerokuCLIをローカル環境にインストールする

Herokuを使うにはHeroku CLIというアプリケーションをローカル環境にインストールする必要がある。
これをインストールすることでgitを使ってデプロイが可能になる。

sudo snap install --classic heroku

※上記コマンドはLinux系のUbuntuコマンドなため各自環境に沿ったコマンドを実施する必要あり詳細は公式で確認

2. Herokuへログイン

ローカル環境で以下コマンドを入力しHerokuへログインする

heroku login -i

Enter your Heroku credentials.
Email: Herokuに登録したメールアドレスを入力
Password: Herokuに登録したパスワードを入力

Logged in as 登録したメールアドレス   //ログイン完了

3.Herokuアプリケーションの作成

デプロイしたいアプリケーションのプロジェクト直下にて下記コマンドを実行。

heroku create アプリケーション名

アプリケーション名がhttps://Herokuアプリケーション名.herokuapp.com/とドメイン名になります 

Creating ⬢ example.app.. !
 ▸    Name example.app is already taken

heroku appsコマンドで作成したアプリが確認できれば作成完了

4.リモートリポジトリherokuの確認

念の為git 環境にherokuリモートリポジトリがあるか確認

git remote -v

5.Heroku設定ファイルの新規作成

プロジェクトルート直下に以下コマンドでProcfileを作成する

echo "web: vendor/bin/heroku-php-nginx -C nginx.conf public/" > Procfile

Procfileが以下のようになっているか確認

web: vendor/bin/heroku-php-nginx -C nginx.conf public/

※今回はNginxサーバーですがapacheの場合は

echo "web: vendor/bin/heroku-php-apache2 public/" > Procfile

で作成

Procfileを作業ブランチにコミット&プッシュし、ローカルmasterブランチへマージ

6.本番環境へデプロイする

いよいよデプロイといってもデプロイしたいmasterブランチへ移動して下記のコマンドを実行するだけ

git push heroku master

1分ほど待ち、下記の表記がでればデプロイ完了

remote: Verifying deploy... done.

このままだとURLにアクセスしてもエラーが出るので後ほど環境変数を設定する

URLを叩いて以下のエラーが出たら・・・

  • There's nothing here, yet. ブランチへ入力したURLが間違っている可能性があります。スペルミスを確認しましょう
  • Forbidden Procfileの設定が原因の可能性があります。こちらもスペースやスペルミス、masterブランチにProcfileがあるかを確認しましょう。

7.MySQLの導入

Herokuには複数のadd-onが用意されており、MySQLを使うための ClearDB MySQL をインストールする必要がある。
下記コマンドを実行。

heroku addons:create cleardb:ignite

これでFreeプランのMySQLが追加される。

以下のエラーが出た場合はアカウントにクレジットカードの登録が必要

▸    Please verify your account to install this add-on plan (please enter a credit card) For more
▸    information, see https://devcenter.heroku.com/categories/billing Verify now at
▸    https://heroku.com/verify

あとは環境変数を設定するだけ

環境変数の設定

.envはgitignoreされているためherokuリポジトリには反映されません。
heroku環境に環境変数を直接設定する必要があります。

  • 設定コマンド heroku config:set 環境変数名=キー
  • 確認コマンド heroku config

APP_KEYの設定

DockerPHPコンテナ内プロジェクトルート直下で

$ php artisan key:generate --show

内容をコピーしてローカル環境プロジェクトルート直下で下記コマンドを入力

heroku config:set APP_KEY=base64:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

設定した APP_KEY が設定されていればOK。

MySQLの設定

heroku configで環境変数を確認。
cleardbのadd-onを追加しているためCLEARDB_DATABASE_URL:という環境変数が自動で設定されている。

CLEARDB_DATABASE_URL:  mysql://<ユーザー名>:<パスワード>@<ホスト名>/<データベース名>?reconnect=true

これをもとに各環境変数を設定

$ heroku config:set DB_CONNECTION=mysql
$ heroku config:set DB_DATABASE='<データベース名>'
$ heroku config:set DB_USERNAME='<ユーザー名>'
$ heroku config:set DB_PASSWORD='<パスワード>'
$ heroku config:set DB_HOSTNAME='<ホスト名>'
$ heroku config:set DB_PORT='3306'

その他の環境変数

APP_URL

$ heroku config set:https://アプリケーション名.herokuapp.com

slack認証系

SLACK_KEY=ローカル環境の`.env`の記述と同じ
SLACK_REDIRECT_URI=ローカル環境の`.env`の記述と同じ
SLACK_SECRET=ローカル環境の`.env`の記述と同じ

S3系

AWS_ACCESS_KEY_ID=ローカル環境の`.env`の記述と同じ
AWS_BUCKET=ローカル環境の`.env`の記述と同じ
AWS_DEFAULT_REGION=ローカル環境の`.env`の記述と同じ
AWS_SECRET_ACCESS_KEY=ローカル環境の`.env`の記述と同じ

その他の設定方法

Herokuのビルドに関する設定

buildpackを追加する

  • Herokuダッシュボード内の上部メニューのSettingsを選択

  • Add buildpackの選択

  • node.jsの選択

  • Save changesで完了

  • PHPの選択

  • Save changesで完了

* heroku/nodejs
* heroku/php

が表示されれば、buildpackの追加は完了

データベースのマイグレーション

Herokuからデータベース(MySql)に接続できるよう設定済みですが、まだテーブルを作成していません。
そこで、Laravelのマイグレーションコマンドを使ってテーブルを作成します。
以下コマンドを実行してください。

$ heroku run php artisan migrate —seed

heroku run (実行したいコマンド)で、Heroku上でコマンドを実行できます。
コマンドを実行すると、以下が表示されるので、yesと入力してエンターキーを押してください。

Do you really wish to run this command? (yes/no) [no]:

以下のように各テーブルのマイグレーションが完了した旨のメッセージが表示されれば問題ありません。

Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table (0.1 seconds)
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table (0.04 seconds)

Mysql接続コマンド

mysql -h <DB_HOSTNAME> -u <DB_USERNAME> -p -D <DB_DATABASE>

作業内容を本番環境へ反映したいとき

ローカルのmasterブランチに変更内容を反映させgit push heroku masterをするだけ

Heroku環境内に入るコマンド

heroku run bash

共同開発者の追加

  • Heroku にログインし、任意のサービスを選択
  • 上部メニューのaccessを選択
  • Add collaboratorを押下し、共同開発者のアカウントのメールアドレスを入力後、save changeを押下
  • 招待者のメールアドレスが追加されていることを確認
  • 招待者はメールの案内に沿ってHerokuにアクセス

これでデプロイやHeroku環境系の操作が可能になります。

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-20T14:27:02+09:00

【Laravel】ユーザ認証/ユニットテスト

こちらの記事は以下の書籍を参考にアウトプットとして執筆しました。
PHPフレームワーク Laravel入門 第2版

ユーザ認証

Laravel標準装備の認証機能「Auth」について

ユーザ認証は以下の機能のこという

  • ユーザ登録
  • ログイン、ログアウト
  • ユーザ情報の管理などのホーム画面
  • ログインしていないユーザのアクセス制限
  • 現在のユーザのログイン状態などを調べるプログラム

これらの機能はLaravelのAuthクラスを使うと一括で実装できる。

Authのセットアップ

Auth機能はLaravelに標準で要されておらず、以下の2つのインストールが必要

名前 説明
laravel/ui composerでインストール
npm Node.jsをインストール

インストール手順は省略

Userモデルクラス

AuthはDBにusersテーブルを作り、そこにユーザ情報を保存する。

Authの各種メソッド

Auth::user

ログインしているユーザのモデルインスタンス(Usersモデルクラス)を返す。
ログインしていなければnullが返る

Auth::check

現在アクセスしているユーザがログインしているかどうかを確認

返り値 意味
true ログインしている
false ログインしていない

ログインページ

ログインページはAuthが自動生成する。

ユニットテスト

テスト機能の基本となる

ユニットテスト

アプリ開発におけるプログラムの正常性確認をユニットテストという。
単体テストとも呼ばれ、PHPUnitを利用してテストする。

ユニットテストではテストのスクリプトファイを生成、しそこにテスト内容を書く。
ExampleTest.phpを参考にテスト処理を生成する。

クラス名は冒頭にtestが入っていればいい

テスト用DBを用意する

本番のDBをテストに使用するのは危険
テスト用のDBを作成しておく。

その後ダミーレコードなどを入れておく。

phpunit.xml

PHPUnitの設定に使用するDBを追記する
SQLiteはファイルパス、MySQLはDB名でOK

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-20T12:44:39+09:00

Laravel で vendor 配下のファイル操作ライブラリ Filesystem（Flysystem） を拡張する方法

こんにちは、しょいみんです。
Laravel フレームワーク内の処理で詰まったところがあったので知見を共有していきますm(_ _)m

概要

Laravel フレームワークはフレームワーク自体に様々なオープンソースのライブラリが含まれているため、それほどプラスα でライブラリをインストールすることなく簡単に開発できるようになっています。

しかし、開発を進めていくと「既存のライブラリだと少し物足りないなぁ」、「既存のライブラリを少しだけ拡張したいなぁ」といった要望が出てくると思います。

今回は、Laravel で標準インストールされている Flysystem のライブラリを拡張する方法を紹介いたします。この方法を利用すれば Flysystem に限らず Laravel 内の他のライブラリも同様に拡張することができます。

結論

サービスプロバイダーを既存のクラスから自分で定義したクラスに切り替えることでどんなライブラリでも自分で定義したクラスに差し替えて呼び出すことができます！！！！！

拡張したい関数だけ修正して他の処理は元のライブラリの処理のままコピペすることで既存の処理を壊さずに拡張したい関数だけ修正することができます。

環境

Laravel 5.8
php7.4.5
※検証してませんが Laravel 6, 7 でもサービスプロバイダーの考え方は一緒なので同様の方法で実現できると思います。

目標（拡張したい処理の内容）

画像一覧を取得する関数がデフォルトでファイル名ソートしかできないので任意のメタ情報で昇順・降順ソートできるように関数を拡張します

拡張前の元ファイルと関数

下記ライブラリの関数を修正します。
見ての通りオプションもなくファイルパスでしかソートできないですね (´・ω・｀)
vendor/league/flysystem/src/Util/ContentListingFormatter.php

ContentListingFormatter.php
class ContentListingFormatter
{
・・・・・省略・・・・・・

    /**
     * @param array $listing
     *
     * @return array
     */
    private function sortListing(array $listing)
    {
        usort($listing, function ($a, $b) {
            return strcasecmp($a['path'], $b['path']);
        });

        return $listing;
    }
}

拡張後のファイルと関数

拡張後のファイルと関数の内容です。
ファイルパスでしかソートできなかった sortListing() 関数を任意のメタ情報と昇順・降順フラグを引数にとって並び替えできるように拡張します。

app/Extensions/Flysystem/Util/ContentListingFormatter.php

ContentListingFormatter.php
class ContentListingFormatter
{
・・・・・省略・・・・・・

    /**
     * @param array $listing
     * @param string $sortType
     * @param bool $isAsc
     *
     * @return array
     */
    private function sortListing(array $listing, string $key = 'path', $isAsc = true)
    {
        usort($listing, function ($a, $b) use ($key, $isAsc) {
            $result = $isAsc ? strcasecmp($a[$key], $b[$key]) : strcasecmp($b[$key], $a[$key]);
            return $result;
        });

        return $listing;
    }
}

修正手順

修正手順です。この３つの手順に沿って修正手順を解説していきます。

  1. 拡張したい関数が記述されてるクラスとそのクラスを呼び出しているクラスをコピペして新しく作成
  2. 関数の修正やネームスペース、呼び出しクラスの参照パスを修正
  3. サービスプロバイダー（FilesystemServiceProvider::class）の切り替え

新しく作成するファイル一覧

下記ファイルパスの vendor 配下のライブラリのコードをコピー元として新規作成します。
修正箇所は後述します。

元ファイルと新規作成ファイル
# league/flysystem ライブラリ
コピー元：  vendor/league/flysystem/src/Filesystem.php
新規作成： app/Extensions/Flysystem/Filesystem.php

コピー元：  vendor/league/flysystem/src/Util/ContentListingFormatter.php
新規作成： app/Extensions/Flysystem/Util/ContentListingFormatter.php

# Laravel 標準フレームワーク内の ファイルシステム 
コピー元：  vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemManager.php
新規作成： app/Extensions/Flysystem/FilesystemManager.php

# Laravel 標準フレームワーク内の サービスプロバイダー
コピー元：  vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemServiceProvider.php
新規作成： app/Providers/FilesystemServiceProvider.php

※ 新規作成するファイルの保存ディレクトリはどこでもいいですが Extensions に格納することとします。
※ サービスプロバイダーは Providers フォルダに格納することとします。

1. 拡張したい関数が記述されてるクラスとそのクラスを呼び出しているクラスをコピペして新しく作成

ContentListingFormatter.php を自身で定義したクラスに差し替えるために必要なファイルをすべてコピペします。
新規作成するファイルは上記の 「元ファイルと新規作成ファイル」 で記載されている 4 ファイルです。
Laravel のファイルシステム実行処理の関係で修正が必要なクラスファイルが増えています。
下記に画像一覧を表示させるための処理の流れを記述しておきます。

  1. config/app.php に記載されている FilesystemServiceProvider.php が呼び出される
  2. FilesystemServiceProvider.php の registerManager() がエイリアス 'filesystem' で FilesystemManagerインスタンスを作成する。
  3. FilesystemManager.php の createFlysystem() 関数で Flysystem のインスタンスを返す。
  4. Flysystem.php の listContents() 関数で ContentListingFormatterのインスタンスのformatListing() 関数を実行する。
  5. ContentListingFormatter.php の formatListing() 関数内でソートの関数である $this->sortListing() が実行される。　← 今回はここの関数の処理を改造します。

流れを確認したことで、5番で利用されている ContentListingFormatter.php を自身で定義したクラスに差し替えるために 1 ~ 4 で呼び出されているクラスファイルの参照パスを修正する必要があることがわかります。

2. 関数の修正とネームスペース、呼び出しクラスの参照パスを修正

次にコピペして新規作成したファイルを一つずつ修正していきます。

ContentListingFormatter.php

app/Extensions/Flysystem/Util/ContentListingFormatter.php
<?php

namespace app\Extensions\Flysystem\Util;
# namespace League\Flysystem\Util;

use League\Flysystem\Util;

/**
 * @internal
 */
class ContentListingFormatter
{

--------- 途中 vendor と同じなので省略 ---------

    /**
     * @param array $listing
     * @param string $sortType
     * @param bool $isAsc
     *
     * @return array
     */
#    private function sortListing(array $listing)
    private function sortListing(array $listing, string $key = 'path', $isAsc = true)
    {
        usort($listing, function ($a, $b) use ($key, $isAsc) {
            $result = $isAsc ? strcasecmp($a[$key], $b[$key]) : strcasecmp($b[$key], $a[$key]);
            return $result;
        });

#        usort($listing, function ($a, $b) {
#            return strcasecmp($a['path'], $b['path']);
#        });
        return $listing;
    }
}

ContentListingFormatter.php では拡張したい関数を修正し namespace を app フォルダ配下のパスに修正します。

それ以外のコードは元ファイルのコピペをそのまま利用します。

Filesystem.php

app/Extensions/Flysystem/Filesystem.php
<?php

# namespace League\Flysystem;
namespace app\Extensions\Flysystem;

use InvalidArgumentException;
use League\Flysystem\Adapter\CanOverwriteFiles;
use League\Flysystem\Plugin\PluggableTrait;
# use League\Flysystem\Util\ContentListingFormatter;
use League\Flysystem\FilesystemInterface; # 追記
use League\Flysystem\ConfigAwareTrait; # 追記
use League\Flysystem\AdapterInterface; # 追記
use League\Flysystem\File; # 追記
use League\Flysystem\Directory; # 追記
use League\Flysystem\Handler; # 追記
use League\Flysystem\Util; # 追記
use League\Flysystem\Config; # 追記
use League\Flysystem\FileNotFoundException; # 追記
use League\Flysystem\FileExistsException; # 追記
use League\Flysystem\RootViolationException; # 追記
use App\Extensions\Flysystem\Util\ContentListingFormatter; # 追記
--------- 以下 vendor と同じなので省略 ---------

Filesystem.php では namespace と Filesystem.php 内で利用してるクラスを use 文で参照させます。

もともと vendor 配下の Filesystem.php では同ディレクトリに他のクラスファイルの php が配置されていたので直で参照されていました。今回は app フォルダ配下に Filesystem.php を新規作成したので vendor 配下のクラスファイルをしっかりと use 文で参照させています。

また、
use League\Flysystem\Util\ContentListingFormatter; は vendor 配下のクラスファイルを参照してるのでコメントアウトし、今回自分で作成したファイル
use App\Extensions\Flysystem\Util\ContentListingFormatter;
に参照させ直します。

FilesystemManager.php

app/Extensions/Flysystem/FilesystemManager.php
<?php

# namespace Illuminate\Filesystem;
namespace app\Extensions\Flysystem;

use Closure;
use Aws\S3\S3Client;
use OpenCloud\Rackspace;
use Illuminate\Support\Arr;
use InvalidArgumentException;
use League\Flysystem\AdapterInterface;
use League\Flysystem\Sftp\SftpAdapter;
use League\Flysystem\FilesystemInterface;
use League\Flysystem\Cached\CachedAdapter;
# use League\Flysystem\Filesystem as Flysystem;
use App\Extensions\Flysystem\Filesystem as Flysystem; # 追記
use League\Flysystem\Adapter\Ftp as FtpAdapter;
use League\Flysystem\Rackspace\RackspaceAdapter;
use League\Flysystem\Adapter\Local as LocalAdapter;
use League\Flysystem\AwsS3v3\AwsS3Adapter as S3Adapter;
use League\Flysystem\Cached\Storage\Memory as MemoryStore;
use Illuminate\Contracts\Filesystem\Factory as FactoryContract;
use Illuminate\Filesystem\FilesystemAdapter; # 追記
--------- 以下 vendor と同じなので省略 ---------

こちらも同様 namespace と参照している vendor 配下の Filesystem.php の参照先を自分で作成した app 配下の Filesystem.php に参照させ直しています。

FilesystemServiceProvider.php

app/Providers/FilesystemServiceProvider.php
<?php

# namespace Illuminate\Filesystem;
namespace App\Providers; # 追記

use Illuminate\Support\ServiceProvider;
use Illuminate\Filesystem\Filesystem; # 追記
use App\Extensions\Flysystem\FilesystemManager; # 追記
--------- 以下 vendor と同じなので省略 ---------

Filesystem のサービスプロバイダーです。 config/app.php から呼び出されるやつですね。
こちらも同様、namespace と FilesystemManager.php の参照パスを修正し、参照が切れてしまっているクラスファイルを参照させ直しましょう。

以上で、新規作成したファイルの修正が完了となります。
最後にサービスプロバイダーの切り替えを行いましょう。

3. サービスプロバイダー（FilesystemServiceProvider::class）の切り替え

既存のファイルシステムサービスプロバイダーを自身で作成したサービスプロバイダーに切り替えて変更を反映させます。

app.php

config/app.php
<?php

return [
    /*
    |--------------------------------------------------------------------------
    | Autoloaded Service Providers
    |--------------------------------------------------------------------------
    |
    | The service providers listed here will be automatically loaded on the
    | request to your application. Feel free to add your own services to
    | this array to grant expanded functionality to your applications.
    |
    */

    'providers' => [

        /*
         * Laravel Framework Service Providers...
         */
        Illuminate\Auth\AuthServiceProvider::class,
        Illuminate\Broadcasting\BroadcastServiceProvider::class,
        Illuminate\Bus\BusServiceProvider::class,
        Illuminate\Cache\CacheServiceProvider::class,
        Illuminate\Foundation\Providers\ConsoleSupportServiceProvider::class,
        Illuminate\Cookie\CookieServiceProvider::class,
        Illuminate\Database\DatabaseServiceProvider::class,
        Illuminate\Encryption\EncryptionServiceProvider::class,
        // 既存の Filesystem ではなくソートのコードを拡張した Filesystem を利用するため
        // Illuminate\Filesystem\FilesystemServiceProvider::class,
        App\Providers\FilesystemServiceProvider::class, # 追記

----------- 以下略 -------------
    ],
];

config/app.php ファイルを開けて、'providers' 配列を見てみましょう。
既存のファイルシステムサービスプロバイダーであるIlluminate\Filesystem\FilesystemServiceProvider::class
クラスが記述されています。

ここを自身で作成した、
App\Providers\FilesystemServiceProvider::class
に変更します。

以上ですべての修正が完了です。あとはオートローダのリロードを行うと反映されます。

composer dump-autoload

まとめ

Laravel ではサービスプロバイダーの切り替えで vendor 配下のライブラリですら自身で定義したクラスファイルに切り替えできることがわかりました。

切り替えの手順は ３ ステップ

  1. 拡張したい関数が記述されてるクラスとそのクラスを呼び出しているクラスをコピペして新しく作成
  2. 関数の修正やネームスペース、呼び出しクラスの参照パスを修正
  3. サービスプロバイダー（FilesystemServiceProvider::class）の切り替え

これで vendor 配下を汚さずに拡張できるのでもし要件があったら参考にしてみてくださいm(_ _)m。

ただし、自身で拡張したクラスファイル（ここの場合は Filesystem.php、ContentListingFormatter.php、FilesystemManager.php、FilesystemServiceProvider.php の4ファイル） は composer でのライブラリアップデートには追随しないことに注意してください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-08-20T00:59:36+09:00

【Xdebug】VSCODE+PHP Laravel+Windows+Xamppでデバッグ実行

環境

Windows10 x64
VisualStudio Code 1.47.3
Xampp v3.2.4 (PHP 7.4.7)
VSCODEプラグイン PHP Debug v1.13.0(本記事でインストール～設定します)

Xdebugインストールと設定

①VSCODEでPHP Debugをインストール

image.png

②php.iniに下記を追記

※ C:\xampp\php\ext\php_xdebug.dllが存在しているか確認してください

C:\xampp\php.ini
zend_extension = "C:\xampp\php\ext\php_xdebug.dll"
[XDebug]
xdebug.remote_autostart = 1
xdebug.profiler_append = 0
xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 0
xdebug.profiler_output_dir = "c:\xampp\tmp"
xdebug.remote_enable = 1
xdebug.remote_handler = "dbgp"
xdebug.remote_host = "127.0.0.1"
xdebug.remote_log="c:\xampp\tmp\xdebug.txt"
xdebug.remote_port = 9000
xdebug.trace_output_dir = "c:\xampp\tmp"
xdebug.remote_cookie_expire_time = 36000

③「上部メニュー→実行→構成を追加」からlaunch.jsonを下記のようにする。

既に実行情報が記述されている場合は良い感じにマージする

launch.json
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000
        }
    ]
}

デバッグ実行してみる

①左メニュー→デバッグ(再生アイコンに虫が乗っているアイコン)を選択して、構成が「Listen for Xdebug」が選択されているのを確認

image.png

②あとはブレークポイントを仕掛けて「F5」でデバッグ実行

image.png

Laravelでも動作確認済み

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧