Dans la vie de tous les jours…

Maintenant que nous avons installé notre serveur, il va probablement falloir effectuer quelques réglages, comme activer des modules Apache ou des extensions PHP, mais aussi spécifier un paramètre important depuis PHP 5.3. WAMP permet de faire cela très simplement.

Paramétrer Apache

Apache est lui-même composé de modules, dont certains sont activés dès l’installation de WAMP, soit parce qu’ils sont souvent utilisés et que l’entreprise qui fournit WAMP a prédéfini qu’il serait activé, soit… parce qu’ils sont au cœur même de notre serveur. 
En effet, l’un des modules permet l’utilisation de PHP avec Apache. Il est donc activé dès l’installation.

Mais ce n’est pas nécessairement le cas de tous les modules, notamment l’un d’entre eux qui revêt beaucoup d’importance si vous utilisez un framework comme CodeIgniter, Laravel ou Symfony, voire même plus simplement un CMS comme Joomla!, Drupal ou WordPress : celui qui permet de faire des réécritures d’URLs, afin de pouvoir éviter des adresses comme ?module=Item&action=show&idItem=23 et les voir sous la forme /Item/show/23, par exemple. J’ai nommé mod_rewrite, parfois désigné par son identificateur rewrite_module.

Nous allons vérifier de suite s’il est activé afin de changer cela au besoin.

Une fois n’est pas coutume, rendez-vous dans le menu de WAMP accessible par un clic sur l’icône dans la barre de statut, puis pointez Apache > Modules Apache.

La liste qui apparaît est celle des modules existants pour Apache, mais les noms affichés sont les identificateurs. À côté de leurs noms, on peut voir trois choses :

• Rien
  C’est le cas le plus courant. Le module est disponible, mais pas activé.
  Dans le fichier de configuration, cela se traduit par une ligne commentée.
• Une coche verte (✓)
  Second cas le plus courant, qui signifie que le module est activé, donc disponible.
  Dans le fichier de configuration, la ligne est décommentée.
• Un i dans un cercle bleu (ⓘ)
  Cas particulier qui indique que le module ne peut pas être désactivé. C’est notamment utilisé pour les modules permettant d’exécuter une certaine version de PHP avec Apache (soient php5_module, php7_module ou php_module). Les modules dans cet état sont, avec les versions récentes de WAMP, regroupés en fin de liste.
• Un carré rouge (■)
  Les fichiers nécessaires au fonctionnement du module ne sont pas présents. C’est donc à vous de les trouver et de les placer dans le dossier %WAMPDIR%\bin\php\php%PHP_VERSION%\ext si vous en avez besoin. Ceci fait, la ligne s’affichera comme dans le second cas.
• Un panneau "attention" (⚠)
  Les fichiers nécessaires au fonctionnement du module sont présents, mais pas la ligne à décommenter dans le fichier de configuration. Il vous faudra aller l’insérer à la main si vous avez besoin de ce module.

Vérifiez l’état de rewrite_module dans la liste. Un clic dessus permet de passer d’un état à un autre. Notez que cela va faire redémarrer Apache automatiquement, et Apache uniquement, ce qui veut dire que l’icône ne passera que par l’orange. Si l’icône redevient verte, vous pouvez immédiatement utiliser les fonctionnalités qu’offre le module.

Paramétrer PHP

WAMP permet de paramétrer deux choses distinctement par son menu. Si les possibilités et le fonctionnement sont similaires à celui des modules Apache, ce n’est pas pour rien qu’il y a deux menus séparés. Par contre, les possibilités sont un peu différentes de ce que l’on peut observer pour Apache. Qui plus est, selon le menu, certaines options n’y sont pas observables.

• Rien
  De même que pour Apache, l’extension est disponible, mais pas activée.
  Dans le fichier de configuration, cela se traduit par une ligne commentée.
• Une coche verte (✓)
  Là aussi, cela veut dire que l’extension est activée.
  Dans le fichier de configuration, la ligne est décommentée.
• Un triangle vert pointant vers la droite (▶) C’est l’indication que le paramètre ne supporte que certaines valeurs. Celles-ci sont généralement listées et fournies dans un nouveau sous-menu.
• Un i dans un cercle bleu (ⓘ)
  Ici, ce n’est pour PHP qu’une indication sur une valeur particulière de la configuration.
• Un panneau "attention" (⚠)
  Les fichiers nécessaires au fonctionnement du module ne sont pas présents. C’est donc à vous de les trouver et de les placer dans le dossier %WAMPDIR%\bin\php\php%PHP_VERSION%\ext si vous en avez besoin. Ceci fait, la ligne s’affichera comme dans le premier ou deuxième cas.
• Un carré rouge (■)
  Les fichiers nécessaires au fonctionnement du module sont présents, mais pas la ligne à décommenter dans le fichier de configuration. Il vous faudra aller l’insérer à la main si vous avez besoin de ce module.

Voilà, maintenant regardons les menus disponibles qui nous intéressent.

Les extensions

PHP propose aussi des fonctions optionnelles, qui sont elles aussi activées ou non à l’installation. Si on parlait de modules avec Apache, on parle plutôt d'extensions avec PHP. L’une d’entre elles qu’il est intéressant d’activer est php_openssl, qui permet d’établir des connexions distantes en https avec file_get_contents() ou cURL, entre autres.

Affichez la liste des extensions PHP disponible en passant par l’icône de WAMP > PHP > Extensions PHP. La liste est bien plus courte que celles des modules Apache, vous n’aurez pas de mal à voir où se trouve php_openssl et l’activer au besoin. 
Là aussi, WAMP va redémarrer Apache uniquement, donc l’icône passera à l’orange avant de redevenir verte.

La configuration PHP

