[RESOLU] création de tables et webform

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Submitted by sahuni on

Bonjour,
quand pour l'applicatif, on veut créer une table (pour enregistrer des inscriptions par exemple), on fait cela tout à fait normalement via mySql, dans la même base de données que drupal?

Forum : 
Développement
Version de Drupal : 
6.x

Soumis par davidm le 4 Février, 2009 - 10:55

Ta question n'est pas très précise, je pense que c'est pour ça que tu n'as pas eu de réponse jusque là...

Si tu cherches à enregistrer des inscriptions, tu as plusieurs options en fonction de quel type d'inscription tu veux gérer.

Le module Webform de Drupal te permet de créer facilement des formulaires liés à des tables de la base qui sont créés automatiquement pour toi. Les données soumises sont stockées dans la base et peuvent être envoyées aussi par email.

Si tu veux gérer des inscription en relation avec les évènements d'un calendrier par exemple, le module Signup est tout désigné.

Il faudrait plus d'info sur ce que tu souhaites faire pour t'orienter. Si tu avais besoin de stocker une base de données de produit par exempl, je te dirai le module CCK.

Soumis par sahuni le 4 Février, 2009 - 18:55

Merci pour cette réponse précise.
Je vais installer webform dès que possible. Donc pas besoin de créer de tables, fantastique.
J'étais partie de l'idée qu'il fallait passer obligatoirement par l'API form et ensuite faire des maj de tables liées au submit.
Apparemment il y a plus simple.

Je suis arrêtée pour le moment car j'ai voulu installer Easyphp 3.0 et tout ne se passe pas comme je veux. Comme j'ai encore des applications ASP que je maintiens j'ai IIS et Apache sous windows . Et j'ai beau avoir changé le httpd.conf avec un autre port, quand j'accède à easyphp en faisant un clique droit sur l'icone en bas à droite, il ne tient pas compte du port spécifique alors que si je rentre dans l'url l'adresse avec le port spécifique cela fonctionne. Donc qqch de pas net à ce niveau là, si quelqu'un a une solution, je ne crache pas dessus.

Soumis par sahuni le 10 Février, 2009 - 11:26

Bon,
j'ai installé webform, mais je ne sais pas comment m'y prendre.
Quelles sont les étapes à respecter pour l'utilisation du webform?
dans le menu contenu, il y a types de contenu et webform.
Je dois créer un nouveau type de contenu de type webform?
puis un contenu qui utilise ce type? mais au définitif, j'ai une page résultat et non un formulaire qui s'affiche ...

Soumis par davidm le 10 Février, 2009 - 11:44

Normalement WebForm installe automatiquement le type de contenu WebForm. Il te suffit de créer un nouveau formulaire. Attention bien sûr à bien paramétrer les droits d'accès avant, comme toujours ;)

