Techno-magis

C’est souvent dans l’urgence que l’on se rend compte qu’une nouveauté ne passe pas. En l’occurrence, j’ai voulu profiter des emoji 😄 fournis par Unicode 7.0 pour éviter de mettre des images à la place des smileys et c’est plus universel, pour le coup. Sauf que je n’avais pas fait attention au fait que ces caractères en UTF-8 sont codés sur 4 octets ce qui dépasse ce qui est prévu de base dans l’interclassement « utf8_unicode_ci » qui n’accepte que l’UTF-8 sur 3 octets maximum. Il faut que les tables et les champs passent en « utf8mb4_unicode_ci ». L’utf8mb4 est là pour préciser que l’UTF-8 sur 4 octets est accepté. Il faut savoir que l’UTF-8 peut en théorie accepter jusqu’à 8 caractères, mais la version normalisée se limite à 4 pour l’instant. Attentions, il semble que « utf8mb4_unicode_ci » soit un peu plus lourd.

Côté PHP, il faut aussi préciser que l’on voit des données « utf8mb4 » pour éviter les surprises.

$mysqli = new mysqli($sql_host, $sql_user, $sql_pass, $sql_base);
$mysqli->set_charset("utf8mb4"); //  utf8 → utf8mb4

Bon visiblement, à part l’interclassement et l’encodage d’envoi, il n’y a rien de plus à faire. Les champs restés en « utf8_unicode_ci » fonctionnent toujours, mais il ne faut pas leur envoyer du « utf8mb4 » sous peine d’une mauvaise surprise.

J'avais déjà fait une petite fonction pour les jours fériés en France dans cet article. Puis, comme j'aime bien le Japon, je me suis dit que j'allais faire de même pour le Japon ce qui a été largement plus compliqué vu qu'ils ont la bonne idée d'avoir les équinoxes en jours fériés. Contrairement au dimanche de Pacques, il n'y a pas de méthode miracle qui les calcule tous seule. Heureusement, j'ai trouvé comment les avoir.

Encore une idée stupide, ici, directement liée à un autre petit projet que présenterait dans un prochain article. J'avais besoin des dates de changement des saisons... le problème c'est : « comment ça se calcul ? ».

À la base, c'était une demande du boulot, sauf qu'une fois que j'avais ce que je voulais pour mon module, il y avait peu d’intérêt d'aller plus loin. Du coup, j'ai repris l'idée chez moi et j'ai essayé d'en faire un outil plus polyvalent qui ne demande même pas de connaître la syntaxe de Crontab. J'ai découpé la chose en deux parties, la gestion des lignes et du fichier d'un côté et de l'autre celui du temps. Le plus long a été de faire tous les contrôles lors du parsing d'un fichier pour s'assurer qu'il n'y a pas d'erreurs.

J'avais une petite méthode pour générer ou vérifier des EAN13 que j'ai présentés dans un article précédent. J'avais fait une méthode de formatage pour ajouter des tirets (en anglais “hyphenation”). Je pensais bêtement qu'il y avait un seul formatage, jusqu'à ce que j'y fasse vraiment attention. En fait il y a un formatage spécial pour les ISBN13, et c'est un poil plus compliqué que je ne le pensais.

Comme d'habitude ça part de l'idée de ne pas se prendre la tête et surtout ne rien avoir à faire par la suite pour gérer les jours fériés. Le seul problème c'est le lundi de Pâques, qui ne semble pas si simple à avoir. Heureusement, PHP dispose de la fonction easter_date() qui permet d'avoir le timestamp du dimanche de Pâques. Avec ça, ça devient infiniment plus simple.

Encore des problématiques de code-barre ou plutôt identificateur. Comme en ce moment c'était une de mes problématiques, et que j'ai trouvé des solutions facilement intégrables. Autant en faire profiter tout le monde avec quelques explications.

Pour compléter l'article d'hier, quelques méthodes simples pour l'EAN13 (accessoirement ça marche aussi pour l'ISBN13 qui est une plage de l'EAN13).

Télécharger la classe : EAN13 (1.0)

Exemple, avec ce code :

$ean13 = EAN13::generator(40, 49);
echo $ean13; // affiche : 0418408982338
 
echo EAN13::format($ean13);  // affiche : 041-8-4089-8233-8

