Le problème

La documentation de CodeIgniter propose de faire cette séparation en créant autant de sous-dossiers qu’il y a d’applications dans le répertoire « application » et d’y dupliquer tous les répertoires nécessaires. Le problème avec cette approche vient du fait qu’il y a un risque de duplication de code puisque chaque application est totalement indépendente. Par exemple il faudra plusieurs fichiers de configuration, plusieurs fichiers de routes… Pire encore : si vous souhaitez partager des librairies, helpers, models, etc… ça ne sera pas possible et il faudra également les dupliquer.
Sur ce dernier point, depuis la version 2 de CodeIgniter ce n’est plus tout à fait exact : on peut utiliser le dossier « third_party » pour y partager configurations, helpers, models et librairies – mais il n’y a toujours pas de séparation des applications et l’on ne peut pas interagir avec le router.

Une solution

En effet il n’y a pas une seule et unique solution au problème mais je vous une présente une que je trouve assez astucieuse, relativement simple à mettre en place et qui ne nécessite aucune librairie ni overload de classes. Elle se résume en deux mots : liens symboliques.

Mise en œuvre

Pour cette article nous partirons du postulat que nous voulons créer un site web en local (pour le développer bien sûr^^) et séparant le front-office (ce que voit le visiteur) du back-office (ce qu’utilise le(s) gestionnaire(s) du site).

Pour commencer il faut choisir une stratégie de différenciation des applications : adresse IP, sous-domaine, URI, session… ou, vraisemblablement, une combinaison de ces possibilités. Pour l’example nous utiliserons un sous-domaine « admin » pour le back-office, le front-office étant sur « www ».

Configuration hosts

En développement local j’utilise toujours des hôtes virtuels et comme je travaille sur un Mac utilisant MAMP, j’explicite les réglages pour cette plateforme – mais c’est à peu de choses près la même chose sous Windows et Linux. Bref :
On édite le fichier /private/etc/hosts en y ajoutant à la fin deux lignes :

127.0.0.1 www.montest.local
127.0.0.1 admin.montest.local

Sous Lion faites bien attention à ce qu’il y ait une ligne vierge à la fin du fichier, comme je l’explique dans cet article.

Configuration Apache

Les serveurs de MAMP doivent être arrêtés et l’on édite le fichier /Applications/MAMP/conf/apache/httpd.conf en y ajoutant les deux serveurs virtuels correspondants à ce que nous avons ajouté dans le fichier hosts :

<VirtualHost *:80>
DocumentRoot /Applications/MAMP/htdocs/montest/www/
ServerName www.montest.local
</VirtualHost>

<VirtualHost *:80>
DocumentRoot /Applications/MAMP/htdocs/montest/www/
ServerName admin.montest.local
</VirtualHost>

Vous noterez que le document root est « www » et non la racine du site, ceci pour des raisons de sécurité : le serveur apache ne permettra que d’accéder aux fichiers nécessaires à l’application : le bootstrap (index.php) et les ressources (javascript, images, css).

Arborescence du projet CodeIgniter

Nous allons modifier l’arborescence de base de CodeIgniter pour prendre en compte la séparation d’applications et le déplacement des fichiers d’application et du framework :

Les modifs sont les suivantes :

• Le répertoire « application » à été renommé « applications »
• Les répertoires « bo » et « fo » ont été créés
• Le contenu originel du répertoire « application » a été déplacé dans « bo »
• Un répertoire « www » a été créé au même niveau que « applications » et index.php y a été déplacé

Dans le répertoire « fo » nous rajouterons les répertoires « controllers » et « views » et c’est là que la séparation aura effectivement lieu : le front-office aura ses propres controlleurs et vues. Tout le reste proviendra du répertoire « bo ».

L’astuce pour que ça marche

Comment le framework va-t’il trouver les modèles, librairies, etc… dans la partie front alors qu’il n’y sont pas ? Tout simplement en utilisant des liens symboliques de Linux. Pour les créer, un petit tour dans le Terminal, en se plaçant dans le répertoire « fo » il n’y plus qu’a tapper les lignes suivantes (en validant ligne par ligne) :