Outre le menu Extensions PHP, il y a aussi Configuration PHP. Les éléments de ce menu n’activent pas des fonctionnalités supplémentaires, mais plutôt changent le comportement de PHP en général. On y trouve des options relatives à la sécurité comme allow_url_fopen, qui détermine si on peut ouvrir un fichier hébergé sur un autre site avec les fonctions de lecture de fichiers (fopen(), file_get_contents() ou encore readfile() pour n’en citer que quelques unes), ainsi que allow_url_include, qui gère la possibilité d’inclure (avec include, require, include_once et require_once) des scripts sur des sites distants. C’est aussi là qu’on trouve short_open_tags, qui, si c’est activé, permet d’utiliser <? au lieu de <?php.
Il est justement conseillé de désactiver cette option depuis PHP 5.4, où elle était souvent activée parce que cela gérait aussi l’utilisation de <?=. Or, toujours depuis PHP 5.4, <?= est désormais utilisable que l’on ait activé short_open_tags ou non.
Ce dont il faut se rendre compte, c’est que la version courte <? est aussi l’ouverture de la déclaration XML, et cela pose problème quand on génère un fichier XML avec PHP avec cette option activée. De fait, de nombreux CMS et frameworks actuels recommandent, voire exigent, que cette directive soit désactivée.

Certains paramètres n’acceptent pas n’importe-quelle valeur, mais une parmi un ensemble précis : c’est notamment le cas du paramètre date.timezone. Depuis la version 3.0.6, ce paramètre peut aussi être modifié depuis le menu Configuration PHP, et vous pouvez choisir le fuseau horaire de référence par continent, puis par ville. Pour les versions précédentes, il fallait éditer le fichier de configuration à la main.

Encore une fois, Apache devra redémarrer, donc icône à l’orange, puis verte.

Parce que c’est Apache qui utilise PHP, et donc Apache qui doit savoir comment PHP est configuré. La configuration de PHP est lue au démarrage d’Apache, donc il faut le redémarrer pour que la nouvelle configuration soit prise en compte. 

Paramétrer votre SGBD

De manière similaire, vous pouvez accéder à certains paramètres de votre SGBD en passant par le menu de WAMP. Vous pouvez modifier la taille des buffers de tri, le temps de blocage sur les tables InnoDB, ou encore le détail des fichiers de logs. Une fois la modification enregistrée, c’est le service du SGBD qui va redémarrer, et donc faire varier la couleur de l’icône de WAMP.

Comme pour Apache qui utilise (entre autres) httpd.conf et PHP php.ini, vous pouvez accéder directement aux fichiers de configuration en mode texte depuis le menu de chaque partie de WAMP. Prenez cependant la précaution de vous renseigner sur quoi et comment changer la configuration de cette manière afin de ne pas "bloquer" votre serveur. 

Enfin, si vous modifiez à la main les configurations d’Apache ou de PHP, n’oubliez pas de redémarrer Apache au minimum en passant par l’icône de WAMP > Apache > Service > Redémarrer le service.

Un serveur est, pour continuer avec l’image du restaurant, une cuisine. Pour cuisiner, il faut des ingrédients, et ces ingrédients, il faut les stocker dans un garde-manger.
Avec un serveur, on va dire que les ingrédients sont vos pages HTML, vos scripts PHP, vos fichiers CSS et JavaScript.

Il faut néanmoins savoir où aller les chercher. Pour WAMP, on ne va évidemment pas parler de garde-manger, mais de racine serveur. C’est le dossier où sont rangés les scripts qui seront disponibles pour vos sites. Ce dossier, par défaut, est le dossier %WAMPDIR%\www¹. Pour ne pas trop charger, je ne parlerai que du « dossier www » par la suite. 

Le dossier www

Dans le dossier www, vous pouvez mettre tout ce dont vous avez besoin pour construire vos sites. Vous pourrez y accéder en utilisant l’adresse http://localhost/monFichier.php ou http://localhost/monAutreFichier.html.

Seulement, vous l’imaginez bien, cela fonctionne tant que vous n’avez pas beaucoup de sites à gérer. En effet, un site contient plusieurs pages, et ces pages demandent plusieurs fichiers (des images, les fichiers CSS, des scripts JavaScript, etc.). Si vous voulez créer un autre site, imaginez le nombre de fichiers que ça fera…
De plus, certains fichiers seront nommés de la même manière d’un site à l’autre, mais sans avoir le même contenu, et ça, ce n’est ni possible ni pratique. En toute logique, on va donc mettre tous les fichiers pour chaque site dans des dossiers séparés. Ce qui fait que, pour accéder à un fichier de l’un ou l’autre site, l’adresse deviendra http://localhost/monPremierSite/monFichier.php ou http://localhost/monSecondSite/monAutreFichier.html.

Outre le fait que les fichiers sont désormais organisés, vous aurez remarqué que si vous accédez à http://localhost/, vous verrez les dossiers listés dans la partie Vos projets. Vous pouvez donc accéder à vos sites en passant par http://localhost/, puis en cliquant sur l’un des noms de dossier.

Depuis WampServer 3.2.0, cela ne sert plus qu’à cela, la solution actuelle est mentionnée dans la section suivante sur les hôtes virtuels. Rassurez-vous, si elle est un peu plus compliquée à comprendre et à mettre en place, elle résout aussi bien d’autres cas. 

En attendant, vous pouvez toujours accéder à vos scripts en tapant l’entier de l’URL dans la barre d’adresse.

Oui, c’est connu avant WampServer 3.2.0. Notez cependant que ce n’est pas une page d’erreur 404 : c’est le navigateur qui ne trouve pas le serveur, ou, plus précisément, la résolution de l’hôte a échoué.

Oui une fois de plus !
Mais regardez un peu mieux dans la barre d’adresse quand vous êtes sur l’erreur.

