CakePHPとの戦い
公式のUpgradeツール。
CakePHPの途中からRectorで差分検知できるようになっているっぽい。
3系のなかでも違いがあるらしい
2.CakePHPのバージョンは、3.8を前提としてます。特に3.4より前とそれ以降とでは違いが多いのでご注意ください。
devcontainerで起動してみようと思ったけど、全然うまくいかない。大変だ
devcontainerでは古いバージョンのLinuxとは設定をしないと上手く接続できないらしい
いったん起動した

素直に公式ドキュメント見ておけばよかった案件。。
起動したときのDockerfile
# php:5.6-apacheベースのイメージを使用
FROM php:5.6-apache
# 必要なPHP拡張をインストール
RUN docker-php-ext-install pdo pdo_mysql
# Apacheのmod_rewriteを有効化
RUN a2enmod rewrite
# .htaccessの使用を許可するためのApache設定変更
RUN sed -i 's/AllowOverride None/AllowOverride All/' /etc/apache2/apache2.conf
# Apacheのドキュメントルートを変更
ENV APACHE_DOCUMENT_ROOT=/workspace/app
# PHPのタイムゾーン設定
RUN echo "date.timezone=Asia/Tokyo" > /usr/local/etc/php/conf.d/timezone.ini
# DebianのaptリポジトリのURLをアーカイブ版に変更し、stretch-updatesを削除
RUN sed -i -e 's/deb.debian.org/archive.debian.org/g' \
-e 's|security.debian.org|archive.debian.org/|g' \
-e '/stretch-updates/d' /etc/apt/sources.list
RUN echo 'Acquire::Check-Valid-Until "false";' > /etc/apt/apt.conf.d/100no-check-valid;
# 必要なツールと拡張のインストール (zip, unzip, git)
RUN apt-get -o Acquire::AllowInsecureRepositories=true update && apt-get install -y --no-install-recommends --allow-unauthenticated \
unzip \
git \
libzip-dev \
&& docker-php-ext-install zip
# ComposerのインストールとPATHへの追加
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \
&& composer self-update --1 \
&& composer config --global repo.packagist composer https://packagist.org
RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/sites-available/*.conf
RUN sed -ri -e 's!/var/www/!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf
# ワーキングディレクトリの設定
WORKDIR /workspace
モデルの自動生成はすごいな
もし一致するファイルが /app/Model に見つけられなければ、CakePHP は動的に モデルオブジェクトを生成します。これはまた、不意に間違ったファイル名 (例えば、 post.php や posts.php) をつけると、CakePHP はどんな設定も認識できず、 代わりにデフォルトのものを使うことになるということも意味します。
2の構造

リカルドさんが http://www.example.com/cakes/buy を指しているリンクをクリックすると、 ブラウザは、ウェブサーバにリクエストを送信します。
Router が、URL を解析(parse)し、このリクエストのパラメータを取り出します。 このリクエストにおいてビジネスロジックに影響するコントローラ、アクション、その他の引数などです。
リクエストされた URL は、Router によって、コントローラのアクション(コントローラクラスの 中にあるメソッド)にマップされます。この場合は、CakesController の buy() メソッドです。 コントローラのアクションロジックが実行される前には、コントローラの beforeFilter() コールバックが呼ばれます。
コントローラは、アプリケーションのデータを取り出すためにモデルを使用することができます。 この例では、リカルドさんの最新の購入履歴をデータベースから取得するため、コントローラが モデルを使用します。この操作で、該当するモデルのコールバック、ビヘイビア、データソースが動作します。 モデルは使用しなくてもかまいませんが、CakePHP のすべてのコントローラは、初期状態では 少なくともひとつのモデルを使用する設定になっています。
モデルがデータを取得すると、それはコントローラに送られます。 モデルのコールバックが設定されていれば、それが動作します。
コントローラはコンポーネントを使用して、データをさらに調整したり、その他の操作 (セッション操作、認証、Eメールの送信など)ができます。
コントローラがモデルとコンポーネントを使用してデータを準備し終えると、コントローラの set() メソッドを使用して、ビューにテータを渡します。 データが送信される前に、コントローラのコールバックがあれば実行されます。 ビューのロジックが動作すると、エレメントやヘルパーなどがあれば使用されます。 デフォルトでは、ビューは、レイアウトの内側に表示されます。
コントローラのその他のコールバック(afterFilter など)があれば、 実行されます。完全に描画されたビューコードは、リカルドさんのブラウザに送信されます。
3の構造

典型的な CakePHP のリクエストサイクルはユーザーがアプリケーション内でページまたはリソースにリクエストを 投げるところから始まります。高位のそれぞれのリクエストは以下のステップで動きします。
ウェブサーバーが webroot/index.php へのリクエストを制御するルールを書き換えます。
あなたのアプリケーションがロードされ、 HttpServer にひも付きます。
あなたのアプリケーションのミドルウェアが初期化されます。
リクエストとレスポンスは、あなたのアプリケーションで使用する PSR-7 ミドルウェアを経由して ディスパッチされます。これは、一般的にエラートラップとルーティングを含みます。
ミドルウェアからレスポンスが返らない場合やリクエストがルーティング情報を含む場合、 コントローラーとアクションが選択されます。
コントローラーのアクションが呼ばれ、コントローラーが要求されたモデルとコンポーネントと通信します。
コントローラーが出力を生成するためにレスポンスの生成をビューに委任します。
ビューがヘルパーとセルを使ってボディーとヘッダーを生成して返す。
レスポンスは、 ミドルウェア を経由して送信されます。
HttpServer は、ウェブサーバーにレスポンスを送ります。
見た目は変わっているけど、これだけ見ると作りはそんなに変わっていない気がする
2系
App フォルダ
アプリケーション開発の大部分は、CakePHP の app フォルダ内で行われます。 app の内部フォルダについて調べてみましょう。
Config
CakePHP が使用する(数個の)設定ファイルが入る場所です。 データベース接続の詳細、ブートストラップ、コアの設定ファイルなどがここに入ります。
Console
アプリケーションのコンソールコマンドやコンソールタスクを含みます。このディレクトリは、 bake の出力をカスタマイズするための Templates ディレクトリも含みます。 詳しくは、 シェルとタスクとコンソール をご覧ください。
Controller
アプリケーションのコントローラとコンポーネントが入ります。
Lib
サードパーティ、外部ベンダからのライブラリではなく、ファーストパーティのライブラリが入ります。 これはベンダライブラリと内部ライブラリの構成を分割することを可能にします。
Locale
国際化のための文字ファイルが入ります。
Model
アプリケーションのモデル、ビヘイビア、データソースが入ります。
Plugin
プラグインパッケージが入ります。
Test
このディレクトリは、アプリケーションの全てのテストケースやフィクスチャを含みます。 Test/Case ディレクトリは、あなたのアプリケーションを反映し、あなたのアプリケーションの クラスごとに1つかそれ以上のテストケースを含むべきです。 テストケースやフィクスチャの詳細は、 テスト をご覧ください。
tmp
CakePHP が一時的なデータを保管する場所です。保管される実際のデータは、CakePHP の 設定しだいですが、このフォルダは通常、モデルの内容デ ータや、ログの保管に使用されます。 時にはセッション情報も入ります。
確実にこのフォルダが存在し、書き込み可能であるようにしてください。 そうしないと、アプリケーションのパフォーマンスは激しく影響をうけることになります。 デバッグモードでは、CakePHP がそうなっているかどうかを警告してくれます。
Vendor
外部(サードパーティ)で作成されたクラスやライブラリは、ここに置いてください。 そうすることで、App::import('vendor', 'name') で簡単にアクセス できるようになります。 注意深く見ている人は、これは重複しているのではないか、と言うかもしれません。 ディレクトリ構造のいちばん上にも vendors フォルダがあるからです。 この二つのフォルダの違いは、複数のアプリケーションを動作させて、 より複雑なシステムセットアップをする場合のことを考える際に取り扱います。
View
表示用のファイルはここに置きます。エレメント、エラーページ、ヘルパー、レイアウト、 ビューのファイルなどです。
webroot
運用時 (production) 用のセットアップでは、このフォルダがアプリケーションの ドキュメントルートになります。CSS スタイルシートや画像、JavaScript ファイルを入れるための フォルダもあります。
3系
bin フォルダーには実行可能な Cake コンソールを保持します。
config フォルダーは、CakePHP が使用する(数個の) 構成設定 ファイルが入る場所です。データーベース接続の詳細、ブートストラップ、 コアの設定ファイルなどがここに格納されます。
plugins フォルダーは、あなたのアプリケーションが使う プラグイン が格納されます。
logs フォルダーは、通常、ログ設定に応じたログファイルが含まれます。
src フォルダーは、あなたのアプリケーションのファイルが配置される場所です。
tests フォルダーは、あなたのアプリケーションのテストケースを置く場所です。
tmp フォルダーは、CakePHP が一時的なデータを格納する場所です。 格納する実際のデータは、CakePHP の設定方法によって異なりますが、このフォルダーは、通常、 翻訳メッセージ、モデルの詳細、および時にはセッション情報を格納するために使用されます。
vendor フォルダーは、CakePHP と他のアプリケーションの依存ライブラリーが Composer によってインストールされる場所です。これらのファイルを 編集することは推奨されません。次回の更新時に Composer があなたの変更を上書きしてしまうからです。
webroot ディレクトリーは、あなたのアプリケーションのパブリックドキュメントルートです。 それはあなたが公開したいすべてのファイルを含みます。
tmp フォルダーと logs フォルダーは存在していてかつ書き込み可能な状態にしておいてください。 そうでない場合、あなたのアプリケーションのパフォーマンスに影響を及ぼす場合があります。 これらのディレクトリーが書き込み可能ではない場合、デバッグモードでは CakePHP は警告を出します。
src フォルダー
アプリケーション開発の大部分は、CakePHP の src フォルダー内で行われます。 src 内のフォルダーを少し近づいて見てみましょう。
Command
アプリケーションのコンソールコマンドを含みます。 更に学ぶためには、 コンソールコマンド をご覧ください。
Console
Composer によって実行されるインストールスクリプトを含みます。
Controller
アプリケーションのコントローラーとコンポーネントを含みます。
Locale
国際化のための文字列ファイルを格納します。
Middleware
アプリケーションの ミドルウェア を格納します。
Model
アプリケーションのテーブル、エンティティー、ビヘイビアーを含みます。
Shell
あなたのアプリケーションで使うコンソールコマンドやコンソールタスクが入ります。 詳細は コンソールツール、シェルとタスク を確認してください。
Template
表示用のファイルが、ここに配置されます。 エレメント、エラーページ、レイアウト、ビューテンプレートのファイルなどです。
View
表示用のクラスが、ここに配置されます。ビュー、セル、ヘルパーなどです。
3系も起動までできた。こっちはdevcontainerで簡単だった

これ、upgrade guideではないな。
移行ガイド
Controllerで利用していたusesはなくなっているが移行ドキュメントには書いてない。
移行ドキュメント、色々なさすぎでは。。
ChatGPTに聞いたところ、以下のようになっているらしい
2.x: $uses でモデルをバインド/ClassRegistry::init()
3.x: TableRegistry::get() → 後に getTableLocator()->get() に移行
4.0〜4.2: loadModel()(Controller のみ)か TableLocator を直接利用
4.3〜(現在 5.x 含む): fetchTable() が追加され、Controller や Component で統一的に使える
この処理の時にはここに書くのがよいっていうプラクティスを愚直に調べていくことにする
認証プラグイン
認証を行っている部分
Componentとして実装されているらしい
Serviceの処理にはいる
こういうのだよねー
大きな違いが見つかりました:
CakePHP2のConfig.time
有効期限(現在時刻 + タイムアウト秒数)を保存
検証: static::$time <= $time (現在時刻が有効期限以下か)
CakePHP5のConfig.time
最終アクセス時刻(現在時刻)を保存
検証: time() - $time > $this->_lifetime (経過時間がタイムアウトを超えたか)
この違いにより、Redisに保存されるtimeフィールドの値が全く異なります。これがセッション共有時の互換性問題の根本原因です。