[翻譯]CI從2.2升級到3.0

英文原文

從2.2 升級到3.0 更新以前先保證網站處於離線狀態.

步驟 1: 更新 CI 全部文件

替換 system 目錄下全部文件,而後替換index.php文件,若是以前有更新index.php,請在新的文件上作更改.

你必須先刪除舊的system/目錄，而後把它放到其它 的地方.直接簡單的複製過去可能會致使問題.

若是您在這些文件夾中有任何自定義功能的文件，請先複製它們.

步驟 2: 更新你的類的文件名

從CI 3.0開始,全部的類文件名(庫,驅動,控制器,模型)必須首字母大寫的形式,必須大寫字母開頭. 例如:

application/libraries/mylibrary.php

須要更改爲

application/libraries/Mylibrary.php

一樣的有,驅動庫,擴展和對CI 核心庫的擴展

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

請注意這並不影響目錄,配置文件,視圖,輔助,鉤子或其它,只是做用於類 你如今必須記住一個簡單規則 -類的文件名首字母大寫,除此以外所有小寫

步驟 3: 替換 config/mimes.php 文件

這個文件更新了更多的用戶mime類型, 請複製這個文件到 應用目錄下/config/mimes.php.

步驟 4: 在config/autoload.php 文件中移除 $autoload['core'] 配置選項

從CI 1.4.1開始$autoload['core'] 配置就已通過時了,如今移除了,使用$autoload['libraries']配置來替代.

步驟 5：移動你的日誌類(包括重寫的和擴展之類)

日誌類被做爲是一個「核心」類，如今位於system/core/ 目錄下,所以,爲了你的日誌類(重寫或擴展)能工做,必須移動到application/core/目錄下:

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

步驟 6: 更新Session 庫的用法

在CI 3.0中Session庫是徹底重寫的,而且有不少新特性,但也意味着須要做出改變...

最值得注意的地方是，該庫如今使用單獨的存儲驅動程序,而不是始終依賴於(加密)的cookies.事實上,cookies做爲存儲已被刪除,你必須始終使用服務器端存儲引擎，默認的選項是使用文件.

Session 類如今使用PHP自身的機制構建自定義會話句柄，這也意味着，您的會話數據如今能夠經過全局$_SESSION 變量來訪問(雖然，咱們不可能把它做爲「userdata」，就像如今這樣)

幾個配置選項已被刪除,而且也添加了幾個.你應該閱讀整個SESSION庫手冊的詳細資料,下面是一個簡短的列表，變化包括：

• 設置$config['sess_driver']配置的值 默認值爲file,若是有設置 $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 數據庫部分的詳細手冊獲取更多信息

只有MySQL和PostgreSQL官方支持.其餘數據庫可能能夠工做，但因爲缺乏協同鎖(Advisory lock)功能，它們是不安全的併發請求,你應該考慮使用其它的驅動程序.

• 移除 $config['sess_match_useragent'] 配置 用戶user-agent字符串是用戶的瀏覽器輸入的,或者說是客戶端輸入.所以,它的功能意義並不大,已經被移除了.

• 移除 $config['sess_encrypt_cookie'] 配置 正如上面所說,cookie庫不在做爲一個存儲機制,這個選項也沒有做用了.

• 移除 $config['sess_expire_on_close'] 配置

此選項仍可使用，但僅用於向後兼容的目的,不然應刪除.經過設置$config['sess_expiration']的值爲0來實現一樣的效果。

• 檢查 "userdata"中與"flashdata"的衝突

flashdata如今只是普通的"userdata"的一部分,只是標記爲在下一個請求時刪除。換句話說,你不能有「userdata」和「flashdata」具備相同的名稱，由於它是同一個內容裏面。

• 檢查 session的 元數據內容(metadata)

之前,你能夠訪問「session_id','ip_address','user_agent'和'last_activity'元數據項目的用戶數據.如今這是不可能的，若是你的應用程序依賴於這些值，你應該閱讀session元數據的手冊內容。

