PHP sous Windows 2008 : installer WordPress en pratique

Auteur : Sébastien Warin Microsoft Student Partner Développeur Wygwam

Introduction

Les personnes qui ont déjà installé une application telle que WordPress connaissent son installation en « 5 minutes ». Cependant l’installation de WordPress – et c’est également le cas d’autres applications spécifiquement développé pour Apache – sur un serveur IIS 7.0 est un peu différente de ce que l’on a l’occasion de faire sur un serveur Apache.

En effet sous IIS 6.0, nous avons le choix d’exécuter notre PHP au travers des CGI, ISAPI ou alors, un composant qui est plus performant : le Fast-CGI pour IIS6.0 qui n’est ni plus ni moins qu’un filtre ISAPI utilisant de manière optimisée le processus "php-cgi.exe". Vous toruverez une documentation pour l’installation de PHP en Fast-CGI sur IIS6.0 ici

De plus, WordPress utilise un module Apache nommé mod_rewrite pour faire profiter aux utilisateurs des permalinks (liens permanents). Comme vous vous en doutez, ce module n’est pas compatible avec IIS 7.0 puisque spécifique à Apache. Ainsi pour éviter les erreurs 404 et profiter de l’URL rewriting qui permet d’utiliser des URLs plus conviviales et donnant plus de visibilité quant au contenu pour les moteurs de recherche, vous allez devoir recourir à un module personnalisé.

Installation de PHP 5 sous IIS 7.0

Préparation de IIS pour Fast-CGI

Tout d’ abord, sous IIS 7.0 nous disposerons de deux modules natifs qui nous intéressons fortement nommé "CgiModule" et "FastCgiModule" qui vous faudra activer lors de l’ installation du rôle Web Server en sélectionnant entre autre "CGI" :

Les deux modules devraient être activés dans le fichier de configuration de IIS (dans %systemroot%\system32\inetsrv\config\applicationHost.config) sous la section globalModules (étant donné que ce sont des modules natifs).

<configuration>
    ....
    <system.webserver>
        ....
        <globalmodules>
            ......
            <add image="%windir%\System32\inetsrv\cgi.dll" name="CgiModule" />
            <add image="%windir%\System32\inetsrv\iisfcgi.dll" name="FastCgiModule" />
            ......

La commande "appcmd list modules" devrait d’ ailleurs vous indiquer le bon chargement de ces deux modules :

1  C:\Users\Administrator>%systemroot%\system32\inetsrv\appcmd list modules
2  .....
3  MODULE "CgiModule" ( native, preCondition: )
4  MODULE "FastCgiModule" ( native, preCondition: )
5  .....
6  C:\Users\Administrator>

Installation de PHP et configuration Fast-CGI pour PHP

Il vous faudra ensuite configurer le module Fast-CGI avec PHP. Pour cela :

1. Télécharger PHP 5 (en ZIP) que vous décompresserez dans c:\PHP\.
2. Créer une copie du fichierphp.ini-recommanded et le renommer en php.ini.
3. Éditez ce fichier et redéfinir extension_dir = "C:\PHP\ext" qui nous servira un peu plus tard pour activer quelques extension de base de PHP. Pour plus d’informations sur l’installation et la configuration de PHP je vous renvoi sur le site PHP.net.
4. Rajoutez le bout de XML suivant dans votre fichier applicationHost.config dans la section system.webServer pour configurer le Fast-CGI au niveau de votre serveur :

1  <configuration>
2      ....
3      <system.webserver>
4          ......
5          <fastcgi>
6              <application fullpath="C:\PHP\php-cgi.exe" />
7          </fastcgi>
8          .......

Vous pouvez aussi réaliser cette manipulation par la simple commande :

appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php\php-cgi.exe']

Ajout du handler sur les extensions PHP

