Pour éviter de répondre sans cesse aux memes questions, j'invite les nouveaux membres du forum à lire ce topic avant de poster une demande d'aide dans la catégorie php.
 
Prérequis et mises au point
 
    Le forum dispose d'une fonction "rechercher", c'est une raison suffisante pour l'utiliser.
    Comme le reste du forum prog, la cat' php n'est pas l'endroit approprié pour recruter, ni proposer ses services. Le forum Emploi et Etudes est là pour ca.
    Il est parfaitement inutile de créer un topic pour demander un script, de l'aide sur phpBB.
 
A] Faq générale
 
    I)  Php, c'est quoi ?
    II)  Qu'est-ce qu'il me faut pour développer en php ?
 
B] Faq technique: le langage, les erreurs classiques, les remèdes
 
    I)  Headers already sent
    II)  Parse error in... leFichierPhp.php on line xxx
    III) Warning: mysql_fetch_xxx(): supplied argument is not a valid MySQL result resource in...  leFichierPhp.php on line xxx
    IV)  Mon code s'affiche dans le navigateur au lieu d'etre interpreté
 
C] Bonnes pratiques
 
    I) Coder avec la configuration la plus restrictive possible
    II) Separer les couches
 
===============
A] Faq générale
===============
 
I) Php, c'est quoi ?

 
II) Qu'est-ce qu'il me faut pour développer en php ?

 
===============
B] Faq technique: le langage, les erreurs classiques, les remèdes
===============
 
I) Headers already sent

 
II) Parse error in... leFichierPhp.php on line xxx

 
III) Warning: mysql_fetch_xxx(): supplied argument is not a valid MySQL result resource in...  leFichierPhp.php on line xxx

 
IV) Mon code s'affiche dans le navigateur au lieu d'etre interpreté

<?php
    phpinfo();
?>

 
===============
C] Bonnes pratiques
===============
 
I) Coder avec la configuration la plus restrictive possible

 
II) Séparer les couches

