J'ai réalisé il y a quelques jours une série de petites vidéos sur Azure, et l'une d'entre elles est spécifquement dédiée à PHP et Azure. Comment installer son application, comment utiliser les composants de Windows Azure, et quels sont les frameworks dèjà capables de faire tout ça :

 

Je ferai un billet plus spécifique à Zend Framework prochainement. Si vous avez besoin de billes rapidement, un petit mail à pierre point couzy at microsoft point com et on en discute.

Depuis novembre 2010, les évolutions de Windows Azure ont ouvert les fonctionnalités de Windows Azure, mais ces évolutions ont également apporté quelques différences de fonctionnement, notamment pour l'installation de PHP sur Azure. Voici donc les méthodes que j'ai pu trouver, et une opinion sur leur intérêt.

Installation de PHP dans Hosted Web Core

Cette technique est celle qui était préconisée avant la disponibilité de Full IIS dans Azure, et elle repose sur l'installation de PHP depuis un Web Role. Cette technique est toujours utilisable, mais il faut retoucher légèrement les projets fournis en standard par Visual Studio. En effet, le mode de paramétrage change entre IIS et Hosted Web Core. Dans Hosted Web Core, les paramètres de votre site Web sont logiquement dans Web.Config, mais vous pouvez également prendre la main sur le paramétrage d'IIS en vous appuyant sur le fichier web.roleconfig. Voici par exemple la déclaration de PHP au module fastCGI et son utilisation sur le site web :

web.roleconfig :

<configuration>
  <system.webServer>
    <fastCgi>
      <application fullPath="e:\approot\php\php-cgi.exe"/>
    </fastCgi>
  </system.webServer>
</configuration> 

 

Web.config :

  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />
    <handlers>
      <add name="PHPFastcgi" verb="*" 
           path="*.php" scriptProcessor="e:\approot\php\php-cgi.exe" 
           modules="FastCgiModule" resourceType="Either" />
    </handlers>

     ...

Malheureusement, cette belle mécanique ne fonctionne pas dans le mode Full IIS (le fichier web.roleconfig est ignoré), et la solution pour la rétablir consiste simplement à forcer votre Web Role à revenir en mode Hosted Web Core, en modifiant le fichier csdef qui définit vos rôles, et en supprimant la sections sites :

 

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="JoomlaDansAzure" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="JoomlaWeb" vmsize="ExtraSmall">
<!--
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
-->    
    <Endpoints>
      
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
    </Imports>
  </WebRole>
  
</ServiceDefinition>

 

Un grand merci au passage au blog d'Avkash Chauhan qui contient un paquet de choses intéressantes sur les évolutions d'Azure.

Installation de PHP par le biais de WebPI

C'est la technique actuellement présentée dans la majorité des posts, et elle repose sur un principe assez simple : au lieu de procéder soi-même à l'installation de PHP, on délègue cette tâche à quelque chose qui le fait déjà, et qui est en plus capable de gérer les dépendances.

Cette délégation d'installation se fait dans une startup task : juste avant d'insérer votre nouvelle instance dans le load balancer, on exécute un certain nombre de tâches sous la forme suivante :

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="InstallPHP" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="PHPWebRole">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="HttpIn" endpointName="HttpIn" />
        </Bindings>
      </Site>
    </Sites>
    <ConfigurationSettings>
    </ConfigurationSettings>
    <Startup>
      <Task commandLine="InstallPHP.cmd" executionContext="elevated" taskType="simple" />
    </Startup>
    <Endpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
    </Imports>
  </WebRole>
</ServiceDefinition>

Le fichier InstallPHP.cmd fait ensuite appel à webPI pour sélectionner la version de PHP à installer (regarder dans le Windows Azure Training Kit pour en savoir plus). Le souci, c'est que si vous voulez avoir plus de contrôle sur l'installation, il faut soit créer ses propres feeds (compliqué et fragile), soit enchaîner les installations avec WebPI en priant pour ne pas avoir de dépendance incompatible avec Azure (et il y a un hotfix de Windows 2008 qui ne s'applique pas à Azure, entre autre choses qui peuvent bloquer l'installation).

De plus, impossible de définir avec précision son php.ini ou d'ajouter une extension.

Installation manuelle de PHP dans Azure en mode Full IIS

