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 !

Faut-il tout transférer ?

La réponse à cette question simple l’est tout aussi : non. Pour savoir ce qu’il faut transférer il faut faire une distinction entre les fonctions qui impactent le contenu et celles qui impactent le design. Celles qui ont un impact sur le contenu ont tout intérêt à être déplacées dans un (ou plusieurs) plugins alors que les autres servent uniquement le design ou layout du site et doivent rester dans le fichier functions.php du thème.

Que faut-il (ou peut-on) transférer ?

Dès l’instant où le fait de ne plus avoir une fonction va poser un problème il serait judicieux qu’elle se retrouve dans le plugin, par exemple :

• Les shortcodes
• Les filtrages de contenu
• Les custom post types
• Les custom taxonomies
• Les ajouts à l’admin de WordPress

Que faut-il conserver dans functions.php ?

Si une fonction n’a qu’un impact visuel, notamment sur le design et la structure du site, dans ce cas il appartient directement au thème et doit par conséquent rester dans functions.php – par exemple :

• Les menus
• Les sidebars
• La pagination

Créer le plugin de fonctionnalités

La création d’un plugin est très simple et si vous savez ajouter des fonctions à functions.php alors vous pouvez créer votre plugin !

Première étape

Créez un repertoire qui porte le nom de votre plugin en n’utilisant que des lettres non accentuées, des chiffres et des tirets. Pour cette article on partira du principe que le nom du plugin est monsite-fonctions.

Dans ce répertoire créez un fichier PHP qui porte exactement le même nom : monsite-fonctions.php.

Deuxième étape

Ajoutez les commentaires en début de fichier qui permettront à WordPress de voir qu’il s’agit bien d’un plugin :

/*
Plugin Name: Fonctions de monsite
Plugin URI: http://www.monsite.com/
Description: Déplace les fonctionnalités qui impactent le contenu dans un plugin
Author: Nom Prénom
Version: 0.1
Author URI: http://www.monsite.com/
*/

Troisième étape

Il n’y a plus qu’a insérer les fonctions dans ce fichier, puis activer le plugin dans l’administration de WordPress et le tour est joué !

Conclusion

Comme vous l’avez vu il est très simple de créer un plugin rendant les fonctions clés d’un site sous WordPress indépendantes de son thème. Cela peut être également très utile dans le cas où votre client veut pouvoir changer de thème sans pour autant perdre ses fonctions. Vous pouvez également vous constituer une bibliothèque de plugins réutilisables dans d’autres thèmes.

Pour en savoir plus sur la création de plugins, je vous invite à consulter le codex de WordPress (en anglais) : writing a plugin

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 !

Functions.php

Il suffit d’ajout un tout petit bloc de code dans le fichiers functions.php :

// filtrage des recherches -> limite aux articles publiés
function filtre_recherche( $query ) {
	if ( $query->is_search && !is_admin() ) {
		$query->set( 'post_type', 'post' );
	}
	return $query;
}
// ajout du filtrage sur le hook 'pre_get_post'
add_filter( 'pre_get_posts', 'filtre_recherche' );

Ce bout de code restreindra la recherche aux seuls articles (posts) publiés. Si l’on souhaite étendre la recherche à plusieurs types, il suffit de modifier légèrement la fonction :

// filtrage des recherches -> limite aux articles publiés, aux pages et à un custom post type
function filtre_recherche( $query ) {
	if ( $query->is_search && !is_admin() ) {
		$query->set(  'post_type', array( 'post', 'page', 'custom-post-type' ) );
	}
	return $query;
}
// ajout du filtrage sur le hook 'pre_get_post'
add_filter( 'pre_get_posts', 'filtre_recherche' );

Vous l’aurez remarqué, seule la partie $query->set() change : on lui passe un array des types de posts que l’on souhaite voir apparaître dans les résultats de recherche.

Pour en savoir plus

Rendez-vous sur le Codex de WordPress : la class WP_query (qui contient la propriété $query) et le hook pre_get_posts

Happy coding !