It would be great to have the option of moving the signup form from the fieldset at the bottom to an entirely separate page. I have event nodes with big long descriptions, and a signup form that requires a ton of information, and basically the page is too long. Am I right in thinking this isn't currently possible?

I'd be happy to sponsor this feature, or hack at it myself if someone would give me a push in the right direction. Thanks!

CommentFileSizeAuthor
#5 signup_tab.patch_1.txt17.67 KBdww
#3 signup_tab.patch.txt14.36 KBdww

Comments

dww’s picture

Assigned: Unassigned » dww

ksenzee offered to sponsor my time to work on this, so i'll be implementing this in the nearish future...

a few ideas on how it should work:

I'll add a new global setting to the admin/settings/signup page:

Location of the signup form and related information:
(x) At the bottom of each post
( ) On a separate "Sign up" tab

If the above setting is configured to use the separate tab, when viewing a signup-enabled node, you'll get a new "Sign up" menu tab at node/N/signup. This means that anyone with permission to signup will now get both the "Sign up" and "View" tabs on all signup-enabled nodes -- hope that's ok. ;)

This new tab will basically include everything that's currently injected into the main node -- either the signup form if the current user isn't signed up, or their signup details (and, if they have the right perms, the signup info of the other folks who signed up for that node, etc).

I've got a few open questions, mostly for ksenzee since she's paying for this, but if other signup users care to comment, I'll take your opinions into consideration, too. ;)

A) Is a global switch flexible enough? Does anyone see the need to make this option per content-type, not just site-wide? Seems like the big motivation for this feature is if you have a really long signup form (which must be site-wide given how the signup form currently works), you might want to put it on a different page. That makes me think a global option makes the most sense (at least until the signup form is more flexible for each node type).

B) People with administer signups (either global, or for their own content) will also see a "Signups" tab at node/N/signups. Is that too confusing with node/N/signup vs. node/N/signups? Any suggestions on what to do about it?

C) Should there be a 3rd option to put the signup form/details in a block?

Input welcome...

Thanks,
-Derek

ksenzee’s picture

This means that anyone with permission to signup will now get both the "Sign up" and "View" tabs on all signup-enabled nodes -- hope that's ok. ;)

This is how I envisioned it working too, so it's fine with me. :)

A) Is a global switch flexible enough?

For me it's flexible enough. I'll probably use this lovely messy hack to get different form fields on different events, and I can see where someone else that was doing this would want more flexibility. But for me a global switch is great.

B) People with administer signups (either global, or for their own content) will also see a "Signups" tab at node/N/signups.

I only have one user with signups admin rights, and she can deal. :) Seriously, the difference between "sign up" and "signups" seems clear enough. The only possible improvement I can think of would be to change "signups" to "view signups," but frankly I'd rather keep it as is. The word "view" is already a bit confusing on a site with views installed.

C) Should there be a 3rd option to put the signup form/details in a block?

I don't need this personally, but I like the idea.

Another pie-in-the-sky thing -- which I don't even think is possible in D5 -- is that it would be nice to have some convenient way to alias signup forms. If my event title is "events/november-meetup", I'll want the signup form to live at "events/november-meetup/register". The only way I can see to do that right now is to create the alias manually at /admin/build/path/add. Since this site has about an event a month, that's fine with me, but it would be nice if I didn't have to.

Thanks!
Katherine

dww’s picture

Status: Active » Needs review
StatusFileSize
new14.36 KB

Initial implementation. Seems to work on a local site given light testing, but I'd appreciate other tests, reviews, feedback on the UI, help text, etc.

Thanks,
-Derek

p.s. Unfortunately, this conflicts a lot with http://drupal.org/node/79331#comment-437537 which I'd really like to fix in the next release. :( So, I'm going to have to spend some extra time making these play nicely together, but I wanted to at least post my initial effort.

ksenzee’s picture

It worked perfectly in my testing. Thanks for the lightning-fast response. One UI request: Is it possible to pull the form fields out of their fieldset when they appear on the signup tab? The fieldset seems a bit superfluous when the form is the only thing on the page.

dww’s picture

StatusFileSize
new17.67 KB

Good idea. New patch with the following:
- If the signup form is on a separate tab, no fieldset.
- Fixed descriptions of the advanced settings about this.
- Fixed typo in the previous patch for the setting ('On a separate %sign_up tag' -- should be tab).
- Added more doxygen about the various functions involved in all of this.
- Added a CHANGELOG.txt entry for the feature.

Let me know if there's anything else.

Thanks,
-Derek

ksenzee’s picture

I swear it takes me longer to apply the patches than it takes dww to write the code.

Yes, this looks fabulous. Is it rude to mark someone else's code RTBC in their own issue queue??

dww’s picture

Status: Needs review » Fixed

Hehe, thanks. ;) No, it's not rude at all. That's the point of the queue. I write it. You test it. You say it's RTBC. I commit it. ;)

But anyway, this seems to be ready, so I just committed to HEAD. It'll show up in the next official release whenever that's ready (there are some other things I want to include before then, so I'm not going to roll a release just for this). Meanwhile, you should see it in the 5.x-2.x-dev snapshot in the next few hours (whenever the packaging script next runs).

Cheers,
-Derek

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.