C'est la technique que je suis en train d'explorer et pour le moment j'en suis content (mais je n'ai pas encore couvert tous les cas possibles). L'idée est de revenir au modèle proposé par Hosted Web Core. Le problème de Full IIS est qu'il est impossible de paramétrer correctement les composants d'IIS qui ne sont pas sous le contrôle de Web.Config. Après avoir un peu tourné autour du problème et lu la documentation d'installation manuelle de PHP sous IIS faite par Ruslan Yakushev, j'ai utilisé le Web.Config et une startup task.

Le début du packaging est strictement identique à celui de PHP en mode HWC : on pose son runtime dans un répertoire PHP à la racine du site Web (on peut également le déporter ailleurs sur le disque si on le souhaite en utilisant d'autres startup tasks, mais je n'ai pas encore peaufiné assez pour m'occuper de ce genre de configuration).

On insère ensuite une startup task de la forme suivante dans le csdef :

    <Startup>
      <Task commandLine="PHP\InstallPHP.cmd" executionContext="elevated" taskType="simple"></Task>
    </Startup>

Et le fichier InstallPHP.cmd fait simplement ce que faisait web.roleconfig en mode Hosted Web Core :

rem Creating IIS FastCGI process pool
%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='e:\approot\php\php-cgi.exe'] > PHPInstallLog.txt

rem Creating handler mapping for PHP requests
%windir%\system32\inetsrv\appcmd set config /section:system.webServer/handlers /+[name='PHP_via_FastCGI',path='*.php',verb='*',modules='FastCgiModule',scriptProcessor='e:\approot\php\php-cgi.exe',resourceType='Either'] >> PHPInstallLog.txt

rem Configuring FastCGI and PHP recycling
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/fastCgi /[fullPath='E:\AppRoot\PHP\php-cgi.exe'].instanceMaxRequests:10000 >> PHPInstallLog.txt
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='E:\AppRoot\PHP\php-cgi.exe'].environmentVariables.[name='PHP_FCGI_MAX_REQUESTS',value='10000']" >> PHPInstallLog.txt

rem Configuring FastCGI timeout settings
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/fastCgi /[fullPath='E:\AppRoot\PHP\php-cgi.exe',arguments=''].activityTimeout:"90"  /commit:apphost >> PHPInstallLog.txt
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/fastCgi /[fullPath='E:\AppRoot\PHP\php-cgi.exe',arguments=''].requestTimeout:"90"  /commit:apphost >> PHPInstallLog.txt

rem Changing the location of php.ini file
appcmd.exe set config  -section:system.webServer/fastCgi /+"[fullPath='e:\approt\php\php.exe',arguments=''].environmentVariables.[name='PHPRC',value='e:\approt\php\']" /commit:apphost >> PHPInstallLog.txt

A noter : en mode Full IIS, le package est déployé deux fois, une à la racine de approot et une dans un sous-répertoire qui est physiquement utilisé par IIS. La technique de déploiement ci-dessus utilise la version déployée dans AppRoot, ce qui permet de supprimer le répertoire PHP du répertoire utilisé par IIS afin de ne pas déployer le runtime PHP dans une zone du filesystem accessible en http.

Attention à un dernier détail : si vous préférez faire l'association entre votre site et FastCGI en utilisant web.config, l'exemple fourni dans les web roles CGI est incorrect : en effet, il utilise %RoleRoot% pour désigner le lecteur où est installé votre package dans la VM Azure, mais cette variable d'environnement n'est pas disponible au moment où le Web.Config est parsé, et il faut donc coder en dur E: de cette façon :

<?xml version="1.0"?>
<configuration>

  <system.web>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>

  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
    <handlers>

      <add name="PHPHandler"
           verb="*"
           path="*.php"
           scriptProcessor="E:\approot\php\php-cgi.exe"
           modules="FastCgiModule"
           resourceType="Either" />

    </handlers>
  </system.webServer>
</configuration>

Depuis quelques années, PHP prend de plus en plus d’importance en développement Web. Comment faire tourner PHP sur une plateforme Microsoft ? Comment l’installer ? Quels sont les petits (et gros) pièges ? Il est évidemment impossible d’être exhaustif en quelques pages, mais cet article essaie de balayer les fondamentaux.

