Upgrade Codeigniter from 1.7.2 to 3.1.6

Question

I need to upgrade my codeigniter from 1.7.2 to 3.1.6. I see that there are a lot of intermediate version in between. Is there a quick way or I should follow every update in between?

Answer 1

I just upgraded from 2.1.6 to 3.1.6. Easiest way to do it is a fresh install of 3.1.6 in a new directory. Configure everything similar to your current prod site... config.php, database.php, .htaccess, etc, etc. Copy all your controllers/models/views from your prod site to your new site. Remember to rename your new model/controller/library files with the proper Ucase notation... ex: home.php becomes Home.php in 3.x.

Once you've tested the new site, simply rename your directories to switch from old to new. Way easier than trying to modify your old site. And if you ever need to revert, your old site is still there.

Answer 2

As per the documentation of official Codeigniter it says that you need to follow step by step to upgrade it. Here is the link Upgradation Link for official CI Website . Somehow by researching I got to know about this steps 1. You need to anyhow manually update to 2.2.x by using above link, but after this version you can directly jump to version 3.x

Here is the way:

Pre-required Warning: Before performing an update you should take your site offline by replacing the index.php file with a static one.

Step 1: Update your CodeIgniter files Replace all files and directories in your system/ directory and replace your index.php file. If any modifications were made to your index.php they will need to be made fresh in this new one.

Note : You have to delete the old system/ directory first and then put the new one in its place. A simple copy-paste may cause issues.

Step 2: Update your classes file names Starting with CodeIgniter 3.0, all class filenames (libraries, drivers, controllers and models) must be named in a Ucfirst-like manner or in other words - they must start with a capital letter.

For example, if you have the following library file:

application/libraries/mylibrary.php

… then you'll have to rename it to:

application/libraries/Mylibrary.php

The same goes for driver libraries and extensions and/or overrides of CodeIgniter's own libraries and core classes.

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

The above files should respectively be renamed to the following:

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

Controllers:

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

Models:

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

Please note that this DOES NOT affect directories, configuration files, views, helpers, hooks and anything else - it is only applied to classes.

You must now follow just one simple rule - class names in Ucfirst and everything else in lowercase.

Step 3: Replace config/mimes.php This config file has been updated to contain more user mime-types, please copy it to application/config/mimes.php.

Step 4: Remove $autoload['core'] from your config/autoload.php

Use of the $autoload['core'] config array has been deprecated as of CodeIgniter 1.4.1 and is now removed. Move any entries that you might have listed there to $autoload['libraries'] instead. Step 5: Move your Log class overrides or extensions

The Log Class is considered as a “core” class and is now located in the system/core/ directory. Therefore, in order for your Log class overrides or extensions to work, you need to move them to application/core/:

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

Step 6: Update your Session library usage

The Session Library has been completely re-written in CodeIgniter 3 and now comes with a bunch of new features, but that also means that there are changes that you should make … A few configuration options have been removed and a few have been added. You should really read the whole Session library manual for the details, but here's a short list of changes that you should make:

    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'));

Finally, if you have written a Session extension, you must now move it to the application/libraries/Session/ directory, although chances are that it will now also have to be re-factored.

Step 7: Update your config/database.php

Due to 3.0.0's renaming of Active Record to Query Builder, inside your config/database.php, you will need to rename the $active_record variable to $query_builder:

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

Step 8: Replace your error templates

In CodeIgniter 3.0, the error templates are now considered as views and have been moved to the application/views/errors directory.

Furthermore, we've added support for CLI error templates in plain-text format that unlike HTML, is suitable for the command line. This of course requires another level of separation.

It is safe to move your old templates from application/errors to application/views/errors/html, but you'll have to copy the new application/views/errors/cli directory from the CodeIgniter archive. Step 9: Update your config/routes.php file Routes containing :any

Historically, CodeIgniter has always provided the :any wildcard in routing, with the intention of providing a way to match any character within an URI segment.

However, the :any wildcard is actually just an alias for a regular expression and used to be executed in that manner as .+. This is considered a bug, as it also matches the / (forward slash) character, which is the URI segment delimiter and that was never the intention.

In CodeIgniter 3, the :any wildcard will now represent [^/]+, so that it will not match a forward slash.

There are certainly many developers that have utilized this bug as an actual feature. If you're one of them and want to match a forward slash, please use the .+ regular expression:

(.+) // matches ANYTHING (:any) // matches any character, except for '/'

Directories and 'default_controller', '404_override'

As you should know, the $route['default_controller'] and $route['404_override'] settings accept not only a controller name, but also controller/method pairs. However, a bug in the routing logic has made it possible for some users to use that as directory/controller instead.

As already said, this behavior was incidental and was never intended, nor documented. If you've relied on it, your application will break with CodeIgniter 3.0.

Another notable change in version 3 is that 'default_controller' and '404_override' are now applied per directory. To explain what this means, let's take the following example:

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

Now, assuming that your website is located at example.com, you already know that if a user visits http://example.com/ , the above setting will cause your 'Main' controller to be loaded.

However, what happens if you have an application/controllers/admin/ directory and the user visits http://example.com/admin/ ? In CodeIgniter 3, the router will look for a 'Main' controller under the admin/ directory as well. If not found, a Not Found (404) will be triggered.

The same rule applies to the '404_override' setting.

Final step : For all further missing files/folders/settings here is the link Link