Avertissement :
Il ne s’agit pas là d’une documentation officielle et aboutie de « Forms & tables » mais d’une compilation de messages divers de Cedric (l’auteur de ce plugin) sur différentes listes et sur irc. Ce qui implique qu’il peut y avoir des erreurs et imprécisions, voire que certains commentaires sont datés car le code a pu évoluer. L’idée a été qu’il fallait mieux publier ces notes en l’état plutôt que d’attendre la documentation complète qui sera un gros morceau à réaliser vu les potentialités de Forms & tables.
N’hésitez pas à vous servir de ce plugin dès maintenant, il est fonctionnel, et à contribuer à sa documentation, ne serait-ce que via le forum associé
NicolasR
Introduction
Créer aujourd’hui à partir de SPIP une application gérant un objet X gérant par exemple des auteurs, des mots clés et 2 champs texte, ca prend pas 2 jours ... mais à terme, ca pourrait prendre 1 heure !
C’est déjà aujourd’hui, c’est Forms&tables, c’est 5 min, c’est tout ajaxé.
Tu y définis la table, les champs, le formulaire d’édition/saisie d’un seul coup. Tout cela est utilisable depuis la partie privée, ou depuis la partie publique directement. Il y a une gestion de statuts pour modérer les données proposées depuis la partie publique. Tu associe les données de ta table personnelle avec les articles comme tu le fais avec les auteurs ou les mots clés par exemple.
On peut associer des documents et images aux données, comme pour les articles.
Les données peuvent etre importées/exportées en csv avec le plugin (c’est csv_import) qui marche de concert. Les structures des objets peuvent être importées/exportées en xml avec le plugin Snippet qui marche de concert. Il y a un début d’API pour utiliser tout cela depuis d’autres plugins, et un bon exemple d’utilisation de l’API est le plugin spip-sms-listes qui cree plusieurs tables différentes avec jointures chaines de langues spécifiques etc ...
Téléchargement
Récupérer les zips suivants sur l’espace de téléchargement, ou le(s)miroir(s), de spip-zone :
- forms_et_tables
- snippets
- csv_import
Installation
Comme tous les autres plugins, cf. http://www.spip.net/fr_article3396.html
La partie Forms
à rédiger ... peut etre en reprenant des extraits de plugin Forms : création de formulaires
Rajouter notamment pour SPIP 1.9.1 (n’est pas nécessaire avec SPIP 1.9.2 ou jquery est inclus dans le core) : « L’activation du plugin j-query permet d’améliorer sensiblement le déplacement des champs. Le déplacement par les flèches disparaît au profit d’un déplacement par "cliquer-glisser" qui permet de réorganiser complètement le formulaire ou d’insérer plus facilement un champ oublié »
Forms & table successeur de Forms
Mais la doc de Forms est encore utilisable en grande partie, voir cet échange repris sur l’irc le 10 décembre 2006
cedric : forms&tables il est clic and play
cedric : completement pret a l’emploi
cedric : j’ai fait un effort suite au retour d’experience sur l’agenda justement ...
cedric : donc j’ai meme integré les modeles qui vont bien
nicolasr : pour sa présentation : c’est le successeur de Forms qui pass en archives ?
nicolasr : (forms&tables)
cedric : oui il remplace forms
cedingrotte : a partir de la 1.9.1
nicolasr : est-ce qu’une partie de la doc de Forms est réutilisable (pour la partie forms), ou ça n’a rien à voir ?
Linstit : si, c’est ok, la doc sur contrib, elle est bonne AMHA
Linstit : faut juste documenter sondages et tables en plus, non, Cédric ?
cedric : oui tout ce qui concerne la creation de formulaires reste en grande partie vraie
cedric : quelques amenagements a faire suite a l’evolution de l’interface
Voir donc : plugin Forms : création de formulaires
La partie Tables
Avec la partie tables, le formulaire est utilisé aussi (dans la partie privée ou publique) pour ajouter/modifier des données de tables, donc potentiellement plusieurs id_donnee pour un seul id_auteur. Je pense donc qu’il faudrait qu’id_donnee soit passée dans l’url pour permettre la modif pour un auteur connecté. C’est ce que fait déjà le formulaire lorsque l’on est dans l’espace privé (mais je n’avais pas encore réfléchi à comment l’intégrer dans la partie publique)
La partie tables de Forms&tables fonctionne sur la même mécanique. Elle est juste séparée de la partie Forms car correspond a un usage différent. Pour définir une table, on définit ses champs à travers le formulaire de saisie.
Chaque champ peut être :
- spécifiant : il sera considéré comme pertinent pour trier/filtrer/rechercher les donnees dans la table
- public : les données de ce champ sont affichées dans les modèles, dans le cas contraire elle ne sont visibles que dans l’espace privé
- obligatoire : le champ doit être rempli lors de la saisie
Attention, ce ne sont pas des tables physiques, mais des tables logiques implémentées dans un nombre de tables physiques fixe. La question subsidiaire concerne plutot les perf, mais avec qq milliers de refs ca ne s’écroule pas. Et par contre la recherche est potentiellement efficace car tous les champs étants implémentés le champ valeur d’une même table, une recherche dans touts les données se résume à un SELECT ... WHERE valeur LIKE ’%mixeur%’ par exemple.
Aide contextuelle
Par ailleurs, une aide contextuelle peut être définie pour chaque champ. Le wrapping html permet de définir des encapsulation des champs dans la vue donnée (typiquement pour faire du microformat), sur le format :
- implicite : la donnee est insérée au milieu de l’encapsulation qui peut comporter plusieurs tags <div class='truc'></div>
- explicite : la donnee est inseree a la place du $1<a href='$1' class='truc'>$1</a>
Import/export aux formats csv et hCard
Le plugin contient un exemple de structure hCard (Snippets/forms/hCard.xml) qui utilise ce format. Mais la fonctionnalité est encore incomplète, il manque la possibilité de gérer une hiérarchie de div englobants. (Les fieldsets sont utilisés pour gérer un premier niveau de groupe, mais il est nécessaire de pouvoir faire des sous groupes, j’y refléchis).
Le hCard.xml contenu dans le plugin est importable à l’aide du plugin Snippets (1.9.2 uniquement) qui permet de gérer des imports/exports des structures des tables&formulaires en xml. Un formulaire peut etre exporté et réimporté dans un formulaire existant, auquel cas les champs y seront ajoutés.
Les types de champ sont personnalisables, il y a un exemple dans etc/forms_types_champs.xml. Cela permet de definir des formats qui n’ont pas de vocation à être en dur car ne ils correspondent pas a un besoin général. Pour le moment la vérification de format est limitée a un preg_match sur une regexp, mais je pense mettre un pipeline pour permettre de créer des types de champs plus complexe.
Le plugin csv_import fonctionne avec les tables de Forms&tables, et il permet de faire de l’import/export csv des données (en ajoût et mise à jour si l’id_donnee est fournie).
La différence entre une table et un formulaire
Une histoire de point de vue
reprise du post « forms et tables - formulaire multipage » du 16 juin 2007 sur la liste spip at rezo
C’est plus une question de point de vue.
Le formulaire a vocation à être utilisé pour collecter des données saisies par les internautes et les stocke pour permettre de les retrouver. Les tables ont plutôt vocation à créer des objets éditoriaux personnalisés gérés depuis l’espace privé et que l’on affiche dans le site soit via des
boucles, soit via des tags dans les articles de la formeou . Mais les fonctionnalités de l’un peuvent être utilisées sur l’autre. Si tu crée une table X tu peux donc mettre en ligne le formulaire de saisie correspondant avec un tag
pour permettre à l’internaute de proposer des infos par exemple.
La même explication traitée un peu différemment
reprise du post « API Forms&tables » du 15 février 2007 sur spip-zone at rezo
C’est juste un concept différent que j’ai distingué dans le plugin :
- un formulaire c’est dédié a la saisie de données dans l’espace publique (collecte d’informations), et on stocke les réponses pour pouvoir les suivre/gérer/traiter, comme des forums ...
- une table, c’est une structure de données destinées à être utilisées dans les squelettes. Le socle commun permet de disposer du formulaire de saisie associé, utilisable aussi bien dans l’espace privé que dans l’espace publique si besoin. La définition de la structure de la table se fait par la définition de son masque de saisie, ie son formulaire de saisie.Donc dans le premier cas, ce qui est central c’est la collecte d’informations dans l’espace publique, et le stockage est juste destiné à du post-traitement. Dans le second, ce qui est central, c’est les données et leur manipulation pour les afficher dans les pages de l’espace publique. La saisie est juste un moyen de créer/modifier des données, mais pas unique (l’import/export csv en est un autre)
Les tables sont ... des tables
reprise de ce fil de discussion http://listes.rezo.net/archives/spi...
27 janvier 2007 - <cedric.morin@yterium.com>
Les tables sont ... des tables, pour gérer des données que l’on définit comme on veut dans l’admin. C’est la même interface qui sert à définir les champs d’un formulaire et les champs d’une table. apparté Cedric : Par contre il ya des libellés pas explicites, meme en francais, et ca me plait pas non plus. Mais j’ai pas encore eu le temps de passer faire du nettoyage et de la mise en forme.
La structure des tables se définie dans l’espace privé, via l’interface de création. Chaque champs y est défini, avec un certain nombre de propriétés utilisées pour les boucles, les modèles, ... Cette structure peut se remplir par exemple via l’import d’un fichier csv par exemple), ou même directement dans l’espace privé, ou il est possible de faire de la saisie/edition des données, comme pour n’importe quel objet natif de SPIP.
Il y a une double boucle : une sur les données comme pour des articles par exemple, puis une sur les champs qui constituent ces données, la ou pour une table physique on utilise une balise par champ ... Voir le modele table du plugin par exemple... Aussi pour gèrer l’affichage, lorsque l’on rajoute un champ dans la structure il également modifier l’affichage pour qu’il s’affiche.
Exemples rapide mais concret d’utilisation
reprise de ce fil de discussion http://listes.rezo.net/archives/spi...
27 janvier 2007 - <cedric.morin@yterium.com>
Typiquement un annuaire d’associations, avec un mot clé pour le thème qui permet de sélectionner uniquement une partie, selon le thème de la page en cours :
- http://www.ville-noyon.fr/-Annuaire...
- http://www.ville-noyon.fr/Annuaire-...L’interêt évident est que la table n’est pas figée en dur, le webmestre peut ensuite ajouter/modifier/supprimer des champs dans la table sans avoir a toucher quoi que ce soit au squelette pour être pris en compte, ce qui n’est pas le cas avec une table physique définie lors de la conception du site. Et pour ma part, je n’ai jamais vu de cas ou la définition initiale était la bonne du premier coup, il y a toujours un truc qui ne va pas au moment de la finalisation, nécessitant une reprise du squelette. Sans parler de l’évolution du besoin avec le temps...
Un autre exemple, une table pour faire un trombinoscope, puisqu’on peut joindre des docs et des photos aux données comme avec les articles : http://www.saintsebastien.fr/-L-equ...
Ou une autre présentation d’un annuaire des assos : http://www.saintsebastien.fr/-Assoc...
Et ca ne sont que des exemples. Tu peux définir tout type de table, et même les types de données gérées par les tables sont d’ores et déjà extensibles (les types numéro de tel et code postal, par exemple, ne sont pas en dur car pas universels, mais définis dans un xml personalisable). L’API va être complétée pour permettre d’ajouter des types de champs plus complexes.
Mise en oeuvre
Les boucles
Les tables définies dans Forms&tables sont en fait toutes stockées dans les mêmes tables physiques. Dans les squelettes, on utilise les boucles
FORMS_DONNEES et FORMS_CHAMPS sur le mode :
<BOUCLE_reponses(FORMS_DONNEES){id_donnee}>
<BOUCLE_champs(FORMS_CHAMPS){id_form}{par rang}>
#TITRE : <span class='#_reponses:EDIT{#CHAMP}'>#LESVALEURS{','}</span>
</BOUCLE_champs>
</BOUCLE_reponses>Notez la balise EDIT qui permet d’utiliser les crayons sur les donnees de vos tables !
La balise #LESVALEURS permet d’eviter une boucle supplémentaire sur FORMS_DONNEES_CHAMPS. Dans cette derniere boucle, #VALEUR retourne non le champ sql brut mais la valeur en clair dans le cas ou il s’agit d’un champ mot clé, select ou multiple. #VALEUR* retourne elle le champ sql brut.
Sur la boucle FORMS_DONNEES
- le critere tout permet de récuperer les données non validées
- le critere statut=.. de récuperer les données non publiées (par défaut seules les données avec le statut publié sont retournées par la boucle)
- le critère id_mot=.. de récupérer toutes les données associées à un mot clé. Cela suppose que la table comporte au moins un champ de type mot clé.
Sur la boucle FORMS_CHAMPS
- par défaut seuls sont retournés les champs publics
- le critère tout permet de récupérer tous les champs
Allègement de l’écriture
Date : 17 avril 2007 11:06:50 GMT+02:00
À : spip-zone@rezo.net
Cc : spip-zone-commit@rezo.net
Objet : Rép : [Spip-zone-commit] r11357 - /_plugins_/_stable_/forms/forms_et_tables_1_9_1/public/forms_boucles.phple commit est parti trop vite, avant que je corrige le commentaire :
- (DONNEES) -> les données d’une table
- (TABLE_CHAMPS) -> les champs d’une table
- (DONNEE_CHAMPS) -> les valeur des champs pour une donnée (donc attention DONNEE au singulier, CHAMPS au pluriel)Voila ces nommages vont alleger l’écriture. Par ailleurs, le formulaire de recherche sur les tables applique un AND entre les conditions des champs (il faut que le champ 1 ait telle valeur
ET le champ 2 telle valeur). Mais, attention tout de même, sur les champs de type multiple, cela
reste un OU entre les valeurs du meme champ (champ 1 ait telle ou telle valeur ET champ 2 aie telle valeur)Pour étendre le formulaire de recherche à tous les types de champs(select,multiple, mot par defaut) il suffit de personnaliser formulaires/forms_recherche dans son dossier squelette)
Snippets, Csv_import,ecard
Snippets est autonome, forms&tables aussi, csv_import aussi mais snippets est utilisé par forms&tables pour ajouter des fonctions. Pareil pour csv_import qui ajoute des fonctions a forms&tables. Par contre ecard nécessite froms&tables, et c’est en ce sens un plugin de forms&tables et forms&tables a été pensé pour fournir une api a des plugins, donc il en aura d’autres ...
Un peu de documentation sur Snippets
En savoir plus
Voilà un petit apercu des fonctionnalités, cela mériterait évidemment une grosse doc que je n’ai pas du tout le temps de faire en ce moment , notamment sur l’utilisation avancée du plugin comme support pour d’autres plugins :
- créations de tables sur structure xml
- création d’un type de table supplémentaire pour gérer des tables qui ne soient pas mélangées avec celles du module tables par défaut
- utilisation de l’API d’interface liste/edition/modification ... des tables ....)
Mais le lecteur/codeur curieux pourra utilement se reporter aux plugins spip-sms-listes et spip_outliner pour en savoir plus !
Discussions par date d’activité
180 discussions
Question simple (je crois). Je veux simplement trier ma boucle donnees sur mes deux champs spécifiant. (nom et prénom)
Comment faire ? J’ai tenté sans résultat :
ou
Merci !
<tableX|recherche>dans un article et puis tes champs spécifiants doivent être des champs publics également.X correspondant au numéro de formulaire dont tu veux afficher les résultats.
Répondre à ce message
bonsoir, je désespère de mettre au point mon annuaire. J’étais emballée par tout ce que j’ai vu et lu sur le potentiel offert mais hélas je sèche sur la connection de ce plugin à ma rubrique.
je lis et relis ce carnet de note mais aucune explication « claire » ne vient m’épauler. La « mise en oeuvre » est trop technique (ou laconique) et je suis plus que néophyte...
Dois-je créer un squelette « annuaire.html » avec un lien dans ma rubrique (je ne pense pas c’est trop barbare pour spip.
qu’est-ce que l’id-donnee : le nom de ma table ?
où place-t-on ces boucles « forms_données » et « forms_champs » ; doit-on les créer ? j’ai lu le forum et j’ai cru trouver la solution mais hélas non...
Parallèlement, le formulaire fonctionne très bien ! Du moins ce que j’ai pu en tester et c’est super car j’en aurais besoin mais pour le moment j’aimerais que vous me donniez un ch’ti coup d’main. Merci.
Je suis très sincérement interréssé par les réponses à cette question : en effet je suis dans le même cas.
Je trouve que l’adaptation du plugin manque de precision.
Ce que je crois avoir compris :
Dans l’espace privé , il n’y a pas de probleme : tu as du pourvoir créer une table , installer un formulaire dans un article (<form1>...comme les images)...
Dans l’espace public, c’est plus difficile d’afficher les resultats d’une table : il faut effectivemment faire un squelette propre à ta rubrique (voir la doc SPip) dans lequel tu inclus la boucle proposée dans cet article (voir plus haut)
Tu disposes d’exemple egalement dans le repertoire « modele » livré avec le plugin.
Cependant (et la aussi je bloque) , la boucle proposée n’affiche rien !
si je remplace « id_donnee » par « id_donnee=1 » par contre la donnée « 1 » s’affiche !
je cherche de l’aide aussi.
merci
SPIP 1.9.2a [8878] + Version : 0.301
La boucle suivante te permet d’accéder à l’ensemble des réponses de la première personne qui a répondu à ton formulaire 2.
La boucle suivante te permet d’accéder à l’ensemble des réponses de la deuxième personne qui a répondu à ton formulaire 2.
La boucle suivante te permet d’afficher l’ensemble des réponses de l’auteur qui a un id=13. Pour voir l’id d’un auteur va dans la rubrique auteur ou connecte toi via phpmyadmin.
Voili voilou
Merci de ces précisions qui , j’en suis sur, servirons à beaucoup.
Ces trois boucles fonctionnent parfaitement.
Quelle est la boucle qui affichent toutes les reponses à mon formulaire ? (j’ai utilisé la boucle proposée dans cet articles mais c’est la seule qui ne renvoit rien du tout)
Affiche l’ensemble des réponses à un formulaire donné
La réponse a déjà été donné dans le post dans bas
Répondre à ce message
Pffh, avec la meilleure volonté, ce plugin est incompréhensible. Je vois bien comment créer une table, des champs... Et puis quoi ? Comment lier un champ à un champ déjà existant ? Comment intégrer tout ça dans un squelette en affichage simple ou avec possibilité d’ajouter un enregistrement ? Encapsuler le champ dans le code html, c’est quoi ? Les auteurs ont-ils accès aux tables ? Comment ?
En attendant des explications plus claires, je laisse tomber.
Et bien, une fois que l’on a créé une table, on l’affiche dans un squelette par une boucle habituelle.
Au plus simple, ça doit donner quelque chose comme (pour afficher la table 1 (id_form=...)) :
Attention, important : seuls les champs publics (définis comme tels dans la création de la table) seront affichés !
Bon, j’essaie encore...
Premier problème : lorsque je publie la donnée, j’ai un message d’erreur :
pour chaque champ. Mais la donnée est visible dans la partie privée.
Deuxième problème : dans la partie publique, j’ai juste
qui s’affiche quand je place la boucle que tu m’indiques...
On va y arriver. Je l’espère car l’outil semble extrêmement utile...
Pour ton deuxième problème, cela ressemble à des champs non publics (à vérifier).
L’autre solution, si _tous_ les champs sont publics est d’ajouter le critère
{tout}dans la boucle CHAMPS.Sinon, je ne suis pas un expert, et je n’ai pas le problème 1, donc...
Merci pour l’aide, mais ça ne marche toujours pas malgré que les champs soient tous publics... J’ai oublié de signalé que lorsque je valide un nouveau champ, l’interface déconne : l’ensemble de la partie privée se retrouve dupliquée à l’intérieur même de la zone de paramétrage. Pour info, je suis en 1.9.2
Je pose la meme question :
« Encapsuler le champ dans le code html » c’est quoi ?
Pour le reste pas de problemes sauf un, dans firefox je n’ai pas les fleches pour remonter ou descendre les parties du formulaire ?
Merci.
Même question ....
Répondre à ce message
Il y a une incompatibilité entre Forms & tables 1.9.1 et Tweak_spip.
A l’installation du plugin Tweak-spip, les formulaires ne sont plus affichés.
FDM
les plugins
- form&tables
- tweak
sont compatibles chez moi sous Spip 191 ! (maintenant il est possible que certaines fonctionnalité du tweak ne le soit pas)
voir en ligne :
Répondre à ce message
Bonjour, je trouve cet article très intéressant, et ai essayé de mettre en œuvre le plugin en question. Cependant, amha, il comporte - en terme d’ergonomie - un manque : il semble impossible de mettre sur la même ligne un champ avec son libellé. Le libellé est toujours au dessus du champ : cela limite pas mal les possiblités de présentation, notamment pour un formulaire un peu complexe.
Comment faire, donc, pour customizer cela ?
Autre remarque : sur la foi des lignes ci-dessus, j’ai installé le plugin jquery, puisqu’il est censé améliorer la gestion de la position des champs dans le formulaire, mais c’était une erreur. En effet, celui-ci m’a totalement planté le site !! (v.192 [8810]).
En tout cas, merci aux auteurs pour ce superbe boulot !!
Pour gerer la présentation des formulaires, il suffit de modifier la feuille de style forms.css et d’en mettre une version personalisée dans le dossier squelette (qui ne sera prise en compte que pour l’espace public cependant).
Si cela est absolument necessaire, le formulaire est généré à partir d’un squelette (dans formulaire/froms_structure), donc TOUT est personalisable.
Quand à jQuery, le plugin est nécessaire en SPIP 1.9.1, mais pas en 1.9.2 puisqu’il est intégré à SPIP. Les fonctionnalités permettent de modifier l’ordre des champs dans le formulaire, par glissé/déposé, ainsi que l’ordre des choix.
Malgré ces explications, je n’arrive pas à modifier le style de mon formulaire. Quand je change la couleur des styles “label” et “legend” par exemple, rien ne change. J’ai pourtant enregistrer mon fichier spip_forms.css dans le dossier squelettes.
Mon problème est que tous les titres sont en blanc par defaut, or le fond de mon site est blanc, donc rien ne s’affiche...
Pouvez-vous me dire comment dois-je procéder ?
Merci
Il faut travailler à partir du fichier spip_forms.css et penser à vider les caches pour visualiser les changements.
Répondre à ce message
Bonjour,
je cherche à savoir comment on peut utiliser l’option
Formulaires obligatoires pour la saisie de celui-ci :
J’ai un form1 et un form2 dans deux articles différents article 1 et article 4 par exemple.
Si je mets form1 dans cette option du form4, le formulaire de l’article 4 n’apparait plus.
D’autres tests ne sont pas concluants.
Même problème pour l’ption Encapsuler le champ dans le code html :
Aucun test n’est concluant.
Merci de vos éventuelles pistes.
Répondre à ce message
Bonsoir,
J’ai un soucis atypique. J’ai utilisé avec succès ce plug-in (merci et bravo !) pour implémenter une base de données gérée en admin et réutilisée sur le site.
En local (Wamp) tout se passe bien. Mais en production, les données n’apparaissent pas dans l’admin dans les champs si l’on veut éditer une entrée. Elles sont pourtant présentes puisque affichées dans le tableau de résumé juste avant.
J’ai essayé de tout supprimer, effacer la base pour en créer une nouvelle et réinstaller SPIP et rien de changé.
J’ai tenté l’installation sur mon hébergement « perso » (1&1) et là... tout va bien !
Le problème serait donc lié à l’hébergement... Quelqu’un a-t-il déjà eu ce problème ?
Quels sont les fichiers du plug-in qui gèrent le tableau de résumé et la génération du formulaire pré-remplis ensuite, pour voir si je peux changer quelque chose ?
Merci d’avance pour vos réponses
php 5 m’a fait ce pb chez 1&1
Je viens d’installer le dernier package mais hélas ! les données restent toujours invisibles lors de l’édition d’une donnée existante...
Quel est le fichier qui contrôle cet affichage ? Quelle différence avec celui qui affiche la table des données juste avant, pourrait provoquer ce manque ?
Répondre à ce message
Bonjour,
J’ai installé ce plugin il y a quelques jours et il m’est très utiles. Par contre j’aurais quelques questions , je l’ai installé en local et sur mon site et il y a des différences dans les 2 interfaces administrateurs : le paramétrage des champs du formulaire propose des options différentes alors je ne sais pas trop où ça coince , si c’est normal etc. Mais surtout, sur la partie publique de mon site (que ce soit en local ou sur le web), j’ai le bloc de texte qui dépasse de beaucoup par rapport au cadre de mon site. Comment faire pour réparer ce souci ? Est ce que je dois toucher à une feuille de style et si oui laquelle ou quel autre fichier dois je modifier ?
MErci d’avance.
Satindoll
Répondre à ce message
1&1 vienne de faire une MAJ de php vers 4.4.6
du coup site planté (je suis sous SPIP191)... j’ai réussit à remettre ça sur pied
mais l’insertion de formulaire n’est plus fonctionnelle avec ce plugin avec lequel je n’avais pas de soucis
quelqu’un as t il une piste ?
ce qui est étonnant c’est que ça fonctionne toujours dans la partie privée du site (ecrire) alors qu’il ne se passe rien en partie publique (meme pas <form1> affiché !
au secours
finalement ça devait etre la redirection du .hraccess vers php 5 que j’avais mis à la racine
Répondre à ce message
Bonjour,
Parce qu’il s’agit d’une évolution majeure de Spip, j’ai du mal à en imaginer toutes les utilisations possibles.
Pourrait-on par exemple utiliser les tables pour lier les articles à une autre application comme os-commerce ou zencart ?
Ou encore, c’est trés flou pour moi, utiliser les tables pour passer des paramètres à un modèle ?
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 :
|
