codeigniter logo

Migrer son framework CodeIgniter de la version 2.1.4 vers la version 3.0.0

Dans cet article je vais m’efforcer de vous traduire les consignes pour migrer son projet Codeigniter 2.1.4 vers la version 3.0.0 :

le texte original est disponible ici :

Ces notes de mise à niveau sont valables pour une version qui n’est pas encore publié.

Avant d’effectuer la mise à jour, vous devriez mettre votre site en ligne en remplaçant le fichier index.php avec une version >statique pour prévenir vos utilisateurs d’une migration en cours.

Étape 1 : Mettre à jour les fichier de Codeigniter

Remplacer tous les dossiers présents dans « system » ainsi que index.php. Si des modifications ont été apportées à votre index.php, elles devront être refaites à nouveau .

Si vous avez des fichiers de votre crus présents dans « system », pensez à en réaliser une copie d’abord !

Étape 2 : Mettre à jour les noms de fichiers de classes

À partir de CodeIgniter 3.0, tous les noms de fichiers de classe (bibliothèques, les pilotes, les contrôleurs et modèles) doivent être nommés de manière « ucfirst », en d’autres termes – ils doivent commencer par une lettre majuscule.

Par exemple, si vous avez le fichier suivant dans « libraries » :

application/libraries/mylibrary.php

…vous devez le renommer en :

application/libraries/Mylibrary.php

La même chose vaut pour les bibliothèques de pilotes et extensions et / ou celles qui on été remplacé par vos propres bibliothèques et les classes.

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

Les fichiers ci-dessus doivent être renommés respectivement de cette manière :

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

Veuillez noter que cela n’affecte pas les répertoires , seulement les fichiers de configuration , des vues, des aides, des crochets et rien d’autre – ce n’est appliqué qu’ aux classes.

Vous devez maintenant suivre une règle simple – le noms de classes en « ucfirst » et tout le reste en minuscules.

Étape 3 : Replacer le fichier config/mimes.php

Ce fichier de configuration a été mis à jour pour contenir plus de mime-types, copiez-le dans « Application/config/mimes.php« .

Étape 4 : Supprimer $autoload[‘core’] de votre fichier config/autoload.php

L’usage de $autoload['core'] est déprécié depuis CodeIgniter 1.4.1, il est maintenant supprimé. Déplacez toute les entrées que vous avez ajouté dans $autoload['libraries'] à la place.

Étape 5 : déplacez votre classe de log et extensions

La classe log est considéré comme une extension du « core » elle est maintenant situé dans le dossier system/core/. Par conséquent, pour que votre classe Log remplace ou étende , vous devez les déplacer dans application/core/:

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

Étape 6 : Convertir votre utilisation de « session » à partir de la bibliothèque « driver »

Lorsque vous chargez (ou autochargez) la Session library, vous devez maintenant le charger en tant que pilote au lieu d’une bibliothèque. Cela signifie qu’il faut appeler $this->Load->driver('session') au lieu de $this->Load->library('session') et/ou de la liste ‘session’ dans $autoload['drivers'] au lieu de $autoload['library'].

Avec le changement de la libairie session de la nouvelle session utilisant « driver », deux nouveaux éléments de configuration ont été ajoutés :

  • $config['sess_driver'] sélectionner les drivers que vous voulez utiliser. Les option sont :

    • ‘cookie’ (par défault) pour des sessions basées sur les cookies
    • ‘native’ pour utiliser les sessions native de PHP
    • le nom de votre driver personnalisé
  • $config['sess_valid_drivers'] offre toute une gamme de drivers personnalisés supplémentaires pour rendu disponible au chargement

La nouvelle bibliothèque session driver charge le pilote de Cookie par défaut mais « cookie » et « native » disponible comme avant, aucune configuration n’est nécessaires. Cependant, il est recommandé que vous les ajoutiez à pour la clarté et la facilité de configuration future.

Si vous avez écrit une extension à session, vous devez la déplacer dans un sous-répertoire «session» de «libraries», conformément à la norme pour les drivers. Méfiez-vous également à ce que certaines fonctions qui ne font pas partie de l’API Session externe ne soit installés dans les pilotes, si votre poste peut être décomposé en extensions de library de la classe de driver séparément.

Étape 7 : Mettre à jour config/database.php

en raison du chenagement de nom de Active Record pour Query Builder, à l’intérieur de votre config/ database.php, vous devez renommer la variable $active_record en $query_builder

$active_group = 'default';

// $active_record = TRUE;

$query_builder = TRUE;