ln -s ../bo/cache cache
ln -s ../bo/config config
ln -s ../bo/core core
ln -s ../bo/errors errors
ln -s ../bo/helpers helpers
ln -s ../bo/hooks hooks
ln -s ../bo/language language
ln -s ../bo/librairies librairies
ln -s ../bo/logs logs
ln -s ../bo/models models
ln -s ../bo/third_party third_party

Et le tour est joué ! Ou presque…

Configurer index.php

Comme nous avons modifié l’arborescence du framework il faut lui indiquer où trouver ses fichiers, mais aussi lui indiquer quelle application utiliser. Nous modifions donc /www/index.php :

[...]
$system_path = '../system'; // on a sorti le framework du webroot (sécurité)
[...]
// changement application en fonction du sous-domaine
// a modifier en fonction de la stratégie de différenciation choisie
if( preg_match('/admin\.*/', $_SERVER['SERVER_NAME']) ) {
	$app_folder = '/bo';
} else {
	$app_folder = '/fo';
}

$application_folder = '../applications' . $app_folder; // les applications sont également en dehors du webroot (sécurité)

A noter qu’il s’agit là d’une partie du fichier index.php de la version 2.0.3 du framework – le reste n’étant pas intéressant pour cet article. Pour les versions précédentes du framework, ce fichier est similaire.

Dorénavant tous les models, librairies, configs etc… seront stockés dans un lieu commun (le répertoire « bo ») et seront disponibles pour toutes les applications.

Conclusion

Cette technique permet de simuler un système de modules qui manque à CodeIgniter (bien qu’il existe des librairies le permettant, par exemple HMVC). Elle a l’avantage de fonctionner sur les versions antérieures à la 2.X du framework, alors qu’à partir de la version 2 on pourrait utiliser le système de « third_party » bien qu’il faille encore les charger « à la main ».

Happy coding !

Le problème

Si vous êtes webdesigner ou développeur il y a de fortes chances que vous utilisiez des hôtes virtuels (virtual hosts) configurés dans Apache et, par conséquent, que vous routiez vos noms d’hôtes virtuels par le biais du fichier hosts de MacOS.

Vous aurez certainement remarqué que la dernière entrée de ce fichier ne fonctionne pas, à savoir : page blanche :(

La solution

C’est bête comme choux mais il fallait le savoir : il suffit d’ajouter une ligne vide à la suite de votre dernière entrée et tout rentre dans l’ordre !

Le problème

Pour pouvoir faire de l’upload il faut déclarer les types de fichiers acceptés dans son controlleur (ou dans un fichier de config) à l’aide de la déclaration

$config['allowed_types'] = 'gif|jpg|png|zip';

Lors de la soumission du formulaire contenant le fichier a envoyer, le navigateur envoi un mime type au serveur correspondant au type de fichier que l’on souhaite uploader. CodeIgniter va ensuite confronter ce mime type avec ceux qui sont autorisés et agir en conséquence.

Le problème vient du fait que les navigateurs n’envoyent pas tous le même mime type pour les fichiers ZIP et, après recherche, il s’avère qu’il en existe 7 différents. Hors CodeIgniter n’en prend en charge que 3. Donc si votre navigateur envoi l’un des 4 types non répertoriés, l’upload échoue avec un magnifique message d’erreur : « The filetype you are attempting to upload is not allowed. »

La solution

Il suffit d’éditer le fichier application/config/mimes.php en ajoutant les mime types manquants à la ligne correspondant à votre type de fichier. Dans le cas d’un fichier ZIP il s’agit de la ligne 54 :

'zip'	=>  array('application/x-zip', 'application/zip', 'application/x-zip-compressed'),

qu’il faut changer en

'zip'	=>  array('application/x-zip', 'application/zip', 'application/x-zip-compressed','application/octet-stream','application/x-compress','application/x-compressed','multipart/x-zip'),

Et tout rentre dans l’ordre :)

Ajouter d’autre mime types

Si vous deviez ajouter de nouveaux types de fichiers à la liste des fichiers autorisés ou qu’un type existant posait le même problème que pour les ZIP, il suffit de faire un simple