Liens utiles
Editeur de code pour windows: Télécharger Notepad++
Editeur de code pour Mac: Télécharger Textmate ( version d'eval 30j )

Installation d'un serveur Apache

Manuel Php en ligne
EDI sur Wikipedia
Model View Controller (MVC) - Architecture des applications PHP

Sujets abordés dans le topic

__autoload et spl_autoload_register: Pour inclure automatiquement les classes qu'on utilise
Entity.class.php: Pour gerer automatiquement des accesseurs
Mysqli + prepared statements: Alternative a PDO pour des requetes sécurisées et rapides
Includes + url_rewriting: Faire des includes sans faille de sécurité et rendre les url sexy

Un lien a rajouter dans ce topic ?

Depuis le temps que je l'attendais celle-la.
Bon, je me permet un p'tit reserved aussi pour y contribuer.

[edit]
Allez on attaque :

Les erreurs courantes :

parse error in... leFichierPhp.php on line xxx
Si vous obtennez ce genre d'erreurs, pensez en premier à relire le point A) II). Il vous faut impérativement un éditeur à coloration syntaxique pour éviter les erreurs les plus classiques. En effet Dieu a inventé la coloration syntaxique et il serait triste de s'en passer.

Et oui ce genre d'erreur vient, la plupart du temps, de fautes de frappe dans le code que vous avez saisis. Ces erreurs sont facilement repérabales à l'aide d'un bon EDI (Environnement de développement intégré).

Si l'erreur persiste, pensez à vérifier à la ligne précédente!
Par exemple, une erreur à la ligne 26 peut venir d'un ; oublié à la ligne 25!

Warning: mysql_fetch_xxx(): supplied argument is not a valid MySQL result resource in...  leFichierPhp.php on line xxx
Ceci n'est pas seulement valable pour MySQL. Mais comme c'est certainement le plus répandu chez les débutants, nous attaquerons par là!

Lorsque vous rencontrez ce genre d'erreur, et de manière plus générale, lorsqu'une requête ne change rien à votre base de données pensez à faire appel à la fonction mysql_error() juste après un appel à mysql_query(). Cette fonction vous en dit généralement plus sur l'erreur que vous avez comis lors de la saisie de votre requête en retournant une chaîne décrivant l'erreur en question.

Vous pouvez également tester votre requête dans un système d'aide à la gestion de votre base de donnée tel que phpMyAdmin dans lequel vous pouvez saisir directement votre requête et obtennir moultes informations sur les problèmes survenus lors de l'exécution de celle-ci.

Une section liens peut-être?
Edit :
Je transformerais : "Coder avec register_globals à off " par "Coder avec la conf la plus restricitve possible"
Détaillable en sous points.

* Pour les éditeurs sous nux, il y a Qanta si je ne me trompe pas. Tout le monde n'utilise pas VI ou Emacs
 
(moi chuis pas sous nux, mais j'utilise Emacs sous Windows et sous OSX )
 
* Pour Headers Already Sent, il y a aussi le problème du BOM UTF-8 qui, non reconnu par le parseur PHP, est envoyé au serveur web quand il est présent
 
* lé ligne -> la ligne
 
* répendu -> répandu
 
* La fin du post est cassée
 
* Il n'y a pas les A, B, C, I, II, III, IV, ... dans le post même, on s'y retrouve pas.

Avec mon enthousiasme du lundi matin, je pose la question désobligeante:
Vous pensez que ça va servir à qui ce topic?
 
Nan parce que :
1- 90% les questions PHP sont pas dans la cat PHP
2- 90% du temps les questions dans la cat PHP n'ont rien a voir avec le langage
Sur les 10% restants, 90% ne font jamais l'effort de lire la doc, pourquoi viendraient-ils lire ce topic?
 
Et sinon, j'emets comme une légère réserve sur le contenu de certains points...
 
Je ne critique pas l'initiative ou les efforts déployés, juste j'interroge

Nan mais ça c'est un topic pour pouvoir envoyer balader les gens en cat php avec un minimum de justifications
 
Sinon, faudrait ajouter une partie sur le typage des variables qui est très important même s'il est faible, la différence entre les classes V4 et V5, comment utiliser des exceptions au lieu de die() et puis des trucs de base genre comment fonctionne un cookie (cf ce post), les bases pour utiliser la DOM XML, GD ou encore la fonction mail (les questions qui reviennent souvent quoi)
 
PS : le coca chaud, c'est une horreur

réservé

Quelques idées de bonnes pratiques, inspirées de ce que j'ai lu dernièrement :
 
register_globals = off (obligation absolue)
 
Quand on travaille sur un script, toujours utiliser error_reporting(E_ALL); dans tous les autres cas display_errors = off et log_errors = on
 
Laisser tombre les long arrays au profit de $_GET, $_POST, $_SESSION, $_SERVER, $_FILES.
 
Laisser tomber opendir au profit de glob
 
Laiser tomber while(list($key, $val) = each($array)) au profit de foreach($array as $key=>$val)
 
Laisser tomber if($x == 'a'){}elseif($x == 'b'){}else{} au profit de switch($x){case 'a': break; case 'b': break; default:}
 
Dans pas mal de cas, laisser tomber fopen, fread et fclose au profit de file_get_contents() ou file() selon l'utilisation (idem pour fwrite et file_put_contents)
 
Très souvent, laisser tomber include() au profit de require_once qui est nettement plus rapide
 
Au sujet des types : pour tester si une variable existe, on utilise isset() et non empty() qui peut provoquer une E_NOTICE. Si on attend un nombre en entrée, c'est une excellente idée que de le préciser en utilisant (int)$_GET['nombre']; empty() c'est très bien  
 
Règle d'or : toujours se méfier de données fournies par l'utilisateur.
Même si un formulaire contient un <input type="text" maxsize="2" name="var">, il est possible que $_POST['var'] contienne un fichier MP3 de 3 Mo ... Ne jamais entrer de variable dans une base SQL ou un fichier si elle n'a pas été filtrée, que ce soit son type, sa taille, ou l'échappement des caractères spéciaux.

 
Ça dépend l'objectif, mais si on cherche du *.* je préfère encore scandir ou opendir/readdir selon le cas, perso.
 

 
Je dirais même au profit de require qui l'est encore plus, et qui permet de s'assurer qu'on n'a pas deux instructions d'inclusion là où une seule suffirait (évidemment, dans certains cas la version once est utile mais selon moi elle ne devrait être employée que lorsqu'on souhaite explicitement profiter de sa caractéristique). Enfin bref.
 

 
Jamais eu d'E_NOTICE avec empty(), tu dois confondre.

Dans la pratique, opendir pose trop de problèmes, en particulier trop de personnes demandent comment supprimer . et .. ; un autre avantage de glob est qu'il retourne des noms de fichiers avec chemin relatifs, donc prêts pour être utilisés avec d'autres fonctions sur les fichiers alors qu'avec opendir le chemin relatif doit être rajouté avant d'utiliser les noms de fichiers dans les fonctions ultérieures ce qui rend le code moins clair.
 

 
Je suis globalement d'accord avec toi, mais comme dans la majorité des cas un fichier n'a besoin d'être inclus qu'une seule fois, le _once est préférable par défaut ; sur SquirrelMail par exemple on a pu constater une baisse du temps de chargement de la configuration (de 30ms exactement sur les 250ms au total) en passant de include à include_once ; les résultats sont encore plus probants quand on utilise un accélérateur comme Zend, du fait que le script est inclus de manière statique dans le bytecode.
 

 
empty($_GET['test']); peut provoquer une notice si test n'est pas définie dans la requête GET, ça peut arriver par exemple dans un formulaire avec des checkbox qui ne sont pas définies dans la requete si elles ne sont pas cochées. De manière générale, pour un formulaire, il vaut mieux vérifier que tout est bien défini avec un isset en série (du type isset($_GET['name'], $_GET['firstname'], ...) et ensuite vérifier si certaines sont vides.
Erreur de ma part, empty est une structure de langage, aucun problème à l'utiliser.

Personellement, je ne suis pas trop fan non plus de glob. Maintenant je suis d'accord pour la conseiller à un débutant qui veut pas apprendre le php et se faire un "directory listing" en trois clic!

 
 
dites moi,
 
je code un nouveau site, et j'essaye de faire mon code de maniere "propre" et re-utilisable (genre pas comme mon premier site )
 
mais je ne veut pas pour autant faire un mvc, voici un exemple de mon code (il affiche un mini-chat sur le menu du site) :
 

 
est-ce que je me rapproche du modele mvc ? avec la separation des couches (1- requetes sql, 2-affichage) ? faut-il commenter plus ?
 
merci je veut faire du propre  

 
Ce que je voulais dire, c'est que si le once ne "fait pas de mal", l'utilisation de la version la plus restrictive quand on le peut permet de s'éviter des erreurs un peut bébêtes (qui seraient masquées dans le cas contraire). J'ai déjà vu des développeurs qui mettaient des require_once un peu partout n'importe comment, histoire d'être "sûr que c'est bien inclus" ; ça leur aurait probablement rendu service de ne connaître que require et de réfléchir un peu plus à l'"arborescence" de leurs fichiers.
 

 
Normalement non vu qu'un empty revient a priori à un isset($val) && $val != NULL/0/"0"/etc. J'ai déjà fait des tests empty sur des variables non définies sans soucis, en tout cas, maintenant je l'utilise trop rarement pour savoir s'il est buggé ou s'il a des cas particuliers.

Je souhaiterais retourner le compliment sur la lecture de doc à ceux qui tenteraient de l'étoffer
 
empty retourne un booléen et point, il envoit rien d'autre pas même un semblant d'erreur puisque c'est son boulot de te dire si quelque chose est vide (donc défini sinon c'est que c'est vide de toutes manières puisque ça existe pas )
 
Donc le mauvais exemple de dire utilisez isset() au lieu de empty() est vereux C'est tout le contraire, empty() fait un isset + un test sur le contenu, donc pour savoir si quelque chose est défini et/ou vide c'est empty(), pas besoin de se poser de question et le test est exhaustif.

Au temps pour moi, empty n'est plus une fonction mais bien un opérateur de langage, qui ne génère donc pas d'erreur sur des variables non définies. Faut que je faisse plus attention au changelog...

T'es pas fou, moi aussi fut un temps je faisais du isset && !empty, et y'avait forcément une bonne raison! Donc ça devait remonter quelque chose avant en effet, mais ça fait bien longtemps, c'est d'ailleurs ici qu'on me l'avait fait remarqué

 
Non, la séparation des couches passe principalement par une séparation réelle dans des fichiers différents. Le but c'est aussi le concept "separation of concerns" ; en fait on essaie définir des couches différentes pour chaque spécialité (HTML, SQL, etc...). Regardes sur le net du côté de "application N-tiers"
 
En gros ça donne (à la va-vite) :
 
1a - filtres divers sur la requête (ex: configurations, choix de la langue, parfois gestion du login)
1b - contrôle pour déterminer l'action à effectuer (peut être considéré comme un filtre, peut remplacer l'URL-rewriting)
1c - vérification des formulaires
1d - réalisation de l'action (utilise 2a)
1e - renvoie la réponse (utilise 2b
 
2a - modelisation, on parle aussi de business model (utilise 3)
2b - vues (en php on parle souvent de templates)
(je met les deux ensemble parce qu'ils sont à peu près au même niveau même s'ils n'ont rien à voir au niveau structure N-tiers
 
3 - DAO, accès aux données (utilise 4)
 
4 - persistence, donne un accès aux données en cachant la base de données et en gérant les transactions et autres détails du genre (utilise 5)
(le principe de la partie 4 est assez récent, j'ai jamais vu en php et peut être évité)
 
5 - bases de données (plusieurs bases possibles si la couche 4 est présente)
 
Séparation des couches, ça veut dire un fichier différent pour chaque point (et par objet à utiliser). Bon tu peux faire moins si tu veux pas un MVC complet mais il faut au moins essayer d'avoir 4 couches :
- contrôles généraux dont le choix des actions à effectuer
- model/gestion des formulaires/actions
- templates
- DAO
 
Voilà et surtout, évites de mettre du code HTML dans un code PHP, même avec des echo "<p>truc</p>"; C'est même pire. Le but quand tu développes, c'est de pouvoir maintenir/corriger/faire évoluer ton code rapidement. Celui qui a pour but d'avoir un site web qui marche rapidement, c'est pas le codeur, c'est celui qui paye pour avoir un site. Dans ton cas, tu sera quand-même plus du côté codeur ...

absolument pas

 
merci pour les conseils,
 
je vais essayer de voir ce que tu m'as dit =)

ma principale remarque concerne essentiellement la définition que tu donnes de php:

1- Dire de PHP que c'est un langage de script c'est un abus de langage. Dans le sens traditionnel, un script est une suite de programmes lancés dans un ordre défini. PHP est un langage interprété, ce qui n'en fait pas un langage de script.

2- pages dynamiques ça veut rien (ou tout) dire.  
Sauf erreur de ma part, l'appelation historique "html dynamique" c'est une invention crosoft ( dynamic html => dhtml) et désignait l'utilisation de js (puis de l'api DOM) pour modifier la page html après qu'elle ait été chargée.
On peut pas dire que ça s'applique à PHP.

3- l'exemple que tu donnes sur un traitement "lourd" n'est pas super. Il est tout à fait possible de lancer un traitement "lourd" détaché d'une requete HTTP sans passer par un accè SSH

Au rayon chipotage:
- Sur le nécessaire pour developper en php, un serveur web ne suffit pas. Je peux tout à fait installer WEBrick, c'est pas pour ça que ça supportera le PHP. Par contre y'a pas un mot sur l'interpréteur.

- Dans la FAQ, l'ordre est pas terrible. Il eut été plus logique de mettre l'erreur d'interprétation en premier, puis le parse erreur, puis les erreurs de langage.

- Je suis pas d'accord sur "l'obligation" de créer un header/footer dans le cadre d'une 1ere séparation des couches. Exemple simple: une page "centrale" qui accueille du contenu par include

- Il me semble qu'il serait interessant d'expliquer quelques bases du langage, par exemple:

• les strings (double et simple quote)
• l'absence de typage des variables

Enfin voilà
Je reprécise qu'il s'agit de critiques que j'espère constructives...

Pas mal cette FAQ je vais la recommander à tout le monde et m'empresser de lire certains points que j'ai omis
Le require_once me fait gagner un impressionant temps de calcul :]
Une question cependant : est-il bénéfique de fermer la connection sql à chaque fin de requête ?

Alors permet moi, à mon tour, d'émettre certaines reserves sur ce second point.
On parle de pages dynamiques et non pas de html. Et ça fait quand même une différence, suffisante pour ne pas confondre avec le "dhtml".
Et puis... par opposition à "pages statiques", quoi de mieu que d'employer le terme "pages dynamiques".
 

Par contre là je serais tenter de dire que ta remarque est plus que pertinante et qu'elle mérite une place plus importante que le rayon "chipotage".
Un débutant à quand même besoin de comprendre comment fonctionne le tout, donc serveur web, interprêteur et éventuel sgbd. C'est un point important pour comprendre tout ce qui se déroule quand une requête est envoyée au serveur.
D'autre par, pour interprêter du PHP, seul l'interprêteur est indispensable.

dgowsi> fait un google "pages dynamiques" et tu verras qu'on trouve de tout ( y compris un article d'openweb ). Ce que je voulais dire c'est que l'appelation est vague / abusif

