Closed (won't fix)
Project:
Signup
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 Oct 2010 at 23:50 UTC
Updated:
7 May 2011 at 19:02 UTC
Jump to comment: Most recent file
Comments
Comment #1
fax8 commentedsubscribing. looking for some time for testing this one..
Comment #2
macdee commentedI forgot to mention that this patch also expands the number of supported webform field types and also recognizes fields within fieldsets, but ONLY if you are using Webform 6.x-3 and above**.
**There has been no change made to the limited field type behavior for anyone using versions of Webform prior to 6.x-3, nor is there any intention to do so. That part of the code was only included to maintain the status quo for legacy users.
Comment #3
netv commentedWow very cool, and EXACTLY what I'm looking for right now.
But... don't actually know how to use it and what to do exactly?
Could you please write a real short tutorial, step-by-step what to do?
Where can I find the signup_webform module??
I have signup and webform installed, and attached a node-reference field to the signup-content where I can select a webform, right?
What file(s) do I need to patch? Do I need something else? How do I apply the functionality? Do I need something in template.php?
Comment #4
macdee commented@Gevatter Tod You should read http://drupal.org/node/29568 to see the long history behind this.
The short answer is that you need to follow the "View all releases" link from the Signup main project page and apply this patch against the signup 6.x-2.x-dev branch. Once you've tested the functionality please report back here.
David
Comment #5
netv commentedThanx David,
After I've applied the patch I get the following Error message when trying to call the node for signup:
Fatal error: Call to undefined function drupal_get_installed_schema_version() in /var/www/virtual/XXXXX.de/htdocs/XXXXX/sites/all/modules/signup/modules/signup_webform/signup_webform.module on line 68
Comment #6
macdee commentedIt's a standard Drupal function that's been around forever (see http://api.drupal.org/api/function/drupal_get_installed_schema_version) so I doubt it's mia... did you flush your caches and run update.php after applying the patch? I'm thinking that your site thinks it's still using the old version of the module.
If that fails, try unloading and reloading the module.
Comment #7
netv commentedHm... Yes, I tried flushing the cache before and called up update.php.
Right now I even deinstalled everything from the signup module and installed it again.
Everytime I try to configure the signup settings for a node it's the same error-message above...
by the way, I did't have the error before applying the patch ...but then fileuploads did't work.
Comment #8
fax8 commentedare you sure that you are running Drupal 6.x?
Comment #9
netv commentedwell... yeah... I AM pretty shure, thanx.
6.19, and newest webform module, too.
Comment #10
macdee commented@ Gevatter Tod Thanks, I was able to reproduce the error using a fresh install.
Until I figure out why this is happening and can roll a new patch, just manually change line 68 to "return TRUE;" instead of what is currently written there and you should be able to continue with testing.
David
Comment #11
netv commentedOk, many thanx! It works.
Here's a little bug:
If I go to "Edit webform components" from the signup, then I can select which field to add... if I submit it jumps right back to the signup-configuration page instead of adding a field and going on to the configuration of that field.
Filefields don't work either, do they? Simply nothing happens there, when I add a local file and submit the form. Form is submitted but no file is stored or sent.
If I combine several forms in one signup, the data is stored seperatly in every webform-results-table? So I can't see all Submissions of a combined signup and export them right?
If I use one form in multiple different signup nodes, all results run together in the same webform results?
Comment #12
macdee commented@ Gevatter Tod:
#5 I fixed the problem with the error message you were getting... it seems that you have to make sure the installation API is already available before calling drupal_get_installed_schema_version(). Learn something new everyday!
#11a I've also addressed your concern with the "add field" but you'll now have to navigate back to the signup-configuration page manually after editing webform components.
#11b I see what you say about file uploads, I'll have to look deeper into that when I have time.
#11c Since everything to do with webforms is stored by webforms itself you get your results the webform way. If you want to combine multiple webform results I suggest using views and the csv exporter in the views bonus pack.
I've attached a new patch (use the patch in #16, not this one) against 6.x-2.x-dev that includes fixes for #5 and #11a
Comment #13
netv commentedThanx macdee, good job anyway!
I also had the idea with views and the bonus pack, but the problem with using the same webform for different nodes still applies then... I can't figure out which entry is for which node... maybe with a "referer"-field...
According to the module itself: Would't it work fine if a copy of the chosen webform is generated (changing the name in "[webformname] - [node-title of signup-node]" evertime a webform is assigned to a node-signup?
Next Idea: Instead of the "Informations" for each signup in the signups overview then there could be a link to the webform result instead.
Just some ideas, and pretty much influenced about my current projekt issue ;-)
But anyway, this would be an awesome solution for signups.
Comment #14
macdee commented@ Gevatter Tod #13:
I don't think that making copies of webforms programmatically would be useful. Not only would it really upset the webform module, but even making local copies kind of defeats the purpose of using webform's native storage.
Keep in mind that all the information you need is available in signup's db tables so you should be able to create a views relationship that takes those factors into account and display whatever you want to see.
Comment #15
macdee commentedIgnore this... I was tired and used the wrong file.
Comment #16
macdee commentedRevised patch with some minor bug fixes. Use this instead of the one in #12
Comment #17
macdee commentedMore tweaks. All standard webform 3 field types work as expected except for file, which unfortunately gets flushed during the submission process.
Comment #18
joachim commentedPlease don't include Id changes in patches; CVS takes care of this.
Ditto. You should be working from a CVS checkout and these lines should be absent from it anyway.
Don't make unrelated changes please.
... or alter whitespace ;)
I don't see where this is called from or how it's used, but I don't see the point of it. Webform 3 is now the only supported version -- all we need to do is say in the documentation and the project page that you need Webform 3. End of story. At a push, we can stick a hook_requirements(), if we're really feeling nice.
This patch has now exceeded its kitten allowance. Could you tidy up and I'll try to find time to review it again?
Powered by Dreditor.
PS. Also, WTF?
You're testing for truth and THEN on the back of that returning TRUE or FALSE? You already have that!!!
Comment #19
macdee commented@joachim: Stripped out all the older webform stuff so this is strictly webform 3 (which also eliminates the need for the WTF line... yeah, yeah, I guess it was a little redundant :))
Rolled against -6--2 as per request.
edit** Sigh... looks like some of the preamble leaked into this one. Please use the patch in #20 instead. (I wish I could alter my own file attachments when editing so I didn't have to keep adding comments).
Comment #20
macdee commentedPlease use this instead of the patch in #19.
Comment #21
macdee commentedMinor revision to reduce size.
Comment #22
macdee commentedwith an implementation of hook_signup_update for multiple webforms in the same signup.
Comment #23
joachim commentedYou're still making a load of spurious changes to whitespace.
Given that pane ids are machine names, I doubt we need unicode support in dealing with them.
Comment and code do not agree.
What's this for? Is it cribbed from similar behaviour in webform?
Do we really have to do all this? Does webform not have a function we can call? If not, and it does everything in the submit handler, then maybe consider submitting a patch to it?
What are you doing for the form_data hook?
This too.
Call to t() is missing the token.
Move this so it's immediately after the form builder.
Are those more than 80 cols wide?
Also, nitpick, but it's 'an SQL', not 'a SQL'. ;)
Also, by 'a new webform added', do you mean created as a node, or added to the signup system? If the latter, then we should be able to act on its addition and fix our data. Suppressing errors doesn't seem like a good thing to me.
Powered by Dreditor.
Comment #24
macdee commented@joachim: Sorry, these were not meant as "spurious" changes to whitespace. I merely addressed whitespace and formatting issues in the original that Coder was complaining about. Ditto with the string functions. I tried to revert as much as I could find back to what you previously had just to cheer you up.
You're right, the cookie and email parts are most likely superfluous and I may be able to offload those items back to webform. I just haven't had the need to re-visit that part because I'm not using that functionality on my test site. I will take a deeper look when I can.
The form_data_display_alter function: This is probably no longer doing anything useful... it's just what was left of the original routine you wrote after I removed webform 2 specific references and changed the includes. I haven't removed it completely yet because I was unsure of any negative impact without checking further. A corresponding webform submission is always created, even if all the fields are left blank. Components are themed by webform.
The hook_nodeapi: I chose not to delete associated webform submissions when deleting the signup because there's the strong possibility that somebody might want to use the collected data from within webform for other purposes and it seemed presumptuous to unilaterally remove that data. If the time comes that the user wishes to deep six them then that can be accomplished via webform's own interface.
Other points taken.
As for the nitpick, I guess it's all in how you pronounce it. I pronounce it as 'sequel' not as individual letters.
I will see what I can fix, but it may take awhile until I have time.
Comment #25
joachim commented> I merely addressed whitespace and formatting issues in the original that Coder was complaining about. Ditto with the string functions. I tried to revert as much as I could find back to what you previously had just to cheer you up.
Please read up about how best to make patches -- in particular, search for webchick's blog post about patches and kittens. In brief: a patch should address ONE thing only.
> As for the nitpick, I guess it's all in how you pronounce it. I pronounce it as 'sequel' not as individual letters.
Indeed, but Wikipedia seems to say the standard pronunciation is as initials ;)
Comment #26
joshuarr commentedsub
Comment #27
peterm95018 commentedAny movement on this issue? I could use some webform v3 compatibility with signup 6.x-2.x-dev.
Comment #28
joachim commentedPatch needs work -- it's up to someone with the time to work on it.
Comment #29
schackattack commentedsubscribing
Comment #30
MathFreak.be commentedHi
I installed signup and signup webform from the following location: https://github.com/joachim-n/signup which contains a singup_webform.module file form march 3, 2010.
I am a bit confused on which patch if any I should be using. Right now it isn't working, when I try to go to a page that has a signup with a webform, I get this message:
Fatal error: Call to undefined function webform_load_components() in C:\xampp\htdocs\drupal_6_2\sites\all\modules\joachim-n-signup-226fc7e\modules\signup_webform\signup_webform.module on line 124
Help appreciated
Comment #31
robotjox commentedsubscribe
Comment #32
meichr commentedHi,
I'm interested in the signup_webform integration module including any patch necessary for adapting it to the most up-to-date version of webform (and signup) under Drupal 6. Maybe, it could also be useful for the signup rules integration module I'm working on (still a sandbox project).
Is there a reason that the signup_webform module is not available on drupal.org as a project? Now, that drupal.org has moved from cvs to git, I mean. Are there plans for an official module?
Thanks for any info,
Christian.
Comment #33
macdee commented@meichr:
Christian,
The signup_webform module that you see here relies on specific features only found in the 6.x-2x-dev version of signup and last I heard 6.x-2x-dev is not in sync with the current dev version of signup and may never be, thus it won't work as a separate standalone module/project.
I did do some further work that improves upon the parsing of the webform elements over the latest patch above but I also discovered that file uploads within a webform and multi-page webforms do not seem to be compatible with the way the forms get rendered in 6.x-2x-dev so I put aside creating any more patches until I could come up with a solution that would also include those capabilities. Then 6.x-2x-dev seemed to go off the rails so I was waiting for the dust to settle to see if it was worth proceeding down this path.
I have strongly considered a complete rewrite so that it doesn't depend on 6.x-2 and would be a complete standalone but haven't pursued it.
David
Comment #34
ajzz commentedThis module has great potential. The current reason why we are not using SignUp for events is because more than three fields of information are typically requested from people attending events. A signup_webforms module will be great by allowing the flexibility of webforms with the convenience of reminders etc.
+1 vote for a project
Comment #35
MasterChief commentedInteresting idea, i am agree with macdee, a separate module will be better and compatible with 6.x-1-x.dev of signup will be great :)
Comment #36
scottrigbyJust to be practical with respect to branching (1.x not 2.x), but also to go ahead & test even before commit, I'm re-rolling this patch against another patch here #1148552: Sync 6.x-2.x with 1.x/master. Reasons explained in #1 of that issue.
I made the following changes to this patch:
* replaced pane_id drupal_substr() instances with substr()
* changed sid comment to pane_id
* removed cookie stuff
* fixed missing token in t()
* moved signup_webform_form_validate() just below signup_webform_form()
* wrapped comments in signup_webform_get_signup_submission at 80 columns with //
* followed wikipedia about SQL pronunciation just for fun (a to an)
* I left the whitespace cleanup, because - why not.
@joachim I don't have answers to some of the other questions you raised about macdee's last patch. However, unless there's a solution, this is better to get working insist on perfection at this point. Maybe we'll even get this all in the 6.x-1.x version of Signup. That's be pretty sweet wouldn't it?
Comment #37
scottrigbyTypo in above patch. Also, fix the t() token to read as it should.
Comment #38
ezra-g commentedmarking this as won't fix per #1148552: Sync 6.x-2.x with 1.x/master -It would be great to see this functionality made available as a separate project, and I'd be happy to improve the Signup API if necessary to help make this possible.