missing list of signup users inside node

As a new user I also thought it was a shame I couldn't seem to be able to do this and from reading around it did appear that it was possible in old versions.

For bike races my users will be more willing to sign up if they can instantly see their mates have already signed up.

Yeah, I guess I was a little hasty in my decision to nuke that listing from the node itself over at #349292: Reorganize signup node tabs. I could add another advanced setting to control if this should be embedded in the node like it used to be, or on a separate node/N/signups/list tab like it is now. This isn't as high prio for me as #51226: allow users to edit their own signup but I'll work on this once that's in.

Excellent. Look forward to it when you have time.

Attached patch does the following:

A) Adds 2 more options to the "How to display the list of signed-up users:" setting for a total of 5 choices:

(*) Use the built-in listing at the bottom of each node
( ) Use the built-in listing under the Signups tab
( ) Embed a view at the bottom of each node
( ) Embed a view under the Signups tab
( ) Do not display a listing at all

(See attached screenshot)

B) In nodeapi('view'), if the user list is included in the node, it's now in a separate entry in the $node->content array.

C) The info about the "signup" and "signup_list" sections of the content array are exported separately to hook_content_extra_fields(), so you can control their weights independently. This lets you drag/drop the user list above the signup form, for example. I also fixed it so that each section only appears if the global settings indicate that section should be included directly on the node. There's still a fallback variable (no UI, but you can put it in settings.php) to control the weights per content type if you don't have CCK.

D) If you save the signup settings page now, it automatically rebuilds the menu, since so many of those settings can impact the menu tree and it's unreasonable to expect admins will clear the cache manually or otherwise rebuild the menu.

E) Fixed the jQuery for admin/settings/signup so that the "View to embed for the signup user list:" setting appears if either of the "Embed a view ..." options is selected.

I've tested pretty heavily, and it all appears to be working correctly.

I had considered splitting up the "where" and the "how" parts into separate settings, something like:

Location of the list of signed-up users:
(*) At the bottom of each node
( ) Under the Signups tab
( ) Do not display a listing at all

How to display the list of signed-up users:
(*) Use the built-in listing
( ) Embed a view

However, that would have required (much) more complicated JS to hide/reveal everything as necessary, and a DB update to migrate people's configuration to the new settings, since the existing saved value of 'signup_display_signup_user_list' wouldn't mean anything anymore. Overall, that seemed more complicated, so I got this working via a single setting that gives you all the options at one glance. This is an "advanced" setting after all, so I'm not that worried about giving something with too many choices. But, if folks really think this is too confusing as-is, I'd be willing to look into splitting it into two settings...

There was a minor bug in the initialization of the js-hide class on the "View to embed for the signup user list:" setting, such that if you had "How to display the list of signed-up users" saved as "Embed a view under the Signups tab", when you first loaded the settings page, the "View to embed..." setting was hidden. Now fixed.

Two fixes since the last patch:

1) "... at the bottom of each node" is misleading, since it's really up to you to control where it is based on weights or the CCK drag+drop UI. So, the 5 options for the setting now look like this:

(*) Use the built-in listing on each node
( ) Use the built-in listing under the Signups tab
( ) Embed a view on each node
( ) Embed a view under the Signups tab
( ) Do not display a listing at all

I'm not thrilled with the wording yet, but it's better.

2) If CCK is enabled, there was a bug where the first time you changed one of the settings about where things should appear, and/or the first time you tried to view a node after applying the patch, the weights wouldn't be initialized properly, and the signup user list would show up at the top of the node, not near the bottom like it's supposed to by default. If you reload the page, it starts working again. I tracked this down to a bug in CCK: #363456: content_extra_field_weight() gives bogus answer when cache needs refreshing ;) There are 3 possible solutions here:

2a) If CCK is enabled, add a call to content_clear_type_cache() after we save the advanced settings, so that the per-type weights for where the signup info should be displayed will be reset. This works whenever you save the settings, but it doesn't work on the very first page load for each signup-enabled node type after you install the patch (or, upgrade to RC4). Patch attached (361446_signup_user_list_settings.6a.patch).

2b) When we call content_extra_field_weight() in signup_nodeapi('view'), always call it twice. This is sort of stupid, but it works, since the CCK bug is that the first time you call that function when the cache is empty, it returns NULL instead of computing the right value and returning that. So, this bloats the code a bit, but it works in all cases, even if you just upgrade but don't visit the settings page. See 361446_signup_user_list_settings.6b.patch.

2c) Patch CCK to fix the bug. ;) Then, we don't need either of these bloaty work-arounds in here. See 361446_signup_user_list_settings.6c.patch and http://drupal.org/files/issues/363456_content_extra_field_weight.1.patch from #363456-1: content_extra_field_weight() gives bogus answer when cache needs refreshing.

I think I prefer "signup-provided" over "built-in" in those option choices. But, I'm not going to re-roll all 3 patches, I'll just wait until we figure out which work-around for CCK to use and change the wording before I commit.

Ok, talking it through with deviantintegral in IRC, I convinced myself that #6.2B is the best approach for now (just call content_extra_field_weight() twice). Once CCK is fixed and there's a new official release, we can easily remove the two extra calls, but at least this will always work, and doesn't require patching CCK or running -dev, etc.

Also changed the settings to "signup-provided":

(*) Use the signup-provided listing on each node
( ) Use the signup-provided listing under the Signups tab
( ) Embed a view on each node
( ) Embed a view under the Signups tab
( ) Do not display a listing at all

Committed #8 to HEAD and D6--1.