Problème affichage PHP

UU-YouYou-UU

Membre enregistré
20 Mai 2008
7
0
Bonjour,
J'ai un projet à réaliser en PHP/MySQL, et j'ai donc télécharger MAMP pour installer tous ces composants, je n'ai pas de soucis avec MySQL, mais par contre, quand j'ouvre une page PHP que j'ai créé avec Firefox ça ne s'affiche pas du tout !!!
Voici le code source de ma page :
<HTML>
<HEAD>
<TITLE>Hello world</TITLE>
</HEAD>

<BODY>
<?php
$i="Hello world" ;
echo "$i" ;
?>
</BODY>
</HTML>
Et tout ce que j'obtiens quand je l'ouvre, c'est une page blanche !!! Alors, je ne comprends pas, j'ai installé MAMP comme expliqué dans le "manuel", donc je ne vois pas ce que j'ai pu oublier de faire ou ce que j'ai mal fait ! Si ça peut aider, je suis sous Mac OS X 10.4
Si quelqu'un peut m'aider, ce serait cool...
 
Bonjour et bienvenue sur MacGé' :coucou:

Le code source de cette page blanche est-il vide, ou contient-il les balises HTML (<HTML>, <HEAD>, etc.) ?
 
Quand j'affiche le code source de la page, il me donne ça :
<HTML>
<HEAD>
<TITLE>Hello world</TITLE>
</HEAD>

<BODY>
<?php
$i="Hello world" ;
echo "$i" ;
>
</BODY>
</HTML>
Donc il a l'air de zapper le point d'interrogation de la balise fermante php....
 
Je viens de modifier mon code source. En écrivant mon fichier PHP de cette manière :
<HTML>
<HEAD>
<TITLE>Hello world</TITLE>
</HEAD>

<BODY>
<?
$i="Hello world" ;
echo "$i" ;
?>
</BODY>
</HTML>
c'est-à-dire en retirant le "php" de la balise ouvrante pour le PHP, lorsque j'affiche le code source par le navigateur, j'obtiens :
<HTML>
<HEAD>
<TITLE>Hello world</TITLE>
</HEAD>

<BODY>
<?
$i="Hello world" ;
echo "$i" ;
?>
</BODY>
</HTML>
et là le point d'interrogation de la balise fermante PHP est bien affiché...
Je ne comprends pas pourquoi ça ne marche pas !!!!
 
L'affichage du point d'interrogation n'est, je pense, qu'un problème secondaire sans rapport avec l'affichage de la page blanche.

Pour moi, le fichier n'est pas interprété par le serveur, mais envoyé tel quel au navigateur.

Le module PHP du serveur web est-il bien activé et paramétré ?
Le fichier est-il lu à une adresse impliquant qu'on passe effectivement par le serveur web pour l'atteindre ?
Quelle est l'extension du fichier ?
 
Le module PHP su serveur web doit être activé et paramétré puisque j'ai installé XAMMP pour que tout ça soit pris en charge directement et que je n'ai pas à me casser la tête modifier des tas de fichiers etc.

En ce qui concerne l'adresse du fichier, le problème vient peut-être de là puisque l'adresse affichée dans le navigateur est l'adresse du fichier sur mon disque dur. Il n'y pas de lien avec mon serveur "localhost". Mais si c'est de là que vient le problème, comment je fais pour avoir une adresse impliquant qu'on passe par le serveur web pour l'atteindre ?

Et sinon, l'extension du fichier est PHP. C'est ce qu'il faut, non ?
 
l'extension du fichier est PHP. C'est ce qu'il faut, non ?
Oui. Donc là, c'est ok.

Le module PHP su serveur web doit être activé et paramétré puisque j'ai installé XAMMP pour que tout ça soit pris en charge directement et que je n'ai pas à me casser la tête modifier des tas de fichiers etc.
On peut en tout cas admettre dans un premier temps que ça marche.

En ce qui concerne l'adresse du fichier, le problème vient peut-être de là puisque l'adresse affichée dans le navigateur est l'adresse du fichier sur mon disque dur.
La page blanche obtenue vient de là. En ouvrant le fichier PHP dans le navigateur directement depuis le disque, ni le serveur ni l'interpréteur PHP ne sont sollicités.

La balise <?php ... ?> (ou même <? ... ?>) est lue mais ignorée, conformément à la norme HTML. D'où l'absence d'affichage.

Il n'y pas de lien avec mon serveur "localhost". Mais si c'est de là que vient le problème, comment je fais pour avoir une adresse impliquant qu'on passe par le serveur web pour l'atteindre ?
Il faut absolument que l'adresse du fichier dans le navigateur commence par http://localhost/... (par exemple http://localhost/monfichier.php).

