Carnet Wiki

Et si on automatisait tout ça ?

Version 35 — Mars 2017 spipfactory

Arnaud, Jean Christophe, Stéphane de Ch’Nord, Stéphane le charentais (Après le 15 août.) participent et vous ? ; Ne pas hésiter a modifier, corriger ...

Suite a l’expérience d’utilisation de la mutualisation c’est a dire partager le noyau de SPIP entre plusieurs sites., des besoins d’automatisation se sont fait sentir.

Pourquoi faire ?

  • pour certains c’est diminuer les coûts
  • pour d’autres se simplifier la vie

Quels besoins ?

A) Pour la plateforme de SpipFactory.com (nous sommes en mutualisation). (Stéphane).

L’idée est d’utiliser la table auteur de spip , de considérer un inscrit comme visiteur.

On essaye d’utiliser l’existant, ne pas réinventer le fil a couper le beurre

A ce jour l’inscription est bien réaliser dans la table spip auteur, sauf pour :
-  l’Url du site qui ne s’inscrit pas dans la table.
-  l’inscription a la newletters qui ne ce réalise pas (le trio plugin Newsletters, Mailsubscribers, Mailshot)

Un plus serait l’inscription possible a une liste de discussion, avec une case supplémentaire a cocher
(pour nous cela serait Spip-escal (http://listes.rezo.net/mailman/listinfo/spip-escal)

  • partie validation

Lorsque le formulaire a été correctement remplie et valider, une procédure d’installation d’un site spip soit enclenché (Création du site sur la mutualisation, via le nom de l’URL + extension)

  • partie création

Deux webmestres sont créer dans le site.
le premier avec un identifiant et mot pass définie (permet d’intervenir sur le site)
le deuxième avec le Nom d’utilisateur (login) et Mot de passe issue du formulaire.

Est il possible de s’appuyer sur le plugin Création automatique d’un webmestre dans une mutualisation

  • partie envoie de Courriel

l’inscrit recevant un mail (issue de inscription 3 )

<blockquote class="spip">

ceci est un message automatique)

Bonjour stéphane,

votre compte a correctement été créé. Vous avez choisi vous-même votre mot de passe.

Rappel : votre login est "stephane".

</blockquote>

Il serait souhaitable qu’il soit modifier pour recevoir ceci :

<blockquote class="spip">

(ceci est un message automatique)

Bonjour stéphane,

votre compte a correctement été créé. Vous avez choisi vous-même votre mot de passe.

Rappel : votre login est "stephane".

votre site est : http://www.xxx.spipfactory.com ; (url qui a été choisi lors de l’inscription)

</blockquote>

-  partie Projet

Intégration du plugin associaspip pour une gestion plus fine de l’association de Fait SpipFactory

-  Un plus sur le formulaire d’inscription 3

Une cases a cocher pour validation (confirmation de lecture)

    • Mentions légales

— -

Quelques Pistes :

exemple : Nursit pour la première partie du formulaire

<blockquote class="spip">

« Est-on sûr que c’est pas fait en manuel derrière , déjà sur l’exemple proposé ? ;-)
Personnellement je pense que c’est pas fait en auto, déjà car il est pas mal d’avoir une validation manuelle de l’inscription au service. »
(Arnaud B.)

</blockquote>

de ce que j’ai pu lire de la Documentation d’inscription 3, celui ci est capable de gérer une confirmation piur ceux et celles qui le souhaite) (stéphane)

-  l’inscription automatique d’un Auteur Webmestre
permettre au webmestre de la mutu de passer en tant que webmestre dans un site mutualisé, pratique pour du dépannage de configuration du squelette

<blockquote class="spip">

« On peut s’appuyer sur un mécanisme utilisant l’api editer_objet comme pour n’importe quel objet. Cela dit, le problème des comptes c’est qu’on va faire du cross-posting - envoyer sur plusieurs bases, donc c’est pas top, une solution comme celle que tu souhaite serait faisable mais en LDAP - annuaire externe.
C’est pour ça je pense que le Panel a été penssé sur une table dédiée et externe des spip, en fait après si on fait un plugin mutu-connect, qui est dans chaque site à l’instalation on peut avoir une connexion a, cette table, ou une autre en la déclarant, des news rss sur l’accueil, un accès au compte, une aide partagée ... bref c’est comme ça que j’ai pensé le truc pour ma mutualisation perso. »
(Arnaud B.)

</blockquote>

-  Multilinguisme
Le squelette Escal est pré configuré pour le multilinguisme
il serait intéressant lors de l’activation que celui-ci que ça s’active

  • Non car beaucoup d’utilisateurs d’Escal n’utilisent pas le multilinguisme (Jean Christophe)

