Make it abundantly clear everyone can come.

Karen got feedback that some people were confused about who can attend.
This change makes it more abundantly clear everyone can attend.

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.