Étape 8 : Remplacez votre template d’affichage des erreurs

Dans CodeIgniter 3.0, le template error est maintenant considéré comme une vue et à été déplacé dans le dossier _application/views/errors.

En outre, nous avons ajouté un support pour des modèles d’erreur en CLI (ligne de commande) un format texte qui, contrairement au HTML, est plus addapté la ligne de commande. Bien sûr, cela nécessite un autre niveau de séparation.

Il est plus sûr de déplacer vos modèles préexistants de _Application/erreurs vers _Application/views/errors/html, n’oubliez pas de copier le nouveau _application/views/errors/cli dans le répertoire de CodeIgniter.
Nous vous conseillons de déplacer vos anciens templates du dossier _application/errors vers _application/views/errors/html, vous aurez à copier le nouveau _application/views/errors/cli répertoire de l’archive de CodeIgniter.

Étape 9 : Mettre à jour les config/routes.php de type (:any)

Historiquement, CodeIgniter a toujours fourni la route :any générique, avec l’intention de fournir un moyen de faire correspondre tout les caractères dans un segment de type URI.
Cependant, la :any générique est en fait juste un alias pour une expression régulière, il est utilisé pour être exécuté de cette manière + .. Ceci est considéré comme un bug, car elle correspond également au caractère (slash) /, qui est le segment séparateur URI dont cela n’a jamais été l’intention… Dans CodeIgniter 3, le générique :any est représenté par [^/]+,de sorte qu’il ne peux pas correspondre à un slash.

Il y a certainement beaucoup de développeurs qui ont utilisé ce bug comme une caractéristique réelle. Si vous êtes l’un d’entre eux et que vous voulez faire correspondre un slash, utiliser une expression régulière .+ :

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

Étape 10 : Toutes les fonctions qui retournent NULL à la place de FALSE

De nombreuses méthodes et fonctions renvoient désormais NULL, au lieu de FALSE lorsque les éléments nécessaires n’existent pas :

  • `Config Class ../libraries/config`
    • config->item()
    • config->slash_item()
  • :doc:`Input Class ../libraries/input`
    • input->get()
    • input->post()
    • input->get_post()
    • input->cookie()
    • input->server()
    • input->input_stream()
    • input->get_request_header()
  • :doc:`Session Class ../libraries/sessions `
    • session->userdata()
    • session->flashdata()
  • :doc:`URI Class <../libraries/uri `
    • uri->segment()
    • uri->rsegment()
  • :doc:`Array Helper ../helpers/array_helper `
    • element()
    • elements()

Étape 11 : Application du filtre XSS

De nombreuses méthodes de CodeIgniter vous permettent d’utiliser la fonction de filtrage XSS à la demande en passant un paramètre de type booléen. La valeur par défaut de ce paramètre utilisé est FALSE, il est maintenant remplacé par la valeur NULL et il sera déterminée dynamiquement par votre $config ['global_xss_filtering'] value.

Si vous avez utilisé pour passer manuellement une valeur booléenne pour le filtre $xss ou si vous avez toujours eu $config ['global_xss_filtering'] défini à FALSE, alors ce changement ne vous concerne pas. Sinon vérifier l’utilisation des fonctions suivantes :

  • input->get()
  • input->post()
  • input->get_post()
  • input->cookie()
  • input->server()
  • input->input_stream()

Important, les superglobals $_GET, $_POST, $_COOKIE et $_SERVER ne sont plus automatiquement écrasé lorsque le filtrage global XSS est activé.

Étape 12 : Mettre à jour l’utilisation de la méthode de la classe get_post()

Précédemment, la méthode get_post()recherchait les données en POST en premier, puis en GET. La méthode à été modifiée pour chercher en premier en GET puis en POST, comme son nom le suggère.

Une méthode à été ajouté, post_get(), qui recherche en POST puis en GET, comme get_post() le faisait avant.

Étape 13 : Mise à jour des dossier Helpers en directory_map()

Dans le tableau résultant, les répertoires finissent maintenant avec un séparateur de répertoire(c’est à dire un /, généralement).

Étape 14 : Mise à jour de l’utilisation de la base de données et de la méthode Forge de DROP_TABLE

Jusqu’à présent il y avait une clause IF EXISTS DROP_TABLE() par défaut qui ne fonctionne pas du tout avec certains pilotes. Avec CodeIgniter 3.0, l’IF EXISTS ​​n’est plus ajoutée par défaut, il y a un second paramètre optionnel qui le permet. Il est mis à FALSE par défaut.

