正月早々ですが、また次回ハマったらいやなのでメモ。
xserverに開発済みのCIアプリを入れて、一通りページを表示して確認していたところ、homeコントローラ配下の画面がことごとく404エラーになっていました。
なんでなんでー?とlogレベルをdebugに変更して/index.php/home/indexと直打ちしてアクセス
URI class initialized
404 notfound --> index
どうやらURIクラス初期化までOK、次のROUTERの初期化がうまくいってない(ここで404?)。
で、system/libraries/Router.phpを見る。
Router class initializedをログ出力する前に呼んでいるRouter::_set_routing()内で、URIクラスから渡されたURIを見てみる。…??あれ??/home/indexにアクセスしたのに/indexになってる。そりゃ404にもなる罠。
Routerクラスを元に戻して、system/libraries/URI.phpを見る。
URI::_fetch_uri_string()→URI::_parse_request_uri()と実際の処理部分を探して見る。
$_SERVER['REQUEST_URI']は/home/indexが入っている。OK。
その次、$fc_pathというのと$_SERVER['REQUEST_URI']を/でexplodeしたものを比較して、array_sliceしている。ここアヤシイ!!
$fc_pathってなに?と値を見てみたところ、index.php(フロントコントローラ)のパスが入っていました。
要するに、xserverのドキュメントルートのパスが/home/hogehoge/public_htmlのようになっているのに、デフォルトコントローラ名としてhomeを使ったのが原因。CIアプリをドキュメントルートでなく物理フォルダを切って配置した場合に対するCI側の対策が仇になっていた。
とりあえず、今回のブツは他へ移植する予定のないアプリなので、$fc_pathとの比較&array_sliceしている箇所をURI.php内で勝手にコメントアウト。
私はデフォルトコントローラをhomeとすることが多いのですが、前回xserver使ったときはCI使い初期に作ったアプリでデフォルトコントローラはwelcomeのままだったので、これにひっかからなかった模様。
この問題はURIルーティング方法としてREQUEST_URIを選択した場合のみ出てくるので、他の方法(PATH_INFOとかQUERY_STRING)にすれば問題ない模様。