Licence CC BY-NC-SA

Dans la vie de tous les jours…

Dernière mise à jour :

Maintenant que nous avons installé l’environnement, nous allons voir comment l’utiliser, parce que, comme pour tout, il n’est pas vraiment possible de faire n’importe quoi et que ça fonctionne ! :pirate:

Paramétrer les composants

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.  :D
En effet, l’un des modules permet l’utilisation de PHP 5 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.

Si ces deux dénominations sont utilisées, c’est parce que mod_rewrite est le nom de fichier qui contient le module, et rewrite_module est le nom utilisé en interne pour désigner le module1.

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 (✓)
    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 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 petit 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.

Vous pouvez faire défiler la liste avec les triangles ▲ et ▼ afin de trouver rewrite_module et vérifier son état. 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.

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, ce qui pose donc problème quand on génère un fichier XML avec PHP quand cette option est 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.

Pourquoi est-ce que changer quelque chose pour PHP demande de redémarrer Apache ?

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 MySQL

De manière similaire, vous pouvez accéder à certains paramètres de MySQL 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 MySQL 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.


  1. Plus d’informations à propos de cet identificateur dans la documentation officielle 

Organiser vos projets

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%\www1. 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.

Euh, non ! Quand je clique dessus, je reçois un message d’erreur comme quoi la page ne peut être trouvée !

Oui, c’est connu. 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é.

Hé, ho, on vient de l’installer, le serveur ! Il fonctionne, sinon on ne pourrait pas accéder à http://localhost/, non ?

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. ;)

Tu nous as dit qu’on devait accéder à nos fichier avec des adresses ressemblant à http://localhost/monPremierSite/monFichier.php, mais pour http://localhost/, on n’a pas de nom de fichier. Pourquoi est-ce que quelque chose s’affiche alors ?

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.php dans le dossier.

  • S’il le trouve, il sera utilisé
  • S’il n’y a pas de index.php, le serveur va chercher un fichier index.html
  • 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 est un peu plus complexe que ça, c’est surtout pour vous expliquer le principe.

Corriger les liens vers vos projets

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.  ^^

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 :

329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
<?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";;
Extrait du script index.php fourni avec WAMP 2.5.0. Cette partie montre comment est générée la liste des projets

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.

29
30
<?php
$suppress_localhost = true;
Initialisation de la variable $suppress_localhost dans index.php fourni avec WAMP 2.5

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. :magicien:

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. ^^


  1. %WAMPDIR% est à remplacer par le chemin d’installation de WAMP 

Les <VirtualHost>

Maintenant que vous avez créé des projets, vous souhaitez faire "plus professionnel" et pouvoir vous affranchir de la partie localhost qui apparaît dans l’adresse, et utiliser une URL comme http://mon-projet.local.
Ou alors, vous utilisez un framework, et vous vous rendez compte qu’il ne fonctionne pas très bien, 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.local, de même que le projet http://localhost/monSecondSite pourra être accessible via l’URL http://second-site.local.

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 ! :D
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. ;)

Puis-je utiliser n’importe quel nom de domaine ?

Oui, absolument n’importe quel nom de domaine, même si 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.

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. :p

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. ^^

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

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

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

Le fichier hosts est un fichier caché du système. Pour pouvoir le trouver, il vous faut donc afficher ces fichiers.
Rendez-vous dans le Panneau de Configuration, rubrique Option des dossiers. Dans la fenêtre qui s’ouvre alors, cliquez sur l’onglet Affichage, et cochez le bouton radio Afficher les dossiers les fichiers, dossiers et lecteurs cachés, puis cliquez sur Appliquer.
Vous pourrez recocher Ne pas afficher les fichiers, dossiers ou lecteurs cachés une fois les modifications effectuées.

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) :

1
2
3
4
5
127.0.0.1   premier-site.local
::1         premier-site.local

127.0.0.1   second-site.local
::1         second-site.local

Code:Lignes à ajouter dans le fichier hosts

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.local et second-site.local se trouvent à l’adresse 127.0.0.1 (::1). ;)

Dès lors, lorsque vous tenterez d’accéder à http://premier-site.local 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.

Vous pourrez trouver sur différents sites qu’il faut ajouter ou décommenter les lignes

