Intégrer une table existante dans SPIP 3 avec la Fabrique Étude, méthodologie, plugins, objet éditorial

, par Matthieu Marcillaud

Pour un site de mode fraîchement migré en SPIP 3 (toujours en développement à l’heure de ces lignes), et pour qu’il soit encore plus à la mode, on m’a demandé de pouvoir gérer des tables SQL déjà présentes en base, depuis l’interface privée de SPIP, et avec quelques contraintes. Ce document a un objectif de transfert de connaissances et se veut pédagogique. Il est fortement recommandé d’avoir lu Chats 2 - SPIP 3 avant de poursuivre.

Cet article va raconter la migration d’une table SQL nommée « villes » (qui n’a rien à voir avec le plugin « géographie »). Cette table devra pouvoir être parcourue depuis l’interface privée, mais seule une ou deux colonnes seront éditables (la table a 15 colonnes), et il ne sera pas possible de créer de nouvelles villes.

Nous créerons une première base du plugin grâce à un autre plugin « La Fabrique » que je développe actuellement. La Fabrique génère les fichiers d’un plugin et peut générer un plugin contenant des objets éditoriaux. Bien sûr, le code produit n’est qu’une base de travail (certes fonctionnel) que l’on édite ensuite à sa sauce.

Il nous faudra migrer les données présentes dans la table, pour créer une colonne de clé primaire id_ville, déplacer les coordonnées géographiques sur le plugin GIS 3, et charger à l’installation du plugin les données des villes.

Copie des tables pour une utilisation en serveur local

Tout d’abord, puisque je travaille uniquement sur un serveur local, j’ai ajouté les tables SQL en question dans une base de données crée sous PHPmyAdmin. Pour cela, j’avais à disposition un export des tables et données au format SQL. En ligne de commande (sous Ubuntu) je charge les données dans la base en me connectant à mysql :

Ensuite, dans un SPIP3 local, je vais déclarer ma nouvelle base sur la page « Maintenance technique » de sorte que je peux boucler sur ces nouvelles données

Fabriquer la base du plugin

Nous allons générer un premier jet de plugin en utilisant la Fabrique. Dans un premier temps sans trop rien de plus. Une fois le plugin activé, il faut se rendre sur Squelettes > La Fabrique. Si un plugin avait été construit auparavant, il faut aller réinitialiser le formulaire dans l’onglet prévu.

On peut alors remplir les informations relatives au plugin. Cette première page (en ayant rempli la partie « paquet ») suffit à générer des fichiers du plugin (bouton « Créer le plugin ») mais nous allons continuer et ajouter un objet éditorial.

L’objet éditorial ajouté, l’interface propose d’utiliser une table existante pour en déduire la structure des données notre objet éditorial. Ici, j’utilise la table « villes » sur le connecteur « source ».

Au retour du pré-chargement, les infos de l’objet ont été déduites si cela était possible, et au mieux de l’information disponible. Il faudra donc apporter pour chaque partie quelques corrections ou informations supplémentaires.

En complétant quelques parties, on peut ajouter des logos, gérer les champs (en plus ou en moins), les déplacer, leur attribuer des types de saisies. On peut trouver des logos par exemple sur http://thenounproject.com, qui m’a servi dans cet exemple. Les chaînes de langues sont pré-remplies également (en français) et on peut lancer une première création du plugin.

Une fois créé, on peut se rendre sur la page d’administration des plugins pour l’activer et le tester.

Dans édition > villes on découvre la liste, vide, des villes. Et l’on peut alors créer une nouvelle ville. Évidemment, il faut avoir ajouté des saisies dans certains champs de notre objet dans la Fabrique, sinon le formulaire d’édition sera vide. Pour les tests, j’avais créé 2 champs en plus de ceux de la table d’origine : nom et description.

À la validation du formulaire, on obtient cependant un joli message d’erreur.

Cela signifie, dans notre cas qu’il y a eu une erreur SQL au moment de l’insertion. Un tour dans les logs nous indique l’erreur :

On comprend que la description SQL des champs de la table d’origine ne correspond pas tout à fait au fonctionnement de SPIP. En effet, SPIP crée d’abord une ligne vide dans un objet et obtient ainsi un identifiant de ligne (ici un id_ville) pour insérer ensuite les valeurs soumises par le formulaire d’édition. Or dans ce cas, des champs ne tolèrent pas d’être « NULL » mais n’ont pas de valeur par défaut de définis. Il nous faut donc, pour chaque champ dans ce cas, ajouter cette valeur par défaut, ce qui revient le plus souvent à ajouter « DEFAULT ’’ » dans l’expression SQL du champ