La première partie du masque de saisie permet de définir les paramètres pour ce formulaire (titre, description, url ou message de confirmation, contrôle d'accès, adresse expéditeur, destinataire et sujet).

Une fois que tu as validé tu auras un message "The new webform ... has been created. Add new fields to your webform with the form below".

Et en dessous de ce message tu auras accès à l'interface te permettant de créer des champs. L’édition d’un champ de formulaire permet de définir, l’étiquette du champ, la valeur par défaut qui permet d’utiliser des tokens (variables remplacées dynamiquement).

Tu n'as pas défini de chemin pour ton formulaire ou noté son chemin d'accès lorsque tu l'as créé ? Tu peux toujours le retrouver via admin/content/node en faisant un tri par type -> webform

Soumis par sahuni le 10 Février, 2009 - 12:07

tu dis :
Il te suffit de créer un nouveau formulaire.
C'est à dire? créer un contenu qui utilise le type de contenu webform?
Si oui, c'est ce que j'ai fait. J'ai rajouté le champ "nom", à titre de test.

quand je fais modifier (en tant qu'administrateur), je peux remplir ces champs. Mais ce que je veux, c'est quand un utilisateur vient sur le site, il puisse remplir les champs du formulaire et l'envoyer. Hors quand il vient su la page, il n'y a pas de champs de formulaire, le bouton envoyer etc ...

quelque chose m'échappe.

Soumis par davidm le 10 Février, 2009 - 12:37

D'après ce que tu dis, comme je disai c'est un problème de permissions donc il faut que tu vérifies :

1) Edites ton formulaire et va voir du côté de "Webform access control" et vérifie que dans "Roles that can submit this webform" tu as bien coché "utilisateur anonyme" et/ou "utilisateur identifié"

Si ce n'est pas un problème à ce niveau là vérifie dans admin/user/permissions dans "module webform" les permissions :

access own webform submissions
access webform results
clear webform results
create webforms
edit own webform submissions
edit own webforms
edit webform submissions
edit webforms
use PHP for additional processing

Soumis par sahuni le 10 Février, 2009 - 15:54

J'ai vérifié tout cela et c'est OK.
Je ne comprends vraiment pas.
Je suis désappointée. Je suis à deux doigts d'arrêter Drupal et de refuser les mandats en attente. Ca fait 1 mois que j'essaie diverses choses et si on ne fait pas d'instinct l'action requise, c'est la galère.
Ca n'a plus rien à voir avec la logique et la programmation.
Pour webform par exemple, si ce qu'on fait d'instinct ne fonctionne pas, on ne trouve nulle part un tuto ou une marche à suivre.
J'y passe trop de temps, ce n'est par normal : je ne dois pas être faite pour ça...

Soumis par sahuni le 10 Février, 2009 - 17:08

j'ai essayé, mais la vidéo ne fonctionne pas chez moi. J'ai vu d'après les comments que je n'étais pas la seule. Quand je clique sur view or download, je vois qu'il y a un téléchargement qui se fait sur la barre en bas, mais rien de plus.
J'imagine qu'il s'agit d'un problème de configuration. Les vidéo de biboo.net passe très bien, mais pas ça.
.

Soumis par jptosi le 10 Février, 2009 - 18:01

Je viens de la re-télécharger depuis FF car je l'avais visionné à la maison.

C'est un .mov donc à visionner sans soucis avec VLC.

Jean-Pierre
Débutant Drupal

Soumis par sahuni le 10 Février, 2009 - 20:21

Bien,
j'ai réussi à voir cette vidéo.
Et j'ai réussi à trouver mon erreur.
En fait je pensais qu'il fallait créer différents types de contenus webform (1 pour chaque formulaire désiré) et du coup je rajoutais mes champs de formulaire au type de contenu et non au contenu. D'où le résultat indiqué.
On a besoin normalement que d'un seul type de contenu webform;
et c'est quand on crée le contenu, qu'on spécifie les éléments du formulaire. Il n'y a pas d'étape intermédaire. C'est tout simple.
Mais quand on est mal embarqué, on galère. J'avais un terrible coup de blues.
Je n'essaie rien d'autre ce soir, pour finir sur une note positive.
Merci pour l'aide des uns et des autres.

Soumis par nyl auster le 11 Février, 2009 - 09:11

Je ne connais pas le webform de drupal 6 mais si il est aussi bon et intuitif que celui du 5, maintenant c'est que du bonheur pour toi : cette gestion des formulaire est vraiment très bonne et simple à mettre en place ;-)

Le plus dur avec drupal c'est de sa familiariser avec tout ces concepts :
node
bloc
type de contenu
views
etc...

C'est comme une langue étrangère; mais une fois qu'on a compris tous les termes, tout va très très vite !
Bonne continuation avec drupal !

Soumis par davidm le 11 Février, 2009 - 09:51

Webform est vraiment très bien, mieux qu'eForm (modx) et même un poil mieux que l'excellent module FormAuto (typolight), même si c'est moins intuitif. C'est d'une simplicité remarquable.

Je dirai que le plus complexe à gérer avec Drupal c'est le nombre de modules (et de tables dans la base) qu'on fini par avoir même pour une install moyennement complexe... facilement plus de 100. Avoir un core léger et une appli modulaire, c'est très bien mais là on est sur de la modularité "atomique" !

Pour les termes types "noeud" et "vocabulaire" franchement je pense que pour les clients je vais faire du search and replace dans la traduction et changer pour "contenu" et "thématique", ainsi que d'autres termes.

Soumis par nyl auster le 11 Février, 2009 - 10:07

Salut
oui l'approche modulaire est parfois éreintante.
En même temps c'est vraiment la nature même de Drupal qui veut ça avec son système de hook qui permet de créer un module très rapidement pour modifier et overrider le comportement des modules du coeur (ou n'importe quel autre module d'ailleurs).
Du coup ça amène à "rajouter des couches" qui customise le coeur plutôt qu'à optimiser/agrandir le coeur lui même qui se veut une base de travail pour le framework.

Maintenant difficile aussi de reprocher ça sachant que c'est ce qui fait la souplesse et la force de son framework php, qui est le véritable maître d'oeuvre de tout cette histoire. C'est grâce à ce fonctionnement que je vais pouvoir tordre le CMS exactement comme je veux dans un temps records d'ici quelques semaines et c'est très appréciable comme approche !

Soumis par davidm le 11 Février, 2009 - 10:13

Je ne dis pas le contraire, je dis juste qu'en terme de maintenance et de gestion c'est un véritable jeu de Memory (parfois on se dit, mais quel module gère cette fonctionnalité, et comment je modifie le template... heureusement il y a le module Devel !)

Autre chose, on est un peu off topic mais bon, c'est que tous ces modules bouffent une mémoire hallucinante (memory limit est à 256Mo maintenant). Il suffit de voir le temps de chargement de admin/build/modules... même sur un dédié costaud !

Soumis par nyl auster le 11 Février, 2009 - 10:21

oui je comprends :-)
Franchement je passe mon temps à me perdre dans l'admin et à demander où je dois configurer tel truc. J'ai un projet sur Modx pour très bientôt et ça me faire une bouffée d'air salvatrice.
J'ai aussi un probleme de memroy_limit hier, mais vu qu'on est sur un mutu pour l'instant on est coincé sur ce paramètre.
Je ne sais pas pourquoi la page de module est aussi longue à charger car en théorie drupal ne charge que les fichiers .info dans cette page et pas les modules même (en tous cas sur drupal 5).

