User Details
- User Since
- Oct 28 2014, 2:36 PM (438 w, 4 h)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- AGreen (WMF) [ Global Accounts ]
Yesterday
Just to confirm, the issue with user preferences not correctly hiding banners based on type: this part of the system now seems to be working as expected. Is anyone still experiencing this specific bug?
Fri, Mar 17
Thanks so much for this @jgleeson! The attached patch looks great.
Thu, Mar 16
Wed, Mar 15
Tue, Mar 14
Heyyy here are some quick notes:
- I was able to reproduce this on production just by disabling banner categories in my preferences and seeing what happened. Not sure why you're not seeing any banners, @TheresNoTime.
- The fix turned out to be quite simple. It has been merged and placed on this week's deploy train. It should be deployed to most Wikipedias on Thursday, and to most other projects and a few Wikipedias on Wednesday.
Apologies for the delay in getting to this, and for not writing more details just now. (FR-Tech is rushing to get a new payments integration finished this week.) I'll try to find time later this week to explain more and reply to some comments above.
Thanks again!!
Mon, Mar 13
Thanks so much for this, it's been immensely helpful!! As noted here T331671#8688951, it looks like there is indeed be a bug. I'll post more on the parent task as soon as I can.
Thanks so much everyone for your input and effort on this, and many apologies for the delay.
Thu, Mar 9
Wed, Mar 8
Wed, Mar 1
Attached patches add the required fields to the donations queue message. Test and UI elements will be included in follow-on patches.
Fri, Feb 24
Wed, Feb 22
Feb 16 2023
Feb 14 2023
Feb 13 2023
Summary
- The updated code for this is merged and deployed, but I'm unable to turn on the process-control job myself due to a permissions issue. (Can't push to fran1001:/var/lib/git/localsettings.git/)
- Comparing the output of the old and new versions of the script, via spot-checking, we see the following:
- Data in banner impressions seems identical.
- Data in landingpageimpression_raw seems almost identical.
- Data in donatewiki_unique seems to get additional entries with the new script. These entries are not present in data generated previously by the old script in the production pgehres database. However, this was probably due to an issue with the old script, or something related to the setup at that time, causing the old script to incorrectly drop data.
Feb 7 2023
Instructions for running under fundraising-dev with bullseye:
Feb 6 2023
Thanks @Jdlrobson! I'll make a CN patch just to always expose a mw.centralNotice.isBannerShown() function no matter what, since that seems like the most logical way for the CN JS API to work, and would prevent errors like the one mentioned in the task description.
Feb 5 2023
An additional use case is the global enabling or disabling of components. Possible commands for this:
frdev disable privatebin
frdev enable donut
Feb 1 2023
Fresh is now working on Donut (the MW instance with CentralNotice on the fr-dev stack).
This is working for Donut, with this patch: https://gerrit.wikimedia.org/r/885446.
Jan 31 2023
Thanks for all this!!
Jan 30 2023
While I'm still unable to run tests locally using npm run qunit, I've made some progress running them in the browser locally under Donut wiki on the fr-dev stack.
Two attached patches (the second one was somehow not added by gerritbot):
Jan 25 2023
Jan 23 2023
From the commit message on the patch for the 2nd variant:
Hmmm maybe we're not mocking mw.requestIdleCallback in a qunit test somewhere where we should, and some recent change to CI has made calls to the original method unreliable? (More detailed explanations in also Gerrit.) Also, I do see this still happening recently, for example, here.
Jan 20 2023
Jan 18 2023
Another idea: an updated fr-dev CLI could also be a place to put automated scripts for the local steps needed to prepare a deploy.
Jan 17 2023
Jan 13 2023
Looks like the issue is the campaign seems to be set to display 0 banners per device.
Hi @Addshore! Ah interesting, thanks! They're part of the fundraising-dev environment we use to set up the diverse fundraising stack locally.
The fix for T320734 is now deployed, so the ESI comment string for testing is now being added to the base HTML for both desktop and mobile sites. So, once the cache finishes rolling over, it'll be present throughout the base HTML served via Varnish.
This is now deployed!
Jan 12 2023
Current version of the attached patch seems to work! I think at least a bit more testing and study is needed to check for possible side effects/edge cases. Also I feel we'd we need to fix exception thrown and add inline comments to explain how things work.
Jan 11 2023
Jan 9 2023
Note: hoping to deploy the latest fix to production pretty soon, possibly this week. This would cause the test ESI comment string to be injected on both desktop and mobile sites (rather than just desktop, as is currently the case). Thanks!
Quick update: the patch in question was looked over by other fr-tech engineers and we agreed it seems extremely safe. So, we merged it to master, which meant it has been deployed to the beta cluster, but not to production, since December 15th.
Jan 3 2023
Dec 22 2022
Dec 18 2022
Dec 16 2022
Dec 15 2022
Dec 14 2022
Here's a proposal for the command-line interface. Let's have a single base command, say, frdev, with various subcommands to perform specific actions.
Dec 12 2022
I'm able to reproduce this, or something similar to this, locally, with the following procedure:
- Open an Adyen cc form.
- Fill in the form using test card info.
- In the JavaScript console, execute:
$( '#paymentSubmitBtn' ).click(); $( '#paymentSubmitBtn' ).click(); $( '#paymentSubmitBtn' ).click();