[06:06:59] Good day, I am here seeking information on, if perhaps, there is an already built out iso9001 certification QMS system using wikimedia which I can avail myself of? [08:35:39] I have problem with 'first configure'(or something you have to do when you setup your wiki). I selected 'SQLite' as database and it fails to create database at the end of process. Any good idea of determine the reason of this problem? [08:36:44] I set language as Korean so It is hard to just copy & paste error message because you will have to translate the message yourself... [09:01:38] you can always figure out what variable is used for the error message, or copy and paste it 1:1 so others can look it up in the translation file, and figure what variable is used, therefor what the error would be in their own language [09:04:37] it was [09:05:29] `[path-to-sqlite-database].sqlite 데이터베이스 파일을 만들 수 없습니다.` [09:05:58] and I cannot find where I can find that translation in `languages` directory [09:07:13] oh I found it. `config-sqlite-cant-create-db` [09:16:15] it is 'Could not create database file' in english [09:18:34] TetraTheta: Check folder permissions. php must be able to write to that directory. If permissions are correct, check if you have SELinux or similar enabled that would prevent the creation of the file [09:19:55] since I use ubuntu, it seems there isn't SELinux in my machine. [09:20:14] and what user does PHP to access directories? [09:24:02] TetraTheta: usually, that would be the user "www-data" [09:26:21] If in doubt, give the folder 777 permissions, test that MediaWiki creates the file, then adjust permissions back again to readonly, giving only permissions to modify the sqlite file [09:29:44] what is disadvantage of keeping permission 777 of mediawiki data directory instead only set 777 permission on database files? [09:40:34] ok problem solved and I think everything works fine. thanks! [16:59:51] Hi and big thanks for the awesome software and support. Got a non-urgent question this time [17:01:19] I was looking on the search engine if there is a way to reset all users' passwords en-masse. The reasoning is that should the password hashes get stolen, it would be very nice to force a random password to be set and emailed to all of the users of the wiki [17:02:30] A hacker would hook this up to emailing and a control script and done, but I'm no hacker https://www.mediawiki.org/wiki/Manual:ChangePassword.php [17:13:04] password hashes aren't useful nowadays. However, resetting all user's passwords would lock up users without a valid email address [17:13:38] users without a mail address are spammers. :P [20:00:38] I thought that if some intruder gains the password hashes he/she can attempt to break them at CPU speed [20:02:43] Depends if they get the salt and similar too [20:15:31] Hi. Is there an API to list all pages that belong to category Foo and category Bar? [20:16:24] And list them in the reverse order when they were added to Foo? [20:19:09] no x 2 [20:19:59] There's probably some tool lab tools for that sort of intersection [22:21:51] Reedy hi, i'm wondering if you are around? :) [22:22:07] it appears https://github.com/miraheze/mediawiki/commit/507501d6ee29eb1b8df443192971fe2b6a6addb6#diff-d3dee2cf9f07dc2a4cc4b6cec07b3674671e4d3044a934aa270d9a596889f183 may have broke using thumb_handler.php [22:22:24] at least when using https://meta.miraheze.org/w/thumb_handler.php/7/7d/Cloudflare_dashboard_3.png/800px-Cloudflare_dashboard_3.png i got "The specified thumbnail parameters are not recognized." [22:22:28] reverting it fixed it. [22:26:28] seems var_dump($relPath); returns false for me [22:27:16] returns false for you where? [22:28:23] i put the var_dump under $relPath = WebRequest::getRequestPathSuffix( $basePath ); [22:29:10] I guess you'd be best filing a followup task to T235357 [22:29:11] T235357: PHP Warning: preg_match(): Compilation failed: two named subpatterns have the same name at offset 62 - https://phabricator.wikimedia.org/T235357 [22:30:03] ok [22:31:39] And probably mention what $basePath is that is being passed to WebRequest::getRequestPathSuffix() [22:33:43] Reedy done https://phabricator.wikimedia.org/T266619 [22:43:09] https://github.com/miraheze/mediawiki/blob/REL1_35/includes/WebRequest.php#L240 returns true Reedy [22:44:04] adding some more var dumps shows "string(15) "/metawiki/thumb" string(85) "/w/thumb_handler.php/7/7d/Cloudflare_dashboard_3.png/800px-Cloudflare_dashboard_3.png" string(16) "/metawiki/thumb/" string(16) "/w/thumb_handler" bool(true)" [23:09:26] think i found a fix Reedy [23:15:56] Reedy https://gerrit.wikimedia.org/r/c/mediawiki/core/+/636703 [23:16:19] setting $wgThumbPath to "$wgScriptPath/thumb_handler.php" worked for me. [23:39:02] hmm