Quelle version de PHP installer ?

PHP se compose aujourd’hui de plusieurs grandes briques :

• Le runtime
• Les extensions
• Les frameworks divers

Le runtime est le binaire chargé d’intercepter vos requêtes et de les traiter. La version majoritaire actuelle est PHP 5.2, mais PHP 5.3 devient rapidement la norme, et il existe des différences non négligeables entre les deux environnements, particulièrement sur une plateforme Microsoft.

En effet, les binaires PHP est composés de plusieurs sources (en gros, le runtime lui-même et les extensions), et pour les unifier il faut un compilateur adapté. Le premier compilateur utilisé fréquemment sous windows pour produire un binaire PHP est Visual C 6, c’est-à-dire un produit qui a plus de 10 ans. Même si la qualité de ce compilateur n’est pas à prouver, force est de constater qu’il a vieilli : nous en sommes aujourd’hui à la version 9, qui apporte un certain nombre de nouveautés intéressantes pout PHP :

• Compilation 64 bits
• Optimisations de performance
• Meilleure sécurité

Pour n’en citer que quelques-unes. Comme nous sommes en période de transition, vous trouverez PHP 5.3 en plusieurs versions : des versions VC6, pour assurer la compatibilité avec des modules non encore disponibles sous VC9, et VC9.

Au-delà du compilateur, il existe également deux versions de PHP : l’une est thread-safe, et l’autre non. En d’autres termes, la version thread-safe a été conçue pour être réentrante, en protégeant certaines sections de code pour garantir qu’une exécution simultanée est impossible et que vous ne pouvez pas corrompre les données d’un utilisateur lorsqu’un autre utilisateur consulte votre site Web. Intéressant ? Oui, mais le prix à payer en performance n’est pas négligeable. Utiliser la version non-thread-safe peut sembler un peu inquiétant mais rassurez-vous, l’isolation des processus est assurée à un autre niveau : dans IIS.

Comment IIS exécute vos applications PHP

IIS a la possibilité d’exécuter PHP dans trois modes, et il est important de bien les comprendre :

PHP en processus CGI

Dans ce mode d’exécution, IIS lance un nouvel exécutable PHP pour chaque nouvelle requête. Ce type de fonctionnement est extrêmement lent, et est très rarement utilisé en production. Si votre serveur reçoit une très faible charge, c’est cependant un mode d’exécution offrant une très grande stabilité.

PHP en mode ISAPI

Cette approche a longtemps été la plus performante sous IIS (et Apache, par le biais de modphp). La raison de cette performance est aussi la cause de sa fragilité : toutes les requêtes PHP sont en effet envoyées dans le même binaire PHP, et ce binaire est directement chargé dans IIS. Si l’une de vos applications se comporte mal et fait planter le binaire PHP, l’exécutable dans lequel il vit va subir le même sort, et votre serveur web entier peut tomber. Cette approche impose d’utiliser la version thread safe de PHP, et peut dans certains cas apporter un peu plus de performance que la suivante, mais au détriment de la stabilité.

PHP en mode FastCGI

Le mode fastCGI est un raffinement de CGI : comme dans CGI, IIS passe le contrôle à un autre exécutable lorsqu’une requête PHP lui parvient. La différence est dans la gestion de l’autre exécutable : dans CGI, il est simplement détruit et un autre sera relancé à la requête suivante. Dans le cas de fastCGI, l’exécutable reste chargé en mémoire et servira plus tard à traiter une autre requête. Pour les curieux, la communication entre l’exécutable et IIS est assurée par des canaux nommés en mémoire (on peut aussi utiliser des canaux TCP mais la performance est moindre). Ce mode de fonctionnement permet de fournir des performances identiques à celles de la version ISAPI, en consommant un peu plus de mémoire mais avec une stabilité très supérieure. Vous pouvez dans ce mode utiliser les versions non thread safe de PHP.

En conclusion, les configurations que vous devez privilégier sont dans cet ordre :

Version 5.3 de PHP, pour VC9, en mode non thread safe, et avec IIS en mode FastCGI.

Version 5.2 de PHP, pour VC6, en mode non thread safe, IIS en mode FastCGI