var_dump($_FILES)

et de repérer le résultat de ["file_type"] dans l’array retourné. C’est cette information qu’il faudra ajouter au fichier application/config/mimes.php.

Pourquoi commenter ?

Les intérêts sont multiples et variés allant du simple « j’en suis là » à la fin de la journée jusqu’à la documentation d’une application.

Commenter pour comprendre ce qu’on a fait

Lors d’une session de développement on est souvent confronté à un problème nouveau à gérer et la solution n’est pas forcément toujours évidente. On fait quelques recherches, on trouve une solution ou l’inspiration pour la créer et on l’intègre. Tout fonctionne, c’est parfait, on est content.
3 mois plus tard on doit revenir dessus car il faut améliorer la fonction en y intégrant de nouveaux paramètres ou s’en resservir pour un autre projet, et là c’est le drame : on ne comprend plus comment ça fonctionne, voire même à quoi sert ladite fonction… Les 30 secondes nécessaires à écrire les quelques commentaires salutaires nous auraient permises d’éviter une décapilarisation crânienne subite et la perte de pas mal de temps.

Commenter pour expliquer aux autres

On peut travailler en équipe sur un projet et d’autres développeurs risquent d’avoir à intervenir sur votre code pendant que vous faites autre chose. Autre cas de figure : vous développez seul un projet puis un peu plus tard c’est un autre développeur qui le reprend ou qui vous rejoin dessus. Vous pouvez également être en train de développer un script/module/librairie/application destiné(e) à être partagé(e) avec d’autres (dans le cadre d’open source par exemple).
Encore une fois, le temps passé à commenter le code évitera aux autres d’être complètement perdus à la lecture de votre chef d’oeuvre. Ceci est d’autant plus vrai que chaque développeur a son style et sa manière de coder et qui, bien souvent, n’est limpide que pour lui-même…

Commenter pour se faciliter la tâche

Les IDE de qualité sont capable de lire les commentaires DocBlock et de s’en servir pour afficher, lors de la saisie, les informations d’utilisation que vous avez pris le soin d’entrer. Dans le cadre du développement d’une application répartie en plusieurs fichiers (souvent le cas en POO ou en utilisant un framework), les commentaires révèlent toute leur puissance en vous évitant de replonger dans le code d’une fonction pour retrouver quels arguments lui passer ou encore ce qu’elle retourne.
Ce type de commentaire peut aussi être utilisé pour l’écriture automatique de la documentation d’une API, par exemple, à l’aide d’un générateur de documentation tel que PHPdocumentor ou Doxygen

Les différents types de commentaires

Il existe 3 types de commentaires : ligne simple, multiligne et DocBlock. Les 2 premiers ne servent qu’à indiquer des informations courtes au sein même du code alors que le DocBlock permettra aux IDE et générateurs de documentation d’en faire bien plus.

Les commentaires simples et multilignes se présentent de la manière suivante :

// je suis un commentaire sur une seule ligne
/* je suis
un commentaire
sur plusieurs lignes */

Le commentaire DocBlock se présente ainsi :

/**
 * Cette fonction sert à faire ceci...
 * un commentaire
 * sur plusieurs lignes
 *
 * @param string $text Description du paramètre
 * @param int $id Description du paramètre
 * @return bool Description de ce que retourne (ou non) la fonction
*/

Notez l’utilisation de certains mots clés (@param, @return) dont vous trouverez la liste complète ici. C’est précisément ces mots-clés qui permettrons à l’IDE et au générateur de documentation de travailler.

Un exemple d’utilisation

Voici un petit exemple d’utilisation des 3 types de commentaires dans un modèle du framework CodeIgniter :

<?php

class Blog_model extends CI_Model {

	// constructeur
	function __construct() {
		parent::__construct();
	}

