L'atelier

Comment intégrer à tarteaucitron une demande de consentement pour Matomo

Comment intégrer à tarteaucitron une demande de consentement pour Matomo
Bien que la CNIL ait rendu un avis favorable sur la mise en place du tracker Matomo sans demande de consentement préalable, elle l'a fait en donnant des contraintes fortes sur sa configuration. Les conditions obligatoires pour être exempté de consentement sont :
  • Désactiver les exports de données
  • Permettre aux visiteurs de refuser d'être suivis (Opt-out)
  • S'assurer que les adresses IP sont anonymes
  • S'assurer que les cookies tiers et le cross-domain ne sont pas utilisés
  • S'assurer que la mesure du "User ID" n'est pas utilisée
  • S'assurer que la mesure du e-commerce n'est pas utilisée
  • S'assurer que les cartes de chaleurs et enregistrements de session sont désactivés
  • Vérifier qu'il n'y a pas de collecte de données personnelles (dimension et événements personnalisés)
Si une seule de ces conditions n'est pas satisfaite, il devient alors obligatoire de demander le consentement de l'internaute. Typiquement, pour les sites e-commerce, le simple fait de remonter les commandes dans Matomo oblige le commerçant à réactiver les mécanismes de gestion des cookies et du consentement.

Si vous êtes dans le cas où une ou plusieurs de ces conditions sont rédhibitoires, pas de panique. Ce guide contient toutes les explications pour configurer et activer la demande de consentement pour Matomo via le service tarteaucitron.

Déjà utilisé par bon nombre de kiubistes sur leurs sites, gratuit, très complet et extrêmement simple d'utilisation, tarteaucitron (abrégé en TAC dans la suite de cet article) prend en charge nativement la gestion du tracker Matomo et de ses cookies. Il fonctionne avec le service Matomo Cloud mais aussi avec les dernières versions de Matomo en mode auto-hébergé (On-Premise).

Cependant, cette prise en charge comporte deux défauts :
  • Les URLs des trackers ne sont pas tout à fait à jour
  • TAC gère Matomo en opt-out par défaut
Nous allons donc utiliser TAC et créer un gestionnaire sur-mesure pour corriger ces défauts.

Pour installer manuellement TAC sur un site, il suffit de télécharger la dernière version sur le site officiel et de le déployer dans son site ou alternativement d'utiliser une version mise à disposition par un CDN. On utilisera ici celui de Cloudflare.

On ajoute alors dans le <head> des pages de son site la librairie TAC :

<script src="https://cdnjs.cloudflare.com/ajax/libs/tarteaucitronjs/1.9.6/tarteaucitron.js" integrity="sha512-gXl6bTROZxxymUcoVPuH93os9XPq+SrORZCtUiYDNoaxrrJhDX9o0b/kl3a+MeQJxeYqUBejvkCi4gziE6xrqQ==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>

Vient ensuite la déclaration d'un gestionnaire sur-mesure matomoconsent pour TAC, à ajouter avant la balise </body> :

<script>

tarteaucitron.services.matomoconsent = {
	"key": "matomoconsent",
	"type": "analytic",
	"name": "Matomo (privacy by design)",
	"uri": "https://matomo.org/faq/general/faq_146/",
	"needConsent": true,
	"cookies": ['_pk_ref', '_pk_cvar', '_pk_id', '_pk_ses', '_pk_hsr', 'mtm_consent', 'matomo_ignore', 'matomo_sessid'],
	"js": function () {
		"use strict";
		if (tarteaucitron.user.matomoId === undefined || tarteaucitron.user.matomoHost === undefined) {
			return;
		}

		window._paq = window._paq || [];
		window._paq.push(["setSiteId", tarteaucitron.user.matomoId]);
		window._paq.push(["setTrackerUrl", tarteaucitron.user.matomoHost + "matomo.php"]);
		window._paq.push(["setDoNotTrack", 1]);
		window._paq.push(["trackPageView"]);
		window._paq.push(["setIgnoreClasses", ["no-tracking", "colorbox"]]);
		window._paq.push(["enableLinkTracking"]);
		window._paq.push([function () {
			var self = this;
			function getOriginalVisitorCookieTimeout() {
				var now = new Date(),
					nowTs = Math.round(now.getTime() / 1000),
					visitorInfo = self.getVisitorInfo();
				var createTs = parseInt(visitorInfo[2]);
				var cookieTimeout = 33696000; // 13 mois en secondes
				var originalTimeout = createTs + cookieTimeout - nowTs;
				return originalTimeout;
			}
			this.setVisitorCookieTimeout(getOriginalVisitorCookieTimeout());
		}]);

		// Handle specific cdn matomo cloud url
		var isCloud = tarteaucitron.user.matomoHost.match(/^https:\/\/([^\.]+\.matomo\.cloud\/)/)
		var trackerDomain = isCloud ? 'https://cdn.matomo.cloud/' + isCloud[1] : tarteaucitron.user.matomoHost;
		tarteaucitron.addScript(trackerDomain + 'matomo.js', '', '', true, 'defer', true);

		// waiting for Matomo to be ready to check first party cookies
		var interval = setInterval(function () {
			if (typeof Matomo === 'undefined') return;

			clearInterval(interval);

			// make Matomo cookie accessible by getting tracker
			Matomo.getTracker();

			// looping through cookies
			var theCookies = document.cookie.split(';');
			for (var i = 1; i <= theCookies.length; i++) {
				var cookie = theCookies[i - 1].split('=');
				var cookieName = cookie[0].trim();

				// if cookie starts like a matomo one, register it
				if (cookieName.indexOf('_pk_') === 0) {
					tarteaucitron.services.matomoconsent.cookies.push(cookieName);
				}
			}
		}, 100);
	}
};