Cette adresse ne peut bien évidemment être atteinte que si le serveur HTTP est effectivement lancé et correctement paramétré, et que le fichier est enregistré dans l'un des dossiers assignés au site web.
 
Et comment je sais où sont les dossiers assignés au site web ? Ou comment assigner un dossier au site web ? Je ne sais même pas où ça se situe !!!! lol !
 
Et comment je sais où sont les dossiers assignés au site web ? Ou comment assigner un dossier au site web ? Je ne sais même pas où ça se situe !!!! lol !
C'est un paramètre du serveur HTTP.

Par exemple, sur le serveur Apache, ça se trouve dans le fichier de configuration principal (qui est généralement appelé httpd.conf), et on utilise la directive <Directory ...>.

Mais comme le sujet est vaste, je te conseillerait plutôt de commencer à utiliser les dossiers préconfiguré du serveur (il y a déjà au moins le racine du site web, et probablement aussi un dossier spécialement prévu pour les script PHP), puis de lire par la suite l'ensemble de la doc de ton logiciel serveur sur le sujet, ou un tutoriel qui lui serait consacré.
 
Oki, merci beaucoup. J'ai déménagé mon dossier de travail dans le dossier du site PHP de XAMPP qui était lié associé au serveur PHP. Du coups j'arrive à afficher mes pages !!!
Merci beaucoup, maintenant je vais pouvoir me mettre à bosser ! :)
 
1- HTML 3 c etait il y a plus de dix ans :)
2- on s epare le fond de la forme :)
Oui certes, je suis tout-à-fait d'accord.

Mais quand on débute, il faut bien commencer par faire quelque chose de simple et qui marche, avant d'apprendre comment bien faire et entrer dans les complications (ça vient tout naturellement, mais il faut un peu de temps).

Là ce n'était qu'une petite mise en route. Maintenant que ça marche, les choses sérieuses vont pouvoir commencer.
 
Oui certes, je suis tout-à-fait d'accord.

Mais quand on débute, il faut bien commencer par faire quelque chose de simple et qui marche, avant d'apprendre comment bien faire et entrer dans les complications (ça vient tout naturellement, mais il faut un peu de temps).

Là ce n'était qu'une petite mise en route. Maintenant que ça marche, les choses sérieuses vont pouvoir commencer.
Je ne suis pas tout à fait d'accord : effectivement pas la peine de commencé à apprendre les "subtilités" (si on peut appeler ça comme ça) de xhtml 1.1, mais aujourd'hui apprendre du HTML3 même pour commencer c'est ridicule, la plupart des tuto qu'on trouve enseigne le xhtml et c'est pas plus compliqué.

Parce que bon là c'est quand même les balises en majuscules et tout... vraiment vieux vieux ça ! À quoi ça servirai qu'il apprennent à faire des frames pour qu'on lui dise tout de suite après "nan mais ça faut pas s'en servir c'pas cool"..? Je pense que c'est pareil pour le html, pourquoi apprendre quelque chose qu'il te faudra oublier et mettre à jour dès que tu voudra faire quelque chose de sérieux ?

Puis apprendre directement le xhtml (n'importe quelle version) permet de ne pas prendre de (très) mauvaises habitudes.



On commence par apprendre le C à la fac en général, pas l'assembleur (même si la comparaison est foireuse c'est le principe ^^).

:)
 
Je dis seulement qu'un "Hello world" en HTML 3 est amplement suffisant pour tester l'installation de MAMP. Ça marche, et c'est l'essentiel compte tenu du but à atteindre.

D'un point de vue pédagogique, il est intéressant de savoir que HTML 3 a existé, que c'était simple, et que ça fonctionne encore (c'est bon à savoir quand, plus tard, on doit faire un fichier de test de trois lignes : ça prend moins de dix secondes).

Pour tout le reste (et je suis d'accord qu'il fait absolument y venir rapidement) c'est de la formation et de la pratique à acquérir.
 
Je suis d'accord pour ne pas trop s'attarder sur HTML 3, mais pas pour le passer totalement sous silence.

Et puis écrire un ou deux fichiers en HTML 3, ça ne fait pas de mal. Je n'appelle pas ça "prendre de mauvaises habitudes".
On commence par apprendre le C à la fac en général, pas l'assembleur (même si la comparaison est foireuse c'est le principe ^^). :)
Justement, moi j'ai commencé par l'assembleur (et même le langage machine, tout en hexa et à la main) bien avant le langage C.

Et avec le recul, je m'aperçois que ça m'a permis d'acquérir un énorme avantage sur mes camarades de classe et mes collègues de bureau, tant pour la compréhension du langage (je dois être le seul à avoir pigé les pointeurs en C du premier coup) que pour l'analyse et l'utilisation de ce qu'il produit (optimisation, débogage, reverse engineering).

