[14:08:58] Hi, I have an Issue with using MariaDB in a MediaWiki Docker Container. Maybe someone can help? [14:08:59] I created a Docker Image based on the Quickstart Guide. I added MariaDB with a replica as a database behind it. The Mediawiki itself runs without problem. The Extension I was writing does so aswell (also communicates with the database). Now I wanted to install an additional extension, but when I run update.php to make the extension create it's [14:08:59] tables I get the following Error message: [14:09:00] Wikimedia\Rdbms\DBConnectionError from line 1309 of /root/docker-image-mediawiki/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php: Cannot access the database: php_network_getaddresses: getaddrinfo for mariadb-main failed: Temporary failure in name resolution (mariadb-main) [14:11:30] looks like a dns issue? [14:14:31] Is there a way to check this/fix this? I couldn't find anything regarding that in the Mediawiki. I'm sorry if my question is stupid, I'm relativly new to both MediaWiki and Docker. [14:29:07] Guest85: you could open an interactive shell in the docker container and see what a DNS query gives you for "mariadb-main" [14:29:17] are you using plain docker or docker compose? [14:29:30] I use docker compose [14:35:33] Whats the name of the db service in the compose file? [14:35:45] here is my docker-compose.override.yml : https://dpaste.org/2oT7b [14:36:40] as you can see in file above it's "mariadb-main" [14:39:13] Is the mediawiki container also part of that compose file? [14:40:13] it's part of the original docker-compose.yml [14:41:33] could you also paste that? [14:42:48] yes i'm on it, but I might already found the problem [14:43:16] https://dpaste.org/pTrG9 [14:44:00] I only added proxy to it and never touched it again. I just noticed, that there is still sqlite set as DB type [14:48:11] okay no, it's still not working [14:54:13] Alright so what I did is to setup the project, create a local shell in the mediawiki container, install dnsutils and do a "dig mariadb-main" (which worked as expected) [14:54:21] is this the case for you aswell? [14:55:09] I will try it [14:58:31] And maybe another (easier) question: Is the db actually running? I had a typo in the override filename at first and so it wasnt even starting xD [14:59:30] yes it is running, as I said the wiki and my own written extension have access to the database [15:07:09] I have to be honest, I'm kind of struggling right now installing dnsutils, because when I try to use "apt-get install dnsutils" inside the Docker Bash it tells me, that it is unable to locatio package dnsutils [15:15:26] Guest85: you have to "apt update" beforehand [15:22:33] Oh Sorry, didn't notice I timed out here. But I saw what you wrote in the log. He doesn't seem to connect to the internet with apt-get update [16:05:14] okay, that was something a restart fixed [16:06:13] I will install dnsutil and write here once I can give you the result. [16:06:13] But anyway, thank you very much for your help! [16:08:23] okay no, nevermind, I'm an idiot, I run apt update from outside the dockerĀ '=( [16:25:06] do you allow 'article' or 'section' HTML tags in MediaWiki? [16:30:46] kv4fv: T25932 [16:30:46] T25932: Allow use of semantic HTML5 elements in wikitext - https://phabricator.wikimedia.org/T25932 [16:36:11] Thanks! [20:18:29] Sorry for asking again. Is there an owner or maintainer for ConfirmEdit that has +2 permission? The extensions look semi-abandoned and there are many unreviewed patches. Since it is a highly-used and bundled extension, it is worth a while to look into. [20:22:10] there's less than 20 open patches! ;) [20:22:11] https://gerrit.wikimedia.org/r/q/project:mediawiki/extensions/ConfirmEdit+status:open [20:24:48] i can review simple/uncontroversial patches, but i can't promise to spend time on more complicated ones [20:24:51] https://www.mediawiki.org/wiki/Developers/Maintainers says "Editing Team" [20:25:06] andre: lol [20:26:19] MatmaRex: I think one of the patches atxatx4928[m] wants reviewing may be in your wheelhouse... https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/866798 [20:27:16] yeah, i was just reading it [20:27:37] Both stewards haven't been active for more than a year. I was looking through the commit of ConfirmEdit and it looks like it is basically on life support so that FancyCaptcha will not break on production :S [20:27:58] i'm a little confused why the old version would not be working. but the new version is nicer anyway [20:28:38] Yeah that one was brought to my attention since I wrote the hCaptcha implementation. I verified it and ReCaptcha is also broken as well. Once this is code reviewed I will get the ReCaptcha in [20:29:14] It seems that the old way of getting config isn't working anymore, could be core-related but I am not sure [20:29:37] atxatx4928[m]: i don't have either of those set up locally, but if you promise that you tested it and it works, i'll merge it :D [20:30:28] I tested hCaptcha locally on 1.39, but the hook I used is available since 1.35 so it should be fine [20:31:02] ooh, i blame Reedy: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/768206/1/hCaptcha/includes/Hooks/ResourceLoaderHooks.php [20:31:09] on line 22 the namespace name was not updated [20:31:31] I knew it is one of the namespace patches haha [20:32:19] Either way my goal is to consolidate ReCaptcha and hCaptcha into the same class, since there are already a lot of duplication: https://phabricator.wikimedia.org/T324925 [20:33:14] They are both triggered by Javascript and require custom VE implementation, so it is more natural if they extend from the same class instead of building from SimpleCaptcha [20:33:17] MatmaRex: This is why ::class is much better :P [20:33:47] sounds okay to me. as long as you don't consolidate them with FancyCaptcha or anything we use in WMF production (since we don't want to have a way to accidentally call out to those services) [20:33:53] Reedy: true [20:35:57] No it will be a different class extend from Simple, shouldn't touch anything else [20:37:13] Btw Reedy are you still working on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/778564? [20:37:15] * on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/778564 ? [20:41:15] atxatx4928[m]: It's waiting for someone to review and merge it [20:41:24] I don't think there's anyhting else to "work on" [20:58:09] i can merge it i guess [20:59:55] Thanks folks for looking into it! [21:02:09] Reedy: do we need more class_alias stuff? since the captcha class names go into site configuration? [21:02:53] hmm, or is that only a thing for FancyCaptcha [21:02:55] We don't tend to bother unless we need it for WMF config [21:05:40] seems like an unfun breaking change [21:07:04] We haven't really got a "good" way of highlighting that that is deprecated, so people will just use the aliases... and it'll break later [21:07:32] i'd just keep them forever :) [21:08:01] Then we never get the benefits of moving away fully from autoload classes :P [21:08:06] (ie to namespaces) [21:08:42] Done properly, the sysadmin shouldn't be setting wgCaptchaClass manually [21:08:53] They should be relying on the relevant wfLoadExtension() setting it for them [21:09:06] and/or it shouldn't really be tied to the PHP class name [21:10:34] welllll yes but, everyone does it, including us apparently https://codesearch-beta.wmcloud.org/search/?q=wgCaptchaClass [21:11:00] but also, yeah, maybe this shouldn't be tied to the PHP class name [21:11:24] so instead of class_alias, it could be some "manual" alias in ConfirmEdit code? [21:11:28] to keep the old values working [21:12:03] the code is kinda nasty already [21:12:03] $class = $wgCaptchaClass ?: SimpleCaptcha::class; [21:12:04] $wgCaptcha = new $class; [21:12:34] looks easy to add back-compat to that :D [21:12:53] lol [21:13:07] I know they're sub extensions... [21:13:16] So it's hard coding in one for the others... [21:14:44] I guess add the aliases now... [21:14:52] Back compat can be added later/when aliases are removed? [21:17:11] * Reedy wonders if anyone is actually using SimpleCaptcha [21:18:48] ok now I'm confused [21:18:55] SimpleCaptcha isn't in AutoloadClasses? [21:20:36] Doesn't everything extend Simple? [21:20:40] Yup [21:20:51] But I don't see how MW knows where it is [21:21:00] unless there's some random require/include somewhere [21:21:08] https://phabricator.wikimedia.org/T177133 [21:21:52] That is also what T178599 was trying to address [21:21:52] T178599: Make CAPTCHA modules inherit the abstract base CAPTCHA class - https://phabricator.wikimedia.org/T178599 [21:25:23] oh, wait [21:25:28] I guess I namespaced that before? [21:25:46] makes more sense [21:28:38] seems I never added hCaptcha to the phan dirs either - https://gerrit.wikimedia.org/r/867717 [21:28:44] MatmaRex: ALIASES ADDED :P [21:29:06] :O [21:30:12] I think I namespaced it when I implement it [21:31:00] ? [21:31:22] Nevermind mixed up with something else :S [21:31:37] +2'd, hope it all works correctly [21:32:36] it can break beta [21:32:42] and production in the new year [21:48:52] very reassuring [22:04:25] ikr?