Cette section traite de questions courantes sur la façon d'installer PHP.
PHP est disponible sur la plupart des systèmes d'exploitation et pour
quasiment n'importe quel serveur web.
-
Pourquoi ne doit-on pas utiliser Apache 2 dans un environnement threadé
multiprocesseur de production ?
-
PHP est un mortier. C'est un mortier utilisé pour construire de belles
applications web en utilisant beaucoup de bibliothèques ensemble,
apparaissant comme une seule entité à travers un langage intuitif et
facile à apprendre. La flexibilité et la puissance de PHP se fondent sur
la stabilité et la robustesse de la plate-forme fondamentale. Il a besoin
d'un OS qui fonctionne, d'un serveur web qui fonctionne et de bibliothèques
externes pour coller le tout. Lorsqu'un seul de ces éléments arrête subitement
de fonctionner, PHP doit identifier le problème et le réparer au plus vite.
En rendant le cadre fondamental plus complexe en ne séparant pas les exécutions
des threads, ni les segments mémoires, ni un endroit clos pour traiter chaque requête
entrante, de nouvelles faiblesses sont introduites dans le système PHP.
Pour utiliser un MPM threadé, il est possible de regarder du côté
d'une configuration FastCGI dans laquelle PHP s'exécute dans son propre espace
mémoire.
-
Unix/Windows : où doit être placé mon fichier php.ini ?
-
Par défaut sous Unix, il doit être placé dans /usr/local/lib
qui est en fait <install-path>/lib.
La plupart des personnes voudront changer ceci lors de la compilation
avec l'option --with-config-file-path.
Il est possible par exemple de le régler de cette façon :
--with-config-file-path=/etc
Il faut alors copier le fichier php.ini-development livré
avec les sources vers /etc/php.ini et l'éditer pour
l'adapter aux besoins.
--with-config-file-scan-dir=PATH
Sous Windows, le chemin par défaut de php.ini est le répertoire de
Windows. Lors de l'utilisation du serveur web Apache, php.ini est tout
d'abord cherché dans le répertoire d'installation de Apache, c'est-à-dire
c:\program files\apache group\apache. De cette
façon, il est possible d'avoir un php.ini différent pour chaque version de
Apache installée.
Consulter aussi le chapitre sur le
fichier de configuration.
-
Unix : j'ai installé PHP, mais à chaque fois que je charge un
document, j'obtiens l'erreur 'Document Contains No Data' ! Que se
passe-t-il ?
-
Cela signifie probablement que PHP rencontre un problème et génère un
fichier de vidage. Consulter les fichiers de logs du serveur pour voir
si c'est le cas, et tentez de reproduire le problème avec un test
simple. En cas de maîtrise de 'gdb', il serait très utile de fournir un
backtrace avec le rapport de bogue, afin d'aider les développeurs à
cerner le problème. Lors de l'utilisation de PHP en module Apache, essayer
ceci :
-
Stoppez les processus httpd
-
gdb httpd
-
Stoppez les processus httpd
-
> run -X -f /path/to/httpd.conf
-
Pointez alors avec le navigateur vers l'URL posant problème.
-
> run -X -f /path/to/httpd.conf
-
En cas de fichier de vidage, gdb en informera.
-
tapez : bt
-
Il est recommandé d'inclure le backtrace dans le rapport de bogue.
Celui-ci doit être posté sur
» https://github.com/php/php-src/issues.
Si le script utilise les expressions régulières
(preg_match() et consorts), il faut s'assurer que PHP et
Apache ont été compilés avec les mêmes outils d'expressions régulières.
Cela devrait être automatiquement le cas avec PHP et Apache 1.3.x.
-
Unix : J'ai installé PHP en utilisant des fichiers sources RPM, mais
apache ne traite pas les pages PHP. Que se passe-t-il ?
-
En supposant qu'Apache et PHP ont été installés à partir
de fichiers RPM, il faudra commenter ou ajouter au moins quelques-unes
des lignes suivantes dans le fichier httpd.conf :
# Extra Modules
AddModule mod_php.c
AddModule mod_perl.c
# Extra Modules
LoadModule php_module modules/mod_php.so
LoadModule php5_module modules/libphp5.so
LoadModule perl_module modules/libperl.so
Et ajouter :
AddType application/x-httpd-php .php
... aux propriétés globales ou aux propriétés du VirtualDomain où
PHP doit officier.
-
Unix : J'ai patché Apache avec l'extension FrontPage et subitement, PHP
ne fonctionne plus.
Est-ce que PHP est incompatible avec l'extension FrontPage pour Apache ?
-
Non, PHP fonctionne très bien avec l'extension FrontPage. Le souci vient du fait
que le patch pour l'installation de FrontPage modifie la structure d'Apache,
qui est relié à PHP.
Recompiler PHP (en utilisant 'make clean ; make') après avoir patché Apache avec
l'extension FrontPage devrait résoudre ce problème.
-
Unix/Windows : J'ai installé PHP, mais lorsque je tente d'accéder à un fichier
contenant un script PHP via mon navigateur, j'obtiens un écran vide.
-
L'affichage du code source du document dans le navigateur devrait
probablement révéler le code source du script PHP.
Cela signifie que le serveur web n'a pas envoyé le script à PHP pour
interprétation. Quelque chose est incorrect dans la configuration
du serveur web - revérifiez la configuration du serveur web en vous
référant aux instructions d'installation
de PHP.
-
Unix/Windows : J'ai installé PHP, mais lorsque je tente d'accéder à un fichier contenant un
script PHP via mon navigateur, j'obtiens une erreur de type 'server 500 error'.
-
Quelque chose se passe mal lorsque le serveur tente d'utiliser PHP.
Pour tenter de récupérer un message d'erreur, depuis la ligne de commande,
se placer dans le répertoire contenant l'exécutable PHP
(php.exe sous Windows) et exécutez la commande
php -i.
Si PHP a un problème quelconque l'empêchant de fonctionner, un message
d'erreur devrait s'afficher qui devrait expliquer comment résoudre ce souci. Si un
écran de code HTML apparaît (la sortie de la fonction
phpinfo()),
cela signifie que PHP fonctionne correctement et que le problème doit
certainement venir de la configuration du serveur web qu'il est recommandé de
re-vérifier.
-
Quelques systèmes d'exploitation : J'ai installé PHP sans erreur, mais lorsque
je tente de démarrer Apache, j'obtiens une erreur du type
'
Undefined symbols' :
[mybox:user /src/php5] root# apachectl configtest
apachectl: /usr/local/apache/bin/httpd Undefined symbols:
_compress
_uncompress
-
Cela n'a actuellement rien à voir avec PHP mais avec la bibliothèque cliente
MySQL. Suivant les versions, elle a besoin que PHP soit compilé avec l'option
--with-zlib, d'autres non.
Ce problème est également traité dans la FAQ de MySQL.
-
Windows : J'ai installé PHP, mais lorsque je tente d'accéder à un fichier contenant un script PHP
via mon navigateur, j'obtiens l'erreur :
cgi error:
The specified CGI application misbehaved by not
returning a complete set of HTTP headers.
The headers it did return are:
-
Ce message d'erreur signifie que PHP a échoué lors de l'affichage.
Pour tenter de récupérer un message d'erreur, depuis la ligne de commande,
se placer dans le répertoire contenant l'exécutable PHP
(php.exe sous Windows) et exécuter la commande
php -i. Si PHP a un quelconque souci de
fonctionnement, alors un message d'erreur le décrivant s'affichera. Si un
écran de code HTML apparaît (le contenu du résultat de la fonction
phpinfo()), alors PHP fonctionne
correctement.
Si PHP fonctionne depuis la ligne de commande, tenter d'accéder au script
encore une fois via le navigateur. S'il échoue toujours, alors, il se peut que ce
soit l'un des soucis suivants :
-
Les permissions du script PHP des fichiers php.exe,
php5ts.dll, php.ini ou de toute extension nécessaire à PHP
que l'on tente de charger, sont telles que l'utilisateur internet anonyme du système
ISUR_<machinename> ne peut pas y accéder.
-
Le script PHP n'existe pas (ou n'est pas à l'endroit supposé, relativement au
répertoire racine du serveur web). Il est à noter que pour le serveur web IIS, il est possible de
vérifier cela en cochant la case 'vérifier si le fichier existe' lors de la configuration
de l'exécution des scripts dans le gestionnaire de services Internet. Si un fichier de script
n'existe pas, le serveur web retournera une erreur 404. IIS a également
l'avantage d'effectuer toutes les identifications requises automatiquement,
basés sur les permissions NTLanMan, sur le fichier de script.
-
Windows : J'ai suivi toutes les instructions, mais je n'arrive toujours pas à faire fonctionner
PHP et IIS ensemble !
-
Il faut s'assurer que chaque utilisateur qui a besoin d'exécuter un script PHP
possède les droits requis pour exécuter le fichier
php.exe !
IIS utilise un utilisateur anonyme qui est ajouté lors de l'installation de IIS.
Cet utilisateur doit avoir les droits suffisants sur le fichier
php.exe. De même, tous les utilisateurs enregistrés
doivent posséder les droits requis pour exécuter le fichier
php.exe.
Pour IIS4, il faut lui dire que PHP est un moteur de script.
De plus, il est recommandé de lire cette FAQ.
-
Lors de l'exécution de PHP comme CGI avec IIS, PWS, OmniHTTPD ou Xitami,
j'obtiens l'erreur suivante :
Security Alert! PHP CGI
cannot be accessed directly..
-
Il faut définir la directive
cgi.force_redirect à 0. Par défaut, elle vaut 1, donc,
soyez sûrs que cette directive n'est pas commentée (précédée d'un point virgule).
Comme toutes les directives, elles sont définies dans le php.ini.
Comme la valeur par défaut vaut 1, il est impératif d'être sûr
à 100% que le bon fichier php.ini a été lu.
Consulter cette FAQ
pour plus de détails.
-
Comment puis-je savoir si mon php.ini a bien été trouvé et lu ?
Cela semble être le cas mais aucun de mes changements n'ont eu d'effet.
-
Pour être sûr que le php.ini a été lu par PHP, effectuer un appel à la fonction
phpinfo(). Vers le haut du document résultant, il devrait figurer
une liste appelée Configuration File (php.ini).
Cela indiquera où PHP a cherché le php.ini et si oui ou non il l'a lu.
Si seul un dossier PATH existe, alors le fichier n'est pas lu,
et il faut copier le php.ini dans ce dossier. Si le php.ini est présent dans le
chemin, cela signifie qu'il a bien été lu.
Si le php.ini a bien été lu et que PHP est exécuté comme module,
alors il faut s'assurer de redémarrer le serveur web après avoir effectué les modifications
au php.ini.
Voir aussi la fonction php_ini_loaded_file().
-
Comment rendre le fichier php.ini disponible à PHP sous Windows ?
-
Il y a plusieurs façons de faire cela. Lors de l'utilisation d'Apache,
se référer à la documentation d'Apache, sinon il faut définir
la variable d'environnement PHPRC.
-
Est-il possible d'utiliser la négociation sur le contenu fournie par Apache (option
MultiViews) avec PHP ?
-
Si les liens vers les fichiers PHP incluent l'extension, tout fonctionne
parfaitement. Cette entrée de la FAQ traite uniquement du cas où les liens
vers les fichiers PHP n'incluent pas l'extension et que l'on souhaite
utiliser la négociation sur le contenu fourni par Apache pour choisir les
fichiers PHP depuis une URL qui ne contient pas d'extension. Dans ce
cas, remplacez la ligne
AddType application/x-httpd-php .php par :
AddHandler php5-script php
AddType text/html php
Cette solution ne fonctionne pas pour Apache 1 car le module PHP
ne capture pas le php-script.
-
Est-ce que PHP est limité au traitement des méthodes GET et POST ?
-
Non, il est possible de gérer tout type de méthode, comme CONNECT. Le
statut de réponse approprié peut être envoyé avec la fonction
header(). Si seules les méthodes POST et GET doivent
être gérées, il est possible de configurer Apache comme ce qui suit :
<LimitExcept GET POST>
Deny from all
</LimitExcept>