• 檢查 unset_userdata() 用法

之前,該方法接受一個關聯數組的'key'=>'value' 多維數組.然而,這是沒有意義的，你如今只有經過keys，做爲數組的元素.

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

// 如今
$this->session->unset_userdata(array('item', 'item2'));

最後,若是你寫了一個Session 擴展,必須把擴展文件放入 application/libraries/Session/ 目錄下

步驟 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;

步驟 8: 替換錯誤模板(error templates)

在CI 3.0中,錯誤模板被做爲視圖移動到應用目錄/views/errors* 目錄下. 此外，咱們增長了命令行錯誤模板在普通文本格式的，不像HTML那樣，適用於命令行.這固然須要必定的層次分離. 比較安全的作法是,把之前的模板從應用目錄/errors* 移動到應用目錄/views/errors/html*,可是,你須要從相應CI庫的文件中拷貝放入應用目錄/views/errors/cli* 文件目錄中

步驟 9: 更新 config/routes.php 文件

#####路由規則包括 :any

一直以來,CI 在路由匹配中已經提供了通配符 :any 來匹配任意字符的的一種方式

然而,通配符 :any 其實只是一個別名爲正則表達式，用於在方法執行.+,這是錯誤的，由於它也包括符號/（斜線）字符，這是URI段分隔符,沒有意義.

在CI 3.0中,通配符 :any 講表明 [^/]+,因此不會匹配到 / (斜線).

有許多開發人員用到了這個功能.若是你是其中的一個,想要匹配一個正斜槓,請使用.+表達式：

(.+)    //  匹配任意字符 
(:any)  //  匹配任意字符,除了'/'

目錄和默認控制器(default_controller),404重寫(404_override)

咱們知道，$route['default_controller'] 和 $route['404_override'] 的設置 不只能夠設置爲一個控制器名稱,也能夠設置爲控制器/方法名稱。然而,可能的一些用戶使用 目錄/控制器這種方式來使用.

正如已經說過的,這種行爲是附帶的,不是逾期的,也沒有文檔說明.若是你已經用到它了,你的應用可能影響到CI。

在3.0中的另外一個顯著的變化是,'default_controller'和'404_override'如今支持每一個應用的目錄了,下面來解釋一下,看下面的例子：

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

如今,假設你的網站是位於example.com，咱們已經知道,若是一個用戶訪問http://example.com, 上面的設置會首先加載 'Main' 控制器.

然而,若是你有一個application/controllers/admin/ 和用戶訪問http://example.com/admin/ 會發生什麼? 在CI 3.0中,路由會首先尋找 admin/ 目錄下的'Main' 控制器爲好,若是未找到,將會觸發 Not Found (404)。

一樣的規則也適用於 '404_override' 設置

步驟 10: 不少函數返回值爲空代替以前的FALSE(在找不到參數項時)

須要方法和函數如今在找到不到參數項的時候返回FALSE代替NULL:

• Common functions config_item() Config Class config->item() config->slash_item()
• Input Class input->get() input->post() input->get_post() input->cookie() input->server() input->input_stream() input->get_request_header()
• Session Class session->userdata() session->flashdata()
• URI Class uri->segment() uri->rsegment()
• Array Helper element() elements()

步驟 11: XSS 過濾器的用法

在CI的許多方法容許你經過一個布爾參數來決定是否使用XSS過濾器,這個參數的默認值是FALSE,可是如今改爲NULL,而且是由$config['global_xss_filtering']配置的值來決定. 若是你手動改變 $xss_filter 參數的值或者$config['global_xss_filtering']的值一直設置爲FALSE,那麼這種用法改變不會影響到你.

不然,須要查看如下函數的用法:

//Input Library
input->get()
input->post()
input->get_post()
input->cookie()
input->server()
input->input_stream()
//Cookie Helper 
get_cookie()

另外一個相關的變化是，當全局XSS過濾器打開的時候, $_GET, $_POST, $_COOKIE and $_SERVER superglobals再也不自動覆蓋

