This changes the hard-coded style for what I'm calling the
content-with-donate-sidebar. The advantage of not hard-coding style are
obvious, but I'm doing this now rather than later so that I can add
changes to the CSS that causes the width to extend to 100% on smaller
screen media when the donate bar disappears (the latter of which is
already implemented).
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.
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.
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.
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.
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.
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.
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.
