Don't list full menu on signup page.

After much discussion with Tony and tmarble, we've concluded not to put
the menu on the initial page, and instead place it on the thank-you
page, to which PayPal payers are redirected.

Close paren (HT tmarble)

<tmarble> (likely vegetarian needs closing paren [16:17]

Remove (aka Bruxelles) (per tmarble)

<tmarble> (aka Bruxelles) is not required [16:16]
<bkuhn> tmarble: removed
<bkuhn> I put it in only because people might not know.
<bkuhn> (I didn't the first year I attended)

Add supporter night button.

Thanks to Tony for making it.

No banner done for this one:

<bkuhn> tony: also, do you want a banner, ala
http://sfconservancy.org/img/conservancy-supporter-header.png ?
[16:09]
<tony> nah, this is such a short term thing. I don't think it's necessary

First pass at Supporter Night form.

This is my first pass of the supporter night form with necessary
Javascript and CSS.

Annual Supporter RSVP for FOSDEM 2015 event.

Annual supporters can RSVP for the FOSDEM 2015 event.

FY 2013 Form 990, CHAR 500, and Auditor's report.

These filings were taken care of by the 2015-01-15 deadline and are
herein presented publicly.

Ordering likely screwed up when I muck with query.

Force order_by at the end of my mucking.

Use only on0/os0/on1/os1 options with PayPal.

According to these URLs:
https://www.paypal.com/cgi-bin/webscr?cmd=p/xcl/rec/options-help-outside
https://developer.paypal.com/webapps/developer/docs/classic/paypal-payments-standard/integration-guide/Appx_websitestandard_htmlvariables/

only two Options are supported via PayPal. I was fooled initially
because other fields *did* come through and *did* show up on the web
interface, but they are *not* accessible via the SOAP interface.

Therefore, I've switched to using the hack described here:
https://ppmts.custhelp.com/app/answers/detail/a_id/298/kw/soap%20gettransactiondetails%20option

to get 4 fields of data for Supporter transactions.

Wording changes and typo fixes for Supporters.

Update information about who can become a Supporter (small companies
can, too), and make sure they're called "Conservancy Supporters"
throughout.

Place Supporters counter on front & sponsors pages

The number of current supporters now appears on the frontpage and the
sponsors page.

Support anonymous supporter listings by count.

Remove anonymous listing from the alphabetical supporters list and
instead list them by count found.

Supporters list built dynamically.

Hitherto the supporters list has been committed directly to the static
sponsors/index.html file. This was never ideal and a quick hack to
build Conservancy's supporters list at the beginning of the supporters
program.

With this change, a Django app now exists that dynamically generates the
supporters list.

The database rows must be built from Conservancy's internal Ledger file,
which will be done in a separate script.

Rename file to template.

Since we'll produce dynamic content onto this page going forward, this
apparently needs to be in the templates directory now.

For now, ignore .webm files in static/videos/

We're going to host some videos on the site and we'll just copy them to
the server rather than keep them in the Git repository.

Update public ack for last week and a half.

There needs be to an automated process for this, but there's none yet.

Correct total for proper amount of 2-to-1 match.

The original total was miscalculated. Some of the donations weren't
properly counted as 2-to-1.

progressbar Javascript need not change for content

The content of the amounts for the fundraiser can be kept in the HTML
rather than the progress bar Javscript code.

I suspect at some point I should keep this data in the Django database
and extract it from there as dynamic content.

Note that possible fix the sidebar scroll.

Sidebar currently gets bottom cut off when your browser height is too
small. This URL seems to indicate a fix. I don't have time to do it
now, but wanted to save it as a note to do later.

Shorten text in bar so it scrolls better.

The text in the bar was a bit too much, it did not scroll well. I've
shortened the text to fix the problem.

Rework CSS for "Big News" & add image.

This image now is displayed with the same background and to the left of
the "Big News". I spent extensive time researching how best to present
a larger <div> with the grey background and have the image properly
scale beside it. Ultimately, I couldn't find a better way than this,
and this is hardly optimal.

For example, I looked into wrapping the whole thing in a div, with two
div's inside, and applying various CSS to each to get the image to
properly stay right next to the text and scale in size when resizing of
media made paragraph longer. This generated even more problems, so I
went with the simpler solution herein, which probably isn't correct and
may well do odd things on different types of media.

Progress bar & $5k triple-match program.

An anonymous donor is matching up to $5k at 2-to-1 for supporter
donations. Therefore, update the page to include a progress bar for
this, and add notes about it in various places.

Start errors in shown state for non-Javascript.

Since the error messages have important information, and since the
Javascript code is the only "enforcer" of the minimum donation, the
errors really should be displayed by default if the browser is not
Javascript-capable. This change does that, but also toggles the state
back so that errors are not shown until needed in Javascript-capable
browsers.

I believe this still fits graceful degradation, since browsers without
Javascript and CSS were already showing the errors anyway, so now the
only real change is that everyone sees the errors by default.

It *might* make sense to not show the errors in red in non-Javascript
browsers (i.e., make the default CSS color black for the form-error-show
class, and then change it to red in the Javascript). I didn't make that
so, because it's not clear to me that's right, and we *do* want to draw
attention to the errors lest people become a supporter below the
minimum (which has happened once already -- that precipitated this
change).

I'm still annoyed that PayPal doesn't provide a "minimum but no maximum"
variable donation box of its own, which would solve this problem
outright.

Match right form for these changes.

The general selectors previously used here matched either form. With
this change, they will only match the form for which the selection was
actually made.

Rework Javascript final form validation.

The problem before was that an error in the annual form would prevent
submission of the monthly form and vice-versa. That is herein corrected
with this change, which assures that the input with id of "amount" if
the specific form (id'd with "annual" or "monthly") is the only one
checked.

supporter-form & support-form-submit: class,not id

These should be classes, not ids, and the ids should identify whether
it's the monthly or the annual form.

Return amount to id; add id for error span.

I actually think I want amount to be id rather than a class, now that I
figured out the proper selector to find them all.

Also, the $("span", input.parent()) was buggy if there were any other
span's other than error-related ones in the supporter-form-inputs div.

Finally, ditch that <small> stuff and simply place a font-size reduction
into the CSS for the form-error-show.

Modify PayPal "no_shipping" var via t-shirt choice

According to
https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/Appx_websitestandard_htmlvariables/

no_shipping has the following values:
0: prompt for an address, but do not require one
1: do not prompt for an address
2: prompt for an address, and require one
The default is 0.

Ideally, any time they change wantGift, even in a pure HTML form, we'd
change it between 0 and 2 as appropriate (i.e., we need the address if
they want the t-shirt).

However, I couldn't find an easy way to make this modification in pure
CSS or HTML, so it only happens in Javascript-enabled browsers.

This is still graceful degradation, since the only impact is in cases
where a non-Javascript user fails to give us an address, and we have to
email later to get the shipping address.

Monthly supporter can enter variable amount.

This required some doing. I'm not completely sure it works, but I
roughly followed the tutorial available at:
https://www.paypal.com/webapps/mpp/get-started/create-recurring-donation-button
with back-reference to this:
https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/Appx_websitestandard_htmlvariables/

My main concern with this setup currently is that 'p3' must be set to
'1', which would seem from the documentation to be saying the payment
will recur only once. There is a subtle hint via the tutorial that
setting 'src' to 1 will override 'p3' with whatever is found in 'srt',
but that's not said anywhere explicitly that I can find. So, I'm going
with this and I'll just test it myself with a monthly subscription to
see if it's indefinite (which is the behavior we herein desire).

Finally, note that "amount" is now a class rather than id, since I'm now
using the associated jQuery .on('input') code for both the annual and
monthly amount boxes.

Change default to "no t-shirt".

I suspect some supporters are just accepting the default, so by default,
the t-shirt option will be "No", and supporters will have to
affirmatively chose "Yes".

Thanks to previously committed Javascript hack, users with Javascript
capable browsers should avoid seeing the t-shirt sizing options until
they chose "Yes".