步驟 12: Check for potential XSS issues with URIs

步驟 12: 檢查與URIs相關的潛在XSS問題

URI 庫用來自動轉換在URI中遇到的特殊字符爲HTML轉義字符. 除了在$config['permitted_uri_chars']中配置內容外,這是爲了提供自動的XSS保護的,但已被證實是有問題的,在CI 3.0中被移除.

若是在你的應用中依賴這個特性,你應該經過$this->security->xss_clean()來過濾URI段的輸出

步驟 13: 檢查驗證規則中的 xss_clean用法

大量的XSS 清理規則應該做用於輸出,而不是改變輸入數據. 咱們在自動處理和全局XSS處理功能上犯了一些錯誤(參考前面XSS處理部分),因此如今努力阻止這種作法,咱們從驗證規則中移除了xss_clean處理的這部分功能. 由於Validation 庫主要是處理輸入數據,xss_clean 放在一塊兒不合適,不屬於這裏. 若是你確實須要使用這個功能，你能夠加載 Security 助手,裏面包含xss_clean(),

步驟 14: 更新輸入類的方法get_post()

之前，輸入類的方法get_post()首先在POST請求中搜索數據，而後纔是GET請求的數據.這種方法已被修改爲先是GET,而後是POST，正如它的名字同樣,而後增長了一個方法post_get(),先搜索POST,後GET,和之前get_post()的功能同樣.

步驟 15: 更新 目錄助手函數directory_map()

在數組結果中，目錄如今以一個尾隨目錄分隔符結束(一般爲斜線)

步驟 16: 更新數據庫的 drop_table() 方法

到目前爲止,drop_table() 函數默認加上了IF EXISTS,可是大多數數據庫驅動是不能工做的. 在CI 3.0中,默認不會添加 IF EXISTS條件了,而且第二個參數是可選的,默認是FALSE.

若是你的應用是加上了IF EXISTS判斷的話,不用作任何改變.

// 如今只是刪除表'table_name'
$this->dbforge->drop_table('table_name');

// 存在表'table_name'的話便刪除
$this->dbforge->drop_table('table_name', TRUE);

示例使用MySQL特定的語法，但它應該工做在除ODBC的之外全部數據庫驅動.

步驟 17: 郵件庫的多封郵件發送方法

發送郵件成功後會自動清除發送設置的參數,在send()方法中設置的第一參數爲FALSE時,就不會清除設置的參數,以下:

if ($this->email->send(FALSE))
{
    // Parameters won't be cleared
}

步驟 18: 更新表單驗證的語言方式

對於表單驗證庫的語言包文件和錯誤信息的格式有兩點改進:

• 這裏是列表文本爲了不名字衝突，語言庫的索引鍵的前綴必須爲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.'

之前的方式還能夠繼續工做,但在CodeIgniter 3.1和之後的版本中，非前綴的索引鍵會被移除，所以應該儘早替換.

步驟 19: 刪除使用過期(舊)的功能用法

除了$autoload['core']配置選項之外,在 CI 3.0.0中移除了大量功能:

SHA1庫(SHA1)

之前的SHA1庫被移除了,只能使用php的原生函數sha1()了.
另外 Encrypt庫的sha1()方法也被移除了.

擴展名常量(The EXT constant)

自從放棄支持php4之後,一直不同意使用擴展名常量,如今CI新版本中也不須要有不一樣的文件擴展名了,只使用``.php``來代替了.

表情助手(Smiley helper)

表情助手是來自EllisLab's ExpressionEngine的產品,然而對於CI的框架來講做用不大，如今也被移除了.
另外,之前廢棄的函數js_insert_smiley()(從 1.7.2版本開始)如今被移除了.

加密庫(The Encrypt library)

根據大量漏洞報告,加密庫已通過時了.
新的加密庫使用MCrypt 擴展( /dev/urandom 可用) 或者 PHP 5.3.3 版本以上和 OpenSSL擴展,這彷佛不是比較方便,可是須要咱們使用正確使用的加密功能

