PCS開発チーム

これも最近よく見る質問のパターン。
Folioを知らないエディターからは未定義の$idがいきなり使われてるように見えるってだけ。

<?php
dump($id);
?>
<div>
    //
</div>

Folioではこれは正しいコードなので実際に実行すれば正しく動く。
「エディターがFolioに対応してないのが原因で出てる警告メッセージ」でしかないので気にする必要はないのに「自分のコードの間違い」と思い込んだ質問が最近多い。

こんなのはプログラミングの最初に身に付ける基礎でしかないので本当の根本的な原因は「PHPの基本も分かってない初心者がいきなりLaravel使ってるから」。結局全部ここに辿り着く。

https://laracasts.com/discuss/channels/laravel/folio-page-parameter-is-undefined-variable

https://github.com/livewire/livewire/releases/tag/v3.5.10

• テスト中のエラーを無視するように変更。
• wire:navigate呼び出し間でポップオーバーを保持するように変更。

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"

https://php.new/install/mac

PHP公式ではなくLaravel公式と分かってよく見直すと https://php.new/ はLaravel+Livewireで作られてる。

使うべき？

使わなくていい。Laravel公式とはいえ独自バイナリなんて使いたくないだろう。
node.jsはインストールされないので別途必要。
普通の使い方からも離れてる。
Macならbrew、WindowsならWSLを使う普通の使い方をしたほうがいい。

超初心者向けにPHPをインストールする部分からLaravel公式が提供してる形だけどLaravel入門よりも先がない。

追記

これを書いた数時間後には https://php.new/ が全面改修されてLaravelなことが明記された。
macならSpotlightを開いてTerminalを起動してペーストなんて手順まで丁寧に説明してるので本当に超初心者向け。
ここまで説明されなくても分かる人は使わなくていい。

https://github.com/laravel/framework/releases/tag/v11.27.2

• queue:work コマンドのリグレッションを修正。
• ServiceProvider::optimizes() のパラメータ宣言を修正。

https://github.com/laravel/jetstream/releases/tag/v5.2.1

• ロゴをダーク/ライトテーマに対応するよう更新。
• Illuminate\Support\php_binary()を利用。
• モデル内のファクトリードキュメントブロックの整理。

https://github.com/laravel/breeze/releases/tag/v2.2.2

• ロゴを更新し、ダーク/ライトテーマをサポート。
• マルチセレクトの使用方法を明確にするヒントを追加。
• Illuminate\Support\php_binary()を利用。
• 属性のためのBladeのエスケープ解除を削除。
• テキスト入力で@disabledを使用するように変更。
• デフォルト関数の名前をファイル名に合わせて更新。

https://github.com/laravel/laravel/releases/tag/v11.2.1

• Collisionのバージョンがアップグレードされました。
• ユーザーモデルにジェネリクスが追加されました。
• welcome.blade.phpに欠落していたaltタグが追加されました。

https://github.com/laravel/framework/releases/tag/v11.27.1

• テーマスイッチャーのホバー時の境界線のオーバーフローを修正
• コマンドレジストリを最適化
• laravel/framework#53071を修正

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のパフォーマンスを向上。

便利に使ってるのに困るけど代わりの通知先は色々あるのでMessaging APIに移行せず削除する。

https://developers.line.biz/ja/news/2024/10/07/line-notify-will-be-discontinued/

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"
      ]
    }
  },

https://stackoverflow.com/questions/79059645/laravel-package-development-need-to-extend-the-formrequest-class-but-dont-wa

LaravelでEloquentを使うとき、遅延ロード（レイジーローディング）ではなく、｢with｣メソッドを使ってリレーションを事前にロードすることで、N+1問題を防ぐことができます。例: User::with('posts')->get();

https://github.com/composer/composer/releases/tag/2.8.1

• ライセンスが提供されていない場合のinitコマンドの不具合を修正
• --strict-ambiguousフラグの処理を修正し、すべての問題を報告するように改善
• create-projectでインストールされたプロジェクトファイルがターゲットフォルダの権限を継承するように修正
• 親ディレクトリのcomposer.jsonを使用するプロンプトが正しく動作しないいくつかのケースを修正

「JavaScriptからのAPI呼び出しが上手くいかない。Postmanからは成功する」という質問も最近多いけど前提が全く違うのでPostmanから成功してもコードが間違ってない保証にはならない。

PostmanはサーバーサイドやPC/モバイルアプリからのリクエストと同じ。CORSは関係ない。クッキー・セッションは使える。
フロントからのAPI呼び出しが失敗する原因はCORSが8割、セッションが1割、コードの間違いが1割程度なんだからPostmanから成功しても原因の特定ができない。
「CORSによって制限されている」とか「使えないセッションを使おうとしている」とかはPostmanでは分かりにくい。

Postmanでフロントからのリクエストをある程度再現するにはクッキーを無効にしてHeadersにOriginを追加。

デフォルトの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側で自動的に実行されているので自分で追加しなくていい。
余計なことをする必要はなかった。