WampServer
Apache, PHP, MySQL
on Windows
Aller à : Liste des Forums•Liste des messages•Nouvelle discussion•Recherche•Connexion•Imprimer la vue
Le BESOIN DE VIRTUALHOST
Envoyé par:
Otomatic
(Modérateur)
Date: 29 May 2014 à 17:03
Bonjour,
LE BESOIN DE VirtualHost (Page d'accueil - Menu Vos projets)
Nota : L'utilisation des VirtualHost est (presque) obligatoire avec Apache si vous voulez travailler correctement avec les applications WEB, les CMS ou vos sites locaux.
Il est recommandé - et même impératif - de créer un hôte virtuel pour chacun de vos projets, même si vous les mettez dans la structure \wamp\www\sous-dossier.
La page d'accueil de WampServer (\wamp\www\index.php) nécessite que vous ayez créé un hôte virtuel pour chacun de vos projets et ne fonctionnera correctement que si vous le faites.
Historique Wampserver
Dans la préhistoire de Wampserver, il était demandé de créer des sous-dossiers pour chacun des projets sous le dossier \wamp\www\
Acceptable uniquement pour des tutoriels simples
Cette « facilité » pour le débutant était parfaitement acceptable - par exemple pour ceux qui suivent des tutoriels pour apprendre uniquement le codage PHP - mais n'a jamais été destinée à être utilisé pour l'élaboration d'un site Web local ou transférable plus tard chez un hébergeur.
En fait, utilisé comme ça, ce mécanisme a causé beaucoup de problèmes dans la configuration des sites réels qui ne correspondaient plus à la configuration du site en développement.
Remarque : Dans les explications suivantes tous les (http://) sont entre parenthèses ceci pour éviter que ce soit transformé en url par le forum.
Lancer ses sites locaux par (http://localhost/projet1/) ou (http://localhost/projet2/) n'est ABSOLUMENT PAS une bonne solution, c'est même quelque chose à bannir totalement.
En effet, vous introduisez un niveau supplémentaire "localhost/" dans les url d'accès à vos sites locaux ce qui fait que beaucoup de variables prédéfinies par le serveur HTTP, par exemple des éléments du tableau $_SERVER['xxx'] n'auront pas les bonnes valeurs.
Par exemple, pour un projet wamp/www/mon-projet/
Avec l'appel tel qu'il devrait être : (http://mon-projet/) voici les valeurs de quelques éléments prédéfinis
Ces valeurs erronées vont - à coup sûr - induire des erreurs incompréhensibles avec des Frameworks, des CMS ou des applications web que vous ajouterez à vos projets, par exemple Wordpress ou Joomla ; mais ce ne sont pas les seules.
Vos « projets » sont hébergés chez "localhost" tout comme les sites « réels » sont hébergés chez "ovh", "free", "1and1", "gandi" ou autres et, pour accéder à ces sites réels , vous ne tapez pas (http://gandi/wampserver.com) mais bien (http://wampserver.com)
Il faut donc définir quelles sont les caractéristiques et la localisation de vos projets par rapport à leurs hébergement chez "localhost".
Sans définition de VirtualHost, (http://localhost/mon-projet/) fonctionne parce que ce nom "localhost" est défini en tant nom de site par défaut et qu'une adresse d'accès lui est donnée et que le dossier /mon-projet/ est considéré comme un « niveau » secondaire du site localhost. Ceci est effectué par le fichier "C:\Windows\System32\drivers\etc\hosts" (sans extension) qui donne les correspondances entre les adresses IP et les noms de site. Après installation du serveur, ce fichier doit contenir, comme lignes actives (C'est-à-dire sans # au début de ligne), au moins :
Comment créer des VirtualHost avec Wampserver
Il faut toujours créer un VirtualHost AVANT d'installer une application Web ou un CMS (Joomla, Wordpress, Prestashop, Moodle, etc.)
-------------------------------------------------------------
------ Wampserver 3 - Création (ou ajout) de VirtualHost ------
Bien que cela ne vous empèche pas de lire tout ce qui suit (Et c'est même recommandé), avec Wampserver 3, la création ou l'ajout de VirtualHost ou l'ajout peut se résumer en quelques clics. Il est même recommandé d'utiliser les outils internes à Wampserver pour créer ou ajouter un VirtualHost : Voir : Wampserver 3 - Création de VirtualHost
-------------------------------------------------------------
Voir en note 3 les prérequis au sujet de l'éditeur de texte à utiliser
En fait, cela doit fonctionner exactement de la même manière que pour tout serveur Apache d'un hébergeur, avec quelques petites différences quant aux autorisations d'accès.
Il est indispensable de lire tout ce qui suit pour bien comprendre le mécanisme des VirtualHost
C'est le fichier appelé `httpd-vhosts.conf` qui contient les VirtualHost pour Apache
Nota : Chaque VirtualHost a sa propre définition de DocumentRoot
Petit « à côté » N°1
-- Comment les hôtes virtuels travaillent dans Apache :
La première définition de ce fichier sera également le site par défaut, de sorte que si le nom de domaine utilisé dans le navigateur ne correspond à aucun domaine défini, c'est localhost, le premier domaine dans le fichier, qui sera servi par exemple par une tentative de hack sur votre adresse IP.
Donc, nous nous assurons que la sécurité Apache pour le domaine localhost ** A TOUJOURS POUR VALEUR **
Petit « à côté » N°2
-- Pour les scripts CGI
Si vous utilisez des scripts CGI, par exemple dans certains cas pour Perl, il faut en ajouter le support dans la ligne Options, par exemple :
L'ajout d'un VirtualHost nécessite d'ajouter votre nouveau nom de domaine dans le fichier HOSTS.
`C:\windows\system32\drivers\etc\hosts`
Le fichier n'a pas d'extension et doit absolument rester sans extension. Méfiez-vous du bloc-notes (Notepad), car il peut essayer d'ajouter une extension `.txt` si vous n'avez pas de meilleure éditeur. Je vous suggère de télécharger Notepad++, c'est gratuit et un très bon éditeur.
Si vous n'arrivez pas à ouvrir le fichier hosts, voir la Note 2 de CONSEILS DE DÉPANNAGE
C'est aussi un fichier protégé que vous devez modifier avec des privilèges d'administrateur, il faut donc lancer l'éditeur avec l'option « Exécuter en tant qu'administrateur » Explications Exécuter en tant qu'administrateur
Après édition et ajout du domaine projet1, le contenu du fichier devrait ressembler à ça :
Notez que vous devez avoir les définitions pour l'adresse `127.0.0.1` de bouclage IPv4 et aussi l'adresse `::1` de bouclage IPv6. Apache supporte IPv6 depuis la version 2.2.19 et le navigateur va utiliser IPv4 ou IPv6, ou les deux. Je n'ai aucune idée de comment il décide quel type utiliser, mais il peut utiliser IPv6 et, si l'adresse locale IPv6 n'est pas définie, il peut y avoir des problèmes.
Maintenant, nous devons indiquer à Windows de rafraîchir le cache des noms de domaine (Sinon, il faudra redémarrer).
Ouvrir une fenêtre de commande en tant qu'Administrateur Explications Lancer en tant qu'administrateur et tapez la commande ci-dessous :
NOTE : Nom de Domaine. C'est une très mauvaise idée que de définir un ServerName ou ServerAlias qui soit le même que votre nom de domaine (*) réel. En effet, lorsque l'on demande une url dans le navigateur, ce sont d'abord les DNS locaux (fichier hosts, puis cache local) qui sont lus et si une correspondance est trouvée, c'est le site local qui sera chargé ; il sera donc impossible d'accéder au site réel.
Une bonne pratique, est de donner le même nom mais sans le tld, donc, par exemple, monsite.net en réel et monsite en local.
Le site local exemple.test est accessible à partir du réseau local dans les définitions de serveur virtuel (Require ip 192.168.0, si c'est la plage d'ip du réseau), ce changement ne s'appliquera qu'à ce site et à aucun autre. SEULEMENT ce site local sera accessible depuis le réseau puisque tous les autres, localhost compris, sont avec Require local.
Il y a aussi quelques modifications de la configuration de PHP, qui ne s'appliqueront QUE pour ce site local. Ce peut être très utile pour un site ayant besoin d'exigences spécifiques, contrairement à tous les autres sites que vous gérez.
Éventuellement, on pourrait penser que ce site est mal écrit et que seulement pour celui-ci, nous masquons les erreurs. Il existe des sites comme cela et les gens veulent toujours à les maintenir mal. Mais cela montre que nous pouvons avoir tout un tas de paramètres spécifiques qui ne s'appliquent qu'à un site local et non pas globalement à tous les sites virtuels s'exécutant sur WampServer.
(*) ServerName est un nom de domaine, même en local et doit respecter des règles. Un nom de domaine doit comporter entre 2 et 63 caractères. Les caractères autorisés sont les lettres, les chiffres et le signe "-". Le signe "-" est autorisé n'importe où sauf en première ou en dernière position.
Les accents (àâäéèêëôöùûüîï) et les lettres infléchies (ç) sont autorisés uniquement pour les noms de domaine avec l'extension .com, .net, .fr et eu. et, comme c'est relativement récent, le problème est que tous les serveurs, hébergeurs, et navigateurs ne les prennent pas en compte.
Mais, dans TOUS LES CAS, le tiret-bas (underscore) n'est pas autorisé dans les noms de domaine. Pour plus d'informations (Mais c'est assez rébarbatif), voir la Internationalized Domain Names in Applications, RFC 5890 et aussi la RFC 1034.
====== Note 3 - Éditeur de texte ======
*Prérequis important au sujet de l'éditeur de texte utilisé : Pour modifier les fichiers, vous devez utiliser un éditeur de texte, mais pas n'importe lequel. En effet, certains éditeurs de texte, le Bloc-Notes (notepad.exe) de Windows par exemple, ne sont pas capables de visualiser correctement des fichiers comportant de retours à la ligne de type Unix*, d'autres recodent subrepticement ces retours à la ligne de type Unix en type Windows/DOS, d'autres encore changent le jeux de caractère utilisé ou ajoutent des entêtes ; Or, il est impératifs que les types de fin de ligne ou les jeux de caractères des fichiers de Wampserver ne soient pas altérés, sinon cela génèrera des impossibilités et des erreurs lors de son utilisation. C'est pourquoi je recommande fortement d'utiliser un éditeur de texte gratuit, performant et en français comme Notepad++ que vous trouverez à Notepad++ (Si vous utilisez un éditeur de texte comme UtraEdit, ça ne posera aucun problème).
* Les caractères indiquant les fins de lignes sont de trois types :
- Windows/DOS : CR - LF (Carriage Return - Line Feed) Deux octets 0x0D et 0x0A
- Unix : LF (Line Feed) Un octet 0x0A
- Mac : CR (Carriage Return) Un octet : 0x0D
==============================================================
Cette contribution est une compilation des informations de RiggsFolly du forum Anglais et d'Otomatic du forum Français
Modifie 40 fois. Derniere modification le 09/03/2020 à 18:38 par Otomatic.
LE BESOIN DE VirtualHost (Page d'accueil - Menu Vos projets)
Nota : L'utilisation des VirtualHost est (presque) obligatoire avec Apache si vous voulez travailler correctement avec les applications WEB, les CMS ou vos sites locaux.
Il est recommandé - et même impératif - de créer un hôte virtuel pour chacun de vos projets, même si vous les mettez dans la structure \wamp\www\sous-dossier.
La page d'accueil de WampServer (\wamp\www\index.php) nécessite que vous ayez créé un hôte virtuel pour chacun de vos projets et ne fonctionnera correctement que si vous le faites.
Historique Wampserver
Dans la préhistoire de Wampserver, il était demandé de créer des sous-dossiers pour chacun des projets sous le dossier \wamp\www\
wamp
|-- www
|-- Projet1
|-- Projet2
|-- etc
Ces sous-dossiers (projet) étaient alors vus comme des liens dans la page d'accueil de WampServer sous un menu appelé « Vos projets » et ces liens contenaient "/localhost/sous-dossier".Acceptable uniquement pour des tutoriels simples
Cette « facilité » pour le débutant était parfaitement acceptable - par exemple pour ceux qui suivent des tutoriels pour apprendre uniquement le codage PHP - mais n'a jamais été destinée à être utilisé pour l'élaboration d'un site Web local ou transférable plus tard chez un hébergeur.
En fait, utilisé comme ça, ce mécanisme a causé beaucoup de problèmes dans la configuration des sites réels qui ne correspondaient plus à la configuration du site en développement.
Remarque : Dans les explications suivantes tous les (http://) sont entre parenthèses ceci pour éviter que ce soit transformé en url par le forum.
Lancer ses sites locaux par (http://localhost/projet1/) ou (http://localhost/projet2/) n'est ABSOLUMENT PAS une bonne solution, c'est même quelque chose à bannir totalement.
En effet, vous introduisez un niveau supplémentaire "localhost/" dans les url d'accès à vos sites locaux ce qui fait que beaucoup de variables prédéfinies par le serveur HTTP, par exemple des éléments du tableau $_SERVER['xxx'] n'auront pas les bonnes valeurs.
Par exemple, pour un projet wamp/www/mon-projet/
Avec l'appel tel qu'il devrait être : (http://mon-projet/) voici les valeurs de quelques éléments prédéfinis
$_SERVER['HTTP_HOST'] = mon-projet $_SERVER['SERVER_NAME'] = mon-projet $_SERVER['DOCUMENT_ROOT'] =C:/wamp/www/mon-projetEt voilà quels sont les mêmes éléments prédéfinis avec (http://localhost/mon-projet/)
$_SERVER['HTTP_HOST'] = localhost $_SERVER['SERVER_NAME'] = localhost $_SERVER['DOCUMENT_ROOT'] =C:/wamp/wwwVous pouvez voir, entre autres, que le chemin d'accès au dossier racine du projet ($_SERVER['DOCUMENT_ROOT']) n'est pas le bon chemin. et, en plus, ce sera TOUJOURS C:/wamp/www quel que soit le projet lancé de cette manière.
Ces valeurs erronées vont - à coup sûr - induire des erreurs incompréhensibles avec des Frameworks, des CMS ou des applications web que vous ajouterez à vos projets, par exemple Wordpress ou Joomla ; mais ce ne sont pas les seules.
Vos « projets » sont hébergés chez "localhost" tout comme les sites « réels » sont hébergés chez "ovh", "free", "1and1", "gandi" ou autres et, pour accéder à ces sites réels , vous ne tapez pas (http://gandi/wampserver.com) mais bien (http://wampserver.com)
Il faut donc définir quelles sont les caractéristiques et la localisation de vos projets par rapport à leurs hébergement chez "localhost".
Sans définition de VirtualHost, (http://localhost/mon-projet/) fonctionne parce que ce nom "localhost" est défini en tant nom de site par défaut et qu'une adresse d'accès lui est donnée et que le dossier /mon-projet/ est considéré comme un « niveau » secondaire du site localhost. Ceci est effectué par le fichier "C:\Windows\System32\drivers\etc\hosts" (sans extension) qui donne les correspondances entre les adresses IP et les noms de site. Après installation du serveur, ce fichier doit contenir, comme lignes actives (C'est-à-dire sans # au début de ligne), au moins :
127.0.0.1 localhost ::1 localhost(La séparation entre l'adresse IP et le nom peut être un ou plusieurs espaces ou tabulations)
Comment créer des VirtualHost avec Wampserver
Il faut toujours créer un VirtualHost AVANT d'installer une application Web ou un CMS (Joomla, Wordpress, Prestashop, Moodle, etc.)
-------------------------------------------------------------
------ Wampserver 3 - Création (ou ajout) de VirtualHost ------
Bien que cela ne vous empèche pas de lire tout ce qui suit (Et c'est même recommandé), avec Wampserver 3, la création ou l'ajout de VirtualHost ou l'ajout peut se résumer en quelques clics. Il est même recommandé d'utiliser les outils internes à Wampserver pour créer ou ajouter un VirtualHost : Voir : Wampserver 3 - Création de VirtualHost
-------------------------------------------------------------
Voir en note 3 les prérequis au sujet de l'éditeur de texte à utiliser
En fait, cela doit fonctionner exactement de la même manière que pour tout serveur Apache d'un hébergeur, avec quelques petites différences quant aux autorisations d'accès.
Il est indispensable de lire tout ce qui suit pour bien comprendre le mécanisme des VirtualHost
C'est le fichier appelé `httpd-vhosts.conf` qui contient les VirtualHost pour Apache
\wamp\bin\apache\apache2.4.33\conf\extra\httpd-vhosts.conf(Les numéros de version Apache peuvent différer, faites travailler vos petites cellules grises{©Hercule Poirot} avant de continuer)
Nota : Chaque VirtualHost a sa propre définition de DocumentRoot
Petit « à côté » N°1
-- Comment les hôtes virtuels travaillent dans Apache :
La première définition de ce fichier sera également le site par défaut, de sorte que si le nom de domaine utilisé dans le navigateur ne correspond à aucun domaine défini, c'est localhost, le premier domaine dans le fichier, qui sera servi par exemple par une tentative de hack sur votre adresse IP.
Donc, nous nous assurons que la sécurité Apache pour le domaine localhost ** A TOUJOURS POUR VALEUR **
Require localet qu'il RESTE TOUJOURS LE PREMIER de la liste des VirtualHost. Tout piratage occasionnel à partir d'une adresse externe recevra une erreur et ne pourra pas entrer sur le PC, mais si vous orthographiez mal un domaine vous verrez la page d'accueil WampServer (ou un domaine externe), parce que vous êtes sur le même PC que WampServer et donc en `local`.
Petit « à côté » N°2
-- Pour les scripts CGI
Si vous utilisez des scripts CGI, par exemple dans certains cas pour Perl, il faut en ajouter le support dans la ligne Options, par exemple :
Options +Indexes +FollowSymLinks +MultiViews +Includes +ExecCGIL'ajout d'un VirtualHost nécessite d'ajouter votre nouveau nom de domaine dans le fichier HOSTS.
`C:\windows\system32\drivers\etc\hosts`
Le fichier n'a pas d'extension et doit absolument rester sans extension. Méfiez-vous du bloc-notes (Notepad), car il peut essayer d'ajouter une extension `.txt` si vous n'avez pas de meilleure éditeur. Je vous suggère de télécharger Notepad++, c'est gratuit et un très bon éditeur.
Si vous n'arrivez pas à ouvrir le fichier hosts, voir la Note 2 de CONSEILS DE DÉPANNAGE
C'est aussi un fichier protégé que vous devez modifier avec des privilèges d'administrateur, il faut donc lancer l'éditeur avec l'option « Exécuter en tant qu'administrateur » Explications Exécuter en tant qu'administrateur
Après édition et ajout du domaine projet1, le contenu du fichier devrait ressembler à ça :
127.0.0.1 localhost 127.0.0.1 project1 ::1 localhost ::1 project1Que l'on peut très bien regrouper sur les mêmes lignes, à condition de ne pas mettre plus de huit noms de serveur par ligne :
127.0.0.1 localhost projet1 ::1 localhost projet1Remarque : Les noms (Par exemple project1) doivent être exactement les mêmes que les noms des ServerName définis dans les VirtualHost.
Notez que vous devez avoir les définitions pour l'adresse `127.0.0.1` de bouclage IPv4 et aussi l'adresse `::1` de bouclage IPv6. Apache supporte IPv6 depuis la version 2.2.19 et le navigateur va utiliser IPv4 ou IPv6, ou les deux. Je n'ai aucune idée de comment il décide quel type utiliser, mais il peut utiliser IPv6 et, si l'adresse locale IPv6 n'est pas définie, il peut y avoir des problèmes.
Maintenant, nous devons indiquer à Windows de rafraîchir le cache des noms de domaine (Sinon, il faudra redémarrer).
Ouvrir une fenêtre de commande en tant qu'Administrateur Explications Lancer en tant qu'administrateur et tapez la commande ci-dessous :
ipconfig /flushdnsCela oblige Windows à effacer le cache des noms de domaine puis à le recharger. En rechargeant Windows relira le fichier HOSTS et le nouveau domaine `project1` sera connu.
NOTE : Nom de Domaine. C'est une très mauvaise idée que de définir un ServerName ou ServerAlias qui soit le même que votre nom de domaine (*) réel. En effet, lorsque l'on demande une url dans le navigateur, ce sont d'abord les DNS locaux (fichier hosts, puis cache local) qui sont lus et si une correspondance est trouvée, c'est le site local qui sera chargé ; il sera donc impossible d'accéder au site réel.
Une bonne pratique, est de donner le même nom mais sans le tld, donc, par exemple, monsite.net en réel et monsite en local.
Le site local exemple.test est accessible à partir du réseau local dans les définitions de serveur virtuel (Require ip 192.168.0, si c'est la plage d'ip du réseau), ce changement ne s'appliquera qu'à ce site et à aucun autre. SEULEMENT ce site local sera accessible depuis le réseau puisque tous les autres, localhost compris, sont avec Require local.
Il y a aussi quelques modifications de la configuration de PHP, qui ne s'appliqueront QUE pour ce site local. Ce peut être très utile pour un site ayant besoin d'exigences spécifiques, contrairement à tous les autres sites que vous gérez.
Éventuellement, on pourrait penser que ce site est mal écrit et que seulement pour celui-ci, nous masquons les erreurs. Il existe des sites comme cela et les gens veulent toujours à les maintenir mal. Mais cela montre que nous pouvons avoir tout un tas de paramètres spécifiques qui ne s'appliquent qu'à un site local et non pas globalement à tous les sites virtuels s'exécutant sur WampServer.
(*) ServerName est un nom de domaine, même en local et doit respecter des règles. Un nom de domaine doit comporter entre 2 et 63 caractères. Les caractères autorisés sont les lettres, les chiffres et le signe "-". Le signe "-" est autorisé n'importe où sauf en première ou en dernière position.
Les accents (àâäéèêëôöùûüîï) et les lettres infléchies (ç) sont autorisés uniquement pour les noms de domaine avec l'extension .com, .net, .fr et eu. et, comme c'est relativement récent, le problème est que tous les serveurs, hébergeurs, et navigateurs ne les prennent pas en compte.
Mais, dans TOUS LES CAS, le tiret-bas (underscore) n'est pas autorisé dans les noms de domaine. Pour plus d'informations (Mais c'est assez rébarbatif), voir la Internationalized Domain Names in Applications, RFC 5890 et aussi la RFC 1034.
====== Note 3 - Éditeur de texte ======
*Prérequis important au sujet de l'éditeur de texte utilisé : Pour modifier les fichiers, vous devez utiliser un éditeur de texte, mais pas n'importe lequel. En effet, certains éditeurs de texte, le Bloc-Notes (notepad.exe) de Windows par exemple, ne sont pas capables de visualiser correctement des fichiers comportant de retours à la ligne de type Unix*, d'autres recodent subrepticement ces retours à la ligne de type Unix en type Windows/DOS, d'autres encore changent le jeux de caractère utilisé ou ajoutent des entêtes ; Or, il est impératifs que les types de fin de ligne ou les jeux de caractères des fichiers de Wampserver ne soient pas altérés, sinon cela génèrera des impossibilités et des erreurs lors de son utilisation. C'est pourquoi je recommande fortement d'utiliser un éditeur de texte gratuit, performant et en français comme Notepad++ que vous trouverez à Notepad++ (Si vous utilisez un éditeur de texte comme UtraEdit, ça ne posera aucun problème).
* Les caractères indiquant les fins de lignes sont de trois types :
- Windows/DOS : CR - LF (Carriage Return - Line Feed) Deux octets 0x0D et 0x0A
- Unix : LF (Line Feed) Un octet 0x0A
- Mac : CR (Carriage Return) Un octet : 0x0D
==============================================================
Cette contribution est une compilation des informations de RiggsFolly du forum Anglais et d'Otomatic du forum Français
Modifie 40 fois. Derniere modification le 09/03/2020 à 18:38 par Otomatic.
Pourquoi créer VirtualHost AVANT install CMS ?
Envoyé par:
Otomatic
(Modérateur)
Date: 14 April 2020 à 11:10
Bonjour,
Pourquoi faut-il créer un VirtualHost AVANT installation d'un CMS
Revenons un peu sur les VirtualHost ou Hôtes Virtuels.
Une déclaration d'un hôte virtuel comprend des éléments (presque) impératifs :
Adresse IP signifie l'adresse IP du serveur virtuel et, dans le cas présent, le caractère *, qui agit comme un caractère générique, et correspond à toute adresse IP. Le numéro de port est optionnel et est 80 par défaut. Néanmoins, ici nous le précisons pour permettre de faciliter les remplacements éventuels
- Ligne 01 ServerName [protocole://]nom de domaine qualifié[:port]
Par défaut, le protocole est http. Le nom de domaine est le nom par lequel on demandera à se connecter au site virtuel. Il doit correspondre aux normes des noms de domaine. Si, comme nom on a (sans les guillemets) "ServerName nom_du_site", on se connectera par (http://nom_du_site)
- Ligne 02 DocumentRoot chemin du répertoire (Sans slash final)
Cette directive permet de définir le répertoire à partir duquel Apache va servir les fichiers. Le chemin de l'URL sera ajouté par le serveur à la racine des documents afin de construire le chemin du document recherché.
Par exemple, avec DocumentRoot C:/wamp/www/monsite, un accès à (http://nom_du_site/index.php) se réfère alors à C:/wamp/www/monsite/index.php.
Si chemin répertoire n'est pas un chemin absolu, il est considéré comme relatif au chemin défini par la directive ServerRoot.
- Ligne 03 <Directory chemin du répertoire> ... </Directory> (Avec un slash final sur le chemin)
Les balises <Directory> et </Directory> permettent de regrouper un ensemble de directives qui ne s'appliquent qu'au répertoire précisé, à ses sous-répertoires, et aux fichiers situés dans ces sous-répertoires, par exemple des autorisations ou des interdictions d'accès.
- Ligne 04 Options ....
Définit les fonctionnalités disponibles pour un répertoire particulier. Le signe + (non présent par défaut si toutes les options sont +) avant le nom de la fonctionnalité valide celleci, le signe - la dévalide. Dans le cas présent :
Indexes : Si une URL requise correspond au répertoire concerné, et si aucun fichier index.html ou index.php n'est défini pour ce répertoire, le module mod_autoindex va renvoyer un listing formaté du contenu du répertoire.
FollowSymLinks : Le serveur va suivre les liens symboliques dans le répertoire concerné.
Multiviews : Les vues multiples ("multiviews"
à contenu négocié à l'aide du module mod_negotiation sont autorisées.
- Ligne 05 AllowOverride all
Lorsque le serveur trouve un fichier .htaccess , il doit savoir lesquelles des directives placées dans ce fichier sont autorisées à modifier la configuration préexistante ; c'est le rôle de AllowOverride d'autoriser toutes ou certaines des directives des fichiers .htaccess.
- Ligne 06 Require local
La directive Require autorise ou interdit les accès au répertoire concerné. Dans le cas présent (Require local) seules les demandes d'accès provenant du PC sur lequel est installé le serveur seront autorisées (Cela correspond à Allow from 127.0.0.1 et ::1 et localhost).
-----------------------------------
Lorsque vous mettez en ligne un CMS (Joomla, Wordpress ou autre) chez un hébergeur, vous ne pouvez le faire que si vous disposez, chez cet hébergeur d'un « site » pour y installer ledit CMS ou y mettre d'autres fichiers.
Vous ne vous en rendez pas compte, mais chez l'hébergeur, votre « site » est déclaré sous forme de Virtual Host, exactement comme on vient de le décortiquer ci-dessus (Peut-être avec des options en plus ou en moins).
En y regardant d'un peu plus près, chez l'hébergeur, le chemin d'accès (DocumentRoot) est un petit peu plus complexe qu'en local, par exemple :
/srv/data/web/vhosts/nom_du_site/htdocs
ou
/mnt/109/sdb/a/d/nom_du_site
en supposant que chez l'hébergeur, votre site soit nom_du_site.net lorsque vous demanderez (http://nom_du_site.net/wordpress/index.php), c'est le fichier /srv/data/web/vhosts/nom_du_site/htdocs/wordpress/index.php qui sera servi.
Et si, dans un script PHP chez cet hébergeur vous demandez :
Venons-en maintenant à un serveur local, par exemple Wampserver.
Vous créez un dossier, par exemple C:/wamp/www/mon_site/ dans lequel vous installez un CMS, par exemple Joomla (dans un dossier nommé joomla) et vous lancez le script d'installation. Pour le faire, vous avez été obligé de mettre l'url (http://localhost/mon_site/joomla/proc_install.php). Et oui, il a fallu ajouter localhost dans l'url.
Que dit la documentation Apache :
- Toute requête qui ne correspond à aucune section <VirtualHost> existante est traitée avec la configuration du serveur principal.
- Si un serveur virtuel ne définit pas de directive ServerName, le nom de ce serveur virtuel sera hérité du serveur principal.
C'est bien le cas, car après installation de Wampserver, aucun VirtualHost n'est défini. Ce sont donc les définitions du fichier de configuration Apache qui sont prises en compte :
Et, dans ce cas d'installation d'un CMS avec l'url (http://localhost/...), tous les paramètres (chemins, fichiers, url internes, etc.) créés lors de la procédure d'installation le seront avec la variable php $_SERVER['DOCUMENT_ROOT'] égale à C:/wamp/www et non pas C:/wamp/www/mon_site
C'est pourquoi il est beaucoup plus diffcile de créer un VirtualHost mon_site APRÈS l'installation d'un CMS, car alors, la valeur de $_SERVER['DOCUMENT_ROOT'] deviendrait C:/wamp/www/mon_site alors que les paramètres, après installation du CMS ne connaissent que C:/wamp/www d'où erreur de chemin et fichiers non trouvés.
Modifie 1 fois. Derniere modification le 14/04/2020 à 11:12 par Otomatic.
Pourquoi faut-il créer un VirtualHost AVANT installation d'un CMS
Revenons un peu sur les VirtualHost ou Hôtes Virtuels.
Une déclaration d'un hôte virtuel comprend des éléments (presque) impératifs :
<VirtualHost *:80>
ServerName nom_du_site
DocumentRoot C:/wamp/www/monsite
<Directory "C:/wamp/www/monsite/">
Options Indexes FollowSymLinks MultiViews
AllowOverride all
Require local
</Directory>
</VirtualHost>
- Ligne 00 <VirtualHost adresse IP[:port]>Adresse IP signifie l'adresse IP du serveur virtuel et, dans le cas présent, le caractère *, qui agit comme un caractère générique, et correspond à toute adresse IP. Le numéro de port est optionnel et est 80 par défaut. Néanmoins, ici nous le précisons pour permettre de faciliter les remplacements éventuels
- Ligne 01 ServerName [protocole://]nom de domaine qualifié[:port]
Par défaut, le protocole est http. Le nom de domaine est le nom par lequel on demandera à se connecter au site virtuel. Il doit correspondre aux normes des noms de domaine. Si, comme nom on a (sans les guillemets) "ServerName nom_du_site", on se connectera par (http://nom_du_site)
- Ligne 02 DocumentRoot chemin du répertoire (Sans slash final)
Cette directive permet de définir le répertoire à partir duquel Apache va servir les fichiers. Le chemin de l'URL sera ajouté par le serveur à la racine des documents afin de construire le chemin du document recherché.
Par exemple, avec DocumentRoot C:/wamp/www/monsite, un accès à (http://nom_du_site/index.php) se réfère alors à C:/wamp/www/monsite/index.php.
Si chemin répertoire n'est pas un chemin absolu, il est considéré comme relatif au chemin défini par la directive ServerRoot.
- Ligne 03 <Directory chemin du répertoire> ... </Directory> (Avec un slash final sur le chemin)
Les balises <Directory> et </Directory> permettent de regrouper un ensemble de directives qui ne s'appliquent qu'au répertoire précisé, à ses sous-répertoires, et aux fichiers situés dans ces sous-répertoires, par exemple des autorisations ou des interdictions d'accès.
- Ligne 04 Options ....
Définit les fonctionnalités disponibles pour un répertoire particulier. Le signe + (non présent par défaut si toutes les options sont +) avant le nom de la fonctionnalité valide celleci, le signe - la dévalide. Dans le cas présent :
Indexes : Si une URL requise correspond au répertoire concerné, et si aucun fichier index.html ou index.php n'est défini pour ce répertoire, le module mod_autoindex va renvoyer un listing formaté du contenu du répertoire.
FollowSymLinks : Le serveur va suivre les liens symboliques dans le répertoire concerné.
Multiviews : Les vues multiples ("multiviews"
à contenu négocié à l'aide du module mod_negotiation sont autorisées.- Ligne 05 AllowOverride all
Lorsque le serveur trouve un fichier .htaccess , il doit savoir lesquelles des directives placées dans ce fichier sont autorisées à modifier la configuration préexistante ; c'est le rôle de AllowOverride d'autoriser toutes ou certaines des directives des fichiers .htaccess.
- Ligne 06 Require local
La directive Require autorise ou interdit les accès au répertoire concerné. Dans le cas présent (Require local) seules les demandes d'accès provenant du PC sur lequel est installé le serveur seront autorisées (Cela correspond à Allow from 127.0.0.1 et ::1 et localhost).
-----------------------------------
Lorsque vous mettez en ligne un CMS (Joomla, Wordpress ou autre) chez un hébergeur, vous ne pouvez le faire que si vous disposez, chez cet hébergeur d'un « site » pour y installer ledit CMS ou y mettre d'autres fichiers.
Vous ne vous en rendez pas compte, mais chez l'hébergeur, votre « site » est déclaré sous forme de Virtual Host, exactement comme on vient de le décortiquer ci-dessus (Peut-être avec des options en plus ou en moins).
En y regardant d'un peu plus près, chez l'hébergeur, le chemin d'accès (DocumentRoot) est un petit peu plus complexe qu'en local, par exemple :
/srv/data/web/vhosts/nom_du_site/htdocs
ou
/mnt/109/sdb/a/d/nom_du_site
en supposant que chez l'hébergeur, votre site soit nom_du_site.net lorsque vous demanderez (http://nom_du_site.net/wordpress/index.php), c'est le fichier /srv/data/web/vhosts/nom_du_site/htdocs/wordpress/index.php qui sera servi.
Et si, dans un script PHP chez cet hébergeur vous demandez :
echo $_SERVER['DOCUMENT_ROOT'];vous obtiendrez
/srv/data/web/vhosts/nom_du_site/htdocsou
/mnt/109/sdb/a/d/nom_du_siteTout ça pour dire que un VirtualHost existait chez l'hébergeur AVANT que vous n'y installiez un CMS, Joomla ou Wordpress par exemple.
Venons-en maintenant à un serveur local, par exemple Wampserver.
Vous créez un dossier, par exemple C:/wamp/www/mon_site/ dans lequel vous installez un CMS, par exemple Joomla (dans un dossier nommé joomla) et vous lancez le script d'installation. Pour le faire, vous avez été obligé de mettre l'url (http://localhost/mon_site/joomla/proc_install.php). Et oui, il a fallu ajouter localhost dans l'url.
Que dit la documentation Apache :
- Toute requête qui ne correspond à aucune section <VirtualHost> existante est traitée avec la configuration du serveur principal.
- Si un serveur virtuel ne définit pas de directive ServerName, le nom de ce serveur virtuel sera hérité du serveur principal.
C'est bien le cas, car après installation de Wampserver, aucun VirtualHost n'est défini. Ce sont donc les définitions du fichier de configuration Apache qui sont prises en compte :
ServerName localhost:80 DocumentRoot "C:/wamp/www" <Directory "C:/wamp/www/">localhost étant le seul VirtualHost défini, toutes les url devront être basées sur ce site virtuel, donc commencer par (http://localhost/...) pour pouvoir être traitées sans erreur. De plus, de base, c'est le seul qui est défini dans le fichier hosts. Si on omet localhost, les url ne seront pas trouvées d'où erreur 404.
Et, dans ce cas d'installation d'un CMS avec l'url (http://localhost/...), tous les paramètres (chemins, fichiers, url internes, etc.) créés lors de la procédure d'installation le seront avec la variable php $_SERVER['DOCUMENT_ROOT'] égale à C:/wamp/www et non pas C:/wamp/www/mon_site
C'est pourquoi il est beaucoup plus diffcile de créer un VirtualHost mon_site APRÈS l'installation d'un CMS, car alors, la valeur de $_SERVER['DOCUMENT_ROOT'] deviendrait C:/wamp/www/mon_site alors que les paramètres, après installation du CMS ne connaissent que C:/wamp/www d'où erreur de chemin et fichiers non trouvés.
Modifie 1 fois. Derniere modification le 14/04/2020 à 11:12 par Otomatic.
Cette discussion a été fermée
