2.2.x から 3.0.0 へのアップグレード¶

Step 1: CodeIgniter ファイルを更新する¶

system/ ディレクトリのすべてのファイルと index.php を新しいものに 置き換えてください。index.php に何か変更を加えていた場合、 新しいファイルに再度適用する必要があります。

Step 2: クラスファイルの名前を更新する¶

CodeIgniter 3.0 以降、全てのクラスファイル （ライブラリ、ドライバ、コントローラ、そしてモデル）の名前は Ucfirst 形式、 つまり大文字で始まるようにしなければなりません。

例えば、あなたが次のようなライブラリを持っているなら:

application/libraries/mylibrary.php

このようにファイル名を変更します:

application/libraries/Mylibrary.php

ドライバライブラリ、それから CodeIgniter 付属の コアクラスやライブラリを拡張や置き換えしている場合も同様です。

application/libraries/MY_email.php application/core/MY_log.php

これらのファイル名は次のように変更します:

application/libraries/MY_Email.php application/core/MY_Log.php

コントローラ:

application/controllers/welcome.php -> application/controllers/Welcome.php

モデル:

application/models/misc_model.php -> application/models/Misc_model.php

このルールはディレクトリ名、設定ファイル、ビュー、ヘルパー、フック等には適用 されません。クラスのみが対象です。

まとめると、次のシンプルな 1 つのルールになります。 クラス名は Ucfirst、それ以外は小文字です。

Step 3: config/mimes.php を置き換える¶

より多くの MIME タイプを含むように更新されています。 これを application/config/mimes.php にコピーしてください.

Step 4: config/autoload.php から $autoload[‘core’] を削除する¶

$autoload['core'] は CodeIgniter 1.4.1 で非推奨になっていましたが、ついに削除されました。 もし何か指定されていれば $autoload['libraries'] に移動してください。

Step 5: Log クラスへの拡張・置き換えを移動する¶

Log クラスは “core” クラスとして扱われるようになったため、 system/core/ ディレクトリに移動されました。もし Log クラスを拡張・置き換えて いた場合、それらのファイルを application/core/ に移動してください:

application/libraries/Log.php -> application/core/Log.php application/libraries/MY_Log.php -> application/core/MY_Log.php

Step 6: セッションライブラリの使い方を更新する¶

セッションライブラリ は CodeIgniter 3 で刷新され、 様々な新機能が追加されています。 しかし同時に、注意の必要な変更も加えられています。

最も大きな変更は、（暗号化された）クッキーの代わりに 独立したストレージを使うようになったことです。 データの格納先としてのクッキーは完全に廃止されたので、 今後はサーバ上の何らかのストレージエンジンを使わなければなりません。 デフォルトではファイルシステムが使われます。

新しいセッションクラスは PHP のカスタムセッションハンドラを利用しています。 これによりスーパーグローバルの $_SESSION からも セッションデータにアクセスできるようになりました （これまで同様 “userdata” としても使えます）。

設定オプションも追加・削除されています。 詳しくは セッションライブラリのマニュアル を すべて読まれることをお勧めしますが、 ここでもいくつかのポイントを説明します。

• $config['sess_driver'] を設定する

  デフォルトは ‘files’ ですが、もしあなたが $config['sess_use_database'] を設定していた場合は ‘database’ になります。

• $config['sess_save_path'] を設定する

  ‘database’ ドライバでは $config['sess_table_name'] に フォールバックしますが、それ以外のドライバではマニュアルを参照して 選択したドライバでの適切な値を設定する必要があります。

• ci_sessions テーブルを変更する（’database’ ドライバのみ）

  テーブルの構造がすこし変更されています。具体的には:

  • session_id 列は id に名前が変わりました
  • user_agent 列は削除されました
  • user_data 列は data に名前が変わり、 MySQL では BLOB 型が使われます
  • last_activity 列は timestamp に名前が変わりました

  これに伴いインデックスの更新も必要です。 詳しくは Session Database ドライバ の説明を参照してください。

  重要

  現在公式にサポートしているのは MySQL と PostgreSQL のみです。 他のデータベースでも動作するかもしれませんが、助言ロックがないために 同時アクセスに対して安全ではありません。 この場合は他のドライバを検討してください。

• $config['sess_match_useragent'] を削除する

  ユーザエージェント文字列はブラウザから提供される値、つまりクライアントからの 入力値です。これを検証しても意味がないので、 この機能は廃止されました。

• $config['sess_encrypt_cookie'] を削除する

  前述の通り、今後クッキーにセッションデータが格納されることは ありませんから、このオプションもお役御免になりました。

• $config['sess_expire_on_close'] を削除する

  このオプションはまだ使えますが、後方互換性のためだけに残されています。 同じ効果は $config['sess_expiration'] を 0 に設定することで 得ることができます。

• “flashdata” と “userdata” の衝突をチェックする

  フラッシュデータは次のリクエストで削除するようにマークされている以外は ただの “userdata” になりました。つまり、同じ名前の “userdata” と “flashdata” を別々に扱うことはできません。

