Agora —> SPIP

Le migrateur Agora—>SPIP, un outil pour les sites Agora qui veulent passer à SPIP

Laurent Poinsignon, Nicolas Bellenge — 2008-04-04T15:06:55Z

Le « migrateur Agora2SPIP » est un outil de migration de données d'une base de données vers une autre, au sein d'une même machine. Il s'agit d'un script php/mysql avec une interface web pas à pas, conçu pour faciliter le travail d'un développeur novice chargé de convertir un site Agora en site SPIP.

Le migrateur s'appuie sur un fichier de définition paramétrable à la main afin de personnaliser la conversion des champs/tables de la base Agora vers leurs équivalents SPIP 1.9.2. (inc/field_definition_14x.php).

De plus, un fichier de paramétrage général permet de forcer la conversion de l'encodage des caractères vers UTF8 ou vers ISO Latin-1.

Dans le cadre d'une migration d'Agora vers SPIP, un tel outil est nécessaire du fait des écarts qui sont apparus dans les structures des tables entre les deux logiciels. Agora était à l'origine fondé sur la version 1.7 de SPIP, puis a évolué au fil du temps. De son côté, SPIP a également évolué. De sorte qu'il existe trois sortes de différences :

de nouvelles tables sont apparues en SPIP, sans équivalent Agora ;
de nouvelles tables ont été ajoutées à Agora, sans équivalent SPIP ;
au sein des tables communes, certains champs sont apparus de part et d'autre ou bien les noms ont été changés.

Cet outil de migration vise donc à transférer au mieux les données selon les éléments communs entre Agora et SPIP. Vous l'aurez compris, il n'est pas possible de transférer automagiquement l'intégralité des données d'Agora vers SPIP, mais cet outil facilite grandement la tâche.

La documentation complète est livrée dans le fichier zip. Bonnes migrations !


Migrateur Agora2spip

Présentation d'AGORA, suite et fin

Laurent Poinsignon, Régie technique AGORA — 2007-09-05T18:46:50Z

Genèse du projet AGORA

En 2002, AGORA a répondu au besoin des administrations française de convaincre leurs [DSI|Direction des Services Informatiques] de l'opportunité d'utiliser des logiciels libres dans le cadre de la publication de sites web institutionnels et gouvernementaux.

Bilan

5 ans plus tard, nous pouvons constater :

que l'usage des logiciels libres s'est largement démocratisé dans les administrations ;
que les logiciels libres disponibles ont gagné en maturité, robustesse et richesse.

Ainsi donc :

