1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
|
#############################
Upgrading from 3.1.x to 3.2.x
#############################
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.
.. note:: If you have any custom developed files in these directories,
please make copies of them first.
Step 2: Check your PHP version
==============================
We recommend always running versions that are `currently supported
<https://secure.php.net/supported-versions.php>`_, which right now is at least PHP 5.6.
PHP 5.3.x versions are now officially not supported by CodeIgniter, and while 5.4.8+
may be at least runnable, we strongly discourage you from using any PHP versions below
the ones listed on the `PHP.net Supported Versions <https://secure.php.net/supported-versions.php>`_
page.
Step 3: Change database connection handling
===========================================
"Loading" a database, whether by using the *config/autoload.php* settings
or manually via calling ``$this->load->database()`` or the less-known
``DB()`` function, will now throw a ``RuntimeException`` in case of a
failure.
In addition, being unable to set the configured character set is now also
considered a connection failure.
.. note:: This has been the case for most database drivers in the in the
past as well (i.e. all but the 'mysql', 'mysqli' and 'postgre'
drivers).
What this means is that if you're unable to connect to a database, or
have an erroneous character set configured, CodeIgniter will no longer
fail silently, but will throw an exception instead.
You may choose to explicitly catch it (and for that purpose you can't use
*config/autoload.php* to load the :doc:`Database Class <../database/index>`)
::
try
{
$this->load->database();
}
catch (RuntimeException $e)
{
// Handle the failure
}
Or you may leave it to CodeIgniter's default exception handler, which would
log the error message and display an error screen if you're running in
development mode.
Remove db_set_charset() calls
-----------------------------
With the above-mentioned changes, the purpose of the ``db_set_charset()``
method would now only be to change the connection character set at runtime.
That doesn't make sense and that's the reason why most database drivers
don't support it at all.
Thus, ``db_set_charset()`` is no longer necessary and is removed.
Step 4: Check logic related to URI parsing of CLI requests
==========================================================
When running a CodeIgniter application from the CLI, the
:doc:`URI Library <../libraries/uri>` will now ignore the
``$config['url_suffix']`` and ``$config['permitted_uri_chars']``
configuration settings.
These two options don't make sense under the command line (which is why
this change was made) and therefore you shouldn't be affected by this, but
if you've relied on them for some reason, you'd probably have to make some
changes to your code.
Step 5: Check Cache Library configurations for Redis, Memcache(d)
=================================================================
The new improvements for the 'redis' and 'memcached' drivers of the
:doc:`Cache Library <../libraries/caching>` may require some small
adjustments to your configuration values ...
Redis
-----
If you're using the 'redis' driver with a UNIX socket connection, you'll
have to move the socket path from ``$config['socket']`` to
``$config['host']`` instead.
The ``$config['socket_type']`` option is also removed, although that won't
affect your application - it will be ignored and the connection type will
be determined by the format used for ``$config['host']`` instead.
Memcache(d)
-----------
The 'memcached' will now ignore configurations that don't specify a ``host``
value (previously, it just set the host to the default '127.0.0.1').
Therefore, if you've added a configuration that only sets e.g. a ``port``,
you will now have to explicitly set the ``host`` to '127.0.0.1' as well.
Step 6: Check usage of the Email library
========================================
The :doc:`Email Library <../libraries/email>` will now by default check the
validity of all e-mail addresses passed to it. This check used to be Off by
default, and required explicitly setting the **validate** option to ``TRUE``
in order to enable it.
Naturally, a validity check should not result in any problems, but this is
technically a backwards-compability break and you should check that
everything works fine.
If something indeed goes wrong with that, please report it as a bug to us,
and you can disable the **validate** option to revert to the old behavior.
Step 7: Check usage of doctype() HTML helper
============================================
The :doc:`HTML Helper <../helpers/html_helper>` function
:php:func:`doctype()` used to default to 'xhtml1-strict' (XHTML 1.0 Strict)
when no document type was specified. That default value is now changed to
'html5', which obviously stands for the modern HTML 5 standard.
Nothing should be really broken by this change, but if your application
relies on the default value, you should double-check it and either
explicitly set the desired format, or adapt your front-end to use proper
HTML 5 formatting.
Step 8: Check usage of form_upload() Form helper
================================================
The :doc:`Form Helper <../helpers/form_helper>` function
:php:func:`form_upload()` used to have 3 parameters, the second of which
(``$value``) was never used, as it doesn't make sense for an HTML ``input``
tag of the "file" type.
That dead parameter is now removed, and so if you've used the third one
(``$extra``), having code like this::
form_upload('name', 'irrelevant value', $extra);
You should change it to::
form_upload('name', $extra);
Step 9: Remove usage of previously deprecated functionalities
=============================================================
The following is a list of functionalities deprecated in previous
CodeIgniter versions that have been removed in 3.2.0:
- ``$config['allow_get_array']`` (use ``$_GET = array();`` instead)
- ``$config['standardize_newlines']``
- ``$config['rewrite_short_tags']`` (no impact; irrelevant on PHP 5.4+)
- 'sqlite' database driver (no longer shipped with PHP 5.4+; 'sqlite3' is still available)
- ``CI_Input::is_cli_request()`` (use :php:func:`is_cli()` instead)
- ``CI_Router::fetch_directory()`` (use ``CI_Router::$directory`` instead)
- ``CI_Router::fetch_class()`` (use ``CI_Router::$class`` instead)
- ``CI_Router::fetch_method()`` (use ``CI_Router::$method`` instead)
- ``CI_Config::system_url()`` (encourages insecure practices)
- ``CI_Form_validation::prep_for_form()`` (the *prep_for_form* rule)
- ``standard_date()`` :doc:`Date Helper <../helpers/date_helper>` function (use ``date()`` instead)
- ``do_hash()`` :doc:`Security Helper <../helpers/security_helper>` function (use ``hash()`` instead)
- ``br()`` :doc:`HTML Helper <../helpers/html_helper>` function (use ``str_repeat()`` with ``'<br />'`` instead)
- ``nbs()`` :doc:`HTML Helper <../helpers/html_helper>` function (use ``str_repeat()`` with ``' '`` instead)
- ``trim_slashes()`` :doc:`String Helper <../helpers/string_helper>` function (use ``trim()`` with ``'/'`` instead)
- ``repeater()`` :doc:`String Helper <../helpers/string_helper>` function (use ``str_repeat()`` instead)
- ``read_file()`` :doc:`File Helper <../helpers/file_helper>` function (use ``file_get_contents()`` instead)
- ``form_prep()`` :doc:`Form Helper <../helpers/form_helper>` function (use :php:func:`html_escape()` instead)
- The entire *Cart Library* (an archived version is available on GitHub: `bcit-ci/ci3-cart-library <https://github.com/bcit-ci/ci3-cart-library>`_)
- The entire *Javascript Library* (it was always experimental in the first place)
- The entire *Email Helper*, which only had two functions:
- ``valid_email()`` (use ``filter_var($email, FILTER_VALIDATE_EMAIL)`` instead)
- ``send_email()`` (use ``mail()`` instead)
- The entire *Smiley Helper* (an archived version is available on GitHub: `bcit-ci/ci3-smiley-helper <https://github.com/bcit-ci/ci3-smiley-helper>`_)
Step 10: Make sure you're validating all user inputs
====================================================
The :doc:`Input Library <../libraries/input>` used to (often
unconditionally) filter and/or sanitize user input in the ``$_GET``,
``$_POST`` and ``$_COOKIE`` superglobals.
This was a legacy feature from older times, when things like
`register_globals <https://secure.php.net/register_globals>`_ and
`magic_quotes_gpc <https://secure.php.net/magic_quotes_gpc>`_ existed in
PHP.
It was a necessity back then, but this is no longer the case and reliance
on global filters is a bad practice, giving you a false sense of security.
This functionality is now removed, and so if you've relied on it for
whatever reasons, you should double-check that you are properly validating
all user inputs in your application (as you always should do).
|