• セッションメタデータをチェックする

  これまでは ‘session_id’ 、’ip_address’ 、’user_agent’ 、’last_activity’ といったメタデータにも userdata としてアクセスできました。 今後はできませんので、もしこれらのデータを利用しているなら、 セッションメタデータ に関する説明を参照してください。

• unset_userdata() の使い方をチェックする

  これまでは 'key' => 'dummy value' といった連想配列で、 一度に複数のキーを削除することができました。 しかし、この方法は無意味なので、 今後はキー だけ を配列の要素として渡さなければなりません。

  // 以前
  $this->session->unset_userdata(array('item' => '', 'item2' => ''));
  
  // 今後
  $this->session->unset_userdata(array('item', 'item2'));
  

最後に、もしセッションを拡張して使っていたら、 application/libraries/Session/ ディレクトリに移動してください。 たぶん、コードの書き換えも必要でしょうが。

Step 7: config/database.php を更新する¶

3.0.0 で Active Record から Query Builder に名前が変更されたので、 config/database.php の $active_record 変数も $query_builder に変更する必要があります:

$active_group = 'default';
// $active_record = TRUE;
$query_builder = TRUE;

Step 8: エラーテンプレートを置き換える¶

CodeIgniter 3.0 ではエラーテンプレートもビューとして扱われ、 application/views/errors ディレクトリに移動されました。

また、CLI 向けにプレインテキストのエラーテンプレートを サポートするようになりました。これも新たに分ける必要があります。

これまでのテンプレートは application/errors から application/views/errors/html にそのまま移動して構いませんが、 新しい application/views/errors/cli ディレクトリは CodeIgniter のアーカイブからコピーしてください。

Step 9: config/routes.php ファイルを更新する¶

(.+)    // 全ての文字にマッチする
(:any)  // '/' 以外、全ての文字にマッチする

$route['default_controller'] = 'main';

Step 10: 多くの関数が要素がないとき FALSE ではなく NULL を返すようになりました¶

多くのメソッドと関数は、要求された要素が存在しないとき、FALSE ではなく NULL を返すようになりました:

• 共通関数
  • config_item()
• Config クラス
  • config->item()
  • config->slash_item()
• Input クラス
  • input->get()
  • input->post()
  • input->get_post()
  • input->cookie()
  • input->server()
  • input->input_stream()
  • input->get_request_header()
• Session クラス
  • session->userdata()
  • session->flashdata()
• URI クラス
  • uri->segment()
  • uri->rsegment()
• Array クラス
  • element()
  • elements()

Step 11: XSS フィルタの使い方¶

CodeIgniter の多くの関数は、論理値のパラメータを渡すことで、 XSS フィルタリング機能を使うことができます。 そのデフォルト値は以前は FALSE でしたが、今は NULL に変更され、 $config['global_xss_filtering'] の値により動的に 決定されます。

もし、手動で論理値を $xss_filter パラメータに渡していたり、 $config['global_xss_filtering'] に FALSE を設定していた場合は、 この変更は影響しません。

そうでない場合は、次の関数の使い方を確認してください:

• Input ライブラリ
  • input->get()
  • input->post()
  • input->get_post()
  • input->cookie()
  • input->server()
  • input->input_stream()
• Cookie ヘルパー get_cookie()

Step 12: URI にまつわる潜在的な XSS 問題をチェックする¶

URI ライブラリ は以前は特定の “問題のある文字” が URI セグメントに含まれるとき、HTML エンティティに自動的に 変換していました。

これは、$config['permitted_uri_chars'] の設定に加えて、 自動 XSS 保護の提供を目的としていましたが、問題があることが判明したため、 CodeIgniter 3.0 で削除されました。

もし、あなたのアプリケーションがこの機能に頼っているなら、 出力時に $this->security->xss_clean() で URI セグメントを フィルタするように更新するべきです。

Step 13: バリデーションルール ‘xss_clean’ の使い方をチェックする¶

XSS クリーニングについて広く知られていないルールとして、 入力データに対してではなく、出力にのみ適用すべき があります。

我々は自動グローバル XSS クリーニング機能（上の XSS についてのステップを参照） においてミスを犯しました。そのため、現在、そのような実践に反対するために、 フォームバリデーション のルールの 公式サポートリストから、’xss_clean’ を削除しています。

何故なら、フォームバリデーションライブラリ は一般的に 入力 データを検証するため、 ‘xss_clean’ ルールは単純にそこに属さないからです。

もし本当に本当にそのルールを適用する必要があるなら、 通常の関数として xss_clean() が含まれる Security ヘルパー をロードしてください。 通常の関数なら検証ルールとして今でも使用できます。

Step 14: 入力クラスの get_post() メソッドの使い方を更新する¶

以前は、 Input クラス の get_post() メソッドは最初に POST データを探し、それから GET データを探しました。 このメソッドは、その名前が示すように、GET を先に探しその後 POST を 探すように変更されました。

以前と同じようにするために、POST を先に探し GET を探す post_get() メソッドが追加されました。