加密庫一直會保持向後兼容

儘快使用新的加密庫

購物車庫(The Cart library)

購物車庫,對於CI來講,和表情助手同樣,計劃在CI 3.1+版本中移除.

如今仍可以使用,可是儘快移除此功能用法

數據庫驅動('mysql', 'sqlite', 'mssql', 'pdo/dblib')

mysql數據庫驅動使用的最老的mysql擴展,衆所周知,有些許底層問題,在PHP 5.5 和CI 3.0中已通過時了,使用mysqli擴展來代替

請使用'mysqli' 或者 'pdo/mysql' 做爲nysql數據庫驅動,mysql 驅動會在未來版本中移除.

同一緣由,sqlite, mssql 和 pdo/dblib (相似 pdo/mssql or pdo/sybase)驅動和mysql驅動同樣,從php5.3版本以來就沒有了.

所以,在CI 下一版本中,這些過期驅動會移除掉,應該使用sqlite3, sqlsrv or pdo/sqlsrv 更高級的驅動.

這些驅動如今還可使用,可是強烈建議儘快使用其它的.

#####加密助手函數do_hash()

加密助手函數do_hash()只是php原生函數hash()的別名,是過期的而且計劃在CI 3.1版本去掉.

這些函數如今還可使用,可是強烈建議儘早更換

$config['global_xss_filtering']的設置

上面已經描述過,XSS 過濾處理不該該在全部數據輸入的時候,所以 ```$config['global_xss_filtering']```的配置不是一個好策略,而後是過期的.

代替方法就是須要處理用戶端的數據時使用```xss_clean()```函數,或者使用相似HTML Purifier那樣去處理數據.

這些設置如今還可使用,可是強烈建議儘早更換

文件助手函數read_file()

文件助手函數read_file()只是php原生函數file_get_contents()的別名,是過期的而且計劃在CI 3.1版本去掉.

這些函數如今還可使用,可是強烈建議儘早更換

字符串助手函數repeater()

字符串助手函數repeater()只是php原生函數str_repeat()的別名,是過期的而且計劃在CI 3.1版本去掉.

這些函數如今還可使用,可是強烈建議儘早更換

字符串助手函數trim_slashes()

字符串助手函數trim_slashes()只是php原生函數trim()的別名(第二個參數有變化而已),是過期的而且計劃在CI 3.1+版本移除.

這些函數如今還可使用,可是強烈建議儘早更換

表單助手函數form_prep()

字符串助手函數form_prep()只是php原生函數html_escape()的別名,是過期的而且計劃在CI 3.1版本去掉.

請使用html_escape()函數替代

這些函數如今還可使用,可是強烈建議儘早更換

郵件助手函數

郵件助手函數總只有兩個函數方法

valid_email()

send_email() 兩個函數的別名分別是php原生函數filter_var() 和 mail(),所以,郵件助手是過期的,而且計劃在CI 3.1+版本移除.

這些函數如今還可使用,可是強烈建議儘早更換

數據助手函數standard_date()

數據助手函數standard_date()是過期的PHP常量,它與函數date() 提供功能是同樣的,此外,名字也相似,下面如何替換的例子:

// 之前方式 
standard_date(); // 至關於 standard_date('DATE_RFC822', now());

// 替換方式
date(DATE_RFC822, now());

// 之前方式
standard_date('DATE_ATOM', $time);

// 替換方式
date(DATE_ATOM, $time);

這些函數如今還可使用,可是強烈建議儘早更換,而且計劃在CI 3.1+版本移除.

HTML助手函數nbs(), br()

數據助手函數nbs() 和 br() 只是原生函數str_repeat()加上對&nbsp; 和 <br > 字符的處理.

由於只是原生php函數的別名,沒有提供功能做用,是過期的而且計劃在CI 3.1+版本去掉.

這些函數如今還可使用,可是強烈建議儘早更換

分頁庫'anchor_class'的設置

