La Fabrique

La Fabrique est un outil pour créer des plugins, essentiel dans la phase de développement d’un site SPIP. La Fabrique est capable de générer le code source minimal d’un plugin pour SPIP 3 (elle accélère donc le démarrage d’un plugin) et peut s’occuper également de construire un plugin fonctionnel gérant un ou plusieurs objets éditoriaux et leurs liaisons (et là, elle devient formidable !). La base du plugin construit, il ne vous reste plus qu’à l’adapter à vos désirs les plus créatifs.

La Fabrique est un outil de construction de plugin spécialement orientée pour la gestion d’objets éditoriaux. Pour ceux qui ont connu le plugin « Chat » ou « Chat2 », sachez que la Fabrique sait gérer tout ce qui est présent dans ce tutoriel / plugin, et même au-delà, bien au-delà.

N’allez pas trop vite !

Cette note est aussi présente lors de l’installation du plugin, mais redisons le encore :

  • la Fabrique crée un code fonctionnel mais qui ne répondra peut être pas à 100% de vos attentes. La Fabrique ne peut pas tout faire. À vous d’adapter ensuite le code généré.
  • un plugin est très vite fait grâce à la Fabrique. Mais attention : le code n’est qu’une partie d’un plugin. Si vous voulez que votre plugin perdure dans le temps, il faut qu’il soit utile, partagé, documenté, traduit, il faut assister les utilisateurs, et maintenir son code avec les évolutions de SPIP et c’est tout cela aussi un plugin !
  • la Zone de SPIP permet de collaborer sur les plugins. Essayez au maximum de ne pas créer des plugins existant déjà, pour éviter des doublons qui peuvent disperser d’autant les énergies pour toutes les tâches citées au point précédent.

Pré-requis

Pour faire fonctionner la Fabrique il faut :

  • PHP >= 5.3 (il est possible que 5.2 fonctionne aussi)
  • SPIP 3.0-RC minimum
  • Un navigateur récent (testé avec FF11 et Chrome 18.0)
  • Saisies >= 0.25
  • Et peut être un système Unix/Linux pour son serveur (appel de exec('diff') en PHP) [1]

Optionnellement mais conseillé :

Démonstration vidéo

Dans la vidéo suivante, vous verrez une présentation de la Fabrique impliquant la construction d’un plugin « Félins » dans lequel nous créons 1 objet éditorial « Chats ».
Cette vidéo est aussi disponible en meilleure qualité sur medias.spip.net

Présentation de la Fabrique en vidéo

Accéder à la fabrique

Depuis SPIP 3.1, La fabrique est accessible dans le menu de développement (il faut activer l’option de vos préférences personnelles pour voir ce menu)

Documentation

En attendant une documentation plus riche ici, vous pouvez lire ces articles :

Capture d’écran

La Fabrique, version 1.13.3
Interface d’accueil de la Fabrique avec un objet éditorial « Chats » de renseigné dans un plugin nommé « Félins »

À tester

« La Fabrique » doit être testée dans différents environnements. Vous êtes donc invités à explorer cet outil développé avec git sur la Zone [2]

Limitation connue

Actuellement (version 1.16.3), à partir d’un certain nombre d’objets et de champs (environ 10 objets * 8 champs ici), le formulaire devient naturellement inopérant à cause d’une limitation voulue de PHP : max_input_vars, par défaut à 1000 dans php.ini.
Pour contourner, il faut modifier php.ini pour tolérer plus de champs (5000) par exemple.

Attention

Depuis la version 2.0.0, le menu de la fabrique se trouve dans celui de Développement. Celui-ci est activable depuis l’espace préférence de l’utilisateur.

Notes

