Wed, Dec 11
Skipped unresolvable module ext.centralNotice.adminUi.bannerEditor resolveStubbornly @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:9
Tue, Dec 10
Fragments aren't even sent in requests, they are handled entirely client side.
Sun, Dec 8
Have they visited Canada, or used a VPN recently? The location cookies can sometimes persist for a while, it can be fixed by clearing cookies.
Sat, Dec 7
Fri, Dec 6
For reference here's our current banner designs
This is still a problem, and has caught us out again this year. @AndyRussG any chance you could take a look?
Fixed by adding width: 50%; - https://meta.wikimedia.org/w/index.php?diff=prev&oldid=19617695
Think I've figured this out, just testing the fix now...
Thu, Dec 5
Oops, I actually meant to do that merge the other way round! Copying Sam's comment here:
Wed, Nov 27
Great, thanks Josh. I should be able to get that data myself, will let you know if I have any trouble.
Thanks for the clear testing instructions @cooltey. Looks great on my Pixel 1! I tried all the target countries and the messaging seems right. Looks nice in all four themes too:
Mon, Nov 25
Fri, Nov 22
Hello, requesting Kerberos credentials for Hadoop access on stat100x and notebook100x. My username is pcoombe. Thanks!
Tue, Nov 19
Thanks @jbolorinos-ctr! Merged this into current best: https://meta.wikimedia.org/w/index.php?diff=prev&oldid=19570738
Thu, Nov 14
T236077: City field and label positioned wrong on India form is something similar
Nov 11 2019
@spatton It's not a bad idea to do it on donatewiki, but I really don't have the time to work on adding that feature before December.
Nov 8 2019
This is fixed in the latest banners.
Nov 6 2019
There is the list I made at T166346: List of DonationInterface messages used in banners/donatewiki, but it's outdated. Note that we also use some messages on donate.wikimedia.org, so would need to either keep DonationInterface there or copy those messages too.
I just set up a GBP 1.75 recurring upsell donation. And the notification email now says that it's for £ 2.26, which is the USD equivalent but with GBP localisation! This is wrong, and definitely a blocker to testing this outside of the US.
Nov 4 2019
This is done, thanks again @Jdrewniak for the help!
Oct 31 2019
Still happening in the latest banners. I feel like there was something odd with IE11's handling of radio buttons which tripped us up in the past too. Will look into this.
Oct 29 2019
Here's a super hacky script you can use in the browser console, or base a userscript on. It won't update the control display, but it will change the languages when you click Submit.
Checked the tickets from the Triage doc, and couldn't see anything unusual about the links they were using. I also see a few of the donors followed up and said they were able to successfully make a donation later, which makes me think this could have been something temporary - network issues? But then I don't understand why it would only affect Safari...
Just want to say thanks both for investigating! Seems even more complicated than I first thought :/
@MBeat33 Have we had any more of these, or managed to get console logs from anyone? I don't see anything new in the triage doc.
Oct 23 2019
This error message ("If the form does not load, your web browser may not be supported. Please try a more modern browser.") is from donatewiki. I couldn't reproduce in Safari 13.0.2 but will keep looking.
Just made a test donation and got the new email. Thanks a lot @Ejegg!
Oct 22 2019
Yes, it was using raw HTML. I moved one script into https://donate.wikimedia.org/wiki/MediaWiki:SupportPage.js, and removed the other since it's not actually needed.
Oct 21 2019
Oct 18 2019
Oct 16 2019
Oct 15 2019
Well darn, thanks to T182549 I didn't get notified about this task until David's comment. I've requested access to the copy and will prep a patch for this soon.
Thanks @Nuria !
Oct 11 2019
@kaythaney Sorry for the delay on this. I've updated donatewiki with the changes requested: https://donate.wikimedia.org/?utm_medium=endowment. Let me know if this looks okay.
Oct 10 2019
Oct 8 2019
Don't have time to play around with this now, but maybe it has the same solution as T234953 i.e. add width and height attributes to the <svg>
Japan is done. There were a surprisingly low number of donations, it's not clear why. Results from the test are [here].(https://docs.google.com/spreadsheets/d/1cHQhoMOYTTWnHZNH8V1d64DhHrZ79iBIz9KLEl-Q-Gc/edit#gid=1305301970)
This should be fixed now. Internet Explorer needed the width and height attributes set on the <svg> elements directly, without that they were displaying too wide and pushing the other logos out of view.
Oof, looks like an issue in IE11. I'll look into it ASAP.
We're in peak fundraising season now, and I'm worried this might affect links to https://donate.wikimedia.org.
Oct 2 2019
Sep 30 2019
Sep 20 2019
Sep 19 2019
Just made a test endowment donation and confirmed I get the new email. Thanks!
@jrobell No, this was just a test from the staging environment. It still needs to be deployed to production which will make it the email donors actually get.
Sep 18 2019
@kaythaney I just sent you a couple of test emails, one with a named donor and one anonymous. Please can you check these and confirm if they look correct?
An update on this, it's in review but testing is blocked by a bug we found (T232504: 500 error when testing Endowment thank you emails in Civi). I believe Elliott is working on fixing that this sprint.
Sep 17 2019
After discussing this further today, we decided to go ahead and make the logos the default. I have now done this: diff
I took a more in-depth look at the results from Spain, and see no statistically significant differences from adding the logos in:
- share of card donations
- amounts given
This is now on by default
Sep 16 2019
Sep 13 2019
This looks identical to the text we currently have in banners: https://en.wikipedia.org/wiki/NASA?banner=B1920_0701_enWW_dsk_p1_lg_template&country=IN
Sep 11 2019
Sorry, this one was my fault. I recently added code in CoreJS to block typing letters in the "other monthly amount" field, which was a bug one of the QA specialist candidates spotted. But this throws an error if that field doesn't exist in the banner, i.e. before the introduction of the upsell. The much older banners were still working as they don't include this CoreJS.
Sep 10 2019
Ooh, I notice this label variant fixes T169797: Inconsistent order of payment field errors too!
Sep 9 2019
This is fixed in current best, I realised we could just re-use frb.shouldShowRecurring() from CoreJS. Cleaned them all up to use the same method.
Sep 8 2019
Sep 5 2019
I'll prepare a patch for this, as a chance to test the new direct git method.