À noter que ce gestionnaire active la fonction "Do Not Track" (cf ["setDoNotTrack", 1]) du tracker Matomo pour un meilleur respect de la vie privée des internautes.

Et juste après, l'initialisation classique de TAC à personnaliser selon vos besoins :

tarteaucitron.init({
"privacyUrl": "/donnees-personnelles.html", /* Privacy policy url */
"cookieName": "tarteaucitron" /* Cookie name */
});
</script>

Il est très important de laisser la valeur de cookieName à tarteaucitron.

Il ne reste plus qu'à activer le module Matomo dans la console d'administration de votre site en précisant bien que la gestion du consentement se faire via TAC et Kiubi se charge du reste.

Le module va exécuter automatique le gestionnaire matomoconsent dans toutes les pages du site, ce qui va permettre le tracking des visites et des commandes uniquement des internautes ayant donné leurs consentements. Il ne reste plus qu'à serveiller l'arrivée des données dans Matomo !

L'atelier

Les releases sans peur et sans reproche

Les releases sans peur et sans reproche
Une des grandes forces du SaaS est de s’autoriser à oublier tous les petits tracas techniques des logiciels informatiques. Le service est tout le temps disponible et accessible de n’importe où. Pas d’installation de mises à jour, pas de matériels défectueux, pas de maintenance.

Ces tracas n’ont pourtant pas disparu, ils ont simplement changé de mains.

Dès qu’un lot de nouvelles fonctionnalités est développé, c’est à nous de les installer. Les évolutions de Kiubi se font par ces petits bonds qu’on appelle en interne : "release". C’est au final un ensemble de procédures administratives et techniques qui vont amener la plateforme de la version en cours à une nouvelle version.

Pour cela, nous mettons au point un programme qui contient toutes les instructions nécessaires à la mise à jour, comme par exemple la nouvelle version du code source ou les requêtes SQL pour modifier les bases de données. Ce programme est tout simplement appelé un patch. Chez nous, c’est un assemblage de scripts Shell, de PHP et de SQL qui sera exécuté en une fois sur la plateforme.

Le choix du patch par rapport à d’autres techniques de diffusion de mises à jour s’est imposé à nous car, d’une part, le patch permet plus facilement de transmettre les mises à jour à des tiers qui utilise notre technologie sur leur infrastructure et, d’autre part, car il permet d’enrober la mise à jour de tout un ensemble de sécurités qui nous semblent critiques et qu'on détaillera ci-dessous.
 
Un prérequis de base, qui peut sembler évident, est de disposer AVANT la mise à jour d'une copie de sauvegarde des données à distance ainsi qu’une architecture de secours. C’est la sécurité ultime dans l’hypothèse où tout devait se passer affreusement ou horriblement mal.

Branle-bas de combat

Une fois le patch prêt et testé, il est copié en production puis exécuté pour démarrer la mise à jour. Le patch s’assure d'abord de la compatibilité de l’environnement dans lequel il est installé. C’est à dire qu'il vérifie les versions des logiciels installés, la cohérence des données et si la plateforme est dans une version supportée par le dit patch.

Le patch arrête ensuite tous les services qui doivent l’être pour leur mise à jour : apache, démons, mysql, serveur ftp. La mise à jour peut maintenant commencer en tout sérénité. Le patch crée une nouvelle copie complète du code source dans un dossier qui contient déjà toutes les versions antérieures. Un simple lien symbolique désigne le dossier qui contient la dernière version. Cela permet facilement de passer d’une version à une autre en modifiant un lien symbolique.
 
Un lien symbolique est une sorte d’alias qui peut pointer vers un fichier ou un dossier existant. Imaginons deux répertoires qui contiennent des versions différentes d’un même logiciel :
$ mkdir version1 version2 
$ ls 
version1 version2
On peux alors créer un lien symbolique "courant" qui pointe vers "version2" :
$ ln -s version2 courant
$ ls
courant version1 version2
En prenant l’habitude de toujours utiliser les sources dans "courant", on pourra faciliter la mise à jour du logiciel lors de la prochaine version :
$ mkdir version3
$ ln -sf version3 courant
Maintenant "courant" pointe vers "version3".

Les bases de données principales et celles de tous les sites sont ensuite scannées et mises à jour au besoin. Pour ça, nous avons disposé dans chaque base de données une table contenant un petit compteur indiquant dans quelle version elle est. Le patch peut alors déterminer quelle série de requêtes SQL il doit accomplir en comparant ce compteur avec sa version interne.
 
Le patch vérifie ensuite la cohérence des données avant de relancer tous les services qui avaient été arrêtés. Puis, ultime étape, il lance un ensemble de tests automatiques pour vérifier que tout à l’air de bien fonctionner. L’exécution du patch aura duré un peu moins de 10 minutes.
 
Une des dernières vérifications en date est un système de test de non-régression par carottage. Le principe est de collecter des échantillons de code HTML issus d’un panel représentatif de nos sites. Nous allons par exemple insister sur le catalogue produits ou le tunnel de commande des sites e-commerce, et sur le blog ou les pages de contenus des sites institutionnels. La comparaison des échantillons avant et après la mise à jour pourra garantir que les sites n’ont pas été altérés.

Après c’est au tour des humains avec leurs mains pleines de doigts de faire une petite recette manuelle du bon fonctionnement de tout ce qui a été modifié par la mise à jour avant de réouvrir l'accès à tout le monde.

10 ans de retours d'expérience

Notre système de release a évolué petit à petit en 10 ans pour être de plus en plus fiable. Il s’est construit empiriquement au contact de tout ce qui a mal fonctionné. Nous avons évidement anticipé le maximum de soucis que nous pouvions rencontrer, mais la réalité est toujours pleine de surprises ! Alors c’est parti pour un top 7 des enseignements que nous avons tiré de tout ça :

1. Le dev, c'est pas la prod

Le patch doit être testé sur un environnement le plus proche possible de la production. Même type de serveurs, mêmes systêmes d'exploitation, mêmes versions de tout ce qui a été installé dessus. Et dans l’idéal avec une copie des données de production, même partielle. Nous utilisons des machines virtuelles avec snapshot, ce qui nous permet de figer un environnement dans un état idéal puis de rejouer la mise à jour autant de fois que nous le souhaitons.

Dans la lise des pépins qui nous est arrivé, on peut citer la fois où l’inclusion d’un fichier fonctionnait sur les environnement de tests où le système de fichier n’était pas sensible à la casse, mais plantait en production où le système de fichier est sensible à la casse. Tout cela aurait pu être détecté avec un test de mise à jour sur un environnement ISO.

2. L’erreur est humaine

Le patch est un bout de code à poser et à exécuter tel quel. Le minimum d’opérations doit être effectué à la main car il est toujours possible de se tromper dans l’ordre des étapes à suivre ou de faire une faute de frappe/copier/coller dans une ligne de commande. Quel est le sysadmin qui n’a jamais fait de "rm -rf /" me kill -9 le premier shell.

Il y a 10 ans, l’arrêt des services était fait manuellement, ce qui était source d’erreurs. Maintenant c’est fait de façon automatique. C'est fiable et beaucoup plus rapide. On y a gagné également en confort, on sait que tout est arrêté dans les règles de l’art.

3. Chérie, ça va couper

Ne pas hésiter à faire une interruption de service pendant les mises à jour pour des raisons de simplicité et de fiabilité. Nous avons le luxe d’arrêter tous les services qui utilisent le code source, de purger les caches, puis de les redémarrer une fois le nouveau code en place. On exclut donc les possibilités d’avoir différents bouts de la plateforme qui exécutent des versions différentes du code en manipulant différentes versions des données. Et des bouts, il commence à y en avoir un paquet, entre les APIs, les sites, les consoles d’administration, sans compter les différents démons qui s’occupent des imports/exports, des envois d'emails, etc.

Pour assurer une mise à jour à chaud, il faudrait prévoir et tester le fonctionnement des différentes parties de la plateforme malgré des variations dans les versions de code source et des données. C’est beaucoup de temps, d’efforts et de complexité pour garantir un fonctionnement dans des conditions exceptionnelles qui ne durent en principe que le temps de la mise à jour.

Un dernier avantage est aussi de pouvoir dédier toute la puissance des serveurs à la mise à jour. Les bases de données sont par exemple soulagées de quasiment toute leur charge. Et malgré tout, c’est la mise à jour des quelques milliers de tables nécessaires qui reste l’opération la plus longue actuellement (dans les 5 minutes). Il en serait autrement à pleine charge.

Il faut toujours néanmoins penser aux utilisateurs et proposer un écran de courtoisie expliquant qu'une mise à jour est en cours. Une petite page statique "Mise à jour en cours" est la moindre des choses plutôt qu’un site qui ne réponds pas du tout.
 
Petit détail SEO, pendant nos périodes de maintenance, nous prennons soin de diffuser un code HTTP 503 pour signaler aux moteurs de recherche qu’une maintenance est en cours et qu’il faudra repasser un peu plus tard.

4. Ça passe ou ça casse c’est comme avant

C’est bien d’avoir un plan d’action quand tout se passe bien, mais c’est encore mieux d’en avoir un dans le cas où ça dérape. Le point le plus crucial est qu'un patch sache non seulement comment mettre à jour l'architecture mais aussi comment revenir en arrière en cas de soucis. Il doit pouvoir défaire de façon autonome tout ce qu’il a fait. C’est à dire qu’à la moindre erreur, à n’importe quelle étape, la plateforme doit revenir à son état d’origine.

Pour le code source, c’est facile car le code est archivé. Un simple changement de lien symbolique et tout est à nouveau en place. Pour les données, c’est un peu plus complexe. Hors de question de restaurer la sauvegarde, ça prendrait bien trop de temps. Le patch doit contenir le code permettant directement de faire les opérations inverses. Si un patch ajoute par exemple un champ dans une table Mysql, il doit savoir l’enlever aussi.

5. Les logs, c’est la vie

Le patch doit écrire dans un coin absolument tout ce qu’il fait. La moindre petite commande, et sa sortie, aussi insignifiante soit-elle, doit être loggée et horodatée. C’est très important pour identifier les problèmes, les corriger et améliorer le patch pour la prochaine fois.

Ça nous est arrivé d’analyser ces logs pour identifier les parties du patch les plus lentes et les optimiser. C’est comme ça que le temps d’exécution des patchs est passé de 45 minutes à moins de 10 actuellement.
 
Nous utilisons deux petites fonctions shell bien pratiques pour exécuter ET logger une commande en même temps :
function log {
echo "-- $(date) : $*" >> update.log
}
function xlog {
log "$*"
$* >> update.log
}
Par exemple la copie d’un fichier :
$ xlog cp fileA fileB

6. Notez tous les accros

A chaque release, notez tout ce qui s’est mal passé et trouvez une solution pour que ça ne puisse plus arriver la prochaine fois, quitte à rajouter des tests, des sécurités ou en automatisant mieux les taches. Dans le cas où ça ne concerne pas directement le patch, mettez à jour une checklist des points à vérifier avant la mise à jour.

Des fois, il s’agit juste de circonstances exceptionnelles. Il nous est arrivé d’avoir un problème de réseau au moment où nous testions une mise à jour, ce qui a coupé la connexion avec la machine virtuelle de test. Les sessions SSH se sont évidement coupées également en entrainant l’arrêt de l’exécution d'un patch en plein milieu. Depuis, le patch refuse de se lancer s’il n’est pas dans un screen.

7. Bien plus qu’un patch

Le patch n’est pas le seul élément d’une release. Nous préparons également un ensemble de documents pour cadrer l’intervention, à savoir :
  • un bulletin de révision qui contient une liste de toutes les améliorations, nouveautés ou correctifs de la mise à jour
  • la checklist des quelques étapes manuelles à faire
  • une fiche d’intervention qui précise qui touche à quoi, pour quelle raison et avec le détail de ce qui s’est bien/mal passé
  • une cahier de tests pour effectuer la recette de la mise à jour

TL;DR

Une relase est un processus rafiné par le temps et l'experience, qui nous permet d’aborder les mises à jour avec un état d’esprit apaisé et confiant : nous savons exactement quoi faire, que le tout a déjà été exécuté avec succès sur un environnement ISO prod, qu’une stratégie de retour en arrière est en place et que des diagnostiques automatiques vont nous aiguiller rapidement vers d’éventuels problèmes.

Mais on vous rassure, nous gardons quand même un petit frisson quand on est sur le point d’appuyer sur le bouton ;)

L'atelier

Utiliser un thème Wordpress avec Kiubi

Utiliser un thème Wordpress avec Kiubi
Themeforest, Template Monster, Elegant Themes, etc. vous avez l'embarra du choix pour acheter un thème graphique pour vos sites Internet.

Ces thèmes sont généralement disponibles pour un CMS en particulier, comme Wordpress, ou simplement au format HTML.

Kiubi permet l’utilisation de n’importe quel thème graphique, moyennant certains aménagements rapides et simples à mettre en place.

