fopen()関数 概要 ファイルまたはURLを開く 返り値 成功時はファイルポインタリソース、失敗時はfalse fgetcsv()関数 概要 ファイルポインタから行を取得し、CSVフィールドを処理する 返り値 読み込んだフィールドを含む配列。取得できない場合はfalse
はじめに ・WordPress初心者の方 ・WordPressのテーマで、画像やCSSが反映さない方 テーマに、画像やCSSが反映されない理由 ・テーマファイルは、WordPressディレクトリの「wp-content/themes/~」に置くため、画像やCSSのファイルパスが切れて反映さません。なお、相対パスでも反映されないので注意が必要です。 ※画像とCSSファイルのパスと、WordPressで認識されるパスの詳細 画像、CSSのパス WordPressで認識されるパス wp-content/themes/自作テーマ/images/画像.jpg wordpress/images/画像.jpg wp-content/themes/自作テーマ/css/style.css wordpress/style.css テーマの画像と、CSSファイルのパスを修正 WordPressに認識されるパスを記述するには、WordPressの独自の関数であるget_template_directory_uri()を使用します。 get_template_directory_uri()は、使用しているテーマのディレクトリのURLを返します。パラメータはなしになります。有効化しているテンプレートのみに有効で、文末には/（スラッシュ）が付かないので注意が必要です。 WordPresの「style.css」について WordPressのテーマを使用する際は、必ずstyle.cssを作成してください。また、style.ccsを記述する際にはテーマの名前を必ず記述します。 ※以下を参考にしてください。 style.css /* Theme Name : ここにテーマの名前 */ /* ここに、CSSを記述 */ では、実際に簡単なテーマのサンプルコードを書いていきます。 サンプルコード ディレクトリ構成 ※画像のファイルパス wp-content/themes/qiita_wp01/images/wordpress.jpg ※CSSのファイルパス wp-content/themes/qiita_wp01/style.css index.php <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>WordPressパスの修正</title> <link rel="stylesheet" href="<?php echo get_template_directory_uri(); ?>/style.css"> </head> <body> <h1>WordPress</h1> <img src="<?php echo get_template_directory_uri(); ?>/images/wordpress.jpg"> </body> </html> style.css /* Theme Name : WordPress */ h1 { color: blue; text-align: center; } img { width: 100%; } まとめ ・WodPressで画像やCSSファイルのパスを修正する場合は、get_template_directory_uri()を使用。 ・テーマを作成する際には、必ずstyle.cssを作成する。 ・style.cssには、テーマの名前を必ず記述する。
問題 LaravelでAPIを作ってて、Sanctumを利用してユーザー認証を実装し、開発環境では動作しました。そこで検証環境に持って行ったところ「ログインは成功するが、そのあと認証が必要なAPIにアクセスすると『401 Unauthorized』エラーで弾かれる」という現象が発生しました。開発者ツールで見てもCookie等は正常に設定されているように見えますし、どこが問題なのか分かりません…… （私の場合の）原因 そもそも開発環境用の.envだけ設定してて、検証環境用の.envにSanctum周りの設定するの忘れてた 1を受けて設定したものの、.envのSANCTUM_STATEFUL_DOMAINSの記載が間違っていた 原因1に関しては「実装できた～✌」と完全に気が抜けてましたね……スーパーアホでした? 原因2に関してはDocker上で開発してて、雑にlocalhostで設定していても動いてしまっていたので、仕様をちゃんと理解できてなかったのが原因です。 調査 .envの反映し忘れの線はすぐに当たりましたが駄目で、ブラウザの開発者ツールで401しか出ず、Cookie周りも正常動作してるように見え、「（デプロイ自動化してないので）検証環境のライブラリ自体にロガー仕込むの面倒くさい」と、ググり倒したり設定弄り回したりあがいてみましたが駄目でした。 ただ調べる過程でこの記事を見かけて、どのクラスに仕込めばいいのか当たりがついたのでめちゃくちゃ助かりました? メソッド名から察しがつくかと思いますが、Webブラウザからのアクセス（Session使える）か、CLIアクセス（Session使えない）かの判定ですね。 // \vendor\laravel\sanctum\src\Http\Middleware\EnsureFrontendRequestsAreStateful.php public static function fromFrontend($request) { $domain = $request->headers->get('referer') ?: $request->headers->get('origin'); if (is_null($domain)) { return false; } $domain = Str::replaceFirst('https://', '', $domain); $domain = Str::replaceFirst('http://', '', $domain); $domain = Str::endsWith($domain, '/') ? $domain : "{$domain}/"; $stateful = array_filter(config('sanctum.stateful', [])); return Str::is(Collection::make($stateful)->map(function ($uri) { return trim($uri) . '/*'; })->all(), $domain); } なるほど「refererあるいはorigin、SANCUM_DOMAIN_ORIGINSを加工した上で比較してるんだな」というのは分かって、Str::isも調べてようやく、SANCTUM_STATEFUL_DOMAINSに「www.」のないドメインを登録してて、$domainとはマッチしないと気づきました。 .envの他の項目とごっちゃになったか、省略可能だろうと当てずっぽうに設定した線が濃厚です? 「www.」を含めたドメイン名を設定することで無事動きました。 感想 ググった限り、このトラブルはそこそこある上に、原因となる要素が多いんで、StackOverFlow等でも「更新後の.envちゃんと適応してる？」とか「sessionタイプをcookieにしろ（注：デフォルトのfile設定で動きます。誤解してる人の書き込みがあるので注意）」等、場当たり的なアドバイスが多い印象を受けました。チェックリストが必要ですね……誰か作ってください。（怠慢） またsession管理がファイルの場合だと書き込み権限絡みで失敗するパターンもあるみたいなんで、この問題にハマっている人はチェックしてみてください。 それと「（検証環境とはいえ）APP_DEBUG=trueにしたらもっと早く分かったんじゃね」と今書いてて思いましたw デプロイが手作業だし、マルウェア問題の記事を読んだ直後で、検証環境でAPP_DEBUG=trueするのに抵抗があったので、思いついても実行出来たかどうか微妙ですが……。
個人的な習作に関するメモ 前提 windows10（hyper-v有効） docker install済み composer install済み step1 とりあえずプロジェクト構築 php composer.phar create-project slim/slim-skeleton:dev-master [my-app-name] まずはこれを動かしてプロジェクトを作りたい。このままだと使えないので composer create-project slim/slim-skeleton slim-auth と変更して実行。win内のphpが8系だったので怒られた。（何故か7系縛り） 適当にdockerで環境を立ち上げる docker run --mount type=bind,src=${PWD},dst=/var/www --name php --rm -it php:7 bash これだとcomposerが動かないので雑に https://getcomposer.org/download/ これを実行し、composerが動く環境を用意。 コンテナ内部で下記実行。途中色々ないと怒られたのでついでにそれも入れる。 cd /var/www apt-get update apt-get install -y git zip unzip php composer.phar create-project slim/slim-skeleton slim-auth で、OK。スマートにやる方法は絶対あるけど、ググルのめんどいのでとりあえずこんな感じで。 exitで抜けて作業終了。 step2 slim動かす 作ったディレクトリにdocker-compose.ymlがあるので、それを少し改造する。 最新のslim4.7ではphp8で動くっぽいので、php8にする。とりあえずそれだけ。 docker-compose up -d すれば http://localhost:8080/にアクセスできるようになる。 これでOK。 step3 ディレクトリデザインを見ていく。 ADRパターン (Action Domain Responder) というのに沿って作られてるらしい。MVCを触ることが多かったので少し困惑したが、慣れればそんなに問題じゃない。 とりあえず、ぱっと見た感じ ドメイン層はRepositoryのInterfaceとか、そこから取得できるデータのEntityクラスを持っている。 インフラストラクチャ層では、ドメイン層で持つInterfaceの実装をやってる。 アプリケーション層は...めっちゃ広い。その他。みたいな感じ。 個人的に、Interfaceクラスの末尾にInterfaceと書いてないのが混乱の元だったので、そこは後でどうにかしたい。 総括 laravel以外のフレームワークを選ぶとした何がいいかなー、特に深い思い入れはないけどDIとかrouteの設定は似てるやつがいいなと思って見つけたのがslim。 せっかくだからメモ的にQiitaにまとめようと思ったのがこの記事を書いたきっかけです。 Windowsでphpを使っていてslimを使おうとしているｎ人の開発者の役に立てば幸いです。 では。 end
はじめに 例えば、あるサイトでユーザーID1の人がマイページのユーザー詳細画面を開いた時、URLが https://○○○○/user/1 のような形だったとします。1というのはユーザーIDを指します。 もしここを2に変えた時、何が起こると思いますか？ なんと、ユーザーID1の人がユーザーID2の人のユーザー詳細画面に入れてしまうんです！ 個人情報が全て筒抜けになってしまうんです。他にも、ユーザー情報の編集画面に入って他人の情報を書き換えることもできてしまったりします。 そんな危ないサイト使いたくないですよね。 なので、このような場合は必ず認可機能を実装してアクセス制限を行うようにしましょう！！ ※IDを推測されやすい番号にしない、といった内容は今回の記事では取り扱わないことにします。 環境 Composer 1.10.20 PHP 7.4.15 Laravel 6.20.20 Policyとは Laravelでは認可のために方法がいくつか用意されています。 今回はその中からPolicyについてのみ説明しますが、詳しく知りたい方は以下の記事を読んでみてください。 Laravel Gate(ゲート)、Policy(ポリシー)を完全理解 Laravel Document （Laravel 6.x 認可 ） Policyとは、ある特定のモデルに対して行うアクション(作成、更新、削除、閲覧等）に関してアクセス制限を行う仕組みのことです。そのためモデルごとに個別の独立したPolicyファイルを作成する必要があります。 実装 ここから、実装の手順を説明していきます。 1. Policyの作成 まず、Policyファイルを作成します。 –-modelオプションでモデルを指定してPolicyを作成をすると、Policyで使用するメソッドが記述された状態でファイルを作成することができます。 今回はUserモデルに対してPolicyを生成します。 $ php artisan make:policy UserPolicy --model=User これを実行すると、app/Policiesディレクトリの中にUserPolicy.phpが作成されます。 UserPolicy.php namespace App\Policies; use App\User; use App\User; use Illuminate\Auth\Access\HandlesAuthorization; class UserPolicy { use HandlesAuthorization; /** * Determine whether the user can view any users. * * @param \App\User $user * @return mixed */ public function viewAny(User $user) { // } /** * Determine whether the user can view the user. * * @param \App\User $user * @param \App\User $user * @return mixed */ public function view(User $user, User $user) { // } } ※本来は他にcreate, update, delete, restore, forceDeleteのメソッドが記述された形で作成されますが、省略しています。 今回はviewメソッドを使用しますが、当時僕はここで「ん？」となりました。 User $user, User $userってどういうこと？同じじゃないの？？ ここの説明と記述は後ほどします。 2. Policyの登録 Policyを作成したら、登録する必要があります（省略可※後述） app/Providersディレクトリ内のAuthServiceProvider.phpを編集します。 AuthServiceProvider.php protected $policies = [ 'App\User' => 'App\Policies\UserPolicy', ]; ※ Policyの自動検出 Laravel 5.8 で追加された機能です。 モデルとポリシーの標準命名規則に従っているポリシーをLaravelが自動的に見つけてくれる便利な機能で、この場合はPolicyの登録を省略できます。 例えば、appディレクトリ下にモデルがある場合、app/Policiesディレクトリ下のPolicyファイルを自動検出してくれます。 この時、モデルの名前に対応させたPolicyファイルを作成する必要があります。 （今回の場合はUserモデルに対するPolicyなので、UserPolicy.phpという名前をつけます。） 3. コントローラーの編集 次に、マイページ表示の処理を行っているshowアクションにauthorizeメソッドを追記していきます。 UserController.php public function show(User $user) { $this->authorize('view', $user);//追記 return view('mypage'); } authorizeメソッドの最初の引数をview、2番目の引数をUserモデルの変数$userとすることで、UserPolicy.phpのviewメソッドに$userの情報を渡します。 アクションが認可されない場合、authorizeメソッドは403エラーを返します。 4. Policyの編集 UserPolicy.phpに戻って、viewメソッドを編集していきます。 UserPolicy.php public function view(User $user, User $user) { return $user->id === $user->id } ここで、先ほどお話しした「User $user, User $userってどういうこと？」について説明します。 この2つの$userにはちゃんと違いがあります。1つ目の$userにはこのviewメソッドにて取得されたユーザーの情報が入っていて、2つ目の$userにはコントローラーのshowアクションから送られてきたユーザーの情報が入っています。 このままだと分かりづらいので、2つ目の方を$request_userに変更しておきましょう。 UserPolicy.php（変更後） public function view(User $user, User $request_user) { return $user->id === $request_user->id; } 完成！ これで機能としては完成しましたが、処理の流れを簡単に説明したいと思います！ IDが1のユーザーがログインしている状態と仮定して、 https://○○○○/user/1 というURLを https://○○○○/user/2 に変更してリロードした際の処理を説明します。 処理の流れ コントローラーのshowアクションで、UserモデルからユーザーID2の情報を$userとして取得。 $this->authorize('view', $user); で、ユーザーID2の情報をUserPolicy.phpに渡す。 UserPolicy.phpにて、Userモデルから本来のユーザーID1の情報を$userとして取得、$request_userにはコントローラーから送られた$user（今回はユーザーID2の情報）の値が入っている。 return 1 === 2;となるのでfalseを返し、403エラーを表示する。 最後に 以上、Laravelにおける認可機能の一部をご紹介しました！ 初学者あるあるなのかなと思いますが、書いたコードをいざ言葉で説明するとなると、それが意外と難しいことに気づきました。 僕も初学者なので、初学者でも分かりやすい言葉で説明できるように意識したいと思います。 認識が間違っている点があれば、ぜひコメントをお願いいたします！！ 参考文献 Laravel Document （Laravel 6.x 認可 ） Laravel Gate(ゲート)、Policy(ポリシー)を完全理解 【初心者向け】Laravel Policyの使い方(認可)
phpのDockerfileに # nodejs install RUN curl -sL https://deb.nodesource.com/setup_12.x | bash - RUN apt-get install -y nodejs こちらの記述を書くこと 12.xはバージョン 参考 nodeのバージョン
概要 業務で数百万件のCSVファイルをインポートする処理を実装することがあった。 自分が従来書いていたDB存在チェックの処理だとCSV一行ずつDB存在チェックを行なっていたため、わかってはいたものの処理に時間がかかってしまっていた。 まとめてDB存在チェックできるように実装したのでその仕組みを記載しておこうと思います。 前提 例として、以下のusersテーブルが存在するとします。 (例なので件数少ないですが…) id login_id age 1 test_user_1 0 2 test_user_2 5 3 test_user_3 10 4 test_user_4 15 5 test_user_5 20 そのusersテーブルに対して、画面上からCSVをアップロードしてusersの登録が行えるインポート機能を実装します。 CSVは「loginid,age」を複数行で作成されるものとします。 login_idは重複を許していません。 なのでCSVに重複があった場合はエラーを返さなければいけません。 以下のようなCSVは「test_user_5」が登録済みなのでエラーにします。 test.csv test_user_5,20 test_user_6,25 test_user_7,30 test_user_8,35 test_user_9,40 ※本当は１項目ずつ半角アルファベット、アンダーバー、数字のみとか色々なバリデーションが必要かと思いますが今回は省略 従来の方法 例なので簡素なphpにしていますが言いたいことは伝わるかなと。 CSV一行ずつDB存在チェックしているのでCSVの行数分SQLが発行されてしまうのはわかってたのですが、こうしないと今調べてる行数とかがエラーメッセージで出せないと思ってたんですよね… 従来の方法サンプルコード index.php <?php $errors = default_validation(); var_dump($errors); function default_validation() { $file_path = './test.csv'; $errors = []; $fp = fopen($file_path, 'r'); $line_num = 0; $clm = [ 'LOGIN_ID' => 0, 'AGE' => 1, ]; while (($line = fgetcsv($fp)) !== false) { $line_num++; // 既にDBに登録済みかチェックを行う。 $users = get_users($line[$clm['LOGIN_ID']]); if (!empty($users)) { $errors[] = $line_num . '行目のデータは登録済みです。'; } } fclose($fp); return $errors; } function get_users($login_id = '') { // DBの準備が面倒だったので擬似的な関数 // モデルクラスで単純な完全一致検索をする関数を想定 // ここではこういうSQLを想定 // SELECT login_id // FROM users // WHERE login_id = '引数のlogin_id' // usersテーブルにはlogin_id=test_user_5が登録されている想定 if ($login_id === 'test_user_5') { return [ 0 => [ 'login_id' => 'test_user_5', ], ]; } return []; } 効率化した方法 チェック用の配列にCSVの行数を記憶させる 自分が設定した件数ごとにまとめて存在チェックすることでSQLの発行回数を抑える DBで取得した値とチェック用の配列を照合してエラーメッセージ作成する 効率化した方法サンプルコード index.php <?php $errors = validation(); var_dump($errors); function validation() { $file_path = './test.csv'; $errors = []; $record_max = count(file($file_path)); $fp = fopen($file_path, 'r'); $line_num = 0; $clm = [ 'LOGIN_ID' => 0, 'AGE' => 1, ]; $exists_validation_limit = 10000; $exists_check = []; while (($line = fgetcsv($fp)) !== false) { $line_num++; // 既にDBに登録済みかチェックを行う。 // 設定件数ごとにまとめてチェックすることで効率化。 if (isset($line[$clm['LOGIN_ID']]) && $line[$clm['LOGIN_ID']] !== '') { // チェック用の配列にCSVの行数を記憶 $exists_check[$line[$clm['LOGIN_ID']]] = $line_num; } if ($line_num % $exists_validation_limit === 0 || $line_num === $record_max) { $users = get_users(array_keys($exists_check)); if (!empty($users)) { foreach ($users as $val) { // DBで取得した値とチェック用の配列を照合してエラーメッセージ作成 if (isset($exists_check[$val['login_id']])) { $errors[] = $exists_check[$val['login_id']] . '行目のデータは登録済みです。'; } } } $exists_check = []; } } fclose($fp); return $errors; } function get_users($login_ids = []) { // DBの準備が面倒だったので擬似的な関数 // モデルクラスで単純なIN句検索する関数を想定 // ここではこういうSQLを想定 // SELECT login_id // FROM users // WHERE login_id IN ('引数のlogin_id') // usersテーブルにはlogin_id=test_user_5が登録されている想定 if (in_array('test_user_5', $login_ids, true)) { return [ 0 => [ 'login_id' => 'test_user_5', ], ]; } return []; } 今回は10000件毎、またはCSVの最大件数に達した時に存在チェックするようにしています。 この最大値はメモリなどによって適宜調整してあげると良いと思います。 あとがき 需要ありそうかな？と思って書き残したので、ぜひ誰かの参考になればと思います！
Xamppでローカルサーバー立てて開発してたのに、再起動後以下のエラーが発生。 調べてみても解決しづらかったので、だれかの助けになればと思い、ここに残します。 予期せぬ終わり方をしていくつかのファイルが消えた？と推測しました。 ※実行する際はフォルダ毎バックアップを取っておいてください。 また、記憶を頼りに書いているので、抜け漏れがあるかもしれません。 参考程度にしてください。 以下の手順。 ①xamppディレクトリにあるxampp_start.exeでエラー内容の確認。 恐らく、どこかのファイルの〇行目でエラーみたいなことが分かります。 私の場合は、httpd-xampp.conf17行目のphp8ts.dllがないと怒られていました。 ②エラー個所の確認 確認してみると、確かにロードしてる。 ③php8を再インストール 下記urlのVS16 x64 Thread Safeをダウンロード。その中にphp8ts.dllもあると思います。 https://windows.php.net/download#php-8.0 ④php8ts.dllをxampp/phpフォルダの中に入れて実行してください。 ⑤ほかのphp.exeなどのファイルも消えていたので、先ほどダウンロードしたものから引っ張ってきました。 ⑥xamppを再起動し、再度実行すると、起動しました。 が、mysqliがない、などと怒られていました。 (mysqlとの連携もしていたので) ⑦そこで、C:\xampp\php\extの中に先ほどダウンロードしたフォルダのext内のファイルを置き換えずにがさっと入れ込みました。その中にphp_mysqli.dllとかがあったので。 ⑧xamppを再起動してみると、繋がりました。 メモの乱書きなので、参考程度にしてください。
はじめに phpのWEBアプリ（？）、Humhubを使うにあたり、AmazonWebService（AWS）のうち、Beanstalkでデプロイできるか試してみようかと思ったが見送ることにした。参考にした情報は、次のとおり。 AWS Elastic Beanstalk 開発者ガイド プラットフォームチュートリアル > チュートリアル- HA Wordpress デプロイ前に、それができたとして考えたメリット、デメリットは以下のとおりかな。 メリット 「プリケーションを実行しているインフラストラクチャについて知識を得なくても、AWS クラウドでアプリケーションのデプロイと管理を簡単に行うことができます。」AWSドキュメントより。要は、バックエンドのWEBサーバーやらDBサーバーの構築・管理をお手軽にすることができるらしい。 デメリット ソースの改変のたびに、全データをZipに圧縮、beanstalk に登録って操作をしなければならない。はっきり言って開発担当が毎日ソース書き換えるような環境には不向き。githubと連携できるHerokuのほうがそういう用途に向いてるのかも。 今回の結論 現在、ソースの書き換えを複数人で同時に頻繁に行っているため、Beanstalkでの運用は不向きと判断した。 参考サイト
前置き いままでPHP7.4でコードを書いていましたが、この度、PHP8.0にマイグレーションすることにしました。 そこで、ApacheもPHP7.4からPHP8.0に切り替える必要があったので、その手順を残しておきます。 前提 OS：Ubuntu 20.04 既にPHP8.0がインストールされていること。 1. モジュールのインストール ApacheのPHP8.0モジュールをインストールします。 aptコマンドでインストールできます。 sudo apt install libapache2-mod-php8.0 2. PHP8.0モジュールの有効化 a2enmodコマンドでApacheモジュールの有効化が行えます。 sudo a2enmod php8.0 3. PHP7.4モジュールの無効化 PHP8.0モジュールを有効化しただけでは、PHPのバージョンが競合してApacheが起動できなくなります。 なので今度は、a2dismodコマンドでPHP7.4モジュールを無効化します。 sudo a2dismod php7.4 4. Apache再起動 最後にApacheを再起動して終わりです。PHP8.0アプリがApacheで動作するようになります。 sudo service apache2 restart