Si votre application utilise IF EXISTS, vous devez controler son utilisation.

// Now produces just DROP TABLE `table_name`
$this->dbforge->drop_table('table_name');

// Produces DROP TABLE IF EXISTS `table_name`
$this->dbforge->drop_table('table_name', TRUE);

Le présent exemple concerne la syntax MySQL, mais elle devrait fonctionner pour tous les pilotes à l’exception de ODBC.

Étape 15 : Changer l’utilisation de la bibliothèque e-mails pour l’envoi de plusieurs e-mails

Effacement automatiquement des paramètres réglés après l’envoi des e-mails avec succès. Pour remplacer ce comportement, passer FALSE comme premier paramètre dans le send () :

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

Étape 16: Mettez à jour vos traduction avec la méthode Form_validation()

Deux améliorations ont été apportées à la validation de formulaire bibliothèques / form_validation..> 'Slt; / bibliothèques / langue&gt; fichiers et le format des messages d’erreur..:

  • touches de ligne doivent désormais être précédés de form_validation_ afin d’éviter les collisions :
    // Ancien
    $lang['rule'] = ...
    
    // Nouveau
    $lang['form_validation_rule'] = ...
    
  • Le format des messages d’erreur a été modifié pour utiliser des paramètres nommés, afin de permettre plus de souplesse que ce que propose sprintf() :
    // Ancien
    'The %s field does not match the %s field.'
    
    // Nouveau
    'The {field} field does not match the {param} field.'
    

Le vieux formatage fonctionne toujours, mais les touches de ligne non-préfixés sont obsolètes et programmé pour être supprimé dans CodeIgniter 3.1 +. Par conséquent, vous êtes encouragés à mettre à jour son utilisation au plutôt tôt.

Étape 17 : Retirer l’utilisation des fonctionnalités obsolètes

En plus de $autoload['core'] de paramètre de configuration, il y a un certain nombre d’autres fonctionnalités qui ont été supprimés dans CodeIgniter 3.0.0:

La librairie SHA1

La bibliothèque de SHA1 du framework a été supprimé, modifier votre code pour utiliser le SHA1 natif de PHP pour générer un hash SHA1.

SHA1() a été supprimé le la libraire encrypt.

La constante EXT

L’utilisation de la constante EXT a été dépréciée depuis l’abandon du support de PHP 4. Il n’y a pas plus besoin de maintenir des extensions de nom de fichier et dans cette nouvelle version CodeIgniter, EXT constante a donc été retirée. Utilisez seulement ‘.Php’ à la place.

Le helper js_insert_smiley()

La function js_insert_smiley() est dépréciée depuis CodeIgniter 1.7.2, elle est maintenant supprimée. Vous devez passer à smiley_js() à la place.

La libraire Encrypt

Après de nombreux rapports de vulnérabilité, la Bibliothèque Encrypt a été déprécié et une nouvelle, Bibliothèque Encryption est ajouté pour prendre sa place.

La nouvelle bibliothèque nécessite soit l’extension MCrypt ou PHP 5.3.3 et l’extension OpenSSL. Même si cela peut être assez gênant, c’est une exigence qui nous permet d’avoir des fonctions cryptographiques correctement mises en œuvre.

Remarque

La bibliothèque Crypter est toujours disponible dans le but de maintenir la compatibilité ascendante.

Important : Vous êtes fortement encouragés à passer à la nouvelle bibliothèque Encryption dès que possible!

Le pilotes de base de données ‘mysql’ , ‘sqlite’, ‘MSSQL’, ‘AOP / dblib’

Le pilote mysql utilise l’ancienne extension ‘mysql’ de PHP, connue pour sa base de code vieillissante et de nombreux problèmes de bas niveau. L’extension est obsolète depuis PHP 5.5 et CodeIgniter le déprécie dans la version 3.0, la valeur par défaut du pilote MySQL est configuré pour mysqli .

S’il vous plaît utiliser le pilote ‘mysqli’ ou le pilote ‘PDO / mysql’ pour MySQL. L’ancien pilote ‘mysql’ sera retiré dans l’avenir.

Les pilotes sqlite , MSSQL et AOP / dblib (aussi connu comme AOP / MSSQL ou AOP / sybase) dépendent tous des extensions de PHP qui pour différents raisons n’existent plus depuis PHP 5.3.

Par conséquent, nous sommes en train de déprécier ces pilotes que nous aurons à retirer dans les prochaines versions de CodeIgniter. Vous devez utiliser les pilotes les plus avancés, soit sqlite3 ,sqlsrv ou AOP / sqlsrv .

