La Taverne à Tonton

Evolution du site Plugins SPIP

_Eric_ — 2013-05-24T09:37:33Z

	Titre	#
	Utiliser Tickets pour remonter les problème du site, les actions à réaliser voire les erreurs sur la présentation des plugins	#1
	Ajouter un menu des langues disponibles	#2
	Vérifier la gestion correcte des langues dans les pages	#3
	Mettre en place la gestion des tags en plus des catégories	#4
	Revoir la présentation du formulaire de sélection des plugins en vedette	#5

Mise à jour des Plugins pour SPIP 3.0

_Eric_ — 2013-05-22T13:25:34Z

Boussole

	Titre	#
	Ecrire l'article Boussole V2, usages avancés sur Contrib	#1
	Finir l'article Réalisation de la version v2 du plugin Boussole	#2
	Mise au point des erreurs retournées par le serveur	#3
	Déploiement de la version V2 du plugin Boussole sur tous les sites de la Galaxie	#4

PlugOnet

	Titre	#
	Supprimer l'aide sur les balises de paquet.xml qui ne fonctionne plus et le remplacer par des items de langue ou autres	#1
	Modifier les onglets en les présentant comme LangOnet	#2
	Revenir sur la désactivation de la génération du paquet.xml si celui-ci existe déjà	#3

Réalisation de la version v2 du plugin Boussole

_Eric_ — 2013-02-24T17:14:51Z

Création d'un plugin « Boussole SPIP »

Il suffit d'extraire du plugin Boussole v1 actuel les éléments suivants :

les logos contenus dans le dossier images/boussole/ dans une organisation identique,
les items de langue dédiées à la boussole SPIP, à savoir, le titre de la boussole et les noms, slogans et descriptions de tous les sites et groupes de sites. Ces items sont inclus dans un fichier de langue nommé boussole-spip_xx.php et de façon générale boussole-${alias_boussole}_xx.php.

En outre, il faut rapatrier le fichier XML boussole_spip.xml inclus dans le squelette boussole.spip.org à la racine du plugin Boussole SPIP en le renommant boussole-spip.xml et de façon générale boussole-${alias_boussole}.xml.

Coté paquet.xml il parait plus approprié :

de conserver le slogan du plugin Boussole v1 pour cette boussole
de fixer la version du plugin à celle de la boussole et donc de la supprimer dans le fichier XML
prendre un nouveau préfixe afin de laisser le préfixe boussole au plugin de gestion. Le préfixe adopté est « bouspip ».

Il n'y a pas d'intérêt à nécessiter le plugin Boussole.

Enfin, on déclare la boussole comme prête à être diffusée via le pipeline declarer_boussoles. Pour chaque boussole déclarée dans le tableau, l'index correspond à l'alias de la boussole et la valeur à un tableau associatif composé pour l'instant uniquement du préfixe du plugin (ou à la chaine vide sinon).
Par exemple, la boussole SPIP déclare :

function bouspip_declarer_boussoles($flux) {
$flux['spip'] = array('prefixe' => 'bouspip');
return $flux;
}

Télécharger

Ajout d'une fonction serveur au plugin Boussole

C'est une des évolutions majeures de la version v2. Plutôt que d'installer les informations de la boussole SPIP -ou d'une boussole personnalisée- sur chaque site utilisateur la v2 permet de créer un serveur qui fournira les informations de la boussole souhaitée à tous les sites utilisateurs sur demande.

Le mode serveur n'est pas actif par défaut. Pour l'activer il faut définir la constante _BOUSSOLE_ALIAS_SERVEUR qui désigne le nom du serveur. A partir de ce moment, le CRON serveur journalier s'active. Ce CRON scanne une fois par jour les boussoles déclarées - soit par le pipeline declarer_boussole pour un plugin, soit par ajout manuel dans la globale $serveur_boussoles_disponibles - et crée les fichiers XML complets de chacune d'entre elles ainsi que la liste des boussoles hébergées.

Le fichier XML complet est issu du fichier XML de base d'une boussole en plugin (identique aux version précédentes) auquel on ajoute les traductions sous format multilingues et les adresses des logos. Pour une boussole manuelle, seul les logos sont à calculer, les traductions étant déjà incluses dans le fichier XML de base.

Pour fournir les informations complètes sur une boussole, le serveur possède une action serveur_informer_boussole qui renvoie le fichier XML complet de la boussole demandée ou une erreur.

Pour fournir la liste des boussoles, le serveur possède cette fois une action serveur_lister_boussoles qui renvoie le fichier XML des boussoles hébergées.

Modifications de la fonction client du plugin Boussole

Evolution v2 du plugin Boussole

_Eric_ — 2013-02-02T11:41:05Z

Rappel du fonctionnement de la version v1 actuelle

Le plugin Boussole v1 est basé sur les principes suivants :

une boussole est définie par un fichier XML, la liste des logos et les items de langue des noms, slogans et descriptions des sites et groupes concernés ;
le fichier XML est lu une fois par jour par le plugin et ses informations sont mises à jour dans la base de données à l'exception des traductions et des logos bien entendu ;
le fichier XML de la boussole SPIP est chargé automatiquement à l'activation du plugin Boussole. Ce fichier fait partie du squelette boussole.spip.org de la galaxie SPIP ;
les items de langue de la boussole SPIP ainsi que ses logos font partie du plugin Boussole ;
les sites d'une boussole sont regroupés selon cinq groupes définis une fois pour toute pour toutes les boussoles mais dont l'utilisation est optionnelle et personnalisable ;
tout site souhaitant afficher la boussole SPIP doit activer le plugin Boussole.

On note d'emblée qu'il y a, dans le plugin Boussole v1, un mélange entre fonctions de service généralistes et contenu de la boussole SPIP à l'origine des problèmes discutés ci-après.

Problèmes posés par la version v1 actuelle

Les problèmes de cette version v1 sont principalement visibles lors des mises à jour des boussoles, et particulièrement, de leurs items de langue et de leurs logos.

En effet, étudions un par un les différents cas de mise à jour d'une boussole -par exemple, la boussole SPIP-, à savoir :

modification de l'url ou du statut d'activité d'un site de la boussole,
ajout d'un site dans la boussole,
modification d'une information traduite ou du logo d'un site déjà présent dans la boussole,
et suppression d'un site de la boussole.

1- Modification d'une URL ou de l'activité d'un site

Ces deux informations sont contenues exclusivement dans le fichier XML de description de la boussole. Lors de la mise à jour quotidienne de la boussole via le CRON SPIP, ces informations sont relues et mises à jour en bdd.

En outre, comme le fichier XML n'est pas inclus dans le « plugin » Boussole mais disponible dans le « squelette » boussole.spip.org, chaque site utilisant la boussole SPIP sera mis à jour sans souci dés l'instant où le site boussole.spip.org est mis à jour. Ce fonctionnement est donc optimal car il ne nécessite la mise à jour que d'un seul site.

2- Ajout d'un site

L'ajout d'un site demande en premier lieu de modifier le fichier XML de la boussole pour y intégrer une balise . Comme pour le cas 1, tous les sites utilisant la boussole SPIP vont voir leur base de données mise à jour avec ce site.

Pour autant, si on s'arrête là, le site n'a ni logo ni aucune traduction disponible. Il faut donc ajouter les logos dans le plugin Boussole (emplacement images/boussole/) et les traductions comme des items de langue dans les modules lang/boussole_xx.php.

Mais à partir de ce moment, il faut que tous les sites utilisant la boussole SPIP mettent à jour le plugin lui-même afin de récupérer les traductions et le logo. Ce fonctionnement est pénible et l'on risque de voir longtemps des boussoles avec un nom ou un slogan réduit à celui de l'item de langue associé.

3- Modification d'une information traduite ou du logo

Cette modification est similaire au cas 2 pour ce qui est des traductions et du logo. Il faudra donc mettre à jour le plugin Boussole sur tous les sites utilisateur.

4- Suppression d'un site

Que ce soit en passant le site en inactif dans le fichier XML de la boussole ou en supprimant complètement la balise, cette modification sera prise en compte par tous les sites utilisateur lors de la mise à jour quotidienne pour autant que le site boussole.spip.org ait été upgradé. Comme la base de données ne fera plus référence à ce site, les affichages seront donc corrects sans autre intervention.

Néanmoins pour être complet lors d'une suppression, les traductions et le logo devraient aussi être supprimées du plugin Boussole. Ce cas est un peu bancal car les sites fonctionneront correctement avec des versions du plugin Boussole obsolètes.

Nouvelles exigences pour une v2

L'objectif de cette version v2 est donc de simplifier les mises à jour d'une boussole pour les sites utilisateur en ne les obligeant plus à upgrader leur plugin Boussole.

On peut exprimer cet objectif en plusieurs exigences plus techniques :

EX1 : il faut séparer les composants d'une boussole -XML, logo et traductions- du plugin affichant la dite boussole.
EX2 : il faut un mécanisme de mise à jour d'une boussole sur chaque site utilisateur qui permette de récupérer toutes les informations -y compris les traductions et les logos- d'une façon automatique sans avoir à mettre à jour le plugin Boussole.
EX3 : il faut donc un « serveur » qui fournisse sur demande les informations complètes sur une boussole.
EX4 : il faut conserver la possibilité pour une boussole d'avoir ses noms, slogans et descriptions traduits via le site Traduire SPIP.
EX5 : il faut limiter les échanges entre le « serveur » et les sites utilisateur.
EX6 : il faut assurer une compatibilité ascendante en faisant en sorte que les sites utilisateur n'aient qu'une mise à jour de leur plugin Boussole à faire et rien d'autre.
EX7 : il faut étendre l'utilisation des groupes en permettant de définir leur liste, leur alias.