Je pense que pour profiter à fond Drupal il faut tatonner un peu de php sinon on perd clairement certains avantages.

Soumis par jptosi le 11 Février, 2009 - 11:30

Salut

J'avance sur Drupal mais à moins de ne pas avoir tout compris mais webform à pour moi un gros défaut par rapport à autoform, c'est qu'il enregistre tout dans une seule table alors qu'autoform te permet de créer une table par formulaire.

C'est pour moi un frein à l'utilisation de webform pour gerer une table mais

Par contre coté perf, vous me faite peur. La je suis sur un mutualisé et franchement, j'ai des doutes. J'ai limité à une dixaine de modules (cck et annexe, view, webform, imagecache, lightbox2, wisiwig, tynimce) et je desactive les truc du style admin menu, devel... quand je m'en sert pas

Maintenant est ce qu'en dehors des périodes ou je suis connecté en admin, les ressources sont moindre ?

Jean-Pierre
Débutant Drupal

Soumis par nyl auster le 11 Février, 2009 - 11:33

hello
Sur un 90 plan OVH j'ai un drupal qui tourne avec bien 80 modules + un joomla et ça passe.

Bon ça rame un peu quand même xD

De même ce site tourne sur un petit mutu tranquillou:
http://www.vst-freeware.com/

La seule fois où j'ai eu ce probleme de memory_limit, ça concernait uniquement l'admin et pas le site.

