Le Journal de Nikrou - PHP

Encore une migration...

Nicolas — Tue, 09 Jan 2024 16:39:00 +0100

En ce début d'année, après une première migration, puis une deuxième et une troisième, j'ai de nouveau migré mon serveur dédié sur une nouvelle machine, avec plus d'espace disque, plus de mémoire, plus de performance processeur et pour moins cher. Que demander de plus ?

J'en ai profité pour passer postgreSQL de la version 14 à la version 16. Au passage, la configuration est un peu plus stricte et je suis tombé sur un message un peu abscon :
user does not have a valid scram secret

Le mot de passe de l'utilisateur était trop simple ou plus exactement, l'algorithme pour chiffrer le mot de passe était trop simple. Jusqu'à présent c'était md5. PostgreSQL conseille très fortement un algorithme scram-sha-256.

Pour cela il suffit, par exemple de se connecter au serveur avec la commande psql et pour chaque mot de passe n'utilisant pas le bon algorthme de taper :

postgres=# \password NOM_DU_ROLE

puis en réponse de taper le mot de passe et la confirmation.

Phyxo et PHP 8

Nicolas — Sun, 30 May 2021 13:58:00 +0200

Phyxo fonctionne sans aucun soucis avec PHP 8, sorti au mois de novembre 2020. Phyxo nécessite php 7.3 au minimum. D'ailleurs je vais changer ce minimum et passer à php 7.4 à minima car le support actif de php 7.3 s'est arrêté au mois de janvier 2021. La version 7.3 ne reçoit plus que des patchs de sécurité et va arriver en fin de vie à la fin de 2021. On peut voir toutes les versions supportées sur le le site officiel.

La version 8 de PHP apporte de nombreuses nouveautés. Une évolution pose un petit problème : l'ordre des paramètres d'une fonction ou d'une méthode. PHPStan se plaint car le code de Phyxo contient de nombreuses méthodes dont certains paramètres obligatoires suivent des paramètres optionnels. Un exemple valant mieux qu'un long discours voici une méthode qui fait râler PHPStan :


public function findRandomImages(array $forbidden_categories = [], int $max): array
{
   // code de la méthode
}

Ce code fonctionne parfaitement. Mais si on exécute ce code avec PHP 8, on a en retour le message suivant :

Deprecated: Required parameter $max follows optional parameter $forbidden_categories

Cet avertissement dénote un problème de logique dans le prototype de la méthode. Si la méthode accepte que le paramètre $forbidden_categories soit non défini alors il doit être après le paramètre obligatoire $max. C'est le sens du message d'avertissement renvoyé.

Atoum ou PHPUnit ou les deux ?

Nicolas — Sun, 04 Apr 2021 17:42:00 +0200

Depuis que j'ai commencé le développement de Phyxo, j'ai utilisé Atoum pour faire des tests unitaires. J'aime l'approche plus "moderne" de la façon d'écrire les tests. Mais depuis quelques temps je commence à écrire des tests fonctionnels de mes contrôleurs et du coup, j'utilise aussi PHPUnit.

J'ai essayé d'utiliser AtoumBundle pour tester mes contrôleurs mais le projet a l'air mort ou tout du moins pas très actif : le dernier commit date de presque 3 ans et ne supporte que symfony/framework-bundle en version 2.0 ou 3.0. Du coup j'ai laissé tomber cette possibilité.

Travailler simultanément sur plusieurs branches d'un même dépôt git

Nicolas — Thu, 01 Apr 2021 17:31:00 +0200

Dans le cadre du développement de Phyxo, il m'arrive de devoir travailler sur plusieurs branches en même temps pour de multiples raisons :

vérifier "visuellement" que n'ai rien cassé entre deux versions
vérifier un comportement que je trouve étrange sur la version en cours de développement et m'apercevoir que le comportement était le même sur une branche précédente
exécuter les tests fonctionnels (en utilisant Behat) d'une branche sur le code d'une autre branche

Ce ne sont que quelques cas d'usage. Tous ces cas peuvent être gérés simplement en clonant plusieurs fois le dépôt de Phyxo et ça fonctionne parfaitement mais il y a beaucoup mieux : la commande git worktree. Cette commande permet de gérer plusieurs copie de travail à partir du même dépôt git.

Par exemple si j'ai un clone sur la branche master et que je veux en même temps bosser sur la branche new-feature, il me suffit de taper la commande suivante :

$ git worktree add ../phyxo_new-feature new-feature

La commande va créer une nouvelle copie de travail du dépôt dans le répertoire ../phyxo_new-release en se positionnant sur la branche new-feature. Pour chaque branche c'est comme si on avait un projet différent sur disque. On peut vérifier que notre nouvelle copie de travail a été créée en tapant la commande suivante qui liste toutes les copies de travail :

$ git worktree list

/var/projets/git/phyxo              8a8bae91f [master]
/var/projets/git/phyxo_new-feature  699393471 [new-feature]

Il y a de nombreux avantages à utiliser git worktree plutôt que de faire un git clone : elle est plus rapide (les données sont déjà là), utilise des liens. C'est une copie light du dépôt d'origine et qui prend bien moins de place sur disque.

Et pour finir de convaincre, d'autres exemples d'utilisation :

