[05:29:11] Reedy: what do you mean about the global_edit_count table being missing? Is this on an existing wiki where you've not applied (some of) the db_patches from the extension? [05:29:51] asking just to gain a better understanding of the state of things, as I just started to look a little at the extension recently [06:43:54] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralAuth/+/refs/heads/master/includes/Hooks/Handlers/NoServicesHookHandler.php [06:43:59] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralAuth/+log/refs/heads/master/schema/mysql/db_patches/patch-global_edit_count.sql [06:44:17] looks like a separate patch file (for older local installs) did exist for this table [06:44:30] but not registered to MW in any way, so update.php does nothing for it I guess [06:45:04] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralAuth/+/refs/heads/master/schema/mysql/db_patches/patch-global_edit_count.sql [07:15:47] apergos: My dev wiki [07:15:55] That has been around 10+ years in various states :) [07:16:32] ah. mine get exported and re-imported from time to time, every few years I do a full wipe of the os and related partitions [07:17:15] the readme in there or in one of those dirs expicitly states that manual application of changes is required. (but I don't know the rationale for that) [07:18:10] I think it's the "we don't use this in WMF production" and "we couldn't guarantee reliably it would run in the right place" via update.php [07:18:16] (at least historically anyway) [07:18:30] It's not a big deal, but it's funny when things come up [07:19:14] it is a barrier for devs who might be interested in working on this [07:19:28] amir is very much working on it [07:19:44] beta suffers from similar issues, but usually get fixed fairly soon either because someone remembers to run the patch proactively, or because it's clearly broken soon after, and it's obvious [07:19:51] uh huh [07:23:12] while I'm in here: is there some other logging module we should be using rather than the 'LegacyLogger' on our not-wmf-production-wikis? [07:26:58] probably not specifically [07:27:12] I'm not sure I even set that on my dev wiki [07:27:34] mostly defining MW_LOG_DIR in LocalSettings.php and then using whatever DevelopmentSettings.php uses [07:36:38] huh ok [07:36:44] let me have a look at that [07:47:51] apergos: the default logger is indeed called "LegacyLogger" (and LegacySpi). these are constructed automatically and don't require any config (in particular, unless you have a specific custom outcome in mind, you don't need to set wgMWLoggerDefaultSpi LocalSettings.php; $wgDebugLogFile and $wgDebugLogGroups work out of the box). If you use mediawiki-docker, then MW_LOG_DIR and DevelopmentSettings are set and included by default as well, [07:47:51] so you get /w/cache/mw-debug-www.log and /mw-error.log similar to what Jenkins builds store as artefacts. [07:48:53] I was just put off by the name, if you have something called 'LegacyBlah' it seems to me there ought to be a "regular" Blah that is recommended [07:49:10] I don't use mw docker, I'm bare metal all the way :-P [07:50:23] If you use a baremetal setup of your own, then you can accomplish the same by doing e.g. `putenv( "MW_LOG_DIR=$IP/cache" ); require "$IP/includes/DevelopmentSettings.php";` in LocalSettings.php [07:51:15] and yeah, the Legacy part of that should perhaps be removed. It shouldn't be visible anywhere though, given it's the implicit default "Spi" singleton. But it might show in stack traces if you inspect the $logger variable in your IDE. [07:51:27] I wonder where you found it, if not by browsing the code. [07:51:43] I improved some docs around this last week in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/963430 [07:52:32] I could but I have a wikifarm, so I do something a bit different ctually [07:54:40] cool. if you end up needing/wanting some of the Monolog features locally and setting up wgMWLoggerDefaultSpi, we have Monolog\LegacyHandler as a way to emulate the LegacyLogger features such as $wgDebugLogFile [07:55:11] given you can only have 1 Spi active at any given time, and MonologSpi supports multiple handlers/outputs. [07:55:50] taht's what prod uses for some ad-hoc debug features [07:56:17] I was looking into how $wgDebugDumpSql is used, and that led me to this commit https://gerrit.wikimedia.org/r/c/mediawiki/core/+/842940 and that led me right to LegacyLogger :-P [07:57:45] now looking at your patch with doc updates [07:59:45] it says there that the docs for the debug directory ought to show up in the Modules list on doc.wm.o but I must be looking in the wrong place because I do not see it there [08:02:37] I was able to get to it from here however https://doc.wikimedia.org/mediawiki-core/master/php/debuglogger.html [08:23:39] Krinkle: have a typo fix https://gerrit.wikimedia.org/r/c/mediawiki/core/+/965052 [08:30:07] https://www.mediawiki.org/wiki/Manual:How_to_debug perhaps these should be updated to something that doesn't use the "legacy" stuff. ? [11:38:56] tgr|away: or anyone else who cares to answer, in setting up CentralAuth locally on your own system, do you use the same hostname/domain (i.e. "localhost") for the wikis in your centralauth farm, or do you use different names? [11:41:46] apergos: I use local.wmftest.net subdomains [11:42:29] ok, one vote for subdomains, ty [15:57:37] I tend to use subdomains of .localhost which are offline built in to Firefox and chrome and are treated as secure context (can add to /etc/hosts for other tools if needed) [21:02:53] was there some special process to follow to drop tables from production? [21:15:45] usually file a task and ask a DBA [21:15:54] certainly for any sizeable table [21:57:14] thanks Krinkle. I went the .dev route, then learned that google kindly placed that entire tld which it owns on the https only list, so firefox will always redirect http urls for subdomains to https, regardless of your settings and turning the feature off in the browser and etc. [21:57:22] so then I went the ".test" route [21:58:36] is it my imagination or was the whole "you log in separately to each wiki family" deal not always a thing? I kind of feel like in the earlier SUL one login got you everywhere (except foundationwiki, wikitech, mw.org) [21:58:54] and with that question I'm off to bed