	/**
	 * Recupération des derniers posts de wordpress
	 *
	 * @param	int $count	Le nombre de posts que l'on veut afficher (optionnel)
	 * @return	object		Les posts à afficher
	 */
	function get_latest_posts($count = 5) {
		// requete mysql à l'aide d'ActiveRecord
		$this->db->select('post_title, post_name');
		$this->db->where('post_status', 'publish');
		$this->db->where('post_type', 'post');
		$this->db->limit($count);
		$this->db->order_by('ID', 'desc');

		$query = $this->db->get('wp_posts');
		
		/* on récupère les posts
		sous forme d'objet */
		$data = $query->result();

		//var_dump($data); exit; // test des résultats obtenus
		
		// renvoi des résultats au controlleur
		return $data;
	}

}

J’ai eu la main un peu lourde ici mais en même temps il vaut mieux trop de commentaires que pas assez !

Conclusion

Il y a peu de temps j’ai eu l’occasion d’intervenir sur un gros projet de CRM/ERP qui était quasiment abouti et dont le développeur a du se retirer. Malheureusement il n’avait pas jugé utile de commenter son code et la conséquence directe à été une grosse perte de temps pour moi (le temps de comprendre le fonctionnement) et une grosse perte de temps et d’argent pour le client car il a du supporter le coût de « temps de compréhension » du code existant en plus du temps de développement nécessaire au résultat demandé…
Pour faire bref, passez un peu de temps à commenter votre code – votre client, les utilisateurs de votre code et vous-même ne vous remercieront jamais assez !

HTaccess à la rescousse !

La première étape consiste à créer un fichier .htaccess que l’on placera à la racine du site. Il faut noter que dans le monde unixien les fichiers commençants par un point sont invisibles. Si cela pose un problème il suffira de nommer le fichier htaccess.txt puis de le renommer une fois transféré sur le serveur.

Contenu du fichier .htaccess :

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L,QSA] 

Ces directives indiquent au serveur Apache de rediriger toute requete qui ne cible pas un dossier ou un fichier spécifique vers le fichier index.php et de lui passer en argument tout ce qui suit le nom de domaine. En clair, une url du type « http://mon-site.com/contact » sera redirigée vers « http://mon-site.com/index.php/contact.

Bien sûr on peut intégrer des directives plus élaborées mais ce n’est pas nécessaire si l’on ne cherche qu’à supprimer l’infâme index.php

Modification du fichier de configuration

Il faut ensuite modifier le fichier /system/application/config/config.php en changeant la ligne

$config['index_page'] = "index.php";

en :

$config['index_page'] = "";

Et voila, plus d’index.php !

J’ai trouvé cette astuce, en cherchant un peu partout une solution à ce problème, sur ce blog. Je me suis simplement permis de traduire en partie sa mise en place.

Autocomplete de base

Pour accéder à l’autocomplete des fonctions de base de CodeIgniter, il suffit simplement de créer un fichier « nom_du_fichier.php » dans le dossier de projet de Netbeans (nbproject) de votre application et d’y coller le contenu ci-dessous. Après cela, relancez Netbeans. Pour ce tutorial nous supposerons que ce fichier sera nommé « ci_autocomplete.php ».

<?php

/**
* @property CI_DB_active_record $db
* @property CI_DB_forge $dbforge
* @property CI_Benchmark $benchmark
* @property CI_Calendar $calendar
* @property CI_Cart $cart
* @property CI_Config $config
* @property CI_Controller $controller
* @property CI_Email $email
* @property CI_Encrypt $encrypt
* @property CI_Exceptions $exceptions
* @property CI_Form_validation $form_validation
* @property CI_Ftp $ftp
* @property CI_Hooks $hooks
* @property CI_Image_lib $image_lib
* @property CI_Input $input
* @property CI_Language $language
* @property CI_Loader $load
* @property CI_Log $log
* @property CI_Model $model
* @property CI_Output $output
* @property CI_Pagination $pagination
* @property CI_Parser $parser
* @property CI_Profiler $profiler
* @property CI_Router $router
* @property CI_Session $session
* @property CI_Sha1 $sha1
* @property CI_Table $table
* @property CI_Trackback $trackback
* @property CI_Typography $typography
* @property CI_Unit_test $unit_test
* @property CI_Upload $upload
* @property CI_URI $uri
* @property CI_User_agent $user_agent
* @property CI_Validation $validation
* @property CI_Xmlrpc $xmlrpc
* @property CI_Xmlrpcs $xmlrpcs
* @property CI_Zip $zip
*/

