@Pcoombe - Take a look at this banner to resolve the issue. It takes the style of disabling the payment method or frequency option depending on selection from CB Mobile Large. I also fixed an issue where the Amazon Pay logo color didn't change to white when selected.
Mon, Dec 28
@jbolorinos-ctr - Do these appear differently than in the control mobile small banner? I agree that they could probably be laid out better, but we would want to keep the layout the same as control for the purpose of this test. Let me know if they are different than control and, if so, I will dig into it.
Dec 18 2020
@jbolorinos-ctr - I believe this issue is resolved. I fixed by changing the display property of this element from table to flex (diff). This should be fine, but please do review the browser screenshots with this change to confirm.
Dec 2 2020
@jbolorinos-ctr - Take a look now. I changed some padding to resolve the issue.
Nov 18 2020
Noting the CSS elements here that are setting the height on this iframe:
Oct 30 2020
Now I'm not receiving any emails?
Does this generate an email to me?
Oct 26 2020
Btw, a good way to review these frb variables is to set up live expressions in Chrome's inspector tools (Firefox may have something analagous). You can see that I did that with the relevant variables in this screenshot:
Oct 23 2020
I have a proposed solution in this banner.
Oct 21 2020
I'll take a look at this task this week.
I don't think there was a specific test of this change, but it was implemented in part to avoid a possible display issue in some browsers. From an Aug. 1, 2019 comment on the Current Best banner sheet from @spatton:
@jbolorinos-ctr - This is the intended behavior of the banner. I believe the thinking is that once the user clicks "Continue" they've begun the donation process and no longer need the RML. I'll look back and see if there was a test or more notes regarding this decision.
Oct 1 2020
Just wanted to note that we recently discovered that WYDG Foundation webpage is not up-to-date (it uses numbers/text from a previous annual report rather than the most recent one). Might want to hold on any tests that link to that page until that is updated.
Sep 21 2020
Jul 21 2020
Confirming that you fix looks looks good to me in Browserstack testing. And IMO, the slight font weight change on the PTF amount is an UX improvement (maybe one we should test out in 6C).
Jul 15 2020
Jul 7 2020
As another data point, I am able to submit a successful transaction with a valid CC number and expiration data WITHOUT entering a security code using the steps above.
Jun 29 2020
Sounds good. I've updated the RML options banner to include this update: https://en.wikipedia.org/wiki/Wikipedia?banner=Trilogy_mlWW_dsk_p1_lg_RMLTiming1&country=US
Yes, we can auto-focus the email input in the nag. Noting again that this is how it works in control. So, let's fix it there as well.
Jun 16 2020
Agreed with this assessment that the "back" button is unnecessary/confusing on the RML options step in the nag. I've modified the banner to hide that on this step.
I am seeing the email input being auto-selected (put in focus) when the user clicks the RML link. This is the code in this banner and the control:
Just noting on this main task that this is the current candidate being QA'ed: https://en.wikipedia.org/wiki/Wikipedia?banner=Trilogy_mlWW_dsk_p1_lg_RMLTiming1&country=US
We left this as "Submit" to keep it consistent with the control that does not have a second step. The idea being we want the initial signup behavior to be the same even if there is a second step. My concern with changing the language of this button to "Continue" is that it could depress signups if a user infers a drawn out process. I'm certainly open to testing that assumption.
The link in my comment loads for me. Can't think of why it would not load for you unless there's a client-side issue.
Jun 8 2020
May 28 2020
Proposed solution in this banner: https://en.wikipedia.org/wiki/Wikipedia?banner=Trilogy_mlWW_dsk_p1_lg_RMLTiming1&country=US. This only changes the behavior of the UI in the main banner, not the nag. The nag UI is different (back instead of close), so I'm not exactly sure how to handle. Thoughts?
May 20 2020
I don't believe this is a bug. We can decide if it's a feature we want to implement. Currently, clicking outside of the nag does not close the nag does not close the nag in any banner; adding this would be new functionality.
May 5 2020
Confirming that this is still an issue. I do not have a proposed solution yet, but wanted to note that I can recreate it.
Apr 10 2020
Can you give it another pass now, @jbolorinos-ctr? I spent more time ensuring the styles match the mobile large payment buttons. It looks good in my local testing.
Apr 9 2020
Alright, I've fixed the button spacing issue that @Pcoombe mentioned. These buttons are adapted from mobile large, so I made sure the styles were in line with that. I also added a new style that allows the PayPal and Amazon SVGs to size down at small widths:
I do see that difference in button spacing, @Pcoombe. I'll fix that and maybe it will resolve the issue for all web clients.
Apr 7 2020
@jbolorinos-ctr - Can you provide a screenshot of how this looks on that Swedish URL? Does it not occur on the English version?
@jbolorinos-ctr, do you know what version of Android and Chrome this test is using? Trying to reproduce to debug.
Apr 6 2020
@jbolorinos-ctr - Can you confirm if this is an issue on the control mobile small banner? Also, could you check the mobile large control banner as well as that is where this banner code was pulled from? Thanks.
Mar 18 2020
Right, but 200,000 Colombian Pesos is only ~50 USD. 1,000,000 Pesos is ~250 USD. It looks like the max for that currency is 55,680,000, so 8 digits. I recommend setting the max width to something much more conservative since places you accept currencies and rates of those currencies could change over time and limiting entry length could be something that becomes a hidden issue for donors. As the banner is designed, the bug we're solving for here doesn't start occurring until 20-30 characters in my testing.
Mar 17 2020
Wanted to flag a concern here that limiting this to 6 characters might be a problem for some currencies. Maybe not an issue for bundle countries but in places with weak currencies 6 digits isn't a large amount. Should we be more conservative and allow something like 12 chars?
Jan 2 2020
I consider this a feature rather than a bug :-). Currently the legends are bolded and turned red for an error and then we further explain the actual errors below the continue button. While this is very explicit, I don't think it's redundant. Just my opinion, but I prefer to go overboard in identifying the issues preventing the user from moving on.
Dec 31 2019
This seems like a logical explanation, @Pcoombe. I don't have a crossbrowsertesting account but using my Browserstack account I am seeing similar behavior in Firefox. But I also see this behavior when I go to a completely unstyled form like https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_radio. It's not possible that Firefox didn't show radio buttons in a completely unstyled state, so I think this must be a VM thing.
Dec 19 2019
Acoustic will not send to addresses it deems invalid (or those that have bounced before), so it shouldn't be affecting our bounce rates. We can review the bounce data though to confirm.
Dec 16 2019
I'll add that there is verification on the Acoustic (nee, IBM and Silverpop) side as well so some emails will either not make it into the system or will never be sent to due to their characteristics. Agree with Peter that this isn't a high priority concern.
Nov 26 2019
Agreed, @spatton. And to be clear, you can add this CSS to the .mc-button class and then I *think* you can get rid of the .mc-edit-amount .mc-button CSS altogether.
Nov 21 2019
Taking a look at the control banner and I think these CSS changes would resolve the issues noted:
Sep 23 2019
I experienced this issue on a donation made on 8/26/19. Just re-tested and did not experience the same issue, so it does appear the bug I encountered has been resolved.
Aug 28 2019
44 x 44px is the recommended target size for inputs according to the W3 WCAG. It's going to be tough to get there with radio inputs. Also, I think we should consider that other touch-capable devices - such as many new laptops - access the desktop site already.
Feb 13 2018
Feb 12 2018
Feb 23 2017
Thanks, @RobH, the new cert is in place on benefactorevents.wikimedia.org.
Feb 22 2017
Feb 21 2017
@Jgreen Yes, I will be the point of contact for this update. This domain is hosted using Azure's App Service which requires us to manually upload a PFX cert file to update the cert. While we could certainly do this with Let's Encrypt, because of the short-lived expiration (90 days) of those certs we would be making this manual update regularly. We would prefer to stick with the previous cert vendor for now to limit updates to once per year.
Aug 17 2015
As the domain for the Domain Key record has changed, we need to use a new DNS value. Please update to the following:
Aug 4 2015
We cannot. An alternative is to just add the DKIM record and leave the SPF record as is. This would give email sent through the system a valid DKIM record and an SPF value of neutral. That may be sufficient to keep messages out of spam.
Thanks, @BBlack. The cert is now in place.
Aug 3 2015
Sure. Here's my public PGP key:
Jul 29 2015
@CCogdill_WMF - I've updated the task description with the DNS additions we need for the Major Gifts' event tool.
Jul 28 2015
Thanks, @BBlack and @RobH for the insight into current operating procedure for third-party sites hosted over HTTPS under the wikimedia.org domain. We were not given direction regarding a SOP for this process, so that helps immensely. I understand your concerns re: the wildcard certificate and agree that you should generate the certs on your end.
I apologize as I don't know who the question above was directed towards, but I'll add some thoughts from our end. Since there is already a wildcard cert for the site, it would be redundant to purchase another one for the Major Gifts event tool. We will host the site, but the SSL cert is used to identify the site as legitimate and secure regardless of where the site is hosted. However, if Wikimedia prefers we purchase a new cert for this subdomain we are able to do that. We will need help from the ops team to approve the purchase of the cert; I can post more regarding this as we move forward with the purchase. Are there any specific requirements for the type of cert we should purchase?