On retourne donc dans la fabrique pour le faire, on recrée le plugin, on désinstalle puis réinstalle notre plugin dans admin plugin, puis on reteste.
Cette fois l’insertion se passe bien.

Peupler notre plugin avec les données de la table d’origine

Tout ceci est bien joli, mais dans notre cas, ce qui nous intéresse est de peupler notre table de ville avec un contenu pré-défini, à l’installation du plugin. Le contenu se trouve actuellement dans la table source ayant servi de base de déclaration de notre objet. Une fois peuplé, il faut afficher les champs, mais ne mettre que la description éditable (le reste étant figé).

La Fabrique ne gère pas depuis le formulaire de création du plugin l’insertion de ces données, mais propose sur la page ?exec=fabrique_peuple un outil pour se faciliter cette tâche.

Cet outil crée un ou deux fichiers qui seront à placer dans le répertoire base/ du plugin que l’on a créé. Il faut également ajouter l’appel de la fonction d’insertion dans le fichier d’administration lors de la création de la table, avec :

Cette fonction d’import gère la reprise de l’insertion des données en cas de timeout (trop de temps utilisé par rapport à ce qui est autorisé dans la configuration de PHP). Très utile pour insérer ces 36000 lignes en SQLite notamment.

Du coup, nous pouvons voir sur la liste des villes que le compte est bon, mais que… nous n’avons pas correctement redéclaré le champ servant au calcul du titre. Je l’avais déclaré sur la colonne « nom » pour tester, colonne que j’avais créé, mais l’insertion insère les noms de nos villes dans une autre colonne. Il nous faut donc :

  • corriger soit directement notre plugin
  • soit en passant par la Fabrique, modifier les colonnes, recréer le plugin, remettre les fichiers d’imports, désinstaller et réinstaller notre plugin (réinstallation uniquement utile si une colonne a été ajoutée ou retirée, ce qui va être le cas car je vais supprimer la colonne « nom »).
Mettre le bon nom de colonne de titre

Les noms de ville s’affichent bien, mais il y a un problème de charset. Les données de la table d’origine ne semblent pas au bon format. Nous allons donc modifier notre script d’import pour corriger les caractères au passage et tester sur un panel d’insertion plus petit pour aller plus vite.

On choisit dans la fonction importer_spip_villes() du fichier du même nom de ne prendre que 100 villes, grâce à la fonction array_slice() :

Et l’on teste un utf8_encode() un peu plus loin :

Une fois désinstallé et réinstallé le plugin, on obtient les bons accents (coup de bol !).

On peut donc enlever la limitation à 100 villes, et réinstaller le plugin complètement.

Perdre le moins de modifications possibles entre chaque recréation de notre plugin

Au fur et à mesure de ces travaux, je constate qu’il est effectivement embêtant de devoir remettre les modifications apportées au plugin après sa création, à chaque fois qu’on le recrée avec la Fabrique (comme les fichiers d’import de ville et l’ajout de notre fonction dans $maj).

Après 3 jours de réflexions, j’opte pour un compromis qui me satisfait pour le moment :

  • à chaque fois que l’on crée le plugin, une copie de l’ancien est sauvegardée et la Fabrique génère un « diff » entre les répertoires. Si des fichiers manquent dans le nouveau plugin, une alerte est levée et on affiche la liste de ces fichiers absents bien visibles après la création. Ainsi, si c’est un oubli de les remettre dans le nouveau plugin, on peut les récupérer dans la sauvegarde.
  • des points d’insertions sont ajoutés où l’on peut intégrer son propre code, rempli depuis l’interface de création du plugin. Évidemment, il faut que ce code soit valide, la Fabrique ne peut pas le vérifier !
  • des points d’exécution de scripts sont ajoutés où l’on peut faire exécuter du code (via eval()) que l’on rempli depuis l’interface également. Ce code ne sera exécuté uniquement si l’on est webmestre (sinon c’est potentiellement très dangereux). Ainsi, on peut, après la création du plugin, déplacer des fichiers qui étaient présents dans la sauvegarde.

Nous ajoutons donc, dans la partie insertions le code d’insertion des données de la ville, et dans la partie script, la recopie des fichiers allant avec :

Le code de recopie est donc assez simple :

Migrer à l’installation les données géographique des villes vers le plugin GIS

L’ancienne table de villes contient des données géographiques que l’on va migrer vers des points du plugin GIS. Chaque ville sera donc liée à 1 point géographique. Il va donc nous falloir modifier le script d’import qui avait été automatiquement créé, pour gérer notre spécificité.

Pour s’en sortir et tester, on remet déjà une liste courte de villes, et non les 37000. En prendre 10 suffira largement. On remet donc le array_slice sur le fichier d’import :