Solutions possibles pour répondre aux exigences v2

Les exigences EX1 et EX4 conduisent à scinder le plugin en deux :

d'un coté les fonctionnalités de gestion des boussoles dans un plugin,
et de l'autre les composants -XML, logos, traductions- de la boussole SPIP proprement dite dans un format qui autoriserait les traductions.

L'exigence EX3 induit la création d'une fonction serveur qui permet de mettre à disposition des sites client les informations d'une boussole (sites, groupes, traductions) ainsi que ses logos. Cette fonction pourrait être à la base d'un nouveau plugin serveur de boussoles.

Néanmoins, le meilleur compromis semble être de regrouper les fonctions serveur et client dans un même plugin dérivé du plugin Boussole actuel et de sortir dans un plugin Boussole SPIP les composants de cette boussole, ce qui répondrait aux exigences EX6 et EX4.

Cependant, il peut être intéressant pour d'autres boussoles personnalisées, d'autoriser une diffusion simple sans passer par un plugin.

Pour répondre à l'exigence EX2, le plugin Boussole actuel doit évoluer pour permettre la mise à jour des boussoles non plus par la lecture d'un XML mais pas la réception des informations via une requête adressée à un serveur (réponse JSON ou XML). En revanche, les logos doivent être accessibles sur ce même serveur dans un espace ouvert à leur lecture à l'instar de SVP et des logos de plugins.

Néanmoins, comme requis par l'exigence EX5, il sera nécessaire de limiter au strict minimum les requêtes au serveur étant donné que le nombre de sites client peut être important. Un mécanisme type md5 devra être ajouté soit à la fonction d'upgrade client actuelle soit à la fonction de réponse du serveur.

Pour l'exigence EX7, il faut pouvoir gérer les alias de groupes quels qu'ils soient.

Rainette v2, mise en œuvre du multi-services

_Eric_ — 2012-12-25T17:08:07Z

Les modèles standard

Dans la version v1 de Rainette, l'insertion de données météorologiques dans un squelette se fait toujours via un modèle standard :

rainette_conditions, pour les conditions temps réel,
rainette_previsions, pour les prévisions à n jours,
rainette_infos, pour les informations sur la ville,

qui fait uniquement appel à un filtre dont le nom est tiré de celui du modèle. Pour le modèle rainette_conditions, par exemple, le code de la version v1 de Rainette est le suivant :

[(#ENV{code}|rainette_coasse_conditions{
#ENV{sous_modele,conditions_tempsreel}})]

Télécharger

On s'aperçoit que deux arguments sont toujours passés à ces modèles - et donc aux filtres - à savoir :

le code du lieu
et le sous-modèle qui définit la structure exact de l'affichage.

Afin de conserver dans la version v2 de Rainette une compatibilité ascendante avec ces appels, la première évolution consiste à ajouter en dernier paramètre des filtres le service utilisé, qui par défaut prendra la valeur du service Weather.com(r). Cela correspond dans les modèles standard à un paramètre « service ». Ce paramètre prend les valeurs « weather », « wwo », « wunderground » et « yahoo ».

Le code du modèle rainette_conditions est donc modifié comme suit :

[(#ENV{code}|rainette_coasse_conditions{
#ENV{sous_modele,conditions_tempsreel},
#ENV{service, weather}})]

Télécharger

Le chargement des données météorologiques

Le chargement des données météorologiques est confié à une fonction unique charger_meteo() qui est appelé par les filtres rainette_coasse_xxxx(). Cette fonction a aussi évolué en v2 pour, d'une part, intégrer l'argument service et d'autre part, revêtir une forme standard pour les conditions, prévisions et infos.

Cette fonction, suivant qu'elle lit le cache ou qu'elle le recrée en interrogeant le service distant concerné, appelle une liste de fonctions standardisées pour chaque service et renvoie le fichier cache correspondant à la demande. Le code est le suivant :

function inc_charger_meteo_dist($lieu, $mode='previsions', $service='weather') {
// Traitement des cas ou les arguments sont vides
if (!$mode) $mode = 'previsions';
if (!$service) $service = 'weather';
// En fonction du service, on inclut le fichier des fonctions
// Le principe est que chaque service propose la même liste de fonctions d'interface dans un fichier unique
include_spip("services/${service}");
// Construire le nom du fichier cache
$cacher = "${service}_service2cache";
$cache = $cacher($lieu, $mode);
// Déterminer la période de renouvèlement du cache
$reloader = "${service}_service2reload_time";
$reload_time = ($mode == 'previsions') ? $reloader('previsions') : $reloader('conditions');
if (!file_exists($cache)
OR (($mode != 'infos') AND (!filemtime($cache) OR (time()-filemtime($cache)>$reload_time)))) {
// Construire l'url de la requête
$urler = "${service}_service2url";
$url = $urler($lieu, $mode);
// Acquérir le flux XML ou JSON dans un tableau
$acquerir = "${service}_url2flux";
$flux = $acquerir($url);
// Convertir le flux en tableau standard pour la mise en cache
if ($mode == 'infos')
$convertir = "${service}_flux2infos";
else
$convertir = ($mode == 'previsions') ? "${service}_flux2previsions" : "${service}_flux2conditions";
$tableau = $convertir($flux, $lieu);
// Ajout du crédit affiché en regard de chaque modèle
$crediter = "${service}_service2credits";
$tableau['credits'] = $crediter();
// Pipeline de fin de chargement des données météo. Peut-être utilisé :
// -- pour effectuer des traitements annexes à partir des données météo (archivage, par exemple)
// -- pour ajouter ou modifier des données au tableau (la modification n'est pas conseillée cependant)
$tableau = pipeline('post_chargement_meteo',
array(
'args' => array('lieu' => $lieu, 'mode' => $mode, 'service' => $service),
'data' => $tableau));
// Création du nouveau cache
ecrire_fichier($cache, serialize($tableau));
}
return $cache;
}

Télécharger

Le codage d'un service

La structure de codage d'un service est la suivante :

chaque service est codé dans un fichier PHP portant le nom du service - weather.php par exemple,
et inclut une liste de fonctions standard appelées par la fonction de chargement des données précitée ainsi que toutes les sous-fonctions et constantes propres.

Les fonctions standardisées à coder pour chaque service sont :

${service}_service2cache, qui renvoie le nom du fichier de cache calculé.
${service}_service2url, qui renvoie l'url complète de la requête correspondant à la demande.
${service}_service2reload_time, qui renvoie la période de renouvèlement des données en fonction du type.
${service}_url2flux, qui renvoie la chaine correspondant au flux XML fourni par le service concerné et correspondant à la demande.
${service}_flux2conditions, ${service}_flux2previsions et ${service}_flux2infos, qui renvoient le tableau des données collectées dans le format standardisé par Rainette prêt à être mis en cache.
${service}_service2credits, qui renvoie le code HTML des crédits affichés dans chaque modèle conformément aux termes d'utilisation du service.

La fonction `${service}_service2cache`

Cette fonction calcule pour chaque service le nom du fichier cache en fonction du lieu et du type de données requis. De façon générale, ce fichier .txt est stocké dans un sous-dossier du cache SPIP nommé rainette/${service}/.

La structure du nom du fichier est :${lieu}_${typedonnees} où :

${lieu} est le nom du lieu en majuscule pour lequel les caractères tels que les points, virgules, slash, plus... sont remplacés par un underscore.
${typedonnees} est le type de données, « infos », « conditions » ou « previsions ».

Pour le service Wunderground uniquement et dans le cas où l'on utilise les libellés météorologiques traduits de ce service, le nom est suffixé par le code de la langue ${lieu}_${typedonnees}-${langue} .

La fonction `${service}_service2url`

Cette fonction construit l'url de la requête adressée au service distant en fonction de la demande qui lui est faite. Quand l'API du service l'autorise la fonction élabore la requête la plus optimisée par rapport à la demande : les conditions, les prévisions et les infos font l'objet de requête différente. C'est le cas de tous les services à l'exception de Yahoo Weather.

Suivant le service il est possible ou pas de préciser le système d'unités utilisé pour les valeurs numériques et bien entendu la clé d'inscription. Pour Wunderground, il est aussi possible de préciser la langue des textes.

La fonction `${service}_service2reload_time`

Cette fonction renvoie pour chaque service la valeur de la période de renouvèlement des données météo en fonction de la demande, conditions ou prévisions. Chaque service défini un tableau associatif statique dont les index sont les type de données.

La fonction `${service}_url2flux`

Cette fonction récupère le flux en réponse à la requête formulée et renvoie un tableau brut après phrasage du XML ou du JSON.

Cette fonction aurait pu être généralisée à l'ensemble des services si le format de retour était toujours le même, en l'occurrence du XML. Mais il existe des services ne supportant que le format de réponse JSON. Pour garder cette possibilité dans le futur, on conserve cette fonction dans l'API de chaque service mais on fournit des sous-fonctions standard dans inc/phraser.php :

url2flux_xml()
url2flux_json()

La fonction `${service}_flux2infos`

Cette fonction convertit le tableau brut phrasé à partir du flux XML ou JSON par la fonction ${service}_url2flux en tableau standardisé pour l'affichage dans les modèles des informations géographiques sur le lieu.

Le tableau associatif résultant est composé des index :

Index	Description	Format	Disponibilité
“ville”	nom complet du lieu souvent complété du pays	chaine	tous
“région”	nom de la région	chaine	wwo, yahoo
“longitude”	longitude du lieu	réel	tous
“latitude”	latitude du lieu	réel	tous
“population”	décompte de la population du lieu	entier	wwo

Quand l'information n'est pas disponible la valeur de l'index concerné est positionnée à chaine vide.

La fonction `${service}_flux2conditions`

Cette fonction convertit le tableau brut phrasé à partir du flux XML ou JSON par la fonction ${service}_url2flux en tableau standardisé pour l'affichage dans les modèles des conditions météorologiques temps réel sur le lieu.

Le tableau associatif résultant est composé des index :

Index	Description	Format	Disponibilité
— Données d'observation —
“derniere_maj”	date de l'observation	chaine	tous
“station”	station météo origine de l'observation	chaine	weather, wunderground
— Températures —
“temperature_reelle”	température mesurée	entier	tous
“temperature_ressentie”	température ressentie en tenant compte du refroidissement éolien. Si la donnée n'est pas fournie par le service elle est calculée	entier	tous
— Données anémométriques —
“vitesse_vent”	vitesse du vent	réel	tous
“angle_vent”	direction angulaire du vent	entier	tous
“direction_vent”	direction textuelle abrégée selon une rose des vents à 16 points en anglais (E,ESE, WNW...). Si la donnée n'est pas fournie par le service elle est calculée	chaine	tous
— Données atmosphériques —
“humidite”	pourcentage d'humidité	entier	tous
“point_rosee”	température du point de rosée	entier	weather, wunderground
“pression”	pression barométrique	réel	tous
“tendance_pression”	tendance barométrique (stable, à la hausse ou à la baisse). Pour les services autres que weather, elle est transcodée dans le référentiel weather (steady, rising, falling)	chaine	weather, wunderground, yahoo
“visibilite”	distance de visibilité des objets	réel	tous
— Etats météorologiques natifs (non utilisés dans les modèles) —
“code_meteo”	code désignant l'état météorologique. Suivant le service ce code est un entier ou une chaine (wunderground)	entier / chaine	tous
“icon_meteo”	url de l'icône représentant l'état météorologique	chaine	wwo, wunderground
“desc_meteo”	description littérale de l'état météorologique. Seul wunderground fournit une description traduite	chaine	tous
— Etats météorologiques calculés —
“resume”	résumé de l'état météorologique. Voir ci-après pour en savoir plus	divers	tous
“icone”	icône illustrant l'état météorologique. Voir ci-après pour en savoir plus	entier / tableau	tous
“periode”	0 pour le jour, 1 pour la nuit	entier	wwo, wunderground

Quand l'information n'est pas disponible la valeur de l'index concerné est positionnée à chaine vide.

La fonction `${service}_flux2previsions`

Cette fonction convertit le tableau brut phrasé à partir du flux XML ou JSON par la fonction ${service}_url2flux en tableau standardisé pour l'affichage dans les modèles de prévisions météorologiques sur le lieu.

Le tableau associatif résultant est composé des index :

Index	Description	Format	Disponibilité
— Données d'observation —
“date”	date de l'observation	chaine	tous
“index”	numéro du jour dans le tableau	entier	tous
— Lever et coucher du soleil —
“lever_soleil”	heure de lever du soleil	chaine	weather
“coucher_soleil”	heure de coucher du soleil	chaine	weather
— Données jour —
“temperature_jour”	température	réel	tous
“code_icone_jour”
“vitesse_vent_jour”	vitesse du vent	réel
“angle_vent_jour”	direction angulaire du vent	entier
“direction_vent_jour”	direction textuelle abrégée selon une rose des vents à 16 points en anglais (E,ESE, WNW...). Si la donnée n'est pas fournie par le service elle est calculée	chaine
“risque_precipitation_jour”	risque de précipitation en pourcentage	entier
“humidite_jour”	pourcentage d'humidité	entier
— Données nuit —

La fonction `${service}_service2credits`

Cette fonction ajoute à chaque tableau standardisé pour l'affichage dans les modèles les crédits propres à chaque service (se référer aux conditions d'utilisation pour en savoir plus sur leur format).

Le tableau associatif résultant intègre un index supplémentaire “crédits” qui est un tableau comportant les sous-index suivants :

Sous-index	Description	Format	Disponibilité
“lien”	URL du site de référence du service	chaine	tous
“titre”	Attribut title du lien affiché	chaine	wwo
“logo”	Logo du service à afficher. Si le logo n'est pas fourni alors un libellé contenant le nom du service est affiché	chaine	wunderground

A minima il est nécessaire de fournir un lien vers le site de référence du service. Quand l'information n'est pas disponible la valeur de l'index concerné est positionnée à chaine vide.

Gestion de la configuration des plugins

_Eric_ — 2012-11-04T14:36:19Z

Le mécanisme de configuration actuel

Nombre de plugins utilisent des variables de configuration pour paramétrer les traitements qu'ils proposent. Initialement motorisé par le « très utilisé » plugin CFG, le mécanisme de configuration est maintenant proposé nativement par le noyau de SPIP 3.0 ce qui entraine l'abandon progressif de CFG.

Le mécanisme de configuration de SPIP 3.0 est basé principalement, comme l'explique l'article Configurer une fonctionnalité de votre site, ou un plugin :

sur la technique des formulaires CVT
sur la méthode de stockage dans la table « spip_meta » ou dans une table déclarée dans l'attribut « meta » de la balise du nouveau fichier XML de description d'un plugin (paquet.xml).
et sur l'API de manipulation des variables de configuration issue de CFG, à savoir, la balise #CONFIG en HTML et les fonctions lire_config(), ecrire_config() et effacer_config() en PHP.

Cette évolution proposée par SPIP 3.0 permet de rationaliser la mise en place d'une configuration au sein d'un plugin mais laisse encore des points ouverts ou du moins non standardisés comme :

l'affectation des valeurs par défaut,
la possibilité d'exporter ou d'importer une configuration,
la suppression automatique des variables de configuration en base de données suite à la désinstallation complète du plugin.

Affectation des valeurs par défaut

La problématique

Aujourd'hui deux techniques cohabitent dans les plugins sans que l'une ou l'autre ne soit réellement adoptée comme une pratique standard malgré les explications donnée dans l'article cité ci-dessus :

Les valeurs par défaut sont positionnées à chaque fois qu'on utilise une fonction de l'API de configuration : par exemple, #CONFIG{variable, défaut} ou lire_config(variable, défaut).
Les valeurs par défaut sont chargées une fois pour toute lors de l'activation du plugin via la fonction d'installation du schéma de données ${prefixe}_upgrade(). Dans ce cas, il n'est plus utile de préciser la valeur par défaut quand on manipule une variable de configuration en HTML ou en PHP.

La première technique devient rapidement pénible quand la liste des variables s'allonge et de surcroît multiplie les risques d'erreur d'affectation par défaut.

La deuxième technique simplifie grandement l'écriture dans le code HTML ou PHP et le rend aussi plus maintenable et évolutif. Cette initialisation à l'installation permet aussi d'envisager l'utilisation du mécanisme d'upgrade de schéma pour faire évoluer la configuration : elle semble donc à privilégier.

Les pistes de solution

Adopter en standard cette technique d'initialisation à l'installation d'un plugin, revient à faire évoluer les pratiques de codage mais aussi le noyau de SPIP 3.0 (très peu car tout existe ou presque). Une configuration de plugin nécessiterait donc :

d'utiliser systématiquement l'attribut « schema » d'un plugin pour décrire l'existence d'une configuration de plugin tout autant que l'existence d'une modification de la structure de la base de données. Le principe d'évolution du schéma s'appliquerait donc indifféremment à la configuration ou à la base de données.
de déclarer la liste des couples (variable de configuration, valeur par défaut) du plugin.
d'utiliser la fonction ${prefixe}_upgrade pour déclarer les évolutions de la configuration du plugin dans le temps.
de continuer à utiliser l'attribut « meta » du plugin pour décrire la table de stockage des variables de configuration si celle-ci est différente de spip_meta.

En ce qui concerne la déclaration afin de se rapprocher du mécanisme actuel de création de la base on pourrait utiliser un pipeline declarer_config pour définir les variables de configuration et leur valeur par défaut dans une variable globale $config_plugins indexée par le préfixe du plugin.

function prefixeplugin_declarer_config($config) {
$config['prefixeplugin'] = array(
// Variables de configuration du plugin
'nom_meta1' => array(
"variable11" => "defaut11",
"variable12" => "defaut12",
"variable13" => "defaut13",
"variable14" => "defaut14"),
'nom_meta2' => array(
"variable21" => "defaut21",
"variable22" => "defaut22"),
);
return $config;
}

Télécharger

Cette fonction pourrait être insérée dans le même fichier que celui de la base si il existe ou du moins dans le dossier base/ du plugin. Il est également possible d'améliorer cette déclaration pour introduire plus finement les types et méthodes de stockage des variables de configuration (un peu comme le faisait CFG).

Dans le même genre d'idée SPIP fournirait une fonction maj_config('prefixeplugin') pour déclencher la création des variables de configuration du plugin. Pour l'upgrade de la configuration il est déjà possible aujourd'hui d'utiliser une fonction dédiée par upgrade ou les fonctions ecrire_config() ou effacer_config().

function prefixeplugin_upgrade($nom_meta_base_version, $version_cible) {
$maj = array();
$maj['create'] = array(
array('maj_tables',array('table1','table2')),
array('maj_config', array('prefixeplugin')),
);
$maj['0.2.0'] = array(
array('sql_alter',"bla bla..."),
array('maj_config_020'),
);
$maj['0.3.0'] = array(
array('sql_alter',"bla bla..."),
array('ecrire_config','prefixeplugin/variable', 'defaut'),
);
include_spip('base/upgrade');
maj_plugin($nom_meta_base_version, $version_cible, $maj);
}
function maj_config_020() {
// code de l'upgrade...
}

Télécharger

A ce stade, il reste un petit bémol avec les formulaires de configuration. En effet, il y a une dernière redondance à gérer car le formulaire définit aussi :

le nom des metas dans la base soit en utilisant son nom ou un input caché
et le nom des variables en utilisant les attribut name des inputs.

Il faudrait donc assurer la cohérence des deux définitions. A réfléchir !

Autre chose, sauf à utiliser des variables obligatoires dans le formulaire de configuration il faut s'assurer qu'il n'est pas possible d'effacer une valeur en la supprimant dans un input du formulaire sinon une écriture type lire_config('variable') pourrait être incorrecte. Peut-être faudrait-il appeler une fonction de vérification/positionnement du défaut spécifique au processus de validation du formulaire de configuration.

Sauvegarde et restauration de variables de configuration

La problématique

Quand le nombre de variables de configuration augmente, repasser tous les formulaires de configuration en revue pour appliquer une configuration donnée peut s'avérer pénible.

Même si d'aucuns, à juste titre, ne sont pas fans des configurations « clicodrome », force est de constater que la multiplication des plugins activés sur un site fait de toute façon enfler la configuration globale du site sans que l'on puisse distinguer celle de SPIP de celle des plugins. De ce fait, la nécessité de sauvegarder et de restaurer cette configuration des plugins pour des besoins de distribution par exemple n'est plus à négliger.

Un squelette comme Sarka-SPIP possède entre 100 et 200 variables de configuration réparties dans plus de 20 formulaires (donc 20 metas en base de données). Le squelette intègre donc un mécanisme spécifique de sauvegarde/restitution de la configuration basée sur des fichiers texte contenant les metas sérialisées.

Le noiZetier, le squelette Aveline et d'autres plugins ont aussi été confrontés à la même problématique et de là est né le plugin IEConfig, qui porte bien mal son nom, car il permet d'importer et d'exporter une liste de metas dans un même fichier au format YAML et non de configurer Internet Explorer ! Néanmoins, pour traiter ces metas de configuration, IEConfig demande à chaque plugin de (re)définir sa liste de metas de configuration dans un pipeline dédié.

Actuellement, IEConfig est utilisé de façon sporadique et n'est pas un standard même si il est intégré « à la hussarde » dans les plugins de la distribution SPIP 3.0. Il convient donc de trouver un solution générique SPIP à cette problématique.

Les pistes de solution

A partir du moment où l'on utilise la déclaration des variables de configuration des plugins comme proposée plus haut, il est toujours possible de connaître :

la liste des metas de configuration d'un plugin
la liste des metas de configuration de tous les plugins
et donc a fortiori, par différence, la liste des metas de configuration de SPIP si on considère une situation où ce mécanisme est en place pour tous les plugins [1].

Il est alors facile d'imaginer un mécanisme d'exportation et d'importation de la configuration intégré à SPIP ou au plugin Dump voire à un plugin dédié. Le format du fichier d'export reste à déterminer : YAML, XML, Texte... Il pourrait être créé dans tmp/dump afin de ne pas multiplier les répertoires et s'appeler config_[${prefixeplugin}|plugins|spip]_${date_heure} en fonction du choix d'exportation.

On pourrait aussi envisager des pages d'export et d'import de la configuration à l'instar de celles de sauvegarde et restauration de la base de données proposée par le plugin Dump. Le choix entre un plugin donné, tous les plugins et SPIP serait proposé systématiquement.

Nettoyage des variables de configuration

La problématique

Au fur et à mesure que l'on installe, active, désactive ou désinstalle des plugins, la table spip_meta s'engorge d'enregistrements inutiles sauf si la configuration des plugins est contenue dans une table dédiée désignée par l'attribut « meta » de la balise (cas très rare).

Si cela n'est pas plus dangereux que de laisser les tables du plugin Notation sans qu'elles soient utilisées, ce n'est pas non plus satisfaisant. Je suis d'ailleurs tombé sur un problème récemment où ayant supprimé le plugin STEP par FTP, je n'ai donc pas détruit proprement la table spip_plugins. Or, en migrant à SPIP 3.0 j'ai installé automatiquement SVP qui crée lui aussi une table spip_plugins : le résultat a été un peu surprenant.

Désinstaller un plugin devrait donc toujours s'accompagner de l'effacement en base de données de toutes ses traces.

Les pistes de solution

Là encore la déclaration des variables de configuration permettrait de s'acquitter automatiquement de cette tache. En appelant une fonction vider_config_plugin('prefixeplugin') dans la fonction actuelle ${prefixe}_vider_tables() ou peut-être en l'intégrant systématiquement dans le mécanisme de désinstallation on pourrait supprimer les enregistrements des metas du plugin.
Cette fonction pourrait aussi s'occuper de supprimer automatiquement la meta prefixeplugin_base_version.

En outre, l'existence d'une fonction d'export des variables de configuration permettrait de sauvegarder la configuration du plugin avant de la supprimer complètement.

[1] Il convient aussi de réfléchir à déclarer les variables de configuration de SPIP pour identifier clairement cette liste lors de l'export et de l'import et pouvoir nettoyer la table spip_meta pendant la phase de transition.

Évolutions de la gestion des thèmes sous SPIP 3

Joseph — 2012-10-31T09:27:48Z

Cet article est maintenant en discussion sur SPIP.blog.

La gestion des thèmes dans SPIP a connu de multiples évolutions. La situation actuelle n'est pas satisfaisante, avec deux logiques différentes qui coexistent (SVP et Zen-Garden). Nous tentons ici de poser les bases d'une discussion sur les évolutions possibles de la gestion des thèmes sous SPIP 3.

Historique

Au cours des dernières années, plusieurs approches de gestion des thèmes / habillages ont été proposées. On pourra se référer par exemple au plugin Habillages ou à Sktheme (tous deux développés pour SPIP 1.9.2).

Le projet Zpip développé à partir de 2009 pour SPIP 2.0 et supérieur a apporté entre autres :

un mécanisme de génération des pages HTML organisés en blocs (contenu, navigation, extra...) ;
une convention de nommage (ou nomenclature Z) des classes CSS utilisées par un squelette.

Plus précisément, dans le contexte Zpip 1, le squelette Zpip-dist fournit à la fois le moteur de génération des pages et un contenu HTML des blocs de page suivant cette nomenclature Z.

Est alors délégué à un thème Z de fixer le layout de la page, c'est-à-dire l'organisation des blocs dans la page (mais pas leur contenu) et de fournir un habillage CSS correspondant à la nomenclature Z.

Cette notion de nomenclature est importante car elle définit un formalisme permettant d'avoir plusieurs variations de squelettes et plusieurs habillages différents pouvant fonctionner ensemble.

Les thèmes Z se présentent sous la forme d'un plugin (voir Écrire un thème pour Zpip) avec cependant quelques éléments qui diffèrent par rapport aux autres plugins :

Historiquement, tous les thèmes avait le même préfixe theme afin d'assurer qu'un seul thème puisse être activé à la fois.
Un thème peut soit être installé dans le répertoire plugins/ et être activé classiquement, soit être installé dans un répertoire themes/ pour être activé via Zen-garden un gestionnaire de thèmes.
Un thème ne peut pas définir de dépendances ou user des pipelines car s'il est activé via Zen-Garden, ces dépendances et pipelines ne seront pas prises en compte. En effet, Zen-Garden n'active pas un thème (au sens de l'activation d'un plugin) mais ajoute simplement le répertoire du plugin dans la liste des chemins.

Zen-Garden a évolué pour pouvoir gérer également les thèmes d'autres squelettes. C'est le cas notamment des thèmes pour Sarka-SPIP. Zen-Garden filtre la liste des thèmes proposées à l'utilisateur en se basant sur la balise utilise du fichier plugin.xml des thèmes disponibles localement sur un site. Ainsi, si Zpip est actif sur le site, Zen-Garden n'affichera que les thèmes ayant dans leur fichier plugin.xml.

En mai 2011, et suite à la réflexion menée sur le concept de paquets et de plugins, les thèmes disposent dorénavant de leur propre préfixe (un préfixe différent par thème). Cela permet de gérer correctement le numéro de version de chaque thème et leur gestion, notamment par SVP. Par ailleurs, les thèmes deviennent identifiés via une catégorie de plugins spécifique (la catégorie thèmes).

À partir de septembre 2011 (voir commit 51365), Zen-Garden prends en compte à la fois les thèmes installés dans le répertoire themes/ et ceux installés dans plugins/. De plus, Zen-Garden masque dorénavant les thèmes dans la liste des plugins (exec=admin_plugin) dans l'interface privée de SPIP (voir commit 51644).

Situation actuelle et limites

SPIP 3 embarque SVP, un nouveau système de gestion des plugins/paquets permettant notamment de télécharger facilement un paquet, de gérer les mises à jour et de prendre en compte les dépendances.

Site utilisant SVP sans Zen-Garden

Sur un site utilisant seulement SVP sans Zen-Garden, l'installation d'un thème doit se faire au même titre que les autres plugins. Autrement dit, le thème doit être installé dans le répertoire plugins/. Il revient cependant à l'utilisateur d'être vigilant à n'activer qu'un seul thème à la fois, SVP permettant actuellement d'activer plusieurs thèmes à la fois. De plus, c'est à l'utilisateur de s'assurer que le thème activé correspond bien au squelette qu'il utilise. Il n'y a pas d'information spécifique (excepté peut-être dans le descriptif du plugin) indiquant s'il s'agit d'un thème pour Zpip 1, Zpip 2 ou Sarka-SPIP (ou autre...).

Site utilisant SVP et Zen-Garden

Lors de l'utilisation conjointe de SVP et de Zen-Garden, l'utilisateur doit être vigilant à ne pas activé un seul thème dans SVP dans la mesure où Zen-Garden utilise un autre système pour spécifier le thème à utiliser. Zen-Garden ne procède à aucune vérification quant à l'activation éventuelle (au sens d'activation d'un plugin SPIP) d'un plugin de thème. Dès lors, si un thème est déjà activé dans SVP, il peut arriver que le choix effectué dans Zen-Garden reste sans effet si le thème activé dans SVP est prioritaire sur Zen-Garden.

À l'heure actuelle, sous SPIP 3, ni la gestion des thèmes via SVP ni celle via Zen-Garden n'est satisfaisante.

Réintégrer complètement les thèmes dans la logique plugins

L'adoption d'un préfixe unique pour chaque thème a été une première étape vers une gestion des thèmes comme des plugins à part entière. Cependant, les thèmes ont toujours certaines contraintes dérogatoires par rapport aux autres plugins, notamment le fait qu'ils ne peuvent utiliser les pipelines ou déclarer d'autres dépendances. Cela empêche par exemple un thème de pouvoir disposer d'un formulaire de configuration. Cela était voulu en 2009 (voir Écrire un thème pour Zpip). Il était cependant envisagé que : La notion de variante pourra être intégrée au Zen Garden dans le futur, pour en simplifier la gestion pour les développeurs et leur éviter de dupliquer une partie des images et des css. Cette notion de variante n'a pour l'heure jamais été formalisée ni implémentée.

L'absence de dépendance oblige un plugin de thème d'embarquer tous les éléments qu'il utilise, ce qui va à l'encontre de la logique actuelle visant à découper en plusieurs plugins chaque fonctionnalité. Or, un plugin de thèmes peut dès lors utiliser des librairies ou des outils distribués par d'autres plugins (par exemple Less CSS ou bootstrap). D'ailleurs, certains thèmes déclarent déjà des dépendances comme Arclite Brun.

Actuellement, on se retrouve avec deux fonctionnements différents :

une activation avec SVP va correctement vérifier les dépendances mais également les compatibilités ;
sous Zen Garden, les dépendances et compatibilité ne seront pas vérifiées et les fonctionnalités additionnelles ne seront pas prises en compte.

Implications pour Zen-Garden :

Une solution serait de faire évoluer Zen-Garden pour que ce dernier utilise l'API fournie par SVP afin d'activer proprement le thème utilisé. L'ensemble des dépendances seront ainsi correctement vérifiées et prise en compte. Par ailleurs, le réglage du thème actif sera maintenu même si Zen-Garden est par la suite désactivé.

Unicité du thème

Il importe qu'un seul thème soit actif à la fois. Ce que gère Zen-Garden mais pas SVP.

Implications pour SVP :

SVP pourrait évoluer pour n'activer qu'un seul thème à la fois, en se basant sur l'attribut categorie de paquet.xml.

Autrement dit, l'activation d'un thème doit provoquer la désactivation de l'autre thème déjà actif. De même, si l'activation simultanée de deux thèmes (ou plus) est demandée, un message d'avertissement doit être donné à l'utilisateur (car la situation est indéterminée). Enfin, lors du téléchargement simultané de plusieurs thèmes avec SVP, le téléchargement ne doit pas être suivie d'une activation puisqu'on ne peut savoir quel est le bon thème à activer.

Répertoire Thèmes

Une des conséquences d'une gestion des thèmes au même titre que les autres plugins est la disparation du répertoire themes/, tous les thèmes devant être alors installés dans plugins/.

Implications pour Zen-Garden :

Ne prendre en compte que le répertoire plugins/

Filtrage des thèmes

Une des problématiques de la gestion des thèmes est de gérer la « compatibilité » entre thème et squelette. En effet, cette compatibilité est dépendante de la nomenclature HTML/CSS ou convention de nommage des classes qui doit être commune entre le thème et le squelette.

Pour le moment, il n'y a pas de déclaration formelle de cette nomenclature. SVP ne procède à aucune vérification ni filtrage. Zen-Garden pour sa part filtre les thèmes disponibles pour n'afficher que les thèmes « compatibles » avec le squelette actif sur le site.

Actuellement, ce filtrage se fait de la manière suivante dans Zen-garden :

// si on utilise ZPIP-v2 ou ZPIP-v2 invalider les themes qui n'utilisent pas
// ce skel
$search = "";
if (defined('_DIR_PLUGIN_ZPIP')) $search="zpip";
elseif (defined('_DIR_PLUGIN_Z')) $search="z";
elseif (defined('_ZENGARDEN_FILTRE_THEMES')) $search=_ZENGARDEN_FILTRE_THEMES;
if ($search){
foreach ($themes as $k => $theme){
$keep = false;
foreach ($theme['utilise'] as $u){
if (strncasecmp($u['nom'],$search,max(strlen($u['nom']),strlen($search)))==0){
$keep = true;
continue;
}
}
if (!$keep)
unset($themes[$k]);
}
}

Télécharger

Zen-Garden gère donc nativement les thèmes Z. Pour les autres squelettes, ces derniers doivent déclarer dans un fichier d'options la constante _ZENGARDEN_FILTRE_THEMES qui doit correspondre au préfixe du squelette.

Une première limite est que la vérification est effectuée uniquement sur la balise utilise de plugin/xml/paquet.xml et ne prends pas en compte la balise necessite, ce qui ajoute une contrainte de rédaction aux plugins. Par exemple, le thème Brownie pour Zpip 2 n'est pas correctement filtré car il utilise un nécessite.

Par ailleurs, cela exclu la possibilité que deux squelettes différents (ayant donc deux préfixes différents) puissent utiliser une même nomenclature.

Par exemple, dans le cadre des évolutions du projet Z (qui sont en cours de développement et donc susceptible d'évoluer), Zpip v1 se retrouver scinder en deux, avec d'un côté Zcore qui implémente le moteur de génération des pages et Zpip-dist 2 de l'autre qui est un squelette Z utilisant Zcore et suivant une nomenclature donnée. Il est possible de réaliser un squelette proposant un autre contenu que Zpip-dist mais respectant la même nomenclature et donc pouvant utiliser les mêmes thèmes. La question est alors de savoir comment indiquer que ce squelette suit cette nomenclature donnée ?

Il me semble que trois approches peuvent être discutées.

1. Surcharger le squelette de base

Ce second squelette qui utiliserait la nomenclature de Zpip, doit nécessiter le squelette Zpip-dist et dès lors surcharger Zpip-dist pour effectuer ces propres modifications.

Cette approche a cependant plusieurs inconvénients, en particulier celui d'avoir à effectuer le cas échéant un « reset » du squelette surcharger. Par exemple, si ce second squelette n'utilise pas les brèves, il lui faudra surcharger les squelettes de brèves fournis par défaut. De même, cela impose d'avoir à suivre les mises à jour du squelette surchargé, en particulier quand ce dernier ajoute de nouveaux éléments [1].

2. Procurer le squelette de base

Une autre astuce consisterait à utiliser la balise procure dans le second squelette. Ce dernier déclarerait ainsi qu'il « procure Zpip » et définirait la constante _ZENGARDEN_FILTRE_THEMES comme étant égale à "Zpip".

3. Une déclaration formelle de la nomenclature utilisée dans paquet.xml

Les deux approches précédentes reposent sur l'utilisation des balises utilise, necessite ou procure de paquet.xml mais ne sont pas tout a fait sémantiquement exactes.

Il serait dès lors plus rigoureux d'étendre la DTD de paquet.xml en y ajoutant un attribut dédié, nomenclature ou convention ou type_theme (à discuter). Cet attribut permettrait de spécifier la nomenclature HTML/CSS utilisée par un thème ou par un squelette. Par exemple, les thèmes pour Zpip v1 pourraient indiquer nomenclature="zpip1", tandis que ceux pour Zpip v2 indiqueraient nomenclature="zpip2" et ceux pour Sarka-SPIP nomenclature="sarkaspip".

Cet attribut ne concernerait que les plugins de la catégorie themes et ceux de la catégorie squelettes.

La « compatibilité » (à défaut d'un meilleur terme dans l'immédiat) entre un squelette et un thème serait dès lors établie à partir de cette déclaration.

Par ailleurs, cette information pourrait également être utilisée sur http://plugins.spip.net pour afficher les squelettes compatibles avec un thème et les thèmes compatibles avec un squelette.

Éléments de discussion

Il importe de faire un choix quant à la meilleure façon de déclarer la nomenclature HTML/CSS utilisée par un squelette et par un thème. Les plugins SVP et Zen-garden (ainsi que http://plugins.spip.net) devant ensuite être mis à jour en conséquence.

Question de vocabulaires

Doit-on parler de thèmes « compatibles » avec un squelette, c'est-à-dire partageant une même nomenclature ou bien est-il préférable, pour éviter toute confusion, d'avoir recours à un autre terme. Si un autre terme est à privilégier, on pourrait alors parler de thème « conciliable » avec un squelette donné, ou à l'opposé de thème « inconciliable » si ce dernier utilise une autre nomenclature.

Quelle que soit la solution retenue, il importe de faire évoluer SVP afin de rendre compte de la compatibilité/conciliabilité entre un thème et un squelette.

Implications pour SVP :

Au même titre que les versions obsolètes ou incompatibles d'un paquet sont présentées en grisé, si un plugin de la catégorie squelette est actif et qu'il précise une nomenclature HTML/CSS, les plugins de thèmes ne suivant pas la même nomenclature HTML/CSS devraient être affichés en grisés avec un message indiquant qu'il ne sont pas compatibles/conciliables avec le squelette XXX actuellement actif sur le site. On doit pouvoir garder la possibilité de les supprimer et/ou de les mettre à jour.

De même, les résultats d'une recherche (dans le cadre de l'installation d'un plugin) doivent également présenter les thèmes incompatibles/inconciliables avec un message explicite.

Par ailleurs, l'option La version la plus récente doit tenir compte de cette compatibilité/conciliabilité et bien afficher pour les thèmes la version la plus récente du thème compatible/conciliable avec le squelette actif sur le site.

Calcul du chemin

Un thème a besoin d'être prioritaire vis-à-vis du squelette pour pouvoir, par exemple, surcharger une CSS par défaut qui serait fournie par le squelette.

Cette priorité est actuellement établie du fait de la balise utilise dans le paquet.xml du thème. Cependant, si la déclaration de la nomenclature devient possible dans paquet.xml et que dès lors deux squelettes différents (avec donc deux préfixes différents) peuvent partager une même nomenclature, il n'est pas forcément pertinent d'avoir à ajouter un utilise par squelette différent dans le paquet.xml de chaque thème.

Une solution simple consisterait à considérer que, par défaut et sauf mention contraire, un plugin de la catégorie 'theme' est prioritaire sur un plugin de la catégorie 'squelette'.

Implications pour SPIP-core (ou SVP ?) :

Lors du calcul du chemin, et avant prise en compte des modifications induites par les necessite et les utilise, considérer que les plugins de la catégorie 'theme' sont prioritaires sur ceux de la catégorie 'squelette'.

Thèmes de l'espace privé

J'ai identifié deux plugins classés dans la catégorie 'theme' mais portant sur une personnalisation de l'espace privé :

Ces plugins intervenant dans l'espace privé ne sont pas concernés par la règle d'unicité du thème actif. Ces deux plugins pourraient tout à fait être classés dans la catégorie Configuration, maintenance, au même titre que les plugins Personnaliser l'espace privé et Thèmes pour l'interface privée.

Implications pour paquet.xml :

La catégorie “theme” devrait être précisée et réservée uniquement aux plugins de thèmes pour l'espace public à utiliser en conjonction avec un squelette.

Aujourd'hui, deux logiques différentes s'appliquent aux thèmes. D'un côté, SVP gère les thèmes comme des plugins à part entière mais ne prends pas en compte leur spécificité (unicité du thème actif et compatibilité/conciliabilité avec un squelette donné). De l'autre, Zen-Garden prends en compte cette spécificité mais gère les thèmes de manière dérogatoire, les thèmes n'étant pas activés au même titre que les autres plugins.

En terme d'évolution, il serait souhaitable que SVP et son API évoluent pour prendre en compte la spécificité des thèmes. Ces derniers doivent pouvoir être entièrement gérables uniquement via SVP.

Zen Garden, quant à lui, permet d'offrir une interface plus user-friendly pour gérer les thèmes, mais devraient reposer sur l'API de SVP pour leur activation. L'interface de Zen Garden pourrait également évoluer pour lister les thèmes compatibles disponibles au téléchargement et les installer en un clic. Enfin, les fonctionnalités telles que la prévisualisation d'un thème et le switcher de thème restent du ressort de Zen Garden.

[1] Par exemple, si Zpip-dist fourni dans une mise à jour un squelette extra2/plan.html ce qui n'était pas le cas avant, le squelette surchargeant devra prendre en compte ce nouvel élément à surcharger.

Aide en ligne : proposition alternative pour une aide embarquée

Joseph — 2012-10-20T21:41:19Z

Dans le cadre de la réflexion autour de la restructuration de l'aide en ligne de SPIP, deux articles ont déjà été rédigés sur ce site :

La proposition qui avait été faite reposait, comme l'aide actuelle, sur des fichiers d'aide gérés sur un serveur distant, SPIP téléchargeant à la demande les fichiers d'aide nécessaires. Les discussions qui ont suivi cette première proposition ont évoqué un certain nombre de points durs inhérents à la solution :

Comment gérer une aide versionnée qui corresponde bien à la version de SPIP et des plugins qui sont installées sur le site ? Est-il nécessaire de recréer la roue alors que l'on utilise déjà SVN/GIT pour le versioning ?
Faut-il recréer un système de gestion des traductions alors qu'il existe déjà http://trad.spip.net/ ?
Quid des sites locaux qui n'ont pas d'accès distants ?
Pourquoi ne pas utiliser les mécanismes déjà en place dans SPIP ?

La présente proposition est donc une alternative reposant pour une aide en ligne embarquée dans le core ou les plugins et s'appuyant sur des squelettes.

Concepts

L'aide en ligne sera composée de différentes entrées d'aide organisées en rubriques d'aide [1].

Les rubriques d'aide auront simplement un identifiant et un titre et n'ont d'autres vocations que d'organiser les différentes entrées.

Plusieurs rubriques d'aide génériques seront proposées par défaut, telles que [2] :

Raccourcis typographiques
Modèles
Configuration

Un plugin pourra déclarer des rubriques d'aide additionnelles, par exemple le plugin mots pourra déclarer une nouvelle section Mots-Clés pour y ranger les entrées d'aide relatives aux mots-clés.

Chaque entrée d'aide sera rattachée à une rubrique d'aide (afin d'organiser les différentes entrées), aura un identifiant [3], un titre et un squelette associé qui contiendra le contenu de l'entrée d'aide.

L'ensemble du système de gestion d'aide sera implémenté dans un plugin dédié qui devra à terme intégrer la distribution standard de SPIP. L'aide en ligne correspondant au core sera livré par le core lui-même et non par le plugin de gestion de l'aide.

Squelettes des entrées d'aide

Chaque plugin intégrera donc sa propre aide. Dès lors, l'aide en ligne sera disponible localement, y compris pour les sites sans accès distant. L'aide disponible correspondra bien à la version du plugin actuellement installée et le versionning de l'aide sera gérée comme le reste du plugin.

À chaque entrée d'aide correspondra un squelette ayant pour nom l'identifiant de l'entrée d'aide et rangé dans un sous-répertoire aide/. Il s'agira d'un squelette comme un autre et donc l'ensemble des mécanismes de SPIP pourront y être utilisés. Par exemple, on pourra utiliser la balise #AUTORISER ou la balise #CONFIG pour afficher certains passages uniquement aux personnes pour qui c'est pertinent ou adapter l'aide en fonction de la configuration.

Par exemple, l'entrée d'aide décrivant le champs titre d'un article pourra ne mentionner le rôle du surtitre et/ou du sous-titre uniquement si ces derniers ont été activés. Il n'est pas nécessaire en effet de « polluer » l'aide adressée aux rédacteurs avec des informations non pertinentes. La même entrée pourrait afficher, uniquement pour les admins, un court texte expliquant que les surtitres et sous-titres sont activables/désactivables dans la configuration du site.

Les squelettes des entrées d'aide auront recours, classiquement, à des chaînes de langue. Afin d'organiser ses dernières, elles pourront être rassemblées préférentiellement dans un fichier aide-{$prefixe_plugin}_{$lang}.php. La traduction de l'aide sera donc assurée, pour les plugins sur la zone, via http://trad.spip.net/ au même titre que les autres chaînes de langues.

Les entrées pourront au besoin inclure des images (par exemple des captures d'écran), qui seront rangées dans un sous-répertoire aide/images. Il y a le cas particulier des captures d'écran qui pourraient être différentes selon la langue. On peut tout à fait envisager une nouvelle balise #CHEMIN_LANG{image.png} qui rechercherait l'existence d'un fichier image-lg.png (où lg est le code de la langue actuelle et se rabattrait sinon sur image.png [4].

Exemple de squelette d'aide

Il s'agit de l'aide portant sur le surtitre, le titre et le soustitre d'un article. Le fichier aide/spip-arttitre.html contiendrait :

<:aide-spip:titre_article:>
[(#CONFIG{article_surtitre}|=={oui})
<:aide-spip:explication_surtitre:>
]
<:aide-spip:explication_titre{lien=#URL_AIDE{spip-numtitre}}:>
[(#CONFIG{article_soustitre}|=={oui})
<:aide-spip:explication_soustitre:>
]
[(#AUTORISER{configurer})
<:aide-spip:explication_configurer_article_titre{lien=#URL_ECRIRE{configurer_contenu}}:>
]

Télécharger

Avec les chaines de langue suivantes déclarées dans le fichier lange/aide-spip_fr.php :

Code	Valeur
titre_article	Titre de l'article
explication_surtitre	Optionnel, le surtitre est un titre complémentaire placé au-dessus du titre principal de l'article. Dans la presse écrite, le surtitre sert le plus souvent à indiquer le type d'article (éditorial, chronique, opinion...).
explication_titre	Titre : rien de bien compliqué, il s'agit du titre de l'article. Ce dernier est obligatoire. Pensez à le rédiger en respectant les règles usuelles d'emploi des majuscules. Surtout, ne l'écrivez pas tout en capitales. La mise en forme finale du titre sera effectuée par le squelette. Les titres peuvent être numérotés pour un indiquer un ordre de tri des articles au sein de la rubrique. Voir Numérotation des titres.
explication_soustitre	Optionnel, le sous-titre est un titre complémentaire placé au-dessous du titre principal de l'article. Dans la presse écrite, le sous-titre sert le plus souvent à fournir des éléments factuels permettant de mieux situer le sujet de l'article.
spip:explication_configurer_article_titre	Les administrateurs du site peuvent configurer l'utilisation ou non du surtitre et/ou du sous-titre sur la page « Contenu du site ».

Exemple 2

Voici ce que pourrait être le squelette d'une entrée d'aide expliquant le gras et l'italique [5]. Cette entrée d'aide sera fournie par le plugin textwheel puisque c'est ce dernier qui implémente les raccourcis typographiques.

<:aide-textwheel:gras_italique:>
<:aide-textwheel:explication_gras_italique:>
#SET{exemple,#VAL{aide-textwheel:exemple_gras_italique}|_T}
[(#VAL{}|concat{#GET{exemple},< /cadre>}|propre)]
<:aide-textwheel:produira:>
[ class="spip">(#GET{exemple}|propre)>]

Télécharger

Avec les chaines de langue suivantes déclarées dans le fichier lange/aide-textwheel_fr.php :

Code	Valeur
gras_italique	Gras et italique
explication_gras_italique	L'italique s'indique en plaçant le texte concerné entre simples accolades. Pour du texte en gras, utilisez des doubles accolades.
exemple_gras_italique	Du texte {en italique} et du texte {{en gras}}.
produira	produira :

Déclarer les rubriques et les entrées d'aide

Les rubriques et les entrées d'aide seront déclarées à SPIP via un pipeline declarer_aide. Cette déclaration est nécessaire pour produire le sommaire de l'aide et organiser les entrées d'aide en sections.

Pour déclarer une nouvelle rubrique :

$aide['']['titre'] = "Titre de la rubrique d'aide";

Pour déclarer une entrée :

$aide['']['entres'][''] = "Titre de l'entrée";

Le sommaire sera construit selon l'ordre du tableau.

Le recours à un pipeline plutôt qu'à une déclaration xml permet une plus grande souplesse. On pourra ainsi afficher dans le sommaire que les entrées pertinentes. Par exemple, le plugin brèves pourrait n'afficher l'aide éditoriale sur les brèves que si ces dernières sont activées sur le site et une entrée sur la configuration des brèves seulement aux admins. Encore une fois, il s'agit de n'afficher que les informations utiles à l'utilisateur. Un pipeline permet par ailleurs aux plugins une plus grande souplesse de surcharge au besoin.

Compléter une entrée existante

Dans les quelques cas où il serait plus pertinent pour un plugin de compléter une entrée d'aide plutôt que d'en ajouter une, il sera possible de passer par le pipeline affiche_milieu, à moins de mettre en place un pipeline dédié affiche_aide.

Balise `#AIDER`

#AIDER{id_entree} produira l'icone d'aide avec un lien sur l'entrée demandée.

La balise sera par ailleurs étendue avec #AIDER{rubrique/id_rubrique} pour afficher une rubrique d'aide et la liste de ses entrées (par exemple la section Raccourcis typographiques). #AIDER{''} affichera le sommaire de l'aide.

Avantages d'une aide embarquée

Repose sur les mécanismes déjà existants dans SPIP.
Aisée à mettre en œuvre.
Traductions facilitées car possibles via http://trad.spip.net => Les traducteurs n'ont pas besoin d'apprendre un nouvel outil.
Aide accessible y compris pour un intranet.
Facilité de surcharge / extension.
Versionnage de l'aide intégrée au versionnage du plugin => il y a cohérence entre l'aide affichée et les fonctions implémentées, plus historique via SVN/GIT.
Peut prendre aisément en compte la configuration du site pour n'afficher que les éléments pertinents.
Facile à mettre en place également pour les plugins non développé sur la zone (inutile d'avoir à créer et gérer un serveur d'aide en ligne).
En intégrant l'aide dans le code, il est plus aisé de rédiger/modifier une aide en parallèle du code.

Inconvénients

En premier lieu, une intégration de l'aide directement dans les plugins devrait aboutir un poids (taille en octets) plus élevés de ces derniers. Reste à savoir si cela représente un problème majeur ou non. En effet, les hébergements proposent plus d'espace disque de nos jours que par le passé. Par ailleurs, il est assez difficile de mesurer le poids additionnels que représenterait une aide intégrée. Si cela s'avère vraiment nécessaire, il serait assez facile de produire automatiquement des zips des plugins sans aide intégrée (en excluant le répertoire aide et les fichiers de langue commençant par aide). Mais cela est-il nécessaire ?

Le second élément concerne la rédaction de l'aide en ligne (dans la langue d'origine) qui nécessite dès lors de savoir écrire un fichier de langue, éditer un squelette et commiter sous SVN alors que le système actuel repose sur des articles SPIP. De plus, cela implique d'avoir à découper le texte de l'aide en plusieurs chaines de langue, ce qui n'est pas toujours aisé. Enfin, la rédaction en PHP du texte est moins aisée que celle d'un article SPIP.

Il est à noter que ce problème ne concerne que la langue de base de l'aide en ligne puisque la traduction serait gérée pour sa part via http://trad.spip.net. Cependant, sur spip.net, les contributions en matière de rédaction de l'aide en ligne sont peu nombreuses. L'aide n'a que très peu évolué depuis 2006-2008. De plus, bien qu'il s'agisse d'articles SPIP, ils utilisent des conventions spécifiques, notamment avec des titres en H2 et les images insérées en HTML et non joignables classiquement. Le recours à des squelettes et des chaînes de langue, bien que plus connu par un public de "développeurs", reposent quant à lui sur des mécanismes génériques de SPIP.

[1] Sur un seul niveau.

[2] Il s'agit ici d'exemples. La définition des rubriques d'aide par défaut pouvant faire l'objet d'une discussion ultérieure.

[3] L'identifiant devant être unique, on favorisera les identifiants de la forme prefixe_plugin-nom_entree.

[4] Une telle balise serait intéressante de manière générale dans SPIP, pas uniquement pour les fichiers d'aide, mais aussi pour certains squelettes. D'ailleurs, cette balise pourrait vérifier en second lieu l'existence d'un fichier image-ltr.png ou image-rtl.png avant de se rabattre sur le fichier par défaut.

[5] Dans le cadre de la réorganisation de l'aide en ligne, il est prévu de découper l'aide sur les raccourcis typographiques en plusieurs entrées rassembler dans une rurbique d'aide dédiée.

Rainette v2, extension des services météo

_Eric_ — 2012-08-05T10:30:06Z

Schéma général d'intégration de plusieurs services

Actuellement le moteur de Rainette, sur requête périodique ou évènementielle :

reçoit en entrée la localisation et les options permettant de choisir entre les conditions actuelles, les prévisions à n jours, le système d'unités...
fabrique l'url du flux correspondant à la requête et acquiert le XML,
stocke les informations sous forme tabulaire dans un fichier cache.

Cependant, le moteur actuel considère uniquement le format de requête et la structure XML de weather.com(r) ce qui a pour conséquence que les traitements sont complètement dédié à ce service. Il faut donc conserver ce schéma en le généralisant, en particulier, en indexant la fabrication de l'url de la requête et le transcodage en tableau par le service comme l'illustre le schéma ci-dessous. En outre, la structure du tableau en cache doit être standard (il faut vérifier si la structure actuelle convient ou pas) afin, d'une part, que celle-ci puisse être remplie par n'importe lequel des services utilisés et d'autre part, que l'ensemble des affichages puissent être conservés.

Pour mémoire, les documentations des APIs de chacun des services sont disponibles aux adresses suivantes :

Identification du lieu

La première problématique à régler concerne la généralisation de l'identifiant du lieu. En effet, il n'existe pas de norme et chaque service propose des méthodes différentes qui parfois se recoupent.

Service	Paramètres
Weather.com(r)	code de ville du type YYXXXX ou YY est un bigramme du pays et XXXX un numéro ordinal
Meteorologic	p : le nom ou le code postal de la ville cn : le pays parmi la France, la Suisse et la Belgique mais ce paramètre est optionnel (permet d'éviter des ambiguïtés)
World Weather Online	q : qui représente le nom de la ville accompagné ou pas du pays d'origine, le code postal (uniquement pour les US) ou le point géolocalisé, l'adresse IP...
Wunderground	query : reprend les mêmes possibilités que WWO avec en plus le PWS Id qui ne semble utilisé que parce ce service
Yahoo Weather	w : code appelé WOEID. Ce code est uniquement utilisé par Yahoo mais rappelle en cela l'API de weather.com(r)
Open Weather Map	xxx

D'après le tableau ci-dessous, on peut conclure qu'en étendant juste la portée du paramètre unique de lieu actuel on résout simplement l'équation posée. En effet, seul Meteorologic demande parfois deux paramètres. En résumé :

on conserve le paramètre « code » actuel qui suffit pour Weather.com et Yahoo Weather
pour les services Wunderground et World Weather Online ce code représente n'importe lequel des identifiants acceptés par le service.
pour Meteorologic, le code représentera le code postal ou le nom de la ville sans possibilité de gérer les ambiguïtés.

Remarque : le meilleur compromis aurait été de choisir la latitude et la longitude qui est un identifiant universel de lieu. Néanmoins, il n'est pas supporté par Weather.com et Yahoo Weather.

Requêtes et options

Outre le lieu des données météorologiques, les requêtes font appel à d'autres options pour désigner le type d'informations demandées, le système d'unité à utiliser, le nombre de jours de prévisions... Là encore, il n'y a aucune normalisation entre les services.

Actuellement, pour Weather.com(r) on distingue 3 requêtes différentes avec des options spécifiques :

la demande des conditions courantes
la demande des prévisions pour les n prochains jours
la demande des informations sur le lieu

Pour les deux premières requêtes le système d'unité est paramétrable dans Rainette. Pour les prévisions, il est possible de spécifier le nombre de jours voulus.

Il faut donc étudier comment simuler ces mêmes types de requêtes avec les autres services sachant qu'il est inutile pour l'instant de rajouter plus de possibilités de paramétrage.

Service	Requêtes et options
Weather.com(r)	Voir ci-dessus
Meteorologic	Ce service ne dispose que d'une seule requête et d'aucune option. Pour un lieu donné, les prévisions à 3 jours sont fournies et comprennent le jour courant.
World Weather Online	Il est possible de faire varier plusieurs paramètres : num_of_days : pour préciser le nombre de jours de prévisions souhaités cc : pour préciser si on veut les conditions courantes ou pas fx : à vérifier si il permet de désactiver les prévisions afin d'optimiser les requêtes. En outre, format sera toujours positionné à XML et key désignera la clé de l'utilisateur. Par contre, le système d'unité n'est pas paramétrable. Il faudra prévoir soit des fonctions de conversions soit de trouver les deux valeurs dans le XML.
Wunderground	Il est possible de faire varier un paramètre : features : pour préciser le type de demande. Pour simuler le comportement actuel les valeurs conditions, forecast ou forecast10day et geolookup sont à étudier, le nombre de jours de prévisions ne pouvant pas être spécifiés En outre, format sera toujours positionné à XML et your_key désignera la clé de l'utilisateur. Par contre, le système d'unité n'est pas paramétrable. Il faudra prévoir soit des fonctions de conversions soit de trouver les deux valeurs dans le XML.
Yahoo Weather	Ce service ne dispose que d'une seule requête qui renvoie toutes les informations géographiques et météorologiques d'un lieu. Seul le système d'unité est configurable : c'est le paramètre u. Le service n'est donc pas optimisé puisque l'ensemble des données est remontée à chaque demande.
Open Weather Map	xxx

En conclusion, il est possible de simuler le même comportement qu'actuellement avec ces nouveaux services mais certains comme Yahoo Weather - qui s'appuie sur Weather.com(r) - et surtout Meteorologic ne sont pas optimisés. L'utilité d'intégrer ces services n'est donc pas prouvée sauf à conserver des services gratuits.

Gestion des clés d'inscription

Meteorologic et Yahoo Weather ne demandent aucune clé d'inscription pour fonctionner.

L'API utilisée actuellement pour Weather.com(r) fonctionne encore sans clé mais il est possible de l'utiliser avec une clé obtenue avant la sortie de la nouvelle API (Partner ID et Licence Key). Cependant, Rainette n'autorise pas aujourd'hui l'utilisation de cette interface avec clé. De même, la nouvelle API ne sera pas supportée par Rainette si elle se limite à une utilisation payante.

Open Weather Map ne demande pas de clé d'inscription pour fonctionner. Néanmoins, si le volume de requêtes devient trop important (plus de 2000 par heure) il est demandé de s'inscrire et d'insérer la clé d'inscription gratuite dans les requêtes.

Wunderground et World Weather Online demandent tout deux une clé d'inscription mais le service reste gratuit. WorldWeather Online propose un abonnement premium autorisant plus d'options mais celui-ci ne sera pas supporté par Rainette.

En conclusion, il faut donc prendre en compte aujourd'hui la gestion des clés d'inscription dans Rainette lors de la construction des requêtes. En outre, il faudra rajouter un formulaire de configuration pour les enregistrer.

Gestion du cache

Il est essentiel de continuer à gérer le cache des données météo car les services sont de plus en plus pointilleux sur le nombre de requêtes maximum par période de temps. Cependant, il est devenu superflu de continuer à choisir la période de renouvèlement des données, mieux vaut se conformer à la recommandation des services. Il est par contre nécessaire de fixer une période en fonction du service.

Actuellement, le nom du fichier de cache coïncide avec l'identifiant du lieu au format de Weather.com(r). Étant donné que les services peuvent utiliser des identifiants différents, le nom de fichier pour un même lieu peut varier en fonction du service (pas de possibilité de trouver un nom unique).

En outre, dans le cas de Wunderground qui propose une interface traduite pour les conditions et prévisions, il faut indexer le nom du fichier avec le code de la langue. Cela a tendance à augmenter le nombre de fichiers caches donc d'accès mais peu de site sont concernés.
C'est aussi le cas de Open Weather Map mais le nombre de traductions étant limitée il convient de vérifier au préalable l'intérêt de l'utiliser.

Prise en compte des conditions d'utilisation

Les conditions d'utilisation sont consultables aux adresses suivantes :

Weather.com(r) :
Meteorologic : http://www.meteorologic.net/zone-rss.php#condition
World Weather Online : http://www.worldweatheronline.com/free-weather-feed.aspx?menu=usage
Wunderground : http://www.wunderground.com/weather/api/d/terms.html
Yahoo Weather : http://developer.yahoo.com/weather/#terms
Open Weather Map : http://openweathermap.org/copyright

Il est important d'améliorer le traitement de Rainette à cet égard en :

rappelant ces conditions dans la page de configuration
utilisant les chartes graphiques dans les affichages proposés de base par Rainette

Evolution v2 de Rainette

_Eric_ — 2012-08-04T13:34:37Z

Les problèmes actuels

Depuis quelques mois, Weather.com(r) - qui est le service unique utilisé par Rainette - s'est orienté plus clairement dans une démarche commerciale. Le flux gratuit est toujours disponible mais a perdu en fiabilité, du moins pour les lieux à « faible popularité ».

Ceci étant, les erreurs de flux remontées par les utilisateurs de Rainette se multipliant sur les forums, il semble nécessaire aujourd'hui de faire évoluer Rainette pour pallier cette dérive et permettre à tous de disposer d'une météo locale.

Etendre la liste des services météo

La principale évolution est évidente : acquérir et restituer les données météo fournies par différents services et permettre ainsi à chaque utilisateur de choisir le meilleur flux correspondant à sa localisation.

Suite à une petite étude des flux disponibles une première liste de services a été élaborée, chacun proposant une API de récupération des données météo en XML ou JSON :

Malheureusement, certains de ces services sont payants ou utilisent une clé d'inscription pour repérer les utilisations de leur flux. Même si ce n'est pas l'esprit de Rainette, le plugin doit aujourd'hui être capable de prendre en compte ces flux si des utilisateurs sont prêts à l'accepter.

En outre, même pour Weather.com(r), qui restera le flux par défaut de Rainette tant qu'il offrira une API gratuite, il peut être intéressant pour certains sites d'utiliser le service payant. Il faudra donc faire évoluer son utilisation actuelle.

Néanmoins, Rainette offrira toujours au moins une alternative gratuite par défaut.

Améliorer la gestion des thèmes

La deuxième évolution concerne la gestion des thèmes d'icônes de conditions météorologiques. Avec SPIP 3 la gestion actuelle est devenue vieillotte et il est nécessaire de la faire évoluer selon le standard SPIP 3.

La Taverne à Tonton

Evolution du site Plugins SPIP

Mise à jour des Plugins pour SPIP 3.0

Boussole

PlugOnet

Réalisation de la version v2 du plugin Boussole

Création d'un plugin « Boussole SPIP »

Ajout d'une fonction serveur au plugin Boussole

Modifications de la fonction client du plugin Boussole

Evolution v2 du plugin Boussole

Rappel du fonctionnement de la version v1 actuelle

Problèmes posés par la version v1 actuelle

Nouvelles exigences pour une v2

Solutions possibles pour répondre aux exigences v2

Rainette v2, mise en œuvre du multi-services

Les modèles standard

Le chargement des données météorologiques

Le codage d'un service

La fonction ${service}_service2cache

La fonction ${service}_service2url

La fonction ${service}_service2reload_time

La fonction ${service}_url2flux

La fonction ${service}_flux2infos

La fonction ${service}_flux2conditions

La fonction ${service}_flux2previsions

La fonction ${service}_service2credits

Gestion de la configuration des plugins

Le mécanisme de configuration actuel

Affectation des valeurs par défaut

Sauvegarde et restauration de variables de configuration

Nettoyage des variables de configuration

Évolutions de la gestion des thèmes sous SPIP 3

Historique

Situation actuelle et limites

Réintégrer complètement les thèmes dans la logique plugins

Unicité du thème

Répertoire Thèmes

Filtrage des thèmes

Calcul du chemin

Thèmes de l'espace privé

Aide en ligne : proposition alternative pour une aide embarquée

Concepts

Squelettes des entrées d'aide

<:aide-spip:titre_article:>

<:aide-textwheel:gras_italique:>

Déclarer les rubriques et les entrées d'aide

Compléter une entrée existante

Balise #AIDER

Avantages d'une aide embarquée

Inconvénients

Rainette v2, extension des services météo

Schéma général d'intégration de plusieurs services

Identification du lieu

Requêtes et options

Gestion des clés d'inscription

Gestion du cache

Prise en compte des conditions d'utilisation

Evolution v2 de Rainette

Les problèmes actuels

Etendre la liste des services météo

Améliorer la gestion des thèmes

La fonction `${service}_service2cache`

La fonction `${service}_service2url`

La fonction `${service}_service2reload_time`

La fonction `${service}_url2flux`

La fonction `${service}_flux2infos`

La fonction `${service}_flux2conditions`

La fonction `${service}_flux2previsions`

La fonction `${service}_service2credits`

Balise `#AIDER`