Quick Signup via URL

I believe this patch does the trick. I created a new menu callback /signup/node, it expects the node id as an additional argument. By calling that URL the user will be signed up using his username as a name.

Attachment	Size
quick_signup.patch	2.17 KB

I've been looking for something similar. I'll give this a try!

Okay, I installed this patch. I created an event node with signups enabled. I tried to access either signup/node/[nid] (mentioned in the patch itself) and /signup/quick/[nid] (mentioned above) and both give me a Page Not Found. Am I doing something wrong?

Also, how are you going about creating the button that sends the argument for the NID?

Their are two possible problems. First to make it clear the URL is /signup/node/[nid]
So if you have a signup on node 20. Just put the URL /signup/node/20 as the URL.

Secondly, since the module was active, and it changes the static menu. You need to disable and re-enable the module. I did this on my production site. You will not lose any data. This should updade the menu information.

Thanks for working on a patch, it's nice to review a feature request accompanied by some code for a change. ;) That said, this patch has some problems, one of which is pretty large:

A) This patch assumes the site hasn't modified the signup form at all. You just hard-code Name and Phone. This is a huge problem, and probably might be reason to just kill the effort. What if the site adds 5 other required fields? You have no way to just guess/fill-in values for those. This requires a lot of thought if you want to see this feature go in. I really don't see a good solution to this, without making it much more complicated. For example, all of this would be a conditional feature that's disabled by default, and if the admin wants to enable it, they have to provide the values for all the signup questions on their site, with a few placeholders we could automatically provide like %username, etc. It'll make this patch much bigger, and at that point, I'm not sure the complication in the code is worth it for the convenience of these "1-click" signup links.

Perhaps it should just be put into a totally separate module (signup has some decent APIs exposed to let other modules manipulate signups, etc) that handles all this complexity. I don't personally have much need for this functionality, so I'd rather not have to support all this code indefinitely, port it to new versions of core, etc. To me, the point of signup.module is to get users to fill out a form of your choosing to indicate their reply to a specific event. These quick links are only useful on sites that basically don't ask any questions on the signup form.

B) The patch doesn't follow Drupal coding conventions (pay particular attention to spacing issues, especially after "if" and "//").

C) "Node does not have a open signup" isn't very clear for user-facing text. Generally, we avoid putting "node" in any UI text at all, for example. How about "Signups are closed for %title." ? Oh, and I'd split up the two parts of that if clause and treat them as separate errors for clarity ("Signups are disabled for %title" vs. "Signups are closed for %title")...

D) The handling of anonymous needs a lot of usability work. They click on this link and then are (seemingly at random) sent to the login page, instead? Seems whacky. You need to print out a message about what's going on here, or better yet, just print out a simple page with the "Login or register to sign up" link. Similarly, if they do have permission to do anonymous signups, the message isn't very clear, either.

E) I'm not so thrilled with the URLs for these quick links. Perhaps node/N/quick-signup or something might be better, instead of starting a whole new URL namespace tree under /signup?

Given all of that, I'm tempted to mark this "won't fix". (A) is really a killer. But, I'll leave this in "CNW" if you want to keep working at it and come up with a viable solution to (A), and then clean up the remaining problems. If you decide to go the route of your own module for this, feel free to post it here -- I'd be happy to give you feedback on implementation and design decisions with your code.

Cheers,
-Derek

Thanks for the feedback, really appreciate it. I had tried a simpler block for the Signups, but the fieldset for the signup data killed the idea. The other alternative was the URL based signup. My real use case for the quick link is using signup as a way to track registered users interest in some proposals. Not the event enrollment use. Having user dive into a node, then fill a form (on version 1.0 it was collapsed) just wasn’t flying.

I’ll start with the easy issues: sorry for (B) (eclipse should have done it right); agreed with (C), really is much cleaner; with regards to (E) I just didn’t want an additional tab on the node page (so I assumed that was an acceptable route, but your URL looks cleaner). Issue (D), that is anonymous users, brings in to mind the real big issue (A). I had observed, looking at the code, that modules could add new fields to the form. I wondered which modules where doing this.

So I have some questions, so we can work out the best way to work this out:

1) Is there a way to know additional fields are being added? If so this could mean that user supplied data is required, and we are kind of in the same place as with (D). One way to solve both (A) and (D) is to only allow quick signup for non modified signups, if you have more than the default options, we just say “In order to process your signup, please fill in the form below”, and show the node.

2) If we go to the placeholder route, where should the admin supply this information? I haven’t really looked into any module that adds fields, and this is the key point, to be able to add default to field, I need to know which fields exist and then ask the defaults somewhere.

