Tout comme la dernière fois, je commence par citer les références de l’article  :

  • Titre "Programmer en PHP pour dynamiser son site Web",
  • PC Expert n°143 juin 2004 p.111 à 113,
  • Sommaire du numéro sur le site de PC Expert (lien pas encore actif au moment ou je publie ce billet),
  • il s’agit de la seconde partie d’une série d’articles portant sur PHP et comptant 4 parties.

On commence par le HTML. Je sais parfaitement que le formulaire s'affichera correctement dans un navigateur et vous allez vous demander pourquoi se compliquer la vie puisque ça fonctionne tel quel. Tout simplement parce que des conventions existent et servent à faire en sorte que tout le monde, sans exception et quel que soit le navigateur utilisé, puisse accéder à une page HTML dans de bonnes conditions et puisse remplir le formulaire proposé (ce qui est le thème de cet article). Par conséquent, un simple test effectué en utilisant le validateur de code HTML du w3c aurait indiqué 4 erreurs, lesquelles, une fois corrigées auraient permis d'améliorer les choses :

Et tant qu'à faire on pouvait encore faire mieux :

  • l'utilisation de balises <br> en excès est inutile,
  • le formulaire n'a pas besoin d'être intégré dans un tableau HTML (Pour en savoir plus : la mise en page par tableaux),
  • l'utilisation de <label> n'est pas superflue.

La lecture de l'article d'Eric Daspet (expliquant commen rendre un formulaire accessible) est donc recommandée, l'utilisation des CSS est également souhaitable. Il est vrai que ce n'est pas non plus le but de l'article, mais il me semble que si on est suffisamment rigoureux sur ce point là, ça ne peut qu'être bénéfique pour la suite. De plus, c'est formateur de montrer qu'il est très simple d'arriver à avoir un contenu valide d'une part, mais accessible également.

Ensuite le PHP : malheureusement, le bilan est également négatif, ce qui est logique puisque le manque de rigueur concernant la partie HTML se retrouve au niveau du code PHP. On se rend compte que l'auteur ne devait pas utiliser register_globals = off dans son article. Quelques liens utiles à ce sujet (sans doute redondant, mais très complet) :

Les erreurs que j'ai pu relever sont les suivantes :

  • $_POST est à préférer à $HTTP_POST_VARS, ce qui est effectivement fortement conseillé, mais l'explication donnée n'est pas claire et donne l'impression qu'il s'agit d'une mode. D'ailleurs, l'auteur n'a pas complètement assimilé ce fait, puisqu'à la fin de l'article il réutilise $HTTP_POST_FILES et $PHP_SELF au lieu d'utiliser respectivement $_FILES et $_SERVER['PHP_SELF'] (je vous renvoie donc encore vers les liens cités au-dessus)
  • Les balises d'ouverture, indiquant le début du code PHP, ne sont pas forcément les bonnes. Si <?php est effectivement utilisé en début de script, on passe assez facilement à <?= sans aucun explicatione (pour en savoir plus : Pourquoi il ne faut pas utiliser les balises courtes ?, La syntaxe de base, ou encore short_open_tag pour la configuration).
  • les tests des variables $_POST ne sont pas effectués correctement. Si vous travaillez avec le réglage de php.ini suivant (et normalement recommandé en local) : error_reporting = E_ALL (plus de détails : error_reporting, Gestion des erreurs) , vous aurez le plaisir d'être devant plusieurs erreurs classiques du type Notice : Undefined index: email in .... Ceci est normal puisque le script PHP permettant la vérification du formulaire, placé avant le formulaire (en début de fichier donc), ne teste même pas si les variables existent (ou alors le fait, mais mal). Pour compléter mes propos, je vais utiliser le premier test de variable (et le seul test de variable) effectué de la façon suivante (je cite le script) : if($_POST['submit']). Ceci provoque une jolie erreur d'index (submit ici) inexistant. L'utilisation de empty par exemple n'était pas superflue. Bien sur, le cas ou $_POST['submit'] n'existe pas n'a pas été testé. Conséquence : une variable, dont le but est d'afficher les erreurs, n'existe pas non plus, car elle n'a pas été initialisée.
  • La gestion des champs obligatoires est à revoir également à mon sens : dans le formulaire il existe un input de type hidden ayant pour valeur (je cite) nom,email,message, ce qui oblige à effectuer un traitement (via explode) sans doute inutile...
  • L'envoi de l'email, après validation du formulaire, pose problème puisqu'un index n'existant pas a été utilisé. La variable, correspondant au nom de la personne insérée dans le formulaire, change de nom : on passe de $_POST['nom'] à $_POST[name] (notez au passage la disparition des guillemets, sans que ceci soit expliqué).
  • La vérification de la validité de l'adresse email est basique, puisqu'elle consiste à vérifier la présence de @ et du point (.)... une expression régulière (des exemples sont visibles sur l'excellent site expreg.com) aurait été la bienvenue, mais on aurait sans doute augmenté inutilement la difficulté de l'article.
  • Enfin, cerise sur le gâteau, aucune vérification de ce qui a été inséré dans le textarea n'est effectué...

En conclusion, j'espère que les 2 épisodes suivant de la saga PHP de PCExpert consistent à améliorer ce premier script en incluant l'utilisation des expressions régulières, la gestion des erreurs, et, soyons fou, la manipulation d'objets en PHP (POO).