Quelques prérequis sont cependant nécessaires avant de vous lancer. Vous devez disposer :
  • d'un site qui utilise un thème graphique personnalisé (vous trouverez toutes les informations utiles à ce sujet dans l'aide en ligne),
  • d'un accès FTP à votre thème graphique personnalisé (dont les informations de connexion sont disponibles dans la rubrique Préférences / Générales / Compte FTP de votre console d'administration),
  • de connaissances en HMTL, CSS et javascript ; vous n'aurez cependant jamais besoin de manipuler du PHP et des bases de données,
  • de votre Carte Bleue pour acheter un thème ;-)

Acheter un thème

Pour les besoins de cet article, nous utiliserons le thème Wordpress Editor (achetable ici et testable ). Mais vous pouvez utiliser le thème de votre choix, la méthodologie reste la même.

Petit rappel utile concernant l'utilisation des thèmes et de leurs licences : si vous utilisez un thème pour plusieurs sites, vous devez acheter à chaque fois une licence et cela même quand vous modifiez le thème d'un site à l'autre.
1 thème utilisé pour 1 site = 1 licence achetée !
Une fois le thème acquit, vous pouvez télécharger l'ensemble des fichiers sources qui le composent, à savoir : beaucoup (beaucoup) de fichiers PHP, des images, des feuilles de styles et des fichiers javascript.

La méthodologie utilisée

La procédure la plus simple pour adapter un thème Wordpress (TWP) à un thème Kiubi (TK) est de commencer par copier tous les éléments statiques du TWP : images, feuilles de styles, fichiers javascript et structure HTML.

Ces éléments sont alors ajoutés au TK et rendus dynamiques, c’est-à-dire capables d’afficher des informations issues de la console d’administration de Kiubi.

Les différents modules qui composent le thème (le contenu, les menus, les formulaires de contacts, etc.) sont séparés de la structure HTML principale et ajoutés aux widgets de Kiubi qui leur correspondent le mieux.
La structure HTML/CSS du site, les modules fonctionnels et le contenu sont strictement séparés et gérés de manière indépendante.
Pour finir, l’ensemble (template principal, widgets et contenu) est "réassemblé" directement via la console d’administration, par simple glissé-déposé.

Copier les éléments statiques

Dans un premier temps, nous allons récupérer les fichiers sources du TWP qui nous intéressent. Tous les fichiers du thème ne sont pas nécessaires, seuls les répertoires images, css, js ainsi que le fichier style.css sont utilisés. Copiez-les dans le répertoire /theme/fr/ du TK.

Pour la structure HTML du thème, inutile de chercher dans les fichiers PHP du TWP, allez simplement sur une page du site de démo. Par exemple sur http://themes.pixelwars.org/editor/typography/. Affichez le code source de la page et copiez tout le contenu de la balise <html>.

Ouvrez maintenant le fichier index.html d'un des templates principaux de votre TK, que vous trouverez dans le répertoire /theme/fr/templates/, et collez le code.

Mettre à jour les URLs

Une fois le code récupéré, nous allons commencer par mettre à jour les URLs qui pointent encore vers le site de démo, c'est-à-dire passer de :
<link href="/editor/wp-content/themes/editor-wp/css/main.css" rel="stylesheet" type="text/css" media="all" />
A des URLs dynamiques propres à Kiubi :
<link href="{racine}/{theme}/{lg}/css/main.css" rel="stylesheet" type="text/css" media="all" />
Et cela pour toutes les URLs des feuilles de styles et des fichiers javascript.

Dynamiser les metas

Pour l'instant, les metas et le contenu du template sont encore parfaitement statiques et n'intègrent aucun élément dynamique nécessaire à Kiubi. Nous allons donc immédiatement y remédier.

Copiez le contenu de la balise <head> de n'importe quel autre template du répertoire /theme/fr/templates/ et collez-le dans votre template principal (en plus des metas déjà présentes).

Ce code doit contenir les metas standards :
<title>{title}</title>
<meta name="description" content="{metaDescription}" />
<meta name="keywords" content="{metaKeywords}" />
Les informations pour les robots et les URLs canoniques :
{metaRobots}
{metaCanonical}
Les données pour Open Graph et les microsformats :
<meta property="og:title" content="{title}"/>
<meta property="og:type" content="website"/>
<meta property="og:url" content="http://{domaine}{canonical}"/>
<meta property="og:image" content="http://{domaine}{illustration_pagecourante}"/>
<meta property="og:site_name" content="{site_nom}"/>
<meta property="og:description" content="{metaDescription}" />
<meta property="og:street-address" content="{SOCIETE.societe_adresse}"/>
<meta property="og:locality" content="{SOCIETE.societe_ville}"/>
<meta property="og:postal-code" content="{SOCIETE.societe_cp}"/>
<meta property="og:country-name" content="{SOCIETE.societe_pays}"/>
<meta property="og:email" content="{SOCIETE.contact_email}"/>
<meta property="og:phone_number" content="{SOCIETE.societe_tel}"/>
<link rel="profile" href="http://microformats.org/profile/hcard" />
Les metas ajoutées via la console d'administration :
{Stylesheet}
{js_head}
Et les éléments ajoutés juste avant la balise </body> :
{js_body}
Prenez soin cependant à ne pas mettre de meta en double et à ne pas copier les liens vers les feuilles styles et les fichiers javascript par défaut, qui sont maintenant inutiles (car remplacés par ceux du TWP).

