Teddy Payet

Lister les pages de configuration

Teddy Payet — 2015-08-05T07:00:00Z

Ce plugin SPIP permet de lister sur une page tous les liens vers les pages de configuration des plugins.

La version 1.0.0 permet grâce à un pipeline de rajouter des éléments au menu. Les plugins suivants utilisent ce pipeline :

Lister les pages ?exec=xxx
Lister les constantes PHP de SPIP
Lister les extensions PHP chargées
Liste des objets principaux
Les plugins nécessaires au site
Lister les fonctions PHP de SPIP

Plus d'informations :

Plugin « Agrandir la largeur de page »

Teddy Payet — 2015-08-03T07:00:00Z

Ce plugin permet d'agrandir la largeur de la page dans l'espace privé de SPIP. Vous pourrez personnaliser cette largeur si besoin.

Pour informations, le préfixe du plugin est spip_hop. Il vient de l'onomatopée "Hop" qui, selon Wikipedia, signifie une « exclamation suggérant l'exécution d'un saut ou d'une manœuvre habile ». De par sa fonctionnalité principale "les écrans", j'aurais pu l'appeler spip_ecran mais ce terme est trop proche de l'idée "écran de sécurité" induisant ainsi l'utilisateur en erreur.
Mais "Hop" est aussi la réaction des beta-testeurs de ce plugin après son activation. "Et hop !"

Pour plus d'informations :

Plugin « Initialiser Zcore »

Teddy Payet — 2015-07-31T16:00:00Z

Suite à l'article Créer des squelettes avec Zcore, ce plugin voit le jour. Il permet de créer pour tous les objets éditoriaux le squelette nécessaire pour fonctionner avec l'architecture « Z » et plus précisément avec Zcore.

Présentation

Ce plugin reprend les principes dans l'article "Créer des squelettes avec Zcore" et vous aide à faire ces différentes opérations depuis l'espace privé. Après activation, un lien est ajouté dans le menu "Squelettes" : "Squelettes Zcore". Il vous amènera sur la page suivante :

Sur cette dernière, vous avez 3 tableaux :

Les contrôles ;
Les répertoires ;
Les objets éditoriaux.

Plus d'informations :

Plugin "Info Sites" - todo

Teddy Payet — 2014-08-25T19:28:51Z

:Pages
x Liste des organisations commit:z84316
x Liste des projets commit:z84316
x Liste des sites commit:z84316
x Liste des contacts commit:z84316
x Diagnostic ISO des différents sites d'un projet @projets_sites @projets commit:z84358
x Diagnostic d'un site @projets_sites commit:z84380
x Statistiques commit:z84755

:Fonctionnalités
+ Création d'un webservice pour insertion d'une fiche de site, ou projet dans une page externe
Mettre un token pour sécuriser les données

:Page diagnostic d'un site
x Lister les plugins d'un site commit:z97978
x Vérifier la version du plugin sur le site et la dernière mise à jour commit:z97978
x Créer un répertoire de procédure selon le CMS : inclure/diagnostic/spip/blabla.html commit:z97978
x Lien de téléchargement de l'archive commit:z97978
x Lien vers le svn du plugin commit:z97978
+ Version du logiciel

:Page diagnostic ISO des sites d'un projet
x Tableau par champ de la table. commit:z84358
+ Séparation par onglet des listes (administrateurs, webmestres et plugins) du reste des informations. Sinon page trop longue.
+ Essayer de simplifier le code de la page. Possibilité de rendre automatique le retour des balises. On détermine tous les champs de la table, puis on construit les chaînes de langue, retour des valeurs, etc.

:Page projet
x Bouton de modification du projet commit:z84316
x Ajout de formulaires d'édition des liens entre les autres objets
x Ajout de champs liés au dépôt du projet (trac, svn/git, rss des commits etc.)
x Lister les derniers commits du dépôt
x Breadcrumb commit:z84316

:Page organisation
x Bouton de modification de l'organisation commit:z84316
x Liste des contacts commit:z84316
x Liste des projets commit:z84316
+ Création de la page d'édition d'une organisation directement depuis le FO
+ Ajout de formulaires d'édition des liens entre les autres objets
x Breadcrumb commit:z84316

Image : © Barn Images