Step 15: ディレクトリヘルパーの directory_map() 関数の使い方を更新する¶

結果の配列の中で、ディレクトリはディレクトリセパレータ（通常はスラッシュ） で終わるようになりました。

Step 16: データベースフォージの drop_table() メソッドの使い方を更新する¶

今まで drop_table() は IF EXISTS 句をデフォルトで追加していましたが、 いくつかのドライバでは全く動作しませんでした。 CodeIgniter 3.0 では、IF EXISTS 条件はデフォルトでは追加されず、 オプションの第 2 引数が追加され、デフォルトは FALSE です。

もし、アプリケーションが IF EXISTS を使っているなら、使い方を変更する必要があります。

// 今は DROP TABLE `table_name` だけを生成します
$this->dbforge->drop_table('table_name');

// DROP TABLE IF EXISTS `table_name` を生成します
$this->dbforge->drop_table('table_name', TRUE);

Step 17: Email ライブラリでの複数メールの扱いを変更する¶

Email ライブラリ は、メール送信が成功した後に、 自動的に設定されたパラメータをクリアします。 この振る舞いを上書きしたい場合は、send() メソッドの第 1 引数に FALSE を渡します:

if ($this->email->send(FALSE))
{
        // パラメータはクリアされません
}

Step 18: Form_validation の言語ファイルを更新する¶

Form Validation ライブラリ の 言語 ファイルとエラーメッセージのフォーマットに 2 つの改良が加えられました:

• Language ライブラリ の行のキーは、衝突を 避けるために、接頭辞 form_validation_ を付けなければなりません:

  // 以前
  $lang['rule'] = ...
  
  // 今後
  $lang['form_validation_rule'] = ...
  

• エラーメッセージのフォーマットが名前付きパラメータを使うように変更されました。 sprintf() よりも柔軟にするためです:

  // 以前
  'The %s field does not match the %s field.'
  
  // 今後
  'The {field} field does not match the {param} field.'
  

Step 19: ‘base_url’ の設定値が空でないことを確認する¶

$config['base_url'] が設定されていないとき、CodeIgniter は Web サイトの ベース URL を自動的に検知しようとします。これは、純粋に新しいアプリケーションの 開発を開始する際、便利なようになされているものです。

自動検知は決して信頼できるものではなく、セキュリティと関連します。 だから、いつでも 手動で設定すべきものです。

CodeIgniter 3.0.3 での変更点の 1 つは、自動検知がどう機能するかです。 より具体的に言えば、クライアントによりリクエストされたホスト名ではなく、 サーバの IP アドレスにフォールバックするようになりました。ゆえに、 もしあなたが自動検知に頼っている場合、Web サイトの振る舞いが変更されるでしょう。

例えば、複数のドメインを使っていたり、http:// と https:// の両方のプリフィックス をリクエストに応じて動的に使っている場合、 application/config/config.php は PHP スクリプトであることを思い出してください。 例えば、次のような数行のコードでロジックを記述できます:

$allowed_domains = array('domain1.tld', 'domain2.tld');
$default_domain  = 'domain1.tld';

if (in_array($_SERVER['HTTP_HOST'], $allowed_domains, TRUE))
{
        $domain = $_SERVER['HTTP_HOST'];
}
else
{
        $domain = $default_domain;
}

if ( ! empty($_SERVER['HTTPS']))
{
        $config['base_url'] = 'https://'.$domain;
}
else
{
        $config['base_url'] = 'http://'.$domain;
}

Step 20: (以前から) 廃止予定の機能を削除する¶

$autoload['core'] の設定以外にも、CodeIgniter 3.0.0 で削除された機能は たくさんあります。

// 以前の方法
standard_date(); // デフォルトは standard_date('DATE_RFC822', now());

// 置き換え
date(DATE_RFC822, now());

// 以前の方法
standard_date('DATE_ATOM', $time);

// 置き換え
date(DATE_ATOM, $time);

$this->session->userdata();

// 以前の使い方:
$field = array(
        'new_field' => array('type' => 'TEXT')
);

$this->dbforge->add_column('table_name', $field, 'another_field');

// 新しい使い方:
$field = array(
        'new_field' => array('type' => 'TEXT', 'after' => 'another_field')
);

$this->dbforge->add_column('table_name', $field);

$this->router->directory;
$this->router->class;
$this->router->method;

// 以前
$this->input->is_cli_request();

// 以後
is_cli();

Step 21: Text ヘルパーの highlight_phrase() の使い方を確認する¶

Text ヘルパー の highlight_phrase() 関数が使うデフォルトの HTML タグは <strong> から 新しい HTML5 の <mark> タグに変更されました。

独自のハイライトタグを使っていない限り、この変更は Internet Explorer 8 のような より古い Web ブラウザを使っているユーザにトラブルを起こすかも知れません。 そこで、古いブラウザでの後方互換のために、以下のコードを CSS ファイルに 追加することを提案します:

mark {
        background: #ff0;
        color: #000;
};