Christophe Le Bot

  • Navigation rapide
Pratique de la conception numérique

Derniers commentaires

  • Une excellente thèse sur Simile Exhibit
    • Olivier Rossel | Bonjour. Malgre les annees, avez vous toujours en memoire vos usages d’Exhibit? Je serais ravi d’en discuter avec vous. Cordialement, Olivier Rossel.
  • Utiliser le planificateur de tâches OVH (crontab) avec PHP
    • Max | Bonjour, comme faire pour appeler une version de PHP qui n’est plus proposée par défaut dans le manager ? J’essaie de lancer un cron avec php 5.3 mais le log affiche No such file...
    • Christophe | @absolument Merci pour ces précisions. Je n’ai pas mis en place de tâches cron récemment, mais j’ai reçu quelques notifications étranges d’OVH il y a quelques...
  • Récupérer le dernier auto-incrément MySQL avec PHP
    • Thy | Sujet toujours *très* utile en 2015 ! Je réponds à Serge tsimba qui récupère un « Resource id ». (Et à tous ceux qui ont le même souci mais qui ne le disent pas) :)...
  • Régler l’heure de serveurs virtuels sous Debian
    • Ares_XL | Il semble que sur Débian la commande « tzconfig &ra quo; soit dépréciée et remplacée par : « dpkg-reconfigure tzdata » elle donne accès à une...
 

Sauvons MySQL !

Save MySQL

En janvier 2008, le rachat de MySQL AB par Sun fut un événement majeur et plutôt bien accueilli. Mais l’ambience était tout autre après le rachat de Sun par Oracle. J’émettais de fortes réserves sur la survie de MySQL dans le giron de l’ambitieuse société californienne.

Les craintes se sont confirmées et une grande bataille se joue en ce moment pour sauver MySQL. Michael « Monty » Widenius, le créateur de MySQL, a lui-même tiré la sonnette d’alarme en décembre et a anticipé les problèmes que vont rencontrer les utilisateurs de MYSQL.

Sans réponses claires et pérennes d’Oracle, la communauté s’organise et une pétition a été lancée pour convaincre les pouvoirs publics et les autorités de régulation des marchés d’étudier le cas de la fusion Oracle-Sun-MySQL. Libre à vous de décider de l’avenir de MySQL, mais le danger est, à mon avis, bien réel. J’attends d’être convaincu du contraire…

Pour en savoir plus : Save MySQL !

Oracle acquiert Sun

Oracle acquiert Sun

Le rachat de MySQL par Sun était déjà un événement pour moi l’an dernier. Alors je ne sais plus quels mots utiliser après le rachat de Sun par Oracle aujourd’hui…

Sachant comment finissent les entreprises qui passent entre les mains d’Oracle, il reste une sacrée incertitude sur certains projets (Java et MySQL pour commencer).

Journée riche pour Magento

Trois événements majeurs pour le projet Magento, pratiquement au même moment :

Voilà les quelques informations qui manquaient encore pour convaincre les plus réticents !

Concernant la nouvelle version, tout a déjà été écrit sur le blog officiel ou sur celui de Fragento. J’ajouterai que nous avons maintenant la maturité qui manquait pour réaliser de jolis projets e-commerce !

Installer Drupal 6 sur un serveur mutualisé OVH

Drupal + OVH

ATTENTION ! Cette astuce n’est plus valable sur les hébergements OVH à partir de septembre 2015. La surcharge de configuration PHP par fichier .htaccess n’est plus autorisée. Le fichier .ovhconfig le remplace dès maintenant. Pour plus d’information, voir la page FAQ – Migration sur les dernières versions de PHP du site OVH.

Les contraintes des serveurs mutualisés sont souvent agaçantes, mais rarement insurmontables. C’est le cas chez OVH quand on veut installer Drupal 6.

Drupal ne s’installe pas si register_globals est activé, ce qui est le cas par défaut chez OVH (ce serait trop simple…). Mais il est permis de modifier le comportement du serveur, grâce à quelques directives qu’il faut ajouter au début du fichier .htaccess inclus dans le package Drupal :

SetEnv PHP_VER 5
SetEnv REGISTER_GLOBALS 0
SetEnv ZEND_OPTIMIZER 1

En gros, je passe en PHP5, je désactive register_globals et j’en profite pour obtenir les avantages de Zend Optimizer.

