Thanks everyone for the support.

In the mean time, we have introduced pagination with the laika theme. And saw that it's not nice. In 2024 we have gone "full circle" with a one-page solution collapsible payment section

This is a vague ideas "Task" document where in hindsight the code quality/dev experience won't be improved by most of the changes outlines. We will do the EnvironmentBootstrapper-related stuff in {T342461: Change environment-specific setup for FunFunFactory}

We now have the "late_campaign" flag to switch it for all banners, the ability to change colors easily (both globally and per-banner). I consider this to be "resolved"

Thanks for the comment, @awight. Good idea to load banner asynchronously, I agree with your assessment and like your proposal.

Hi @Peter, thanks for bringing this to our attention and thanks to @Pcoombe for confirming. The WMDE fundraising campaign started on October 28th, with banners on the English and German Wikipedia geotargeted to visitors form Germany, this matches your observation.

Pull Request: https://github.com/wmde/fundraising-banners/pull/606

Draft PR with lots of remaining errors and TODOs: https://github.com/wmde/fundraising-banners/pull/603

Sorry, my bad for not seeing the radio label gap, I applied the fix to the wrong file :facepalm:
Fix is deployed now.
Also, the banner server now supports cookie setting on "I already donated".

I've adressed all the issues except two:

It's now fully testable with tracking for the fee (it's tracked when submitting, the evnt is called "cover-transaction-fee").

@kai.nissen You can now user-test this to get a first impression. How will the campaigns team know if people clicked the transaction fee? By the decimal points in the donation sums? Or will they measure if the donation amount is higher for VAR (which would be just ~1% even if most people clicked the checkbox)

The first round of error logging pinpointed to the donation repository as the source of errors. I've investigated and identified the database-entity-to-domain-entity-conversion as the most likely culprit. Unfortunately, we don't log enough information to see what excactly went wrong during the conversion, so we'll have to do another dance of

1. Review Pull request https://github.com/wmde/fundraising-donations/pull/255
2. Create new patch release of Donation bounded context
3. Update donation bounded context in app (manually, dependabot is not active for that repo)
4. Deploy
5. Trigger the IPN again

No longer needed, since we're using Woodpecker CI now on our own infrastructure. Woodpecker uses containers to run and we package kontocheck in our CI container. Spinning it off into its own service might be an idea to keep our PHP version as close to the released one as possible, but sicne we're also using MongoDB which is not part fo the standard distribution we might as well go "All in" with our custom PHP environment.

We're using Woodpecker CI now (on our own infratsructure)

@kai.nissen This new feature interacts with the "upsell" feature and needs more specification for the 2nd and 3d form page:

• What should be displayed on the 2nd page (when we try to "upsell")? Should it be the original amount or the amount + fee? The latter would need duplicated components of the 2nd page that can take the new info in. If we don't display the adapted amount, do we "undo" the checkbox or do we silently add the fee when submitting?
• What do we do on the 3rd form page (upsell with custom amount input)? Do we dynamically update the transaction fee? Do we drop it? What happens if the user does not wait for the total to update and just hits submit? We might need UX input here.

We could also test this feature without the "upsell" in the banner. Please discuss the increased complexity with the campaigns team and make them aware that in this case the complexity (and effort to implement) goes up because two featues are interacting. Another option would be to activate the checkbox only for one-time donations.

Done & Deployed.
PR for updating the deployment playbook: https://github.com/wmde/fundraising-infrastructure/pull/431
PR for updating the server initialization playbook: https://github.com/wmde/fundraising-infrastructure/pull/432

Deployed to https://testing05.wikimedia.customers.manitu.net

I'm moving this into "Deploy to Test", since the code review went through and we will address remaining snag (mentioned in the code review) in T376311: Adapt payment summary at the bottom of the donation form

Thank you so much!

We now carry over URL parameters for different A/B tests. We w're also working in getting rid of the pages and having one unified page with a collapsible payment section.

I have looked at the notification data and the error logs. The exceptions in the error logs make it look like the donation with that specific ID does not exist, but I've queried the database and the donation *does* exist. The first call to getDonationById in the BookDonationUseCase is failing. To determine if this is a database layer problem or if the ID is mangled by the controller that passes it to the use case, I've created https://github.com/wmde/fundraising-donations/pull/253 Please review it, create a new minor release, update the dependency in the fundraising app and deploy the app to production. After deploying, put back this ticket in "Ready for work" and trigger the notification. Then the error message should either contain the donation ID (we can investigate further what weird database error this is) or 0 (which means we need to investigate the controller code).

I've deployed to test and the deploy script deleted the old versions. This means that probably the outdated Ansible version was the cause ...

@CorinnaHillebrand_WMDE The deployed version on the server still had the old ports. The most likely explanation for that would be that you did deploy with an outdated version of infrastructure. fun-deploy.sh should have prevented that (if you have the newest version of that), I wonder what happened ...

Had to change the port, PR https://github.com/wmde/fundraising-infrastructure/pull/429