Plugin « Info SPIP »

Teddy Payet — 2014-07-21T16:00:00Z

Ce plugin permet d'avoir une page, dans la partie privée, donnant la fiche identitaire de votre site et de votre serveur. Il offre aussi la possiblité d'avoir une page au format xml (dans la partie publique) reprenant les même informations que la page du privé.

Ce plugin après activation fournira une page accessible par http://example.org/ecrire/?exec=info_config.

Les pages livrées par le plugin http://example.org/ecrire/?exec=configurer_info_config et http://example.org/ecrire/?exec=info_config ne sont accessibles qu'aux webmestres du site.
En effet, ces informations, plutôt techniques, n'intéressent pas les administrateurs mais les développeurs.

Plus d'informations :

Nettoyer la médiathèque

Teddy Payet — 2014-05-28T07:00:00Z

Ce plugin pour SPIP 2.1 et + a pour but de faire du rangement dans le répertoire IMG/ d'un site SPIP. Il est intéressant dans l'un des cas suivants :

Vous avez un site SPIP avec une version inférieure à la 1.9.2 et vous voulez le monter de version ;
Vous avez un site depuis une version inférieure à SPIP 1.9.2 ;
Vous voulez faire le ménage des logos et des documents orphelins dans votre répertoire IMG/.
Dans tous les cas, ce plugin déplacera les fichiers obsolètes dans un sous-répertoire IMG/orphelins. A vous de décider de leur sort par la suite.

Plus d'informations :

Titre de logo, v2

Teddy Payet — 2014-05-23T07:00:00Z

Ce plugin est une refonte pour SPIP 3.0 du plugin "Titre de logo", créé initialement par ARNO*.

La version 2 du plugin Titre de logo reprend les mêmes fonctions que la v1 mais étend le titre et le descriptif aux logos de tout objet éditorial de SPIP. Il ajoute un titre et un descriptif aux logos.

Plus d'informations :

Concept plugin Projets de sites

Teddy Payet — 2013-11-25T13:18:46Z

Il existe sur la zone un plugin "Projets" créés par Eric et repris par Cyril. Comme son nom l'indique, ce plugin permet de gérer des projets. On y trouve l'essentiel dans ce cadre. Dans un contexte "agence web", j'ai créé le plugin "Projets - Sites Internet".

Présentation

Forcément, quand on est dans une agence web, on réalise... Des sites internet. La bonne méthode dans le monde du web, est de créer 3 types/statuts de site : en production, en recettes, en développement.
Vous pouvez comprendre facilement le concept de ces statuts :
– en développement : et bien, c'est là où l'équipe de développeurs et d'intégrateurs vont ajouter des nouvelles fonctions, tester le nouveau design, etc.
– en recettes : c'est le site sur lequel le client va tester les développements qui ont été réalisé par l'agence. Et après son aval, on migre les fichiers modifiés vers le site en production ;
– en production : le site final auquel les visiteurs ont accès.

Entre autres de ces statuts, pour certaines agences, on pourrait avoir un 4ème statut : pre-prod. C'est la copie conforme du site de production (base de données, contenu éditorial, configuration du serveur, etc.) où on va tester que les fonctions développées sur le site de recette/développement passent correctement dans l'environnement final.

Non non, je ne suis pas parano. Il arrive parfois que les serveurs de dév, de recettes et de prod ne sont pas du tout configurés de la même façon. Cela pour des questions de sécurité de l'infrastructure. Pour schématiser, plus on va vers la version de production, moins de "port" sont ouverts ou moins d'extensions sont activées. Performance et sécurité donc.

Ce qu'on peut renseigner

Pour chaque fiche de site, grâce à ce plugin, nous pouvons renseigner les éléments suivants :

