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
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
À 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.
Discussions par date d’activité
137 discussions
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
J’ai ajouté dans la déclaration :
ç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é)
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
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}
Bonjour,
Est-ce que je comprends bien que cet info est obsolèthe ?
Je vois que le lien avec le mot-clé est stocké dans la table mots_liens.
Non joz, l’info n’est pas obsolète ; seulement tu as mal compris ce qu’il exprime.
Si tu demandes à créer la table de lien pour ton objet éditorial xxx soit donc spip_xxx_liens, les mots s’enregistrent toujours évidement dans spip_mots_liens ; cependant le critère
(XXX){id_mot}
ne sait lui, pas forcément toujours s’il doit utiliser comme table de jointure spip_xxx_liens ou spip_mots_liens ; et par défaut ça va prendre le plus court chemin de jointure, le plus près de l’objet éditorial d’origine. Une explication plus détaillée là : http://marcimat.magraine.net/SPIP-3-Documents-MotsEn alternative tu peux aussi déclarer préférer utiliser la jointure sur spip_mots_liens par défaut pour ton objet ; c’est ce que fait le plugin mots avec la table des auteurs là : http://zone.spip.org/trac/spip-zone/browser/_core_/plugins/mots/base/mots.php#L199 (modification introduite par http://zone.spip.org/trac/spip-zone/changeset/53744)
ah ok !
merci pour l’éclaircissement :)
Répondre à ce message
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 :
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
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 :
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 :
ça rend le même résultat
Répondre à ce message
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 :
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
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 :
- 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
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
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 :
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.
Suivre les commentaires : |