travailler sur une branche sans impacter le travail en cours sur la branche courante. On peut par exemple utiliser git stash pour mettre de côté des modifications sur la branche courante et corriger un bug sur la version en production. Mais ces deux branches peuvent avoir beaucoup de différences. Mon IDE va devoir reconstruire ces index pour pouvoir me proposer de l'aide. Les dépendances ne sont pas forcément les mêmes, ni dans les mêmes versions. Il va falloir que je n'oublie pas de faire un composer install.
vérifier que le projet fonctionne sur une installation "propre" comme si je venais de cloner le dépôt.

Mettre à jour les traductions d'un module drupal

Nicolas — Thu, 10 Feb 2011 13:56:00 +0100

Lorsqu'on développe un module drupal, les traductions ajoutées au fur et à mesure ne sont pas prises en compte automatiquement. drupal ne prend en compte les traductions d'un module que lors de l'installation de celui-là. En cours de développement cela peut rapidement devenir pénible (pour rester poli !) de devoir installer/déinstaller le module à chaque mise à jour...

Heureusement il y a une solution pour se faciliter la vie. En fait c'est d'une bêtise insondable : il suffit d'utiliser le mécanisme de mise à jour d'un module. Pour ce faire, dans le fichier mon_module.install, on déclare une fonction mon_module_update_N, où N est incrémenté à chaque nouvelle mise à jour.

Cette façon de faire est généralement utilisé pour mettre à jour le schéma de la base de données mais on peut aussi l'utiliser pour mettre à jour les traductions de la manière suivante :

function mon_module_update_N() {
   $ret = array();
   if (module_exists('locale')) {
      locale_system_update(array('mon_module'));
      $ret[] = array('success' => true, 'query' => 'New translations were imported.');
   }
   
   return $ret;
}

Pourquoi faut-il bannir l'arobase de tout code PHP ?

Nicolas — Sat, 26 Jun 2010 15:07:00 +0200

Nombreux sont les développeurs (débutants ou non) qui utilisent l'arobase (@) pour masquer les erreurs. C'est un peu cacher la misère et c'est surtout un énorme problème lorsqu'il s'agît de trouver un bug dans un code où fleurissent les arobases.

L'arobase est un opérateur de contrôle d'erreur. Si on préfixe une expression (affectation de variable, include ou require, expression de comparaison,...) par cet opérateur, les messages d'erreurs qui pourraient éventuellement être générés sont ignorés et par conséquent ne sont pas affichés. C'est de là que vient le problème. Les débutants ne maîtrisant pas tous les concepts du langage utilisent l'arobase pour arriver plus vite à leurs fins. On ne peut pas les blâmer mais le remède est pire que le mal !

Le principal problème de cet opérateur est qu'il ne masque pas que le problème que l'on a sur le moment. Il masque toutes les erreurs dont les erreurs critiques qui stoppent le programme. Par exemple, si une variable ou une fonction est mal orthographiée, on ne le saura pas.

Voici un exemple de code à ne pas reproduire qui produirait sans l'arobase un message d'avertissement "Notice Undefined index var ..." :

$ma_var = @$_GET['var'];

Si la variable $_GET['var'] n'existe pas, on ne le saura pas et on devra faire le test ultérieurement. Donc autant tester directement :

if (isset($_GET['var'])) {
   $ma_var = $_GET['var'];
} else {
   $ma_var = '';
}

Dans l'exemple précédent il y a peu de conséquences. Imaginons que l'on veuille inclure un fichier de configuration que s'il existe. Une mauvaise pratique serait de préfixer l'inclusion par un arobase :

@include 'conf.inc.php';

De prime abord on pourrait penser qu'on a atteint le but souhaité. Si le fichier n'existe pas, on n'aura pas d'erreurs ; dans le cas contraire il sera inclus. Pour rendre les choses plus claires imaginons le code suivant :

$nom = 'Pouce';
$prenom = 'Tom';
@include 'conf.inc.php';
echo "Bonjour $prenom $nom";

Et voici le contenu du fichier conf.inc.php :

$prenom = 'Nicolas';
$nom = 'Cémoi';

Bon l'intérêt de ce code est plus que discutable mais en revanche il va permettre d'expliquer plus clairement mon propos. Si le fichier existe, et que le script courant peut l'inclure alors on aura le super message : "Bonjour Nicolas Cémoi". Si le fichier n'existe pas on aura le message : "Bonjour Tom Pouce". Jusque là tout va bien.

Maintenant supposons que le fichier soit bien là mais qu'il y ait une erreur dans le fichier conf.inc.php, par exemple qu'il manque le point virgule à la fin de la première ligne. On n'aura aucun message d'erreur, mais comme l'erreur est critique l'exécution du script s'arrête et on n'a pas de message du tout. L'exécution du script s'arrête à la ligne où on tente de faire l'inclusion du fichier. L'arobase a masqué l'erreur de syntaxe "Parse error: syntax error, unexpected T_VARIABLE ...". L'exemple est très simple et on ne fait appel qu'à deux fichiers mais si on fait de nombreuses inclusions, et/ou des inclusions en cascade, trouver le problème devient un vrai casse-tête.