Que choisit on pour l’inscription / redirection adresse : (Arnaud B.)

  • Domaine : l’utilisateur doit le faire pointer lui-même vers le serveur de la mutualisation (donc faut expliquer ^^ c’est pas gagné).
    • je m’y colle de tenter une Explication ;) (Stéphane)
  • sous.domaine.tld : faut créer le vhost sur le serveur, via un script.sh

Process de l’install :

En partant du principe que le domaine a déjà été redirigé soit par une création de sous-domaine, soit par pointage des dns.

  • Soumission du formulaire d’inscription au service
  • Ajout de l’auteur (inscrit)
    • soit dans une table externe,
    • soit dans la table Auteur du site maitre,
      • ( ça serait bien car en plus , ça permettrai de coupler l’inscription au plugin newletters également (stéphane))
    • soit avec le plugin client en ajout si besoin de champs supplémentaires,
    • soit LDAP.
  • Création des répertoires du site (idem plugin mutualisation)
  • Installation (ici prévoir la possibilité d’import d’une base de démarrage)

A la fin du process d’install :

  • Envoi d’un mail au nouvel inscrit avec son login et son mot de passe, webmestre

Comme nous sommes une plateforme participative :

  • Envoi d’un mail sur une liste de diffusion prévenant l’ensemble des mutualisés qu’il y a un nouvel inscrit
  • Dans notre cas utilisation du squelette Escal (aprés chacun fait ce qui lui plait plait plait ...))

Escal création automatique des Mots-clés

(Arnaud Bérard et Jean Christophe Villeneuve)

  • Test en mutu locale, avec Escal placé en extension (ainsi que agenda/calendrier mini), l’installation des mots-clefs fonctionne dès la création du site. (cf ci dessous, les fichiers modifiés et exemples). (Arnaud B. 6/08/13)

Fichier /escal/paquet.xml

Ajouter un shema dans la description du paquet, pour pouvoir mettre a jour.

<paquet
   prefix="escal"
   categorie="squelette"
   version="3.71.18"
   schema="1.0.0"
   etat="stable"
   compatibilite="[2.10.0;["
   logo="images/escal32.png"
   documentation="http://projetice.crdp.ac-lyon.fr/escal/"
>

 <nom>Escal</nom>

 <auteur>Jean-Christophe Villeneuve</auteur>
 <licence lien="http://www.gnu.org/licenses/gpl-3.0.html">GNU/GPL</licence>
 
 <utilise nom="palette" compatibilite="[2.0.0;[" />
 <utilise nom="spip_400" />
 
 <necessite nom="agenda" compatibilite="[3.11.2;[" />

 <menu nom="escal" titre="escal:escal" parent="menu_squelette" icone="images/escal16.png" action="configurer_escal" />

 <pipeline nom="autoriser" inclure="inc/escal_autoriser.php" />

</paquet>

Fichier /escal/escal_administrations.php

<?php
/**
* Plugin Escal
* (c) xxxx
* Licence GNU/GPL
* Fichier ./escal_administrations.php
*/

if (!defined('_ECRIRE_INC_VERSION')) return;

/**
* Fonction d'installation du plugin et de mise à jour.
* Vous pouvez :
* - créer la structure SQL,
* - insérer du pre-contenu,
* - installer des valeurs de configuration,
* - mettre à jour la structure SQL
**/
function escal_upgrade($nom_meta_base_version, $version_cible) {
   $maj = array();
   include_spip('escal_fonctions');
   include_spip('inc/config');
   include_spip('action/editer_objet');
   
   $maj['create'] = array(
       array('install_groupe_mots'),
       array('ecrire_config', array('escal', array()))
   );
   
   include_spip('base/upgrade');
   maj_plugin($nom_meta_base_version, $version_cible, $maj);
   ecrire_meta($nom_meta_base_version,$version_cible);
   ecrire_meta();
}


/**
* Fonction de désinstallation du plugin.
* Vous devez :
* - nettoyer toutes les données ajoutées par le plugin et son utilisation
* - supprimer les tables et les champs créés par le plugin.
**/
function escal_vider_tables($nom_meta_base_version) {

   include_spip('inc/config');
   $affichage = lire_config('escal/mots_techniques/affichage');
   
   sql_delete('spip_groupes_mots', sql_in("id_groupe", array($affichage)));
   sql_delete('spip_mots', sql_in("id_groupe", array($affichage)));
   
   effacer_meta('escal');
   effacer_meta($nom_meta_base_version);
   ecrire_meta();
}

?>

Fichier /escal/escal_fonctions.php

// Exemple de fonction d'instal de groupes et mots-clef
// a placer dans ./escal_fonctions.php