Une fois le module de Fast-CGI installé et configuré, nous allons ajouter un handler sur l’extension PHP afin que le module Fast-CGI exécute nos pages PHP. Vous pouvez ajouter ce handler directement au niveau de votre fichier applicationHost (au niveau "serveur") afin que tous vos sites IIS enfants héritent de cette configuration ou alors définir ce handler dans vos fichier web.config au niveau de votre "site", "application" ou même "répertoire virtuel".

Dans notre cas, nous ajouterons ce handler au niveau de notre serveur. Pour cela trois méthodes :

Dans le fichier configurationapplicationHost.config, ajouter la ligne ci-dessous sous la section system.webServer dans <location path=""> (qui regroupe la configuration de tous les sites IIS de notre serveur)

1  <configuration>
2      ....
3      <location overridemode="Allow" path="">
4          ....
5          <system.webserver>
6              ......
7              <handlers accesspolicy="Read, Script">
8                  ......
9                  <add name="PHP-FastCGI" path="*.php" resourcetype="Either" scriptprocessor="c:\php\php-cgi.exe" modules="FastCgiModule" verb="*" /> 
10                 ......

• Par AppCmd en tapant la commande :

appcmd set config /section:system.webServer/handlers /+[name='PHP-FastCGI',path='*.php',verb='*',modules='FastCgiModule',scriptProcessor='c:\php\php-cgi.exe',resourceType='Either' ]

• Par la console d’ administration IIS, en sélectionnant le serveur puis sur la page des features sélectionner "Handler Mapping" pour ajouter un nouveau handler et compléter le formulaire comme sur la capture ci-dessous :

Nous pouvons dès maintenant créer un fichier .PHP dans l’un des sites IIS avec un simple <?php echo "Hello PHP" ?> pour s’ assurer que votre PHP est correctement exécuté par le serveur IIS.

Installation de WordPress

Les pré-requis : extensions PHP, MySql et phpMyAdmin

Tout d’abord revenons dans le fichier de configuration de PHP (C:\PHP\php.ini dans notre cas) et dé-commenter les lignes suivantes afin d’activer ces extensions pour le bon fonctionnement de WordPress et phpMyAdmin:

extension=php_curl.dll
extension=php_gd2.dll
extension=php_mbstring.dll
extension=php_mcrypt.dll
extension=php_mysql.dll
extension=php_mysqli.dll

Nous allons ensuite installer un serveur MySql pour héberger notre base WordPress. Vous retrouverez l’installeur de MySql pour Windows ici.

Ensuite, installer un phpMyAdmin et créer la base WordPress ainsi qu’ un utilisateur :

1. Télécharger phpMyAdmin
2. Le décompresser dans un de nos sites IIS maintenant prêts pour accueillir du PHP
3. Naviguer avec votre navigateur sur l’URL de cette application pour lancer la configuration (temporairement donner les droits CT dans votre dossier phpMyAdmin afin que l’ application PHP puisse créer le fichier de configurationconfig.inc.php)
4. Créer ensuite un utilisateur (sur la page "Privilèges" > "Ajouter un utilisateur") en donnant un login et mot de passe et sélectionner "Créer une base portant son nom et donner à cet utilisateur tous les privilèges sur cette base" comme montré sur la capture ci-dessous :

Installation de WordPress 2.3.3 sur IIS

Il ne nous reste plus qu’ a installer WordPress (à télécharger ici) avec La Célèbre Installation en 5 Minutes! Mais attention la version actuelle de WordPress, version 2.3.3, ne fonctionnera pas sur un Windows/IIS au niveau de l’installation dû a des erreurs d’ insertion SQL de ce type :

WordPress database error Table 'wpdemo.wp_options' doesn't exist for query SELECT option_value FROM wp_options WHERE option_name = 'siteurl' made by is_blog_installed

Pour résoudre ce problème remplacer le code du fichier wp-db.php du dossier wp-includes par le code publié sur Pastebin de wpforums - Fi for CGI Error - message n° 893007.

