どurakuの作ったもの、作ろうとしているもの、作ろうとしていたものの近況。3.xで動くように乗せ換えた話です。具体的なコードというよりも、こうやって進めた、という話になります。2016の11日目の記事になります。現状フレームワーク利用無し。8.2以前が組み合わされている。ORマッパーとかも無い。動く前提で作られている。かなりの数がある画面のほとんどのページが数個程度のPHPファイルに纏められている。GETやPOSTの値に機能やページの指定も含まれていて、if文でページを切り替えている。画面表示はCodeigniterでいうHTMLヘルパーのような、フォームやテーブルを楽に作るためのクラスが用意されていて、その関数を呼んでいる。テストコードなんて無い。ソースコードの文字コードもDBの文字コードもEUC-JP。辛そうな感じですが、下手にフレームワークを使われているより、フルスクラッチ的なPHPの方がCodeigniterへの移植相性は良い(と思った)ので移行は出来るだろうと判断しました。全コードをUTF-8に書き換え今後の事を考えて文字コードはUTF-8に統一します。EUC-JPのコードをnkfでサクッと書き換えます。htmlspecialcharsしている所を検索し、見つけた1つ1つをUTF-8に対応した形で書き換えます。9.x系への入れ替え既存のDBの内容はすべてダンプで出力します。ダンプの中身をテキストエディタで開き、文字コードに関連している記述をすべてUTF-8準拠に書き換えます。9.4へ流し込みます。ここは意外と問題になりませんでした。ここで処理上の問題になるのはキャストの仕様変更になります。型変換のチェックが厳密になるよう仕様変更されました。上ではエラーが発生するかもしれません。これがもろに該当しSQL実行時にエラーになるのですが、今はまだ修正しません。5.6で動作する環境となっています。試しに動かしてみる全然動きません。ここからひたすら修正していく作業になります。静的解析と実際に動かして出るエラーをひたすら潰していくEclipse+PDTで作業しています。世間的にはPhpStormな潮流となっていますが、こういう元々動かないようなコードをPhpStormに放り込むとエラー数がすごい事になるので、PDTが静的解析する分が丁度よかったりします(PhpStormでも解析する範囲は調整できるのですが)。これは体感的な物なので実際はどちらでもいいでしょう。静的解析の無いテキストエディタでのコーディングはお勧めできません。ここでIDEによる静的解析でエラーになっている物、ワーニングになっている物をひたすら修正していきます。元のコードでは連想配列を使用する際にほとんどの添え字がシングルクォーテーションで囲まれていなかったりしました。連想配列は相当な数が使用されているので、これが一番作業としてつらかったですね......。register_globalsに関してはオンにしてはいけない、というかPHP5.6ではそもそも使用不可なので、各ファイルの先頭に全てのGETとPOSTを変数に展開するコードを一時しのぎで書いています。$get_value;}PostgreSQLのキャストで問題になるエラーも、実際に動かしてみながらエラーが出る個所を潰していきます。一か所エラーが見つかれば、そのカラムを扱うところすべてが怪しいので、コード全体をカラム名で検索し該当箇所をまとめて修正します。9.4で動くようになった実はまだバグが残っていたりしますが、機能として重要な部分は正常に動作する状態ですので、他は見つけ次第随時潰していく、という対応を取りました。何かしらフレームワークが使われていたらフレームワークまで含んだコード量やフレームワークのメンテナンス状態、それを入れ替えるための仕様変更部分もろもろの理由で諦めていたかもしれませんが、フルスクラッチなのでひたすらバグを潰していくだけで移行が出来ました。CodeIgniterへの入れ替えやっとCodeIgniterの話になります。5.6で動く状態ですので処理の移植は結構楽です。ちなみにここからIDEをPhpStormに切り替えています。etc...というような形で動くコントローラに作り替えました。分類部分がコントローラのクラス、insertやedit、detailの部分がコントローラ内のメソッドになります。既存のWebアプリとはここでURLの互換性が一旦なくなります。コントローラでルーティングした後は、すぐにモデルに渡してしまう形にします。モデルの作成GETとPOSTで振り分けていた処理ブロックの中身をモデル、モデル内のメソッドに分割していきます。元の処理をひたすらコピペをしていくような作業になります。取得するようにします。