Just completed the logging setup for this. (See the updated repo.)

Here's a WIP repo for setting up Fundraising dev environment.

@kostajh thanks so much for this!

Hi! Adding the MediaWiki-Docker tag for visibility and coordination with related projects...

Also, if anyone's interested in the rough notes from work on this, here's the etherpad.

More fallback-related issues were also discovered in work on this bug. They are described here: T261718: More minor bugs introduced with campaign fallback. The cleanup patch only fixes the first of the issues mentioned in that task, though it does clear the way for fixing all of them.

Hi! The patches for this and the related cleanup task (mainly T232235) are ready for review.

The attached patch addresses only the first issue in the description (bannersNotGuaranteedToDisplay not reset on new iteration of fallback loop).

The attached patch renames methods (the first part of this task) but doesn't rename statuses (the second part).

We'll also have to adapt the mixins that register hook handlers to be able to run multiple times, since they were written with the expectation that they could only run once per pageview. We should do this for both pre and post handlers.

In T255810#6393568, @mepps wrote:

To duplicate:

• Create two campaigns A & B.
• Create two banners 1 & 2.
• Assign banner 1 to campaign A, and banner 2 to campaign B.
• turn on banner history logger for both campaigns
• Turn on impression diet for campaign A, limit to 2 or 3 impressions
• In one scenario, close banner 1, on reload, banner 2 should appear
• Other scenario, see banner 1, reload until impression diet is reached, on next reload, banner 2 should appear
• in storage tab of developer tools, look in localstorage for the site, there should be a central_notice_banner_history key, with an array
• for banner 2, statusCode value in this array is supposed to be 6, but will appear as 4 currently.

Thanks again! :)

Hi! The changes in the task description are now available on production. @EMartin, could you please confirm that this works for you? Thanks so much!!!

Thanks so much @Krinkle for the information on this!

Andrew still has access to Phab so I'll ask him to comment here as confirmation.

Thanks so much, @Ejegg!

In T251780#6297530, @Pcoombe wrote:

Thank you banner
This certainly seems like it could solve the problem, but it would need a not insignificant amount of work from fr-creative. We have a lot of content on the TY page that would need porting over, and a lot of stakeholders on that content. I'm not sure how quickly we could turn this around.

If there's a possibility of being able to return donors to their original article (T60506) this becomes more interesting as it's a very common request.

Setting a cookie on donate wiki and checking it before we display the banner

@AndyRussG Can we set a .wikimedia.org cookie (i.e. without the donate subdomain) on the TY page, and then access that in the banner without an additional request? Since the banner is loading from meta.wikimedia.org

One more option (thanks to @Jgreen for this idea): we could create a thank-you banner on Wikipedia. So, instead of going to the thank-you page on Donate Wiki, donors could be sent to Wikipedia with a banner= parameter in the URL to force the banner to appear. It could have the same content as the thank-you page and set the cookie to suppress further FR banners.

@Ejegg what about this option? We set a special cookie on donate.wikimedia.org when people go to the thank-you page, then include code in the banners to check it in the background before actually displaying the banner? I think that's in line with sort of flow for cross-site interactions that will still be allowed?

Just another idea for the shortest-term solution: in the banner, we could try to determine the user's browser version, and based on that, only set the hide cookie from within the banner if we think the browser won't tolerate the hide cookie being set in the background on the thank-you page.

He suggested we put the thank you page on a *.wikipedia.org domain rather than *.wikimedia.org, so it can set the cookie itself.

Adding Traffic and Operations tags to ask for input about how Varnish caching for this new redirecting special page. Please see the attached patch.

Thanks @tstarling! As it turns out, current and upcoming browser restrictions on third-party cookies are quickly making cross-site banner hiding unworkable.