將Codeigniter從1.7.2升級到3.1.6

Question

我需要將Codeigniter從1.7.2升級到3.1.6。 我看到兩者之間有很多中間版本。 有沒有一種快速的方法，或者我應該關注之間的每個更新？

Answer 1

我剛剛從2.1.6升級到3.1.6。 最簡單的方法是在新目錄中全新安裝3.1.6。 配置與您當前的生產站點類似的所有內容... config.php，database.php，.htaccess等，等等。將所有控制器/模型/視圖從生產站點復制到新站點。 記住要使用正確的Ucase標記來重命名新的模型/控制器/庫文件...例如：home.php在3.x中變為Home.php。

測試新站點后，只需重命名目錄即可從舊目錄切換到新目錄。 比嘗試修改舊站點更容易。 而且，如果您需要還原，則舊站點仍然存在。

Answer 2

根據官方Codeigniter的文檔，它說您需要逐步進行升級。 這是官方CI網站的升級鏈接 。 通過某種方式的研究，我對步驟1有所了解。您需要通過上述鏈接手動更新到2.2.x，但是在此版本之后，您可以直接跳至3.x版本

方法如下：

前提條件警告：在執行更新之前，您應該通過將index.php文件替換為靜態文件來使站點離線。

步驟1：更新您的CodeIgniter文件替換system /目錄中的所有文件和目錄，並替換index.php文件。 如果對您的index.php進行了任何修改，則需要在此新版本中重新進行修改。

注意 ：您必須先刪除舊的system /目錄，然后將新目錄放到原位置。 簡單的復制粘貼可能會導致問題。

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

請注意，這不會影響目錄，配置文件，視圖，幫助程序，掛鈎和其他任何內容-它僅適用於類。

現在，您必須遵循一個簡單的規則-Ucfirst中的類名，其他所有內容都小寫。

步驟3：替換config / mimes.php此配置文件已更新，以包含更多用戶mime類型，請將其復制到application / config / mimes.php。

步驟4：從您的config / autoload.php中刪除$ autoload ['core']

自$ CodeIgniter 1.4.1起，已不建議使用$ autoload ['core']配置數組，現已將其刪除。 而是將您可能已在其中列出的所有條目移動到$ autoload ['libraries']。 步驟5：移動您的Log類替代或擴展

日志類被認為是“核心”類，現在位於system / core /目錄中。 因此，為了使您的Log類覆蓋或擴展起作用，您需要將它們移至application / core /：

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

步驟6：更新您的會話庫使用情況

會話庫已在CodeIgniter 3中完全重寫，現在具有許多新功能，但這也意味着您應該進行一些更改…刪除了一些配置選項，並添加了一些配置選項。 您應該真正閱讀整個會話庫手冊以了解詳細信息，但是這里是您應該進行的簡短更改列表：

    Set your $config['sess_driver'] value

    It will default to ‘files’, unless you’ve previously used $config['sess_use_database'], in which case it will be set to ‘database’.

    Set a $config['sess_save_path'] value

    For the ‘database’ driver, a fallback to $config['sess_table_name'] is in place, but otherwise requires you to read the manual for the specific driver of your choice.

    Update your ci_sessions table (‘database’ driver only)

    The table structure has changed a bit, and more specifically:

            session_id field is renamed to id
            user_agent field is dropped
            user_data field is renamed to data and under MySQL is now of type BLOB
            last_activity field is renamed to timestamp

    This is accompanied by a slight change in the table indexes too, so please read the manual about the Session Database Driver for more information.

    Remove $config['sess_match_useragent']

    The user-agent string is input supplied by the user’s browser, or in other words: client side input. As such, it is an ineffective feature and hence why it has been removed.

    Remove $config['sess_encrypt_cookie']

    As already noted, the library no longer uses cookies as a storage mechanism, which renders this option useless.

    Remove $config['sess_expire_on_close']

    This option is still usable, but only for backwards compatibility purposes and it should be otherwise removed. The same effect is achieved by setting $config['sess_expiration'] to 0.

    Check “flashdata” for collisions with “userdata”

    Flashdata is now just regular “userdata”, only marked for deletion on the next request. In other words: you can’t have both “userdata” and “flashdata” with the same name, because it’s the same thing.

    Check usage of session metadata

    Previously, you could access the ‘session_id’, ‘ip_address’, ‘user_agent’ and ‘last_activity’ metadata items as userdata. This is no longer possible, and you should read the notes about Session Metadata if your application relies on those values.

    Check unset_userdata() usage

    Previously, this method used to accept an associative array of 'key' => 'dummy value' pairs for unsetting multiple keys. That however makes no sense and you now have to pass only the keys, as the elements of an array.

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

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

最后，如果您已經編寫了Session擴展，則現在必須將其移至application/libraries/Session/ directory,盡管有可能現在也必須對其進行重構。

步驟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：更換錯誤模板

在CodeIgniter 3.0中，錯誤模板現在被視為視圖，並已移至application / views / errors目錄。

此外，我們添加了對純文本格式的CLI錯誤模板的支持，該格式不同於HTML，適用於命令行。 當然，這需要另一個層次的分離。

將舊模板從application / errors移到application / views / errors / html是安全的，但是您必須從CodeIgniter存檔中復制新的application / views / errors / cli目錄。 步驟9：更新您的config / routes.php文件包含：any的路由

從歷史上看，CodeIgniter始終在路由中提供：any通配符，目的是提供一種匹配URI段中任何字符的方法。

但是，：any通配符實際上只是正則表達式的別名，並且以前以。+的方式執行。 這被認為是一個錯誤，因為它也與/（正斜杠）字符匹配，該字符是URI段定界符，而絕不是故意的。

在CodeIgniter 3中，：any通配符現在將表示[^ /] +，因此它將不與正斜杠匹配。

當然，有很多開發人員已將此錯誤用作實際功能。 如果您是其中之一，並且想匹配正斜杠，請使用。+正則表達式：

（。+）//匹配任何內容（：any）//匹配任何字符，除了'/'

目錄和“ default_controller”，“ 404_override”

如您所知，$ route ['default_controller']和$ route ['404_override']設置不僅接受控制器名稱，而且接受控制器/方法對。 但是，路由邏輯中的錯誤使某些用戶可以將其用作目錄/控制器。

如前所述，此行為是偶然的，並且從未計划或記錄在案。 如果您依賴它，您的應用程序將隨CodeIgniter 3.0一起中斷。

版本3中的另一個顯着變化是，現在每個目錄都應用了“ default_controller”和“ 404_override”。 為了解釋這意味着什么，讓我們看下面的例子：

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

現在，假設您的網站位於example.com，您已經知道，如果用戶訪問http://example.com/ ，則上述設置將導致加載“主”控制器。

但是，如果您有一個application / controllers / admin /目錄，並且用戶訪問了http://example.com/admin/ ，該怎么辦？ 在CodeIgniter 3中，路由器還將在admin /目錄下查找“主”控制器。 如果未找到，則將觸發“未找到”（404）。

相同的規則適用於“ 404_override”設置。

最后一步：對於所有其他丟失的文件/文件夾/設置，這里是鏈接Link