[00:00:56] Hmmm, so, for this site, not a single person (not even me) will edit any of the pages in the Template, Module, Help, or Data namespaces, and only imports such as from Wikipedia will exist, but otherwise, adding a header to appear for those namespaces only, how do I do that? [00:02:43] you could use an editnotice https://www.mediawiki.org/wiki/Manual:Interface/Edit_notice [00:44:48] Oh crap! I just noticed another thing special about the Template namespace, which I need to recreate for the site-specific MPTemplate namespace: The "Manage TemplateData" button, and a few other differences too. [00:45:54] same for Data -> MPData, Help -> MPHelp, Module -> MPModule [00:48:13] it would probably be a better idea to use the standard namespaces for your editable ones, and keep imported content in custom namespaces [00:48:32] Are you sure? [00:48:38] Wouldn't that break links? [00:49:52] I guess I'll have to test and experiment and see what happens [00:53:15] So then all of the Templates/Modules/Data/Help pages that I imported already, do I need to change the namespace of all of them? [01:05:29] Kinda I don't even think it will be important or primary concern even to use the other namespaces too, because if any seriously useful templates, modules, data content that is used on the site, it should be kind of things that would also be useful on Wikipedia as well, such that those contents can be published on Wikipedia first, and pulled in via Wikipedia exports [01:10:58] oh, and given that nobody can edit those namespaces too, it is kinda pointless, defeats the purpose to set up Manual:Interface/Edit_notice since nobody will ever see it anyway. I just confirmed too, that as a sysop, setting $wgNamespaceProtection[NS_TEMPLATE] = ['name_of_role_that_nobody_has']; that the message in MediaWiki:Editnotice-10 does not even appear since the user does not have permission. [01:11:44] when viewing the source, that is [01:12:41] which also suggests that concern about pointing out that the source of the content is CC-BY-SA-3.0 in a header will not even appear for anyone [02:52:38] I'm creating an extension to add [Scribble](https://docs.racket-lang.org/scribble/) support for third-party use. I want to process wikitext as Scribble first so that it precedes the wikitext markup. The Scribble markup should also be saved to the database. Should I create a ContentHandler for this, or is there a simpler solution? [02:53:18] s/markup/code/ [02:59:24] Note that the Scribble is not intended to replace wikitext, just to precede it so it can generate arbitrary wikitext. [03:14:16] coldstone: if the whole page is expected to be Scribble, then ContentHandler seems like the right idea. If you just want to embed fragments of Scribble in a page, I'd recommend looking into a parser tag [03:14:29] With a parser tag it would be [whatever] [03:45:47] Thank you, but I'd rather not use a parser tag. I want to embed Scribble directly. [03:48:08] I think it would discourage the use of Scribble notation. [03:49:59] Yeah, the whole page should Scribble, mixed in with wikitext markup as well. [03:50:54] * page should be Scribble, mixed [07:41:50] https://mediawiki.org/wiki/Extension:MobileFrontend#Installation I set up Minerva skin for MobileFrontEnd version of https://dev.moasspedia.org/ and it works, except the CSS contents of MediaWiki:Minerva.css are not loading like they do for the nonmobile version of the site. [07:44:58] ah maybe MediaWiki:Mobile.css [07:46:01] Yeah, except it is delayed, and the CSS doesn't show up until seconds after the page is loaded. :( [14:47:57] I'm having some issues after enabling SSL on my wiki and just wondering if anyone can help. [14:47:58] In my .htaccess file I have this: https://dpaste.org/0151 [14:47:58] which worked before activating the SSL via certbot. Is there something I heed to change now that I have an assigned SSL certificate? I get the apache The requested URL was not found on this server. [14:47:59]  error when visiting on /wiki/$1 but it works if I use /index.php/$1 [15:07:06] guest111: The problem is on the configured on apache. It probably has a different DocumentRoot for the :80 and :443 sections [15:07:46] Or maybe one allows AllowOverride and the other doesn't [15:10:29] Vulpix this is what I have > https://dpaste.org/E8nC [15:12:07] Did you spot the difference? No rewrite rules on the :443 vhost [15:14:25] Would I just copy the same ones across? [15:19:30] Hmmm, no, those rewrite rules only redirect to https [15:19:48] I have no idea why it doesn't work, then. Unless that configuration is incomplete [15:34:08] hmm, odd. [16:24:10] Vulpix: what you said about AllowOverride [16:24:20] It needs to be set for https guest111 [16:27:05] RhinosF1 like so? https://dpaste.org/gzLH [16:27:49] Should work but I don't know much about Apache [16:29:09] Do I need to add these back to .htaccess? [16:29:10] RewriteEngine On [16:29:10] # main rewrite rule [16:29:11] RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L] [16:29:11] # Redirect / to Main Page [16:29:12] RewriteRule ^/*$ %{DOCUMENT_ROOT}/w/index.php [L] [16:32:11] Yes [16:32:58] Glorious, that works. Cheers for your help :) [16:35:32] Np [16:35:45] Please note that stack overflow is a very good friend [16:46:18] Hmm, I do seem to have run into an issue, now though. I can't edit >.< [16:46:19] I keep getting redirected from to /index.php and it won't let me access the editor. [16:49:51] hmm [16:49:55] seems like instead of getting redirected to /wiki/[pagename]?veaction=edit, it's redirecting me to /index.php?title=[pagename]&veaction=edit [16:50:08] right [16:50:29] Your rule might be too tight [16:50:42] It should be rewriting not redirecting [16:52:24] I copied the one from the MediaWiki manual [17:02:27] Hmm [17:03:04] Solved it — looks like the rewrite rules are different for MW > 1.35.x and integration with the VE. [17:03:58] https://www.mediawiki.org/wiki/Extension:VisualEditor/webserver for example. Should probably be mentioned on the ShortURL article given VE's popularity. [18:05:15] I configured my two instances of MediaWiki on one database, was this a good idea, or should I separate them out to avoid issues in the future (such as if I wanted to install CentralAuth for global user groups and shared logins between domains)? [18:05:52] Did you use different table prefixes? [18:06:14] For the second one I gave it a prefix, but for the first one it doesn't have a prefix. [18:06:28] So it should work fine [18:06:37] It's "common" enough on shared hosting when you only get one database [18:07:09] I can create another database, it's not shared hosting. [18:07:51] I'm just thinking if it would be wise to have another one? For example I'm following the CentralAuth installation guide and it says [18:07:51] > $wgLocalDatabases = array( 'meta_wiki', 'test_wiki', 'cod_wiki' ); [18:07:52] but obviously I only have one database? [18:08:38] CentralAuth is designed with various assumptions [18:09:29] It would probably be better to move one to its own database though, yes :) [18:11:17] !debug [18:11:17] For information on debugging (including viewing errors), see https://mediawiki.org/wiki/Manual:How_to_debug . A list of related configuration variables is at https://mediawiki.org/wiki/Manual:Configuration_settings#Debug.2Flogging Also see https://mediawiki.org/wiki/Manual:Errors_and_symptoms [18:12:35] It's safe to move it to its own database even after installation? [18:17:03] Yeah [18:17:12] Just update the relevant LocalSettings.php entries [18:22:22] Hmm, I did that (after creating database) and got "Fatal exception of type Wikimedia\Rdbms\DBQueryError" error [18:23:27] That could mean many things [18:24:36] I'm pretty sure you *don't* want to install CentralAuth and you probably *do* want to use $wgSharedDB + $wgSharedTables + suitable extensions (we use [[mw:Extension:GlobalUserrights]] on ShoutWiki) :) [18:26:06] I don't want to have to log in to each wiki individually, though. I'd rather have SSO. [18:27:50] CentralAuth's SSO system isn't much better than $wgCookieDomain (in core) due to recent privacy-oriented browser changes [18:29:13] I couldn't get $wgCookieDomain to work at all. [18:30:04] If I could get $wgCookieDomain to work I would go down that route. [18:31:00] what isn't working about it? The setting is rather straightforward [18:31:02] Nonetheless, I seem to have screwed up changing the database of one of my wikis. [18:31:03] Steps: > create new database; > allow admin of first database to access new database; > change settings in LocalSettings.php file, does that sound like the right process? [18:31:30] I was just glancing at https://stackoverflow.com/questions/44471699/how-to-make-undo-work-in-an-html-textarea-after-setting-the-value and https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand#browser_compatibility shows that execCommand is supported by allmajor web browsers. I noticed on Wikipedia both in the edit area at top (Special Characters), as well as the additional ones on the bottom (dropdown menu [18:31:31] for Insert, Wiki markup, Symbols, etc.), that undo states are lost when clicking on any of the characters to insert. Is there a way that future versions can fix this to preserve the undo history? [18:31:52] yeah. if you want, you can also rename the tables to remove the prefix (some extensions assume that you don't have prefixed tables; I think CentralAuth may be one of those) [18:32:13] Well I set it to $wgCookieDomain = ".wikisubdomain.com" and then I logged out of all wikis, logged in again on one and it didn't propagate across. [18:33:04] ok, and what is your $wgSessionCacheType set to? The cookie domain will let each wiki see a session cookie, but they'll also need to all be configured to use the same underlying session store [18:33:09] That's the process I took, moonmoon and it's throwing a database error. [18:33:23] (which also means they'll all need to be configured to use the same underlying user database, since these things are based on user id) [18:34:09] well, what's the actual error? [18:34:26] check error logs or enable $wgShowExceptionDetails = true; [18:34:41] (latter not recommended for production sites that have other people accessing them) [18:38:42] (For the cookie issue, I don't have $wgSessionCacheType set to anything as the manual for $wgCookieDomain doesn't mention it at all) [18:38:43] The DB error is: [c7e829199284b71ababd5f4d] / Wikimedia\Rdbms\DBQueryError: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading or after adding a new extension? [18:38:43] So I just tried to run update.php but couldn't because "Undefined index: SERVER_NAME in /var/www/html/mediawiki/LocalSettings.php on line 10" but I'm using the switch statement from Manual:Wiki family)? [18:39:15] guest111: there is a more detailed error message if you check error logs or enable exception details [18:39:52] https://dpaste.org/jubK [18:40:46] cool, so "Table 'test.l10n_cache' doesn't exist" is the actual error [18:41:01] I guess the new database you created was called test? [18:41:14] Yeah [18:41:29] inside of that db, what do all of the tables look like? Do they still have table prefixes or no? [18:41:44] if you removed the table prefix from LocalSettings.php you'll also need to manually rename all of those tables via SQL [18:42:01] back in 2018 https://mediawiki.org/wiki/MediaWiki_1.33/wmf.8 mentions "Revert "textSelection: Use execcommand to replace text" by Esanders" [18:44:18] moonmoon hmm seems my database is empty. [18:45:48] ah ok [18:46:18] so, your options are 1) rename LocalSettings.php temporarily and re-run the installer to populate that database with a fresh one, or 2) copy the tables you want to move over from the other database using SQL [18:48:54] Ah sweet! I went with option 1 and it worked :) [19:09:54] Okay, question again (sorry). I'm up to creating the database file, but I'm having issues due to my LocalSettings.php file pointing to individual wikiNameLocalSettings.php files. [19:10:32] (for centralauth this is), the error is: Undefined index: SERVER_NAME in /var/www/html/mediawiki/LocalSettings.php on line 6 [19:17:02] is SERVER_NAME your own customisation? [19:18:18] It's what's used in the main LocalSetttings.php file that decides which wikiNameLocalSettings.php file is selected. [19:22:44] Right, but that's not code that MediaWiki is shipping with [19:23:00] As such, we have no idea what code you're using, other than something with 'SERVER_NAME' in an array [19:23:40] Sorry, it's the code in this section: https://www.mediawiki.org/wiki/Manual:Wiki_family#Giant_switch_statement [19:25:04] The answer is partially https://www.mediawiki.org/wiki/Manual:Wiki_family#Updating_wikifarm_from_the_commandline [19:25:21] Basically, SERVER_NAME isn't defined in CLI [19:29:00] Oh damn. The refToolbar gadget cite web template Autofill queries http://toolserver.org/~alexz/ref/lookup.php? (which is not even https). Why isn't there a server-side php script in MediaWiki path to show the title of a given URL as input? This would be faster than querying an external website. [19:30:18] Are you using some really old version of it? [19:32:44] https://en.wikipedia.org/wiki/MediaWiki:RefToolbar.js#L-494 [19:36:54] I made a mistake, was looking at XML imports, and the updated url (with https) is correct, however I still am looking to adjust the dependency on external website to be internal dependency from the existing web environment itself providing the same lookup capabilities. [19:38:59] in theory it wouldn't be that difficult [19:39:12] you could write a parserfunction that does the HEAD request to get the title [19:39:48] I'm trying to run php maintenance/sql.php --wikidb centralauth extensions/CentralAuth/central-auth.sql but getting an error that the output file couldn't be opened. When i look in the extension folder, central-auth.sql and sql.php aren't there — has the process changed? [19:42:01] (found them, ignore thay) [19:42:58] The central-auth.sql, anyway, seems like sql.php isn't there [19:43:51] sql.php is still there [19:45:03] Am I missing something obvious that means I can't run it? [19:47:48] I've no idea [19:47:56] I can't see what's on your disk :) [19:48:59] if I ls the output doesn't show sql.php? [19:49:19] https://postimg.cc/cv7QwTjQ [19:49:37] You're in the CentralAuth folder [19:49:44] sql.php is in mediawiki core's maintenance folder [19:58:44] Seems as though one of my databases didn't get included in the centralauth database [19:58:44] Error 1146: Table 'test.oathauth_users' doesn't exist (localhost) [19:58:45] Function: MediaWiki\Extension\OATHAuth\OATHUserRepository::findByUser [19:58:45] Query: SELECT * FROM `oathauth_users` WHERE id = 0 LIMIT 1 [19:59:37] ? [20:00:26] Thats the error that's being thrown, and when I migrate the accounts, it doesn't include that database for some reason? [20:01:00] You'd need to manually create tha table in the right database [20:04:12] I'm a little confused what table I'm missing? [20:04:27] oathauth_users [20:04:34] in the database test [20:06:48] Okay, but that table doesn't exist in my other database either and that didn't throw an error? or at least when I view the database it doesn't how [20:07:56] You've got the extension enabled though, presumably [20:08:23] yeah. I can log in at the other wiki, but if i try at the one test database is using, thats when the error is thrown [20:21:25] Any ideas? [20:22:03] Disable OATHAuth if you're not using it? [20:26:24] That works. Now when I go to Special:MergeAccounts, I get: No accounts matching your name were found in the central account tracking table! The database must be corrupt. [20:26:51] did you run the centralauth migration scripts? [20:26:53] Have you populated the localaccounts table? (from memory) [20:30:28] *localusers [20:32:17] I ran `php extensions/CentralAuth/maintenance/migratePass0.php` and `php extensions/CentralAuth/maintenance/migratePass1.php` which returned [20:32:17] `2022-03-19 20:29:06 processed 2 usernames (16.4/sec), 0 (0.0%) fully migrated (@ WikiUsername)` [20:32:47] but in this particular instance I've set up other accounts that haven't been migrated [20:41:02] how do I check that a wiki is in the centralauth database? [20:42:54] Could this have something to do with my issue? [20:42:54] 'wgScriptPath' => array( [20:42:55]     'wiki1' => '/wiki1', // wiki1 [20:42:55]     'wiki2' => '/wiki2', // wiki2 [20:42:56] ), [20:42:56] 'wgArticlePath' => array( [20:42:57]     'wiki1' => '/wiki1/$1', [20:42:57]     'wiki2' => '/wiki2/$1', [20:42:58] ), [20:47:23] You will either need to set $wgLocalDatabases or a hook subscriber onto CentralAuthWikiList [20:51:22] I have them set, Reedy, this is the code I'm using https://dpaste.org/hasU] [20:52:19] Adapted from here https://www.mediawiki.org/wiki/Extension:CentralAuth/Walkthrough#Code but with the suffix removed at the beginning as I am not using suffixes. [20:58:22] At the moment, the only accounts are test accounts, so I guess it doesn't matter at the moment if I'm getting thrown an error. I did create an account on wiki1 and when I tried to log in on Wiki2 I got an error but my account is recognised on Special:GlobalUsers [20:58:50] https://postimg.cc/jDB754Nr (mediawiki) is the name of my wiki1 database [20:59:02] But I'm still unable to merge the accounts I already have? [21:08:56] Are you calling it mediawiki somewhere? [21:11:39] Only in the local settings for that wiki for $wgDBname; [21:33:57] Has anyone got any ideas what my issue could be here? [21:55:44] Anyone? [21:55:59] Hello [22:00:12] Are you familiar at all with setting up CentralAuth? [22:01:06] hm, i am planning on doing that [22:01:49] I currently do not have a clue about CentralAuth, but I may be of assistance [22:02:58] I have been following this guide (https://www.mediawiki.org/wiki/Extension:CentralAuth/Walkthrough) but have hit a brick wall. [22:03:31] Hm [22:04:45] if you're on a linux system have you ran the correct command, or the equivalent to another operating system? [22:05:16] I have, I'm near the end and have practically got CentralAuth set up, I'm just having issues with the database. [22:05:30] Which database are you using? [22:05:35] MariaDB [22:06:32] Can you send the trace? [22:17:16] I think my issue stems from here: [22:17:17] https://www.mediawiki.org/wiki/Manual:Wiki_family#Updating_wikifarm_from_the_commandline [22:17:17] I'm setting `export SERVER_NAME=wiki.domain.com` so that I can run `php migratePass0.php`, which gives `processed 6 usernames (52.1/sec), 0 (0.0%) fully migrated (@ USERNAME)` which seems to be fine. But when I try to merge any of the accounts via Special:MergeAccounts thats when I get this error: https://dpaste.org/NYaf [22:18:16] Now, the only place "mediawiki" appears is as the database name in wiki1LocalSettings.php; which aligns with the domain i gave in the `export SERVER_NAME=wiki.domain.com` command. [22:19:12] I wonder if it is because of this: https://www.mediawiki.org/wiki/Manual:Wiki_family#Updating_wikifarm_from_the_commandline it actually recommends using this command: `php update.php --conf ../wiki1LocalSettings.php`, but when I run that I get an error saying can't run update.php [22:19:40] The 6 usernames would be accurate that the script returned, but I'm a little confused about the error I keep getting? [22:26:08] It seems when accounts are being created they are not being created in the centralauth database, I guess. [23:56:50] Is anyone able to help? or can point me in the direction of someone that can?