SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

288 Plugins, 197 contribs sur SPIP-Zone, 129 visiteurs en ce moment

Accueil > Administration et BDD > Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et (...)

Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

2 août 2006 – par jrebillat – 36 commentaires

Toutes les versions de cet article : [français] [italiano]

0 vote

Ceci est une ARCHIVE, peut-être périmée. Vérifiez bien les compatibilités !

Comme il est bien indiqué dans cet article , il est possible d’ajouter des champs dans les tables Spip depuis la version 1.8. Ceci permet de remplacer les champs extras, mais pas vraiment. En effet les champs extras ont l’avantage de pouvoir être entrés directement dans la partie privée lors de l’édition de la table correspondante, ce qui n’était pas le cas des champs ajoutés.

Ayant eu besoin d’ajouter des champs dans la table articles pour un site en préparation, il m’a été nécessaire de me pencher sur ce sujet - uniquement pour la table articles. Ci-dessous sont proposées des fichiers modifiés pour gérer les champs ajoutés directement lors de l’édition des articles. Les modifications proposées essayent de respecter le mode de fonctionnement de SPIP.

Le principe est d’utiliser un fichier descriptif des champs ajoutés pour que l’affichage se fasse en relation avec ce qu’il faut y entrer.

Les modifications sont là :

Pour la V1.8.3 :

Add-ons pour /ecrire

et pour la V1.9 beta2 au 03/06/06 :

add-ons V1.9 courante (03/06/06)

Voici un exemple de fichier de configuration, que je vais décrire plus loin.

<?php
$GLOBALS['champs_site'] = Array (
       'articles' => Array (
                       'inedit' => Array(
                                 'champ'    => 'inedit',
                                 'titre'    => 'Inédit ?',
                                 'style'    => Array( 'couleur' => '#FF0000' ),
                                 'secteur'  => 1,
                                 'type'     => 'choix',
                                 'multiple' => 'non',
                                 'modele'   => 'texte',
                                 'valeurs'  => Array (
                                            'Oui' => 'Inédit',
                                            'Non' => 'Réédition'
                                 )
                       ),
                       'isbn' => Array(
                                 'champ'    => 'isbn',
                                 'titre'    => 'Num.ISBN',
                                 'style'    => Array(),
                                 'secteur'  => 1,
                                 'type'     => 'texte',
                                 'taille'   => 20,
                                 'modele'   => 'texte'
                       ),
                       'essaicheck' => Array(
                                 'champ'    => 'essaicheck',
                                 'titre'    => 'Essai check',
                                 'style'    => Array(
                                              'aligne' => 'horizontal',
                                              'couleur' => '#0088CC'
                                 ),
                                 'secteur'  => 1,
                                 'type'     => 'choix',
                                 'multiple' => 'oui',
                                 'modele'   => 'texte',
                                 'valeurs'  => Array (
                                            'Oui' => 'Oui',
                                            'Non' => 'Non',
                                            'Ptèt' => 'Bof'
                                 )
                      ),
                       'project' => Array(
                                 'champ'    => 'project',
                                 'titre'    => 'Project',
                                 'style'    => Array(),
                                 'secteur'  => 1,
                                 'type'     => 'table',
                                 'table'    => 'site_proj',
                                 'colonne'  => 'name',
                                 'valeur'   => 'prjid',
                                 'multiple' => 'non',
                                 'modele'   => 'entier'
                       ),

        )
);
?>

Chaque champ est décrit avec certains éléments communs obligatoires :
-  ’champ’ pour indiquer le nom de la colonne dans la table
-  ’titre’ pour donner un nom au chmp pour l’utilisateur
-  ’style’ pour éventuellement modifier l’aspect typographique
-  ’secteur’ pour indiquer dans quel secteur ce champ est utilisable (un seul secteur par champ pour l’instant)
-  ’type’ indique le type de représentation souhaitée, qui peut être ’choix’ (un choix dans une liste figée), ’texte’ (entrée simple) ou ’table’ (choix à partir d’une table externe)

Un champ optionnel ’modele’ => ’texte’ pour indiquer que le champ est de type texte dans la base (sinon le champ est considéré comme un nombre).

Ensuite, selon le type de champ, d’autres éléments viennent le préciser.

Pour les champs de type ’texte’, la taille doit être fournie (longueur du champ)