class Controller {};

/**
* @property CI_DB_active_record $db
* @property CI_DB_forge $dbforge
* @property CI_Config $config
* @property CI_Loader $load
* @property CI_Session $session
*/

class Model {};

?>

Comment ça fonctionne ?

Au lancement de Netbeans, celui-ci lit les fichiers contenus dans le répertoire nbproject (notamment project.xml et project.properties) afin de préparer l’environnement de développement.
En « lisant » le fichier ci_autocomplete.php il repère les propriétés définies dans le DocBlock pour les classes Controller et Model.
C’est cela qui lui permettra de fournir l’autocomplete lors de l’édition d’un controlleur ou d’un modèle. En parcourant le contenu du fichier on remarquera que l’on liste simplement les classes mises à disposition par CodeIgniter.

Ajoutez vos propres classes

Le but de la manoeuvre étant aussi d’accéder à l’autocomplete sur vos modèles et librairies, il suffit d’éditer le fichier ci_autocomplete.php que vous venez de créer pour les y incorporer :

* @property Nom_de_votre_classe $nom_de_votre_objet

Par exemple, en ajoutant

* @property Portfolio_model $portfolio_model

dans le DocBlock Controller, vous aurez accès aux méthodes du modèle Portfolio_model lors de l’édition d’un controlleur :

Note : pour que toutes les fonctions de vos modèles soient également disponibles pendant l’édition d’un modèle, il faudra également ajouter les modèles dans le DocBlock du modèle.

Conclusion

Il est dommage que, par défaut, on ne puisse pas accéder à l’autocomplete des fonctions de CodeIgniter — ceci étant apparemment dû à la manière dont le code est commenté — mais grâce à cette petite astuce tout rentre dans l’ordre.
Dernier petit conseil : utilisez également les commentaires DocBlock avec vos méthodes de modèles pour facilement en afficher l’utilisation lors de l’édition de controlleurs et modèles.

Préambule

Nous partirons du principe que nous voulons isoler le (ou les) template(s) du reste des views. Nous partirons également du principe que nous voulons isoler le header et le footer du template pour plus de flexibilité, et notamment pouvoir créer plusieurs templates dont le corps principal est différent (avec ou sans sidebar par exemple).

Le template HTML

Dans le répertoire /application/views créez un dossier nommé « templates« . C’est dans celui-ci que nous placerons les fichiers de notre template. Il y aura 3 fichiers : « template.php », « header.php » et « footer.php ».

template.php

Le fichier le plus simple dont le contenu peut se résumer à ceci :

<?php
$this->load->view("templates/header"); 
$this->load->view($contents);
$this->load->view("templates/footer"); 
?>

Vous remarquerez 3 choses :

• « templates/ » correspond au dossier que nous avons créé dans le répertoire « application/views ».
• Nous omettons l’extension des fichiers « header.php » et « footer.php », car c’est CodeIgniter qui l’ajoutera.
• $contents est une variable (dont le nom importe peu) qui sera définie dans le controlleur et correspondra à la view qui remplira le corps de la page.

header.php

Ce fichier contiendra la partie haute du site — traditionnellement nommée « header » — avec notamment l’en-tête de la page (déclarations html, section head) et la navigation du site (ce qui est à peu près la norme actuelle). Voici un exemple de ce que pourrait contenir ce fichier :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
	<title><?php echo $title; ?></title>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	<meta name="description" content="<?php echo $description; ?>" />
	<meta name="keywords" content="<?php echo $keywords; ?>" />
	<link href="/css/styles.css" rel="stylesheet" type="text/css" media="screen" />
</head>

<body>
<div class="wrap">
	<div id="header">
 		<a href="/"><img src="/css/img/logo.png" alt="logo" /></a>
		<ul id="navigation">
 			<li><?php echo anchor(base_url(), 'Accueil'); ?></li>
			<li><?php echo anchor('services', 'Services'); ?></li>
			<li><?php echo anchor('about', 'A propos'); ?></li>
			<li><?php echo anchor('contact', 'Contact'); ?></li>
		</ul>
	</div><!-- end header -->

