Mais pourquoi ? 

Eh bien, d’après-moi c’est parce que cela offre le meilleur des 2 mondes. Il arrive souvent que dans les applications modernes, le recours au stockage de document (clé / valeur) soit très pratique. Pour enregistrer des logs, des informations rapidement accessibles, de l’information brut et non relative … Les applications modernes ne requiert pas en tout temps des données relative.

Une autre raison qui me parait intéressante est que des fois, la fainéantise (ou le manque de temps) du développeur va faire que certaine données ne seront pas collectées et enregistrées en base données. Si la modélisation demande d’ajouter 7 tables et que le schéma de la base de données devient une usine à gaz, le développeur est humain, oui, et des fois ça ne le tente pas, il préfère aller se boire une bière. C’est alors que le type de données JSON intervient pour permettre de « jeter » un groupe de donnée au format JSON dans un champs. 

Il suffit de créer un champs de type JSON ou JSONB (nous verrons la différence plus tard) et vous avez accès au stockage de donnée hiérarchique que permet JSON. Mais ce n’est pas tout, sinon vous auriez pu mettre vos données au format JSON dans un champ de type « TEXT ». L’important avec le type de donnée JSON est que vous allez pouvoir faire des requêtes SQL directement dans le JSON. PostgreSQL propose des fonctions et des opérateurs spécifiques au format JSON pour faire vos requêtes, et cerise sur le gâteau, c’est très efficace et rapide.

JSON ou JSONB 

Lorsque vous souhaitez enregistrer des données au format JSON dans PostgreSQL, vous avez le choix en JSON et JSONB (JSON Binary). 

Les deux types de données JSON et JSONB dans Postgres sont utilisés pour stocker des données au format JSON, mais ils ont des comportements différents en ce qui concerne l’indexation et la vérification de la validité des données.

JSON est un type de données non indexable, ce qui signifie qu’il n’est pas possible d’utiliser des index pour accélérer les requêtes qui filtrent ou trient des données JSON. Il est également moins efficace pour stocker des données qui contiennent des erreurs de syntaxe ou des valeurs non valides.

JSONB est un type de données indexable, il permet d’utiliser des index pour accélérer les requêtes qui filtrent ou trient des données. Il est également plus efficace pour stocker des données qui contiennent des erreurs de syntaxe ou des valeurs non valides car il vérifie la validité des données au moment de l’insertion.

Requêtes SQL sur un champs JSON dans PostgreSQL

Pour cet article, nous allons nous concentrer sur les opérateurs, mais sachez qu’ils existent aussi plein de fonctions dont vous pouvez trouver la liste dans la documentation de PostgreSQL. Les opérateurs vous permettent de faire des requêtes SQL simple dans un champs JSON ou JSONB.

La flèche courte -> garde le type JSON

La flèche longue ->> retourne du texte.

Voici le code SQL pour reproduire ce petit tutoriel vous même : 

CREATE TABLE transaction (
	id serial NOT NULL PRIMARY KEY,
	message json NOT NULL
);

INSERT INTO transaction (message)
VALUES('{ "order_id": "7856", "items": {"product": "Beer","qty": 24}}'),
      ('{ "order_id": "9801", "items": {"product": "Pizza","qty": 1}}'),
      ('{ "order_id": "10089", "items": {"product": "Wine","qty": 2}}');

Voici un exemple de requête pour récupérer tous les order_id du champs « message » de la table « transaction ». Attention ça va aller vite :

SELECT message->'order_id' from transaction;

Plutôt simple, non ? ça nous retourne 3 ligne : « 7856 », « 9801 » et « 10089 »

Maintenant si je souhaite obtenir les items dont le order_id est 9801, voici la requête :

SELECT message->'items' as items from orders WHERE message ->> 'order_id' = '9801';

Aller plus loin sur JSON et JSONB dans Postgres

Voici une vidéo pour étendre le sujet du JSON & JSONB pour Postgres : 

Conclusion

Vous voyez la puissance du couple JSON et SQL ? C’est super utile de pouvoir stocker des données non organisées dans un JSON et de pouvoir faire une requête SQL dans le JSON directement. C’est un gain de temps énorme et ça peut aussi améliorer votre application puisque le SQL va pouvoir pré-mâcher les données.

Si vous êtes intéressé à en savoir plus sur les champs de type JSON dans Postgres et comment travailler avec ceux-ci, à voir plus d’exemples … Laissez un commentaire et je pourrais faire un autre article plus en profondeur.

Pour stocker un prix dans PostgreSQL il faut utiliser le type de données (datatype) : 

NUMERIC(precision, scale)

En pratique, par exemple : numeric(7,2) permettra de stocker un prix jusqu’à 99999.99. Il y a donc 7 digits au maximum (precision) et 2 après la virgule. PostgreSQL fera un arrondi de tout chiffre pour stocker uniquement 2 chiffres après la virgule.

