Mon, Jun 7
For testing locally, just added a setting in the private config repo for fundraising-dev.
Thu, May 27
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?
Mon, May 24
Tue, May 18
Sun, May 16
May 14 2021
May 13 2021
May 12 2021
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).
May 11 2021
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?
May 10 2021
May 8 2021
May 7 2021
I think this may be all done?
May 4 2021
May 3 2021
May 2 2021
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?
May 1 2021
Apr 30 2021
Apr 29 2021
Apr 28 2021
Apr 27 2021
Apr 26 2021
- 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?
Apr 25 2021
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.
Apr 23 2021
Just noting here, Google has postponed the rollout of its new search ranking metrics to mid-June.
Apr 22 2021
AndyRussG raised the priority of this task from Lowest to High.
Apr 20 2021
Apr 19 2021
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.