PCS開発チーム
「IDEやエディターで表示されてるだけの警告メッセージ」と「コードの間違いによって発生した実行時のエラー」は区別する
これも最近よく見る質問のパターン。
Folioを知らないエディターからは未定義の$id
がいきなり使われてるように見えるってだけ。
<?php
dump($id);
?>
<div>
//
</div>
Folioではこれは正しいコードなので実際に実行すれば正しく動く。
「エディターがFolioに対応してないのが原因で出てる警告メッセージ」でしかないので気にする必要はないのに「自分のコードの間違い」と思い込んだ質問が最近多い。
こんなのはプログラミングの最初に身に付ける基礎でしかないので本当の根本的な原因は「PHPの基本も分かってない初心者がいきなりLaravel使ってるから」。結局全部ここに辿り着く。
https://laracasts.com/discuss/channels/laravel/folio-page-parameter-is-undefined-variable
livewire/livewire v3.5.10
https://github.com/livewire/livewire/releases/tag/v3.5.10
- テスト中のエラーを無視するように変更。
- wire:navigate呼び出し間でポップオーバーを保持するように変更。
php.newはLaravelによる提供
PHPやcomposerのインストール方法として急に登場。
// mac
/bin/bash -c "$(curl -fsSL https://php.new/install/mac)"
https://github.com/laravel/docs/commit/44f2375021852c0b1f0c9b6d3316436d3fc590d3
https://php.new/ だけ見てもPHP公式?としか思わないけどインストールスクリプトの中身を見るとhttps://download.herdphp.com
からphpやcomposerのバイナリを直接ダウンロードしている。
Laravel Herdのライト版みたいな扱いでLaravelに必要なバイナリだけをインストールしている。
# Define variables
BASE_URL="https://download.herdphp.com"
INSTALL_DIR="$HOME/.config/herd-lite/bin"
PHP_BIN="$INSTALL_DIR/php"
COMPOSER_BIN="$INSTALL_DIR/composer"
LARAVEL_BIN="$INSTALL_DIR/laravel"
PHP公式ではなくLaravel公式と分かってよく見直すと https://php.new/ はLaravel+Livewireで作られてる。
使うべき?
使わなくていい。Laravel公式とはいえ独自バイナリなんて使いたくないだろう。
node.jsはインストールされないので別途必要。
普通の使い方からも離れてる。
Macならbrew、WindowsならWSLを使う普通の使い方をしたほうがいい。
超初心者向けにPHPをインストールする部分からLaravel公式が提供してる形だけどLaravel入門よりも先がない。
追記
これを書いた数時間後には https://php.new/ が全面改修されてLaravelなことが明記された。
macならSpotlightを開いてTerminalを起動してペーストなんて手順まで丁寧に説明してるので本当に超初心者向け。
ここまで説明されなくても分かる人は使わなくていい。
laravel/framework v11.27.2
https://github.com/laravel/framework/releases/tag/v11.27.2
-
queue:work
コマンドのリグレッションを修正。 -
ServiceProvider::optimizes()
のパラメータ宣言を修正。
laravel/jetstream v5.2.1
https://github.com/laravel/jetstream/releases/tag/v5.2.1
- ロゴをダーク/ライトテーマに対応するよう更新。
-
Illuminate\Support\php_binary()
を利用。 - モデル内のファクトリードキュメントブロックの整理。
laravel/breeze v2.2.2
https://github.com/laravel/breeze/releases/tag/v2.2.2
- ロゴを更新し、ダーク/ライトテーマをサポート。
- マルチセレクトの使用方法を明確にするヒントを追加。
-
Illuminate\Support\php_binary()
を利用。 - 属性のためのBladeのエスケープ解除を削除。
- テキスト入力で@disabledを使用するように変更。
- デフォルト関数の名前をファイル名に合わせて更新。
laravel/laravel v11.2.1
https://github.com/laravel/laravel/releases/tag/v11.2.1
- Collisionのバージョンがアップグレードされました。
- ユーザーモデルにジェネリクスが追加されました。
- welcome.blade.phpに欠落していたaltタグが追加されました。
laravel/framework v11.27.1
https://github.com/laravel/framework/releases/tag/v11.27.1
- テーマスイッチャーのホバー時の境界線のオーバーフローを修正
- コマンドレジストリを最適化
- laravel/framework#53071を修正
laravel/framework v11.27.0
https://github.com/laravel/framework/releases/tag/v11.27.0
-
throw_if
とthrow_unless
の型を狭める機能を追加。 -
tries()
が二度呼ばれるのを防止。 - PHPDocの改善。
-
Illuminate\Support\php_binary()
の利用。 -
HasAttributes@casts()
の配列ジェネリクスを設定。 -
Schema::hasTable()
のパフォーマンスを向上。 - 親属性を常に継承。
- デフォルトの通貨を変更するオプションを導入。
-
Str::doesntContain()
メソッドとテストを追加。 -
Str::inlineMarkdown()
の拡張サポートを追加。 - リポジトリ取得メソッドの型ヒントを修正。
- ファイルドライバの非柔軟キーの忘却に関するテスト。
- メールビューのデータにメタデータを追加。
-
jsonOptions()
メソッドの例外処理を追加。 -
make:model
のフォームリクエストに関する修正。 - ドット表記を使用するパラメータの
shouldConvertToBoolean
によるバリデーションの修正。 - HTTPカーネルに他のミドルウェアに対して相対的にミドルウェアを追加するメソッドを追加。
-
queue:work
コマンドに構造化ログのための--json
フラグを追加。 - 複数のキューを処理するワーカーのためにRedisキューの
block_for
のパフォーマンスを向上。
LINE Notifyが2025年3月31日でサービス終了
便利に使ってるのに困るけど代わりの通知先は色々あるのでMessaging APIに移行せず削除する。
https://developers.line.biz/ja/news/2024/10/07/line-notify-will-be-discontinued/
Laravel専用パッケージのcomposer.json
requireにlaravel/framework
は指定しない。Laravel専用な時点でlaravel/framework
のクラスはすべて存在しているので指定する意味がない。
代わりにilluminate
で個別に指定するけどこれも「対応するLaravelバージョンの制限」以外の意味はないのでilluminate/support
だけで十分。illuminate/support
を使うのはIlluminate\Support\ServiceProvider
クラスを含むからだけど今はもうただのパッケージ開発者の慣習。
パッケージ開発時にlaravel/framework
のクラスが必要な場合はorchestra/testbench
を使う。
"require": {
"php": "^8.1",
"illuminate/support": "^10.0||^11.0"
},
"require-dev": {
"orchestra/testbench": "^8.0||^9.0"
},
"extra": {
"laravel": {
"providers": [
"My\\Package\\MyServiceProvider"
]
}
},
LaravelでEloquentを使うとき、遅延ロード(レイジーローディング)ではなく、「with」メソッドを使ってリレーションを事前にロードすることで、N+1問題を防ぐことができます。例: User::with('posts')->get();
composer/composer 2.8.1
https://github.com/composer/composer/releases/tag/2.8.1
- ライセンスが提供されていない場合の
init
コマンドの不具合を修正 -
--strict-ambiguous
フラグの処理を修正し、すべての問題を報告するように改善 -
create-project
でインストールされたプロジェクトファイルがターゲットフォルダの権限を継承するように修正 - 親ディレクトリのcomposer.jsonを使用するプロンプトが正しく動作しないいくつかのケースを修正
Postmanからのリクエストとフロントからのリクエストは別
「JavaScriptからのAPI呼び出しが上手くいかない。Postmanからは成功する」という質問も最近多いけど前提が全く違うのでPostmanから成功してもコードが間違ってない保証にはならない。
PostmanはサーバーサイドやPC/モバイルアプリからのリクエストと同じ。CORSは関係ない。クッキー・セッションは使える。
フロントからのAPI呼び出しが失敗する原因はCORSが8割、セッションが1割、コードの間違いが1割程度なんだからPostmanから成功しても原因の特定ができない。
「CORSによって制限されている」とか「使えないセッションを使おうとしている」とかはPostmanでは分かりにくい。
Postmanでフロントからのリクエストをある程度再現するにはクッキーを無効にしてHeadersにOrigin
を追加。
Laravel Vapor デプロイ時にはphp artisan event:cacheだけ実行すればいい
デフォルトのvapor.yml
にはevent:cache
しかないので他のキャッシュコマンドも追加したくなる。
name: vapor-app
environments:
production:
memory: 1024
database: vapor-app
cache: vapor-cache
build:
- 'composer install --no-dev'
- 'php artisan event:cache'
deploy:
- 'php artisan migrate --force'
https://docs.vapor.build/projects/deployments.html#build-hooks
必要なキャッシュコマンドはVapor側で自動的に実行されているので自分で追加しなくていい。
余計なことをする必要はなかった。