Non mais je suis assez d'accord avec ce que tu dis, mais là ou je me pose une question c'est...
Si ça ne s'appel pas des pages dyamiques, alors... comment devrait-on appeler ça? Des pages... "changeantes"...?

générées dynamiquement pour le code html rendu? Interprêté dynamiquement pour le code php?

Quoique maintenant j'me pose plus la question de la réelle utilitée de pareil débat, mais bon...
Générées dynamiquement, définies comme étant statiques mais éventuellement dynamique par la suite?...
Pages dynamiques côté serveur, côté client on verra?
 
Bon je sort, c'est nimp'....

Perso j'ai également toujours vu employer le terme "page dynamique" pour désigner des pages HTML générées...dynamiquement xD ( via ASP, PHP, RoR, etc... ) par opposition aux "pages statiques", en HTML pur, dont le contenu ne change jamais ( a moins de réuploader le fichier bien sur )

C'est du chipottage pour différencier avec la merde que certains ont appelé dhtml, c'est tout...
 
Pas besoin de disserter là dessus, une page générée dynamiquement est dynamique, parce qu'une url donnée peut donner un résultat différent lié à la modification du système entre 2 appels. La limitation est le protocole http c'est tout!
 
Le dhtml c'est du vent, c'est rien ça n'existe pas, c'est juste des goodies grâce au JS qui en soit ne modifie rien mais donne une impression de variation sur clic, faudrait voir à ne pas confondre le client et le serveur, qu'une page gigotte côté client ça nous fait une belle jambe (quand t'en auras deux tu t'achèteras un short ), ce qui compte c'est le système donc le serveur et lui il envoit une page générée dynamiquement (on est d'accord sur le terme), mais qui par extrapolation est considérée comme dynamique tout court. A la vue de http elle l'est. A la vue du client elle l'est pas Qui a raison
 
Personne et tout le monde tant qu'on chippotera
 
Si on prend en compte le http, une page qui évolue entre 2 appels est dynamique, ça me suffit à moi Puisque c'est le fondement du web le http... Donc dans le contexte une page en php est dynamique, cqfd
 
 
Ce débat ne sert à rien puisque c'est du quequettage sur une définition sans prendre en compte le système complet.  
Dans le sens général, il est impossible d'avoir une page dynamique sur un navigateur

Je sais pas à qui est destiné ce gros paté leflos, mais grosso modo tu dis ce que je disais depuis le début: "page dynamique ça veut rien (ou tout) dire"

Mais ce morceau de démonstration ne tient pas vraiment debout, dans la mesure ou je peux avoir une script php qui produit toujours le même résultat html ( juste un print), ou une page html qui n'affiche jamais la même chose ( suppression de noeud aléatoire sur le onload).

cherchez l'erreur

Si le code php génère un truc statique il faut se demander si on a fait le bon choix
L'autre exemple se rapproche de cette appellation fourre tout de dhtml.
 
Rien de bien pas logique dans ça
 
Quand je dis entre 2 appels, c'est tout confondu, même entre 2 visiteurs, header envoyés, vérification de droits d'accès... Même si ça change pas au final entre 2 accès, il se passe d'autres choses Contrairement à un truc qui est pas généré dynamiquement ou modifié côté client.