HOME > RSS > BLOGS France > [SPIP - contrib]

R S S : [SPIP - contrib]


PageRank : 1 %

VoteRank :
(0 - 0 vote)





tagsTags: , , , , ,


Français - French

RSS FEED READER



Co-Marquage Service Public

20 January, by Laurent Vergerolle, Mickaël Hippocrate, Olivier Watté[ —]

Co-Marquage Service Public est un plugin permettant d'intégrer et de rediffuser, sur un site fonctionnant sous SPIP, les contenus et services offerts par le portail de l'administration française, Service-public.fr.

Ce plugin fonctionne avec le Flux v3 de co-marquage et peut remplacer de manière transparente le plugin Comarquage Service public Flux v2 sur un site existant.

À propos du co-marquage

Le co-marquage s'adresse aux services de l'État et aux administrations locales :
il permet aux sites web locaux de rediffuser les contenus et les services offerts par le portail de l'administration française Service-public.fr, en le complétant par des informations locales : coordonnées d'organismes, téléservices locaux, etc.

Depuis août 2016, une nouvelle organisation des fichiers XML, appelée Flux v3 a été mise en place et l'arrêt des mises à jour du Flux v2 a été annoncée officiellement.

Installation

L'installation se déroule comme pour tous les autres plugins.

Compatibilité avec la version 0.x

Si vous utilisez déjà le plugin Comarquage Service public Flux v2 aucune modification des squelettes existants n'est à effectuer ; les nouveaux modèles remplacent ceux fournis par Comarquage Service public Flux v2.

Utilisation

Après avoir installé le plugin, le flux s'insère dans un article au moyen des modèles suivants :

  • flux pour les Particuliers :
  • flux pour les Professionnels :
  • flux pour les Associations :

Intégration

Les squelettes de Co-Marquage Service Public utilisent les classes et composants de Twitter Bootstrap v3.3.7.

Le flux est récupéré grâce à la balise DATA. Les boucles sont en cache par défaut pendant 86400 secondes (soit 24 h).

Les XMLs de co-marquage sont copiés en local |copie_locale{modif}. Pour forcer le re-téléchargement des XMLs vider le répertoire IMG/distant/xml.

Astuces

Vous pouvez appeler une page précise en définissant l'attribut xml du modèle.

Par exemple pour afficher la page Mariage de la catégorie particuliers, utilisez ce code :
.

Pour appeler la page Formalités administratives de la catégorie Associations, insérer ce code :
.

TODO

  • Gérer les pivots pour les informations locales ;
  • ajouter un moteur de recherche interne au co-marquage ;
  • prendre en charge les redirections. cf. redirection.xml ;
  • gérer les définitions et les acronymes. cf .

Contribuer

Si vous trouvez ce plugin utile, vous pouvez :

  • soumettre un Pull Request, pour que nous intégrions vos améliorations ou corrections de bug ;
  • participer aux forums et aider les utilisateurs à intégrer ce plugin.