Il faut également décommenter la ligne RewriteBase / dans le même fichier pour que la réécriture des adresses par Apache fonctionne correctement :

# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
RewriteBase /

# Rewrite URLs of the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

Et là, miracle, Drupal s’installe. Enfin, pas pour tout le monde : sur les anciens hébergements, MySQL est encore en version 4.0, incompatible avec Drupal. Pour s’en sortir, il faut migrer votre base de données vers un autre serveur SQL OVH.

Attention, l’opération est très critique… et n’a pas fonctionné pour moi ! En fait, elle consiste à détruire la base pour la reconstruire à partir de vos sauvegardes. Donc premier point : vérifier que vos sauvegardes sont intègres. Ensuite, il faut suivre la procédure OVH.

Sauf que lorsque j’ai voulu reconstruire la base via le manager OVH, elle n’apparaissait plus dans la liste ! Résultat : plus de base de données ! C’est pratique…

Sun acquiert MySQL AB

MySQL Sun

Sun l’a écrit en très gros parce que c’est un très gros événement pour la communauté open source.

Piloter et sécuriser ses bases de données avec MySQL Proxy

MySQL Proxy

MySQL Proxy, proposé par MySQL AB, est le genre d’outils dont le rôle semble si évident qu’on se demande pourquoi il n’existait pas avant. Comme tout proxy, il récupère les requêtes destinées à la base de données, effectue des traitements et adresse une requête modifiée au serveur MySQL. Bien entendu, l’opération inverse est aussi gérée : MySQL Proxy sait récupérer un résultat de requête et le transformer avant de l’adresser au client initial.

Fonctionnalités

Après cette petite présentation, on peut se demander pourquoi on aurait besoin d’un proxy, puisque les services applicatifs (s’ils sont correctement architecturés et codés…) devraient envoyer une requête optimisée au serveur MySQL. Une petite liste des fonctionnalités finit par convaincre de son intérêt :

  • Analyse des requêtes
  • Filtrage et modification des requêtes et des résultats
  • Injection de requêtes
  • Load balancing
  • Exécution de scripts (basés sur le langage LUA)

Cas d’utilisation

Dans la pratique, on peut imaginer les situations suivantes :

  • Corriger les erreurs de syntaxe communes.
  • Garantir le fonctionnement d’anciennes applications utilisant des requêtes non supportées.
  • Supprimer du résultat un mot de passe demandé dans la requête.
  • Récupérer et fusionner avec le résultat des données externes à la base de données (fichiers, flux XML, RPC…)
  • Router les requêtes vers un autre serveur MySQL ou vers une autre base de données du même serveur.
  • Empiler un lot de requêtes et les contrôler avant de mettre à jour les tables.
  • Dupliquer les requêtes en temps réel sur deux bases différentes.
  • Exécuter un script shell avant ou après des modifications dans la base de données.
  • Interdire certains motifs de requêtes.
  • Verrouiller des tables selon le contexte.
  • Contrer les injections SQL non désirées.

On le voit, les possibilités sont infinies et ne dépendent que des contextes de production et de l’imagination des développeurs. MySQL Proxy permet surtout d’éviter d’intégrer la gestion de l’exploitation des bases de données MySQL dans les services applicatifs. Voilà enfin une saine séparation du travail du développeur métier et de l’administrateur MySQL !

Mise en oeuvre

MySQL Proxy est encore en version alpha et son fonctionnement n’est garanti que pour les versions MySQL 5.0.x et ultérieures.

Pour découvrir ses possibilités, O’Reilly Network propose un didacticiel clair et très fourni : Getting Started with MySQL Proxy.

Source : Linuxfr.org

Rue89 a choisi Drupal et explique pourquoi

Rue89

Dimanche 6 mai 2007, ce sera la fin du suspens : nous saurons tous à quoi ressemble… Rue89 ! Oui, c’est la date qu’a choisi cette équipe de journalistes passionnés et téméraires pour ouvrir un site d’information d’un nouveau genre. Rendez-vous donc dimanche à 18h (pas à 20h !).

Pour en diffuser le contenu, Rue89 a sélectionné Drupal, une plate-forme de gestion de contenu libre. Ce choix est argumenté dans un article du blog Rue89 :

