Fri, Feb 14
This whole parent task is now made obsolete by T243203: Get familiar with errBit setup. Individual unresolved child tasks can still be picked as needed
We're now using Errbit instead of logstash.
Since we'll be using Errbit instead of logstash, this issue is no longer relevant
Should be re-thought as part of T191619: Automated browser tests for the donation application
- Created a new branch from the commit before cat17 was deleted, changed the campaign configuration to be able to switch skins until the end of 2025, see https://github.com/wmde/FundraisingFrontend/tree/skin-archive
- I've asked IT to create the new subdomain and point it at the IP of our test server. Ticket No is 2020021420000332
- Prepared the Nginx on the test server with a new vhost. See https://github.com/wmde/fundraising-infrastructure/pull/291
- Added an inventory file for the new target to FundraisingFrontend/deployment/inventory/skin_archive on the deploy server
- Added the new configuration file for the instance in configurations/spenden-old-designs.wikimedia.de/config.uat.json
Tue, Feb 11
PR for FundraisingFrontend side of things is here: https://github.com/wmde/FundraisingFrontend/pull/1698
Mon, Feb 10
It is deployed, however we discovered two flaws:
- JSON Schema check fails. It is disabled for now but should be re-enabled when the schema is adapted.
- The logging server doesn't send emails
To test the setup, you can use the following curl commands:
Tested the "Special:HideBanners" functionality as a blueprint for this functionality with Chrome, Firefox and Safari. Safari already blocks the cookies, Chrome will follow in the next 2 years. 3rd-party cookies can only be a stopgap measure for now.
Please be aware that 3rd-party cookie support will go away in all browsers, and we'll need to find an alternative to that if we still want to support fundraising sites outside the wikipedia.org / wikimedia.org domains to hide banners. See https://phabricator.wikimedia.org/T244699
Preliminary PR for the banner server is here: https://github.com/wmde/banner-server/pull/37
Fri, Feb 7
Pull request: https://github.com/wmde/banner-server/pull/36
Mon, Feb 3
Fri, Jan 31
In the FundraisingFrontend this is because we have two different EntityManager classes and the AddressChange one was not used to generate the proxy classes on deploy.
Pull request: https://github.com/wmde/FundraisingFrontend/pull/1693
Thu, Jan 30
Wed, Jan 29
Tue, Jan 28
Mon, Jan 27
- Did package upgrades on all servers
- Discovered that the reduction of spare backups from 3 to 2 was not deployed. I've done that now.
- Updated Banner Server PHP container and all dependencies
Jan 24 2020
Jan 23 2020
@kai.nissen @CorinnaHillebrand_WMDE I've put it on review, PR here: https://github.com/wmde/fundraising-banners/pull/299
Jan 22 2020
Jan 21 2020
Sorry, this task is not resolved: [[ https://github.com/wmde/FundraisingFrontend/blob/master/app/config/campaigns.yml | campaigns.yml ]] in the FundraisingFrontend still contains the campaigns, [[ https://github.com/wmde/FundraisingFrontend/blob/master/src/Factories/ChoiceFactory.php | ChoiceFactory.php ]] still contains the different initialization branches for the campaign code and the laika code still contains feature toggles for the campaigns. We need to have a look at campaigns.yml, discuss with Fundraising Ops which ones are really finished and which ones did not get enough data / were inconclusive so they need to be repeated.
Jan 20 2020
We have our own analytics software that plots the donation data (containing the banner name) against the number of impressions. The data from Peter's script gets imported regularly (With IMAP as our transport protocol 😱). So we definitively need a "machine access" (i.e. no credentials from analytics team used) to the data, to import it in regular intervals. The data itself is quite minimal and should not contain user-identifiable data: Banner name, impressions from a 15-minute period, timestamp.
Jan 19 2020
Jan 17 2020
Jan 16 2020
Jan 15 2020
I've posted the result of my investigation in a new bug report: T242895: Safari crashes on some click handling events for banners that move the centralNotice element outside of the the main body. I'm hoping to get help from the WMF mobile developers, because I'm at the end of my wits.