Co-Marquage Service Public est un plugin permettant d'intégrer et de rediffuser, sur un site fonctionnant sous [SPIP->http://www.spip.net/], les contenus et services offerts par le portail de l'administration française, [Service-public.fr->https://www.service-public.fr/]. Ce plugin fonctionne avec le {Flux v3} de co-marquage et peut remplacer de manière transparente le plugin [Comarquage Service public Flux v2->https://contrib.spip.net/Comarquage-Service-public-Flux-v2] sur un site existant.
{{{ À propos du co-marquage }}} Le co-marquage s'adresse aux services de l'État et aux administrations locales : il permet aux sites web locaux de rediffuser les contenus et les services offerts par le portail de l'administration française [Service-public.fr->https://www.service-public.fr/], en le complétant par des informations locales : coordonnées d'organismes, téléservices locaux, etc. Depuis août 2016, une nouvelle organisation des fichiers XML, appelée {Flux v3} a été mise en place et l'arrêt des mises à jour du {Flux v2} a été [annoncée officiellement->https://www.service-public.fr/partenaires/comarquage/actualites/15-06-2016-evolution-flux-en-2016]. {{{ Installation }}} L'installation se déroule comme pour tous les [autres plugins->http://www.spip.net/fr_article3396.html]. {{{ Compatibilité avec la version 0.x }}} Si vous utilisez déjà le plugin [Comarquage Service public Flux v2-> https://contrib.spip.net/Comarquage-Service-public-Flux-v2] aucune modification des squelettes existants n'est à effectuer ; les nouveaux modèles remplacent ceux fournis par [Comarquage Service public Flux v2->https://contrib.spip.net/Comarquage-Service-public-Flux-v2]. {{{ Utilisation }}} Après avoir installé le plugin, le flux s'insère dans un article au moyen des modèles suivants : -* flux pour les {Particuliers} : _ -* flux pour les {Professionnels} : _ -* flux pour les {Associations} : _ {{{ Intégration }}} Les squelettes de {Co-Marquage Service Public} utilisent les classes et composants de [Twitter Bootstrap v3.3.7->https://getbootstrap.com]. Le flux est récupéré grâce à la balise DATA. Les boucles sont en cache par défaut pendant {{86400 secondes}} (soit 24 h). Les XMLs de co-marquage sont copiés en local |copie_locale{modif}. Pour forcer le re-téléchargement des XMLs vider le répertoire IMG/distant/xml. {{{ Astuces }}} Vous pouvez appeler une page précise en définissant l'attribut xml du modèle. Par exemple pour afficher la page {Mariage} de la catégorie {particuliers}, utilisez ce code : _ . Pour appeler la page {Formalités administratives} de la catégorie {Associations}, insérer ce code : _ . {{{ TODO }}} -* Gérer les pivots pour les informations locales ; -* ajouter un moteur de recherche interne au co-marquage ; -* prendre en charge les redirections. cf. redirection.xml ; -* gérer les définitions et les acronymes. cf . {{{ Contribuer }}} Si vous trouvez ce plugin utile, vous pouvez : -* [soumettre un Pull Request->https://github.com/ipeos-and-co/spip_comarquagev3/pulls], pour que nous intégrions vos améliorations ou corrections de bug ; -* participer aux forums et aider les utilisateurs à intégrer ce plugin.

Envoyer des fichiers avec un formulaire Formidable

2 January, by Maïeul[ —]

La version 3.0.0 du plugin Formidable permet de créer des formulaires comprenant des envois de fichiers. Cet article regroupe la documentation relative à cette fonctionnalité. Pour une présentation générale de Formidable, voir « Formidable, le générateur de formulaires ».

Configuration requise

Afin de pouvoir accéder à la fonction d'envoi de fichiers il vous faut :

  • Le plugin CVTupload dans sa version 1.9.4 au minimum. Attention, il reste possible d'activer Formidable sans avoir ce plugin. Simplement, il sera alors impossible d'envoyer des fichiers avec Formidable.
  • Le plugin Formidable en version 3.0.0, lequel nécessite notamment :
    • le plugin Saisies en version 2.17.0 au minimum ;
    • le plugin Vérifier en version 1.4.1 au minimum.

Configuration des fichiers à envoyer

Lors de la création d'un formulaire, il est possible de choisir un champ de type « Fichier(s) ».

PNG - 82 ko
Insertion d'un nouveau champ d'envoi de fichiers

Ce type de champ possède un certain nombre de propriétés configurables. Certaines, telles le titre, sont communes à l'ensemble des champs proposés par Formidable. Nous ne nous attarderons pas dessus, et n'exposerons que les propriétés spécifiques au type de champ « Fichier(s) ».

PNG - 16.7 ko
Accéder à la configuration d'un champ « Fichier(s) »

Nombre de fichiers

Dans la configuration du champ, l'onglet « Utilisation » permet de choisir le nombre de fichiers à envoyer pour ce champ. Par défaut, la valeur est 1.

PNG - 39.9 ko
Configuration du nombre de fichiers par champ

Notez qu'il s'agit du nombre de fichiers pour ce champ, mais qu'il est possible d'ajouter des champs supplémentaires pour d'autres fichiers, ce qui permet de distinguer les fichiers selon les besoins.

Pour l'instant, chaque fichier est associé à un input unique, afin d'être compatible avec un maximum de navigateur. Dans le futur, des versions améliorées de la saisie pourront être disponibles pour améliorer l'ergonomie.

PNG - 12.1 ko
Exemple de champ permettant d'envoyer un seul fichier
PNG - 16.7 ko
Exemple de champ permettant d'envoyer plusieurs fichiers

Notez que si un·e internaute triche et modifie le HTML afin d'envoyer plus de fichiers, le système n'enregistrera pas plus de fichiers que configurés.

Puisque chaque fichier est associé à un input unique, chaque input reçoit un label individuel. Il est cependant possible de désactiver ce label pour n'afficher que le label commun à l'ensemble des fichiers.

Validation

L'onglet « Validation » de la configuration du champ permet de régler les propriétés des fichiers envoyés.
Cet onglet est assez long, car il permet de choisir finement les types de fichiers autorisés à l'envoi.

PNG - 102.3 ko
Présentation globale des options de vérification d'un champ d'envoi de fichiers

Caractère obligatoire

La première option dans cet onglet, est, comme pour tous les champs, le caractère obligatoire ou non de l'envoi de fichier.

Notez que dans le cas d'un champ permettant d'envoyer plusieurs fichiers, on considère que l'obligation d'envoi est remplie à partir du moment où un fichier est envoyé. Si vous souhaitez imposer l'envoi de trois fichiers, il vous faut créer trois champs [1].

Type Mime et extension

Une première série de boutons radio permet de choisir types de fichiers sont autorisés :

  • Autoriser tous les types et extensions cette option est très déconseillée ;
  • Autoriser tous les types Mime et extensions connues de SPIP dans sa table spip_types_documents [2] ;
  • Autoriser uniquement les les images web (gif, jpg, png) (.jpg, .png, .gif) ;
  • Autoriser uniquement les types et extensions sélectionnés parmi les cases à cocher ; utile par exemple pour n'autoriser que l'envoi de pdf. Les cases à cocher de choix de type n'apparaissent que si on choisit cette option.

Notez les points suivants :

  • Dans tous les cas, Formidable zippera automatiquement les fichiers d'un type et/ou d'une extension absente de la table spip_types_documents, afin notamment d'empêcher son exécution sur le serveur.
  • Si vous choisissez l'option « Tous les types Mime et extension autorisés par SPIP » ou « Un type Mime associé à une extension précisée ci-dessous » la vérification se fera :
    • la plupart du temps, sur la base du type Mime détecté par PHP et de l'extension du fichier
    • lorsque PHP détecte un type Mime text/plain ou application/octet-stream, qui sont très génériques, sur la seule base de l'extension [3].

Taille du fichier

La taille du fichier est, de facto, limitée par la configuration de votre serveur. Souvent par défaut, 32 kio [4].

L'ami Marcimat travaille actuellement sur un projet « BigUp » qui permet d'envoyer des fichiers plus gros. Si cela est nécessaire pour vos besoins, le contacter.

En dehors même des limites techniques, il peut être utile de limiter pour des raisons éditoriales la taille des fichiers envoyés. Pour cela, il vous suffit de remplir le champ « taille » en indiquant une taille maximale en kio.

Notez ces deux points :

  • la vérification de la taille a lieu après l'envoi du fichier sur le serveur
  • la vérification de la taille se comprend fichier par fichier, et non pour l'ensemble des fichiers d'un même champ.

Dimension de l'image

Une dernière série de réglages permet de vérifier la dimension des images envoyées.

JPEG - 42.4 ko
Configuration de la dimension d'une image

Notez qu'il faut dans ce cas s'assurer que le document envoyé est bien une image en choisissant la bonne option auparavant. De plus, la fonction utilisée pour déterminer la taille de l'image est getimagesize(), qui ne comprend pas tous les types d'images.

Il est possible de préciser une largeur maximum (en pixels) et une hauteur maximum (en pixels). Une option permet également d'autoriser les images qui rentrent dans ces dimensions lorsqu'on les tourne de 90°.

Configuration des traitements

Comme pour tous les formulaires Formidable, un formulaire proposant l'envoi de fichier peut enregistrer les réponses et/ou les envoyer par courriel. Il n'y a rien de particulier à faire dans le cas qui nous occupe. Cependant, notez ces deux points :

  • Au moment de l'enregistrement des traitements, Formidable vérifie s'il est possible d'enregistrer les fichiers à un endroit inaccessible par http. En cas de problème, un message est affiché, et dans ce cas l'envoi des fichiers ne pourra avoir lieu tant que le problème ne sera pas résolu. Voir plus bas, le paragraphe sur « Où les fichiers sont-ils stockés ? ».
  • Il est conseillé de choisir l'enregistrement des réponses, et de ne pas se contenter de l'envoi par email. En effet, les fichiers ne sont pas joints dans le courriel, pour éviter des problèmes en cas de fichiers lourds, mais un lien y est inséré. Or, ce lien expire 24h après l'envoi du formulaire. Si vous choisissez cependant de ne pas enregistrer les réponses, il est possible d'augmenter ce délai en mettant la ligne suivant dans votre fichier mes_options.php :
    1. define ('_FORMIDABLE_EXPIRATION_FICHIERS_EMAIL', <une_durée_exprimée_en_seconde>);

    Si la durée est mise sur 0, le lien est valable ad vitam aeternam.

Utiliser le formulaire en tant que visiteur⋅euse

Une fois le formulaire publié sur le site public, le·la visiteur⋅euse peut le remplir et choisir les fichiers à envoyer.

Si ielle envoie une réponse avec des erreurs dans un champ, les fichiers déjà envoyés sont conservés, et il n'a pas besoin de les renvoyer. Ielle peut cependant décider, le cas échéant, de supprimer des fichiers déjà envoyés.

PNG - 40.1 ko
Lorsqu'un formulaire contient une erreur, les fichiers envoyés sont conservés

Si vous autorisez un·e visiteur·euse à modifier une réponse envoyée, le formulaire de modification de réponse lui propose automatiquement les fichiers qu'ielle a auparavant envoyés, avec la possibilité de supprimer – et donc de remplacer – des fichiers.
Notez que, comme pour les autres champs, il n'est fait aucune sauvegarde des anciennes valeurs.

PNG - 30.7 ko
Exemple de présentation d'un formulaire pour modifier une réponse déjà existante
PNG - 43.6 ko
Exemple de remplacement d'un fichier envoyé auparavent

Récupérer les fichiers envoyés

Les fichiers envoyés sont stockés dans un endroit normalement inaccessible au public. Dans la présentation des réponses, que ce soit dans l'espace privé de SPIP ou par courriel, un lien est inséré.
Ce lien est sécurisé de telle sorte que seules les personnes ayant le droit de voir les réponses ou ayant reçue le courriel puissent télécharger le fichier.

PNG - 17.9 ko
Présentation des fichiers envoyés dans la réponse d'un formulaire

Notez que quelques changements sont effectués dans le nom des fichiers envoyés :

  • passage en minuscule ;
  • suppression des accents ;
  • remplacement des espaces par des tirets-bas ;
  • suppression des points initiaux si le nom du fichier commence par un point ;
  • ajout éventuel de suffixe pour distinguer les fichiers homonymes ;
  • mise en zip du fichier s'il n'est pas d'un type ou d'une extension listée dans la table spip_types_documents

Dans l'accusé de réception, ces liens sont également insérés.
Cependant, il est possible désactiver cela en mettant la ligne suivante dans le fichier mes_options.php :

  1. define('_FORMIDABLE_LIENS_FICHIERS_ACCUSE_RECEPTION', false);

Où les fichiers sont-ils stockés ?

Cette partie de la documentation intéresse surtout les webmestres et non les administrateur·trice·s.

Dans tous les cas, les fichiers sont enregistrés dans le dossier config/fichiers/formidable, qui est automatiquement créé. Il vous faut donc transférer le dossier config/fichiers [5] lorsque vous migrez un site d'un serveur à un autre, et si possible sauvegarder régulièrement ce dossier.

Normalement SPIP s'assure que le dossier config n'est pas accessible en lecture à l'extérieur.
Par précaution, Formidable s'assure également de cela à chaque envoi du fichier.
Si ce critère n'est pas rempli, ou s'il est impossible d'écrire dans config/fichiers/formidable :

  • un message de log est enregistré dans formidable.log ;
  • le fichier n'est pas déplacé dans config/fichiers ;
  • un courriel est envoyé au webmestre, ce qui lui permet de récupérer en urgence le fichier dans le dossier tmp/cvtupload ;

À l'intérieur de config/fichiers/formidable, les fichiers sont stockés selon la structure suivante :

  • Si les réponses sont enregistrées en base de données, un dossier par formulaire, puis un dossier par réponse, puis un dossier par champ. Par exemple formulaire_1/reponse_2/fichiers_3.
  • Si les réponses ne sont pas enregistrées, mais simplement envoyées par courriel, nous utilisons un dossier timestamp : à l'intérieur de ce dossier est créé un dossier par réponse, dont le nom correspond au timestamp de la réponse. Au sein de chaque dossier de réponse, un dossier est créé par champs.

Ces fichiers sont effacés :

  • Lorsque la réponse est effacée de la base de données, quand Formidable efface les réponses « à la poubelle ».
  • Lorsque le formulaire est effacé de la base de données quand Formidable efface les formulaires en statut « à la poubelle ».
  • Pour les réponses qui ne sont pas stockées en base de données, lorsque les fichiers sont plus vieux que la constante _FORMIDABLE_EFFACEMENT_FICHIERS_EMAIL, qui par défaut est égale à la constante _FORMIDABLE_EXPIRATION_FICHIERS_EMAIL, qui est égale par défaut à 24*3600 secondes. Vous pouvez modifier cette constante en ajoutant dans votre fichier mes_options.php la ligne suivante :
    1. define ('_FORMIDABLE_EFFACEMENT_FICHIERS_EMAIL', <une_durée_exprimée_en_seconde>);

    Si la durée est mise à 0, les fichiers sont conservés ad vitam aeternam.
    Dans tous les cas, veillez à ce que la constante _FORMIDABLE_EFFACEMENT_FICHIERS_EMAIL soit au moins égale à _FORMIDABLE_EXPIRATION_FICHIERS_EMAIL.


[1] En général, dans ce cas, chaque champ correspond à un besoin différent.

[2] Voir l'article de la documentation de SPIP « Ajouter un type de document ».

[3] Nos tests en local nous ont montré qu'un fichier LaTeX, d'extension .tex, était détecté de type Mime application/octet-stream, ce qui n'est pas très utile comme information.

[4] Un kibioctet (kio) contient 1024 octets, un kilooctet (ko) contient 1000 octets… il est vrai que SPIP considère qu'un kilooctets correspond à 1024 octets. Voir l'article Wikipédia à ce sujet.

[5] Pour le moment, seul le plugin Formidable écrit dans config/fichiers, mais d'autres plugins pourraient le faire dans le futur.

La version 3.0.0 du plugin Formidable permet de créer des formulaires comprenant des envois de fichiers. Cet article regroupe la documentation relative à cette fonctionnalité. Pour une présentation générale de Formidable, voir «[->3284]».
{{{Configuration requise}}} Afin de pouvoir accéder à la fonction d'envoi de fichiers il vous faut: -* Le plugin [CVTupload->http://plugins.spip.net/cvtupload.html] dans sa version 1.9.4 au minimum. Attention, il reste possible d'activer Formidable sans avoir ce plugin. Simplement, il sera alors impossible d'envoyer des fichiers avec Formidable. -* Le plugin Formidable en version 3.0.0, lequel nécessite notamment: -** le plugin [Saisies->3364] en version 2.17.0 au minimum; -** le plugin [Vérifier->3852] en version 1.4.1 au minimum. {{{Configuration des fichiers à envoyer}}} Lors de la création d'un formulaire, il est possible de choisir un champ de type «Fichier(s)». Ce type de champ possède un certain nombre de propriétés configurables. Certaines, telles le titre, sont communes à l'ensemble des champs proposés par Formidable. Nous ne nous attarderons pas dessus, et n'exposerons que les propriétés spécifiques au type de champ «Fichier(s)». {{Nombre de fichiers}} Dans la configuration du champ, l'onglet «Utilisation» permet de choisir le nombre de fichiers à envoyer pour ce champ. Par défaut, la valeur est 1. Notez qu'il s'agit du nombre de fichiers pour {ce champ}, mais qu'il est possible d'ajouter des champs supplémentaires pour d'autres fichiers, ce qui permet de distinguer les fichiers selon les besoins. Pour l'instant, chaque fichier est associé à un input unique, afin d'être compatible avec un maximum de navigateur. Dans le futur, des versions améliorées de la saisie pourront être disponibles pour améliorer l'ergonomie. Notez que si un·e internaute triche et modifie le HTML afin d'envoyer plus de fichiers, le système n'enregistrera pas plus de fichiers que configurés. Puisque chaque fichier est associé à un input unique, chaque input reçoit un label individuel. Il est cependant possible de désactiver ce label pour n'afficher que le label commun à l'ensemble des fichiers. {{{Validation}}} L'onglet « Validation » de la configuration du champ permet de régler les propriétés des fichiers envoyés. Cet onglet est assez long, car il permet de choisir finement les types de fichiers autorisés à l'envoi. {{Caractère obligatoire}} La première option dans cet onglet, est, comme pour tous les champs, le caractère obligatoire ou non de l'envoi de fichier. Notez que dans le cas d'un champ permettant d'envoyer plusieurs fichiers, on considère que l'obligation d'envoi est remplie à partir du moment où un fichier est envoyé. Si vous souhaitez imposer l'envoi de trois fichiers, il vous faut créer trois champs[[En général, dans ce cas, chaque champ correspond à un besoin différent.]]. {{Type Mime et extension}} Une première série de boutons radio permet de choisir types de fichiers sont autorisés: -* Autoriser tous les types et extensions {{cette option est très déconseillée}}; -* Autoriser tous les types Mime et extensions connues de SPIP dans sa table spip_types_documents[[Voir l'article de la documentation de SPIP «[Ajouter un type de document->http://www.spip.net/fr_article2002.html]».]]; -* Autoriser uniquement les les images web (gif, jpg, png) (.jpg, .png, .gif); -* Autoriser uniquement les types et extensions sélectionnés parmi les cases à cocher; utile par exemple pour n'autoriser que l'envoi de pdf. Les cases à cocher de choix de type n'apparaissent que si on choisit cette option. Notez les points suivants: -* Dans tous les cas, Formidable zippera automatiquement les fichiers d'un type et/ou d'une extension absente de la table spip_types_documents, afin notamment d'empêcher son exécution sur le serveur. -* Si vous choisissez l'option « Tous les types Mime et extension autorisés par SPIP » ou « Un type Mime associé à une extension précisée ci-dessous» la vérification se fera: -** la plupart du temps, sur la base du type Mime détecté par PHP et de l'extension du fichier -** lorsque PHP détecte un type Mime text/plain ou application/octet-stream, qui sont très génériques, sur la seule base de l'extension[[Nos tests en local nous ont montré qu'un fichier LaTeX, d'extension .tex, était détecté de type Mime application/octet-stream, ce qui n'est pas très utile comme information.]]. {{Taille du fichier}} La taille du fichier est, {de facto}, limitée par la configuration de votre serveur. Souvent par défaut, 32~kio[[Un kibioctet (kio) contient 1024~octets, un kilooctet (ko) contient 1000~octets… il est vrai que SPIP considère qu'un kilooctets correspond à 1024~octets. Voir l'article [Wikipédia à ce sujet->https://fr.wikipedia.org/wiki/Pr%C3%A9fixe_binaire].]]. L'ami [Marcimat->aut6502] travaille actuellement sur un projet «BigUp» qui permet d'envoyer des fichiers plus gros. Si cela est nécessaire pour vos besoins, le contacter. En dehors même des limites techniques, il peut être utile de limiter pour des raisons éditoriales la taille des fichiers envoyés. Pour cela, il vous suffit de remplir le champ «taille» en indiquant une taille maximale en kio. Notez ces deux points: -* la vérification de la taille a lieu {après} l'envoi du fichier sur le serveur -* la vérification de la taille se comprend fichier par fichier, et non pour l'ensemble des fichiers d'un même champ. {{Dimension de l'image}} Une dernière série de réglages permet de vérifier la dimension des images envoyées. Notez qu'il faut dans ce cas s'assurer que le document envoyé est bien une image en choisissant la bonne option auparavant. De plus, la fonction utilisée pour déterminer la taille de l'image est [getimagesize()->https://secure.php.net/manual/fr/function.getimagesize.php], qui ne comprend pas tous les types d'images. Il est possible de préciser une largeur maximum (en pixels) et une hauteur maximum (en pixels). Une option permet également d'autoriser les images qui rentrent dans ces dimensions lorsqu'on les tourne de 90°. {{{Configuration des traitements}}} Comme pour tous les formulaires Formidable, un formulaire proposant l'envoi de fichier peut enregistrer les réponses et/ou les envoyer par courriel. Il n'y a rien de particulier à faire dans le cas qui nous occupe. Cependant, notez ces deux points: -* Au moment de l'enregistrement des traitements, Formidable vérifie s'il est possible d'enregistrer les fichiers à un endroit inaccessible par http. En cas de problème, un message est affiché, et dans ce cas l'envoi des fichiers ne pourra avoir lieu tant que le problème ne sera pas résolu. Voir plus bas, le paragraphe sur «[Où les fichiers sont-ils stockés?->#stockage]». -* Il est conseillé de choisir l'enregistrement des réponses, et de ne pas se contenter de l'envoi par email. En effet, les fichiers ne sont pas joints dans le courriel, pour éviter des problèmes en cas de fichiers lourds, mais un lien y est inséré. Or, ce lien expire 24h après l'envoi du formulaire. Si vous choisissez cependant de ne pas enregistrer les réponses, il est possible d'augmenter ce délai en mettant la ligne suivant dans votre fichier [mes_options.php->http://www.spip.net/fr_article4654.html]: define ('_FORMIDABLE_EXPIRATION_FICHIERS_EMAIL', ); Si la durée est mise sur 0, le lien est valable {ad vitam aeternam}. {{{Utiliser le formulaire en tant que visiteur⋅euse}}} Une fois le formulaire publié sur le site public, le·la visiteur⋅euse peut le remplir et choisir les fichiers à envoyer. Si ielle envoie une réponse avec des erreurs dans un champ, les fichiers déjà envoyés sont conservés, et il n'a pas besoin de les renvoyer. Ielle peut cependant décider, le cas échéant, de supprimer des fichiers déjà envoyés. Si vous autorisez un·e visiteur·euse à modifier une réponse envoyée, le formulaire de modification de réponse lui propose automatiquement les fichiers qu'ielle a auparavant envoyés, avec la possibilité de supprimer – et donc de remplacer – des fichiers. Notez que, comme pour les autres champs, il n'est fait aucune sauvegarde des anciennes valeurs. {{{Récupérer les fichiers envoyés}}} Les fichiers envoyés sont stockés dans un endroit normalement inaccessible au public. Dans la présentation des réponses, que ce soit dans l'espace privé de SPIP ou par courriel, un lien est inséré. Ce lien est sécurisé de telle sorte que seules les personnes ayant le droit de voir les réponses ou ayant reçue le courriel puissent télécharger le fichier. Notez que quelques changements sont effectués dans le nom des fichiers envoyés: -* passage en minuscule; -* suppression des accents; -* remplacement des espaces par des tirets-bas; -* suppression des points initiaux si le nom du fichier commence par un point; -* ajout éventuel de suffixe pour distinguer les fichiers homonymes; -* mise en zip du fichier s'il n'est pas d'un type ou d'une extension listée dans la table spip_types_documents Dans l'accusé de réception, ces liens sont également insérés. Cependant, il est possible désactiver cela en mettant la ligne suivante dans le fichier mes_options.php: define('_FORMIDABLE_LIENS_FICHIERS_ACCUSE_RECEPTION', false); {{{[stockage<-]Où les fichiers sont-ils stockés?}}} Cette partie de la documentation intéresse surtout les webmestres et non les administrateur·trice·s. Dans tous les cas, les fichiers sont enregistrés dans le dossier config/fichiers/formidable, qui est automatiquement créé. Il vous faut donc transférer le dossier config/fichiers[[Pour le moment, seul le plugin Formidable écrit dans config/fichiers, mais d'autres plugins pourraient le faire dans le futur.]] lorsque vous migrez un site d'un serveur à un autre, et si possible sauvegarder régulièrement ce dossier. Normalement SPIP s'assure que le dossier config n'est pas accessible en lecture à l'extérieur. Par précaution, Formidable s'assure également de cela à chaque envoi du fichier. Si ce critère n'est pas rempli, ou s'il est impossible d'écrire dans config/fichiers/formidable: -* un message de log est enregistré dans formidable.log; -* le fichier n'est pas déplacé dans config/fichiers; -* un courriel est envoyé au webmestre, ce qui lui permet de récupérer en urgence le fichier dans le dossier tmp/cvtupload; À l'intérieur de config/fichiers/formidable, les fichiers sont stockés selon la structure suivante: -* Si les réponses sont enregistrées en base de données, un dossier par formulaire, puis un dossier par réponse, puis un dossier par champ. Par exemple formulaire_1/reponse_2/fichiers_3. -* Si les réponses ne sont pas enregistrées, mais simplement envoyées par courriel, nous utilisons un dossier timestamp : à l'intérieur de ce dossier est créé un dossier par réponse, dont le nom correspond au [?timestamp] de la réponse. Au sein de chaque dossier de réponse, un dossier est créé par champs. Ces fichiers sont effacés: -* Lorsque la réponse est effacée de la base de données, quand Formidable efface les réponses «à la poubelle». -* Lorsque le formulaire est effacé de la base de données quand Formidable efface les formulaires en statut «à la poubelle». -* Pour les réponses qui ne sont pas stockées en base de données, lorsque les fichiers sont plus vieux que la constante _FORMIDABLE_EFFACEMENT_FICHIERS_EMAIL, qui par défaut est égale à la constante _FORMIDABLE_EXPIRATION_FICHIERS_EMAIL, qui est égale par défaut à 24*3600 secondes. Vous pouvez modifier cette constante en ajoutant dans votre fichier [mes_options.php->http://www.spip.net/fr_article4654.html] la ligne suivante: define ('_FORMIDABLE_EFFACEMENT_FICHIERS_EMAIL', ); Si la durée est mise à 0, les fichiers sont conservés {ad vitam aeternam}. Dans tous les cas, veillez à ce que la constante _FORMIDABLE_EFFACEMENT_FICHIERS_EMAIL soit au moins égale à _FORMIDABLE_EXPIRATION_FICHIERS_EMAIL.

{fusion}">Agenda : afficher les événements mois par mois avec {fusion}

https://contrib.spip.net/Exemple-programmationplay episode download
December 2016, by Thiébaut[ —]

Cette modeste contribution s'adresse aux utilisateurs/trices du plugin Agenda qui voudraient afficher leurs événements en les triant par année et par mois avec le critère {fusion}.

Certains événements, comme les expositions, s'inscrivent sur la durée : leur date de fin peut être très éloignée de leur date de début. S'ils ont déjà commencé, mais ne sont pas terminés, il est judicieux de les séparer des autres en créant une partie « en cours ».

Pour filtrer l'affichage des événements sur des intervalles de temps, plutôt que de multiplier les critères de sélection, on va associer deux techniques :

  • la sélection à l'aide de la paire de critères doublons/anti-doublons (voire la doc de SPIP et l'explication complémentaire sur Contrib) ;
  • le regroupement d'après la valeur d'un champ, avec le critère fusion.

Ce qu'on veut obtenir



L'objectif est donc d'extraire de façon automatique les événements [1], qu'ils soient dans l'intervalle du mois courant, ou à venir, en éliminant les dates échues.

A. Sélectionner tous les événements non finis

Une première boucle va servir de référence - un doublon nommé - pour « mémoriser » les événements publiés, commencés ou non, dont la date de fin est située dans le futur.

  1. span>(EVENEMENTS){age_fin<=0}{statut=publie}{doublons evtpasfini}/>

Cette boucle sert seulement à sélectionner des événements, pas à les afficher, elle peut donc être de type « auto-fermante » : il suffit de la balise d'ouverture, sa fin y est intégrée par le /> final.

Rappel au sujet de la technique doublons/antidoublons : {doublons} permet de mémoriser la sortie d'une boucle... que l'on récupère ensuite dans une autre boucle avec l'antidoublons, noté {!doublons}.

B. Récupérer et afficher la sélection

En premier, on veut afficher les événements en cours, qui ont déjà commencé mais ne sont pas terminés, comme les expositions :

  1. En cours

  2. span>(EVENEMENTS){!doublons evtpasfini}{age_debut>=1}{par date_fin}{doublons encours}>

Télécharger

En deuxième on veut le reste des événements triés par année et par mois. Ce mécanisme de regroupement nécessite deux boucles imbriquées avec le critère {fusion} spécifiant successivement les deux valeurs, année et mois :

  1. span>(EVENEMENTS){!doublons evtpasfini}{age_debut<=1}{par date_debut}{annee_relatif_debut}{lang_select=non}{fusion YEAR(date_debut)}{fusion MONTH(date_debut)}>
  2. [(#DATE_DEBUT|nom_mois|ucfirst) ][(#DATE_DEBUT|annee)]

  3. span>(EVENEMENTS){!doublons evtpasfini}{age_debut<=1}{par date_debut}{mois_relatif_debut}{doublons}>

Télécharger

Notez l'importance des critères {annee_relatif} et {mois_relatif} documentés ici... que l'on peut appliquer aux dates de début ou de fin utilisées par le plugin Agenda.

C. Afficher le tout sous la forme d'une liste à puce

Pour des raisons d'accessibilité, on veut afficher le tout sous la forme d'une seule liste à puce. Voici ce que cela donne :

  1. span>(EVENEMENTS){!doublons evtpasfini}>
  2. En cours

  • span>(EVENEMENTS){!doublons evtpasfini}{age_debut>=1}{par date_fin}{doublons encours}>
  • [(#LOGO_EVENEMENT)][(#TITRE)]

  • [(#DATE_DEBUT|Agenda_affdate_debut_fin{#DATE_FIN,#HORAIRE})]

  • [(#LIEU|sinon{#LESCOMMUNES})][
    (#ADRESSE|deparagrapher)]

  • span>(EVENEMENTS){!doublons evtpasfini}{age_debut<=1}{par date_debut}{annee_relatif_debut}{lang_select=non}{fusion YEAR(date_debut)}{fusion MONTH(date_debut)}>
  • [(#DATE_DEBUT|nom_mois|ucfirst) ][(#DATE_DEBUT|annee)]

    • span>(EVENEMENTS){!doublons evtpasfini}{age_debut<=1}{par date_debut}{mois_relatif_debut}{doublons}>
    • [(#LOGO_EVENEMENT)][(#TITRE)]

    • [(#DATE_DEBUT|Agenda_affdate_debut_fin{#DATE_FIN,#HORAIRE})]

    • [(#LIEU|sinon{#LESCOMMUNES})][
      (#ADRESSE|deparagrapher)]

    • Télécharger


      [1] Cette démarche est valable sur tous les objets datés de SPIP, sous réserve d'adapter les critères d'age et de date aux champs disponibles…

      Cette modeste contribution s'adresse aux utilisateurs/trices du [plugin Agenda->rub 184] qui voudraient afficher leurs événements en les triant par année et par mois avec le critère {fusion}.
      Certains événements, comme les expositions, s'inscrivent sur la durée : leur date de fin peut être très éloignée de leur date de début. S'ils ont déjà commencé, mais ne sont pas terminés, il est judicieux de les séparer des autres en créant une partie en cours. Pour filtrer l'affichage des événements sur des intervalles de temps, plutôt que de multiplier les critères de sélection, on va associer deux techniques : -* la sélection à l'aide de la paire de critères {{doublons/anti-doublons}} (voire la [doc de SPIP->http://spip.net/4139] et l'explication complémentaire sur [Contrib->http/contrib.spip.net/2482]) ; -* le regroupement d'après la valeur d'un champ, avec le critère [{{fusion}}->http://www.spip.net/fr_article5166.html]. {{{Ce qu'on veut obtenir}}} L'objectif est donc d'extraire de façon automatique les événements[[Cette démarche est valable sur tous les objets datés de SPIP, sous réserve d'adapter [les critères d'age->4452] et de date aux champs disponibles…]], qu'ils soient dans l'intervalle du mois courant, ou à venir, en éliminant les dates échues. {{{A. Sélectionner tous les événements non finis}}} Une première boucle va servir de référence - un doublon nommé - pour mémoriser les événements publiés, commencés ou non, dont la date de fin est située dans le futur. Cette boucle sert seulement à sélectionner des événements, pas à les afficher, elle peut donc être de type auto-fermante : il suffit de la balise d'ouverture, sa fin y est intégrée par le {{/>}} final. {{Rappel au sujet de la technique doublons/antidoublons}} : {doublons} permet de mémoriser la sortie d'une boucle... que l'on récupère ensuite dans une autre boucle avec l'antidoublons, noté {!doublons}. {{{B. Récupérer et afficher la sélection}}} {{En premier, on veut afficher les événements en cours}}, qui ont déjà commencé mais ne sont pas terminés, comme les expositions :

      En cours

      =1}{par date_fin}{doublons encours}>
      {{En deuxième on veut le reste des événements triés par année et par mois. }} Ce mécanisme de regroupement nécessite deux boucles imbriquées avec le critère {fusion} spécifiant successivement les deux valeurs, année et mois :

      [(#DATE_DEBUT|nom_mois|ucfirst) ][(#DATE_DEBUT|annee)]

      Notez l'importance des critères {annee_relatif} et {mois_relatif} [documentés ici->http://www.spip.net/fr_article1971.html]... que l'on peut appliquer aux dates de début ou de fin utilisées par le plugin Agenda. {{{C. Afficher le tout sous la forme d'une liste à puce}}} Pour des raisons d'accessibilité, on veut afficher le tout sous la forme d'une seule liste à puce. Voici ce que cela donne :
      • En cours

          =1}{par date_fin}{doublons encours}>
        • [(#LOGO_EVENEMENT)][(#TITRE)]

          [(#DATE_DEBUT|Agenda_affdate_debut_fin{#DATE_FIN,#HORAIRE})]

          [(#LIEU|sinon{#LESCOMMUNES})][
          (#ADRESSE|deparagrapher)]

      • [(#DATE_DEBUT|nom_mois|ucfirst) ][(#DATE_DEBUT|annee)]


      Mutualisation SPIP sur Gandi Simple Hosting

      December 2016, by Sébastien[ —]

      La mutualisation du noyau de SPIP présente des avantages pour les opérations de maintenance (du noyau comme des plugins) ainsi que pour l'économie des ressources du serveur mais encore faut-il pouvoir l'installer ! On croit parfois que cette possibilité est réservée aux propriétaires d'un serveur dédié qui peuvent modifier la configuration de celui-ci. Les lignes qui suivent présentent la mise en place d'une mutualisation sur une plateforme grand public.

      Avertissement

      Ce tutoriel n'a pas vocation à inciter les utilisateurs de SPIP à migrer leurs sites vers Gandi Simple Hosting (il ne s'agit pas de publicité). Il présente simplement une méthode de mutualisation du noyau SPIP sur cette plateforme pour les personnes ayant ce besoin.
      Ce tutoriel s'appuie principalement sur le plugin mutualisation et sa documentation provisoire.

      Pré-requis et cahier des charges

      On suppose que le lecteur de ces lignes dispose d'une instance de type « Gandi Simple Hosting ».
      Pour information, l'instance qui a servi de modèle pour ce tutoriel est de taille L, basée à Paris avec PHP 5.6 et MySQL 5.6 (Percona).
      Tous les sites considérés ci-après utilisent SPIP (version 3.1).

      Afin qu'un maximum de personnes puissent tirer parti de ce tutoriel, on essaiera de détailler les procédures suivantes :

      1. Mise en place de la mutualisation. On explique comment préparer la mutualisation sur un site « maître ».
      2. Mutualisation d'un autre site situé sur la même instance. On présente les modifications nécessaires permettant d'ajouter (à la mutualisation) un site indépendant situé sur la même instance.
      3. Mutualisation d'un site développé en local. On propose une procédure pas à pas pour ajouter à la mutualisation un site développé en local.

      Mise en place de la mutualisation

      On dispose d'un site (à l'adresse www.domaine1.tld) hébergé sur une instance Simple Hosting et on souhaite qu'il soit utilisé pour stocker la mutualisation.
      Cela signifie que ce site va héberger le moteur de la mutualisation ainsi que tous les fichiers de tous les sites mutualisés. On peut toutefois noter que cela ne sera pas visible par le visiteur et que ce site fonctionnera comme tous les autres sites mutualisés avec sa propre base de données, ses propres plugins et tous ses fichiers de personnalisation (répertoires « tmp », « IMG », « local », « config », « squelettes »).

      Configuration du plugin Mutualisation

      On télécharge le plugin « Mutualisation » compatible avec SPIP 3.1, on dézippe le répertoire puis on le renomme éventuellement « mutualisation » (au moment de l'écriture de cet article, le répertoire s'appelle « mutualisation_v1 », ce qui pose un problème lors de l'appel mutualisation/mutualiser.php du futur fichier « mes_options.php » livré avec le plugin).

      Dans le répertoire « mutualisation », on trouve un fichier « mes_options.php.txt » qu'on copie en dehors du répertoire puis renomme « mes_options.php ».
      On réalise alors les modifications suivantes :

        1. define ('_SITES_ADMIN_MUTUALISATION', 'domaine1.tld');
        1. /* placer dans ce tableau les sites ou l'on ne veut pas la redirection canonique */
        2. $www = array('domaine1.tld');

        Télécharger

      • Astuce de Matthieu Marcillaud permettant d'avoir le site www.domaine1.tld accessible : lien vers le forum. )
        En tête de fichier, juste après < ?php :
        1. $mutualisation = ($_SERVER['HTTP_HOST'] == 'domaine1.tld') ? false : true ;
        2. if ($mutualisation) {

        Télécharger

        Puis tout en fin de fichier, ou juste avant ?> si c'est présent :

        1. }

      Préparation des répertoires sur le serveur

      Attention : l'opération suivante va rendre l'adresse www.domaine1.tld temporairement inaccessible.

      On se connecte maintenant à l'instance par SFTP et on ouvre le répertoire vhosts/www.domaine1.tld/htdocs.
      On déplace les cinq répertoires « config », « tmp », « local », « IMG » et « squelettes » dans un répertoire temporaire (par exemple celui correspondant au vhost de test de forme c123456789.url-de-test.ws fourni avec l'instance) puis on recrée ces répertoires (vides) dans le répertoire htdocs. Ne pas oublier de modifier les droits de ces répertoires conformément aux directives de SPIP (chmod 777 pour « config », « tmp », « local » et « IMG »).

      Transfert du plugin Mutualisation puis redémarrage de l'instance

      On transfère :

      • le répertoire « mutualisation » dans le répertoire htdocs.
      • le fichier édité « mes_options.php » dans le répertoire « config » précédemment créé.

      On crée ensuite le dossier « sites » dans le répertoire htdocs.
      Enfin, on redémarre l'instance Simple Hosting (lien sur la page de l'instance) puis on se connecte à l'interface d'administration de l'instance et on vide le cache Varnish.

      PNG - 68.6 ko
      Redémarrer l'instance
      PNG - 12.4 ko
      Connection à l'interface d'administration
      PNG - 8.2 ko
      Nettoyage du cache Varnish

      Ré-installation du site

      On tape www.domaine1.tld dans le navigateur. Le formulaire d'activation de la mutualisation apparaît :

      PNG - 94.7 ko
      Installation du site

      Le code d'activation demandé est ecureuil (modifiable dans le fichier « mes_options.php » ci-avant). On laisse le système créer les répertoires « config », « tmp », « local » et « IMG » dans vhosts/www.domaine1.tld/htdocs/sites/domaine1.tld/ mais on ne poursuit pas l'installation de SPIP (les fichiers de connexion existent déjà).

      On déplace les contenus des répertoires « config », « tmp », « local », « IMG » et « squelettes » du répertoire de test vers les contenus des répertoires « config », « tmp », « local », « IMG » et « squelettes » (à créer à la main) du répertoire vhosts/www.domaine1.tld/htdocs/sites/domaine1.tld/.

      On réactualise la page www.domaine1.tld dans son navigateur et on se connecte à l'espace privé. On vide le cache et on se rend sur la page d'administration des plugins (et on les réactive le cas échéant).

      Le site est fonctionnel et la base de mutualisation est établie.

      Mutualisation d'un autre site situé sur la même instance

      On dispose d'un autre site (à l'adresse www.domaine2.tld) hébergé sur la même instance Simple Hosting et on souhaite lui faire bénéficier de la mutualisation.

      Redirection vers le site de mutualisation

      Attention : l'opération suivante va temporairement rendre l'adresse www.domaine2.tld inaccessible.

      On se rend sur l'interface d'administration de son instance et on clique sur « multi-address management » puis on relie www.domaine2.tld à www.domaine1.tld.

      PNG - 8.5 ko
      Multi-adress management - figure 1
      PNG - 27 ko
      Multi-adress management - figure 2

      Les fichiers et répertoires du site sont temporairement stockés dans le répertoire vhosts/www.domaine2.tld/htdocs_old. On en aura besoin plus tard.

      Configuration de la mutualisation et installation du site

      On récupère le fichier « mes_options.php » situé dans le répertoire vhosts/www.domaine1.tld/htdocs/config/ puis on effectue la modification suivante :

      1. /* placer dans ce tableau les sites ou l'on ne veut pas la redirection canonique */
      2. $www = array('domaine1.tld','domaine2.tld');

      Télécharger

      On transfère ensuite ce fichier modifié à son emplacement d'origine puis on tape www.domaine2.tld dans le navigateur.
      Le formulaire d'activation de la mutualisation apparaît et on reprend la procédure de la partie précédente (Ré-installation du site) en déplaçant les contenus des répertoires « config », « tmp », « local », « IMG » et « squelettes » de vhosts/www.domaine2.tld/htdocs_old/ vers vhosts/www.domaine1.tld/htdocs/sites/domaine2.tld/. (On pensera également à déplacer les plugins vers vhosts/www.domaine1.tld/htdocs/plugins/).

      On réactualise la page www.domaine2.tld dans le navigateur et on se connecte à l'espace privé. On vide le cache et on se rend sur la page d'administration des plugins (et on les réactive le cas échéant).

      On efface enfin les fichiers restants contenus dans vhosts/www.domaine2.tld/htdocs_old afin d'économiser de l'espace disque.

      Le deuxième site est mutualisé.

      Mutualisation d'un site développé en local

      On dispose d'un autre site développé en local qu'on souhaite lier à l'adresse domaine3.tld et joindre à la mutualisation.

      Redirection permanente

      Tout d'abord, on décide de faire pointer domaine3.tld vers www.domaine3.tld à l'aide d'une redirection permanente. Pour cela, on se rend sur la page de gestion de son nom de domaine et on crée la redirection.

      PNG - 38.6 ko
      Redirection web - figure 1
      PNG - 23.3 ko
      Redirection web - figure 2

      Modification du fichier de zone

      Toujours sur la page de gestion du nom de domaine, on change le fichier de zone pour que domaine3.tld pointe vers l'instance Simple Hosting.

      PNG - 11.1 ko
      Fichier de zone

      Création du vhost

      On ajoute alors le vhost www.domaine3.tld à l'instance Simple Hosting via la page de l'instance en décochant la modification automatique des DNS.

      PNG - 90.6 ko
      Nouvelle adresse

      Redirection vers le site de mutualisation

      On se rend sur l'interface d'administration de l'instance et via le « multi-address management », on relie www.domaine3.tld à www.domaine1.tld comme illustré précédemment (Redirection vers le site de mutualisation).

      Base de donnée

      On crée la base de données depuis l'interface d'administration de l'instance.

      PNG - 13.4 ko
      Accès à la base de données
      PNG - 11.9 ko
      Encodage de la base

      On exporte ensuite la base de données locale puis on l'importe via PhpMyadmin depuis l'onglet SQL de sa base de données.

      Configuration de la mutualisation et installation du site

      On récupère le fichier « mes_options.php » situé dans le répertoire vhosts/www.domaine1.tld/htdocs/config/ puis on effectue la modification suivante :

      1. /* placer dans ce tableau les sites ou l'on ne veut pas la redirection canonique */
      2. $www = array('domaine1.tld','domaine2.tld','domaine3.tld');

      Télécharger

      En attendant la propagation DNS liée à la modification du fichier de zone, on transfère les plugins nécessaires vers www.domaine1.tld/htdocs/plugins/.
      On transfère également les répertoires « config », « tmp », « local », « IMG » et « squelettes » vers le vhost de test (Préparation des répertoires sur le serveur). Attention à modifier préalablement le fichier « connect.php » du répertoire « config » afin que la connexion à la base de données puisse se faire convenablement.

      Au bout d'un certain temps (entre quelques minutes et quelques heures), la propagation DNS est terminée et l'adresse www.domaine3.tld tapée dans le navigateur renvoie bien le formulaire d'activation de la mutualisation. On reprend la procédure indiquée Ré-installation du site (sans oublier de déplacer les plugins vers vhosts/www.domaine1.tld/htdocs/plugins/).

      Une fois connecté à l'espace privé, on n'oublie pas de :

      • changer l'URL du site public (dans l'onglet « configuration » puis « identité du site ») qui est certainement une URL liée à l'installation locale.
      • vider le cache.
      • se rendre sur la page de gestion des plugins pour les activer (éventuellement) et recréer le cache des pipelines.

      Le troisième site est mutualisé.

      La mutualisation du noyau de SPIP présente des avantages pour les opérations de maintenance (du noyau comme des plugins) ainsi que pour l'économie des ressources du serveur mais encore faut-il pouvoir l'installer ! On croit parfois que cette possibilité est réservée aux propriétaires d'un serveur dédié qui peuvent modifier la configuration de celui-ci. Les lignes qui suivent présentent la mise en place d'une mutualisation sur une plateforme grand public.
      {{Avertissement }} Ce tutoriel n'a pas vocation à inciter les utilisateurs de SPIP à migrer leurs sites vers Gandi Simple Hosting (il ne s'agit pas de publicité). Il présente simplement une méthode de mutualisation du noyau SPIP sur cette plateforme pour les personnes ayant ce besoin. Ce tutoriel s'appuie principalement sur le [plugin mutualisation->rub1022] et sa [documentation provisoire->2192]. {{Pré-requis et cahier des charges}} On suppose que le lecteur de ces lignes dispose d'une instance de type Gandi Simple Hosting. Pour information, l'instance qui a servi de modèle pour ce tutoriel est de taille L, basée à Paris avec PHP 5.6 et MySQL 5.6 (Percona). Tous les sites considérés ci-après utilisent SPIP (version 3.1). Afin qu'un maximum de personnes puissent tirer parti de ce tutoriel, on essaiera de détailler les procédures suivantes : -# [Mise en place de la mutualisation.->#MiseEnPlace] On explique comment préparer la mutualisation sur un site maître. -# [Mutualisation d'un autre site situé sur la même instance.->#MemeInstance] On présente les modifications nécessaires permettant d'ajouter (à la mutualisation) un site indépendant situé sur la même instance. -# [Mutualisation d'un site développé en local.->#Local] On propose une procédure pas à pas pour ajouter à la mutualisation un site développé en local. [#MiseEnPlace<-]{{{Mise en place de la mutualisation}}} On dispose d'un site (à l'adresse www.domaine1.tld) hébergé sur une instance Simple Hosting et on souhaite qu'il soit utilisé pour stocker la mutualisation. Cela signifie que ce site va héberger le moteur de la mutualisation ainsi que tous les fichiers de tous les sites mutualisés. On peut toutefois noter que cela ne sera pas visible par le visiteur et que ce site fonctionnera comme tous les autres sites mutualisés avec sa propre base de données, ses propres plugins et tous ses fichiers de personnalisation (répertoires tmp, IMG, local, config, squelettes). {{Configuration du plugin Mutualisation}} On [télécharge le plugin Mutualisation->doc13734] compatible avec SPIP 3.1, on dézippe le répertoire puis on le renomme éventuellement mutualisation ({au moment de l'écriture de cet article, le répertoire s'appelle mutualisation_v1, ce qui pose un problème lors de l'appel mutualisation/mutualiser.php du futur fichier mes_options.php livré avec le plugin}). Dans le répertoire mutualisation, on trouve un fichier mes_options.php.txt qu'on copie en dehors du répertoire puis renomme mes_options.php. On réalise alors les modifications suivantes : -* define ('_SITES_ADMIN_MUTUALISATION', 'domaine1.tld'); -* /* placer dans ce tableau les sites ou l'on ne veut pas la redirection canonique */ $www = array('domaine1.tld'); -* Astuce de Matthieu Marcillaud permettant d'avoir le site www.domaine1.tld accessible : [lien vers le forum->http://contrib.spip.net/Ferme-a-SPIP?lang=fr&debut_comments-list=@432155#forum432155]. ) En tête de fichier, juste après < ?php : $mutualisation = ($_SERVER['HTTP_HOST'] == 'domaine1.tld') ? false : true ; if ($mutualisation) { Puis tout en fin de fichier, ou juste avant ?> si c'est présent : } [#preparation<-]{{Préparation des répertoires sur le serveur}} {Attention : l'opération suivante va rendre l'adresse www.domaine1.tld temporairement inaccessible.} On se connecte maintenant à l'instance par SFTP et on ouvre le répertoire vhosts/www.domaine1.tld/htdocs. On déplace les cinq répertoires config, tmp, local, IMG et squelettes dans un répertoire temporaire (par exemple celui correspondant au vhost de test de forme c123456789.url-de-test.ws fourni avec l'instance) puis on recrée ces répertoires (vides) dans le répertoire htdocs. Ne pas oublier de modifier les droits de ces répertoires conformément aux directives de SPIP (chmod 777 pour config, tmp, local et IMG). {{Transfert du plugin Mutualisation puis redémarrage de l'instance}} On transfère : -* le répertoire mutualisation dans le répertoire htdocs. -* le fichier édité mes_options.php dans le répertoire config précédemment créé. On crée ensuite le dossier sites dans le répertoire htdocs. Enfin, on redémarre l'instance Simple Hosting (lien sur la page de l'instance) puis on se connecte à l'interface d'administration de l'instance et on vide le cache Varnish. |||| [#installation<-]{{Ré-installation du site}} On tape www.domaine1.tld dans le navigateur. Le formulaire d'activation de la mutualisation apparaît : || Le code d'activation demandé est ecureuil (modifiable dans le fichier mes_options.php ci-avant). On laisse le système créer les répertoires config, tmp, local et IMG dans vhosts/www.domaine1.tld/htdocs/sites/domaine1.tld/ mais on ne poursuit pas l'installation de SPIP (les fichiers de connexion existent déjà). On déplace les contenus des répertoires config, tmp, local, IMG et squelettes du répertoire de test vers les contenus des répertoires config, tmp, local, IMG et squelettes (à créer à la main) du répertoire vhosts/www.domaine1.tld/htdocs/sites/domaine1.tld/. On réactualise la page www.domaine1.tld dans son navigateur et on se connecte à l'espace privé. On vide le cache et on se rend sur la page d'administration des plugins (et on les réactive le cas échéant). Le site est fonctionnel et la base de mutualisation est établie. [#MemeInstance<-]{{{Mutualisation d'un autre site situé sur la même instance}}} On dispose d'un autre site (à l'adresse www.domaine2.tld) hébergé sur la même instance Simple Hosting et on souhaite lui faire bénéficier de la mutualisation. [#multiadress<-]{{Redirection vers le site de mutualisation}} {Attention : l'opération suivante va temporairement rendre l'adresse www.domaine2.tld inaccessible.} On se rend sur l'interface d'administration de son instance et on clique sur multi-address management puis on relie www.domaine2.tld à www.domaine1.tld. ||| Les fichiers et répertoires du site sont temporairement stockés dans le répertoire vhosts/www.domaine2.tld/htdocs_old. On en aura besoin plus tard. {{Configuration de la mutualisation et installation du site}} On récupère le fichier mes_options.php situé dans le répertoire vhosts/www.domaine1.tld/htdocs/config/ puis on effectue la modification suivante : /* placer dans ce tableau les sites ou l'on ne veut pas la redirection canonique */ $www = array('domaine1.tld','domaine2.tld'); On transfère ensuite ce fichier modifié à son emplacement d'origine puis on tape www.domaine2.tld dans le navigateur. Le formulaire d'activation de la mutualisation apparaît et on reprend la procédure de la partie précédente ([Ré-installation du site->#installation]) en déplaçant les contenus des répertoires config, tmp, local, IMG et squelettes de vhosts/www.domaine2.tld/htdocs_old/ vers vhosts/www.domaine1.tld/htdocs/sites/domaine2.tld/. (On pensera également à déplacer les plugins vers vhosts/www.domaine1.tld/htdocs/plugins/). On réactualise la page www.domaine2.tld dans le navigateur et on se connecte à l'espace privé. On vide le cache et on se rend sur la page d'administration des plugins (et on les réactive le cas échéant). On efface enfin les fichiers restants contenus dans vhosts/www.domaine2.tld/htdocs_old afin d'économiser de l'espace disque. Le deuxième site est mutualisé. [#Local<-]{{{Mutualisation d'un site développé en local}}} On dispose d'un autre site développé en local qu'on souhaite lier à l'adresse domaine3.tld et joindre à la mutualisation. {{Redirection permanente}} Tout d'abord, on décide de faire pointer domaine3.tld vers www.domaine3.tld à l'aide d'une redirection permanente. Pour cela, on se rend sur la page de gestion de son nom de domaine et on crée la redirection. ||| {{Modification du fichier de zone}} Toujours sur la page de gestion du nom de domaine, on change le fichier de zone pour que domaine3.tld pointe vers l'instance Simple Hosting. || {{Création du vhost}} On ajoute alors le vhost www.domaine3.tld à l'instance Simple Hosting via la page de l'instance en décochant la modification automatique des DNS. || {{Redirection vers le site de mutualisation}} On se rend sur l'interface d'administration de l'instance et via le multi-address management, on relie www.domaine3.tld à www.domaine1.tld comme illustré précédemment ([Redirection vers le site de mutualisation->#multiadress]). {{Base de donnée}} On crée la base de données depuis l'interface d'administration de l'instance. ||| On exporte ensuite la base de données locale puis on l'importe via PhpMyadmin depuis l'onglet SQL de sa base de données. {{Configuration de la mutualisation et installation du site}} On récupère le fichier mes_options.php situé dans le répertoire vhosts/www.domaine1.tld/htdocs/config/ puis on effectue la modification suivante : /* placer dans ce tableau les sites ou l'on ne veut pas la redirection canonique */ $www = array('domaine1.tld','domaine2.tld','domaine3.tld'); En attendant la propagation DNS liée à la modification du fichier de zone, on transfère les plugins nécessaires vers www.domaine1.tld/htdocs/plugins/. On transfère également les répertoires config, tmp, local, IMG et squelettes vers le vhost de test ([Préparation des répertoires sur le serveur->#preparation]). Attention à modifier préalablement le fichier connect.php du répertoire config afin que la connexion à la base de données puisse se faire convenablement. Au bout d'un certain temps (entre quelques minutes et quelques heures), la propagation DNS est terminée et l'adresse www.domaine3.tld tapée dans le navigateur renvoie bien le formulaire d'activation de la mutualisation. On reprend la procédure indiquée [Ré-installation du site->#installation] (sans oublier de déplacer les plugins vers vhosts/www.domaine1.tld/htdocs/plugins/). Une fois connecté à l'espace privé, on n'oublie pas de : -* changer l'URL du site public (dans l'onglet configuration puis identité du site) qui est certainement une URL liée à l'installation locale. -* vider le cache. -* se rendre sur la page de gestion des plugins pour les activer (éventuellement) et recréer le cache des pipelines. Le troisième site est mutualisé.

      {compteur} de Bonux">Le critère {compteur} de Bonux

      December 2016, by JLuc[ —]

      Le critère compteur fait une jointure de la table courante avec une autre table et permet de compter.

      Le critère compteur est utilisé avec au minimum un argument, parfois 2.

      1er argument : une table

      Le premier argument du critère compteur est le nom de table sur lequel doit se faire la jointure dont on veut compter les occurences.

      - Exemple : lister les articles ayant au moins un document et afficher le nombre de documents qui leur est associé :

      1. span>(ARTICLES) {
        }
        {compteur documents}
        >
      2. ARTICLE #ID_ARTICLE
      3. [Il y a (#COMPTEUR{documents}) documents]

      Télécharger

      - Exemple : compter les mots de chaque article

        • span>(ARTICLES){compteur mots}>
        • #TITRE a #COMPTEUR{mots}
      1. Télécharger

        - Inversement on peut compter les articles associés à chaque mot :

          • span>(MOTS){compteur articles}>
          • Le mot '#TITRE' est appliqué à #COMPTEUR{articles} articles
        1. Télécharger

          - Autre exemple, inspiré du plugin 'bilancontributions', pour lister toutes les extensions des documents (ce n'est pas la seule manière de faire) :

            • span>(TYPES_DOCUMENTS documents){compteur documents}{! par compteur_documents}{statut=publie}{0,10}>
            • #EXTENSION
          1. Télécharger

            Tri

            Le critère compteur peut être associé au critère tri en utilisant un argument composé de 'compteur' suivi du nom de la table.

            - Exemple :

              • span>(AUTEURS){compteur articles}{tri compteur_articles,inverse}>
              • #NOM a écrit #COMPTEUR{articles} articles publiés
            1. Télécharger

              Jointures

              Pour son fonctionnement propre, le critère compteur crée une jointure avec la table reçue en argument. On peut également utiliser le critère compteur avec une table déjà requise explicitement par la boucle dans une jointure.

              - Par exemple pour le site trad.spip.net, on trouve une boucle :

              1. span>(AUTEURS spip_versions){compteur versions}{!par compteur_versions}{'
                '}
                >
              2. * #URL_AUTEUR class=spip_in>#NOM : #COMPTEUR{versions} révisions

              Télécharger

              2e argument : un champ

              Lorsqu'il n'y a qu'un argument, la jointure se fait sur la clé primaire de la table indiquée.
              Il est toutefois possible de passer un 2ème argument au critère compteur. Dans ce cas, ce 2ème argument est un champ de la table passée en premier argument.

              - Exemple : voici une version simplifiée d'une boucle présente dans le plugin mediatheque. Cette boucle liste les types de media (image, audio, video, file) et indique le nombre de document correspondant à chacun de ces types :

                • span>(DOCUMENTS){compteur types_documents, media}{media IN image,audio,video,file}>
                • #MEDIA ( #COMPTEUR{types_documents} )
              1. Télécharger

                Le critère compteur fait une jointure de la table courante avec une autre table et permet de compter.
                Le critère compteur est utilisé avec au minimum un argument, parfois 2. {{{1er argument : une table}}} Le premier argument du critère compteur est le nom de table sur lequel doit se faire la jointure dont on veut compter les occurences. - Exemple : lister les articles ayant au moins un document et afficher le nombre de documents qui leur est associé : } {compteur documents}> ARTICLE #ID_ARTICLE
                [Il y a (#COMPTEUR{documents}) documents]
                - Exemple : compter les mots de chaque article
                • #TITRE a #COMPTEUR{mots}
                - Inversement on peut compter les articles associés à chaque mot :
                • Le mot '#TITRE' est appliqué à #COMPTEUR{articles} articles
                - Autre exemple, inspiré du plugin 'bilancontributions', pour lister toutes les extensions des documents (ce n'est pas la seule manière de faire) :
                • #EXTENSION
                {{Tri}} Le critère compteur peut être associé au critère tri en utilisant un argument composé de 'compteur' suivi du nom de la table. - Exemple :
                • #NOM a écrit #COMPTEUR{articles} articles publiés
                {{Jointures}} Pour son fonctionnement propre, le critère compteur crée une jointure avec la table reçue en argument. On peut également utiliser le critère compteur avec une table déjà requise explicitement par la boucle dans une jointure. - Par exemple pour le site trad.spip.net, on trouve une boucle : '}> * #NOM : #COMPTEUR{versions} révisions {{{2eme argument : un champ}}} Lorsqu'il n'y a qu'un argument, la jointure se fait sur la clé primaire de la table indiquée. Il est toutefois possible de passer un 2ème argument au critère compteur. Dans ce cas, ce 2ème argument est un champ de la table passée en premier argument. - Exemple : voici une version simplifiée d'une boucle présente dans le plugin mediatheque. Cette boucle liste les types de media (image, audio, video, file) et indique le nombre de document correspondant à chacun de ces types :
                • #MEDIA ( #COMPTEUR{types_documents} )

                Modèle exergue

                December 2016, by RealET[ —]

                Un plugin pour insérer simplement des exergues dans le texte : centrés, flottant à gauche ou à droite.

                Ce plugin est inspiré d'une discussion commencée sur SeenThis.

                Il permet d'insérer 3 formes d'exergues :

                • centré, seul dans un bloc occupant toute la largeur
                • flottant sur la gauche
                • flottant sur la droite

                Exemple du rendu dans l'espace d'administration :
                Exemples

                Syntaxe

                1. exergue : le nom du modèle
                2. texte : le texte à afficher dans l'exergue
                3. position : argument facultatif, si absent, le comportement par défaut est affichage centré, valeurs possibles : left, right

                Assistant Insérer Modèle

                Par ailleurs, avec le plugin Plugin Insérer Modèles, l'insertion d'un exergue se trouve grandement facilité :

                PNG - 9.6 ko
                Option du modèle Insérer Exergue
                Un plugin pour insérer simplement des exergues dans le texte : centrés, flottant à gauche ou à droite.
                Ce plugin est inspiré d'une [discussion commencée sur SeenThis->https://seenthis.net/messages/269016]. Il permet d'insérer 3 formes d'exergues : -* centré, seul dans un bloc occupant toute la largeur -* flottant sur la gauche -* flottant sur la droite Exemple du rendu dans l'espace d'administration : {{{Syntaxe}}} -# exergue : le nom du modèle -# texte : le texte à afficher dans l'exergue -# position : argument facultatif, si absent, le comportement par défaut est affichage centré, valeurs possibles : left, right {{{Assistant Insérer Modèle}}} Par ailleurs, avec le plugin [->3631], l'insertion d'un exergue se trouve grandement facilité :

                Menu privé alphabétique

                play episode
                download
                December 2016, by nicod_[ —]

                Ce plugin ne fait qu'une chose : trier les items du menu de l'espace privé (le bandeau principal) par ordre alphabétique.

                Également, si un menu compte plus de 20 items (ce qui donne un menu très long et impraticable), ils sont répartis sur deux colonnes.

                Le plugin ne fait que surcharger un squelette (/prive/squelettes/inclure/barre-nav.html) et son fichier fonctions.php

                Ce plugin ne fait qu'une chose : trier les items du menu de l'espace privé (le bandeau principal) par ordre alphabétique. Également, si un menu compte plus de 20 items (ce qui donne un menu très long et impraticable), ils sont répartis sur deux colonnes. Le plugin ne fait que surcharger un squelette (/prive/squelettes/inclure/barre-nav.html) et son fichier fonctions.php

                Métas +

                >https://www.facebook.com/translations/FacebookLocales.xml</a>, <a class=play episode download
                December 2016, by erational, tetue[ —]

                Améliorez l'indexation de vos articles dans les moteurs et leur affichage sur les réseaux sociaux grâce aux métadonnées Dublin Core, Open Graph et Twitter Card.

                Installation

                Activer le plugin dans le menu dédié.

                Dans le panel de configuration, vous pouvez choisir quelles méta-données, vous voulez activer ou non :

                • Dublin Core : sémantique
                • Opengraph : format adopté notamment par Facebook . Il permet d'améliorer les informations transmises lorsque vos utilisateurs partagent une page
                • Twitter Card

                Utilisation

                Dans la balise .... de votre squelette de la page article, ajouter le code suivant à l'intérieur de la boucle ARTICLES

                1. {fond=inclure/metasplus-article,id_article} />

                Utilisation avancée

                Il est possible d'étendre l'ajout des métas à d'autres objets SPIP (rubriques, lieux, cartes, patates, ....)

                Le plugin fournit un modèle général inclure/metasplus.html auquel il faut fournir les informations requises

                1. {fond=inclure/metasplus,
                2. titre=#GET{titre},
                3. lang=#GET{lang},
                4. territoire=#GET{territoire},
                5. desc=#GET{desc},
                6. auteur=#GET{author},
                7. date=#GET{date},
                8. url=#GET{url},
                9. logo=#GET{logo},
                10. og-type=article} />

                Télécharger

                Tous les paramètres sont facultatifs mais il est fortement indiqué de renseigner au minimum titre, desc, url.

                Il faut transmettre des chaînes brutes sans HTML. On pourra utiliser les filtres |supprimer_tags|textebrut pour nettoyer les balises SPIP.

                Nom du paramètreRemarques
                titre titre
                lang langue
                territoire Permet de créer le locale facebook en_UK. Si ce paramètre territoire n'est pas transmis, on tente une locale avec la langue fr_FR, de_DE
                Avec une exception pour l'anglais réglé par défaut sur en_US
                Pour documentation, voici la liste des locales acceptés par Facebook ;
                https://www.facebook.com/translations/FacebookLocales.xml
                desc texte court d'introduction
                auteur auteur sans lien
                date Date en format YYYY-MM-DD
                url URL de la ressource
                logo Les images doivent faire au minimum 200x200 pixels et peser moins de 1Mo.
                og-type Pour connaître les valeurs acceptées de og-type,
                on pourra consulter :
                https://developers.facebook.com/doc....
                Si on ne précise rien, la valeur par défaut est article.

                Par exemple pour un objet pomme

                • créer inclure/metasplus-pomme.html
                1. span>(POMMES){id_pomme}>
                2. [(#REM) Etape 1 : on récupére les données de l'objet ]
                3. #SET{titre,#TITRE|supprimer_tags|textebrut}
                4. ...
                5. [(#REM) Etape 2 : on les transmet au modèle général ]
                6. {fond=inclure/metasplus,
                7. titre=#GET{titre},
                8. lang=#GET{lang},
                9. desc=#GET{desc},
                10. auteur=#GET{author},
                11. date=#GET{date},
                12. url=#GET{url},
                13. logo=#GET{logo},
                14. og-type=product} />

                Télécharger

                • ajouter dans le squelette de la page pomme, dans le ....
                1. {fond=inclure/metasplus-pomme,id_pomme} />

                Outils divers

                Outils Facebook
                Outil pour vérifier vos opengraphs
                https://developers.facebook.com/too...

                Ces données sont mises en cache, voici l'outil pour vider le cache
                https://developers.facebook.com/too...

                Outils Twitter
                Outil pour tester vos twitter cards
                https://cards-dev.twitter.com/validator

                Améliorez l'indexation de vos articles dans les moteurs et leur affichage sur les réseaux sociaux grâce aux métadonnées Dublin Core, Open Graph et Twitter Card.
                {{{Installation}}} Activer le plugin dans le menu dédié. Dans le panel de configuration, vous pouvez choisir quelles méta-données, vous voulez activer ou non: -* Dublin Core: sémantique -* [Opengraph->http://ogp.me] : format adopté notamment par Facebook . Il permet d'améliorer les informations transmises lorsque vos utilisateurs partagent une page -* [Twitter Card->https://dev.twitter.com/cards/overview] {{{Utilisation}}} Dans la balise .... de votre squelette de la page article, ajouter le code suivant à l'intérieur de la boucle ARTICLES metasplus-article,id_article} /> {{{Utilisation avancée}}} Il est possible d'étendre l'ajout des métas à d'autres objets SPIP (rubriques, lieux, cartes, patates, ....) Le plugin fournit un modèle général {{inclure/metasplus.html}} auquel il faut fournir les informations requises metasplus, titre=#GET{titre}, lang=#GET{lang}, territoire=#GET{territoire}, desc=#GET{desc}, auteur=#GET{author}, date=#GET{date}, url=#GET{url}, logo=#GET{logo}, og-type=article} /> Tous les paramètres sont facultatifs mais il est fortement indiqué de renseigner au minimum {titre}, {desc}, {url}. Il faut transmettre des chaînes brutes sans HTML. On pourra utiliser les filtres |supprimer_tags|textebrut pour nettoyer les balises SPIP. |{{Nom du paramètre}}|{{Remarques}}| |{{titre}}|titre| |{{lang}}|langue| |{{territoire}}|Permet de créer le locale facebook en_UK. Si ce paramètre territoire n'est pas transmis, on tente une locale avec la langue fr_FR, de_DE
                Avec une exception pour l'anglais réglé par défaut sur en_US
                Pour documentation, voici la liste des locales acceptés par Facebook ; https://www.facebook.com/translations/FacebookLocales.xml| |{{desc}}|texte court d'introduction| |{{auteur}}|auteur sans lien| |{{date}}| Date en format YYYY-MM-DD| |url|URL de la ressource| |{{logo}}|Les images doivent faire au minimum 200x200 pixels et peser moins de 1Mo.| |{{og-type}}|Pour connaître les valeurs acceptées de {og-type},
                on pourra consulter:
                [->https://developers.facebook.com/docs/reference/opengraph].
                Si on ne précise rien, la valeur par défaut est {article}.| Par exemple pour un objet {{pomme}} -* créer {{inclure/metasplus-pomme.html}} [(#REM) Etape 1 : on récupére les données de l'objet ] #SET{titre,#TITRE|supprimer_tags|textebrut} ... [(#REM) Etape 2 : on les transmet au modèle général ] metasplus, titre=#GET{titre}, lang=#GET{lang}, desc=#GET{desc}, auteur=#GET{author}, date=#GET{date}, url=#GET{url}, logo=#GET{logo}, og-type=product} /> -* ajouter dans le squelette de la page pomme, dans le .... metasplus-pomme,id_pomme} /> {{{Outils divers}}} {{Outils Facebook}} Outil pour vérifier vos opengraphs [->https://developers.facebook.com/tools/debug/] Ces données sont mises en cache, voici l'outil pour vider le cache [->https://developers.facebook.com/tools/debug/sharing/batch/] {{Outils Twitter}} Outil pour tester vos twitter cards [->https://cards-dev.twitter.com/validator]

                pgn4spip à partir de SPIP 3

                https://contrib.spip.net/Interface-Francaisplay episode download
                November 2016, by Jacques[ —]

                Le plugin pgn4spip permet d'afficher des parties d'échecs dans vos articles SPIP.

                La version de pgn4spip disponible à partir de SPIP 3 présente quelques améliorations par rapport à la précédente version pour SPIP 2, notamment l'installation est beaucoup plus simple.

                Utilisation

                L'usage le plus simple est de télécharger un fichier pgn et de saisir dans le corps de l'article le modèle pgn avec le numéro du document, par exemple
                où 123 est le numéro du fichier pgn (document) téléchargé sur le site.
                
                Pour un usage avancé il est possible d'afficher de nombreuses options. Par exemple
                - affiche le document (fichier pgn) numéro 489
                - le coup à jouer à partir de la position affichée est le 6e pour les noirs (initialHalfmove=11)
                - on a un affichage type puzzle (position à résoudre - initialement le texte n'est pas affiché, la solution s'affiche lorsque l'on appuie sur les boutons)

                Les options possibles sont décrites en détail dans l'article de ce site

                On peut voir le plugin en fonctionnement par exemple dans cet article

                Il est possible également de saisir des positions FEN, comme dans cet exemple.

                Installation

                Le plugin copie le plugin original pgn4web dans un dossier lib à la racine du site.

                Pour pouvoir installer le plugin en automatique il faut donc avoir préalablement créés :
                - le dossier plugins/auto
                - le dossier lib

                Configuration

                Dans le backoffice la page de configuration du plugin s'appelle ainsi
                monsitespip.tld/ecrire/ ?exec=configurer_pgn4spip
                

                Il est possible d'y accéder facilement à partir de la page gestion des plugins, en cliquant sur l'icône outils sur la ligne de pgn4spip.

                Crédits

                pgn4spip est l'interface SPIP de pgn4web créé par Paolo Casaschi.

                Todo

                - Vérifier le fonctionnement des parties en live
                - Vérifier que les nouvelles options de pgn4web pourraient s'implémenter (vidéos...)
                - Vérifier l'accessibilité
                - Améliorer la visibilité du sélecteur de parties en multiparties

                Le plugin pgn4spip permet d'afficher des parties d'échecs dans vos articles SPIP. La version de pgn4spip disponible à partir de SPIP 3 présente quelques améliorations par rapport à la précédente version pour SPIP 2, notamment l'installation est beaucoup plus simple. {{{Utilisation}}} L'usage le plus simple est de télécharger un fichier pgn et de saisir dans le corps de l'article le modèle pgn avec le numéro du document, par exemple où 123 est le numéro du fichier pgn (document) téléchargé sur le site. Pour un usage avancé il est possible d'afficher de nombreuses options. Par exemple - affiche le document (fichier pgn) numéro 489 - le coup à jouer à partir de la position affichée est le 6ème pour les noirs (initialHalfmove=11) - on a un affichage type puzzle (position à résoudre - initialement le texte n'est pas affiché, la solution s'affiche lorsque l'on appuie sur les boutons) Les options possibles sont décrites en détail [dans l'article de ce site->https://www.ressources-echecs.net/Les-options-possibles-de-PGN4SPIP] On peut voir le plugin en fonctionnement par exemple dans [cet article->https://www.ressources-echecs.net/Afficher-des-parties-d-echecs-ici-une-petite-base-de-donnees] Il est possible également de saisir des positions FEN, [comme dans cet exemple->https://www.ressources-echecs.net/Diagrams-from-FEN-positions]. {{{Installation }}} Le plugin copie le plugin original pgn4web dans un dossier lib à la racine du site. Pour pouvoir installer le plugin en automatique il faut donc avoir préalablement créés : - le dossier plugins/auto - le dossier lib {{{Configuration}}} Dans le backoffice la page de configuration du plugin s'appelle ainsi monsitespip.tld/ecrire/?exec=configurer_pgn4spip Il est possible d'y accéder facilement à partir de la page gestion des plugins, en cliquant sur l'icône outils sur la ligne de pgn4spip. {{{Crédits}}} pgn4spip est l'interface SPIP de [pgn4web créé par Paolo Casaschi->http://pgn4web.casaschi.net/home.html]. {{{Todo}}} - Vérifier le fonctionnement des parties en live - Vérifier que les nouvelles options de pgn4web pourraient s'implémenter (vidéos...) - Vérifier l'accessibilité - Améliorer la visibilité du sélecteur de parties en multiparties

                Agenda Fullcalendar facile

                October 2016, by Maïeul[ —]

                Dans un précédent article, nous expliquions comment afficher un agenda Fullcalendar sur son site avec le plugin agenda.
                Cependant, ceci nécessite des manipulation de squelettes, ce qui n'est pas toujours évident lorsqu'on débute.

                La présente contribution permet d'intégrer plus facilement un agenda Fullcalendar, sans qu'il ne soit cependant possible d'avoir une configuration avancée [1].

                Fonctionnalité

                Avec le plugin Agenda activé, le présent plugin permet d'afficher dans un article un agenda Fullcalendar, affichant les évènements par mois, semaine ou jour, et liant chaque évènement à la page de l'article qui lui est associé.

                PNG - 39.8 ko
                Agenda souhaité au final

                Installation

                Le plugin nécessite SPIP 3.1, il s'installe comme n'importe quel plugin.

                Utilisation

                Une fois le plugin installé, et les événements créés, il suffit d'insérer le code suivant dans un article :


                [1] Si le besoin s'en fait sentir, il est nécessaire d'apprendre des notions de squelettes SPIP, puis de lire mon tutoriel.

                Dans un précédent article, nous expliquions [comment afficher un agenda Fullcalendar sur son site avec le plugin agenda->4210]. Cependant, ceci nécessite des manipulation de squelettes, ce qui n'est pas toujours évident lorsqu'on débute. La présente contribution permet d'intégrer plus facilement un agenda Fullcalendar, sans qu'il ne soit cependant possible d'avoir une configuration avancée[[Si le besoin s'en fait sentir, il est nécessaire d'apprendre des notions de squelettes SPIP, puis de lire mon tutoriel.]].
                {{{Fonctionnalité}}} Avec le plugin [Agenda->2858] activé, le présent plugin permet d'afficher dans un article un agenda Fullcalendar, affichant les évènements par mois, semaine ou jour, et liant chaque évènement à la page de l'article qui lui est associé. {{{Installation}}} Le plugin nécessite SPIP 3.1, il [s'installe comme n'importe quel plugin-> http://www.spip.net/fr_article3396.html]. {{{Utilisation}}} Une fois le plugin installé, et les événements créés, il suffit d'insérer le code suivant dans un article:

                0 | 10










                mirPod.com is the best way to tune in to the Web.

                Search, discover, enjoy, news, english podcast, radios, webtv, videos. You can find content from the World & USA & UK. Make your own content and share it with your friends.


                HOME add podcastADD PODCAST FORUM By Jordi Mir & mirPod since April 2005....
                ABOUT US SUPPORT MIRPOD TERMS OF USE BLOG OnlyFamousPeople MIRTWITTER