Plugins spéciaux /mise-à-jour

Rappelons d’abord qu’un plugin (particulièrement depuis SPIP3) est défini, plus que par son nom [1], par son préfix de plugin [2], rappelé dans paquet.xml. ]] qui sera utilisé pour générer le sous-dossier dans le répertoire d’installation, et le nom du fichier .zip d’archives.
Plus précisément ce fichier texte paquet.xml descriptif du plugin, structuré au format XML, contient en particulier deux champs importants, respectivement prefix et version, correspondants aux nom interne du plugin, et à son numéro de version.

 Les organisations standardisées des Plugins sous SPIP

Le développement de SPIP s’est très tôt structuré entre un cœur (le core de SPIP) et des greffons, les plugins, ensembles de sous-programmes avec une organisation standardisée et un processus de gestion automatisée cohérent.
De ce fait, deux dossiers parallèles permettent une autre forme de surcharge des sous programmes, tant ceux faisant partie du développement interne à SPIP (voir plugins-dist, (ou extensions)) que ceux, facultatifs, rajoutés par le webmestre dans plugins ; mais ces deux dossiers induisent des comportements quelque peu distincts...

 Accès et organisation des dossiers

Chaque plugin se déploie (avec son arborescence de fichiers source) dans un sous-répertoire (à son nom-préfixe de plugin [3]).
L’installation de SPIP (par FTP à partir du source .zip ou par spip_loader) dépose automatiquement les sources des plugins verrouillés dans les sous-dossiers correspondants de ./plugins-dist .
L’ajout de plugins (utilisateurs, facultatifs au choix du Webmestre) dits "non verrouillés" dans SVP se fait dans l’arborescence de ./plugins [4], en créant un dossier selon le "plugin-préfix énoncé dans le paquet.xml !
 l’accès aux sources du plugin est automatique dans chaque sous-dossier de ./plugins/. dès que SPIP trouve un fichier plugin.xml ou paquet.xml,
 si la création est automatisée par SVP dans ./plugins/auto, celui-ci a pour habitude de recréer, sous le dossier nommé par le préfixe, un sous-dossier au nom du numéro de version [5].

Exemple du dossier d’un Plugin Agenda (v3.16.1)

Création automatique d’un sous-dossier de ./plugins/auto/agenda/

 Les Processus de mise-à-jour

La gestion des plugins "non-verrouillés" est proposée automatiquement par SPIP dans le menu Configuration / Gestion des Plugins, au seul Webmestre, là où il peut également configurer les plugins (comme dans l’exemple ci-dessous.

Activer le bouton "Mettre à jour" proposé au survol quand le plugin est marqué d’une petite roue indiquant une mise-à-jour disponible, provoquera le téléchargement du source correspondant, avec installation automatique dans le sous-répertoire de la nouvelle version.

Les boutons de mise-à-jour, déclenchables au survol

Ensuite, le déclenchement de la fonction de mise-à-jour des tables (voir l’appel de la fonction ... dans prefixe-plugin_administrations.php, utilisant l’API interne de SPIP, se fera toujours quand :

• SPIP détecte la modification du fichier paquet.xml (précisément lorsque l’entrée ’schema’ augmente par rapport à la valeur de version_base en BDD dans spip_meta),
• et lors du passage sur la page de gestion des plugins.
  Ce processus automatique lance les adaptations éventuelles de tables demandées dans les fonctions prefixe-plugin_upgrade(, qu’il s’agisse d’un plugin verrouillé ou non, selon l’exemple ci-dessous :

  

  Exemple partiel de fonction upgrade d’un plugin

Enfin un petit rappel (piégeant) : mettez toujours à jour les plugins juste AVANT de faire la mise à jour du CORE SPIP !