Remarque : Ces pilotes sont encore disponibles, mais vous êtes fortement encouragés migrer au plus tôt.

La sécurité du helper do_hash()

La function do_hash() est maintenant juste un alias pour la fonction de hachage de PHP. Il est obsolète et est programmé pour être supprimé dans CodeIgniter 3.1 +.

Note :
Cette fonction est toujours disponible, mais vous êtes fortement encouragé à retirer arrêter son utilisation au plus tôt.

Le helper read_file()

La fonction read_file() est maintenant un simple alias de la fonction PHP native file_get_contents(). Cette fonction est dépréciée, elle sera supprimé dans CodeIgniter 3.1+.

Note :
Cette fonction est toujours disponible, mais vous êtes fortement encouragé à retirer son utilisation au plus tôt.

String helper repeater()

La fonction est maintenant un simple alias de la fonction PHP native str_repeat(). Cette fonction est dépréciée, elle sera supprimé dans CodeIgniter 3.1+.

Note :
Cette fonction est toujours disponible, mais vous êtes fortement encouragé à retirer son utilisation au plus tôt.

Le helper trim_slashes()

Cette est maintenant un simple alias de la fonction PHP native trim() (avec un slash passé en second argument). Cette fonction est dépréciée, elle sera supprimé dans CodeIgniter 3.1+.

Note :
Cette fonction est toujours disponible, mais vous êtes fortement encouragé à retirer son utilisation au plus tôt.

le helper Email

Le Helper Email a seulement 2 fonctionnalités

  • :func:`valid_email()`
  • :func:`send_email()`

Deux d’entre eux sont maintenant des alias pour la fonction native filter_var () de PHP et le mail() . Par conséquent, le:doc:Email Helper < .. / Helpers / email_helper> tout est obsolète et est prévue pour le déménagement à CodeIgniter 3.1 +.

Note
Cette fonction est toujours disponible, mais vous êtes fortement encouragé à retirer son utilisation au plus tôt.

Date helper standard_date()

La function standard_date() is being deprecated due to the availability of native PHP constants, which when combined with date() provide the same functionality. Furthermore, they have the exact same names as the ones supported by standard_date(). Here are examples of how to replace its usage:

// Old way
standard_date(); // defaults to standard_date('DATE_RFC822', now());

// Replacement
date(DATE_RFC822, now());

// Old way
standard_date('DATE_ATOM', $time);

// Replacement
date(DATE_ATOM, $time);

Note

This function is still available, but you’re strongly encouraged to remove its usage sooner rather than later as it is scheduled for removal in CodeIgniter 3.1+.

HTML helpers nbs(), br()

:doc:HTML Helper &lt;../helpers/html_helper&gt; functions nbs() and br() are just aliases for the native str_repeat() function used with &nbsp; and <br > respectively.

Because there’s no point in just aliasing native PHP functions, they are now deprecated and scheduled for removal in CodeIgniter 3.1+.

Note

These functions are still available, but you’re strongly encouraged to remove their usage sooner rather than later.

Pagination library ‘anchor_class’ setting

The :doc:Pagination Library &lt;../libraries/pagination&gt; now supports adding pretty much any HTML attribute to your anchors via the ‘attributes’ configuration setting. This includes passing the ‘class’ attribute and using the separate ‘anchor_class’ setting no longer makes sense. As a result of that, the ‘anchor_class’ setting is now deprecated and scheduled for removal in CodeIgniter 3.1+.

Note

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

String helper random_string() types ‘unique’ and ‘encrypt’

When using the :doc:String Helper &lt;../helpers/string_helper&gt; function :func:random_string(), you should no longer pass the unique and encrypt randomization types. They are only aliases for md5 and sha1 respectively and are now deprecated and scheduled for removal in CodeIgniter 3.1+.

Note

These options are still available, but you’re strongly encouraged to remove their usage sooner rather than later.

URL helper url_title() separators ‘dash’ and ‘underscore’

When using the function, you should no longer pass dash or underscore as the word separator. This function will now accept any character and you should just pass the chosen character directly, so you should write ‘-‘ instead of ‘dash’ and ‘_’ instead of ‘underscore’.

dash and underscore now act as aliases and are deprecated and scheduled for removal in CodeIgniter 3.1+.

Note

These options are still available, but you’re strongly encouraged to remove their usage sooner rather than later.

Session Library method all_userdata()

As seen in the :doc:Change Log &lt;../changelog&gt;, :doc:Session Library &lt;../libraries/sessions&gt; method userdata() now allows you to fetch all userdata by simply omitting its parameter:

$this->session->userdata();

This makes the all_userdata() method redudant and therefore it is now just an alias for userdata() with the above shown usage and is being deprecated and scheduled for removal in CodeIgniter 3.1+.

Note

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

Database Forge method add_column() with an AFTER clause

If you have used the third parameter for :doc:Database Forge &lt;../database/forge&gt; method add_column() to add a field for an AFTER clause, then you should change its usage.

That third parameter has been deprecated and scheduled for removal in CodeIgniter 3.1+.

You should now put AFTER clause field names in the field definition array instead:

// Old usage:
$field = array(
        'new_field' => array('type' => 'TEXT')
);

$this->dbforge->add_column('table_name', $field, 'another_field');

// New usage:
$field = array(
        'new_field' => array('type' => 'TEXT', 'after' => 'another_field')
);

$this->dbforge->add_column('table_name', $field);

Note

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

Note

This is for MySQL and CUBRID databases only! Other drivers don’t support this clause and will silently ignore it.

URI Routing methods fetch_directory(), fetch_class(), fetch_method()

With properties CI_Router::$directory, CI_Router::$class and CI_Router::$method being public and their respective fetch_*() no longer doing anything else to just return the properties – it doesn’t make sense to keep them.

Those are all internal, undocumented methods, but we’ve opted to deprecate them for now in order to maintain backwards-compatibility just in case. If some of you have utilized them, then you can now just access the properties instead:

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

Note

Those methods are still available, but you’re strongly encouraged to remove their usage sooner rather than later.

Input library method is_cli_request()

Calls to the CI_Input::is_cli_request() method are necessary at many places in the CodeIgniter internals and this is often before the :doc:Input Library &lt;../libraries/input&gt; is loaded. Because of that, it is being replaced by a common function named :func:is_cli() and this method is now just an alias.

The new function is both available at all times for you to use and shorter to type.

// Old
$this->input->is_cli_request();

// New
is_cli();

CI_Input::is_cli_request() is now now deprecated and scheduled for removal in CodeIgniter 3.1+.

Note

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

Config library method system_url()

Usage of CI_Config::system_url() encourages insecure coding practices. Namely, your CodeIgniter system/ directory shouldn’t be publicly accessible from a security point of view.

Because of this, this method is now deprecated and scheduled for removal in CodeIgniter 3.1+.

Note

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

The Javascript library

The :doc:Javascript Library &lt;../libraries/javascript&gt; has always had an ‘experimental’ status and was never really useful, nor a proper solution.

It is now deprecated and scheduled for removal in CodeIgniter 3.1+.

Note

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

Step 18: Check your usage of Text helper highlight_phrase()

The default HTML tag used by :doc:Text Helper &lt;../helpers/text_helper&gt; function :func:highlight_phrase() has been changed from <strong> to the new HTML5 tag <mark>.

Unless you’ve used your own highlighting tags, this might cause trouble for your visitors who use older web browsers such as Internet Explorer 8. We therefore suggest that you add the following code to your CSS files in order to avoid backwards compatibility with old browsers:

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

Publié

dans

par

Commentaires

5 réponses à “Migrer son framework CodeIgniter de la version 2.1.4 vers la version 3.0.0”

  1. Avatar de wiloooo

    Bonjour,
    est-ce que la version 3.0 est stable ? pourquoi ne figure-t-elle pas sur le site officiel ?

    1. Avatar de Grand Maître L

      Salut,
      La v3.0 n’est pas encore stable, elle devrait l’être cette année.

      1. Avatar de wiloooo

        Ok merci pour les informations 😉
        au plaisir de vous lire

    2. Avatar de B.A.Z.
      B.A.Z.

      EllisLab a officiellement abandonné CodeIgniter il y a plusieurs mois maintenant. La version 3.0 est développée par quelques anciens de CodeIgniter et la communauté (Andreev était le lead dév actuel). Il ne faudra pas s’attendre à une documentation avant un sacré moment. Concernant la stabilité de CI3, les seuls problèmes restants concernent des edge cases et du doublon de code. Côté sécurité, rien à signaler, les bases de CI2 ont été conservé. Pour un projet petit-moyen, c’est clairement utilisable en prod.
      Là où je m’inquièterai plus c’est sur les standards PHP-FIG toujours non respectés malgré les efforts.

      1. Avatar de Grand Maître L

        Salut, Il me semble qu’ils veulent surtout que d’autres s’en occupent. Mai il y a toujours la v3 et la 3.5 dans les cartons.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.