[17:14:32] hi there, is there a way to unlock the database from a script or command line? I tried to set database read only and now can't get back in. Maybe I misunderstood the function [17:14:50] What did you use to lock it? [17:16:00] the special page hm I think it's called lockdb? [17:17:18] yes it was Special:LockDB [17:17:53] Try Unlockdb then ;) [17:19:50] lol I did try I just can't get there :/ https://dpaste.org/71S6 [17:22:36] looks like it's deprecated https://www.mediawiki.org/wiki/Manual:Lock_the_database [17:23:01] ningu: It might be.. But when they've used it to lock it... [17:23:16] drvela: That's a bug with BlueSpice; you'd need to file a bug/task with them [17:23:26] I'd disable the extension temporarily to visit that page [17:23:37] Or to fix it manually [17:23:49] hmmm I see [17:23:57] You need to remove the file $wgReadOnlyFile is set to [17:24:06] Which is {$wgUploadDirectory}/lock_yBgMBwiR by default [17:25:43] beat me to it [17:25:47] https://www.mediawiki.org/wiki/Manual:$wgReadOnlyFile [17:47:46] Reedy ningu thank you both so much. Had no idea that was deprecated! Won't be touching that again :) [18:42:34] I'm getting the following error in the console when loading any page on this wiki (domain changed for privacy): [18:43:21] The resource from “http://wiki.somedomain.com/w/load.php?lang=en&modules=ext.uls.pt%7Cext.visualEditor.desktopArticleTarget.noscript%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cskins.vector.styles&only=styles&skin=vector” was blocked due to MIME type (“text/html”) [18:43:21] mismatch (X-Content-Type-Options: nosniff). [18:43:40] I am unsure where to go to fix this. [18:43:43] Any ideas? [18:43:52] nihonjoe: your webserver configuration, likely [18:44:55] (at least judging by the error mentioning a header) [18:46:32] your web server might be overwriting the content type header [18:47:19] I've never run into that before. Where would I go to look at that to see if that's what' [18:47:27] s happening? [18:47:34] It is apache [18:49:08] Is that applied in the .conf file for the site? [18:49:40] nihonjoe: check the response headers for the erroring URL [18:49:46] the one you posted [18:50:09] (you can do this in developer tools, network tab) [18:51:06] check Content-Type, and also check if you have mediawiki headers there, like X-Content-Type-Options [18:51:44] if you do not, there is quite a big chance something is printing out content before headers [18:52:26] I'm not seeing any Content-Type info on the Network tab [18:53:09] nihonjoe: please click the request and look at response headers on the right [18:53:15] thank you in advance [18:55:16] Remilia: I get this: https://dpaste.org/bmVT [18:56:19] nihonjoe: you most likely have "Cannot modify header information – headers already sent" in your error log [18:56:43] (php error log, that is) [18:57:42] if you do not, you should check Apache configuration for anything that refers to mod_mime stuff [18:58:37] but off the top of my head I do not remember anything in Apache that would do this [19:00:10] my instances of mediawiki are also powered by Apache and load.php properly sets content-type [19:07:25] This is a brand new install for an existing wiki, so the only things kept from the old one are LocalSettings.php and the contents of the images directory. [19:10:39] So Load.php should be working properly. I never touch it. [21:59:49] Remilia: I know nihon is offline now, but for what it's worth, content-type issues are a distraction, not the root cause. The reason it responds with text/html is because there is some other error. To see this error, open the load.php (or other url) in a browser and see what the error page says :) [22:00:12] when we show an error, that message is an HTML page. [22:01:01] For most errors we respond with text/javascript and send the error to console.error() [22:01:14] oh [22:01:16] but if the error is really big and before we can set anything up, then it will fallback to an HTML error page. [22:01:25] makes sense