Connexion à la base de données

Pour pouvoir exécuter des requêtes SQL, il faut que votre script PHP soit connecté à une base de données : voir le TP mysqli - connexion aux bases de données.

Sélectionner des données et les afficher dans le navigateur

Les requêtes suivantes sont basées sur cette table SQL, permettant de stocker des utilisateurs :
user (usr_id, usr_login, usr_pwd, usr_naissance, usr_mail_confirme, usr_taille);

Et voici un code PHP qui affiche l'ensemble des utilisateurs :

Et le résultat dans le navigateur est :

Quelques explications :

• $rs_users est une variable que vous nommez comme vous voulez. C'est le résultat de la requête : une ressource qui contient un jeu d'enregistrements (chaque enregistrement renvoyé par le select).
• fetch_assoc() est une fonction qui reçoit en paramètre un jeu d'enregistrements et renvoie successivement chaque enregistrement. Quand elle arrive au bout du jeu d'enregistrements, elle renvoie le booléen false. Ses petites soeurs : fetch_array(), fetch_object()
• $user va donc prendre successivement la valeur de chaque enregistrement, sous forme de tableau PHP, où chaque indice représente un champ de l'enregistrement (par exemple : $user["usr_login"] vaut 'spastore').

Ajouter une gestion d'erreurs

La gestion d'erreurs que l'on va rajouter permet d'afficher une éventuelle erreur dans la requête SQL. On parle bien d'erreurs SQL et non pas d'erreurs PHP, qui normalement sont déjà prises en charge.

Très souvent vous aurez des erreurs à cause de vos requêtes SQL. Si vous ne rajoutez pas la gestion d'erreurs vous passerez un temps énorme à diagnostiquer des erreurs SQL, même évidentes.

Voici un rappel sur la gestion d'erreurs (qui a été présentée en détail dans le cours INSERT) :

Protection des données à l'affichage

Souvent on réaffichera des données qui ont été saisies par nos internautes (messages, login, commentaires, texte d'une annonce, etc.)

Là, la méfiance s'impose. Les internautes peuvent en effet très facilement saisir des textes qui vont perturber vos affichages, le plus gênant étant la possibilité de rediriger votre page vers la page de leur choix avec ce genre de saisie :
(remarque : depuis 2016, les navigateurs protègent contre ce genre de redirection) :

Et voici comment grâce à htmlspecialchars, on se protège de cette insertion de balies HTML dans les textes des internautes :

Pourquoi je ne protège que le login mais ni le usr_id ni la date de naissance (usr_naissance) ?

• Si le usr_id est de type numérique dans la base de données, il ne pourra jamais contenir de textes HTML susceptibles de perturber notre affichage.
• Pareil pour la date de naissance : quoi que saisisse l'internaute, si elle est au format DATE dans la base de données, aucun code HTML ne sera stocké.
• Il ne faut donc protéger que les champs de type char, varchar, text et dérivés (tinytext, longtext, etc.).

Protection des guillemets avec real_escape_string

Une requête peut planter si l'internaute saisi un guillemet simple (ou double, selon le délimiteur choisi dans la requête) dans un des champs de saisi. Par exemple, les requêtes suivantes vont planter :

On obtient alors l'erreur SQL suivante :

On évite cette erreur en échappant les guillemets, ici grâce à la méthode real_escape_string :

La requête SQL ne plante plus, car elle est devenue (remarquez l'échappement du guillemet simple : ' est devenu \') :

Quelques fonctions très utiles associées au SELECT en PHP

Après avoir exécuté une requête de sélection, vous aurez très souvent besoin de num_rows qui compte le nombre d'enregistrements dans un recordset

Si vous savez que votre jeu d'enregistrement ne contient que 0 ou une ligne (par exemple lors d'une authentification), le while est inutile, un if suffit :

Mise en pratique