/*
* function install_groupe_mot
* install les groupes de mots techniques et les mots clefs correspondants
* on les stocke en spip_meta.tbl pour pouvoir les désinstaller, mettre a jour, via une upgrade du shema
*
*/
function install_groupe_mots() {
   // Création du groupe de mot Clef : affichage
   $groupe_affichage = sql_insertq('spip_groupes_mots',array('titre'=>'affichage','tables_liees'=>'articles,rubriques'));
   
   // Création des mots clefs -----------

   // Mot : pas_au_menu
   $pas_au_menu = objet_inserer('mot',$groupe_affichage);
   objet_modifier('mot',$pas_au_menu,array(
       'titre'=>'pas-au-menu',
       'descriptif'=>'pour ne pas afficher une rubrique ou un article dans le menu horizontal'
       )
   );
   
   $result = array(
       'affichage'=>$groupe_affichage,
       'affichage_mots'=> array(
           'pas_au_menu'=>$pas_au_menu
           )
   );
   
   ecrire_config('escal/mots_techniques',$result);
   
   return $result;
}

Comment ?

Une mutualisation de site spip avec le site maître dans la mutualisation

  • permet d’utiliser les fonctions spip

Sur quoi s’appuyer ?


Gestion des plugins

-  Retour d’expérience de mutualisation des plugins et gestion par SVP

La description ci-dessous est la retranscription de la discussion de janvier 2013 sur spip-zone dont le sujet est Plugins, SVP et mutualisation

-  Contexte

Le plugin Mutualisation permet de partager une installation spip, y compris l’ensemble de ses plugins, entre plusieurs sites, définis par des dossiers distincts, des sous-domaines distincts, ou même des domaines distincts.
Ceci permet de n’effectuer la mise à jour de Spip, d’un ou de plusieurs plugins, que sur le site maître pour que l’ensemble des sites mutualisés bénéficient de cette mise à jour.

-  Constat

Imaginons une mutualisation avec un plugin en v1.2.3, ce plugin étant activé dans plusieurs sites esclaves.
Je désire mettre à niveau le plugin en v2.0.0 pour un site seulement. En statut de Webmaster, depuis ce site ou depuis le site maître, j’utilise le gestionnaire de plugins (SVP) pour charger et activer la nouvelle version, et ses dépendances. Très bien.
Mais ces nouvelles versions ayant été chargés, les anciennes ont été supprimées. Donc lorsque l’on visite les autres sites mutualisés, les plugins dans leurs versions attendues ayant disparu, ces sites sont “plantés”.
Il faut alors tour à tour accéder à la partie privée de chacun de ces sites pour activer les nouvelles versions, si tant est qu’on ait eu le désir de mettre à niveau pour ces sites !

Voici le problème posé :

<blockquote class="spip">

« Comment modifier la gestion des plugins pour que la mise à jour d’un plugin sur un site ni ne supprime, ni ne désactive les anciennes versions pour les autres sites ? »

</blockquote>

-  Analyse

Voici l’analyse de départ à laquelle Matthieu Marcillaud a répondu en précisant quelques points :

  • SVP est l’utilitaire (plugin intégré à la Dist de Spip3) de recherche des plugins distants, comparaison de versions installées/disponibles, puis chargement des plugins
  • La procédure qui détecte les plugins installés pour savoir où prendre les différents fichiers surchargés par différents plugins est dans Spip mais hors SVP
  • Lorsqu’un plugin est activé, tout le chemin sous /plugin est enregistré en base de donnée, incluant le numéro de version éventuel
  • Spip3 peut gérer plusieurs versions d’un même plugin, car le dossier au nom du plugin contient les sous-dossiers aux noms de versions. SVP crée ces dossiers “version” automatiquement à la mise à jour de plugins.
  • Lorsqu’un plugin indépendant apparaît dans 2 versions, par défaut seule la version la plus récente est prise en compte par le gestionnaire de plugins et proposée à l’activation.
  • Dans la configuration de SVP, l’option « Autoriser l’activation des paquets obsolètes ? » permet d’activer tous les plugins compatibles (quelles que soient leurs versions).
  • Lorsqu’un plugin est activé dans une version et qu’une nouvelle version est simplement versée dans /plugins (par ftp ou toute méthode hors mise à jour de plugin), c’est l’ancienne qui reste activée
  • Lorsqu’une mise à jour de plugin est demandée à travers SVP, celui-ci charge la nouvelle version, l’active, et supprime l’ancienne version dans /plugins.

A partir de cette analyse, on peut en déduire qu’il est possible, dans le cadre d’une mutualisation, de modifier le comportement de SVP afin qu’il ne supprime pas l’ancienne version d’un plugin au chargement d’un nouveau. Ceci permettra de ne pas modifier le fonctionnement de sites mutualisés sur lesquels on ne désire pas encore upgrader.

Matthieu ajoute, à propos de la suppression de l’ancienne version, que :

<blockquote class="spip">

C’est ligne 860 de inc/svp_actionner.php
À noter que ça ne supprime ces plugins QUE lorsqu’ils sont dans le répertoire auto.

</blockquote>

et

<blockquote class="spip">

Si ce changement fonctionne pour toi, peut être qu’on pourrait ajouter une option à SVP tel que

« Supprimer automatiquement lors des mises à jour des plugins l’ancienne versions (si elle avait été chargée automatiquement) ? »
[x] Oui [ ] Non

</blockquote>


-  Action

  • Sur une mutualisation SPIP3 déjà installée, j’ai :
    • supprimé (commenté) les lignes 860-862 de svp_actionner qui suppriment l’ancienne version d’un plugin mis à jour.
      Ces lignes contiennent
      if (supprimer_repertoire( constant($i['constante']) . $i['src_archive']) ) {
              sql_delete('spip_paquets', 'id_paquet=' . sql_quote($info['i']));
      }
    • configuré SVP pour activer les plugins obsolètes ?exec=configurer_svp
      (normalement à terme pas nécessaire si l’on ne revient jamais en arrière)
    • Aucun dépôt défini sur tous les sites esclaves
    • dépôt défini seulement sur le site maître
  • Chargement pour mise à jour des plugins seulement depuis le site maître (pas de contenu éditorial)
  • Mise à jour des plugins pour un esclave :
    • les plugins apparaissent obsolètes
    • Désactivation/activation des nouveaux plugins
    • Activation des dépendances plus récentes
  • Etat des autres esclaves en report de mise à jour
    • les plugins apparaissent obsolètes mais restent activés
    • des plugins plus récents apparaissent en inactifs mais ne gênent pas
    • En attente de passer par le point précédent "Mise à jour des plugins pour un esclave"

-  Essais

Les essais sont concluants !
Voir l’image de la gestion des plugins inactifs sur le site maître.
Voir l’image de la gestion des plugins actifs sur un site esclave. On constate que les plugins sont pour la plupart obsolètes, mais bien actifs.

Cependant un petit cas à corriger :

  • J’ai un plugin v1.7 sur la mutu activé sur plusieurs esclaves.
  • Sur le site maître, je charge la v1.8, OK.
  • Sur un site esclave, la v1.7 est toujours active, OK.
  • Sur un site esclave, si j’active la V1.8 sans désactiver la v1.7, il supprime la v1.7.

Pour ne pas avoir ce problème, il faut sur le site esclave d’abord désactiver la v1.7, puis activer la v1.8.
Cas donc à traiter aussi.

Autre conséquence : on peut se retrouver avec pléthore de versions obsolètes utilisées par aucun site esclave. Il s’agira d’identifier les plugins inutiles pour pouvoir les supprimer. A automatiser.

-  Développement

On peut donc faire évoluer le plugin Mutualisation pour “Automatiser tout ça”, vers un Tableau de bord étendu comme le propose Bruno Caillard.

Les pistes :

  • D’abord, retrouver dans le code de Spip (SVP ?) la ligne qui supprime l’ancienne version d’un plugin lorsque l’on le met à jour depuis l’esclave sans l’avoir désactivé.
    • D’ailleurs au moment où j’écris ces lignes je crois me rappeler qu’il y a une variable globale de mes_options.php qui permet d’interdire la mise à jour par un admin de l’esclave... à retrouver
  • Suite à la proposition de Matthieu, je suggèrerais une option de SVP pour la mise à jour de plugins :
    Action sur les plugins obsolètes chargés et mis à jour automatiquement :
    (o) Les supprimer
    ( ) Les conserver dans le dossier plugins/auto
    ( ) Les déplacer dans un dossier plugins-bck 
  • Compléter la page /ecrire/?exec=mutualisation du plugin Mutualisation afin de détecter les versions non utilisées de plugins obsolètes.
    Il existe déjà quelque chose qui ressemble à la détection de plugins non utilisés dans exec/mutualisation.php
    • Proposer pour chacun une case à cocher, et pour l’ensemble un bouton Supprimer
    • D’ailleurs au moment où j’écris ces lignes je constate un bug dans cette page : dans la liste des plugins utilisés, il affiche 8 sites sous spip 3.0.5, alors qu’ils sont sous Spip 3.0.10. (La 3.0.5 étant probablement la version de 1re installation ??)
  • ...

Voilà pour poursuivre...

Donc si on peut s’y coller à plusieurs ça serait sympa et profitable à tous.

@micalement