Il vaut mieux trop en savoir que pas assez, et certaines chronologies dans l'enseignement sont préférables si l'on ne veut pas rater des informations importantes pour une appréhension plus complète des problèmes futurs.

Il est beaucoup plus simple d'apprendre et de comprendre le C quand on connaît déjà l'assembleur (même si ce n'est pas dans cet ordre que c'est enseigné à l'école), et il est plus instructif de voir les premières versions de HTML avant les langages qui lui ont succédé et qui en découlent.

Faire l'inverse est beaucoup moins passionnant et nécessite donc plus de volonté, plus d'investissement personnel. Et au final peu de gens le font ou y parviennent suffisamment.

D'une manière générale, apprendre (même très succinctement) les outils dans leur ordre historique d'apparition, et donc conformément au sens d'évolution de la pensée qui les a conçus et fait évoluer, c'est une manière de comprendre les raisons profondes de leur constitution, de connaître leurs défauts et leurs points forts, et d'avoir au final le maximum d'éléments pour pouvoir les choisir et les utiliser au mieux.

Même si ces connaissances n'apparaissent que comme de la culture générale, elles permettent de passer de la simple technique à l'ingénierie efficace.



Bon, me v'la à faire des longs discours. On n'était pas partis pour ça, il me semble... :siffle: ;) :D
 
Et, oh, vous enflammer pas !!! Mon projet c'est pas un projet de développement
de pages web, c'est un projet de bases de données ! La page web on en a juste besoin pour utliser le PHP, pour gérer des requêtes globales que pourraient faire les utilisateurs de la base de données (permettant d'indexer les publications d'un laboratoire)
. DOnc voilà, c'est normal que ça soit du vieux HTML !!! On a même pas de vraie présentations à faire, ça peut être tout moche si on veut, du moment que les requêtes SQL fonctionnent !!!!
Voilou !!! C'est gentil de polémiquer sur mon cas !!!! :D
 
Mais on ne s'enflamme pas, on expose calmement nos points de vue :eek:.

Mais le plus important, c'est que tatouille, p4bl0 et moi-même sommes d'accord sur un point essentiel : il n'est pas raisonnable d'en rester à l'HTML de base tel qu'il apparaît dans le source du fichier que tu as présenté plus haut.


Je vais prendre un exemple simple.

J'imagine que tu vas t'adresser à des utilisateurs qui vivent dans notre beau pays, et que ta base et tes pages d'interface vont par conséquent contenir du texte en langue française.

Or, le codage des pages a une énorme importance lorsqu'on doit traiter des voyelles accentuées ou autres caractères spéciaux. Si de tels caractères ne sont pas transcrits dans des séquences HTML spécifiques (par exemple '&eacute;' pour 'é') et que le codage utilisé n'est pas spécifié, alors ils apparaîtrons différemment selon le système et le paramétrage du navigateur de l'utilisateur.

Un 'é' codé initialement en Mac OS Roman (le codage par défaut sur Mac) va s'afficher sous la forme d'un '&#381;' (Z caron or hacek).

Un 'é' codé initialement en UTF-8 va s'afficher sous la forme d'une séquence 'é' (C3 A9 en hexa).

Bref, ça risque de devenir rapidement illisible et incompréhensible si on n'y prend pas garde.

Pour y remédier, on spécifie dès le début du fichier le nom du code de caractères utilisé (par exemple, en commençant l'entête par un truc du genre :
Bloc de code:
[COLOR="SlateGray"](...)[/COLOR]
<head>
<meta http-equiv="Content-Type" content="text/html; [COLOR="DarkRed"][B]charset=ISO-8859-1[/B][/COLOR]" />
[COLOR="SlateGray"](...)[/COLOR]


D'où l'intérêt de se pencher très rapidement sur le problème.
 
Je rejoins PA5CAL sur le fait qu'il est indispensable de connaître les langages et leurs évolutions, même si j'attache moins d'importance à l'ordre dans lequel on les apprend (moi j'ai pas eu de mal à manipuler un pointeur avant d'apprendre l'assembleur ;) ).

Pour le HTML, c'est particulièrement indispensable d'en connaître les versions précédentes, et même de les connaître bien et avec leurs subtilités. Parce que les projets qui débutent de 0, c'est rarissime, et quand on doit reprendre un site qui a 10 ans, que les tableaux ce soit "pas bien" ou pas, il faut bien faire avec.
Et puis d'ailleurs, il y a de nombreux contextes dans lesquels écrire en xhtml n'a pas d'intérêt particulier.