For testing locally, just added a setting in the private config repo for fundraising-dev.

Here are some general thoughts about how I'm imagining this could go:

Another use case: update all (or specified) codebases to the latest master, and only stop if uncomitted local changes found, maybe?

Quick note to remember a thought on this: Maybe try to document stuff as we go, as much as possible? It just seems that the code here is involved in a bunch of different code paths, and it'd be great to have up-to-date notes on how all that works... Thanks much!!

Quick note to remember a thought on this: Let's maybe document the import logic and related code as we go? Thanks!!

Hi! So,, LandingPageImpression should be migrated, please, and with IP and geocoded data preserved, if possible (same as with other FR schemas).

In T271168#7082147, @Ottomata wrote:

@AndyRussG is CentralNotice special for deployment? We merged the change > 2 weeks ago but it isn't included in either php-1.37.0-wmf.4 or php-1.37.0-wmf.5. I just looked at git log on deploy1002, do we need to merge that change into the wmf_deploy branch?

Hi! Thanks so much for digging in @Cstone! Looking at the code you found... I think Civi::log() should instead be Civi::log('wmf'). That's what we're doing in the new preferences queue consumer. However, grepping through the code, I see a lot of calls to Civi::log() without any parameters. I think Civi does choose a default in that case. So, maybe we want to make sure that logging calls made like that always go to places we see, as well as not erroring out like that?

I think this may be all done?

In T281651#7057497, @jgleeson wrote:

Hi @AndyRussG. Appreciate you writing some of this up for me and giving this your attention over the weekend. The first two tasks do feel like good improvements but I wonder if the others are as much of a priority and need changing at all? I don' envisage us changing the port of civiproxy (as it means then changing the values in the config) or the service name for the ServiceAlias, as these are pretty tightly coupled to the local environment install of CiviCRM. I mean we could, but it feels like the benefits vs the work needed don't stack up which is why I left it out and would be happy to discuss it with you if you feel otherwise. It would have been better to discuss these issues on the gerrit patch before creating tasks I feel. Same again with the rsyslog config, if that is misconfigured it would have been good to know before merging the patch.

Hi! I created a task for follow-on stuff: T281651. The new patch for the API key is now attached to that task, so maybe we can close this one, since Civiproxy dev environment totally reaches a usable state here?

In T280476#7042031, @gabriel-wmde wrote:

Thank you, @AndyRussG this information is very helpful. For the desktop banners of WMDE we have a static 7-second delay before bumping the page content down. I can propose adding an interaction check before displaying point to this discussion. The decision will be made by other people in WMDE.

In T279034#7042610, @DStrine wrote:

@egardner thanks for the note. This is not currently a priority for fr-tech. There are no plans to work on this in the foreseeable future. If it becomes a priority I will initiate the process. Thanks!

In T270731#7032420, @Eileenmcnaughton wrote:

Default offset - we can maybe pass this in from python.
[...]
I think if we did that we could pass in a really really big number to regenerate all the tables with a full dataset

Here are the notes I have so far about stuff to do, summarized from @Ejegg's comment above and from talking to @Eileenmcnaughton on IRC:

• Instead of WmfException, use API_Exception.
• Move concrete queue consumer classes somewhere in the wmf-civicrm Civi extension, maybe to CRM/Queue like here?
• Fix formatting for Drupal norms (no tabs, two spaces).
• Possibly refactor queue consumers to make them more Civi-y, and to have the consumer api less tightly coupled to the code that reads each message and modifies the database. For an example, again, see this patch.
• Maybe add more tests?

Just thinking this over yet again... so, if, for mitigation for infrequent users, we use option (ii) (see the current task description) "choose a banner server-side based on targeting data points available there", we could actually invert the whole proposal. That is, instead of "pageview+1 with exceptions for infrequent visitors and as needed", it could become "server-side banner selection and immediate banner injection, with pageview+1 mitigation for frequent users". (In this case, "mitigation for frequent users" would mean, more or less, preventing them from seeing too many banners, as we currently do, using data stored on the client.)

Just another quick thought... if there are concerns that the banner bump is somehow needed to get users' attention, and that's causing people to worry about an engineering solution... there would be a way to achieve a similar "bump" effect without impacting SEO.

Just noting here, Google has postponed the rollout of its new search ranking metrics to mid-June.

In T280477#7028457, @DStrine wrote:

The banner team will organize tests and integrate them into the asana schedule. There is no plan to reserve a fixed space for banners. This task isn't needed.

In T280476#7028456, @DStrine wrote:

PMs and managers have meetings in place to monitor SEO. This task isn't needed.

AndyRussG raised the priority of this task from Lowest to High.

Just to note: currently not ingressing country since, if I understand correctly, it remains to be determined if a new country selection by the user should cause a new address (empty, except for country ) to be created.

In T279034#7012796, @Gilles wrote:

[...] ideas I've just had [...] Feel free to spin that into a separate task to discuss those ideas separately.

(From T279034)

(Hi, @BBlack, @bd808, @ema... hehe just taking the liberty of adding you to this task, hope that's ok... also, just to emphasize, this task isn't a request for action of any sort... thanks!!)