3) If the “quick-signup” is disabled by default (fair enough for me), I should add some option on the node signup field to handle the un-disabling. Something like a checkbox with “enable quick signup URL” on the signup portion of the node. This is by far the easiest solution since admin take responsibility. I believe we there should be a message saying only basic information will be filled in.

4) The URL is currently hidden, that means no one sees it. I had considered adding a link to the teaser (using the link hook) to indicate that one can signup. Does this make sense?

Given what I know now, and staying in the patch route, I’d suggest the simplest solution would be:

Check if the signup form will have more then the default fields, for the user in question. If that is the case, show the node with a candid reminder that the user must fill in the form to signup. This takes cares of (A) and (D). If there is an easier way to know the added fields, I’d be happy to know. Second to avoid quick signup to things admin know will have additions fields, quick signup is disabled by default and admin can enable it on the signup configuration on the node edit form.

Is this an acceptable solution to these issues?

I know I'm probably just a bystander in this conversation. I jumped in out of interest for a quick sign-up button for authenticated users based on their username only.

Anyhow, I just wanted to say that I am very interested in this feature (in this module or not) and am willing to test to help out this effort. I am on Drupal 5.5 and PostgreSQL.

After a long absence I present a new patch. Still doesn't handle everything. But I want some input on who to proceed. I worked on items B,C,D,E. Still need help with A. I improved messages, fixed coding standards, URL space.

For anonymous users, I did the following. If the can signup, I added a message asking them to fill in the form. If they can't signup, I give them the login page, but give a message "Login or register to signup to %title".

The problem with issue A) is who to know if the form has been modified. I really need some help here.

I also moved it to 5.2-2.4.

Attachment	Size
quick_signup_24.patch	2.47 KB

I find this patch very useful. I have made just two small changes:

1) in order to address issue A raised by dww in #5 I added the following to INSTALL.txt:

"8. (Optional) You can give your users direct links for signing up to
a node, see http://drupal.org/node/208831. The URLs for that are
/node/[nid]/quick-signup. (If you have changed the signup form in the
optional step 2 above then you may need to also make a change in
the signup_quick_signup() function in signup.module.)"

2) I moved the menu callback out of the if (!empty($node->signup)) so that the feedback message is printed when the link is used on a node that is not available for signup.

Attachment	Size
quick_signup.patch	3.24 KB

Hmmm... Seems like something I've been looking for a while. Would it be possible to present the link in a table view as well? Possibly like "Sign up here" if the user is not signed up, and "Already signed up" if the user is alredy signed up for that node...?

Would be great ;-)

See http://drupal.org/node/229852

Roald

subscribing

subscribing

This item has been stopped for a while. I wonder if we shouldn't try to make it a module? I still think this could be part of the module.

A) This is plainly wrong and potentially a security hole:

Oh, I see later in the patch you're manually testing various permissions and trying to return a drupal_access_denied() where appropriate, but I'd rather the access was restricted directly via hook_menu() as much as possible.

B) The patch is full of code style errors.

C) This isn't doing what you expect:

That sets some PHP headers and sends some text, but it doesn't halt execution in the function you call it from. You mean:

Ditto drupal_access_denied() and drupal_goto() in that same function.

D) This text is wrong in general:

Thanks to #190553: Move signup form from fieldset to separate page the signup form might be on a separate page entirely.

E) I still think the usability of this feature is a mess once you customize the signup form. :( This doesn't exactly cut it:

HOW should you "make a change in the signup_quick_signup() function..."? What do you change? What do you change it to? I'll be the first to admit that the process for customizing the signup form totally sucks, but I've never had a chance to re-write that stuff. However, until that's done, adding a feature like this seems dangerous, especially without real documentation about it.

Overall, what I said in #5 mostly still holds, and hasn't been addressed by the latest patch. Please re-read those concerns. Please don't mark this RTBC until a patch appears that actually addresses all my concerns. ;)

Thanks,
-Derek

How can you cancel the signup? the link only confirms that you are still signed up, it does not give you the option to decline your signup.

Chris

subscribing...

+1

subscribing

Subscribing! (it offers an interesting future when using views!)
SaxxIng

Hi !
I have probably not understand all the posts above...
Does the patch work with the 6.x version ?

I want to display just a link to sign up events (with date module) : this patch makes this, doesn't it ?

Thanks !

Is anyone interested in contributing to funding this feature improvement to signup ->

http://drupal.org/node/551266

I will be contributing to fund it.

I just need a few more to help me out with it.

It will be for drupal 6.

cheers