Encore une fois, le code pour éviter le problème est d'une simplicité enfantine :


if (file_exists('conf.inc.php')) {
   include 'conf.inc.php';
}

L'utilisation de l'arobase est une très mauvaise pratique qui est à bannir. Elle crée plus de problèmes qu'elle n'en résoud.

Il y a tout de même des exceptions à cette pratique : si on teste l'erreur. Par exemple lorsqu'on veut créer une connexion à une base de données pour ne pas afficher d'erreur si un problème survenait, on peut utiliser l'arobase devant la fonction pg_connect() (ou mysql_connect() ou ...). Il faut bien entendu ensuite tester le retour de la fonction qui est soit false soit une ressource de connexion.

symfony : hydrater un objet à la main

Nicolas — Fri, 17 Apr 2009 17:49:00 +0200

En utilisant symfony, on ne fait plus réellement de sql du fait de la couche d'abstraction ORM (Propel ou Doctrine). On ne travaille qu'avec des objets. Cela facilite grandement la vie et contribue pour une grande part à la rapidité de développement. Mais cela ne répond pas toujours à tous les besoins...

Imaginons un modèle Script ayant une propriété category qui permet de classifier les différents scripts par catégorie. Si je veux récupérer toutes les catégories de scripts, le code que je vais écrire pourrait ressembler à ça :


public static function getCategories() {
   $criteria = new Criteria();
   $criteria->addGroupByColumn(self::CATEGORY);
   
   return self::doSelect($criteria);
}

J'aurais pu aussi faire un "select distinct catgeory" mais pour les besoins suivants j'ai préféré faire un "group by". Je voudrais maintenant pour chaque catégorie de scripts savoir combien de scripts y sont associés pour afficher dans un menu. Toute ressemblance avec un menu existant n'est pas purement fortuite; mais c'est une autre histoire !

La requête sql serait toute simple :
select category, count(*) as c from scripts group by category;

Il n'est pas possible de faire la même chose en tout objet. Il va falloir hydrater les objets résultats "à la main". On va commencer par ajouter la propriété count à notre object Script, ainsi que les méthodes pour renseigner (setCount) et récupérer (getCount) cette nouvelle propriété:


class Script extends BaseScript
{
  protected $count = 0;

  public function setCount($n) {
    $this->count = $n;
  }

  public function getCount() {
    return $this->count;
  }  
}

Voici maintenant le code pour symfony 1.2.* qui va permettre d'hydrater (c'est-à-dire de transformer chaque ligne de résultat en un objet Script :


  public static function getCategories() {
    $criteria = new Criteria();
    self::addSelectColumns($criteria);
    $criteria->addGroupByColumn(self::CATEGORY);
    $criteria->addAsColumn('cnt', 'COUNT(*)');
    
    $stmt = self::doSelectStmt($criteria);    
    $scripts = array();

    while ($row = $stmt->fetch(PDO::FETCH_NUM)) {
      $script = new Script;
      $col = $script->hydrate($row);
      $script->setCount(($row[$col] !== null) ? (int) $row[$col] : null);
      $scripts[] = $script;
    }

    return $scripts;
  }

Le code pour symfony 1.0.* et plus généralement les versions inférieures à 1.2 est légèrement différents car symopfy 1.2 se base désormais sur PDO:

Il va falloir remplacer la ligne :

$stmt = self::doSelectStmt($criteria);

par

$row = self::doSelectRs($criteria);

Et la ligne :