Configuration des Permalink avec MyWordPressUrlRewriteModule

Maintenant le WordPress est fonctionnel sur le serveur IIS7, intéressons-nous aux URL de notre blog, appelés aussi permalink (liens permanents).

Par défaut les liens sont sous la forme : http://www.monblog.com/?p=123 ce qui n’est très explicite sur le contenu de cette page. WordPress nous permet alors dans l ‘interface d’administration sous "Options > Permaliens" de redéfinir la structure de ces liens pour avoir des URLs personnalisées du genre http://www.monblog.fr/index.php/2008/02/19/sample-post/ qui est déjà plus convivial.

Mais il reste encore un élément dérangeant : le "/index.php/" dans l’ URL reste indispensable pour que WordPress puisse traiter la requête. Nous pourrions jongler avec les erreurs 404 ou utiliser des filtres ISAPI dans un pipeline en mode classique mais là n’est pas le but de cet article. Nous allons donc utiliser tout l’intérêt de IIS 7.0, à savoir le mode intégré d’un pool d’application qui permet l’exécution de modules natifs et managés dans notre pipeline IIS.

Nous allons utiliser Visual Studio 2005 ou 2008 pour créer un module IIS capable de gérer ces différents points.

Création du module IIS

Sous Visual Studio, Ouvrir > Site Web > Local IIS et sélectionner votre site où ce trouve votre blog WordPress. Ajouter alors une classe nommée MyWordPressUrlRewriteModule.cs qui viendra se placer dans le dossier App_Code (créé automatiquement par VS).

Implémenter ensuite l’interface IHttpModule et abonnez-vous à l’événement  BeginRequest de notre "context" (de type HttpApplication) dans la méthode Init. A l’appel de cette événement nous allons simplement tester si le PhysicalPath de notre Request est un fichier ou dossier existant au quel cas nous ne ferons rien. A l’inverse, nous appellerons la méthode RewritePath en rajoutant ~/index.php devant notre RawUrl.

Le code de notre module sera donc très simple :

1   using System;
2   using System.IO;
3   using System.Web;
4   
5   public class MyWordPressUrlRewriteModule : IHttpModule
6   {
7       public void Dispose()  { }
8    
9       public void Init(HttpApplication context)
10      {
11          context.BeginRequest += new EventHandler(context_BeginRequest);
12      }
13   
14      void context_BeginRequest(object sender, EventArgs e)
15      {
16          HttpApplication context = (HttpApplication)sender;
17          string physicalPath = context.Request.PhysicalPath;
18          if (!(File.Exists(physicalPath) || Directory.Exists(physicalPath)))
19          { 
20              context.Context.RewritePath("~/index.php" + context.Request.RawUrl);
21          }
22      }
23  }

La méthode RewritePath permet simplement de redéfinir un chemin d’accès interne. Prenons ces quelques exemples :

Comme nous le voyons, les fichiers wp-login.php, site d’administration dans le répertoire wp-admin ou vos thèmes, plugins et médias de vos posts/pages dans le dossier wp-content ne seront pas affectés par notre module car ces derniers sont des fichiers physiquement existants par rapport avec l’URL demandée. Par contre les URLs du type http://www.monblog.fr/2008/02/19/sample-post/ n’existe pas physiquement et donc seront "rewrités" par notre module sur l’URL http://www.monblog.fr/index.php/2008/02/19/sample-post/ qui sera ensuite attrapée et interprétée par WordPress.

Activation du module dans le pipeline IIS

Une fois le module développé, vous devrez l’ activer au niveau du site IIS hébergeant WordPress. Pour cela, depuis la console d’ administration IIS sur le site IIS de WordPress, entrer dans la feature "Modules" et ajouter depuis le panneau Action un module managé. IIS compilera dynamiquement votre site et détectera votre module que nous pourrons ensuite sélectionner comme "Type" comme le montre la capture ci-dessous :