Sur le principe, il faudra :

  • créer un point géographique pour chaque ville (table spip_gis) et récupérer d’identifiant
  • créer la ville et récupérer son identifiant (table spip_villes)
  • ajouter le lien entre les 2 (table spip_gis_liens)

Du coup, on ne peut plus utiliser la fonction d’insertions multiples (sql_instertq_multi), puisqu’il va falloir agir ligne par ligne.

Commençons pas ajouter le plugin GIS dans les dépendances du plugin.
Pour cela, on ajoute dans la Fabrique, paquet > insertions de code > paquet.xml la ligne :

Nous n’avons plus besoin des colonnes « lon » et « lng » de la table « spip_villes » que l’on supprime alors dans la Fabrique. On observe un peu les tables de GIS (dans base/gis.php du plugin GIS). On en déduit comment doit se réaliser notre migration. On fait un premier jet de code.

On installe désinstalle notre plugin, ainsi que GIS s’il était là, puis le réinstalle.
On va dans la configuration GIS dire qu’on a besoin de GIS sur les villes, mettre un générateur de carte et une position par défaut (on fera cela dans une fonction d’installation ensuite pour automatiser), et on se rend sur une ville pour voir.

On voit entre autres que… la ville française est placée quelque part en Afrique. Quelque chose cloche ! Il faut comparer nos données en base avec la table originale pour savoir si on a bien remis les mêmes valeurs.

Dans la table source, j’ai :

lnglat
45.979851 5.33689

Dans la table de GIS, j’ai :

lonlat
45.979851 5.33689

Manifestement, ce sont bien les mêmes données. Le problème est ailleurs.
Je vais donc créer un nouveau point dans GIS pour comparer. Au hasard, je prends Grenoble, qui ne semble pas très loin en coordonnées.

Et là je lis dans ma table

lonlat
5.745458496026258 45.17920020811579

Soit l’inverse. Ce qui veut dire que les coordonnées sont inversées dans la table source ! Magnifique. Plutôt que d’adapter notre script, on inverse les colonnes dans la table source (via phpmyadmin ou sqlite manager selon), et on la réexporte depuis la Fabrique. On remplace simplement le fichier compressé de données ensuite et on inverse les colonnes dans le tableau $cles du fichier importer_spip_villes.php. On retourne désinstaller, réinstaller GIS et notre plugin, on reconfigure GIS, puis on va tester une ville. Aussitôt, c’est bien mieux placé.

Configurer GIS au démarrage de notre plugin

Puisque notre plugin ajoute des points sur les villes, autant activer les villes sur GIS dès l’installation de notre plugin. Pour cela, on génère un tableau de la configuration de GIS (une fois configuré), en écrivant dans un quelconque squelette (disons test.html que l’on appellera ensuite par ?page=test) :

Ce qui nous donne (ici) :

On ne garde que les infos que l’on veut proposer :

On s’arrangera pour qu’à l’installation, si GIS est déjà configuré, que l’on n’écrase pas sa configuration, mais que l’on ajoute simplement la ville. On utilisera pour cela la fonction array merge de PHP.

Et on ajoute au code inséré par la Fabrique dans l’installation notre modification de la configuration de GIS, en créant une fonction (qui se retrouvera l’intérieur de la fonction de mise à jour, mais PHP tolère cela).

Améliorer le chargement des points

On peut maintenant améliorer un peu notre fonction de peuplement en :

  • encapsulant dans une transaction l’ensemble des requêtes si le moteur le préfère. C’est en fait un hack pas terrible pour SQLite, qui permet de ne pas lui faire générer de verrous pour chaque requête, ce qui lui prend du temps. Du coup, il en génère un pour un groupe de requêtes cohérent.
  • en testant qu’un point GIS identique n’existe pas déjà avant d’en créer un nouveau
  • en utilisant une fonction interne de SPIP pour les liaisons entre gis et la ville.

Cela donne :

Supprimer les informations liées à GIS à la désinstallation de notre plugin

Comme on l’a fait pour l’installation, il faut également supprimer nos informations à la désinstallation :

  • la table « spip_villes » dans la config de GIS
  • les liaisons « spip_gis_liens » avec les villes
  • les points GIS qui étaient liés à une ville mais qui ne sont plus utilisés.

On insère notre code dans la partie prévue par la Fabrique (insérer > administrations > vider_table).

Fin du premier épisode

Bien, nous avons avec ceci à peu près migré correctement une table en l’intégrant dans un objet éditorial géré par SPIP. Il y a eu depuis quelques petits changements dans les codes qui n’ont pas lieu d’être commentés ici. Par exemple le script d’importation de données indique le nombre d’éléments qui sont insérés s’il doit se relancer en cas de timeout.

Dans le prochain article nous allons ajouter à notre plugin un autre objet avec d’autres contraintes.