Le nom du logiciel/CMS utilisé (malheureusement tous les sites ne sont pas fait sous SPIP) ;
La version de ce logiciel ;
Le type de site : c'est le statut. J'ai choisi "type" à la place de statut pour ne pas faire doublon avec le statut classique de SPIP ;
date de création ;
Le front office :
- L'URL du front ;
- Le login ;
- Le mot de passe ;
Le back office (le même type d'info que le FO) :
- L'URL ;
- Le login ;
- Le mot de passe ;
  -* Le nom serveur applicatif : le nom du serveur ;
L'URL du site sur ce serveur ;
Surveillance applicative : en gros le logiciel de Monitoring de votre site ;
SVN (Subversion) :
- L'URL pour récupérer les fichiers. Exemple : svn://zone.spip.org/spip-zone/_plugins_/projets_sites/trunk ;
- L'URL pour voir les révisions de vos fichiers. Exemple : http://zone.spip.org/trac/spip-zone/browser/_plugins_/projets_sites/trunk/ ;
SAS DPI : parfois, on a un service DPI (Direction de la production informatique) à qui l'on doit remettre les fichiers à déposer sur le serveur de production.
S.G.B.D. :
- Le type de base de données : MySQL, MongoDB, etc.
- Le nom du serveur ;
- L'URL du serveur ;
- Le login ;
- Le mot de passe ;
SSO : la méthode d'identification ;
Le périmètre d'accès : internet ? Intranet ? Extranet ? etc.
Le logiciel de statistiques : Webtrend, Google Analytics, etc.
Le moteur de recherche : Moteur interne au logiciel ou solution tierce ;
Autres outils ;
Des remarques ;
et enfin la date de création de ce site.

Comem vous pouvez le voir, il y a pas mal d'éléments que nous pouvons renseigner sur une fiche. On n'est pas obligé de renseigner tout pour chaque type de site.

"Oui... Mais"

Vous pourriez me dire, à quoi bon avoir cela lorsqu'on peut le faire dans un fichier word ou excel. Et bien, c'est plus simple d'avoir sur un site de gestion de ressources du service ce genre d'informations pour que les nouveaux membres d'une équipe puisse les retrouver aisément au lieu de chercher une aiguille dans une botte de foin sur le réseau.

Aller plus loin

Cette fois-ci, c'est moi qui dirait "Oui, mais" on peut aller plus loin avec cela.
En effet, il est arrivé à bon nombre de développeurs de faire une fausse manip sur un des serveurs en pensant être sur le site de développement et en fait être sur le site de recettes...
On peut imaginer un service tout simple qui identifiera le type de serveur sur lequel nous nous trouvons. On aura une belle pastille "Site de recettes", "Site de dév".
Il suffirait d'interroger le site référent (où est installé le plugin Projets Sites) pour savoir sur quelle type de site on se trouve. Exemple : http://gestion.example.com/?page=type_site&url=http://dev.example.org et cela nous retourne un json avec le statut.
On peut aussi avoir toutes les infos dudit site qui ont été renseigné.

Sur une page accessible qu'au webmestre du site, on pourrait avoir un comparatif des valeurs de la fiche et ce qui est en fonction des GLOBALS du site : le nom de la BDD, le nom du serveur, etc.

C'est un outil simple de "monitoring" de votre site.

Tickets et ses possibilités de collaboration

Teddy Payet — 2013-01-20T13:08:54Z

Depuis quelques jours, on est un peu en effervescence dans la communauté de SPIP pour trouver un mode d'organisation pour permettre une meilleure participation des contributions sur des projets majeurs.
Voici un peu, pour mise en notes de ma part, une vision que j'ai et surtout les moyens que nous avons aujourd'hui sur la zone.

Préambule

Je pense qu'un mode de boite à idées serait pas mal. Cette boîte à idées pourra être utilisée par toutes personnes inscrites. Eh bien, oui, c'est plus simple pour savoir qui à créer quoi et pouvoir discuter avec cette personne si nécessaire.

RastaPopoulos avait soumis l'idée de cette boîte il y a un an. J'y ai adhéré fortement. Faute de temps, le projet n'a pu avancer.
Mais, ce concept pourrait nous servir aujourd'hui avec quelques améliorations.

Le concept

Avec la boite à idées, une personne poste un message, une amélioration d'un plugin, une idée de création de plugin, de squelettes, de fonctions, etc. Bien entendu, restons respectueux : si c'est pour revendre ce plugin ou cette fonction, payer un prestataire pour vous le réaliser.
Cette boite à idées peut servir aussi pour poster des idées sur la thématique du graphisme : un nouveau logo, une amélioration de visuels déjà présents, etc.
L'idée créée, on peut discuter de cette idée par un forum (= commentaire) attaché.
Puis, on en fait un ticket (on clique sur "créer un ticket" ou "transformer en ticket").
Des personnes s'y inscrivent pour la réalisation. Et hop ! Une équipe constituée, le groupe de travail démarre.

Comme l'a suggéré Fil sur la liste de SPIP-Dev, on pourrait donner une date limite de 6 mois à un groupe de travail constitué. Cela permet à une équipe de se renouveler soit dans les délais, soit pour les membres du groupe.

Passons à l'aspect technique de tout ça maintenant que le décor est posé.

Existant

Il existe des plugins sur la zone qui pourraient nous aider à mettre ce système en place. Le premier auquel on pense, c'est Tickets. C'est vrai que son utilisation initiale est le suivi de bugs. Mais il peut tout aussi bien gérer des tâches à réaliser, de todo list.
Actuellement, il assigne un seul auteur à la réalisation du ticket. Ce qui enlève l'aspect de collaboration. Ceci peut être palier en surchargeant le fichier tickets/prive/squelettes/contenu/ticket.html avec :

#FORMULAIRE_EDITER_LIENS{auteurs,ticket,#ID_TICKET}

On aura ainsi un groupe de travail autour du ticket. Il faut savoir que la table tickets possède un champ #ID_ASSIGNE qui est le #ID_AUTEUR de l'auteur à qui on attribut le ticket.
On peut imaginer que cet auteur-ci est le "chef de projet". Et les auteurs liés au ticket seront les membres du groupe de travail.

Bon, ça c'est fait. Maintenant, il faudrait attribuer une date… Car Tickets n'offre pas cette possibilité. Il faudrait lui ajouter 2 champs : "date" et "date_fin".

date : la date de début du ticket pour le groupe de travail ;
date-fin : eh bien c'est la date où théoriquement prendra fin le ticket et le groupe de travail.

Petit rappel : Fil avait proposé une date limite pour le sujet d'un groupe de travail.
De ce fait, on pourrait donner quelques petites règles à cette date de fin. Lorsqu'on crée une date de début, SPIP vérifie si la date de fin est inconnue. Si oui, alors, on insère la date de début + 6 mois en tant que date de fin.
Si le groupe de travail a besoin de plus de temps, alors le chef de projet change la date de fin…
Avantage aussi, on versionne les champs date et date_fin. On aura une info complémentaire sur l'évolution et un petit historique.

Mais il manque quelque chose. On ne va pas créer un ticket à chaque fois pour chaque idée alors que cela n'aboutira pas forcement sur un groupe de travail.
Donc, il faudrait avoir une table "idees".

Proposer une idée

Pour le concept, revenir au paragraphe plus haut.

Pour cela, on imagine la table "idees" avec les champs suivant :

id_champ
id_auteur
titre
descriptif
date

Les champs sont suffisamment parlant. Du fait du champ "id_auteur" dans cette table, cela sous entend qu'on aura qu'un seul auteur à l'idée… A voir en pratique.

Sur la partie publique, on attache un forum à l'idée pour que l'on puisse discuter et ainsi constituer un petit cahier des charges. Histoire de savoir si on se comprend bien sur l'idée et savoir où on va.

Et hop, ça fait, on a un bouton "Créer un ticket" ou plutôt "Transformer en ticket" pour et bien oui, créer un nouveau ticket.
Sur cette nouvelle page, on aura repris le champ descriptif de la table idees pour la transmettre au champ texte du ticket.
Premier "cron" effectué par cette méthode donc.
Un autre est d'avoir l'idée liée à notre nouveau ticket. Là aussi, principe de la table spip_idees_liens classique à la méthode spipienne.

Voilà voilà.

Aller plus loin

On pourrait créer un formulaire d'inscription des auteurs à un ticket. Ça sera ainsi sur la base du volontariat. Le chef de projet validera les inscriptions pour la constitution du groupe de travail.

"Conclusion"

On a quasiment tous les outils qu'il faut pour créer cette environnement de collaboration dans la communauté. Il faut s'y atteler.

L'avantage certain est de pouvoir mieux communiquer sur les chantiers. On restera ouvert aux avis de tout le monde. C'est un projet opensource, il ne faut pas l'oublier ;-)

Avez-vous des suggestions ? Des points devant être précisés ? Un avis autre sur ce concept ?

Crédit :
Le visuel de cet article est en provenance de DeviantArt. Dave Bardin en est l'auteur.

Plugin Chants

Teddy Payet — 2012-03-12T11:18:31Z

La documentation officielle de ce plugin est publié sur le site SPIP-Contrib.net. Pour toutes informations ou SAD, merci d'utiliser le forum sur la documentation officielle.

Présentation

Le plugin Chants a été créé sur la même structure de chants du logiciel open source, OpenSong. Il permet de référencer des chants pour une présentation en live par exemple. Ou tout simplement les référencer sur votre site internet.

Installation

Il s'installe comme tous les plugins http://www.spip.net/fr_article3396.html
Le plugin nécessite :
– Saisies ;
– Zippeur.

Il utilise aussi Zpip et Compositions. Mais ces derniers ne sont pas obligatoires pour la bonne utilisation de Chants.

Les balises

Voici la liste des balises offertes par ce plugin :
– #TITRE
– #ALIAS : il arrive parfois qu'on connaisse un chant sous un autre nom, un alias.
– #COPYRIGHT
– #ID_CHANT
– #ID_RUBRIQUE
– #ID_SECTEUR
– #DATE_ANNEE : année de sortie du chant ;
– #DATE : date de publication du chant ;
– #NUMERO : le numéro du chant ;
– #PAROLES : les paroles du chant ;
– #PRESENTATION : l'ordre des couplets du chant. Exemple : [V1] [V2] [C] [V1] [R] ;
– #LIGNE_PRINCIPALE
– #CCLI : le numéro du chant au répertoire de CCLI
– #CAPO : un capo (ou capodastre) est un chiffre de 1 à 5 déterminant la position du capo sur le manche de la guitare ;
– #TONALITE
– #TEMPO
– #SIGNATURE
– #STATUT : en cours de rédaction, proposé, publié, refusé, à la poubelle ;
– #LANG
– #ID_TRAD

Les objets liés

Vous pouvez ajouter des mots-clés à un chant mais aussi associer un auteur. L'auteur associé au chant sera ajouté en tant qu'authors lors de l'exportation du fichier xml (cf. ci-dessous).
Si nécessaire, vous pouvez joindre un logo au chant (facultatif).

Les squelettes disponibles

Le plugin fournit un squelette par défaut pour le public. Il affichera toutes les balises du chant.

Intégration rapide sur votre site

Si vous utilisez le plugin Z et Compositions, il existe une composition pour une rubrique dédiée aux chants. Il vous suffit de sélectionner cette composition pour la rubrique désirée.

Exporter en xml

Vous pouvez exporter chaque chant au format xml compatible OpenSong depuis l'espace privé, sur la page du chant.
Mais vous pouvez l'intégrer depuis les pages publiques grâce à cet appel, dans une boucle CHANTS :

[(#SET{filename, [(#CCLI|replace{' ',''})_][(#TITRE|textebrut|replace{\W})]})] [(#URL_PAGE{chant_export.xml}|parametre_url{'id_chant',#ID_CHANT}|parametre_url{'filename',#GET{filename}})]

Le paramètre filename : c'est le nom du fichier qui sera enregistré sur votre bureau. Si vous ne renseignez pas ce paramètre, le nom par défaut sera "chant_export" et vous donnera de ce fait un fichier chant_export.xml.

Les modèles

Vous pouvez exporter une rubrique contenant les fichiers xml compatible OpenSong.
Pour cela, utilisez l'appel au modèle suivant dans une boucle renseignant l'identifiant de la rubrique :

[(#MODELE{repertoire_zip}{id_rubrique})]

Ce modèle utilise le plugin Zippeur cité en début d'article. De ce fait, vous aurez un fichier zip sous la forme "rubrique_XX.zip" où XX est le numéro de la rubrique.
Le fichier sera enregistré dans un sous-répertoire de "local/". Il sera recréé si vous mettez à jour un chant dans ladite rubrique.
Ce fichier, décompressé, pourra être placé dans votre répertoire "Songs" du logiciel OpenSong (se référer à la documentation de ce logiciel pour plus d'informations).