J'avais besoin d'afficher un EAN13, j'ai trouvé une petite classe qui fait cela, mais comme d'habitude, je tombe sur un code qui date de PHP 4 et la programmation-objet qui en dépend, donc plus à jour. Après une revue de code pour le passage en PHP 5, je redistribue la mise à jour. Normalement, le comportent est identique à l'original, car je n'ai rien modifié sur son fonctionnement interne. Par contre, ça doit être plus facile à intégrer. J'aurais pu ajouter une validation de l'EAN13 (je l'ai fait ailleurs, pour un prochain article ?) Mais je considère que ce n'était pas le rôle de la classe en question.

Télécharger la classe : Debora (1.1)

Exemple, avec ce code :

$ean = new Debora('0123456789012', 2);
$ean->makeImage();

Cela donne :

À la base, j'avais besoin d'une information que je puisse appeler soit par le nom de variable soit par une position dans un index. Pour faire simple, l'information était dupliquée deux fois... Le problème, c'est qu'en cas de modification, c'est assez chiant à corriger.

J'ai fini par simplifier ma tâche en réduisant le tout à un seul tableau indexé avec une table de correspondance. Avec l'aide des méthodes magiques __get() et __set, il est possible de faire ça assez simplement. Pour que ça soit utilisable facilement ailleurs, je suis partis sur des appels static et non self lors de l'appel à liste de correspondance. Le seul inconvénient est que ça augmente le traitement dû à la recherche de la correspondance.

Étant en ce moment sur PrestaShop depuis un peu plus d'une semaine, j'ai rencontré quelques difficultés lors de l'écriture de code pour modifier un module. J'ai fini par surmonter mes problèmes avec un peu d'aide trouver ici et là sur le Net (aide en ligne, blogs, forums) et avec la lecture du code même. Ce n'est jamais très compliqué une fois qu'on a compris.

Je mets ici quelques points qui m'ont semblé utiles. C'est peut-être aussi le premier d'une suite d'article, vu que j'ai eu à toucher à pas mal de choses en peu de temps : ajouter d'information dans la base, surcharge de classe, écriture de templète, injection dans une complète, etc.

Bon, j'avais quelques problèmes avec la venue d'Internet Explorer 11, surtout que php_browscap.ini n'est plus mis à jour depuis juillet et que le net continue d'avancer sans lui. Sans trop de mal, j'arrive à ajouter les nouvelles versions de Firefox ou Chrome (et quelques autres quand j'y pense). Pour IE 11 qui a décidé de changer complètement son user agent, j'ai dû un peu chercher et finalement voilà les bonnes lignes à ajouter dans le fichier : (voir article complet).

J'avais besoin de MathML pour un petit truc, donc j'ai décidé d'intégrer un module PHP. Le souci a été de trouver un truc simple. Il existe bien MathJax, mais ça part du principe que ce n'est pas au client de bosser pour ce genre de chose. Je ne nie pas que l'outil est super puissant, permettant un rendu adapté au navigateur : MathML, HTML ou SVG à partir d'un rendu LaTeX ou MathML. D'ailleurs, je trouve qu'il est plus intéressant de l'utiliser à partir d'un rendu MathML pour les navigateurs ne supportant pas MathML, mais je trouve la bibliothèque vraiment très lourde.

C'est très con, mais j'avais besoin de générer un tableau PHP en PHP pour le stocker et pouvoir l'utiliser plus tard. J'aurais pu passer par du XML ou du JSON, mais quitte à lire du code dans un fichier autant faire un include() en PHP, comme ça il n'y a aucun traitement à faire par la suite.

$mon_tableau = array(
	'clé1_n1' => 'val1_n1',
	'clé2_n1' => 'val2_n1',	
	'clé3_n1' => array(
		'clé1_n2' => 'val1_n2'
	)
);

Il n’est pas toujours évident de récupérer une valeur dans un tableau, surtout la profondeur est variable suivant tout un tas de paramètres. Je n’ai pas trouvé de méthode qui permet de lire, modifier ou tester l’existence d’une valeur dans un tableau dont le chemin est dynamique, type : $table[$keys[0]][$keys[1]]...[$keys[n]]. Pour ce faire, je me suis lancé dans la réalisation de trois méthodes pour arriver à cela.