Pour l’exemple, 135.784 a une « precision » de 6 et un « scale » de 3

Si le prix est supérieur, alors PostgreSQL retourne une erreur du type : 

ERROR:  numeric field overflow
DETAIL:  A field with precision 5, scale 2 must round to an absolute value less than 10^3.

J’ai un nouveau serveur sur lequel je souhaitais passer en SSL pour mes domaines protégés. Comme Let’s Encrypt propose des certificats SSL gratuits et de qualité, je me suis tourné vers cette solution. Pour l’installation, c’est facile et vous trouverez plein de tutoriel sur ce sujet.

Let’s Encrypt propose de valider le nom de domaine en allant vérifier le répertoire .well-known dans votre racine web. Comme chaque certificat émis ne dure que 3 mois, il faut créer une tâche CRON qui va permettre de valider le domaine, émettre un nouveau certificat et l’installer.

Problème, si votre accès au domaine est protégé par un .htaccess couplé à un .htpasswd alors la validation n’a pas lieu correctement puisque l’accès et refusé. Voici une solution très simple. à laquelle j’aurais dû pensé plus tôt … Du fait de son fonctionnement même htaccess fonctionne répertoire par répertoire, il suffit donc d’aller créer un .htaccess dans le répertoire .well-known et y ajouter les instructions suivantes :

Satisfy Any
Order Allow,Deny
Allow from all

Vous pouvez maintenant tester et Let’s Encrypt aura bien accès au répertoire .well-know pour sa validation. Ainsi le certificat pourra être émis de nouveau sans problème.

J’espère que ça vous aidera.

Mon plugin WordPress pour créer un sitemap est Better WordPress Google XML Sitemaps. Mais le problème semble être le même avec Yoast SEO. Vous pourrez surement donc adapter la solution pour Yoast.

En configurant votre Nginx pour WordPress, vous devez avoir créé une ligne qui ressemble à ceci :

location / {
  # include the "?$args" part so non-default permalinks doesn't break when using query string
  try_files $uri $uri/ /index.php?$args;
}

Comme les plugins de WordPress n’écrive pas le fichier sitemap.xml en dure sur le serveur, il génère en dynamique (avec cache) le sitemap. Il faut donc diriger sitemap.xml vers la bonne URL qui va générer le sitemap. Voici pour ma part ce que j’ai utilisé dans mon fichier nginx.conf (dans la racine de mon site, mais vous pouvez le mettre dans votre fichier de config de nginx ou de vhost directement).

## Sitemap XML config
rewrite ^/sitemapindex\.xml$ /index.php?gxs_module=sitemapindex last;
rewrite ^/post\.xml$ /index.php?gxs_module=post last;
rewrite ^/page\.xml$ /index.php?gxs_module=page last;
rewrite ^/post_google_news\.xml$ /index.php?gxs_module=post_google_news last;
rewrite ^/taxonomy_category\.xml$ /index.php?gxs_module=taxonomy_category last;

ATTENTION : À ce stade, si vous souhaitez tester si ça fonctionne il faut REDÉMARRER NGINX

Soit faire la commande suivante :

sudo systemctl restart nginx

Voilà, votre sitemap a retrouvé ces couleurs et est prêt à servir google et autres répertoires …

Si vous avez des questions, n’hésitez pas.

C’est toujours appréciable de voir qu’une équipe, comme celle de WPML, prends au sérieux les gens qui paye pour leur plugin et écoute le feedback.

D’où viennent / venaient les problèmes de performances

Lorsque j’utilise WPML, j’installe presque dans tous les cas, ces plugins « compagnons » : WPML String translation et WPML Media. Lorsque tout cela est installé sur votre WordPress, il y a 20 nouvelles tables MySQL qui s’installent. Pour comparaison, WordPress ne possède que 12 tables à lors d’une nouvelle installation. Donc voilà, WPML est gourmand en ressource mémoire et CPU pour les requêtes SQL qu’il exécute pour afficher les pages. Plus vous avez de chaînes traduites, plus il exécute des requêtes.

Dans le cas de WooCommerce, si vous utilisez les variations de produits (comme couleurs ou tailles), WPML démultiplie le nombre de requêtes ce qui fait chauffer le processeur et gonfler la mémoire. Ceci provoque un vrai goulot d’étranglement lors du chargement de la page.

Comment la version 3.5 de WPML améliore les performances

Peu importe ce que vous avez entendu sur WPML, je vous conseille de lui donner une chance avec cette version 3.5 (et plus). D’après un article de WPML, qui explique leur processus d’optimisation, des efforts ont été déployé pour tester différentes solutions et ont réussi à améliorer les performances de façon très perceptibles. Voici un tableau donné par l’équipe elle même qui explique les performances gagnées.

