pilgrim[.maleo.net]

Si vous êtes le développeur d'un site ou d'une application visant � être distribuée sans connaître la configuration du serveur sur lequel elle sera installée, il est important de coder de manière « générique » en pensant aux maximum de cas possibles tant au niveau de la configuration du serveur (Linux/Windows, Apache/IIS, httpd.conf, php.ini, etc.) que des différences entre les versions successives de PHP (notament PHP < 4.1, PHP 4.2 et 4.3 et PHP 5).

Sitepoint.com a publié un article intitulé PHP Gotchas: Part 1 traitant des points � prendre en compte lors du développement d'une application web en PHP concernant la portabilité de cette application en regard de la configuration du serveur sur lequel elle tourne (différences entre les php.ini d'un serveur � l'autre par exemple).

Les points suivants sont abordés et doivent surtout être pris comme étant des points de départ pour la recherche de vos propres méthodes :

• modification de la configuation de PHP via les fichiers php.ini et/ou httpd.conf et .htaccess
• redéfinition de la configuration nécessaire au sein même de votre application (de manière � être indépendant de la configuration du serveur dans le cas où vous ne pouvez pas la maîtriser)
• sécurisation et débuggage de l'application en positionnant correctement certains paramètres de configuration (error_reporting, register_globals, ...)
• programmation en ayant � l'esprit que votre application peut être installée aussi bien sur un serveur Unix/Linux que Windows (utilisation des constantes PHP_OS et DIRECTORY_SEPARATOR)

Bien d'autres astuces et méthodes existent et sont � prendre en compte, je me permettrais de vous en proposer deux que j'utilise régulièrement et qui sont les suivantes :

Redéfinition du chemin des fichiers inclus (include_path)

Etant un fervent utilisateur de la librairie PEAR DB, je suis toujours confronté au fait que le fichier de base de cette librairie (comme toutes celles de PEAR d'ailleurs) doit nécessairement être accessible dans le chemin des fichiers inclus ; je dois donc redéfinir ce chemin si PEAR n'est pas déj� installé sur le serveur.

J'ai toujours un répertoire includes � la racine de mon site et toujours un fichier common.php ou prepend.php � l'intérieur et que j'inclus au début de chacun de mes scripts. J'utilise donc les deux lignes suivantes au début de ce fichier pour redéfinir mon include_path ce qui me laisse ensuite libre cours pour l'utilisation des classes PEAR :

$include_path = array('.', dirname(__FILE__), dirname(__FILE__).'/pear');
ini_set('include_path', join(( ( substr(PHP_OS, 0, 3) == 'WIN' ) ? ';' : ':'), $include_path));

On peut voir ici que mon include_path contient trois chemins d'accès, � savoir :

1. le répertoire courant '.',
2. mon répertoire includes (en fait celui qui contient mon fichier commun),
3. un sous-répertoire pear situé dans includes qui me permet de stocker les fichiers de PEAR

On peut voir aussi que le séparateur de chemin est défini dynamiquement en fonction du système d'exploitation (';' pour Windows et ':' pour Unix/Linux). Cette méthode permet d'être certain que l'application tournera bien aussi sous Apache ou IIS sur une plateforme Windows.

Il faut noter qu'une constante PATH_SEPARATOR a été introduite � partir de la version PHP 4.3.4 pour ne pas avoir � se poser de question � ce sujet. Un paliatif � cette constante pour des versions inférieures � 4.3.4 serait d'utiliser le code suivant en début du fichier commun :

if ( !defined('PATH_SEPARATOR') ) {
    define('PATH_SEPARATOR', ( substr(PHP_OS, 0, 3) == 'WIN' ) ? ';' : ':');
}

Compatibilité avec Microsoft IIS

Les variables serveurs (celles accessibles via $_SERVER) ne sont pas toutes les mêmes pour Apache et IIS; par exemple, REQUEST_URI n'existe pas et est remplacée par PATH_INFO (arrêtez-moi si je me trompe).

Pour avoir une application portable, il faut donc utiliser une variable qui existe bien dans toutes les configurations possibles; pour ma part, j'utilise le code suivant au début de mon fichier commun pour palier � l'abscence de REQUEST_URI :

if ( !isset($_SERVER['REQUEST_URI']) ) {
    $_SERVER['REQUEST_URI'] = $_SERVER['PHP_SELF'];
    if ( isset($_SERVER['QUERY_STRING']) && !empty($_SERVER['QUERY_STRING']) ) {
        $_SERVER['REQUEST_URI'] .= '?'.$_SERVER['QUERY_STRING'];
    }
}

On voit ici que si REQUEST_URI n'existe pas, on recréé sa valeur � partir de PHP_SELF et de QUERY_STRING si des paramètres existent dans l'URL. Ce code est bien entendu adaptable � n'importe quelle autre variable qui ne serait pas présente sous IIS et donc vous auriez besoin.

Pour conclure cet article, je vous suggère de lire l'article Plusieurs versions de PHP sur un même serveur que j'ai écrit il y a quelques temps et qui traite de la portabilité d'une application PHP non pas entre différents serveurs mais entre différentes versions de PHP comme le titre l'indique. En combinant les deux aspects de portabilité dont il est fait mention ici, vous ne devriez plus avoir de problèmes d'installation et de configuration de vos sites et applications :).