We long ago decided not to auto-renew annual supporters. However, three
different potential supporters mentioned they were unsure, so this note
is added to clarify.
Surprisingly, given her predilection for exclamation points:
<karen> yeah... believe it or not, I'd rather not have two exclamation points
in the 750 achieved! [20:30]
<karen> and I would also delete the exclamation point after " enforcement
efforts!" in the text above it [20:31]
So this change is made on her behalf.
After the next import, we'll have more than 750 supporters. This change
not only handles that fact, but adds sufficient Javascript and Django
templating to handle the case if the Supporter count for any reason
drops below 750 again.
The Supporter appeal didn't discuss the two different targets in much
detail. This change explains a bit better where the "service split" is
between what we can do with 750 Supporters vs. 2,500 Supporters.
Karen helped with this change.
[0d89044: Replace gradient images with CSS gradients.] replaced gradient
images with CSS gradients but in doing so changed some of them from
light blue to gold. Change the colours to correct ones where necessary.
Because #logobutton had a fixed width, browser window narrower than 933
pixels resulted in an unnecessary horizontal scroll bar. Fix that by
using a dynamic 100% width which results in the header image being
automatically clipped as necessary.
To avoid clipping the tree and the text though, include min-width so
that very narrow windows result in a horizontal scroll bar so the whole
name can be seen.
Furthermore, simplify the markup by removing wrapper DIV and SPAN
elements which weren’t really necessary. As a consequence of that
change, the whole top of the page is now a link to the homepage (i.e.
‘/’). Prior to this change, the link wasn’t clickable.
In this situation:
<body class="conservancy-blog">
...
<video>
it turned out that this CSS:
body.conservancy-blog video {}
Did not apply.
So, this adds a hack to force the issue.
This middleware is a bit of a mess anyway, since it's basically using
static files as templates. However, we definitely don't want to add any
GET query parameters rendered into the path name.
I noticed after I updated to jessie that fonts displayed strangely in
some browsers. I still have strange fonts on our website with Chromium,
but this change seems to have helped iceweasel.
The base template now has access to the fund-raising goal that will be
displayed site-wide. The view here must provide it in the context for
access everywhere.
Furthermore, we need a local context processor to make sure it's in
context everywhere, and we have to make sure that context is properly
passed along.
This code is a bit cargo-culted in, based on what I read in various
places about adding the Request context.
Monthly supporters actually do currently receive their t-shirt when
they've given at least $60. They also are listed immediately.
In an effort to make monthly Supporters feel a bit better about the
delay, this text is improved to explain the situation a bit better.
Bradley M. Kuhn wrote the first draft of these principles on 23 May
2015. They were from there rewritten collaboratively over the following
months with the participation (in chronological order) of Karen
M. Sandler, W. John Sullivan, and Allison Randal.
This commit is the first publication of the principles on 1 October
2015.
The news announcement posted on Conservancy's site on 2015-10-28 at:
https://sfconservancy.org/news/2015/oct/28/vmware-update/
had additional facts. This commit incorporates those into the FAQ.
Additionally, a link to additional technical materials was also provided
that day.
The main change here is that the lawsuit FAQ page now shows one how to
verify that VMware combined Linux source code with their binary-only
components using VMware's ESXi 6.0 rather than ESXi 5.5 Update 2.
This required a couple minor path changes and updates to the memory
addresses and SHA-1 checksums. The analysis steps otherwise remained
the same.
The FAQ is now more generic in its discussion of the ESXi versions
that were originally analyzed, in order to avoid confusion with the
analysis provided in the FAQ, which uses a newer version and reaches
the same conclusion.
Some minor, unrelated fixes were also added. These include:
* add period at end of paragraphs where it was previously missing
* convert ">" in <pre> and <code> to ">" so the page is valid HTML
* convert "&" in <pre> to "&" so the page is valid HTML
* add missing 's' to "truct pci_driver"
* fix the "tg.c" filename - this should be "tg3.c"
Add additional information and details about the technical details of
the VMware violation. This extends the existing example with more
detail and improves various other parts related in the FAQ.
Written by Denver Gingerich <denver@sfconservacy.org> and me, this
description gives one example of how VMware incorporated Linux code with
vmkernel and distributed the resulting work.
.. even though you havent’t yet hovered over the link.
This change corrects that behavior. Suggested by mina86:
<mina86> so when you hover over the LI the link changes background even though
you havent’t yet hovered over the link
<mina86> #container #sidebar li:hover a { background: #577632; color: #fff; }
<mina86> s/li:hover a/li a:hover/ would be IMO better
The banner always faded in/out, but now other texts can be designated
with the class 'donate-box-highlight' and those will fade out and fade
back in with bold and slightly larger font.
This is perhaps too flashy, but it does successfully animate the
progress bar up to the target amount, and also changes the amount until
it reaches the total raised so far.
The urls.py is of course only evaluated once: at Apache load time, which
means the data in the template became stale and is not dynamic.
This change should cause the lookup to happen at each page view.
The progressbar is generated by Javascript. As such, the text here
won't have a progressbar formatted around it when the browser doesn't
support Javascript.
However, since the Javascript does update the text, we can format the
Django template to put in place text that we wish will appear when no
Javascript is turned on, and then allow the Javascript to make it right
when it's available.
Graceful degradation: I may be its last proponent.
The npoacct campaign was launched before the Supporter program, and
parts of its functionality were incorporated into supporter-page.js
ultimately. This commit hopefully now backports that functionality to
npoacct campaign.
This seems to be the best approach to pass a fundraising goal record to
a template. While the static hack that tmarble implemented probably
needs work anyway, this is probably the best way currently to interface
certain general data that we seek to place on many different pages
through the templates.
I looked into a templatetags solution, but this seemed more
straightforward and more fitting with Django principles (I think :).
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).
When we have both dt's and the donate-sidebar floating around, things
get tight. Perhaps there is a better solution than this (e.g., can you
set the @media conditional on there being a donate-sidebar at all?), but
this should be a reasonable hack to fix the problem.
Set the min-width for the left-floating dt's to 550px, so that small
screens just get everything in one column.
Note that the formatting previously used is now moved purely to @media,
which I don't know how that will impact browsers that don't support
@media in CSS, but OTOH, I believe the graceful degradation is done
correctly here.
This is accomplished by three key changes:
* use em rather than px sizes, so that font changes are accomodated.
* Add a margin to the dt.
* center the text in the dt's rather than right align.
Using this span, we can update the number in the fundraising percentage
text automatically. The downside is that non-javascript browsers will
not receive a fundraising percentage, but the upside is that fewer
things need to be calculated by hand, and now only the amount raised so
far needs updated.
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.
<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)
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.
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.
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.
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.
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.
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.
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".
Use Javascript to hide the t-shirt size selector when the the user
selects "No" for "Do you want a t-shirt?". Reshow it (and make sure
it's shown by default) for "Yes".
This CSS, which I discovered from extensive research online, should work
to create a bulleted list with the bullets being the heart-shaped
Conservancy logo.
The default amount of $120 appears in the amount field, but the class
"valid" was usually only added when the user changes the amount.
The valid class must be added at the start to ensure someone simply
clicking with the default still can donate.
The donate-sidebar overlaps with text on small screens. This problem is
corrected herein by using @media for 500px screens to remove display of
the sidebar.
This addition to the Javascript and text ensures a clear message to the
user of a Javascript-enabled browser that there is an issue with the
amount. Also, it prevents submission of the form until the amount is
correct.
A user with Javascript disabled can circumvent these validation steps;
however, the worst-case scenario is that they make a donation for less
than $120 that is categorized in Conservancy's internal system as a
Supporter donation, and we'll be adding internal checks to find that.
