[00:00:38] ooh, drupal memcache module seems to be really simple to set up, and cleans up a TON of those registry lookups [00:00:59] cwd: is there a memcache we can talk to on frdev1001? [00:04:02] hmm, or is there an equivalent module for redis? [00:13:46] ejegg: we should try this https://www.drupal.org/project/redis [00:24:40] definitely [00:25:46] i guess I don't have SUCH high hopes for it, since the lookups are already only done once per class for the whole batch run [00:34:48] ejegg: memcache instead of redis? [00:43:35] cwd sorry, turns out there's a redis extension too [00:44:12] memcache was just the first one I saw when I looked for things to stop all the drupal autoloader db lookups [01:14:29] ah cool [01:32:19] (PS1) Ejegg: WIP use redis to cache drupal lookups [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/458089 [02:15:46] (PS1) Ejegg: WIP Stop writing to queue2civicrm_log [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/458091 [02:39:24] ejegg: perm fixed [02:39:33] thanks! [02:39:51] I just tried with the drupal redis module, and not much difference in the queue speed [02:39:59] might be less confusing to hide some rows since I’ve been doing 3 on each [02:40:12] but it's probably still worth it to speed up page loads [02:40:14] I’ve been surprised by what doesn’t make much difference [02:40:16] and quick jobs [02:40:34] I thought this would show up as significant https://github.com/civicrm/civicrm-core/pull/12773 [02:42:21] Shoot, i'd think so too [02:42:35] huh, the queue2civicrm_log table doesn't seem to be our problem either [02:43:06] just testing the patch to stop inserting/updating there (it's a huge table) and performance is actually slower [02:43:31] there is def stuff to try on the wmf_donor data but I think for today I’ll focus on the bits & pieces around it & hone in on tht tomorrow [02:45:03] What do you think about adding the drupal redis module even if it's not a queue speed booster? [02:45:07] Aside just been listening to this on attention - https://www.stitcher.com/podcast/vox/the-ezra-klein-show - it’s pretty good [02:45:28] Adding drupal redis seems to make sense to me [02:45:46] I wonder if we can curl a page & see a difference? [02:45:53] cool, i could use a new podcast in my mix. the latest one looks interesting [02:46:08] yeah that was specifically what I was referring to [02:46:37] save the podcast & it’s kinda like having a David on tap when you need to be reminded how to focus better :-) [02:47:01] ack, looks like I broke something [02:47:12] the perf test seemed to run fine, but no UI [02:47:43] lol [02:47:57] I thought killing those watchdogs would help but not really [02:48:48] hm, where should we see those errors? [02:48:55] ejegg: is drupal configured with redis password [02:49:09] this sort of thing when running drush qperf WD wmf_campaigns: Campaign C14_deAT_FR is missing WMF Campaign info. [02:49:32] we have a test tomorrow & it’s the first one since civitoken caching? [02:49:58] eileen: it does have the password [02:50:02] hmm [02:50:04] cribbed from the civi settings file [02:50:17] :-) [02:50:51] ah, the civi token caching isn't deployed yet [02:50:55] let's get that out [02:50:58] oh it’s not? [02:51:11] yeah we might see a bit better speed tomorrow [02:51:47] but I'm still not seeing the php errors in /var/log/*, just a 500 status in apache2/civicrm-access.log [02:52:29] this is for Redis? [02:55:13] right, since I added the drupal redis settings I'm getting a white screen of death on frdev [02:55:25] and no helpful errors in logs [02:59:20] dangit, that same set of $conf lines is working for me locally [02:59:28] well, with the pw changed [03:00:32] hmm [03:00:39] flush caches? [03:00:51] heh, good call [03:01:05] ...but no dice [03:01:22] Is there someplace I should be looking for the errors? [03:02:31] I'm just trying to load a drupal page (/admin/modules), not anything Civi [03:03:09] oh hey, it's in 'messages' [03:03:19] PHP Fatal error: Class 'Redis' not found [03:03:35] so... I think we need to restart the apache2 service? [03:03:57] hmm - that class is in the new module? [03:04:03] (which is enabled I guess) [03:04:23] perhaps it’s a loop - need the class to find the registry & vice versa [03:04:25] it's part of the native redis PHP extension [03:04:29] drush rr might work [03:05:28] cwd mind restarting apache2 on frdev1001? [03:05:40] if you're still up for some reason... [03:06:51] ejegg: didn’t I use php-redis though with Civi [03:07:29] eileen: huh, interesting. It would have worked via CLI because that loads all the extensions new each time you run it [03:07:37] did you check out the UI while you had it enabled? [03:08:07] I think it's just the apache process which doesn't know about it yet [03:08:11] ejegg: no - it’s just a one word change in civicrm.settings.php [03:08:28] did you check the readme “Please read README.PhpRedis.txt file for configuration and documentation. PhpRedis is the recommended connector. [03:08:28] “ [03:08:28] ok, i'll try disabling it in drupal [03:09:06] ah not much in there [03:09:54] ok, disabled in drupal's settings.php and I can see the drupal UI again [03:10:04] ...and the Civi UI [03:10:11] now to enable it in Civi's settings [03:10:50] eileen: ahh, I see you have it wrapped in if (class_exists('Redis')) { [03:11:17] hmm yeah it slowed down so something must have changed [03:11:39] I think I need to try some debug as to when cache is being hit & when it does / doesn’t return something [03:11:50] yeah, if I take that if out and just define the CACHE_CLASS as 'Redis' I get a whitescreen [03:12:10] on the civi pages, but not on drupal pages [03:13:00] oh, are you running another perf test? [03:13:24] lol yeah [03:13:33] it was a bit slower on the last run [03:13:36] ok, apache still can't find the class [03:13:40] hmm [03:13:54] PHP Fatal error: Class 'Redis' not found in civicrm/CRM/Utils/Cache/Redis.php on line 84 [03:14:01] just needs a restart [03:14:09] ah so when I switched over I didn’t really [03:14:18] wonder why it was slower then [03:14:18] eileen: ah, but you did for CLI [03:14:26] oh I ee [03:14:27] see [03:14:40] we just can't test the speedup in the UI [03:14:50] which is probably where caching will actually help, right? [03:15:39] well likely since array caching probably does quite well in the queus [03:15:46] ah yeah [03:16:29] ok, swapped the civi config back to array caching [03:16:44] Oh, I should add the lines for my other tests to the spreadsheet [03:16:51] yeah [03:17:39] I’m getting a non-compelling improvement with the revised version of https://github.com/civicrm/civicrm-core/pull/12773/files - I think if we deploy civitoken caching today & then after wed deploy that caching fix we can also take some stats off the live q performance [03:17:51] cool [03:18:32] let's see, I had the account caching + drupal redis [03:18:47] then the account caching + drupal redis + no queue2civicrm_log [03:19:25] and neither helped much [03:22:39] (PS1) Eileen: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/458094 [03:22:50] (CR) Eileen: [C: 2] Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/458094 (owner: Eileen) [03:23:16] I’m really surprise what things don’t help - I guess mysql caching is helping us out but still even cached queries have a cost [03:24:40] (Merged) jenkins-bot: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/458094 (owner: Eileen) [03:27:58] Fundraising-Backlog, Technical-Debt: [FundraisingLandingPage] should not double escape - https://phabricator.wikimedia.org/T203142 (AndyRussG) Hi! Thanks much for finding this cruft!!! It's clear that it should be fixed... Still, I'd like to delay doing so until after the new FR EventLogging pipeline is... [03:33:35] hmm, how bad would it be if we just didn't update modified_date on related table updates? [03:34:02] would that actually bust anything? [03:35:33] no - we don’t use that field much [03:35:45] we haven’t tested the impact of turning it off [03:35:57] I got a material change by hacking out the acl cache clearing [03:36:39] up to 5% I think [03:36:51] nice [03:36:53] (although I’m not sure ‘hacking out’ is the final fix we want) [03:37:01] 5% here, 5% there and we're all set [03:37:18] lol - yeah but I don’t want to get there just by hacking core [03:38:36] thank you for being the voice of reason... [03:38:41] :-) [03:39:27] Tim is away this week but when he gets back I might try to discuss the best approach -we have an approach for the group cache that we could use [03:40:41] I’m gonna try to eliminate the last pointless-query-per-insert & then try some Redis ‘does it hit / get from cache’ tests [03:41:04] oh yeah - just gonna deploy civitoken caching now [03:41:26] cool [03:41:37] ejegg: did you run the script to disable that audit module earlier? [03:41:49] eileen: yep [03:41:53] cool [03:42:22] looking back in the sql logs, there's a bunch of stuff the api does that it would be nice to be able to supress when we know we don't need it [03:42:53] !log civicrm revision changed from 7bde3d0ab2 to 7918924e73, config revision is 0b227269a8 [03:42:56] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [03:43:19] like when we're adding an email to a totally new contact, there's no need to "UPDATE civicrm_email SET is_primary = 0 WHERE contact_id = XX" beforehand [03:44:04] hmm - I think that is in a part of the code that doesn’t know if it is a new contact though isn’t it? [03:44:25] Weird, then after we insert the email we select it back out, just the 'email' field and nothing else [03:44:37] :-) [03:44:47] and then a select from uf_match [03:44:57] yeah - I feel like some concept of lazy load with a better object use would make sense [03:45:21] eileen: right, that email bit is just in the email create api call [03:45:39] i was just thinking it could take another parameter to skip steps like that [03:46:30] hmm - so far I haven’t seen great performance gains on skipping a lot of pointless selects - although mysql caching might be the hero there [03:47:02] yah, i was talking about skipping the update [03:47:43] hmm yeah - I think the code is in Block::handlePrimary [03:48:39] although in email I see [03:48:40] public static function create($params) { [03:48:40] // if id is set & is_primary isn't we can assume no change [03:48:42] if (is_numeric(CRM_Utils_Array::value('is_primary', $params)) || empty($params['id'])) { [03:48:43] CRM_Core_BAO_Block::handlePrimary($params, get_class()); [03:48:43] } [03:49:15] hmm, we wouldn't have ID set on the email for that call [03:49:18] just contact_id [03:49:25] ejegg: yeah - I can see an easy change to try there [03:50:02] ah no [03:50:10] because it is the email id that is known [03:50:19] not whether the contact id has another email already [03:51:18] right, we know that from context when we're making the API call (if we just created the contact) [03:51:35] but we'd need to pass another param or something [03:51:50] likewise with address [03:53:04] whew, there are some CHUNKY bits put in civicrm_cache for exportableFields [03:53:21] like 5 screenfulls of base64 [03:53:22] yeah - well I guess we should try commenting out that line & testing without it to see how much difference it makes [03:54:23] Hmm, I'll try to track down that duplicate wmf_contribution_extra insert [03:55:33] ejegg: I think it’s from php land because of that source / currency thing? [03:55:34] ohh, it's doing the source_ fields separate from the main ones [04:12:10] eileen: ahh, I see, the post hook runs and inserts the gateway, gateway_txn_id, original_amount, original_currency, and entity_id. Then after that, the Contribution save process continues and inserts the source_ fields from the message (with an on duplicate key update) [04:12:30] so how the heck could we combine those? [04:12:37] ejegg: yeah - it got tricky [04:13:05] the thing that makes me feel ok-ish is knowing that at least the test coverage is good to we can tinker with a backstop [04:13:23] but it’s tricky [04:13:54] I think we can calculate source earlier though? [04:15:50] yeah? [04:16:18] Hmph, that post hook can't mess with the 'custom' params that end up doing the second insert [04:18:29] what time is it there? [04:18:43] late :S [04:19:10] again, thanks for being the voice of reason! [04:19:30] i'mma head to bed [04:20:51] :-) [04:23:01] so... we move the contribution muckery to a 'pre' hook that just sets the custom values in the params (i.e. not saving to a table) I think that gets us a single wmf...extra insert? [04:25:45] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: wmf_contribution_extra table is inserted twice for a single contribution insert - https://phabricator.wikimedia.org/T203537 (Ejegg) [13:13:10] jgleeson: hey! morningz :) all good any time you'd like to chat 'bout FRUEC... [13:13:59] I just have a couple not-too-long meetings this morning, besides standup... One from 7-7:30 am Pacific Time, and another from 10:30-11 a Pacific [13:14:10] (both on my calendar) [13:14:13] other than that, anytime is cool! [13:26:33] morning AndyRussG :) I've got my 1:1 just now but straight after works for me [13:26:52] jgleeson: I think right after that is my 1:1 [13:27:00] ha [13:27:03] so maybe rather 1 hour from now? [13:27:08] sure! [13:27:13] okok! :) [13:58:36] Fundraising Sprint Lactose is unusually tolerant, Fundraising Sprint Matt Damon to head up Space Force, Fundraising Sprint Naming Sprints Is Not Important, Fundraising Sprint Owls, and 4 others: DB schemas (production changes and test DB) and SQL commands ... - https://phabricator.wikimedia.org/T196564 [14:39:59] jgleeson: done my call, just gimme 10 minutes to finish getting breakfast together? [14:41:58] sure sure [14:55:08] jgleeson: k all set! [14:56:07] shall we use the queenmary? [14:57:56] jgleeson: sure [15:00:24] fr-tech any news for scrum of scrums (in 1/2 hr)? [15:12:35] ejegg: all good here, thanks! [15:21:21] argh, how did we get a message without the gateway_txn_id? [15:21:51] from payments, so nothing to do with the new IPN listener [15:28:19] Fundraising Sprint Queue is pronounced GJif, Fundraising Sprint Raw data can give you salmonella, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Thank You email for Stripe Import - https://phabricator.wikimedia.org/T202099 (Ejegg) @LeanneS and @jkim_wikimedia : This is... [15:33:55] nothing from me ejegg ! [15:55:37] Fundraising-Backlog, FR-PayPal-ExpressCheckout: Deal with PayPal error code 13116 - https://phabricator.wikimedia.org/T203579 (Ejegg) [15:58:29] https://phabricator.wikimedia.org/T201203 [15:59:37] ah man [16:02:29] jgleeson: everything ok? [16:02:48] yeah I was just reading the phab link posted by cwd [16:03:09] looks like we have some tracking stuff sneaking in [16:03:35] hey fr-tech, shouldn't our very own Saurabh be on this list? https://wikimediafoundation.org/2018/08/27/google-summer-of-code-outreachy-round-16/ [16:05:22] :( a glaring oversight jgleeson [16:05:46] harrrghghghg [16:06:21] back in a bit, I have a dog that's desperate to run outside and smell other dog's pee [16:06:25] dogs' [16:07:09] ha, have fun! [16:07:29] mepps, I'm gonna see if I can contact the authors and ask them to update it [16:21:54] (PS1) Ejegg: Test for mangled SET_PAYMENT response [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/458208 (https://phabricator.wikimedia.org/T203126) [16:22:59] Fundraising Sprint Queue is pronounced GJif, Fundraising Sprint Raw data can give you salmonella, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Thank You email for Stripe Import - https://phabricator.wikimedia.org/T202099 (Ejegg) p:Triage>Normal a:Ejegg [16:24:24] (CR) jerkins-bot: [V: -1] Test for mangled SET_PAYMENT response [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/458208 (https://phabricator.wikimedia.org/T203126) (owner: Ejegg) [16:32:03] heh I think he had more fun than I did :) [16:37:23] (PS4) AndyRussG: Inline doc and comments [wikimedia/fundraising/FRUEC] - https://gerrit.wikimedia.org/r/457275 (https://phabricator.wikimedia.org/T195594) [16:42:15] Fundraising Sprint Pluto is still a planet, Fundraising Sprint Queue is pronounced GJif, Fundraising Sprint Raw data can give you salmonella, Fundraising-Backlog, and 3 others: Deal with Ingenico Connect code 300620: MerchantReference XXXX already exists - https://phabricator.wikimedia.org/T201773 (... [16:52:16] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: trait / inheritence property collision in some CRM tests - https://phabricator.wikimedia.org/T203582 (Ejegg) [17:28:38] Fundraising Sprint Karma chameleons hide amongst us, Fundraising Sprint Lactose is unusually tolerant, Fundraising Sprint Matt Damon to head up Space Force, Fundraising Sprint Naming Sprints Is Not Important, and 10 others: Create Ingenico orphan rectifier ... - https://phabricator.wikimedia.org/T163949 [17:43:30] Fundraising-Backlog, Fr-CentralNotice-Translation-Bugs, MediaWiki-extensions-CentralNotice, MediaWiki-extensions-Translate: Change (centralnotice-preview-all-template-translations) link target - https://phabricator.wikimedia.org/T158508 (Ejegg) [17:43:33] Fundraising-Backlog, Fr-CentralNotice-Translation-Bugs, MediaWiki-extensions-CentralNotice, Easy: CentralNotice: "Preview all approved translations" is dead - https://phabricator.wikimedia.org/T105558 (Ejegg) [18:30:42] (CR) XenoRyet: "I've made the change on the ingenico side, and sandbox should be working now." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/456519 (owner: XenoRyet) [18:32:02] (PS4) XenoRyet: Change Payment Products filter [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/456519 [18:32:37] ejegg: ^ That one's ready for testing if you have a minute. [18:33:48] well I'm confused [18:34:10] What's up? [18:34:21] the return URL that the ingenico sandbox hits after a donation attempt is; http://payments.wiki.local.wmftest.net:8080/wiki/Special:IngenicoGatewayResult?order_id=2089992553.11&hostedCheckoutId=&RETURNMAC=23b14955-fcfe-491e-939f-5ecbae3fb3e2&isFramed=true [18:34:57] but if I browse to that URL direction (I've chopped off the hostedCheckoutId for testing) it doesn't get to making a request to ingenico [18:35:10] s/direction/direct/ [18:36:10] although presumably the same URL works fine when it happens as part of the donation process... [18:36:22] hmm [18:36:55] I tried messing with the isFramed flag. I figured that might re-request the same URL [18:37:41] my latest theory is somehow that URL getting broken somewhere in transit, resulting in an empty hostedCheckoutId. [18:38:10] although if I can simulate the error locally, with the suspected offending URL, then that theory is probably out [18:38:43] (using theory liberally) [18:38:54] Sounds like as good an idea as any [18:39:42] nick jgleeson|dinner [18:39:49] Fundraising-Analysis, Analytics-EventLogging, Analytics-Kanban: CentralNoticeImpression occasionaly fails validation on device enum field - https://phabricator.wikimedia.org/T203597 (Ottomata) [19:14:15] (PS5) Ejegg: Change Payment Products filter [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/456519 (owner: XenoRyet) [19:14:43] (CR) Ejegg: [C: 1] "OK, that looks good now. Can you note what you had to change on the Ingenico console side?" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/456519 (owner: XenoRyet) [19:20:47] (CR) XenoRyet: "Yea, no problem. Sign in to the configuration center, go to 'Look & Feel', edit the variant in question. Under 'Variant settings', tick " [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/456519 (owner: XenoRyet) [19:37:43] (PS2) Ejegg: Use redis to cache drupal lookups [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/458089 [19:52:46] (CR) Ejegg: [C: 2] Change Payment Products filter [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/456519 (owner: XenoRyet) [19:54:48] (Merged) jenkins-bot: Change Payment Products filter [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/456519 (owner: XenoRyet) [19:56:12] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Support Tracking endowment contributions in civi - https://phabricator.wikimedia.org/T203601 (DStrine) [20:20:22] Fundraising-Backlog: custom logo and text for endowment donation form - https://phabricator.wikimedia.org/T203603 (DStrine) [20:29:27] mepps were you able to get past that 'class not found' problem? [20:30:23] (PS4) Ejegg: Delete old GlobalCollect audit [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/434597 [20:39:46] cwd would you mind restarting apache2 on frdev? Looks like the cli can see the redis extension but the web UI is still unaware of it [20:40:30] ejegg: sure [20:40:37] thanks! [20:41:43] hecho [20:49:13] Fundraising-Backlog, FR-Smashpig, Fr-Ingenico-integration_2017-18, MediaWiki-extensions-DonationInterface: Trying to get hosted checkout status with no hosted checkout ID - https://phabricator.wikimedia.org/T203406 (jgleeson) a:jgleeson [20:50:11] mepps for what it's worth I'm still getting 'class not found' on my opt-in consumer, but that's more a drupal autoloader thing [20:52:00] Fundraising Sprint Owls, Fundraising Sprint Pluto is still a planet, Fundraising Sprint Queue is pronounced GJif, Fundraising Sprint Raw data can give you salmonella, and 2 others: Queries and maybe scripts to verify equivalence of data in new-Kafka-pipelin... - https://phabricator.wikimedia.org/T198752 [20:53:51] ah shoot [20:53:58] fr-tech: I've just noticed that standup tomorrow overlaps with the staff community time meeting, and we've got the advancement retro immediately following that. I could move standup to 8:30, but I probably couldn't make that myself, or we could do it after, but it looks like mepps isn't free until around 2:30 Pacific. We could also maybe just do an email standup tomorrow. Opinions? [20:53:59] I forgot (again) to try that ejegg [20:56:56] Maybe I'll just move it to 8:30 and see if I can get little Dylan to join me. That should work. [20:57:14] 8:30am pacific XenoRyet ? [20:57:19] Yea [20:57:55] it works for me but if that's early for you later/email stand-up is fine for me [20:57:57] That'd be 3:30 UTC I guess [20:58:21] I'm up at that time, I'm just usually watching the kids and helping get them off to school. I think I can work in a quick standup. [21:00:06] ejegg reinstalling everything with composer helped me [21:00:12] * ejegg discovers issue with opt in class, smacks own forehead [21:00:28] so, I've got a separate civi and drupal db for phpunit [21:01:19] and in the settings files there are conditional blocks around the databases to use different strings depending if WMF_CRM_PHPUNIT is defined [21:01:48] there's a line defining that at the top of settings, which I usually keep commented out [21:02:09] and I made a couple of aliases to quickly uncomment and comment it [21:02:27] but I didn't think about running the 'comment' alias multiple times [21:02:48] so when I though I was uncommenting it, I was just removing one of the # marks [21:02:54] and leaving another [21:03:02] anyway... working now [21:05:40] tricky! [21:05:50] and silly [21:05:57] I just added the queue and was about to run the test [21:06:06] I'll give it a go eitherway [21:06:27] don't expect it to work yet! The tests are expected to fail [21:06:46] I have a big fat TODO in the method that should actually opt someone in [21:07:01] and it looks like i'm not finding the custom field ID correctly either [21:08:24] mepps glad that worked for you! [21:10:03] hmm [21:10:19] so I got the Error: Class 'queue2civicrm\unsubscribe\OptInQueueConsumer' not found [21:10:23] which drush cc all fixed [21:10:29] jgleeosn: yep yep [21:10:44] also as expected [21:10:44] but now I'm getting SmashPig\Core\ConfigurationKeyException: Configuration key 'data-store/opt-in' does not exist. [21:10:52] even after adding in the block [21:10:54] @_@ [21:11:00] oh, i think you also have to composer install [21:11:07] oh? [21:11:11] there's a v minor smashpig update in there too [21:11:33] adds the opt-in queue and a test version [21:11:58] ok that's moved me to: Undefined index: custom_ [21:12:08] is that the expected failure? [21:12:20] heh, cool, that's what I'm trying to fix right now [21:12:26] Thanks! [21:12:36] sorry it took so long! [21:12:40] no worries [21:12:46] ok now for some packing! [21:12:50] g'night fr-tech [21:12:54] gnight [21:15:18] where is Jack at the moment ? I know he told me but I am getting confused [21:15:23] or perhaps I just am [21:15:30] I think he's still in England [21:15:48] but he'll be in Cyprus [21:43:47] Fundraising-Backlog: custom logo and text for endowment donation form - https://phabricator.wikimedia.org/T203603 (DStrine) logo: https://commons.wikimedia.org/wiki/File:Wikimedia_Endowment_-_narrow.png [21:49:16] (PS4) Ejegg: Opt-in queue consumer [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/456517 (https://phabricator.wikimedia.org/T200576) [21:51:44] ready for review fr-tech ^^^ [21:51:50] gonna relocate right quick [22:00:37] (PS1) XenoRyet: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/458311 [22:03:55] is there tech talk [22:04:12] Oh, is it time for that? [22:04:28] I'm in the middle of a deploy, but other than that I'm around if someone's got something to talk about? [22:04:42] (CR) XenoRyet: [C: 2] Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/458311 (owner: XenoRyet) [22:05:43] (Merged) jenkins-bot: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/458311 (owner: XenoRyet) [22:08:59] (PS1) XenoRyet: Update DonationInterface Submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/458313 [22:11:07] (CR) XenoRyet: [C: 2] Update DonationInterface Submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/458313 (owner: XenoRyet) [22:13:35] (Merged) jenkins-bot: Update DonationInterface Submodule [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/458313 (owner: XenoRyet) [22:17:36] !log updated payments-wiki from e749025c1a to 05d796e844 [22:17:40] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [22:33:00] XenoRyet: we're in the meet if you want to talk queue optimization [22:33:10] Oh, cool. [22:33:15] Be there in a minute or two. [22:53:38] (CR) Ejegg: [C: 2] Move tivy theme out of drupal managed themes dir (needs crm patch at same time [wikimedia/fundraising/crm/drupal] - https://gerrit.wikimedia.org/r/457703 (owner: Eileen) [23:00:06] (Merged) jenkins-bot: Move tivy theme out of drupal managed themes dir (needs crm patch at same time [wikimedia/fundraising/crm/drupal] - https://gerrit.wikimedia.org/r/457703 (owner: Eileen) [23:01:34] (PS3) Ejegg: Move tivy theme out of drupal managed themes dir [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/457702 (owner: Eileen) [23:01:54] (CR) Ejegg: [C: 2] Move tivy theme out of drupal managed themes dir [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/457702 (owner: Eileen) [23:08:23] (Merged) jenkins-bot: Move tivy theme out of drupal managed themes dir [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/457702 (owner: Eileen) [23:20:51] ejegg: i'm taking off for a friend's 40th in a minute, anything you think you'll need tonight? [23:21:09] think I'm all set cwd. Have fun! [23:21:49] thanks! [23:22:14] hi, Could you please disable fundraising message for Japan (e.g. 1 month)? In recently, Japan have some disaster occurred. For this, If continues fundraising, I think readers may feels bad mind for fundraising message and WMF. [23:49:39] hmm. It is https://meta.wikimedia.org/w/index.php?title=Special:CentralNotice&subaction=noticeDetail¬ice=C1819_jaJP_dsk_FR [23:59:59] hi rxy, I'm not in charge of the schedule, but I'll pass along your message to the people who are