分頁庫如今支持添加任何HTML屬性的錨經過attributes設置,裏面已經包含了class設置,單獨的anchor_class設置已經屬於多餘了,正由於如此,'anchor_class'的設置是過期的,而且計劃在CI 3.1+版本移除.

這些函數如今還可使用,可是強烈建議儘早更換

字符串助手函數random_string()

字符串助手函數random_string()有兩個類型 'unique' 和 'encrypt'

當使用函數random_string(),兩個類型分別對應 md5 和 sha1的別名,是過期的而且計劃在CI 3.1+版本去掉.

這些選項如今還可使用,可是強烈建議儘早更換

URL助手分隔符'dash' 和 'underscore'

當使用url_title()函數時,你不該該使用長橫線和下劃線做爲單詞的分隔符,這個函數接受任意字符做爲分隔符,你應該用 '-' 代替'dash' 和 '_' 代替 'underscore' 參數.

dash 和 underscore 如今是做爲別名,計劃在CI 3.1+版本移除.

這些選項如今還可使用,可是強烈建議儘早更換

Session 庫的方法 all_userdata()

在變動日誌中看到 Session 庫的方法 userdata() 在沒有參數的狀況下返回全部的用戶session數據:

$this->session->userdata();

這樣的話使得all_userdata()方法是多餘的,只是做爲userdata()的別名而已,是過期的而且計劃在CI 3.1版本去掉.

此方法如今還可使用,可是強烈建議儘早更換

數據庫添加列方法 add_column()的AFTER功能變化

若是你使用了add_column()第三個參數用來定義添加數據庫列的AFTER 功能,須要改變用法. 第三個參數是過期的,計劃在CI 3.1+版本去掉. 你應該把AFTER的定義放在字段的定義數組內,以下例:

// 之前:
$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);

這個參數如今還可使用,可是強烈建議儘早更換

這個參數只是MYSQL和CUBRID數據庫支持,其它的數據庫不支持,會自動忽略它.

URI 路由方法 fetch_directory(),fetch_class(),fetch_method()

隨着CI_Router::$directory, CI_Router::$class and CI_Router::$method 變成公開屬性，而後它們的方法fetch_*()只是返回它們的屬性參數,沒有必要保留這些功能了. 它們屬於內部,未公開方法,可是爲了保持向後兼容性咱們須要選擇改變它們,如何有使用它們,能夠經過它們的屬性來替代：

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

這個方法如今還可使用,可是強烈建議儘早更換

輸入庫方法 is_cli_request()

加載輸入庫以前,CI 內部不少地方須要調用CI_Input::is_cli_request()這個必要的方法,基於此,由一個公用函數is_cli()來替代它,不過只是一個別名而已.

新的方法能夠在任意地方很是方便的使用

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

// 如今
is_cli();

CI_Input::is_cli_request() 如今是過期的而且計劃在CI 3.1+版本去掉.

註解

這個方法如今還可使用,可是強烈建議儘早更換

配置庫(Config) 方法 system_url()

CI_Config::system_url()的用法不太恰當,也就是說,從安全的角度講CI 的system 目錄不該該是公開訪問的目錄

因爲這個緣由,這個方法是過期的而且計劃在CI 3.1+版本移除.

這個方法如今還可使用,可是強烈建議儘早更換

Javascript 庫

JavaScript庫一直是一個「實驗」的狀態，歷來沒有真正有用的,也沒有找到一個恰當的解決辦法.

如今是過期的而且計劃在CI 3.1+版本去掉. 這個庫如今還可使用,可是強烈建議儘早更換

步驟 20: 檢查文本助手 (Text helper)的函數highlight_phrase()用法

文本助手功能函數highlight_phrase()默認的HTML標籤從<strong>更改成新的HTML5標籤<mark> 除非你已經使用了本身的高亮標籤，這可能會給你的瀏覽者帶來問題，好比使用IE8.所以咱們建議你將下面的代碼添加到你的CSS文件，爲了不與舊的瀏覽器的向後兼容性:

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