Comme nous vous l’avons dit, pour accéder à un des sites sur lesquels vous travaillez, l’adresse doit être de type http://localhost/monPremierSite/monFichier.php. Or là, vous n’avez que http://monPremierSite/. Ce n’est pas la même chose, c’est donc normal que cela ne fonctionne pas ! Rassurez-vous, il n’y a pas besoin de changer grand chose pour que cela soit correct.

Parce que notre serveur est configuré pour afficher des pages "par défaut".

Vous avez déjà compris que dans http://localhost/monPremierSite/monFichier.php, on a monPremierSite qui est le nom du dossier de votre site, puis on a monfichier.php, qui est le nom du fichier dans ce dossier. Mais que se passe-t-il si vous ne donnez pas de nom de fichier ?

Dans ce cas, le serveur va chercher s’il y a un fichier index.html dans le dossier.

• S’il le trouve, il sera utilisé
• S’il n’y a pas de index.html, le serveur va chercher un fichier index.php
• S’il le trouve, il sera utilisé
• S’il ne trouve aucun de ces deux fichiers, vous recevrez une erreur HTTP 404, vous disant que le fichier n’a pas été trouvé.

Donc si on n’a pas de fichier spécifié dans l’adresse et qu’il n’y a pas d’erreur, c’est très probablement le contenu de index.php ou de index.html qui s’affiche. 
Le système peut être un peu plus complexe que ça, c’est surtout pour vous expliquer le principe.

Corriger les liens vers vos projets

Vous l’aurez peut-être remarqué si vous avez fait une mise à jour : les éléments listés sous « Vos projets » sur la page d’accueil de WAMP ne sont plus des liens sur lesquels on peut cliquer. Si vraiment vous ne pouvez pas vous passer de cela, il vous reste tout de même la possibilité de changer ce comportement.

Pour ça, il n’y a pas grand-chose à faire avec WAMP 3.0. En effectuant un clic droit sur l’icône dans la barre de statut, vous verrez un élément de menu Paramètres Wamp. Pointez dessus pour faire s’afficher une série de paramètres qui pourront s’activer et/ou se désactiver au gré de vos envies. L’élément qui nous intéresse ici est celui nommé Paramètres Wamp. Le dernier élément listé dans la nouvelle liste qui s’affiche, Ajouter localhost dans url, est celui qu’il nous faut : cliquez dessus. L’icône va passer à l’orange brièvement, puis redevenir verte. Rechargez maintenant la page d’accueil de WAMP, et cliquez sur un de vos projets. 

Depuis une version plus récente, l’option a été déplacée pour décourager son utilisation. Il faut aller dans Paramètres WAMP > Nettoyage automatique > Attention risqué ! Uniquement pour expert et là enfin se trouve l’option Autoriser liens sur les projets page d’accueil.

Pour WAMP 2.5 (avant 2.5.5)

Si WAMP 3.0 apporte quelques simplifications, il a bien fallu faire sans avant. Et donc, voici comment.

Dans le dossier www, il y a un des fichiers index.php dont nous avons parlé plus haut. C’est celui qui gère la page quand vous accédez à l’adresse http://localhost/, et c’est aussi dans ce fichier qu’est construite la liste des dossiers pour vos projets.
Seulement quelque part, il y a un petit détail qui fait que vous avez http://monPremierSite/ au lieu de http://localhost/monPremierSite/. Si l’on va regarder le code, on trouve ces lignes :

<?php
// récupération des projets
$handle=opendir(".");
$projectContents = '';
while (($file = readdir($handle))!==false)
{
    if (is_dir($file) && !in_array($file,$projectsListIgnore))
    {
        //[modif oto] Ajout éventuel de http:// pour éviter le niveau localhost dans les url
        $projectContents .= '<li><a href="'.($suppress_localhost ? 'http://' : '').$file.'">'.$file.'</a></li>';
    }
}
closedir($handle);
if (empty($projectContents))
    $projectContents = "<li>".$langues[$langue]['txtNoProjet']."</li>\n";;