[1À faire vérifier par quelqu’un ayant un serveur local sous Windows

Discussion

137 discussions

  • 2

    Bonjour,

    J’ai un problème « récurent » : je n’arrive pas à créer un objet éditorial.

    Message d’erreur : « Oups. Une erreur inattendue a empêché de soumettre le formulaire »
    Puis je me retrouve avec le panneau « Site en travaux ».

    Message dont la recherche m’a mené ici : http://contrib.spip.net/Champs-Extras-3#forum488227

    Problème récurrent, car j’ai déjà rencontré ... il y a longtemps (sur des 3.0), à partir d’une certaine version. Si besoin, je peux retrouver plus de détails.

    Actuellement, mes versions :

    SPIP 3.1.3
    CHAMPS EXTRA 3.8
    SAISIE 2.7.12
    Serveur local : UBUNTU 16.04 (PHP 7 ...)

    J’ai adoré ce plugin ... mais je n’arrive plus à m’en servir. (Snif ...)

    Merci pour votre aide

    • Je ne sais pas ce qui provoque cela. Cette erreur peut apparaître si le formulaire n’arrive pas à se poster, en ajax donc. Peut être surchargez-vous des fichiers, tel que jQuery dans votre répertoire squelettes ?

      Avez vous d’autres plugins qui pourraient interagir en dehors de ceux que vous avez déjà indiqué ?

    • J’ai installé le plugin sur une configuration toute neuve : cela marche.

      J’ai, petit à petit, ré-établi la configuration initiale en espérant trouver le coupable .... Niet, cela fonctionne ! ??????????

      Alors, ce n’est pas gênant, puisque « La fabrique » peut être exploitée hors contexte.

      Si je reproduis le problème avec un soupçon, je reviendrai vers vous sur ce fil.

      Merci beaucoup et encore bravo pour ce plugin !

    Répondre à ce message

  • 2

    J’ai ajouté dans la déclaration :

    'url_voir' => 'concours',
    'url_edit' => 'editer_concours',

    ça semble résoudre la bizarrerie ?exec=concour qui donne page introuvable
    et pour le bouton de création rapide qui ne fonctionnait pas, dans paquet.xml régler l’URL concours_creer action=« editer_concours »

     ?exec=concours toujours Accès interdit
    qui serait peut-être causé par ? (les autorisations sont laissées par défaut et « échafauder » les fichiers tout est coché)

    [(#ENV**{exec}|=={concours_edit}|?{#INCLURE{fond=prive/squelettes/contenu/concours_edit,redirect='',env,retourajax=oui},#REM|sinon_interdire_acces})]

    En effet, prive/squelettes/contenu/concours_edit.html n’existe pas ...

    Pas faciles les exceptions de la langue française ... un concour, des concours c’est bien aussi :-)
    Prochain exemple de plugin pour suivre le plugin Chats : le plugin Chevaux !

    • Hum, je pense que tu ferais mieux de laisser url_voir à ’concours’ et url_edit à ’concours_edit’.
      Par contre, tu pourrais faire comme Gis pour la page qui liste l’ensemble des concours, c’est à dire l’appeler elle ’concours_tous’.

      C’est un cas que je n’ai pas testé avec la Fabrique d’avoir un objet avec un s final au singulier et pluriel. Le cas cheval / chevaux doit poser moins de souci, de même que jeu / jeux (singulier différent du pluriel donc).

      Il y a des choses à améliorer…

    • Merci pour ta réponse Mathieu
      Le ’s’ pose d’autres problèmes que je ne peux pas résoudre, j’ai laissé sans s au singulier, tant pis

    Répondre à ce message

  • 3

    Bonjour,

    d’abord merci pour ce plugin !!!

    un petit complément à la doc, pour celles et ceux qui galèrent à afficher les nouveaux objets liés à un mot clé. Pour faire ça, il faut une jointure sur la table mots_liens. Or la jointure automatique avec le critère {id_mot} est ambiguë... elle se fait sur la table objets_liens. Pour contourner ça, il suffit de préciser sur quelle table on veut la jointure en mettant le critère {mots_liens.id_mot}

    Répondre à ce message

  • 2

    Salut, je crée un objet « Concours » :
    Nom pluriel : Concours
    Nom singulier : Concours

    ça m’affiche des id_concour, supprimer_concour.php, ’type’ => ’concour’, ... sans le ’s’ à la fin, c’est normal ?

    Cordialement

    • Le nom pluriel ou singulier sert juste à la création des chaînes de langue ; pas à la création du nom du champ dans la table.

      Ici tu es dans le cas d’une table un peu spéciale dont tu voudrais id_concours ; c’est ce que j’ai nommé dans la Fabrique une « Table hors norme » il me semble.
      Dans la déclaration de l’objet dans la Fabrique :

      • Table > Spécificités de tables hors normes > clé primaire => adapter id_concour à id_concours
      • et type de l’objet au même endroit, je pense qu’il faut mettre ’concours’

      Cela devrait te générer quelque chose de plus adapté. Enfin dans base/concours.php il te faudra peut être adapter (il me semble que la Fabrique crée un code à peu près correct), par exemple en suivant le code de GIS pour les surnoms, qui a la même contrainte (gis, id_gis) :
      http://zone.spip.org/trac/spip-zone/browser/_plugins_/gis/trunk/base/gis.php#L27

      $tables['spip_gis'] = array(
          /* Declarations principales */
          'table_objet' => 'gis',
          'table_objet_surnoms' => array('gis'),
          'type' => 'gis',
          'type_surnoms' => array('gi'),

      Notamment le dernier type_surnoms doit avoir la valeur sans s final !

    • Merci beaucoup Mathieu pour ta réponse
      Effectivement c’était prévu dans « Table hors-normes », my bad

      Dans base/concours.php, il n’y a pas de ’surnom’, j’ai d’ailleurs fait une recherche dans tous les fichiers du plugin, ’surnom’ n’apparaît nul part, ni ’table_objet’

      La déclaration commence par :

      function concours_declarer_tables_objets_sql($tables) {
      
      	$tables['spip_concours'] = array(
      		'type' => 'concours',
      		'principale' => "oui",
      		'field'=> array(
      			'id_concours'        => 'bigint(21) NOT NULL',
      			'titre'              => 'text NOT NULL DEFAULT ""',

      Maintenant j’ai /ecrire/ ?exec=concours : Accès interdit
      Et bizarrement : /ecrire/ ?exec=concour amène sur la gestion de l’objet
      Hors concour.php n’existe pas, on a bien base/concours.php

      J’ai désinstallé le plugin, vérifié que le table était supprimée, vidé le cache, réinstallé, vidé /tmp à la main

       ?exec=concour&var_mode=debug me montre qu’un squelette ../tmp/cache/scaffold/contenu/concour.html est appelé qui donne :
      #ENV
      exec  : concour
      date  : 2016-08-31 04:45:14
      date_default  : 1
      date_redac  : 2016-08-31 04:45:14
      date_redac_default  : 1
      type-page  : concour
      composition  :
      lang  : fr
      espace_prive  : 1

      J’ai vérifié qu’il n’y a pas de concour.* dans le plugin et il n’y a pas de fichier qui contienne concour sans ’s’ ...

      J’ai aussi essayé d’ajouter les mêmes champs que gis :

      function concours_declarer_tables_objets_sql($tables) {
      
      	$tables['spip_concours'] = array(
      		'type' => 'concours',
      		'principale' => "oui",
      		'table_objet' => 'concours',
              'table_objet_surnoms' => array('concours'),
              'type_surnoms' => array('concour'),
      		'field'=> array(
      			'id_concours'        => 'bigint(21) NOT NULL',

      ça rend le même résultat

    Répondre à ce message

  • 7

    Bonjour,

    J’ai créé avec succès des nouveaux objets éditoriaux avec votre plugin et qui fonctionnent parfaitement.

    Cependant je me suis aperçu que du côté privé, n’importe quel rédacteur pouvait librement modifier ces nouveaux objets éditoriaux sans en être l’auteur pour autant.

    Il y a-t-il un champ sql ou des champs sql spécifique(s) à créer pour qu’un nouvel objet éditorial puisse n’être modifié que par son auteur ?

    Merci et bonne journée.

    • J’ajouterai que paradoxalement la table spip_auteurs_liens référence bien les nouveaux objets éditoriaux avec une juste correspondance id_auteur-id_objet-objet. Alors peut-être le manque se situe-t-il côté privé. Le cas échéant dois-je créer un formulaire côté privé pour chacun de mes nouveaux objets éditoriaux et qui vérifie réellement qui est l’auteur (avant de proposer une modification) ? Si je trouve entretemps, je réponds ici-même..

    • Dans la partie de la Fabrique qui crée l’objet éditorial, il est possible de modifier déjà quelques paramètres d’autorisations, dans le cadre donc « Autorisations ».

      Cependant le choix de ne permettre la modification que par les auteurs appartenant à l’objet n’est pas présent. C’est un manque à mon avis. Il faudrait je suppose également donc un choix de plus, tel que "Être auteur sur l’objet éditorial ou être au moins administrateur ou administrateur restreint sur la rubrique"… C’est à dire à peu près comme cela se passe sur les articles.

      Sinon, donc, on parle d’autorisations, la Fabrique ne fait que créer les fonctions d’autorisations qu’il est possible d’adapter donc ensuite. Ça se passe dans le fichier généré prefixe_autorisations.php, particulièrement donc sur l’autorisation ’modifier’.

      Il faut s’inspirer d’autres plugins / autorisations pour adapter le code dans votre plugin. Par exemple :
      -  https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/autoriser.php#L653
      -  http://zone.spip.org/trac/spip-zone/browser/_plugins_/albums/branches/v2/albums_autorisations.php#L88
      -  http://zone.spip.org/trac/spip-zone/browser/_plugins_/itineraires/trunk/itineraires_autorisations.php#L82

    • Je viens d’ajouter une nouvelle option d’autorisation qui permet de tester l’auteur de l’objet éditorial. http://zone.spip.org/trac/spip-zone/changeset/99199

      Ça répond en partie à la problématique. Là le statut de l’objet éditorial n’est pas testé, du coup, un rédacteur auteur de son objet peut l’éditer même s’il a été publié (contrairement aux articles).

      En tout cas c’est déjà mieux qu’avant.

    • La version 2.2.0 ajoute 2 nouvelles options d’autorisations en plus, dont une qui est comme le fonctionnement des articles. http://zone.spip.org/trac/spip-zone/changeset/99203

    • Merci pour tous ces efforts.

      J’ai fait la mise à jour de la fabrique, j’ai recréé mes 2 objets éditoriaux à partir de la sauvegarde du fichier fabrique_[monplugin].php, j’ai pu recréé le plugin de mes 2 objets éditoriaux toujours avec succès mais au final rien n’est changé. N’importe quel rédacteur peut toujours modifier l’objet qui ne lui appartient pas.

      Donc de mon côté je n’ai aucune différence, l’auteur de l’objet éditorial n’est pas testé côté privé apparemment, tout comme avant.

      Peut-être ai-je mal compris ce qu’apportait la mise à jour ?

      Pour mon nouvel objet information par exemple, je suis tombé sur le fichier prive/squelettes/contenu/information.html, et c’est bien sur cette page que je trouve l’autorisation de modifier mon information puisque concrètement c’est là qu’apparaît le bouton de modification alors qu’il ne devrait pas s’y trouver quand nous ne sommes que simple rédacteur et pas l’auteur de l’information.

      Tout à l’air de se passer ici :

      	[(#AUTORISER{modifier,information,#ID_INFORMATION})
      		[(#ID_INFORMATION|afficher_qui_edite{information}|non)
      			[(#URL_ECRIRE{information_edit,id_information=#ID_INFORMATION}|icone_verticale{<:information:icone_modifier_information:>,information,edit,right ajax preload})]
      		]
      		[(#ID_INFORMATION|afficher_qui_edite{information}|oui)
      			[(#URL_ECRIRE{information_edit,id_information=#ID_INFORMATION}|icone_verticale{#ID_INFORMATION|afficher_qui_edite{information},warning-24,'',right edition_deja ajax preload})]
      		]
      	]

      Je peux certainement faire un bricolage pour sauver les meubles en attendant mieux, mais s’il était possible de revoir ce bout de code pour que seul l’auteur de l’information (ou l’administrateur) puisse avoir le droit de modifier ce serait formidable.

      Sinon je m’inspirerai des autres plugins comme suggéré, mais ça va être beaucoup plus difficile à comprendre...

    • Il ne s’agit pas seulement de faire la mise à jour.

      Sur la fabrique, dans la description de l’objet éditorial « Informations » il y a un accordéon nommé « Autorisations ». Dedans, il y a des sélecteurs pour plusieurs types d’autorisations (créer, modifier, supprimer…). Il faut que tu modifies la sélection sur « Modifier » pour le mettre sur "Auteur de l’objet" ou "Auteur de l’objet sauf si publié"… Et de régénérer le plugin. L’avais tu fais ?

    • Ca marche ! Effectivement dans l’accordéon « Autorisations » j’avais laissé les réglages par défaut... J’ai cette fois régénéré le plugin en spécifiant modifier->Être auteur de l’objet ou au moins administrateur complet.

      Et maintenant donc plus de souci, le rédacteur reste à sa place et ne peut plus inopinément modifier un objet éditorial qu’il n’a pas créé, ni trafiquer son statut.

      Merci infiniment pour ces réponses très rapides !! Bonne fin de soirée !

    Répondre à ce message

  • 1

    Bonjour,
    J’ai une installation mutualisée ou je gère les plugins de la façon suivante
    -  Dans spip/plugins j’ai installé les plugins principaux utilisés sur la plupart des sites par svn. Sinon, sous SPIP3.0 j’avais pleins d’erreurs de désactivations de plugins lors des mises à niveau automatisées par l’interface. Ce fut un peu pénible.
    -  Dans /spip/sites/monsite.tld/config/mesoptions.php je mets :

    define('_ROOT_PLUGINS_SUPPL',_DIR_RACINE.'sites/'.$site.'/plugins/');
    define('_DIR_PLUGINS_SUPPL',_DIR_RACINE.'sites/'.$site.'/plugins/');
    define('_DIR_PLUGINS_AUTO',_DIR_RACINE.'sites/'.$site.'/plugins/auto/');


    -  Cela me permet de mettre d’autres plugins automatiquement installés qui restent au niveau de chaque site, et de développer mes squelettes sous forme de plugins dans ’.$site.’/plugins/gitdev/" pour sinchroniser mon développement à local avec le serveur de production.

    Tout ça pour dire que j’aurais voulu idéalement faire ’.$site.’/plugins/gitdev/fabrique_auto pour synchroniser mon développement, ou à la rigueur : ’.$site.’/plugins/fabrique_auto ...
    Mais celà ne marche que quand je fais /spip/plugins/fabrique_auto ... donc mon plugin de la fabrique serait disponible pour tous les sites ; ce qui n’est pas forcément le but.

    Y a t’il moyen de développer un site dans la fabrique pour un site spécifique d’une installation mutualisée.
    Sinon, une fois l’ébauche du plugin fait à la fabrique, je le ramènerai dans le rpertoire spécifique du site ; c’est pas la mort !

    merci Marcimat pour les conseils rapides et pertinents sur le Chat

    Bon été a tous ...

    • Je comprends. Il n’y a rien de prévu pour l’instant pour un tel usage avec la mutualisation.

      Personnellement j’aurais tendance à dire que du développement ne se fait pas au même endroit (ie sur un même SPIP) que des sites en production ! Il est beaucoup plus simple et sain d’avoir un site de développement en local, ou une copie d’un site existant en local et de travailler dessus pour tester de nouveaux plugins ou en créer avec la Fabrique.

      Il faudrait voir comment pouvoir améliorer le code de la Fabrique pour ton usage, mais c’est loin d’être évident ; en tout cas ça concerne les endroits où FABRIQUE_DESTINATION_PLUGINS est écrit dans le code, notamment la fonction fabrique_destination(), mais pas que.

      Peut être qu’on pourrait tenter d’ajouter une constante _DIR_PLUGINS_FABRIQUE qui vaudrait _DIR_PLUGINS par défaut, et remplacer les usages de _DIR_PLUGINS par cette nouvelle constante. Ça permettrait de la définir avant dans ton fichier d’options sur _DIR_PLUGINS_SUPPL .

      Si tu as le cœur à regarder, tester, le code est sur la zone :)

    Répondre à ce message

  • 1

    Lorsque je fais des modifs sur des champs d’un objet éditorial (ajout de champ, ou modification de taille d’un champ), j’ai compris qu’il fallait modifier le n° de « schéma » (Version de la structure des données), et aussi le n° de version du plugin.
    Mais même dans ces conditions, je dois désinstaller et réinstaller le plugin (et donc, repeupler les tables) pour que les modifications des champs soient prises en compte.

    Ai-je loupé quelque chose, ou bien est-ce le comportement normal ?
    J’avais cru comprendre (ou l’ai-je rêvé ?) qu’en désactivant le plugin, et en le réactivant, la magie opérerait pour trouver les modifications de la base.

    Merci,
    Sylvain

    • Je tente une reformulation... lorsqu’on fait une mise à jour de plugins « traditionnels », on ne perd pas les données, même s’il y a modification des objets éditoriaux.
      Avec mon joli petit plugin issu de la fabrique, chaque modification de la structure des objets éditoriaux nécessite une désinstallation et réinstallation, puis repeuplement de la base pour que la modification soit prise en compte.
      Est-ce que la « fabrique » prend en compte les mises à jour de structure des objets éditoriaux « à chaud » ? si oui, comment faire ? Et si non... comment faire ?...

    Répondre à ce message

  • Ce plugin me sert pour l’instant uniquement à créer le .xml, et les fichiers de conf. J’ai suivi consciencieusement le tuto ci dessus et je bloque dès que je crée un objet. Si je veux le peupler avec une table existante , comme dans l’exemple, ou créer un objet vide, la bulle « Veuillez compléter ce champ » apparait. Le problème est que je ne sais pas où est ce foutu champ sans nom. Et du coup je ne vais pas plus loin. Et pourtant je suis sur que ce plugin est très utile. Ce message d’alerte imprécis est $%&£ !

    Répondre à ce message

  • 2

    Bonjour,

    Je viens d’installer la Fabrique 2.0.30 pour tester en local sous Wamp SPIP 3.1.0 [22707].
    Je n’ai pas le lien du plugin dans l’onglet configuration du site.

    Quelqu’un saurait pourquoi ?

    • Oui, on met des pièges pour voir si les gens suivent :p
      La Fabrique en 3.1 est passé dans le menu « Développement »…
      qui ne s’active que depuis des préférences de l’utilisateur.

      Dans l’espace privé, cliquer sur ton nom en haut pour accéder aux configurations.

    • C’est malin, tu aurais pas pût le dire dans la doc du plug ? :-D
      J’allais te faire remonter le bug aussi :-D

    Répondre à ce message

  • Bonjour,

    Je suis en train de suivre pas à pas le screencast. La fonctionnalité « Différences avec la précédente création » ne fonctionne pas sur mon SPIP (3.1.0) qui tourne sur Ubuntu 12 (Php 5.3, Plesk 11).
    La zone où je devrais voir toutes les différences à chaque mise à jour du plugin est vide.

    Y a-t-il quelque chose à activer pour bénéficier de cette fonctionnalité ?

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

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

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom