Version 31 — Octobre 2013 — 86.201.xx.xx
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 ?
↓
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)
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)
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
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)
— -
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.)
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
« 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.)
- 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
Que choisit on pour l’inscription / redirection adresse : (Arnaud B.)
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.
A la fin du process d’install :
Comme nous sommes une plateforme participative :
(Arnaud Bérard et Jean Christophe Villeneuve)
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.."
etat="stable"
compatibilite="[2.10.;["
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..html">GNU/GPL</licence>
<utilise nom="palette" compatibilite="[2..;[" />
<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;
}Une mutualisation de site spip avec le site maître dans la mutualisation
- 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 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 :
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.
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
- Action
if (supprimer_repertoire( constant($i['constante']) . $i['src_archive']) ) {
sql_delete('spip_paquets', 'id_paquet=' . sql_quote($info['i']));
}- 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 :
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 :
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
/ecrire/?exec=mutualisation du plugin Mutualisation afin de détecter les versions non utilisées de plugins obsolètes.exec/mutualisation.php, mais ça ne sort rien sur ma mutu.... je creuse...Supprimer
Voilà pour poursuivre...
Donc si on peut s’y coller à plusieurs ça serait sympa et profitable à tous.
@micalement