Là encore rien de compliqué, la seule subtilité tenant dans les variables $title, $description et $keywords qui permettrons simplement de définir ces données dans le controlleur…

footer.php

Ce fichier contiendra, vous l’aurez deviné, le pied de page ainsi que les balises de fermeture de page. Voici un exemple de contenu :

	<div id="footer">
		<p>Informations de copyright</p>
	</div>
</div><!-- end wrap -->

</body>
</html>

Le controlleur

Récoltons les fruits de notre (dur) labeur ! Dans notre controlleur au lieu d’appeler directement une view, nous chargerons celle-ci dans une variable que nous transmettrons à notre template (qui est lui-même une view). par exemple :

function about()
{
	// définition des données variables du template
	$data['title'] = 'Le titre de la page';
	$data['description'] = 'La description de la page pour les moteurs de recherche';
	$data['keywords'] = 'les, mots, clés, de, la, page';
	
	// on charge la view qui contient le corps de la page
	$data['contents'] = 'page_contenu_view';

	// on charge la page dans le template
	$this->load->view('template', $data);
}

Conclusion

Et voilà, vous pouvez maintenant créer très rapidement un ou plusieurs templates de pages !

Préambule

Nous utiliserons une structure de permaliens assez classique sous la forme de « monsite.com/blog/le-nom-du-post ». Si ce n’est pas le cas, il faudra adapter la requete mysql dans le model de Codeigniter. Un petit tour dans le gestionnaire de base de données permettra aisément de repérer les colonnes à utiliser.

Le model

Comme souvent dans Codeigniter, le gros du travail se situe dans le model. Nous allons créer le fichier ‘application/models/blog_model.php’ qui contiendra ce qui suit (à noter que le code est lourdement commenté pour plus de précision) :

<?php
class Blog_model extends Model {
  function __construct() {
    parent::Model();
  }

  /**
   * Recupération des derniers posts de wordpress
   *
   * @param $count Le nombre de posts (par defaut : 5)
   */
  function get_latest_posts($count = 5) {
    // les colonnes à récupérer : à adapter à la structure des permaliens de WordPress
    $this->db->select('post_title, post_name');
    // on ne récupère que les posts qui sont publiés
    $this->db->where('post_status', 'publish');
    // on ne récupère que les posts
    $this->db->where('post_type', 'post');
    // nombre de posts à récupérer
    $this->db->limit($count);
    // ordre décroissant pour avoir les derniers posts en premier
    $this->db->order_by('ID', 'desc');

    // wp_posts = la table par défaut contenant les posts de WordPress : à adapter à votre configuration
    $query = $this->db->get('wp_posts');
    // on effectue la requete dont le résultat sera un objet. Si l'on veut un tableau on utilisera la fonction result_array()
    $data = $query->result();

    // renvoi des données au controller
    return $data;
  }
}

Le controlleur

Dans notre controller il suffira d’appeler la fonction ‘get_latest_posts()’ en attribuant sa valeur de retour à une entrée du tableau (array) des valeur transmises à la vue.

// si le model n'est pas en autoload, il faut le charger dans le controlleur
$this->load->model('blog_model');
// $data est le tableau de données transmis à la vue, $blog_posts sera la variable disponible dans la vue
// get_latest_posts(10) indique que nous voulons récupérer les 10 derniers posts
$data['blog_posts'] = $this->blog_model->get_latest_posts(10);
// on charge la vue et transmet les données à celle-ci
$this->load->view('ma_view', $data);

La vue

Finalement dans la vue il suffit de faire une boucle sur la variable $blog_posts pour afficher les X derniers posts de WordPress.

<div>
  <h2>Derniers articles du blog</h2>
    <ul>
      <?php foreach($blog_posts as $post) : ?>
      <li><a href="blog/<?php echo $post->post_name; ?>"><?php echo $post->post_title; ?></a></li>
     <?php endforeach; ?>
   </ul>
</div>