Nous pouvons aussi ajouter manuellement dans le fichier web.config au niveau de la racine de votre site IIS (créé par Visual Studio lors de l’ouverture du site) une balise add contenant la définition de notre module :

1  <configuration>
2      ....
3      <system.webserver>
4         ....
5          <modules>
6              ......
7              <add name="MyWpUrlRewrite" type="MyWordPressUrlRewriteModule" />
8              ......

Configuration des permalinks dans WordPress

Une fois le module installé, il ne reste plus qu’à personnaliser les permalinks dans l’ interface d’ administration de WordPress dans "Options > Liens permanents" et personnaliser l’URL comme par exemple : /%year%/%monthnum%/%day%/%postname%/

En naviguant sur l’une des pages du blog vous devriez être capable de consulter des URLs de la forme http://www.monblog.fr/2008/02/19/sample-post/. Ce format correspond à ce que nous avions spécifié dans la structure des "permaliens".

Module local ou partagé ?

N’oubliez pas que nous n’avons pas compilé notre module, il est simplement activé de manière locale sur notre site IIS WordPress. Cependant, il se peut que vous ayez plusieurs sites IIS hébergeant un site WordPress et par conséquent autant de sites IIS qui ont besoin de ce module.

Pour cela, au lieu de recopier le code de votre module dans chaque site, il est préférable de compiler la classe du module dans une assembly que vous placerez dans la GAC.

Ouvrez Visual Studio et créer un projet de type "Bibliothèque de classes" dans lequel vous placerez la classe de notre module. Dans les propriétés de votre projet, dans l’onglet "Signature", activez la signature de votre assembly :

Toujours dans la page des propriétés de votre projet, dans l’onglet "Événements de génération", entrez la commande suivante afin de placer votre assembly signé dans la GAC afin de partager votre module sur votre serveur.

1  call "%VS90COMNTOOLS%\vsvars32.bat" > NULL
2  gacutil.Exe /if "$(TargetPath)"

Néanmoins, soyez averti qu’à chaque compilation, votre module sera réinstallé dans la GAC et donc déployé pour tous vos sites.

Dans la console d’administration IIS, en ajoutant un nouveau module vous trouverez dans les modules disponibles votre module avec un nom beaucoup long de type : MyWordPressUrlRewrite.MyWordPressUrlRewriteModule, MyWordPressUrlRewriteService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=54ce8ebb28415bb0. Cette forme de nom est appelé un nom fort (strong name) et permet d’identifié de manière fiable une assembly.

<configuration>
    ....
    <system.webserver>
        ....
        <modules>
            ......
            <add name="WpUrlRewrite" type="MyWordPressUrlRewrite.MyWordPressUrlRewriteModule, MyWordPressUrlRewriteService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=54ce8ebb28415bb0" />
            ......

A partir de maintenant vous êtes capable d’ajouter votre module sur chacun de vos sites IIS utilisant WordPress depuis la console d’ administration IIS ou dans le fichier de configuration de votre site IIS (web.config) manuellement en XML. Néanmoins, attention à ne pas l’activer au niveau de votre serveur (applicationHost.config) car cela risquerait de perturber vos applications « non WordPress »

Conclusion

Au travers de cet exemple d’utilisation qui a montré l’installation et la configuration d’un site web PHP, nous avons mis en avant quelques soucis susceptibles de survenir lors de l’exécution d’application testées et réalisées pour les serveurs Apache. Néanmoins, Windows Server 2008 montre outre des performances élevées, une excellente fiabilité d’exécution des applications PHP qu’elles aient été spécialement conçu pour IIS 7 ou non mais aussi une grande modularité de part l’extensibilité du pipeline en code natif ou managé.

La prise en charge native de PHP par Windows Server 2008 va enfin permettre aux entreprises de pouvoir utiliser leur système existant pour y déployer et gérer plus aisément leur parc applicatif d’application PHP, et ceux même aux côtés d’applications non PHP.