Autant dire que ça fait une différence lors du chargement de vos pages mais aussi de l’admin. Pour ceux qui ont l’habitude d’attendre que l’admin se charge, je peux vous dire que c’est un vent de fraicheur

Je n’ai pas encore pu tester avec PHP7, mais comme l’explique WPML, les anciennes versions de WPML sont beaucoup plus réactives sur PHP7 que PHP5. Cependant il semble y avoir un boost de performance dans les 2 cas.

Pour les développeurs de sites WordPress qui utilisent souvent WPML, je pense que de mettre à jour le(s) plugin(s) est un must. Si vous avez l’occasion de pouvoir avoir un hébergement PHP7, vos clients et les visiteurs de ces sites ne pourrons que mieux vous aimer.

Si vous avez des retour d’expérience avec WPML, n’hésitez pas à mettre un message plus bas.

• Performance améliorée : PHP 7 est jusqu’à 2 fois plus rapide que PHP 5.6
• Réduction de l’utilisation mémoire
• support du 64 bit plus consistant
• Passage de beaucoup d’erreurs fatales en Exceptions
• Générateur de nombre aléatoire sécuritaire
• Classes anonymes

Tester votre code avec PHP 7 et d’autres versions de PHP grâce à MAMP PRO 3.

Si vous souhaitez tester votre code avec PHP 7 avant de passer en production, MAMP PRO 3 est solution vraiment simple. La version 3.5 propose nativement PHP7 et vous permet de faire un « virtual host » avec une version différente de PHP. Vous pourrez donc par exemple avoir un site en PHP 5.6, un autre en PHP 5.4.2 puis un dernier en PHP 7. MAMP PRO se révèle donc très pratique pour tester votre code sous différente version de PHP, une chose assez compliquée à mettre en place sur un serveur de production.

MAMP PRO 3 se révèle donc très pratique pour tester votre code en local avec différentes versions de PHP. Avec l’évolution du paysage des hébergements dans les futurs mois, tester votre code dès maintenant pour se préparer à PHP7 semble être une bonne pratique. Étant donnée les gains de performance engendrés par PHP7, il se peut que beaucoup d’hébergeur passe à cette version pour faire quelques économies.

Si vous avez des questions, n’hésitez pas à les poser plus bas dans cette page. Ça me fera plaisir d’y répondre.

1. Installation et configuration
2. Traduction des articles, pages et custom post WordPress
3. Traduction des chaînes de caractère (texte en PHP (hardcodé) dans le thème ou les widgets)

Installation de WPML

L’installation de WPML est très simple, et vous pouvez l’ajouter à n’importe quel moment du développement d’un site. Voici les étapes à suivre :

• Aller sur le site de WPML : http://wpml.org/fr.
• Décider le plan que vous souhaitez prendre. il existe 3 plans différents. Si vous faites un site web complet en utilisant WordPress comme un CMS, si vous utilisez les « custom posts » et « custom taxonomy » vous devrez prendre le plan CMS multilingue à 79$.
• Une fois acheté vous allez pouvoir télécharger le plugin.
• Aller dans l’admin de votre WordPress puis dans le menu « Extensions » puis « Ajouter », cliquez sur Ajouter une extension et sélectionné l’archive que vous venez de récupérer.
• Une fois installé, vous verrez dans votre menu de gauche, un nouveau menu WPML.

Important : Si vous êtes développeur et que vous souhaitez utiliser le plugin WPML sur le site de vos clients, je vous encourage à prendre le plan CMS multilingue à vie.

Choisissez les langues du projet

Pour la configuration, c’est assez simple, il va vous falloir définir quelles langues vous souhaitez utiliser, quelle langue vous souhaitez par défaut, comment vous souhaitez ajouter visuellement le sélecteur de langue sur votre site et très important, la façon dont les URL vont fonctionner.

Voici une série d’images annotées qui vont vous aider à comprendre comment faire :

Choisir le format des URL pour les langues

Une fois les langues ajoutées au projet, vous devez spécifier la façon dont vous souhaiter que le système de langue fonctionne. Vous avez alors 3 choix :