Parce que nous avions pris la décision de démarrer le site au plus vite et de le faire évoluer au fur et à mesure des suggestions et critiques des utilisateurs, nous avons cherché une solution flexible et prête à l’emploi.

[…]

Nous avons opté pour la plateforme LAMP (Linux, Apache, MySQL, PHP) parce qu’elle est très largement répandue sur Internet, maîtrisée par de nombreux développeurs et qu’elle sert de base technologique à plusieurs outils de gestion de contenu Open Source performants et stables.

[…]

SPIP, bien que largement déployé, nous a paru dépassé et ne répondant pas à nos attentes en terme de fonctionnalités.

[…]

En matière de performance, Drupal apporte des résultats bien plus intéressants [que Joomla] à périmètre matériel constant.

Rue89 cite par ailleurs quelques études comparatives qui permettent d’y voir plus clair :

Les commentaires des lecteurs valent également de s’y attarder :

eZ Publish est bien une référence, mais une référence qui ne monte pas ! La faute a sa difficulté à monter en charge (cache PHP obligatoire) et à l’incapacité des développeurs à adapter le framework aux versions courantes de PHP/MySQL.

[…]

C’est un véritable plaisir que de développer sur ce framework [Drupal], notre équipe de dev est littéralement sous le charme !

Voilà beaucoup d’arguments solides en faveur de Drupal. Pour ma part, je l’avais testé sans être convaincu. C’était en 2001. La démonstration en ligne de la version actuelle m’a montré qu’il a beaucoup évolué depuis. Je le replace donc dans le peloton de tête des CMS LAMP (Content Management System sur plate-forme Linux, Apache, MySQL et PHP).

Il me reste à souhaiter bon vent à Rue89 qui aura déjà beaucoup à faire deux heures après son lancement !

Récupérer le dernier auto-incrément MySQL avec PHP

Quand un script ajoute un enregistrement dans une table MySQL, il est parfois utile d’en mettre d’autres à jour. Et pour cela, on peut avoir besoin de récupérer le dernier identifiant d’auto-increment. La fonction PHP mysql_insert_id() le fera très bien… sous certaines conditions.

Petit rappel sur les connexions MySQL

Avant de faire l’opération, voici un petit rappel du comportement des connexions MySQL ouvertes par PHP.

La plupart du temps, la connexion avec MySQL est établie par la fonction PHP mysql_connect(). Si un deuxième appel est fait avec les mêmes arguments, la première connexion sera à nouveau utilisée. Le paramètre new_link modifie ce comportement et permet à mysql_connect() d’ouvrir à chaque fois une nouvelle connexion, même si mysql_connect() a été appelée avec les mêmes paramètres.

Lorsque le script utilise une connexion persistante (par la fonction PHP mysql_pconnect()), le comportement est le même, à deux différences (importantes !) près :

  • Lors de la connexion, la fonction essaie de trouver une connexion persistante déjà ouverte, avec le même nom d’utilisateur et le même mot de passe. Dans ce cas, son identifiant est retourné sans ouvrir de nouvelle connexion.
  • La connexion au serveur MySQL n’est pas coupée à la fin du script. Le lien est conservé pour un prochain accès, même si on utilise la fonction mysql_close().

Au passage, notez que les connexions persitantes ne fonctionnent qu’avec PHP en version module.

Et l’auto-increment dans tout ça ?

L’auto-increment sera retourné par la fonction PHP mysql_insert_id(), mais il y a des risques de ne pas récupérer celui que vous attendez !

mysql_insert_id() retourne le dernier identifiant généré par un champ de type AUTO_INCREMENT, sur la connexion MySQL courante ou sur la connexion spécifiée par le paramètre link_identifier. Mais les surprises sont nombreuses :

  • Si votre colonne AUTO_INCREMENT est une colonne de type BIGINT, la valeur retournée par mysql_insert_id() sera incorrecte. À la place, il faut utiliser la fonction MySQL LAST_INSERT_ID() directement dans une requête SQL.
  • mysql_insert_id() ne fonctionne pas avec un REPLACE.
  • Si vous utilisez dans votre requête SQL un INSERT IGNORE en précisant un identifiant existant dans la table, l’enregistrement ne sera pas créé, ce qui est normal puisqu’il ne peut y avoir deux identifiants égaux. Par contre, mysql_insert_id() vous retournera l’auto-increment suivant, comme si l’enregistrement avait été ajouté !
  • Si vous faites des insertions multiples (par exemple, INSERT INTO table1 (champ1, champs2) SELECT champ1, champs2 FROM table2 WHERE champ1=2), mysql_insert_id() retournera l’identifiant du premier enregistrement ajouté !