AGORA en tant que projet a atteint son but premier : démocratiser l'usage des logiciels libres pour les sites web des administrations ;
AGORA en tant que logiciel édité par le [SIG|Service d'Information du Gouvernement] va donc pouvoir laisser la place à d'autres.

Conséquences

Le [SIG|Service d'Information du Gouvernement], à l'origine du projet AGORA, estime donc raisonnable d'inviter les administrations à puiser dans la richesse des nombreuses offres libres disponibles.

Perspectives

En mai 2008, le [SIG|Service d'Information du Gouvernement] cesse de maintenir le projet AGORA, sauf pour les patchs de sécurité.

La version 1.4 d'Agora a atteint sa maturité et répond à l'essentiel des besoins de ses utilisateurs. Le SIG ne préconise donc pas une migration systématique et immédiate des sites développés sous Agora. Néanmoins, si les administrations font le choix d'une migration vers un autre CMS, alors le SIG pourrait proposer un accompagnement vers SPIP qui est l'outil fonctionnellement et ergonomiquement le plus proche d'Agora [1]. Cet accompagnement s'appuierait sur le site Agora2SPIP.

[1] AGORA étant basé sur une version 1.7 de SPIP, et SPIP avec ses plugins disposant de beaucoup d'équivalents fonctionnels d'AGORA

Versionning d'articles

Régie technique AGORA — 2007-06-12T21:10:16Z

Détails de cette fonctionnalité

Voir le site agora.gouv.fr : http://www.agora.gouv.fr/article.ph…

AGORA permet d'avoir une version d'un article publié et une nouvelle version en cours d'écriture.

Comment faire avec SPIP ?

SPIP ne propose pour l'instant rien de similaire. Il est possible de simuler les versions en utilisants 2 articles distincts et en modifiant le statut des articles « proposé à l'évaluation » / « publié en ligne ».

Modes de contribution à SPIP

Laurent Poinsignon, Régie technique AGORA — 2007-04-22T14:30:03Z

Ce texte cherche à présenter le minimum nécessaire à une intégration possible dans la communauté SPIP. Mais ce n'est qu'une obligation de moyens, pas de résultat.

Ce qu'il ne faut pas faire

Reprenons ci-dessous quelques beaux exemples de mauvaises pratiques dont a fait l'experience le projet Agora :

coder sans se soucier des principes fondamentaux retenus dans SPIP, notamment :
- imposer [PEAR|PHP Extension and Application Repository http://pear.php.net] comme prérequis de l'environnement technique pour installer le logiciel [1]
- opter pour un nommage anglais des fonctions et variables alors que le nomage des fonctions est en français dans SPIP
- changer la présentation du code (indentation des lignes, espacements autour des opérateurs)
- …
coder dans la limite de ses propres besoins, [2] par opposition à un ajout fonctionnel générique qui puisse être librement configuré dans le logiciel ;
réalisation du code sans visibilité publique des commits, en maintenant un silence radio, et en ne présentant qu'à la dernière étape le produit « fini » [3] ;
laisser courir un manque persistant de documentation, au niveau du code (commentaires), des commits [4] et sur le Web. Un code non documenté est un code non partagé. S'il n'a pas le mérite d'être suffisamment intéressant pour les développeurs, c'est un code mort.

Comment contribuer ?

Contribuer à SPIP, c'est donner de manière désintéressée et 'personnifiée' [5].

La contribution doit être 'désintéressée'

Contribuer à SPIP, c'est apporter quelque chose qui serve globalement la communauté.

L'appréciation de ce caractère global et générique est parfois difficile. Par exemple, un squelette qui serait bâti avec des n° de rubriques, articles, mots clefs en dur n'est manifestement pas générique. Cependant, l'étude de ses boucles peut rendre un service à la communauté.

Le caractère désintéressé est donc difficile à apprécier.

Et ce n'est même pas le fait que ça a été fait sur du temps non rémunéré qui est le critère déterminant (bien que la défiance vis à vis de l'argent soit une des composantes de la communauté SPIP).

La contribution doit être faite « en personne »

Une contribution ne peut être apportée au nom d'une société commerciale, d'une administration ou d'une institution quelconque. Ni pour mettre en avant l'organisation où travaille la personne qui contribue.

Le caractère personnifié implique la prise en compte des éventuelles incompatibilité de caractères avec la communauté qui rendront difficile la contribution.

La contribution doit être pérenne

Il est essentiel qu'une contribution à SPIP soit pérenne. Pour cela, il faut qu'elle soit d'abord documentée, mais surtout qu'elle soit maintenue à jour [6]

Quelques types de contributions

Développer pour SPIP

Améliorations de celui-ci par :

du debug
la fourniture de patch améliorant telle ou telle fonctionnalité [7]

Remontées de bugs

Trouver des bugs dans SPIP
Réaliser un ticket
Vérifier parmi les tickets existants pour les confirmer

Documentation

3 aspects principaux de SPIP peuvent être documentés :

l'utilisation de SPIP : http://www.spip.net/ et http://www.spip-contrib.net/
le code de SPIP : http://doc.spip.org/
les plugins

Plugins

Aujourd'hui, le principal mode de contribution à SPIP passe par les plugins. Pour faire de bons plugins, il faut :

qu'ils soient utilisables par beaucoup
qu'ils soient codés en utilisant les API de SPIP [8]
qu'ils soient codés sans ouvrir des trous de sécurité
qu'ils soient coder en « forkant » le moins possible le code de SPIP (tout fork étant par essence un point difficile à maintenir dans le temps)

Les plugins sont aussi, de plus en plus, un moyen simple de tester de nouvelles fonctionnalités qui pourraient être intégrées à SPIP.

Dans ce cas, il est préférable de faire :

un premier commit avec les fichiers originaux de SPIP qui vont être modifiés
un deuxième commit avec les modification
et comme toujours, des commentaires donnant l'intention et la documentation à l'attention des utilisateurs

Participer aux apéroSPIP

Ces ateliers décontractés sont des lieux d'échanges où les personnes expérimentées peuvent aider les novices. Voir le site http://www.spip-party.net/ pour les lieux et horaires.

[1] SPIP étant fait pour s'installer partout, et PEAR n'étant pas disponible chez tous les hébergeurs

[2] En l'occurrence, augmentation du nombre de niveaux utilisateurs et de niveaux de validation dans la chaine de publication pour répondre à un besoin de l'administration

[3] Cette situation a essentiellement marqué le lancement d'Agora

[4] Dans la communauté SPIP, les commits sont le premier temps de la documentation : ils s'adressent donc à des utilisateurs et non à des développeurs. Ces derniers peuvent lire le code. Les utilisateurs ont besoin de savoir l'intention du code.

[5] Personnifiée est à comprendre : en tant que personne humaine, pas en tant qu'institution ou entreprise

[6] À noter : une contribution utilisée par beaucoup de monde finit par être maintenue par ses utilisateurs

[7] Ce peut être global, par exemple l'accessibilité, ou ponctuel, par exemple l'affichage des stats

[8] Et même si celles-ci sont encore mouvantes, c'est justement l'occasion d'aider à leur stabilisation

Règles de codage et architecture

Laurent Poinsignon, Régie technique AGORA — 2007-03-26T09:07:48Z

Des ressources pour mieux comprendre SPIP, le décortiquer, trouver des interlocuteurs expérimentés, les bonnes manières de développer et participer à la communauté.

Quelques articles essentiels à lire

La rubrique Contribuer sur le site officiel est un bon point de départ, et en particulier l'article Contribuer au développement de SPIP qui décrit les règles de code ;
Ensuite, l'article Étendre SPIP parle de l'architecture générale et du modèle MVC de SPIP ;
Après vous être inscrit à l'espace privé de spip.net, allez lire l'article Mécanismes de fabrication des pages publiques et privées ;
enfin, l'article Structure générale de SPIP

Espaces de discussion et d'échanges

La liste de développement de SPIP pour tout ce qui concerne des éléments qui concernent le core de SPIP ;
La liste de la Zone pour les plugins et leur développement ;
Le canal IRC SPIP pour discuter en live avec d'autres personnes connectées ;
Les rencontres des apéros SPIP peuvent être l'occasion de faire des échanges et des démonstrations, que vous soyiez débutant ou experimenté.

Article post daté

Régie technique AGORA — 2007-02-22T18:28:57Z

Une des fonctionnalités d'AGORA est la gestion de l'embargo de publication, c'est-à-dire, la possibilité de créer un article et d'indiquer avant de le publier qu'il ne doit apparaitre sur le site que plus tard.

SPIP, ne permet de régler la date de publication qu'après avoir effectivement publié l'article ce qui ouvre une courte fenêtre de temps durant laquelle quelqu'un pourrait voir l'article avant que le webmestre du site ait eu le temps de changer la date de publication de l'article.

Ceci fait l'objet d'un ticket sur le trac de SPIP avec une piste de résolution sur la zone.

MàJ du 19 juin 2009 : La version 2.0 de SPIP intègre la possibilité d'indiquer la date de publication d'un article proposé à la publication : Révision SVN 14118.

Mots clefs arborescents

Régie technique AGORA — 2007-02-03T11:34:09Z

Cette fonctionnalité n'est pas (encore) disponible en temps que plugin.

Objectif : permettre de gérer une arborescence de mots clefs.

Cédric de Notre-Ville.net aurait cette fonctionnalité loin dans sa ToDo.

Workflow à n niveaux

Régie technique AGORA — 2007-02-03T11:34:07Z

- Les plugins manquant à SPIP pour reproduire Agora

Autorisations centralisées à n niveaux

Régie technique AGORA — 2007-02-03T11:34:05Z

Extensions propres à AGORA

Agora dispose de deux extension du système de validation des articles :

2 statuts d'auteurs supplémentaires : rédacteur en chef et webmestre
2 statuts d'articles supplémentaires : validé et archivé

Ces statuts ont été insérés en dur dans AGORA et ne sont pas extensibles.

Il y a cependant un mécanisme pour permettre de paramétrer quel statut d'auteur peut faire quoi.

Comment faire dans SPIP ?

Le plugin autorité

Ce plugin permet de changer certains droits des auteurs dans SPIP. Il ne demande qu'à être étendu.

Des statuts d'articles extensibles

Il reste à inventer un mécanisme d'extension des statuts des articles.

Le cas du statut archivé

Le statut archivé correspond à 2 besoins distincts :

le besoin de donner une date de fin de publication automatique
le besoin de pouvoir manuellement sortir de la publication normale l'article

Dans les 2 cas, il faut pouvoir montrer d'une manière ou d'une autre les articles archivé.

Acces Restreint 2.0

Régie technique AGORA — 2007-02-03T11:30:33Z

Il permet de restreindre l'accès au contenu de l'interface privé. ⇒ équivalent fonctionnel des admins restreints, mais avec une interface différente. - Les plugins SPIP qui reproduisent les fonctionnalités d'Agora