1. Langues différentes dans les répertoires (http://domaine.com/en/)
2. Un sous-domaine différent pour chaque langue (http://en.domaine.com/)
3. Langue ajoutée dans un paramètre GET (http://domaine.com?lang=en)

Pour ma part, je conseille souvent le choix 1 qui est à mon avis le plus jolie à l’oeil mais aussi qui semble être le meilleur choix pour votre SEO.

Sélecteur de langue

La rubrique suivante vous propose de régler la façon dont le sélecteur de langue va s’afficher. Je ne suis vraiment pas fan de cette façon de faire, je ne me sers donc juste pas de ce composant. Voici ce que je fais à la place et qui me donne beaucoup plus de liberté au niveau du placement et de la forme. Vous pouvez copier ce bout de code dans votre fichier functions.php :

function icl_post_languages(){
  $langs = "";
  $languages = icl_get_languages('skip_missing=1');
  
  $i = 0;
  
  if(1 < count($languages)){
    foreach($languages as $l){
      if(!$l['active'])
        $langs .= '<li><a href="'.$l['url'].'">'.strtoupper($l['language_code']).'</a></li>';
      else {
        $langs .= '<li class="current"><a href="'.$l['url'].'">'.strtoupper($l['language_code']).'</a></li>';
      }
      
      if($i == 0) {
        $langs .= " | ";
      }
      
      $i++;
    }
    echo $langs;
  }
}

Vous pouvez bien entendu modifier ce code pour afficher le sélecteur de langue de la façon que vous souhaitez. Une fois prêt, vous pouvez appeler cette fonction dans votre thème, là où vous souhaitez voir apparaître le sélecteur. Vous pouvez aussi ajouter du CSS pour habiller ce code HTML selon vos besoins.

Conclusion

Si vous avez besoin d’aide à cette étape (installation et configuration), laissez un message dans les commentaires et j’essayerais de vous aider au maximum de mes connaissances. La suite de ce tutoriel suivra sous peu et nous verrons le moyen de traduire les articles, pages er custom post. À bientôt !

Explication du bug

Dans l’admin de WordPress il est possible de visualiser un article en mode aperçu pour tester et voir le rendu avant de mettre en ligne cet article. Dans mon cas et dans certains articles, j’avais des problèmes d’affichage liés au fait que certain metapost (Custom Fields) n’apparaissaient juste pas dans l’article.

Solution et méthode pour déboguer le problème

Après beaucoup de test de code et autre, j’ai vérifié que ce problème apparaissait uniquement dans l’admin et en mode preview. J’ai alors commencé par désactiver les plugins reliés uniquement à l’admin un par un …

Pour rappel, il y a 2 solutions efficaces pour déboguer Wordpress : 

1. Désactiver tous les plugins et les remettre un par un en vérifiant que le problème n’est plus là à chaque fois afin d’isoler le plugin responsable du bug. (et oui, c’est souvent un plugin, rarement WordPress lui-même qui pose problème).
2. Si vous êtes sur un site en production, des fois il est un peu barbare de désactiver tous les plugin puisque votre site pourrait ne plus ressembler à rien. L’autre méthode est alors de désactiver un plugin à la fois et le réactiver si le problème persiste. Lorsque le problème n’est plus là, vous devez avoir trouvé le plugin responsable !

Pour ma part, j’ai utilisé la 2e solution et j’ai rapidement isolé le plugin « Custom Fields Template ». Ce fidèle plugin presque installé depuis 4 ans, m’a fait perdre une demi-journée … après m’avoir fait gagner beaucoup de temps (je dois l’avouer).

Bref, si vous avez ce problème d’aperçu (preview) dans WordPress, c’est donc le plugin dont vous devrez vous séparer !

J’espère que ça aidera quelqu’un !

<!DOCTYPE html>
<html>
<head>
<title>Diagramme circulaire</title>
<meta charset="UTF-8">
</head>
<body>
<script type="text/javascript" src="https://www.google.com/jsapi"></script>
<script type="text/javascript">
  google.load("visualization", "1", {packages:["corechart"]});
  google.setOnLoadCallback(drawChart);
  function drawChart() {
    // Chart 1
    var data = google.visualization.arrayToDataTable([['OS Mobile', 'Parts de marché'],["Android",71.40],["iOS",14.70],["Windows Phone",10.60],["Blackberry",1.00],["Autres",2.30]]);
    var options = {
      title: 'Parts de marché des OS Mobile en Juin 2014 (France)'
    };
    var chart = new google.visualization.PieChart(document.getElementById('piechart'));
    chart.draw(data, options);
  }
</script>

<div id="piechart" style="width: 100%; height: 500px;">&nbsp;</div>

</body>
</html>

Comme vous le voyez, avec juste ces quelques lignes de code, on peut créer un diagramme circulaire vraiment facilement grâce à Google Charts.

Pratique pour un projet rapide, ou montrer des statistiques à votre boss d’une belle façon.

1. Faites une copie de suavegarde du fichier classes/CartRule.php
2. Téléchargez la dernière version 1.6xxx sur le site de Prestashop
3. Trouvez le fichier classes/CartRule.php
4. Remplacez le fichier classes/CartRule.php

Et voilà, la fonctionnalité est réparée. Ce patch est à utiliser uniquement pour les versions de Prestashop 1.6 à 1.6.0.10.