while ($row = $stmt->fetch(PDO::FETCH_NUM)) {

par

while ($row->next()) {

Envoyer des mails avec php

Nicolas — Sun, 16 Sep 2007 21:35:53 +0000

Quoi de plus simple que d'envoyer des mails avec php avec la fonction mail ! Les choses se compliquent légèrement si on n'a pas de serveur de mail ! Et c'est peu de le dire. Evidemment on peut se lancer dans l'installation d'un serveur de mail (sendmail ou postfix par exemple) mais ce n'est pas à la portée de monsieur tout le monde si on ne veut pas servir de relais de spam! Une solution simple: nullmailer

Hier en voulant tester le module d'envoi de mail de mon application utilisant symfony, je me suis apperçu que je ne pouvais pas envoyer de mail pour tester ! Ne voulant pas installer un serveur de mail j'ai installé nullmailer:

Après un apt-get install nullmailer, les trois-quarts du boulot étaient faits. L'installeur pose deux questions:

Nom de courrier de votre système ?
Machines relais ?

A la première question, j'ai répondu free.fr et à la deuxième j'ai répondu smtp.free.fr smtp.

Le serveur de mail (qui n'en est en fait pas un ^[1]!) se lance et après ça marche!!!

Il ne reste plus qu'à modifier la configuration de php pour qu'il utilise nullmailer au lieu de chercher en vain sendmail ! J'ai juste modifier le sendmail_path: sendmail_path = /usr/bin/nullmailer-inject -fmoi@free.fr

La modification de la configuration de php ne me plait qu'à moitié et je pense que je vais écrire un wrapper pour ne pas avoir à la modifier.

Notes

[1] Et oui contrairement à ce qu'on pourrait croire nullmailer n'est pas un serveur de mail. Ce n'est qu'un MTA. Il ne fait que transférer les messages à un autre MTA ou à un MDA qui se charge de l'envoyer à destination.

Mettre fin à une authentification http

Nicolas — Mon, 02 Oct 2006 10:06:00 +0000

Le but du jeu est de mettre fin à une authentificaiton http faite avec le mécanisme des fichiers .htaccess

Tout le monde connait l'authentification http fournie par apache que l'on met en place aisément avec un fichier .htaccess. Vous trouverz tous les détails sur la doc d'apache. Ce type de protection a l'avantage d'être standard mais aussi de protéger tout le contenu d'un répertoire, contrairement aux sessions php.

Mais la question que l'on se pose est comment mettre fin à cette "session" ? Une solution pour le moins bancale est de proposer au visiteur de fermer son navigateur. On oublie tout de suite. Les visiteurs utilisant firefox et l'extension web developer peuvent le faire aussi aisément sans fermer leur navigateur en cliquant sur:

Miscellaneous > Clear Private Data > Clear HTTP Authentification.

Cette solution n'est pas non plus une solution satisfaisante. Tout le monde n'utilise malheureusement pas encore firefox!

Il n'y a alors pas de solution comme nombreux le prétendent (ils se reconnaitront et ne resteront peut-être pas dans leur ignorance!), allant jusqu'à me modérer parce que j'avais l'affront de prétendre que c'était possible. C'est dur de reconnaitre que l'on a tort et c'est plus facile de ramener la cavalerie pour essayer d'enfoncer la personne qui met un coup de pied dans la fourmillière.

Revenons à nos moutons. Imaginons que nous voulions protéger un répertoire de données confidentielles. En supposant que la configuration d'apache nous y autorise - c'est-à-dire qu'il n'y ait aucun AllowOverride None, il suffit de placer dans le répertoire un fichier .htaccess contenant:

AuthType Basic
AuthName "Private Access By Invitation Only"
AuthUserFile /absolute/path/to/pass.db
Require valid-user

Ce type de protection n'est pas conseillé. On ne met pas le fichier de mot de passe dans le répertoire à protéger; c'ets juste pour la démonstration!

Il faut ensuite créer un fichier de mot de passe avec l'utilitaire htpasswd. J'y ai placé l'identifiant nico avec comme mot de passe nico. On va placer dans ce répertoire un fichier test.php nous donnant le couple identifiant/mot de passe que l'on a entré. Ce couple est accessible à travers le tableau $_SERVER au moyen des clés PHP_AUTH_USER et PHP_AUTH_PW. Je vais aussi créer un script logout.php qui va permettre de mettre fin à cette authentification http. Cette déconnexion se fait en envoyant au navigateur un code http 401 (authentificaiton requise), le même code qu'apache envoie au navigateur à la première tentative d'accès au répertoire. Le code ressemble à ceci:


<?php 
header('WWW-Authenticate: Basic realm="Private Access By Invitation Only"');
header('HTTP/1.0 401 Unauthorized'); 
echo 'Texte affiche en cas d\'annulation'; 
exit();
?>

Vous pouvez maintenant aller voir mes données confidentielles (login: nico mot de passe: nico). Déconnectez-vous, désormais vous ne pouvez plus voir les données confidentielles. Vous pouvez cliquer sur annuler si ça vous chante mais vous serez tout de même déconnecter! N'essayer pas directement d'accéder au répertoire car vous auriez un accès non autorisé car par défaut ma configuration n'autorise pas de lister les répertoires (Options -Indexes)

Notez bien que le realm doit être le même que celui déclaré dans le .htaccess!

Qu'est-ce qu'un singleton ?

Nicolas — Sun, 28 May 2006 14:28:39 +0000

Le singleton est un modèle de conception (design pattern pour les grands bretons). En clair c'est une façon éprouvée de résoudre un problème. Avec le sinleton on cherche à n'avoir qu'une seule instance d'un même objet.

L'implémentation de l'objet singleton consiste à créer une instance de l'objet uniquement si elle n'existe pas encore. On stocke l'instance unique dans une propriété statique de l'objet. Cela peut donner quelque chose comme cela:


<?php
class Singleton {
  private static $instance = null;
  
  private function __construct() {
  }

  public static function getInstance() {
    if (self::$instance==null) {
      self::$instance = new Singleton();
    }
    return self::$instance;
  }
}
?>

La théorie c'est bien joli mais j'entends déjà les questions fuser: à quoi ça sert et comment on s'en sert ? Pour répondre à la première question, je dirais qu'à chaque fois que l'on a besoin d'un objet qui doit rester unique, on utilise un singleton. Je pense par exemple à une classe de log ou une classe de debbugage.

Pour la deuxième question, voici la façon de récupérer l'instance unique:


<?php
$instance1 = Singleton::getInstance();
echo '<pre>Instance n°1:', var_dump($instance1), '</pre>';

$instance2 = Singleton::getInstance();
echo '<pre>Instance n°2:', var_dump($instance2), '</pre>';
?>

En exécutant ce code, on obtient:

Instance n°1:object(Singleton)#1 (0) {
}

Instance n°2:object(Singleton)#1 (0) {
}

#1 est une référence vers l'instance. Dans les deux cas on a la même, ce qui est le but recherché. Au prochain épisode je vous donne un exemple concret!

Faut-il utiliser $_REQUEST ?

Nicolas — Fri, 26 May 2006 11:14:49 +0000

Depuis que je suis tout petit, j'utilise $_GET pour les données provenant de l'url et $_POST pour celles provenant de mes formulaires (utilisant la méthode "post"!).

En lisant divers articles, je me demande si je ne prends pas un peu la tête et si je ne devrais pas utiliser $_REQUEST quelle que soit la provenance des données. Peu importe la provenance, de toute façon il faut filtrer, vérifier, contrôler la cohérence de ces données.

Pour commencer par le commencement, $_REQUEST est un tableau associatif constitué du contenu des variables $_GET, $_POST, $_COOKIE.

Nombreux sont ceux qui se disent au premier abord que cela est vraiment important de pouvoir distinguer la provenance des informations. Si l'utlisateur envoie les données par l'url (méthode "get") ou via un formulaire utilisant la méthode "post" qu'est-ce qui est le plus important ? La façon de recevoir les données ou les données elles-même ? Pour ma part je pense que la façon de recevoir les données n'a aucune importance. L'important est de bien contrôler ce que l'on reçoit et de ne faire confiance à aucune donnée même celles qui pourraient sembler anodines et non modifiables telle que $_SERVER['PHP_SELF'] ^[1]. Du coup l'utilisation de $_REQUEST serait plutôt déconseillée aux débutants qui ont déjà du mal à bien faire la différence entre $_GET et $_POST. Ceux-ci se contentent généralement de peu de vérifications sur les données transmises via la méthode "post"; ces données leur semblent sûres. Je ne parle même pas des cookies!

On pourrait se dire que l'utilisation de $_REQUEST pourrait être intéressante pour les cas où on laisse le choix aux utilisateurs de transmettre les données en utilisant la méthode "get" ou la méthode "post". La gestion de la provenance des données serait ainsi transparente.

Je vois un réel intéret d'utiliser $_REQUEST pour le cas où je veux continuer une session valide sans dépendre de la configuration du serveur, c'est-à-dire sans se demander de quelle manière transite l'identifiant de session (soit par cookie, soit par l'url soit par un champ caché d'un formulaire) alors au lieu d'utiliser une cascade de if pour savoir d'où vient l'identifiant je peux utiliser un code tel que:


<?php
if (isset($_REQUEST[session_name()])) {
  session_start();
}
?>

Pour conclure je ne suis pas complétement convaincu d'utiliser ce tableau magique qu'est $_REQUEST surtout si on se réfère à l'utilisation des méthodes "get" et "post" et sur une architecture REST d'une application web. Les méthodes "get" et "post" sont bien distinctes et donc récupérer les données sans en connaitre la provenance leurs fait perdre un peu de leur sens.

[1] Je m'égare; ce sera l'objet d'un prochain billet. Oui j'ai honte de faire du teasing!

Ne pas réinventer la roue.

Nicolas — Sat, 06 May 2006 22:48:00 +0000

On répète souvent que lorsqu'on fait un script il ne faut pas réinventer la roue et utiliser au maximum les fonctions natives du langage. Cela a de multiples avantages: c'est optimisé, sans bug,... Mais on n'imagine pas toujours lorsqu'on est débutant à quel point cet adage doit être pris au sérieux!

Prenons un exemple concret pour éclairer le débat. Imaginons deux tables sql liées entre elles par un identifiant numérique:

table1: id, champ1, champ2
table2: cid, champ3

Si on n'utilise mysql comme base de données on va utiliser en général un entier auto-incrémenté comme clé primaire de la première table et on va se servir de cet indentifiant comme clé étrangère dans l'autre table. On fait l'insertion d'un enregistrement dans la première table:

insert into table1 (champ1, champ2) values('valeur1', 'valeur2');

Jusque là tout va bien. Comment récupérer cet identifiant nouvellement créé ? La première solution qui vient à l'esprit est de récupérer le plus grand identifiant de la table1:

select max(id)as max_id from table1;

Le résultat obtenu risque de ne pas être le résultat escompté: il se peut qu'une nouvelle insertion intervienne avant que l'on récupère l'identifiant. Si le site n'a que 3 visiteurs par mois le risque que cela arrive est faible mais non négligeable pour un site à fort traffic. Ce n'est pas la bonne méthode: il faut utiliser la fonction mysql_insert_id(). Cette fonction récupère l'identifiant auto-incrémenté lié à la dernière insertion, pour la connexion courante.

Essayons de prouver cela avec les deux scripts suivants en simulant une insertion parasite:


<?php

// script n°1 basé sur mysql_insert_id():
$mysql_link=mysql_connect($host, $user, $password);
mysql_select_db('db', $mysql_link);

$query_max = "select max(id) as max_id from table1";
printf('Plus grand id de la table: %d<br>', 
       current(mysql_fetch_assoc(mysql_query($query_max, $mysql_link)))
       );

$query = "insert into table1 (champ1, champ2) values('value1', 'value2')";
$result = mysql_query($query, $mysql_link);
printf('id inséré: %d<br>', mysql_insert_id($mysql_link));
?>


<?php

// script n°2 basé sur le max:
$mysql_link=mysql_connect($host, $user, $password);
mysql_select_db('db', $mysql_link);

$query_max = "select max(id) as max_id from table1";
printf('Plus grand id de la table: %d<br>', 
       current(mysql_fetch_assoc(mysql_query($query_max, $mysql_link)))
       );

$query = "insert into table1 (champ1, champ2) values('value1', 'value2')";
$result = mysql_query($query1, $mysql_link);
sleep(10);

printf('id inséré: %d<br>', 
       current(mysql_fetch_assoc(mysql_query($query_max, $mysql_link)))
       );
?>

Imaginons que le plus grand identifiant de la table1 soit 10. On exécute d'abord le script n°2 puis tout de suite après le script n°1. Le scritp n°2 fait une pause de 10 secondes après l'insertion pour simuler une requête qui s'exécuterait avant la récupération du maximum. L'identifiant inséré par le script n°2 sera donc 11 et celui inséré par le script n°1 sera 12. Mais le résultat obtenu n'est pas bon: le scritp n°2 renvoie 12 et le script n°1 renvoie 12.

On pourrait faire l'opération inverse pour mettre en défaut la fonction mysql_insert_id() en faisant une pause de 10 seconde avant l'appel de la fonction. On verrait que la fonction renvoie bien le résultat voulu.

Quel est mon mot de passe ?

Nicolas — Tue, 14 Mar 2006 15:27:10 +0000

Dans une interface d'administration qui se respecte, on doit pouvoir à un moment créer des comptes. Il est souvent agréable de se voir proposer un mot de passe aléatoire. En général, je n'utilise pas un mot de passe complétement alétaoire: je supprime les caractères ambigus tels que 0, 1, i, j, l, m, n, o, u, v,I,O. Le code peut ressembler à ça. La fonction attend en paramètre la longueur du mot de passe à générer. Cette fonction n'a rien d'extraordinaire mais elle ne fait que ce qu'on lui demande mais elle le fait bien!


<?php
function generate_password($size) {
  $listeChar = '23456789abcdefghkpqrstwxyzABCDEFGHKJLMNPQRSTUVWXYZ'; 
  $max = strlen($listeChar)-1;

  $key = '';
  for ($i=0;$i<$size;$i++) {
    $key .= $listeChar[mt_rand(0,$max)];
  }
  return $key;
}
?>

Petite mise à jour. J'avais oublié de préciser une chose: pourquoi je supprime certains caractères ? Je supprime les caractères 0, 1, i, j, l, m, n, o, u, v,I,O car ils sont potentiellement ambigus. Le "i" peut être confondu avec le "l", le "0" avec le "O". Même dans la phrase précédente on ne sait pas au premier coup d'oeil si j'ai écris "le zéro et la lettre O" ou "la lettre O et le zéro. L'intérêt est de générer des mots de manière automatique en enlevant les ambiguïtés visuelles.

Développement piloté par les tests.

Nicolas — Tue, 21 Feb 2006 17:16:00 +0000

Il ne semble pas évident au premier abord de faire des tests du code que l'on écrit. En général, on se borne à vérifier qu'il n'y a pas d'erreurs de syntaxe. On vérifie que les 3 ou 4 pages que l'on vient de modifier fonctionnent toujours de la même façon. Cette manière de fonctionner atteint rapidement ses limites au fur et à mesure que l'application grossie. Comment se rappeler que le code écrit aujourd'hui n'aura pas d'impact sur le code écrit il y a 6 mois ? Sans tests exhaustifs, c'est tout simplement impossible.

Il est hors de question de dérouler les tests "à la main". On va écrire des tests automatiques ou plus particulièrement des tests de non-régression, c'est-à-dire des tests qui permettent de vérifier que les modifications apportées à l'application n'ont pas apportées de bugs ou de modifications fonctionnelles. En fait ils permettent de s'assurer que l'application fonctionnera de la même façon.

En PHP, il y a de nombreuses bibliothèques pour se faciliter la tâche, notament PHPUnit ou Simple Test. En ayant un peu regardé les deux je me suis décidé à utiliser Simple Test.

Après avoir lu un livre sur l'Extrême Programming, il me parait plus judicieux d'écrire les tests avant de commencer à coder quoi que ce soit. Ca peut sembler étrange au premier abord mais en utilisant cette pratique de plus en plus souvent cela semble bien plus naturel et surtout plus facile que d'écrire le code et de s'assurer que les tests que l'on va mettre en place couvrent bien tout l'aspect fonctionnel du code.

Un p'tit exemple valant mieux qu'un long discours, imaginons que l'on veuille écrire une "interface" de connexion à une zone membre. On veut que l'utilisateur ayant un couple identifiant/mot de passe correct soit connecté à la zone et que les autres utilisateurs soient rejettés.

Code préliminaire: // login_test.php


<?php
require_once('../simpletest/web_tester.php');
require_once('../simpletest/reporter.php');
class TestOfLogging extends WebTestCase {
  function testAuth() {
    $this->WebTestCase();
  }
}
$test =  new TestOfLogging();
$test->run(new HtmlReporter());
?>

Et on obtient le joli panneau suivant:

TestOfLogging

1/1 test cases complete: 0 passes, 0 fails and 0 exceptions.

C'est un peu normal puisque l'on a rien testé! Premier test:


<?php
require_once('../simpletest/web_tester.php');
require_once('../simpletest/reporter.php');

class TestOfLogging extends WebTestCase {
  function testAuth() {
    $this->WebTestCase();
  }

  function testUnknownUser() {
    $this->get ('http://localhost/xp/login1.php');
    $this->setField('login', "inconnu");
    $this->setField('password', 'mot-de-passe');
    $this->clickSubmit('Ok');
    $this->assertWantedPattern('/utilisateur inconnu/i');
  }
}

$test =  new TestOfLogging();
$test->run(new HtmlReporter());
?>

On obtient ceci:

TestOfLogging

Fail: testUnknownUser -> Pattern [/utilisateur inconnu/i] not detected in [String: <br /> <b>Warning</b>: require_once(./classes/Auth.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in <b>/home/nicolas/webspace/simp...] at [/home/nicolas/webspace/simpletests/tests/login_test.php line 15]

1/1 test cases complete: 0 passes, 1 fails and 0 exceptions.

C'est normal puisque l'on n'a pas encore écrit de code! Une fois le formulaire soumis on affiche le message "utilisateur inconnu". C'est ce message que l'on cherche dans le test

L'idée principal du développement piloté par les tests (écrire les tests puis coder) est d'écrire les tests fonctionnels dans un premier temps puis d'écrire le code minimal qui permette de valider le test. On ne cherche pas à faire le code le plus beau et le plus performant à cette étape. Au test d'après on peut factoriser des bouts de code pour améliorer la qualité générale. On n'aura l'assurance que l'on a rien cassé grâce aux tests. Donc pour passer le test, il suffit d'ajouter dans le script login1.php (qui devient login2.php), une ligne avec "Utilisateur inconnu". C'est loin d'être optimal et c'est même un peu moche comme code. On est confronté à un nouveau problème. La première fois que l'on arrive sur la page, on a le message "Utilisateur inconnu".

Lorsqu'on se trouve avec un "bug" ou un comportement non voulu, on commence par écrire le test correspondant et qui échoue nécessairement. Le voici (en tête de la fonction testUnknownUser):


<?php
$this->assertNoUnWantedPattern('/utilisateur inconnu/i');
?>

Il nous faut maintenant écrire le code minimal qui permette de passer ce test. Il suffit d'ajouter le code suivant: (login3.php)


<?php
if (isset($_POST['sub'])) {
  echo '<p>Utilisateur inconnu</p>';
}
?>

Et on arrive au résultat attendu:

TestOfLogging

1/1 test cases complete: 2 passes, 0 fails and 0 exceptions.

Attaquons-nous à la partie "utilisateur reconnu"! On va créer un objet User qui regroupera toutes les propriétés d'un utilisateur et en particulier le fait que son identification est correcte. Les tests dans login.php se résumeront à appeler une méthode vérifiant la validité du couple login/mot de passe pour pouvoir accéder à la zone membre. On va supposer dans un premier temps que l'objet existe et que l'on peut l'utiliser de la manière suivante:


<?php
require_once('./classes/User.php');
$is_valid= false;

if (isset($_POST['sub'])) {
  $user = new User();
  $is_valid = $user->isValid($_POST['login'], $_POST['password']);
}
if ($is_valid) {
  echo 'Vous êtes connecté<br>';
} else {
  // affichage du formulaire
}
?>

Ecrivons maintenant les tests vérifiant qu'un utilisateur reconnu (login: Lebon et mot de passe: Secret) peut se connecter:


<?php
require_once('../simpletest/web_tester.php');
require_once('../simpletest/reporter.php');
require_once('../classes/User.php');

class TestOfLogging extends WebTestCase {
  function testAuth() {
    $this->WebTestCase();
  }

  function testUnknownUser() {
    $this->get ('http://localhost/xp/login.php');
    $this->assertNoUnWantedPattern('/utilisateur inconnu/i');
    $this->setField('login', "inconnu");
    $this->setField('password', 'mot-de-passe');
    $this->clickSubmit('Ok');
    $this->assertWantedPattern('/utilisateur inconnu/i');
  }

  function testKnownUserCanLogIn() {
    $this->get ('http://localhost/xp/login.php');
    $this->setField('login', 'Lebon');
    $this->setField('password', 'Secret');
    $this->clickSubmit('Ok');
    $this->assertWantedPattern('/connecté/i');
  }
}

$test =  new TestOfLogging();
$test->run(new HtmlReporter());
?>

En testant, on obtient ça:


Warning: require_once(../classes/User.php) [function.require-once]: failed to open stream: No such file or directory in /var/www/xp/test/login_test.php on line 4

Fatal error: require_once() [function.require]: Failed opening required '../classes/User.php' (include_path='.:/usr/share/php') in /var/www/xp/test/login_test.php on line 4

Après avoir créer la classe User, on obtient:

TestOfLogging

Fail: testUnknownUser -> Pattern [/utilisateur inconnu/i] not detected in [String: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="fr"> <head> <title>Zone membre</title> </head> <body> <h1>Zone membre</h1> <br /> <b>Fatal...] at [/var/www/xp/test/login_test.php line 17]
Fail: testKnownUserCanLogIn -> Pattern [/connecté/i] not detected in [String: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="fr"> <head> <title>Zone membre</title> </head> <body> <h1>Zone membre</h1> <br /> <b>Fatal...] at [/var/www/xp/test/login_test.php line 25]

1/1 test cases complete: 1 passes, 2 fails and 0 exceptions.

On va donc écrire une classe User minimale permettant de passer le nouveau test. Elle pourrait ressembler à ça:


<?php
class User 
{
  public function __construct() {
  }

  public function isValid($login, $password) {
    if ((trim($login)=='Lebon') && (trim($password)=='Secret')) {
      return true;
    } else {
      return false;
    }
  }
}
?>

Et on obtient alors le beau panneau vert suivant:

TestOfLogging

1/1 test cases complete: 3 passes, 0 fails and 0 exceptions.

Tout le code écrit n'est pas forcément optimal mais on l'idée générale du développement dirigé par les tests. On va pouvoir modifier le code sans risquer d'avoir des régressions fonctionnelles ce qui est un des buts principaux de la méthode.

Version finale de la page d'accès à la zone membre: login.php
Version finale du script de tests: login_test.php
Version finale de la classe User: User.php

A la découverte de php5

Nicolas — Sun, 15 Jan 2006 20:22:24 +0000

La version 5 de PHP est sortie depuis plus d'un an, le 13 juillet 2004 exactement. Je ne parlerais pas des nombreux changements tellement c'est énorme. Mais de quoi je vais parler, alors ? De ma déouverte de php5.

Je me suis mis à php5 voici quelques mois. L'installation sur HP-UX n'a pas été une mince affaire mais ça fonctionne!

J'avais pris comme habitude avec php4 de développer sur le serveur de test avec le niveau d'erreur E_ALL (2047). Avec php5, je suis passé à E_ALL & E_STRICT, soit 4095. La plupart des scripts qui se disent compatibles php5 ne passent pas avec ce niveau d'erreurs. Un exemple flagrant: on ne peut plus déclarer un attribut de classe (une variable) de la manière suivante:

Il faut utiliser un des mots-clés de portée, à savoir public, protected ou private.

Précédence des opérateurs

Nicolas — Wed, 21 Dec 2005 11:01:01 +0000

Il existe en PHP deux types de "ET" (and et &&) et de "OU" (or et ||). La raison est qu'ils ont des priorités différentes. Le and et le or ont une priorité plus faible que l'opérateur = alors que le && et le || ont une priorité plus élevée que le =.

Par exemple si on a le code suivant:

<?php
$choix1 = "un";
$choix2 = "deux";
$choix3 = "trois";

$val1 = $choix1 || $choix2 || $choix3; 
$val2 = $choix1 or $choix2 or $choix3; 
?>

$val1 sera égal à true et $val2 sera égal à "un".

Pour régler le problème, soit on met tout le temps des parenthèses, soit on n'utilise les opérateurs && et ||.

Afficher une arborescence avec menu et sous-menu.

Nicolas — Fri, 22 Jul 2005 22:25:36 +0000

On est souvent confronté à ce type de problème: afficher sous forme d'arbre (liste ul/li par exemple) un menu ou un forum. On récupère les informations d'une base de données où chaque enregistrement comprend les champs suivants (au minimum): id, label, parent. La requête de sélection est toute simple: select id, nom, parent from table.

Imaginons que l'on est récupéré ces enregistrements là:


    <?php

	$tab[1] = array('label'=>'menu1','parent'=>0);

    $tab[2] = array('label'=>'menu1.1','parent'=>1);

    $tab[3] = array('label'=>'menu1.1.1','parent'=>2);

    $tab[4] = array('label'=>'menu1.1.2','parent'=>2);

    $tab[5] = array('label'=>'menu1.2','parent'=>1);

    $tab[6] = array('label'=>'menu2','parent'=>0);

    $tab[7] = array('label'=>'menu3','parent'=>0);

    $tab[8] = array('label'=>'menu3.1','parent'=>7);

    $tab[9] = array('label'=>'menu3.2','parent'=>7);

    $tab[10] = array('label'=>'menu3.3','parent'=>7);

?>

On veut obtenir ça:

menu1
- menu1.1
  - menu1.1.1
  - menu1.1.2
- menu1.2
menu2
menu3
- menu3.1
- menu3.2
- menu3.3

Et le code PHP correspondant peut ressembler à çà:


<?php

function addTree(&$Tree,$feuille,$id) {

	   global $tab;

	

   $Tree[$feuille['label']]['__LABEL'] = $feuille['label'];   

	   foreach ($tab as $cle => $element) {

	      if ($element['parent']==$id) {

	         addTree($Tree[$feuille['label']],$element,$cle);

	      }

	     }

	    }

	      

    
    $Tree = array();

	foreach ($tab as $cle => $feuille) {

	  if ($feuille['parent']==0) {

	    addTree($Tree,$feuille,$cle);

	  }

	  }

	  
	      ?>

Cette petite fonction récurssive peut sembler anodine mais elle fait tout le boulot et elle le fait bien.