Attention : lorsque vous fonctionnez en mode fastcgi, le processus php-cgi.exe reste en mémoire entre deux appels au serveur Web. Si vous êtes en développement et que vous modifiez le runtime PHP (ajout de nouvelles extensions par exemples), il est important de redémarrer IIS pour forcer l’arrêt et le redémarrage de tous les processus PHP qui pourraient vivre en mémoire. Pour relancer IIS, je vous suggère d’ouvrir un command prompt en mode administrateur et d’y exécuter la commande iisreset chaque fois que vous en avez besoin.

Comment procéder à l’installation de PHP sous IIS

Les pré-requis

Installer PHP sous IIS est relativement simple, et demande simplement de vérifier que quelque pré-requis sont bien respectés. Microsoft met à disposition un utilitaire d’installation que je vous recommande, le Web Platform Installer (téléchargeable sur http://www.microsoft.com/web). Cet outil permet d’automatiser l’installation de toutes les dépendances de PHP, ainsi que de PHP lui-même.

Cependant, la version de PHP actuellement disponible sur WebPI n’est pas la plus récente (il s’agit de la version 5.2), et le chemin d’installation par défaut n’est pas celui que vous voudrez forcément utiliser (les binaires sont installés dans Program Files, ce qui peut être gênant notamment si vous désirez apporter des modifications à PHP.INI). Il faut également noter que l’installation contenue dans WebPI déploie automatiquement un grand nombre d’extensions alors que vous voudrez probablement minimiser celles que vous mettez à disposition de vos applications PHP.

La solution que je vous recommande est de passer par WebPI pour les prérequis et de passer par le site http://windows.php.net pour l’installation de PHP en lui-même.

Pré-requis pour installer PHP sur une machine de production :

IIS+document par défaut+contenu statique+module de réécriture d’URL

CGI - FastCGI (et son hotfix pour IIS 7)

Pour installer ces pré-requis, vous pouvez utiliser ce lien :

http://www.microsoft.com/web/gallery/install.aspx?appid= IIS60;IIS51;StaticContent;defaultdocument;directorybrowse;httperrors;httplogging;loggingtools;requestmonitor;requestfiltering;statuscontentcompression;iismanagementconsole;cgi;FastCGIIIS6;fastcgibackport

 

Installation du runtime PHP

Pour installer PHP, je vous conseille de réfléchir un peu à votre environnement de production avant de vous lancer dans l’aventure. Les questions les plus importantes sont :

• Quelles sont les permissions dont votre application a besoin sur le disque ?
• Quelles sont les extensions dont vous avez besoin pour fonctionner ?
• Quelle version de PHP comptez-vous utiliser ?
• Le serveur est-il dédié à un site PHP ou partagé par plusieurs sites ?

Si votre serveur doit héberger plusieurs applications PHP, je vous suggère de toutes les faire tourner avec la même version de PHP : c’est un peu plus de travail en recette mais beaucoup moins de risques en maintenance.

Une fois les décisions prises, passons à l’installation de PHP. La méthode que je vous recommande est de passer par l’installeur disponible sur http://windows.php.net. Ne prenez pas le zip à moins de savoir exactement ce que vous faites, car il installe un grand nombre d’extensions et ne paramètre pas FastCGI pour IIS.

L’installeur va vous guider pas à pas dans le processus d’installation et gérer pour vous trois aspects importants :

• 1/ Renseigner les variables d’environnement permettant à PHP de savoir où trouver PHP.INI
• 2/ limiter le nombre d’extensions et les configurer dans PHP.INI
• 3/ Configurer FastCGI pour IIS

La checklist est donc la suivante :

a/ Choisissez votre version de PHP (je recommande chaudement les versions Non Thread Safe)

b/ Choisissez le chemin d’installation

Si vous comptez utiliser plus d’une version de PHP, je vous suggère de créer l’arborescence suivante :

Vous installerez la version principale de PHP dans \PHP\Default, en vous réservant la possibilité d’installer des binaires spécifiques dans un répertoire correspondant au nom du site que vous souhaitez personnaliser.

c/ Choisissez les modules que vous voulez installer. Moins vous en aurez, mieux vous maitriserez la configuration de votre site. A noter que l’installeur proposé sur http://windows.php.net permet de modifier la liste des extensions installées par simple ré-exécution du MSI.

d/ Demandez l’installation de PHP pour FastCGI. Vous pourrez par la suite faire pointer d’autres sites vers d’autres versions de PHP, mais il est nécessaire de faire une première fois un certain nombre de tâches de configuration dans IIS, et c’est ce que permet cette option.

Paramétrage de PHP pour une bonne exécution sous Windows.

Ce paramétrage doit se faire à deux niveaux : d’une part dans IIS, pour que les requêtes soient correctement passées et que IIS puisse gérer quelques aspects spécifiques à PHP, et ensuite dans votre php.ini, qui doit lui aussi être adapté pour un bon fonctionnement sous IIS.

Le paramétrage d’IIS et FastCGI

Pour que PHP se comporte correctement, vous devez définir ou vérifier un certain nombre de paramètres définis dans IIS, et plus spécifiquement dans les paramètres fastCGI :

Vous voyez dans la copie d’écran ci-dessus quelques-uns des paramètres définis pour l’exécution de PHP via FastCGI. Les paramètres importants sont les suivants :

Nombre max d’instances : c’est le nombre de processus php-cgi.exe que FastCGI est autorisé à exécuter simultanément. Vous pouvez mettre 0 pour laisser FastCGI optimiser ce paramètre en fonction de votre configuration

Demandes d’instance max : ce paramètre définit le nombre de requêtes acceptés par votre processus avant recyclage. Attention, PHP dispose de son propre système de recyclage de processus, et vous devez vous assurer que celui-ci ne prendra pas la main au mauvais moment. Pour ce faire, il vous faut modifier une variable d’environnement définie au lancement du processus php-cgi.exe par FastCGI :

Vous voyez ici l’ensemble des paramètres vous permettant d’influer sur le comportement de php :

Analyser les modifications du fichier permet de définir le paramètre MonitorFileChanges, il sert à redémarrer les instances de php-cgi.exe en cas de modification du fichier php.ini (ce qui vous évitera de faire iisreset à chaque mise à jour).

Le nombre maximal de demandes d’instances doit être supérieur à PHP_FCGI_MAX_REQUESTS : ce dernier paramètre est celui que PHP utilise pour déterminer qu’il doit redémarrer, et vous ne voulez pas que PHP redémarre sans en avoir reçu l’ordre depuis IIS.

L’autre variable d’environnement est très importante : PHPRC est en effet l’une des techniques que le runtime PHP utilise pour déterminer le chemin d’accès au fichier PHP.INI qu’il doit prendre en compte. Si vous désirez déployer en production plusieurs versions de PHP, c’est ce paramètre qui vous permettra de faire pointer chaque runtime PHP vers son PHP.INI.

Le paramétrage de php.ini

Ce fichier comporte le paramétrage fin de PHP, ainsi que la liste des extensions chargées au démarrage de PHP. Voici la liste des points à vérifier sur votre installation :

fastcgi.impersonate = 1

Ce paramètre permet à PHP de fonctionner sous le compte utilisé par IIS. Pour les accès anonymes sous IIS7 et IIS7.5 il s’agit du compte IUSR, et c’est à lui que vous devrez donner les permissions adéquates (par exemple pour utiliser la sécurité intégrée dans sql server, ou accéder à des fichiers)

cgi.fix_pathinfo=1

Il s’agit d’une correction mineure des variables d’environnement.

cgi.force_redirect = 0

Pas ou peu de documentation sur ce paramètre, il est apparemment utilisé pour Apache pour mitiger un risque de sécurité

extension_dir = "…"

C’est l’emplacement où résident les extensions que vous désirez monter dans le runtime PHP.

Quel est le compte qui fait tourner votre runtime PHP ?

Attention, cette section est capitale pour comprendre la sécurité et les droits d’accès de votre application, et les bonnes pratiques sont bienvenues en ce domaine, particulièrement si vous hébergez plusieurs applications Web sur un environnement de production. Afin de simplifier un peu la discussion je vais me limiter aux versions récentes de Windows, les comptes de sécurité par défaut ayant pas mal évolué dans les dernières versions d’IIS.

L’identité de votre processus est déterminée par un ensemble d’étapes. Supposons qu’une bête requête arrive sur votre serveur, et voyons comment IIS va la traiter et déterminer qui l’exécute.

1/ Le serveur accepte les accès anonymes

Dans ce cas, IIS va utiliser l’identité associée à l’utilisateur anonyme pour déterminer s’il a le droit de poursuivre son chemin jusqu’à la page (ou image) demandée. Le premier compte à connaître est celui qu’IIS tente d’attribuer à PHP-CGI.exe. Dans IIS, les applications Web sont exécutées dans des pools d’applications. Chaque pool d’applications a un paramètre important pour PHP : son identité. Les valeurs courantes de cette identité sont :

LocalService, NetworkService, ou LocalSystem

Ce sont les comptes de service pré-définis habituels. Il existe cependant un autre type d’identité prédéfinie :

ApplicationPoolIdentity

Il s’agit d’un compte nommé IIS APPPOOL\NomDuPool qui est créé et maintenu dynamiquement par le système. Choisir ApplicationPoolIdentity (c’est la valeur par défaut sous IIS 7.5) permet d’avoir automatiquement un compte de service distinct par pool d’application, et donc une meilleure isolation entre les différents sites web associés à ces pools.

Tout compte de votre choix

Vous pouvez bien évidemment attribuer un compte de votre choix.

Est-ce que ce compte est celui qui fait tourner mon processus PHP ?

Oui et non : en mode anonyme oui, en mode authentifié c’est une question de paramétrage

2/ Le serveur refuse un accès anonyme.

Dans ce cas, IIS et le navigateur vont négocier pour déterminer votre identité. Si cette identité est un compte windows, PHP va prendre une décision en fonction du paramètre fastcgi.impersonate présent dans PHP.INI. Si cette valeur est à 1, l’identité qui exécute votre requête est celle de l’utilisateur. Si la valeur est nulle, c’est toujours le compte anonyme qui exécute php-cgi.exe.

Attention, il est également possible de changer cette valeur dans les paramètres du site, auquel cas le compte défini pour le site sera utilisé en lieu et place du compte défini par le pool d’applications.

Quelques erreurs fréquentes

Attention, les pièges sont nombreux sur les extensions, en voici quelques-uns :

Mauvaise version de PHP.INI : veillez toujours à contrôler que PHP utilise bien le PHP.INI de votre choix, si ce n’est pas le cas vérifiez la variable d’environnement PHPRC. Le symptôme : vous modifiez PHP.INI et vos modifications ne sont pas prises en compte.

Oubli du redémarrage d’IIS : si vous n’avez pas correctement configuré IIS pour qu’il redémarre automatiquement PHP lorsque vous modifiez le fichier php.ini (par défaut il n’est pas surveillé), les modifications de php.ini ne sont prises en compte qu’au lancement d’un nouveau php-cgi.exe. Symptôme : vous faites des modifications et vous testez, le comportement est variable (vous tombez une fois sur deux sur le php-cgi.exe qui a pris en compte vos modifications, et une fois sur deux sur le précédent).

Mauvaise version des extensions : si vous ne prenez pas la version de l’extension correspondant à votre binaire (version thread safe sur un binaire php non thread safe par exemple), son chargement ou son initialisation échouent. Symptômes : variés, depuis la page blanche jusqu’à un message d’erreur abscons.

open_basedir = "…"

Cette directive permet de restreindre les droits d’accès fichier du runtime PHP aux répertoires spécifiés (séparateur : point-virgule). Veillez à terminer le nom de chaque répertoire par un antislash.

Pour vérifier (et paramétrer) simplement les aspects PHP.ini, n’oubliez pas PHP Manager.

Je viens d’installer la beta du module d’administration PHP pour IIS (http://phpmanager.codeplex.com/). C’est l’œuvre de Ruslan Yakushev, qui a aussi pondu Wincache (http://www.iis.net/download/wincacheforphp).

 

En deux mots, c’est un assistant de configuration de PHP sous IIS qui permet de

 

• Mettre en place N versions de PHP sans douleur
• Accéder à PHP.ini de façon lisible (une grande première)
• Choisir les extensions à charger parmi les extensions disponibles.
• Accéder aux logs de PHP
• etc..

 

 

Installer correctement PHP sous Windows est plus simple que par le passé, mais les docs disponibles sur internet sont souvent datées et proposent plein de petites astuces qui marchent pas ou mal, cet outil donne une configuration simple et sans surprises.