J’arrête là le massacre car il y a bien d’autres cas. Pour s’en sortir, il faut privilégier la fonction MySQL LAST_INSERT_ID() (placée directement dans une requête SQL) et verrouiller la table :

mysql_query("LOCK TABLES table_exemple WRITE");
mysql_query("SET AUTOCOMMIT = 0");
mysql_query("INSERT INTO table_exemple (champ1, champ2) VALUES  ('toto1','toto2')");
$mysql_id = mysql_query("SELECT LAST_INSERT_ID()");
mysql_query("COMMIT");
mysql_query("UNLOCK TABLES");

Formatage d’une durée avec PHP

PHP regorge de fonctions et de variables pour gérer le temps. Pourtant, quand on souhaite afficher une durée entre deux dates, il n’y a aucune fonction spécifique ! Voici comment s’en sortir.

Un peu de mathématiques

Le principe est d’utiliser un nombre entier, par exemple une durée exprimée en secondes. A vous de convertir la durée avec vos scripts PHP (la fonction mktime() est toute désignée).

Ensuite, quelques formules mathématiques simples donnent un tableau contenant toutes les valeurs de la durée dans les unités de temps que vous souhaitez utiliser :

$duration = 3695;

// Initialisation
$duration = abs($duration);
$converted_duration = array();

// Conversion en semaines
$converted_duration['weeks']['abs'] = floor($duration / (60*60*24*7));
$modulus = $duration % (60*60*24*7);

// Conversion en jours
$converted_duration['days']['abs'] = floor($duration / (60*60*24));
$converted_duration['days']['rel'] = floor($modulus / (60*60*24));
$modulus = $modulus % (60*60*24);

// Conversion en heures
$converted_duration['hours']['abs'] = floor($duration / (60*60));
$converted_duration['hours']['rel'] = floor($modulus / (60*60));
$modulus = $modulus % (60*60);

// Conversion en minutes
$converted_duration['minutes']['abs'] = floor($duration / 60);
$converted_duration['minutes']['rel'] = floor($modulus / 60);
$modulus = $modulus % 60;

// Conversion en secondes
$converted_duration['seconds']['abs'] = $duration;
$converted_duration['seconds']['rel'] = $modulus;

// Affichage
print_r( $converted_duration);

Ce code affichera le résultat suivant :

Array
   (
      [weeks] => Array
         (
            [abs] => 0
         )

      [days] => Array
         (
            [abs] => 0
            [rel] => 0
         )

      [hours] => Array
        (
            [abs] => 1
            [rel] => 1
         )

      [minutes] => Array
         (
            [abs] => 61
            [rel] => 1
         )

      [seconds] => Array
         (
            [abs] => 3695
            [rel] => 35
         )
   )

Vous obtenez un tableau avec le nombre de semaines, de jours, d’heures, de minutes et de secondes que vous pouvez ensuite utiliser pour l’affichage. Pour chaque unité de temps, la cellule [abs] du tableau stocke la durée totale, alors que la cellule [rel] stocke la durée restante (définie par le modulo).

Prendre la valeur absolue de la durée est capitale ! En effet, sans abs(), la fonction floor() donnera des résultats faux avec un durée négative. C’est logique puisqu’elle retourne toujours l’entier inférieur d’un nombre réel. Si la durée vaut +4.4, vous obtenez +4. Si la durée vaut -4.4, vous obtenez -5 !

Et si j’utilise une base de données ?

Si vos dates à comparer viennent d’une base de données, la conversion en timestamp peut se faire directement dans la requête SQL. Avec MySQL, les champs de type DATE, DATETIME ou TIME sont convertis par la fonction UNIX_TIMESTAMP(). Au passage, attention à la limite des champs TIME (de ‘-838:59:59’ à ‘838:59:59’) !

Si vous utilisez MySQL 5, la fonction TIMESTAMPDIFF() fera tout à votre place… sauf le formatage en PHP que je vous propose !

En guise de conclusion, consultez les pages PHP et MySQL concernant les fonctions de dates et d’heures qui vous épargneront des calculs inutiles :