Configurable 'closed' messages

I just downloaded the current dev release and found some changes since I added this issue. I also found this issue (#815446: Better IA for closed events) that was since opened. It's added a solution that comes close to resolving this issue in that it shortens the button text.

However, putting text below the disabled button might not work with some designs. The message can be hidden with CSS, but then you would be left with a disabled button and no indication to the user why the button is disabled.

So I have included a patch that will allow you to change the text in the admin settings on the 'Add to cart' button for closed events.

This leaves the closed message that was added in the other issue alone, and it can be hidden with CSS as follows:

.add-to-cart .uc_signup_closed_message {
 display:none;
}

This patch also updates the $form['uc_signup']['uc_signup_signups_closed_text'] description to accurately reflect the #815446 changes so it no longer says its text is displayed on the button.

I also noticed while I was testing that if the user doesn't leaves the configurable add to cart text empty (to use the default "Add to cart"), it bypasses all the checks to disable the button. This patch corrects that.

One thing I found confusing was the logic on the closed messages. You have useful information available for users as to why the events are closed (full or passed). But once the cron switches those events over to closed, that useful information goes away and is replaced by generic "Signups are closed for this event".

The problem with that is not only that users lose the useful information, but also that in the time between when an event's signups closed based on time and when the cron hits it to close the event, the more detailed message is still displayed. That can cause those once useful messages to now become confusing, because now some past events "We're sorry, but the @type %title has already passed" while some past events say "Signups are closed for this event." That could be confusing to a site user.

I think there was a valid concern that you addressed in comment 15 of #815446, but you also took away good functionality that you originally had. I think this is a more effective way of implementing that, which uses tokens and 3 user defined closed messages.

I ended up with a git error when I tried to make the patch. So hopefully this is against the current version.

Last night I realized that with Tokens implemented, I could now include the system default text in the configuration text inputs. That allows for using the default closed text on full and passed events when those inputs are left empty.

I think that's a slightly better way to go. So this patch makes that change.