• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Upgrading a project

#1
I purchased a project off Envato to use as a baseline to build on.

It is written using 3.0.0. Would it be recommended to update it to a later version?
Reply

#2
Yes it would because of security issues.
What did you Try? What did you Get? What did you Expect?

Joined the CodeIgniter Community in 2009.          ( Skype: insitfx )
Reply

#3
I would require the author to update the application for you or request a refund.
Reply

#4
I have already baught some code from Evanto updates dont always follow as expected.
Note also that not all evanto code is out of box ready to go you will surly need to make some modifications to exsisting projet.
so I would go with upgrading myself (good way to learn).
doesn't cost anything but time to try and arror Smile.

Lets hope that the authors have respected CI coding standards and they have not used other extentions like HMVC or some sort of auth plugin etc..

Have a look here for here for the different upgrades of CI,  15 in all between 3.0.0 to 3.1.8
some only require a system replace.

others need some small modifications.

See list below

info found here.
https://www.codeigniter.com/user_guide/i...ading.html

The modifications

Step 1: Update your CodeIgniter files  for all updates 3.0.0 to 3.1.18
Replace all files and directories in your system/ directory.

below are the other changes needed to be made for each upgrade that includes more than step 1 instructions.


Upgrading from 3.0.0 to 3.0.1


Step 2: Update your CLI error templates
Replace all files under your application/views/errors/cli/ directory.


Upgrading from 3.0.1 to 3.0.2

Step 2: Update your application/config/constants.php file
The application/config/constants.php file has been updated to check if constants aren’t already defined before doing that, making it easier to add an environment-specific configuration.

Upgrading from 3.0.2 to 3.0.3

Step 2: Make sure your ‘base_url’ config value is not empty
When $config['base_url'] is not set, CodeIgniter tries to automatically detect what your website’s base URL is. This is done purely for convenience when you are starting development of a new application.

Auto-detection is never reliable and also has security implications, which is why you should always have it manually configured!

One of the changes in CodeIgniter 3.0.3 is how this auto-detection works, and more specifically it now falls back to the server’s IP address instead of the hostname requested by the client. Therefore, if you’ve ever relied on auto-detection, it will change how your website works now.

In case you need to allow e.g. multiple domains, or both http:// and https:// prefixes to be dynamically used depending on the request, remember that application/config/config.php is still a PHP script, in which you can create this logic with a few lines of code. For example:

$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;
}


Upgrading from 3.0.5 to 3.0.6

Step 2: Update your index.php file (optional)
We’ve made some tweaks to the index.php file, mostly related to proper usage of directory separators (i.e. use the DIRECTORY_SEPARATOR constant instead of a hard coded forward slash “/”).

Nothing will break if you skip this step, but if you’re running Windows or just want to be up to date with every change - we do recommend that you update your index.php file.

Tip: Just copy the ``ENVIRONMENT``, ``$system_path``, ``$application_folder`` and ``$view_folder`` declarations from the old file and put them into the new one, replacing the defaults.

Step 3: Remove ‘prep_for_form’ usage (deprecation)
The Form Validation Library has a prep_for_form() method, which is/can also be used as a rule in set_rules() to automatically perform HTML encoding on input data.

Automatically encoding input (instead of output) data is a bad practice in the first place, and CodeIgniter and PHP itself offer other alternatives to this method anyway. For example, Form Helper functions will automatically perform HTML escaping when necessary.

Therefore, the prep_for_form method/rule is pretty much useless and is now deprecated and scheduled for removal in 3.1+.


Upgrading from 3.0.6 to 3.1.0

Step 2: Check your PHP version
We recommend always running versions that are currently supported, which right now is at least PHP 5.6.

PHP 5.2.x versions are now officially not supported by CodeIgniter, and while 5.3.7+ may be at least runnable, we strongly discourage you from using any PHP versions below the ones listed on the PHP.net Supported Versions page.

Step 3: If you’re using the ‘odbc’ database driver, check for usage of Query Builder
Query Builder functionality and escape() can no longer be used with the ‘odbc’ database driver.

This is because, due to its nature, the ODBC extension for PHP does not provide a function that allows to safely escape user-supplied strings for usage inside an SQL query (which our Query Builder relies on).

Thus, user inputs MUST be bound, as shown in Running Queries, under the “Query Bindings” section.

Upgrading from 3.1.1 to 3.1.2

Step 2: Update your “ci_sessions” database table
If you’re using the Session Library with the ‘database’ driver, you may have to ALTER your sessions table for your sessions to continue to work.

Note

The table in question is not necessarily named “ci_sessions”. It is what you’ve set as your $config['sess_save_path'].

This will only affect you if you’ve changed your session.hash_function php.ini setting to something like ‘sha512’. Or if you’ve been running an older CodeIgniter version on PHP 7.1+.

It is recommended that you do this anyway, just to avoid potential issues in the future if you do change your configuration.

Just execute the one of the following SQL queries, depending on your database:

// MySQL:
ALTER TABLE ci_sessions CHANGE id id varchar(128) NOT NULL;

// PostgreSQL
ALTER TABLE ci_sessions ALTER COLUMN id SET DATA TYPE varchar(128);

Upgrading from 3.1.2 to 3.1.3

Step 2: Remove usage of nice_date() helper (deprecation)
The Date Helper function nice_date() is no longer useful since the introduction of PHP’s DateTime classes

You can replace it with the following:

DateTime::createFromFormat($input_format, $input_date)->format($desired_output_format);
Thus, nice_date() is now deprecated and scheduled for removal in CodeIgniter 3.2+.

Note

The function is still available, but you’re strongly encouraged to remove its usage sooner rather than later.

Step 3: Remove usage of $config[‘standardize_newlines’]
The Input Library would optionally replace occurrences of rn, r, n in input data with whatever the PHP_EOL value is on your system - if you’ve set $config['standardize_newlines'] to TRUE in your application/config/config.php.

This functionality is now deprecated and scheduled for removal in CodeIgniter 3.2.+.

Upgrading from 3.1.5 to 3.1.6

Step 2: Remove usage of the APC Cache driver (deprecation)
The Cache Library APC driver is now deprecated, as the APC extension is effectively dead, as explained in its PHP Manual page.

If your application happens to be using it, you can switch to another cache driver, as APC support will be removed in a future CodeIgniter version.

Upgrading from 3.1.6 to 3.1.7

Step 2: Remove usage of CAPTCHA helper extra parameters (deprecation)
The CAPTCHA Helper function create_captcha() allows passing of its img_path, img_url and font_path options as the 2nd, 3rd and 4th parameters respectively.

This kind of usage is now deprecated and you should just pass the options in question as part of the first parameter array.
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


Users browsing this thread:
1 Guest(s)


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2018 MyBB Group.