Pour les choix, il faut indiquer s’ils sont ’multiple’ ou simple, ainsi que la liste des valeurs et de ce qui doit être affiché pour chaque valeur.

Pour les tables externes, il faut indiquer le nom de la ’table’, la ’colonne’ à afficher ainsi que la colonne contenant la ’valeur’ à mettre dans le champ. On peut aussi avoir des choix multiples.

Ceci peut donner en édition :

exemple

et en visualisation (dans l’espace privé) :
exemple2

Dernière modification de cette page le 25 octobre 2006

Retour en haut de la page

Vos commentaires

  • Le 13 mars 2008 à 15:31, par Linagora En réponse à : Version 1.9.2

    J’ai essayé d’installer cette contrib sur une install SPIP 1.9.2 et ça ne fonctionne pas.
    « call to undefined function acces_rubrique()... » dans les scripts ecrire/exec/articles.php et ecrire/exec/articles_edit.php
    Quelqu’un peut m’aider SVP ???

    Merci

    • Le 27 mars 2008 à 10:53, par mathbouq En réponse à : Version 1.9.2

      Je ne sais pas si tu as trouvé une solution ? Pour ma part, j’ai réussi à résoudre ce problème (la solution est donnée ici : http://forum.spip.org/fr_197801.html), mais je tombe ensuite sur un nouveau message d’erreur :
      undefined function bouton_imessage()

      Une fois le code coupable mis en commentaire, nouveau message d’erreur :
      undefined function formulaire_mots()

      Je laisse donc tomber temporairement, le code de cette contribution est sans doute un peu obsolète du fait des nouvelles versions de SPIP (1.9.2c, pour ma part).

      Cette contribution me tente bien, mais je me demande s’il n’y a pas plus simple, en passant par un plugin ?

    • Le 27 mars 2008 à 20:45, par jrebillat En réponse à : Version 1.9.2

      En fait, ce n’est pas comme cela que j’ai porté sur les autres versions mes modifications.
      Le mieux est de prendre le code des fichiers à remplacer et de l’éditer pour y intégrer les changements - ainsi on profite des ajouts de la nouvelle version de Spip.
      Mais pour faire cela, il faut disposer à la fois des sources de la version d’avant (1.9.1), des sources correspondant modifiés - pour voir où sont les différences - et du nouveau code pour effectuer les changements.
      Pour ma part, j’attends la finalisation de la 1.9.3 pour porter mes modifications. La 1.9.2 c’est trop compliqué avec toutes ces sous-versions.

      Et oui, ce serait mieux dans un plugin mais je n’ai pas vu comment insérer du code HTML au milieu de celui de Spip, seulement comment en ajouter à certains endroits (et pas où je le veux)

    • Le 21 avril 2010 à 17:26, par Yves En réponse à : Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

      Bonjour,

      Il suffit de remplacer la fonction acces_rubrique() par acces_restreint_rubrique() dans le code php, dans le style /var/www/spip/plugins/saisie_user/exec/naviguer.php

      J’ai le même problème avec formulaire_mots() mais je ne sais pas par quoi le remplacer ...

    • Le 21 avril 2010 à 18:58, par jrebillat En réponse à : Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

      En fait, j’ai fait le plugin, finalement, pour Spip 2.0.

    Répondre à ce message

  • Le 24 septembre 2007 à 17:59, par lo En réponse à : Plusieur secteur

    Bonjour comment faire pour le modifier pour qu’il fonctionne avec plusieurs rubrique, voici mon code :

    function exec_articles_edit_champs_ajoutes($id_rubrique, $pchamp)

    //============================================================================
    // gestion des champs ajout�s
    //Possibilité de choisir par rubrique et non plus par secteur.
    //MODIFER PAR LOïC (C-Stan) LE 24/09/07
    $txt = «  » ;
    foreach ($GLOBALS[’champs_site’][’articles’] as $keychamp => $pluschamp)

    $tableausecteurs=array() ;
    $tableausecteurs=explode(" « ,$pluschamp[’secteur’]) ;

    foreach ($tableausecteurs as $valsecteur)

    if ($valsecteur == $id_rubrique)

    $pretxt = »" ;
    $posttxt = «  » ;
    if ((isset($pluschamp[’style’]))&&(isset($pluschamp[’style’][’couleur’])))

    $pretxt .= «  » ;
    $posttxt = « 
     ».$posttxt ;

    $txt .= $pretxt ;

    //-------------------------------------------------------
    // champ de type texte
    if ( !strcmp($pluschamp[’type’],’texte’))

    $txt .= «  ».$pluschamp[’titre’].«  » ;
    $txt .= « 

     » ;

    //-------------------------------------------------------
    // champ de type choix pr�d�fini
    elseif ( !strcmp($pluschamp[’type’],’choix’))

    $brtxt = « 
     » ;
    $pbrtxt = « 
     » ;
    if ((isset($pluschamp[’style’]))&&(isset($pluschamp[’style’][’aligne’])) &&
    (!strcmp($pluschamp[’style’][’aligne’],« horizontal »))
    )

    $brtxt = «   » ;
    $pbrtxt = « 

     » ;

    $txt .= «  ».$pluschamp[’titre’].«  » ;
    $txt .= « $brtxt » ;
    if ( strcmp($pluschamp[’multiple’],’non’))

    $inptxt = « type=’checkbox’ name=’ ».$keychamp.« []’ » ;
    $vals = split(« , »,$pchamp[$keychamp]) ;

    else

    $inptxt = « type=’radio’ name=’$keychamp’ » ;
    $vals = array() ;
    $vals[] = $pchamp[$keychamp] ;

    foreach ($pluschamp[’valeurs’] as $keyval => $plusval)

    if (in_array($plusval,$vals))

    $txt .= «  $keyval ».« $brtxt » ;

    else

    $txt .= «  $keyval ».« $brtxt » ;


    $txt .= $pbrtxt ;

    //-------------------------------------------------------
    // champ de type choix � partir d’une table externe’
    elseif ( !strcmp($pluschamp[’type’],’table’))

    $txt .= «  ».$pluschamp[’titre’].« 
     » ;
    $query = « SELECT ».$pluschamp[’colonne’] ;
    if (isset($pluschamp[’valeur’]))

    $query .= « , ».$pluschamp[’valeur’] ;

    $query .= « FROM ».$pluschamp[’table’] ;
    $result = spip_query($query) ;
    if ( !strcmp($pluschamp[’multiple’],’non’))

    $txt .= « 

    else

    $txt .= « 
     » ;

    $txt .= $posttxt ;

    else

    $txt .= «  » ;

    $txt .= « 
     » ;
    return $txt ;

    Ce code fonctionne mais pas avec toute mes rubrique en locurence j’ecrit « 4 5 », la 5 marche mais pas la 4. c toujours la derniere qui fonctionne. pk ? Merci

    • Le 30 septembre 2007 à 22:02, par jrebillat En réponse à : Plusieur secteur

      Pour obtenir le résultat attendu, j’ai modifié le fichier « articles_edit.php » en remplaçant la ligne :

      if ($pluschamp[’secteur’] == $id_secteur)

      de la gestion des champs ajoutés (vers la ligne 354 - dépend de la version de l’add-on) par

      // recherche des secteurs concernés

      $concern = false ;

      $vs = split(’ ’,$pluschamp[’secteur’]) ;

      foreach ($vs as $v)

      {

      if ($v == $id_secteur)

      $concern = true ;

      }

      //if ($pluschamp[’secteur’] == $id_secteur)

      if ($concern)

      Dans mes_champs.php, il faut indiquer les secteurs multiples entre quotes :

      ’secteur’ => ’1 27’,

    Répondre à ce message

  • Le 31 mars 2007 à 01:22, par Jean-Marc En réponse à : Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

    J’ai essayé de gérer pour un site multilingue des balises multi dans les champs supplémentaires, mais cela ne marche pas dans le site public comme pour les autres champs. J’obtiens le champ en entier avec les mutli (texte en français) et non pas juste le texte correspondant à la langue courante.
    Y’a t’il un moyen de gérer les balises multi avec cette méthode ?
    Merci de votre aide.

    • Le 31 mars 2007 à 09:57, par jrebillat En réponse à : Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

      Je n’ai rien prévu de particulier pour le multilingue...
      As-tu bien renseigné tes colonnes dans le fichier base/serial.php ?

    • Le 31 mars 2007 à 10:24, par Jean-Marc En réponse à : Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

      Sous spip 1.9 j’ai déclaré le nouveau champ dans le fichier mes_fonctions.php que j’ai mis dans le répertoire des squelettes.
      J’ai inscrit le champ dans le fichier base/serial.php mais cela ne fonctionne toujours pas. Le champ affiche des ... et ne semble pas passer par le filtre de la langue comme les autres champs...

    • Le 31 mars 2007 à 11:04, par jrebillat En réponse à : Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

      Il m’est difficile de t’aider, j’en suis désolé.
      Je ne connais pas le fonctionnement du multilingue (le site pour lequel je fais cette contrib est seulement en français).
      En plus ma version - qu’il faut que je mette à dispo, d’ailleurs - est très loin de celle qui est disponible ici, donc je n’ai plus vraiment le même code.
      Il serait peut-être possible de trouver une explication en regardant et comparant le contenu des champs dans la base elle-même. Mais il nous faudrait quelqu’un connaissant le fonctionnement du multilingue...

    • Le 1er avril 2007 à 00:05, par Jean-Marc En réponse à : Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

      Merci pour la réponse. Dans la BD tout est ok, l’écriture avec les balises mutli est correct.
      Pour les champs existants (surtitre, titre, etc...) utilisant les balises mutli, le site public me met bien uniquement le texte de la langue courante, par contre pour les nouveaux champs déclarés tout le contenu du champ s’affiche, par exemple pour #TEST j’obtiens tout son contenu cad : « Test en français » alors que le site ne devrait m’afficher uniquement « Test en français ».
      Je testerai la contrib des champs homonymes dans laquelle on parle de l’utilisation possible des champs multi, mais le résultat devrait être identique au vu de la contrib... Je vous tiens au courant.

    • Le 2 avril 2007 à 09:34, par ? En réponse à : Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

      Résultat identique avec la contrib des champs homonymes. Sur le site public mes nouveaux champs créés s’affichent entièrement avec les <multi> !
      Pourtant je ne vois pas pourquoi cela ne se passe pas pareil que les autres champs ou spip n’affiche que le texte du multi restreint à la langue courante.

    • Le 28 mai 2007 à 13:03, par Vinnie En réponse à : Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

      Il suffit d’utiliser le filtre « propre » avec ton champ pour n’afficher que le contenu concernant la langue concernée.
      Exemple : pour un champ qui vaut oui, (#MONCHAMPS affichera « yes » si lang=en et « oui » pour lang=fr.
      En revanche, si dans ton squelette tu utilises [(#MONCHAMPS)], Spip affichera « [en] yes [fr] oui ».

    Répondre à ce message

  • Le 2 février 2007 à 07:36, par Nicolas En réponse à : Affichage permanent des champs vides

    Bonjour,

    Merci pour ette contrib qui m’est très utile. avec Spip 1.8.3
    J’ai cependant un petit souci...

    Comment faire pour que les champs mêmes vides s’affichent, que ce soit en MODIFICATION ou CONSULTATION d’article dans l’espace privé de Spip ?

    C’est gênant de ne pas pouvoir avoir les champs vides.. des fois j,aimerais bien remplir un de ces champs avec de l’info qu’un internaute a mis à la mauvaise place.

    • Le 2 février 2007 à 08:03, par jrebillat En réponse à : Affichage permanent des champs vides

      Le fait de cacher les champs vides en consultation est fait exprés. Par contre ils devraient apparaître en modification.
      Pour la consultation, il y a juste une ligne de source à modifier (justement un test si le champ est vide) mais je ne sais plus trop où dans la version pour la 1.8.3 ...

    • Le 16 février 2007 à 20:41, par Nicolas En réponse à : Affichage permanent des champs vides

      Merci pour la réponse,

      Je confirme l’absence des champs vides en CONSULTATION, ce que je comprends
      MAIS aussi en MODIFICATION ce qui est malheureux.

      Je vais voir si je peux modifier le code.... aie aie aie

    • Le 16 février 2007 à 21:51, par Nicolas En réponse à : Affichage permanent des champs vides

      Finalement je ne trouve pas le code à modifier pour faire en sorte que TOUS LES CHAMPS SOIENT DISPONIBLES en MODIFICATION...
      J’ai cherché dans :

      -  mes_champs.php

      -  articles.php3

      -  articles_edit.php3

      Niet, que dalle...

      zauriez pas une indice à me donner pour que je puisse trouver ce fameux code à modifier ?

      Merci d’avance

    • Le 17 février 2007 à 08:49, par jrebillat En réponse à : Affichage permanent des champs vides

      Un autre point à regarder :
      La contrib permet de n’afficher/modifier certains champs que pour des secteurs donnés. C’est peut-être de là que vient le problème ?

    • Le 18 février 2007 à 16:17, par Nicolas En réponse à : Affichage permanent des champs vides

      Que veux-tu dire par SECTEUR, veux-tu dire RUBRIQUE ?

      En tout cas, jusqu’ici le comportement de la contrib est le même quelle que soit la RUBRIQUE mais je n’ai pas d’ARTICLES dans les SECTEURS, seulement dans des SOUS_RUBRIQUES.

      A part ça, ce sont toutes des colonnes supplémentaires dans la table ARTICLES et lorsque les champs ont déjà de l’information entrée par l’internaute je peux les modifier.

      Tous les champs, s’ils contenaient déjà de l’information peuvent être modifiés mais SI ET SEULEMENT SI car sinon je ne les vois pas en modification.

      Merci A+

    • Le 18 février 2007 à 16:51, par jrebillat En réponse à : Affichage permanent des champs vides

      Un SECTEUR est une RUBRIQUE située à la racine du site.

      Dans « mes_champs.php », pour chaque champ il est possible d’indiquer :

      ’secteur’ => 1,

      (Ou ’secteur’ => xxx, ), ce qui a pour effet de limiter la possibilité d’édition de ce champ aux sous-rubriques du secteur xxx indiqué. Dans ce cas, le champ ne sera pas éditable dans un autre secteur, mais - ce fut mon choix - je l’ai laissé visible s’il possède une valeur (ça a dû me paraître intelligent à l’époque... ). On ne pourra l’entrer que pour les sous-rubriques de la rubrique xxx située à la racine.

    • Le 21 février 2007 à 07:01, par Nicolas En réponse à : Affichage permanent des champs vides

      Voilà, c’était ça... le # de secteur... je me demandais justement à quoi servait ce champs !

      Cela commence à ressembler à la contrib géniale. Mille mercis, vraiment.

      Une dernière question, j’ai ajouté un champ que j’aimerais pouvoir afficher en modification en TEXTAREA avec plusieurs lignes donc. C’est faisable ?

      Merci encore

      Nicolas

    • Le 21 février 2007 à 17:08, par jrebillat En réponse à : Affichage permanent des champs vides

      Ce n’est pas prévu - je n’en ai pas eu besoin.

      Toutefois j’ai actuellement une version plus élaborée (avec des listes venant de tables externes par cross-reference, en particulier) dans laquelle il doit être possible d’ajouter des TextArea - mais elle n’existe que pour SPIP 1.9.1.

    • Le 11 avril 2007 à 14:17, par François En réponse à : Affichage permanent des champs vides

      Cela semble intéressant cette version pour 1.9.1 (ou plus...)
      Serait-il possible de l’avoir ?
      Merci d’avance

    • Le 12 avril 2007 à 00:57, par ? En réponse à : Affichage permanent des champs vides

      Bon, ok, la voila : http://www.alantea.net/downloads/ecrire-spip-1.9.1.zip
      Mais je n’ai pas trouvé le temps de la documenter, ce qui peut poser problème.

      J’ai ajouté :

      - le type « calendrier » pour choisir des dates

      - le type « cross2 » permettant de placer des références à des tables par tables de liens à trois colonnes (dans l’exemple il s’agit pour un livre d’avoir l’auteur et sa fonction)

      - la possibilité d’ajouter des valeurs dans une table externe liée.

      A regarder : l’exemple de fichiers « mes_champs.php »

    Répondre à ce message

  • Le 13 août 2006 à 16:51, par domdas En réponse à : Pb d’affichage sur v.1.9

    Merci pour cette contrib qui me serait très utile mais sauf erreur de ma part elle ne semble pas fonctionner avec la version 1.9 actuelle (01/07/06) en mode local avec easyphp 1.8.

    Les nouveaux champs apparaissent bien dans l’article mais rien ne s’affiche dans le cadre « champs ajoutés » après l’enregistrement des valeurs et pour cause, les données ne sont pas sauvegardées dans la base ?

    Quoi faire pour y remédier ?

    Merci pour votre aide.

    • Le 27 août 2006 à 19:31, par isom En réponse à : Pb d’affichage sur v.1.9

      peut-être inscrire le(s) champ(s) en question dans phpadmin ...

    • Le 23 mars 2007 à 13:48, par ? En réponse à : Pb d’utilisation

      Bonjour,

      Serait-il possible de savoir comment exactement installer cette contrib sur une 1.9.2 ?

      Merci d’avance

    Répondre à ce message

  • Le 2 février 2007 à 07:38, par Nicolas En réponse à : Affichage permanent des champs vides

    Bonjour,

    Merci pour ette contrib qui m’est très utile. avec Spip 1.8.3
    J’ai cependant un petit souci...

    Comment faire pour que les champs mêmes vides s’affichent, que ce soit en MODIFICATION ou CONSULTATION d’article dans l’espace privé de Spip ?

    C’est gênant de ne pas pouvoir avoir les champs vides.. des fois j,aimerais bien remplir un de ces champs avec de l’info qu’un internaute a mis à la mauvaise place.

    Répondre à ce message

  • Le 24 janvier 2007 à 00:39, par Nicolas En réponse à : Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

    Bonjour,

    J’utilisais cette contribution avec bonheur et j’avais ajouté mes propres champs.

    Mais voilà qu’aujourd’hui cela ne fonctionne plus, plus moyen de modifier un article comme avant en utilisant cette contrib. Si je l’enlève, je peux à nouveau modifier les articles.
    Après investigation sérieuse , je me demande ce que j’ai pu faire pour causer cela

    1- Est-ce parce que j’ai ajouté un champ à la table FORUM et un autre à la table AUTEURS et que cette contrib ne prévoit que des ajouts à la table ARTICLES ??

    Sinon je n’ai aucune idée... C’Est ma seule piste.. Etes-vous en mesure de m’aider ??

    Merci

    Répondre à ce message

  • Le 26 septembre 2006 à 12:13, par quentic En réponse à : Edition des colonnes supplémentaires de la table Articles (SPIP 1.8.3 et 1.9B2)

    Bonjour,

    Je cherche à mettre à jour la contrib pour SPIP 1.9.1
    J’y suis presque : Les champs s’affichent correctement dans l’interface privée. Il me reste à enregistrer dans la table articles la valeur entrée pour nouveau champ car pour le moment les modifications dans ces champs ne sont pas prises en compte.

    Un petit coup de pouce : où est-ce que ça se passe en SPIP 1.9.1 ?

    Répondre à ce message

  • Le 27 août 2006 à 19:32, par isom En réponse à : thx

    merci beaucoup pour cette contrib qui est forte utile pour mon cas et qui semble marcher correctement.

    Répondre à ce message

Répondre à cet article

Qui êtes-vous ?
  • [Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Acces Restreint 3.0

    11 décembre 2008 – 813 commentaires

    Le plugin accès restreint permet de définir et de gérer des zones de l’espace public en accès restreint. Cette version du plugin a été redévelopée et optimisée tout spécialement pour SPIP 2.0. Il en découle une amélioration des performances sur les gros (...)

  • SpipClear 2.1

    18 avril 2009 – 138 commentaires

    Un squelette de blog parmi les autres, entièrement pompé (avec la permission du concepteur) sur le thème par défaut de DotClear.

  • Mailsubscribers

    16 janvier 2013 – 328 commentaires

    Ce plugin permet de gérer les inscriptions (ou abonnements) à la diffusion de contenu par email. Mailsubscribers permet de gérer les inscriptions par Opt-in simple ou double et la désinscription par URL. Ce plugin gère également plusieurs listes de (...)

  • Minidoc : différentes vues pour les documents attachés

    3 février – commentaires

    Minidoc est un plugin pour SPIP 3.1 qui ajoute aux listes de documents attachés à des objets éditoriaux (tel que les articles), des boutons permettant de changer le type d’affichage de ces listes. Il a été intégré dans le plugin Médias inclu avec SPIP (...)

  • Agenda 2.0

    3 novembre 2008 – 1095 commentaires

    Voici la version pour SPIP 2.0 du Plugin Agenda pour SPIP 1.9.2, avec une interface remaniée pour encore plus de plaisir. Pour une documentation concernant l’utilisation d’Agenda 3 pour SPIP 3, veuillez pour l’instant vous référer à SPIP 3, Agenda (...)