Dynamiser le contenu

Tous les éléments dynamiques qui composent votre site, comme les menus, le contenu rédactionnel, les slideshows, les articles du blog, les commentaires, le formulaire de contact, les fiches produits, le processus de commande, etc. bref, tout ce qui affiche quelque chose ajouté dans la console d'administration de Kiubi ou contrôlé par Kiubi, est disponible sous la forme de widgets (dont la liste et les fonctions sont disponibles ici).
Les widgets disposent tous de leurs propres paramètres et templates.
Les widgets ne sont pas inclus directement dans le template principal du site, mais ajoutés à une page, par glisser-déposer, directement dans la console d'administration de Kiubi.

Il est donc nécessaire de déclarer dans le template principal de votre site, les zones dans lesquelles des widgets peuvent être placés (avec les explications détaillées disponibles ici et ).

Chaque zone est déclarée grâce à une balise {ZONE.nomdelazone}. Le contenu de la balise <body> de votre template principal devrait donc ressembler à ça :
<div id="page">
	<header role="banner">
		<nav role="navigation">
			{ZONE.menu}
			{FILE "/fr/includes/search.html"}
			{ZONE.entete}
		</nav>
		<!-- BEGIN:logo_site -->
		<h1><a href="{racine}/"><img src="{racine}/media/{logo_site}" alt="{accroche_site}" /></a></h1>
		<!-- END:logo_site -->
	</header>
	<div id="content" role="main">
		{ZONE.contenu}
	</div>
	<footer role="contentinfo">
		{ZONE.piedepage}
		{FILE "/fr/includes/copyright.html"}
	</footer>
</div>
Les balises {FILE "/fr/includes/search.html"} et {FILE "/fr/includes/copyright.html"} agissent comme des includes et permettent donc d'ajouter là où elles sont placées le code du fichier qu'elles déclarent.

Le bloc <!-- BEGIN:logo_site --><!-- END:logo_site --> permet quant à lui d'afficher le logo du site ajouté via la console d'administration de Kiubi.

Nous disposons maintenant d'un template principal dynamique et prêt à recevoir des widgets, qu'il va falloir personnaliser en fonction du thème.

Nous allons illustrer cette opération avec 2 widgets : un menu et un exemple de contenu.

Personnaliser un widget : les billets

Le contenu rédactionnel du site, hors blog et catalogue produit, est présenté sous forme de billets. Chaque billet peut être considéré comme un paragraphe, un bloc de contenu et peut contenir du texte, des images, des liens, des vidéos, etc.
Vous pouvez disposer d'autant de types de billets différents que nécessaires, en fonction du thème et de vos besoins.
Une lecture de l'aide en ligne est utile pour parfaitement comprendre les possibilités offertes par les types de billets.

Pour personnaliser un billet, copiez le code du TWP qui correspond au modèle de contenu qui vous intéresse et collez-le dans le fichier /theme/fr/billets/post_simple/index.html.

Nous allons à nouveau ajouter au code du TWP les éléments propres à Kiubi afin de permettre un affichage dynamique du contenu :
<!-- BEGIN: main -->
<article id="post-{compteur}">
	<!-- BEGIN: titre -->
	<header class="entry-header">
		<h1 class="entry-title">{titre}</h1>
	</header>
	<!-- END: titre -->
	<div class="entry-content">
		<!-- BEGIN: sstitre -->
		<h2>{sstitre}</h2>
		<!-- END: sstitre -->
		<!-- BEGIN: texte10 -->
		<figure class="wp-caption gallery" style="width: {g_miniature_l}px;">
        	<a href="{racine}/media/g_vignette/{texte10}" class="fluidbox">
            <img src="{racine}/media/g_miniature/{texte10}" alt="{titre}"/></a>
			<figcaption class="wp-caption-text">{texte11}</figcaption>
		</figure>
		<!-- END: texte10 -->
		{texte1}
	</div>
</article>
<!-- END: main -->
Les balises {titre}, {sstitre}, {texte1}, {texte10} et {texte11} permettent d'afficher le contenu ajouté via la console d'administration. Chacune de ces balises correspond à un champ du formulaire créé automatiquement par Kiubi pour saisir le contenu.