Après je ne suis pas capable de comparer par rapport aux autres CMS.

Soumis par davidm le 11 Février, 2009 - 11:49

Effectivement il faut nuancer, je parle de l'admin (j'ai 110 modules dont Organic Groups) parceque côté frontend, tu as le cache et le module Throttle et là tu ne dois pas avoir de souci. Sur un dédié tu peux faire tourner de gros site et tu as même la possibilité d'utiliser des accélérateurs comme MemCache.

Pour les tables de webform j'avoue que je n'avais pas regardé mais si ça n'impacte pas l'exploitation des résultats alors ça n'est pas important... surtout qu'on peut exporter sous Excel.

Soumis par jptosi le 11 Février, 2009 - 12:16

"Pour les tables de webform j'avoue que je n'avais pas regardé mais si ça n'impacte pas l'exploitation des résultats alors ça n'est pas important... surtout qu'on peut exporter sous Excel."

En fait tu vois webform comme une gestion de formulaire pour récupérer des données client (contact, survey ...)

Pour moi autoform me permet de gerer une mini application (à la place de catalogue quand je veux faire saisir les infos coté front end). Le client, saisi une info et elle est ensuite gerer par un module.

C'est vrai qu'il y a CCK mais de la meme façon, toutes les contents saisis sont dans la meme table. J'empiete sur http://drupalfr.org/node/5635 ou je vais poster le resultat de ma nuit blanche mais si je saisi 4.000 références client à travers un type de contenu "références" cela ne risque t'il pas de demander trops de ressource pour générer les pages du site toujours dans l'optique mutu.

Je me disais donc faire une table, alimenter par webform et attaqué par un module avec du code php.

Enfin, je vais poster sur le lien ci-dessus car j'a trouver des modules cck (nodereference, freelink ....) qui pourrat me permettre de faire de jolie chose.

Est ce que l'on dit considérer un sous module CCK (link, adress, image ...) comme un gros module ou juste un pett addon

Jean-Pierre
Débutant Drupal

Soumis par nyl auster le 11 Février, 2009 - 12:31

Je ne connais pas le nombre limites de nodes qui ferait ramer drupal (quand tu vois une adresse du genre node/5635 tu te dis qu'il doit y avoir de la marge ! ) mais une table bien conçue avec les bonnes requêtes, qu'elle contienne 10 ou 4000 entrées ne doit pas trop souffrir logiquement. Je pense que le danger c'est plus d'avoir beaucoup de modules sur une page faisant chacun des requetes sql. Les views me paraissent assez consommatrices, j'en mettrai pas 10 par pages vu leurs fonctionnement.

Le module CCK ajoute une table par type de contenu, c'est assez bien foutu et pas spécialement consommateur de mon point de vue mais je suis pas du tout un pro du sql.

Pour afficher un node, drupal doit joindre les tables :
- node
- node revisions
- node comment (si commentaires)
- cck_ton_type_de_contenu (si CCK, appelle tous tes champs custom relatif à ton type de contenu)

En gros tout ça se ramène en une requete SQL; après de toute façon passer par un CMS implique forcément plus de jointures de tables et de tables que du php maison.

En fait je vois pas en quoi ça gene de tout mettre dans la même table si tu peux trier comme tu veux et que tes requetes sont correctes, et que la table contient des clefs pour faciliter la vitesse d'éxécution sql.

Soumis par davidm le 11 Février, 2009 - 13:38

Intéressant si j'étais modo je ferai un split du sujet ceci dit !

Pour la charge en terme de requêtes, il y a un article à ce sujet sur le comment activer mysql query caching :
http://nadeausoftware.com/articles/2007/03/speed_drupal_web_site_enablin...

Il y a aussi une liste de module pour améliorer les perf ici :
http://drupal.org/node/97347

Vu les sites qui tournent sous Drupal, dont certains à fort traffic, je pense que ça doit se gérer...