La ligne mise en évidence contient un test pour déterminer s’il faut ajouter ou non le schéma d’URL (la partie http://). Par défaut, ce test ajoute le schéma, ce qui nous pose problème.

Si vous avez regardé la ligne attentivement, le test se base sur une variable $suppress_localhost, qui contient un booléen. Cette variable est définie plus haut dans le script, à la ligne 30.

<?php
$suppress_localhost = true;

Comme vous le constatez, la valeur de la variable ne vient pas d’un test complexe. Du coup, vous pouvez simplement remplacer true par false.
Rechargez ensuite http://localhost/ et cliquez sur l’un de vos projets listés. Vous pouvez désormais y accéder normalement.

Maintenant que vous savez comment organiser vos fichiers et comment y accéder, sachez cependant que la modification effectuée dans index.php n’est pas la meilleure des solutions. Cela fonctionnera pour de petits sites simples, mais dès que vous passerez à la vitesse supérieure ou que vous souhaiterez utiliser un framework, vous risquez d’avoir des problèmes.

Nous allons donc voir comment mieux organiser notre "garde-manger" par la suite.

Maintenant que vous avez créé des projets, vous souhaitez faire "plus professionnel" et pouvoir vous affranchir de la partie http://localhost/ qui apparaît dans l’adresse, et utiliser une URL comme http://mon-projet.localhost.
Ou alors, vous utilisez un framework, et vous vous rendez compte qu’il ne fonctionne pas très bien, http://localhost/ réapparaît dans les adresses générées.

Ceci est souvent dû à l’utilisation d’une variable de PHP qui donne différentes informations à propos du serveur : $_SERVER, dont vous pourrez trouver la documentation avec ce lien. Or, il se trouve que cette variable est un tableau où se trouve (entre autres) le nom de l’hôte virtuel ou l’adresse utilisée pour accéder à un script. Et sans changement de votre part, ces valeurs contiennent localhost pour tous vos projets. C’est afin de pallier cela qu’il est vivement recommandé d’utiliser les hôtes virtuels.

L’intérêt des hôtes virtuels

Les hôtes virtuels (connus en anglais sous le nom de virtual hosts ou, souvent vu à l’écrit, vhosts) vont nous permettre de lier un nom de domaine à l’un de nos projets contenus dans le répertoire www de WAMP. Ainsi, le projet http://localhost/monPremierSite pourra être accessible via l’URL http://premier-site.localhost, de même que le projet http://localhost/monSecondSite pourra être accessible via l’URL http://second-site.localhost.

L’intérêt des virtual hosts est double :

• raccourcir de manière significative l’URL d’accès à votre projet
• s’affranchir des URLs relatives et absolues qui vous poseront problème lors du déploiement du projet en production

Si nous reprenons notre garde-manger, vous n’allez pas simplement tout mettre dedans et devoir fouiller l’entier pour trouver ce dont vous avez besoin : vous allez avoir différentes armoires qui contiendront diverses choses afin de les retrouver plus facilement. Ici, c’est un peu différent : finalement, on ne va pas trier les ingrédients par types, mais par plats !
Un hôte virtuel permet donc de regrouper les fichiers par projet (comme le dossier créé dans www, cela reste nécessaire), mais en plus vous pourrez y accéder directement avec une adresse plus courte – comme si vous saviez dans quelle partie de votre garde-manger vous pourriez trouver tous les ingrédients nécessaires à un plat précis, même ceux qui sont communs à tous vos plats.

Oui, absolument n’importe quel nom de domaine, même si :

1. l’utilisation d’un nom de domaine existant ou "final" est déconseillée :
   • vous ne pourriez plus accéder au vrai contenu sans changer en permanence des paramètres ;
   • certains navigateurs remarquent que le nom de domaine pointe vers une adresse IP inhabituelle et vous demandent de confirmer l’accès.
2. certains noms de domaine forcent le HTTPS (notamment tous ceux en .dev avec les navigateurs actuels).

Pour illustrer le premier cas, imaginons que vous souhaitiez utiliser google.ch, par exemple. Après toutes les étapes suivies pour paramétrer cet hôte virtuel sur votre machine, vous ne pourriez plus accéder à sa version internet.
Allons dans le plus problématique : vous savez que vous allez publier votre projet au domaine final mon-projet.com. Développer en local avec le domaine mon-projet.com comme hôte virtuel risque de vous faire confondre production et développement quand vous testerez sur le serveur de production. Vous voyez le problème venir, non ? Sauf si vous êtes toujours exactement à votre affaire (et dans ce cas, nous vous tirons notre chapeau), vous risquez :

• de vérifier vos corrections en local sur la version de production, donc vous ne les verrez pas et ne comprendrez pas immédiatement pourquoi
• de vérifier si vos corrections ont bien été poussées en production alors que vous visionnez votre version locale. Vous les verrez, pas le client, et là non plus, vous ne comprendrez pas tout de suite la raison, et c’est un peu plus gênant quand le commanditaire est en train de s’énerver.

Donc évitez d’utiliser un nom de domaine existant ou "final"/"de production" quand vous développez. Cela vous aidera à vous y retrouver, vous évitera d’avoir à confirmer à chaque accès, et vous évitera des situations embarrassantes.

Quant au second cas, c’est plus gênant. Même si vous pouvez évidemment paramétrer votre WAMP pour qu’il puisse répondre à des requêtes HTTPS, les navigateurs vont vous faire remarquer que le certificat est auto-signé, et risquent d’afficher des messages à ce propos…

Voici de quoi vous aider. De même que vous pouvez choisir le nom de domaine, c’est à vous de choisir le TLD¹. Ici, afin d’éviter les soucis mentionnés plus haut, nous vous proposons ceci : nous utiliserons le TLD .localhost. Cela nous permettra de différencier vos projets en local de vos projets en production :

• mon-projet.fr en production
• mon-projet.localhost… en local

Ce TLD est expressément réservé pour une utilisation sur la même machine — ça tombe bien, c’est exactement notre cas —, et cette réservation a été effectuée par l’organisme qui gère les TLDs. Donc il n’y quasiment aucun risque de le voir disparaitre ou devenir gênant !

Notez au passage que vous n’avez pas besoin de nommer les URLs comme les dossiers de vos projets, ce serait plutôt l’inverse : pour mieux vous retrouver dans vos projets quand vous y accédez par l’explorateur Windows, vous aurez probablement utilisé le nom de domaine de votre projet comme nom de dossier.

Edition du fichier hosts de Windows

Sur Windows comme sur UNIX, il existe un fichier nommé hosts qui remplit plus ou moins le même rôle qu’un serveur DNS : il va préciser quelle adresse IP est associée à un nom de domaine. Ce fichier est consulté avant tout accès à un serveur DNS externe. C’est dans ce fichier que vous allez renseigner vos noms de domaines personnalisés.

Afin de pouvoir enregistrer les modifications, ouvrez votre éditeur de texte favori en mode Administrateur, soit avec le traditionnel clic droit > Exécuter en tant qu’administrateur. Si vos ne le faites pas, vous ne pourrez pas enregistrer les modifications (vous recevrez un message d’erreur, ou il vous sera demandé de vérifier si le fichier n’est pas utilisé), qui seront donc inutiles.

Maintenant que votre éditeur de texte est correctement lancé, utilisez le menu de celui-ci pour ouvrir le fichier hosts situé à l’emplacement C:\Windows\System32\drivers\etc.

Ajoutez les lignes suivantes en bas du fichier (une règle par ligne) :

127.0.0.1    premier-site.localhost
::1          premier-site.localhost

127.0.0.1    second-site.localhost
::1          second-site.localhost

Enregistrez et fermez.

Afin de s’assurer que Windows ait bien pris en compte les modifications qu’on vient d’ajouter au fichier hosts, ouvrez l’invite de commande et lancez ipconfig /flushdns. Si vous comprenez un peu l’anglais, vous devinerez que ceci va purger les définitions DNS que Windows a enregistrées. Du coup, le fichier hosts sera à nouveau lu, donc saura que les domaines premier-site.localhost et second-site.localhost se trouvent à l’adresse 127.0.0.1 (::1).

Dès lors, lorsque vous tenterez d’accéder à http://premier-site.localhost ce fichier indiquera qu’il faut s’adresser à la machine portant l’IPv4 127.0.0.1 (ou l’IPv6 correspondante ::1), qui n’est autre que votre WAMP.

127.0.0.1   localhost
::1         localhost

En fait, dès qu’on souhaite utiliser un sous-domaine, que ce soit www ou dev ou ce que vous voulez qui soit avant votre nom de domaine proprement dit (ici premier-site.localhost), il faut aussi le renseigner dans le fichier hosts. Mais on peut le faire très simplement, sans ajouter de ligne, en ajoutant juste le nouveau nom de domaine complet sur la même ligne. Reprenons l’exemple et adaptons-le pour le premier nom de domaine. Nous devrions avoir :

127.0.0.1    premier-site.localhost	www.premier-site.localhost
::1          premier-site.localhost	www.premier-site.localhost

Faites quand même attention au fait que vous ne pouvez mettre ainsi que jusqu’à 8 noms sur une même ligne, pas plus !

Définition des hôtes virtuels

Voilà la question que nous attendions !
Il y a justement un fichier de configuration Apache qui va permettre de router les bonnes URLs vers les bons répertoires. Ce fichier se trouve ici : %APACHEDIR%\conf\extra\httpd-vhosts.conf⁴. Éditez ce fichier, qui doit ressembler à cela :

#
# Virtual Hosts
#
# If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn't need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
#
# Please see the documentation at 
# <URL:http://httpd.apache.org/docs/2.2/vhosts/>
# for further details before you try to setup virtual hosts.
#
# You may use the command line option '-S' to verify your virtual host
# configuration.

#
# Use name-based virtual hosting.
#
NameVirtualHost *:80

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any <VirtualHost> block.
#
<VirtualHost *:80>
    ServerAdmin webmaster@dummy-host.example.com
    DocumentRoot "C:/Apache2/docs/dummy-host.example.com"
    ServerName dummy-host.example.com
    ServerAlias www.dummy-host.example.com
    ErrorLog "logs/dummy-host.example.com-error.log"
    CustomLog "logs/dummy-host.example.com-access.log" common
</VirtualHost>

<VirtualHost *:80>
    ServerAdmin webmaster@dummy-host2.example.com
    DocumentRoot "C:/Apache2/docs/dummy-host2.example.com"
    ServerName dummy-host2.example.com
    ErrorLog "logs/dummy-host2.example.com-error.log"
    CustomLog "logs/dummy-host2.example.com-access.log" common
</VirtualHost>

La partie haute du fichier est composée de commentaires (lignes précédées par des #), la partie basse contient deux définitions d’hôtes virtuels donnés à titres d’exemple. Chaque hôte virtuel est défini dans le bloc <VirtualHost *:80> … </VirtualHost>. Nous n’aurons pas besoin de ces exemples, vous pourrez donc les supprimer.

Pour que votre projet http://localhost/monPremierSite soit accessible à l’URL http://premier-site.local, créez le bloc de règles ci-dessous à la suite dans le fichier :

<VirtualHost *:80>
    ServerAdmin votreemail@exemple.com
    DocumentRoot "C:/wamp/www/monPremierSite"
    ServerName premier-site.localhost
    ServerAlias www.premier-site.localhost
    ErrorLog "logs/premier-site.localhost-error.log"
    CustomLog "logs/premier-site.localhost-access.log" common
</VirtualHost>

Une petite explication s’impose.

• nous avons créé une nouvelle règle, définie dans le bloc <VirtualHost *:80> … </VirtualHost>. Tout ce qui se trouve dans ce bloc ne concernera que l’hôte virtuel ainsi défini
• ServerAdmin indique l’adresse email de l’administrateur de l’hôte virtuel (vous, en l’occurrence !). Si un jour une erreur du serveur survient, le visiteur aura un message l’invitant à contacter cette adresse email ;
• DocumentRoot précise vers quel dossier doit pointer le nom de domaine défini à la ligne suivante, sans slash / ni antislash \ final
• ServerName indique le nom de domaine pour l’hôte virtuel, sans sous-domaine
• ServerAlias indique une URL alternative
  Ici, on permet la prise en compte des sous-domaines. Dans l’exemple, c’est le sous-domaine par défaut www qui est pris en compte
• ErrorLog indique le chemin vers le fichier journal où seront consignées toutes les erreurs PHP rencontrées par la suite
• CustomLog indique le chemin vers le fichier journal où seront consignés tous les accès HTTP

Faisons de même pour le second projet :

<VirtualHost *:80>
    ServerAdmin votreemail@exemple.com
    DocumentRoot "C:/wamp/www/monSecondSite"
    ServerName second-site.localhost
    ServerAlias www.second-site.localhost
    ErrorLog "logs/second-site.localhost-error.log"
    CustomLog "logs/second-site.localhost-access.log" common
</VirtualHost>

Enregistrez et fermez ce fichier.

Pour que vos virtual hosts soient fonctionnels, il ne reste plus qu’à indiquer à WAMP de prendre en compte ce fichier. Pour cela, éditez le fichier httpd.conf situé ici %APACHEDIR%\conf\httpd.conf.

Quelque part vers la fin du fichier (les numéros de ligne peuvent varier d’une version à l’autre de WAMP), vous trouverez ceci

# Virtual hosts
#Include conf/extra/httpd-vhosts.conf

Décommentez la ligne #Include conf/extra/httpd-vhosts.conf en enlevant le signe # du début de ligne, puis redémarrez WAMP.
Maintenant, si tout s’est bien passé, quand vous entrez l’adresse http://premier-site.localhost ou http://www.second-site.localhost, vous arrivez sur la page d’accueil des projets respectifs.

Conserver l’accès à http://localhost/ sur certaines versions de WAMP

Il y a un petit désavantage à créer ces hôtes virtuels : suivant votre version de WAMP, quand vous essayez d’accéder à http://localhost/, vous arrivez sur la page d’accueil de votre premier site !

En fait, c’est parce qu’Apache redirige toutes les requêtes qui arrivent sur la machine (et qui ne sont pas destinées à un hôte virtuel existant) vers le premier hôte virtuel accessible défini, et s’il n’y en a pas, vers la racine serveur (notre fameux dossier www). Or, il peut arriver que, pour des tests simples par exemple, vous ne souhaitiez pas les faire dans un hôte virtuel. localhost serait tout indiqué, mais vous n’y avez plus accès…

Vous voyez, vous avez compris tout seuls !

C’est exactement ce que l’on va faire : créer un hôte virtuel pour localhost. Afin qu’il soit vraiment l’hôte virtuel par défaut, il faut qu’il soit placé avant tous les autres dans le fichier httpd-vhosts.conf.
Notez qu’on peut aussi beaucoup simplifier sa déclaration, qui pourra se résumer à ceci :

<VirtualHost *:80>
	ServerName localhost
	ServerAlias localhost
	DocumentRoot "%WAMPDIR%/www"
	<Directory "%WAMPDIR%/www/">
		Options +Indexes +Includes +FollowSymLinks +MultiViews
		AllowOverride All
		Require local
	</Directory>
</VirtualHost>

Les frameworks actuels font volontiers usage de la ligne de commandes pour lancer des scripts PHP. Seulement, WAMP ne fait pas de réglage à ce niveau, car il est initialement prévu pour une utilisation avec Apache. Il nous faut donc pallier cela.

Rendez-vous d’abord dans le panneau de configuration, puis la rubrique Système (sous Windows 7 et plus récent, vous pouvez utiliser le raccourci + Pause). Dans la partie de gauche de la fenêtre, vous trouverez une rubrique Paramètres système avancés, pour laquelle Windows vous demandera d’être administrateur pour y accéder.

S’ouvre alors une fenêtre avec une série d’onglets. Si ce n’est pas celui qui est déjà choisi, cliquez sur Paramètres système avancés une fois de plus. Dans cet onglet, en bas à droite, se trouve un bouton Variables d’environnement. Cliquez dessus pour ouvrir encore une nouvelle fenêtre.

Cette dernière est séparée en deux parties : les variables pour l’utilisateur en haut, et les variables système, partagées entre tous les utilisateurs, en dessous. C’est parmi celles-ci qu’il vous faut trouver Path et la sélectionner. Une fois ceci fait, cliquez sur Modifier…. Encore une popup qui s’ouvre — ce n’est pas pour rien que le système d’exploitation s’appelle Windows. 

A partir de là, la suite dépend de votre version de Windows et surtout de ce que contient cette nouvelle fenêtre.

• La fenêtre comporte une série de lignes à gauche, et des boutons à droite

  Celui qui nous intéresse, c’est Nouveau. Après avoir cliqué dessus, le curseur va se placer en bas de liste a gauche, et vous n’aurez qu’à coller le chemin vers l’emplacement de PHP, soit %WAMPDIR%\bin\php\php%PHP_VERSION%\^{1, 2}

• La fenêtre comporte deux champs texte l’un sous l’autre

  On va surtout s’intéresser à celui du bas.

  Il ne faut pas changer quoi que ce soit dans le premier champ, sans quoi vous risquez de devoir utiliser un DVD d’installation de votre système d’exploitation pour le réparer, et certains programmes pourraient ne plus fonctionner correctement malgré cela.

  On peut voir que ce qu’il contient est une série de chemins, séparés entre eux par des points-virgules ;. Ce sont en fait des chemins de dossiers dans lesquels Windows vérifie, quand lui ou un programme doit lancer une commande, que les composants nécessaires s’y trouvent. Et nous, tout ce qu’il nous faut, c’est d’y ajouter le chemin vers l’exécutable de PHP.

  Pour ce faire, il suffit de :

  • ajouter un point-virgule tout à la fin de la liste ;
  • coller à sa suite le chemin vers le dossier où se trouve PHP, soit %WAMPDIR%\bin\php\php%PHP_VERSION%\^{3, 4}

  N’ajoutez aucune espace avant ni après le point-virgule

Ensuite de quoi, fermez progressivement les diverses fenêtres en cliquant sur Appliquer quand c’est possible, sinon sur OK.

Vous devriez pouvoir utiliser PHP en ligne de commandes désormais. Ouvrez l’invite de commandes et tapez php -v : le numéro de la version de PHP devrait s’afficher alors.

cURL et HTTPS

Si vous avez besoin de PHP en ligne de commandes, c’est probablement parce que vous allez utiliser composer. Vous avez peut-être déjà tenté de lancer une commande, et vous vous retrouvez avec le message suivant.

cURL error 60: SSL certificate problem: unable to get local issuer certificate

En fait, le problème est que cURL tente de se connecter quelque part en HTTPS, mais qu’il n’arrive pas à vérifier l’authenticité du certificat pour la connexion sécurisée. Pour que cela lui soit possible, il faut lui fournir une base de données qui lui permettra de faire la validation.
Dans un premier temps, il faut télécharger cette base de données, qui se présente sous la forme d’un seul fichier. Vous pouvez le récupérer à l’adresse https://curl.haxx.se/ca/cacert.pem. Enregistrez-le quelque part où vous ne risquez pas de l’effacer, nous vous proposons de créer un dossier %WAMPDIR%\ssl⁶ pour cela.

Ensuite, ouvrez le fichier php.ini avec votre éditeur de texte favori, et recherchez les lignes mentionnées ci-dessous.

[curl]
; A default value for the CURLOPT_CAINFO option. This is required to be an
; absolute path.
;curl.cainfo =

Dé-commentez la dernière ligne, et ajoutez à la fin de celle-ci le chemin du fichier que vous avez téléchargé. C’est prêt !

Quand on a un serveur de développement, on souhaite parfois pouvoir utiliser celui-ci comme un hébergeur, au moins pour les petits projets, avant de les rendre publics. WAMP permet plus ou moins de jouer ce rôle, mais cela demande quelques paramètres suivant ce que vous souhaitez rendre accessible.

S’ouvrir au monde

Quand vous lancez WAMP pour la première fois, il est prévu pour ne laisser accéder que les demandes émanant de votre machine. Toute personne qui tenterait depuis un client quelconque d’accéder à l’un des sites qui se trouvent sur votre ordinateur recevrait une erreur 403.

Initialement, pour permettre à d’autres machines d’accéder à vos sites, il y avait un élément de menu qui permettait de dire Passer en ligne ou, à l’inverse, Passer hors ligne. Cette option est masquée par défaut avec les versions de WAMP 3.1. Qui plus est, si vous avez créé des hôtes virtuels, cette commande ne changera rien pour ceux-ci. Du coup, il faudra aller modifier quelques lignes de configuration armé de votre éditeur de texte favori.

Rendez-vous dans le fichier qui contient les configurations de vos hôtes virtuels, soit %WAMPDIR%\bin\apache\apache%APACHE_VERSION%\conf\extra\httpd-vhosts.conf^{1, 2}. Pour l’hôte virtuel que vous souhaitez rendre accessible, recherchez la ligne Require local, et remplacez par Require all granted. Redémarrez ensuite Apache. Si ça redevient vert, cette première étape est terminée ! 

Rediriger les gens chez vous

Pour l’instant, vous avez ouvert la porte sur votre ordinateur. Il faut encore renseigner les autres ordinateurs de l’endroit où elle est.

Accessibilité sur le LAN⁵

Sur Internet, pour pouvoir afficher un site, il y a plusieurs requêtes qui sont effectuées, afin de connaître l’adresse IP de la machine où le site est hébergé. Cela implique le passage par des DNS. En conséquence, si vous souhaitez accéder à votre serveur depuis une autre machine, il vous faut soit un serveur DNS, soit utiliser directement l’adresse IP de votre machine.
Vous pouvez éventuellement faire une recherche « quelle est mon adresse IP » et utiliser celle qui vous est donnée. Mais faire ainsi va passer par le WAN⁶, alors que vous vous trouvez sur le même LAN. Vous n’avez pas besoin de passer par une machine qui peut se trouver ailleurs sur le continent pour trouver un appareil qui se trouve à maximum 20 mètres de vous, n’est-ce pas ?

Une solution serait d’utiliser l’adresse IP locale de la machine qui fait office de serveur. Mais on se retrouverait avec un problème similaire à celui qui nous empêchait d’accéder à localhost dans la partie des hôtes virtuels : cette méthode ne permet d’accéder qu’au premier vhost défini sur le serveur. Notons au passage que le problème surviendrait avec l’IP publique aussi.
Une autre solution (probablement la plus pratique) serait d’avoir un serveur DNS installé sur votre routeur/box Internet. Certains modèles le proposent, à vous de vous renseigner à ce sujet.
Maintenant, si vous avez encore en tête la solution que nous avions mise en place pour nos hôtes virtuels, vous avez déjà compris que nous allons utiliser le fichier hosts des clients de votre LAN, ce fichier qui fait office de DNS "prioritaire".

Pour ce faire, il nous faut dans un premier temps l’adresse locale du serveur. Ouvrez l’invite de commandes et lancez ipconfig. Vous aurez des informations sur les cartes réseau existantes sur votre machine, et notamment (pour celle qui sert à la connexion) deux lignes nommées Adresse IPv6 et Adresse IPv4, comme dans l’exemple ci-dessous :

Carte Ethernet Connexion au réseau local :

   Suffixe DNS propre à la connexion. . . : ethernet
   Adresse IPv6. . . . . . . . . . . . . .: fd00::f856:66de:b181:c036
   Adresse IPv6 temporaire . . . . . . . .: fd00::24ed:1051:ea57:7bce
   Adresse IPv6 de liaison locale. . . . .: fe80::f855:66de:b181:c036%15
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.0.2
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Passerelle par défaut. . . . . . . . . : 192.168.0.1

Carte réseau sans fil Connexion au réseau sans fil :

   Statut du média. . . . . . . . . . . . : Média déconnecté
   Suffixe DNS propre à la connexion. . . : wifi

Ce sont les deux adresses à utiliser dans le fichier hosts, avec les noms de domaine que vous utilisez sur celle-ci. Pour faire court, en reprenant les divers exemples utilisés dans ce tutoriel, vous pourrez ajouter ces lignes dans les fichiers hosts des clients :

192.168.0.2               premier-site.local
fd00::f856:66de:b181:c036 premier-site.local

192.168.0.2               second-site.local
fd00::f856:66de:b181:c036 second-site.local

Si vous avez bien suivi, vous pourrez avec ça utiliser l’adresse http://premier-site.local sur un client et cela affichera bien le site demandé.

Laisser accéder à phpMyAdmin

Par défaut, phpMyAdmin n’accepte pas non plus les connexions depuis l’extérieur. Mais il ne suffit pas de passer en ligne pour régler cela : il y a une consigne à changer dans la définition de l’alias pour phpMyAdmin.

Alias /phpmyadmin "%WAMPDIR%/apps/phpmyadmin%PMA_VERSION%/"

# to give access to phpmyadmin from outside 
# replace the lines
#
# Require local
#
# by
#
# Require all granted
#

<Directory "%WAMPDIR%/apps/phpmyadmin%PMA_VERSION%/">
   Options Indexes FollowSymLinks MultiViews
   AllowOverride all
  <IfDefine APACHE24>
    Require local
  </IfDefine>
  <IfDefine !APACHE24>
    Order Deny,Allow
    Deny from all
    Allow from localhost ::1 127.0.0.1
  </IfDefine>
  php_admin_value upload_max_filesize 128M
  php_admin_value post_max_size 128M
  php_admin_value max_execution_time 360
  php_admin_value max_input_time 360
</Directory>

Les quatre lignes mises en évidence sont des réglages qui font en sorte que l’on ne peut accéder à phpMyAdmin qu’en étant sur la même machine. Si, pour la première, le changement à effectuer est expliqué plus haut (aux lignes 3 à 11), les trois suivantes sont moins simples à appréhender. En fait, je vous propose d’adapter un petit peu le contenu du fichier pour y faire figurer ceci :

Alias /phpmyadmin "%WAMPDIR%/apps/phpmyadmin%PMA_VERSION%/"

#    to give access to phpmyadmin from outside 
#    replace the lines
#
# Require local
#
#    and
#
# Order Deny,Allow
# Deny from all
# Allow from localhost ::1 127.0.0.1
#
#    by respectively
#
# Require all granted
#
#    and
#
# Order Allow,Deny
# Allow from all
#

<Directory "%WAMPDIR%/apps/phpmyadmin%PMA_VERSION%/">
   Options Indexes FollowSymLinks MultiViews
   AllowOverride all
  <IfDefine APACHE24>
    Require local
  </IfDefine>
  <IfDefine !APACHE24>
    Order Deny,Allow
    Deny from all
    Allow from localhost ::1 127.0.0.1
  </IfDefine>
  php_admin_value upload_max_filesize 128M
  php_admin_value post_max_size 128M
  php_admin_value max_execution_time 360
  php_admin_value max_input_time 360
</Directory>

Et du coup, vous avez toutes les informations nécessaires pour passer en ligne ou restreindre à nouveau l’accès !

Accessibilité depuis n’importe-où

Maintenant que vous avez terminé le site, vous souhaitez que celui pour qui vous l’avez fait puisse y accéder depuis chez lui. On se trouve avec un problème similaire que pour le réseau local, mais il faudra utiliser l’adresse IP globale dans le fichier hosts de la machine client. Seulement, il y a en plus le fait que votre box ne va pas nécessairement savoir où est votre serveur. Nous vous expliquons pourquoi.

En local, vous aviez utilisé l’adresse IP locale de votre serveur. Votre boîtier la connaissait, et pouvait ainsi router les requêtes correctement. Mais ces adresses IP locales sont, comme leur dénomination l’indique, locales, donc connues dans le LAN seulement. Votre LAN est connecté au WAN par votre routeur, et c’est lui qui est votre porte vers Internet, c’est lui qui possède l’adresse IP publique. Si vous voulez le vérifier, vous pourrez voir que tous les appareils connectés à Internet ont la même adresse IP publique. Le souci est le suivant : comment faire pour que votre partenaire puisse accéder à votre serveur précisément, un des éléments de votre LAN, en n’ayant que votre adresse IP publique ?

Si vous n’avez qu’un seul serveur, vous pouvez probablement rediriger le port utilisé pour HTTP vers votre machine d’hébergement (on parle de routage NAT, ou de redirection de port). Ainsi, toutes les requêtes HTTP qui arriveront de l’extérieur arriveront à la bonne machine.
Mais si vous avez plusieurs machines qui servent d’hébergement, on revient au besoin d’un DNS.

Vous pouvez regarder les réglages de votre boîtier pour le configurer afin qu’il assigne une adresse IP locale fixe à votre serveur. Mais là encore, selon le routeur et la version du firmware, vous pourrez peut-être assigner une adresse IP

• à une adresse MAC, ce qui vous obligera à vous connecter par WiFi ou par câble, donc ne vous permettra pas de jongler entre les deux
• à un nom de machine, qui vous assignera la même adresse IP quelle que soit votre moyen de connexion

Quelques obstacles possibles

Il y a quelque chose dont il vous faudra aussi tenir compte : les pare-feux de votre serveur et de votre routeur, ainsi que les antivirus. De manière simple pour voir si l’un ou l’autre pose problème sur le serveur, désactivez le pare-feu et l’antivirus, testez si Apache est accessible, puis testez avec seulement le pare-feu et seulement l’antivirus. Vous vous rendrez compte très rapidement de ce qui pose problème.
Pour l’éventuel pare-feu de votre boîtier, il vous faudra aller regarder dans sa configuration ou son manuel.

Sous Windows, quand vous avez installé WAMP, votre pare-feu vous a probablement demandé si vous souhaitiez laisser l’accès à Apache sur le réseau local/d’entreprise et/ou sur le réseau public. Référez-vous à la documentation de votre pare-feu pour permettre à Apache (httpd.exe) de discuter avec le monde extérieur.

Parfois, les antivirus n’aiment pas non-plus les programmes qui peuvent se connecter à Internet. Vérifiez dans votre antivirus qu’Apache (httpd.exe) n’est pas bloqué d’une quelconque manière. Vous pourrez probablement ajouter une exception.

Ce sont là toutes les pistes que nous pouvons vous transmettre afin d’ouvrir votre serveur aux accès distants. Faites bien attention aux différents points de sécurité mentionnés, rien n’est anodin.