Les blocs de type <!-- BEGIN: titre --><!-- END: titre --> sont utiles pour gérer un affichage conditionnel de leur contenu : si la balise {titre} est renseignée, le contenu du bloc est affiché, sinon il est masqué.

Pour afficher le contenu dans le site, il vous suffit de placer le widget Contenu d'une page libre dans la zone Contenu de votre page, directement dans la console d'administration.

Personnaliser un widget : le menu

Même objectif que précédemment, nous souhaitons associer le code du TWP avec le code du widget.

Copiez la partie du code source du TWP qui correspond au menu déroulant et collez-le dans le fichier /theme/fr/widgets/site_web/menu_v/index.html.

Ajoutez les éléments propres à Kiubi afin de passer de ça :
<div class="nav-menu">
	<ul id="nav" class="menu-custom">
		<li id="menu-item-859"><a href="/editor/">Home</a>
			<ul>
				<li id="menu-item-1063"><a href="/editor/home-alternate/">Home Alternate</a></li>
			</ul>
		</li>
	</ul>
</div>
A ça :
<!-- BEGIN: main -->
<!-- BEGIN: menu -->
<div class="nav-menu">
	<!-- BEGIN: niveau -->
	<ul id="nav" class="menu-custom">
		<!-- BEGIN: pagetype -->
		<!-- BEGIN: page -->
		<li id="menu-item-{compteur}"><a href="{lien}"  class="{actif}" target="{cible}">{page}</a>
		<!-- END: page -->
		<!-- BEGIN:sspage -->
		{sspage}
		<!-- END:sspage -->
		<!-- END: pagetype -->
		</li>
	</ul>
	<!-- END: niveau -->
</div>
<!-- END: menu -->
<!-- BEGIN: nomenu -->
<!-- END: nomenu -->
<!-- END: main -->
L'ensemble des blocs et des balises utilisés par le widget Menu vertical sont décrits ici.

Une fois l'opération effectuée, placez le widget dans la zone Menu de la page, via la console d'administration, avec les bons paramètres de configuration.

Pour aller plus loin

L’intégration complète d’un thème Wordpress, avec le blog, les formulaires de contact et 2 ou 3 modèles de mise en page supplémentaires, prend d'une demi-journée à une journée complète, une fois les mécanismes de Kiubi maitrisés. Comptez une à deux journées supplémentaires pour l’e-commerce. Bien entendu cela peut varier en fonction du thème utilisé.

Si vous souhaitez en savoir plus sur le sujet, un tutoriel très complet est disponible à cette adresse.

Et si vous cherchez à gagner du temps en utilisant des thèmes déjà adaptés à Kiubi, rendez-vous sur www.theme-and-co.fr.

L'atelier

La technologie derrière notre tracking pour le 4L Trophy

Si vous ne le savez pas, nous participons à notre manière au 4L trophy. Cela signifie qu'en plus de poser le nom de Kiubi sur la voiture, nous avons développé un site qui permet de suivre en temps réel l'équipage que nous soutenons.

Ce projet passe inévitablement par du développement spécifique et donc une exploitation de l'API de Kiubi.

Sur le papier

Le principe de fonctionnement est on ne peut plus simple :

  1. Le tracker GPS envoie à intervalle régulier sa position par l'intermédiaire de SMS à une clé 3G sur un serveur.
  2. Ce dernier enregistre les SMS qui arrivent dans une base de données.
  3. Un script va trier et décomposer les SMS pour en extraire l'itinéraire de la journée. Il va ensuite publier cet itinéraire dans le site Kiubi via l'API.
  4. Le site affiche une carte où est dessiné l'itinéraire.

Dans l'atelier

Dans la pratique, le développement fût... fun, avec son lot de problématiques inédites et sympathiques à régler.

D'abord, choisir un tracker. Un choix vite arrêté puisque tous les forums (car à notre surprise, il existe des forums sur le sujet, merci Internet) étaient unanimes : pour notre usage nous voulions le TK-102 en prenant bien garde de ne pas tomber sur une contrefaçon. Nous nous sommes donc tournés vers Geotraceur revendeur exclusif de ce modèle ainsi que de son kit d'alimentation 12V.

Vient ensuite le choix des opérateurs pour les deux cartes SIM. Après réflexion, notre choix s'est arrêté sur une Mobicarte Orange pour le tracker, afin de minimiser le risque de tomber en zone non-couverte au Maroc. Une carte SIM à 2€ de Free assurera les communication de la clé qui reste sur notre serveur, ce dernier n'ayant selon toute vraisemblances pas les mêmes contraintes qu'une 4L dans le désert.