1
2
127.0.0.1 localhost
::1       localhost

Code:Indique que localhost correspond aux adresses IPv4 127.0.0.1 et IPv6 ::1

Ceci n’est plus du tout nécessaire dès Windows 72, 3, mais reste donc à faire pour Windows Vista ou moins récent.

Si vous souhaitez rendre votre site accessible avec les deux adresses http://www.premier-site.local et http://premier-site.local, il faut aussi renseigner ces noms dans le fichier hosts.

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.local), 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 :

1
2
127.0.0.1   premier-site.local  www.premier-site.local
::1         premier-site.local  www.premier-site.local

Code:Ajout de la gestion DNS du sous-domaine www pour premier-site.local

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

Un instant… mes deux URLs personnalisées pointent toutes deux vers la même IP. Comment pourrais-je accéder au bon projet ?

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.conf4. Éditez ce fichier, qui doit ressembler à cela :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#
# 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>
Contenu initial du fichier %APACHEDIR%\conf\extra\httpd-vhosts.conf5

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 :

1
2
3
4
5
6
7
8
<VirtualHost *:80>
    ServerAdmin votreemail@exemple.com
    DocumentRoot "C:/wamp/www/monPremierSite"
    ServerName premier-site.local
    ServerAlias www.premier-site.local
    ErrorLog "logs/premier-site.local-error.log"
    CustomLog "logs/premier-site.local-access.log" common
</VirtualHost>
Définition d’hôte virtuel liant le nom de domaine premier-site.local au dossier C:\wamp\www\monPremierSite\

C’est fait… mais je n’ai rien compris ! :(

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 :

1
2
3
4
5
6
7
8
<VirtualHost *:80>
    ServerAdmin votreemail@exemple.com
    DocumentRoot "C:/wamp/www/monSecondSite"
    ServerName second-site.local
    ServerAlias www.second-site.local
    ErrorLog "logs/second-site.local-error.log"
    CustomLog "logs/second-site.local-access.log" common
</VirtualHost>
Définition d’hôte virtuel liant le nom de domaine second-site.local au dossier C:\wamp\www\monSecondSite\

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

512
513
# Virtual hosts
#Include conf/extra/httpd-vhosts.conf
Inclusion de la configuration relative aux hôtes virtuels dans httpd.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.local ou http://www.second-site.local, vous arrivez sur la page d’accueil des projets respectifs.

Conserver l’accès à http://localhost/

Il y a un petit désavantage à créer ces hôtes virtuels : 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 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…

Hé ! Vous venez de nous dire que les requêtes qui arrivent sur la machine aboutissent par défaut dans le premier hôte virtuel. Pourquoi ne pas créer un hôte virtuel pour localhost, alors ?

Vous voyez, vous avez compris tout seuls ! :p

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 :

1
2
3
4
<VirtualHost *:80>
    DocumentRoot "%WAMPDIR%\www"
    ServerName localhost
</VirtualHost>
Définition de l’hôte virtuel pour localhost. Remplacez %WAMPDIR% par le chemin de votre installation de WAMP

  1. Ce sont les quelques dernières lettres entre le dernier point et le slash suivant dans une URL, comme .com, .fr ou .中国. Plus d’informations sur la page Wikipédia consacrée 

  2. http://support.microsoft.com/kb/972034/fr#LetMeFixItMyselfAlways, partie "Windows 7 et versions antérieurs de Windows", 3e exemple de code, dernières lignes (dernier accès le 24 août 2014) 

  3. http://answers.microsoft.com/en-us/windows/forum/windows_8-networking/how-can-i-reset-ms-host-files-in-windows-8/4057335b-6160-4073-aafb-4412db9db971, réponse d’Anshul Khanna du 31 décembre 2012, partie "Méthode 2", point 7, deux dernières lignes de contenu mentionnées (dernier accès le 24 août 2014) 

  4. %APACHEDIR% est à remplacer par le chemin de l’installation d’Apache 

  5. Idem 


Voilà, vous avez toutes les bases pour vous amuser avec WAMP en amateur.  :D

Néanmoins, il y a d’autres possibilités intéressantes qui risquent de vous plaire si vous êtes ou vous destinez à entrer dans le milieu du développement web.