Nous avons ensuite choisi un thème chez Themeforest et l'avons intégré sur Kiubi.

Enfin vient le coeur de l'application : faire fonctionner ensemble le code PHP exploitant l'API, le logiciel permettant d'intercepter, stocker et exploiter les SMS. Nous n'allons pas revenir dessus ici. Mais si cela vous intéresse, nous vous fournissons un tutoriel, les fichiers et le code Open source que vous pouvez ré-exploiter à votre guise.

Une fois le développement et les (nombreux) tests effectués, notamment en passant la frontière pour s'assurer que tout fonctionne même à l'étranger, nous avons posé le tracker sur le tableau de bord de la 4L.

Depuis Mardi, vous pouvez donc suivre en temps réel l'équipage #1461 de Célia et Sophie sur leur site et juger par l'exemple de ce qu'il est possible de faire avec l'API de Kiubi.

L'atelier

Utiliser l'API de Kiubi dans le Web to store

On vous en parle beaucoup de cette API. D'abord parce qu'on aime ce que vous pouvez en faire, mais aussi parce qu'on sait, et nous sommes loin d'être les seuls, que les APIs et leurs exploitations sont déjà le futur du Net et à fortiori du Web to store dont tout le monde parle en ce moment.

Une API, c'est avant tout un moyen de faire communiquer différents logiciels et services entre eux. Qu'il s'agisse d'un logiciel de comptabilité, d'un service Web, d'objets connectés ou d'une appli mobile, l'API permet d'appeler du contenu et d'en piloter l'édition.

Cependant, nous le savons, une API peut effrayer. Pourtant, il suffit de manipuler quelques minutes celle de Kiubi pour en comprendre l'immense potentiel et la facilité avec laquelle elle peut être utilisée dans un projet.

Prenons le cas de notre appli FlashBurger (on ne peut pas être toujours au top sur les noms de code) : pour un prix de revient inférieur à 300 euros, vous pouvez proposer à votre client, ici une sandwicherie, un service que même Mc Donalds peine encore à proposer.

Tous les grands principes de l'utilisation d'APIs sont présents :

  • piloter du contenu (une commande dans notre exemple);
  • utiliser plusieurs APIs tierces pour fournir un service : ici, faire communiquer Kiubi, un opérateur téléphonique et une imprimante grâce à leurs APIs respectives;
  • proposer grâce à cette synergie créée de toute pièce une expérience enrichie pour l'utilisateur.

Bien que nous détaillons la mise en place et la configuration de cette application dans un pas-à-pas sur notre Github, revenons sur les bases de son exploitation.

Les pré-requis

L'un des nombreux avantages de l'API de Kiubi, c'est sa capacité à être exploitée grâce à n'importe quel langage de programmation moderne. Dans ce cas précis, nous allons utiliser l'exécution de code PHP sur un serveur distant pour récupérer, éditer, exploiter et renvoyer des informations à Kiubi. C'est en ce sens que l'API permet de lier le meilleur du Cloud à la souplesse du dev spé. Matériellement, une Little Printer et une douchette à code-barre suffisent. En option, la souscription d'un service d'envoi de SMS peut compléter l'expérience utilisateur pour une somme modique.

Le principe de fonctionnement

Un dashboard est affiché sur le poste de vente du commerçant (un PC ou une tablette). Il s'agît en fait d'une page Web dans laquelle sont affichées des informations essentielles comme le nombre de ventes de la journée, le CA, les commandes à préparer, les commandes en attente, le nom des clients, etc. Cette page est générée par l'application PHP déposée sur votre serveur. Elle interroge le site de votre client toutes les 15 secondes afin d'afficher des informations toujours à jour.

Lorsqu'une commande en ligne est effectuée, cette page en est informée via l'API. L'impression d'un ticket reprenant son contenu, son destinataire et d'autres informations utiles est lancée sur la Little Printer et le commerçant en dispose immédiatement pour la préparation.

Une fois la commande prête, le commerçant scanne le code-barre à l'aide de sa douchette, toujours depuis le dashboard cité plus haut. Sans aucune autre manipulation de sa part, l'application passe le statut de la commande à "traitée" et un SMS est envoyé au client pour le prévenir que son sandwich est prêt et qu'il peut passer en boutique le récupérer.

Passer à la pratique

Cette application et son guide d'installation/utilisation sont Open Source et disponibles sur notre dépôt Github aux côtés de nombreux autres tutoriels relatifs à l'API de Kiubi.

Vous y retrouverez tout ce que vous devez savoir à propos de leurs installations et configurations. Il s'agît d'app et de pas-à-pas détaillés que vous pouvez utiliser tels quel ou adapter à vos projets.

Et si vous avez encore des questions, la documentation de l'API et notre support sont là pour ça ;)

Derniers billets postés

Haut de page