[12:37:06] Hello, i was trying to allow eml Files for uploading to an intern wiki (Exported Email), and it still fails to upload after adding it to $wgFileExtensions. Is there anything i could be doing wrong? [12:39:49] rifoerster: what error message do you get? [12:41:04] on second, let me grab the translation [12:43:35] "This file failed the file check." forgot where the translation tables where in mediawiki [12:46:39] This file did not pass file verification. <-- found translation file [13:04:33] rifoerster: This may require tuning https://www.mediawiki.org/wiki/Manual:$wgVerifyMimeType or https://www.mediawiki.org/wiki/Manual:$wgMimeTypeFile [13:04:51] eml files may be detected as HTML files or similar [13:05:31] i try to deblacklist html (even through it is a text only email this time) [13:07:17] still failed [13:17:23] i added some error logs and it was filetype-mime-mismatch [13:20:26] not sure how to fix it yet [13:36:49] rifoerster: when you upload a file, your browser sends along the file a mime type that your operating system associates with that file. However, it may not match the mime type detected by the server. I guess this may be the problem here [13:39:11] Maybe you need to map this file type in a file described in $wgMimeTypeFile or $wgMimeInfoFile [13:39:39] Or set $wgVerifyMimeType to false [15:19:35] had to leave earlier, ill look into the maping later, thanks for the hint =) probably have to intercept what type is actually detected [15:20:25] worst case its unknown [16:01:43] maping works for my test case at least, have to check later what mime types can happen [16:01:50] thanks again [17:06:57] in wikipedia's user preferences, there is a bar that hovers at the bottom of the sreen that says "SAVE" and "Restore all default settings (in all sections)" [17:07:31] while scrolling down it often hikes up to the middle of the screen before popping back down to the bottom a split second later [17:07:52] is there a way to get rid of this bar and just have a button at the bottom where i can scroll to? [17:08:14] because this is pretty horrible [17:09:07] see https://phabricator.wikimedia.org/T224984 [17:09:34] bleb: which browser and browser version are you using? [17:10:22] Hey can someone help me here.. [[MediaWiki 1.35]] has a template saying it's a future version, but it went stable today, and I can't figure out how to update it. Can anyone help? [17:10:46] Naleksuh: on which exact page (full URL)? [17:10:54] https://www.mediawiki.org/wiki/MediaWiki_1.35 [17:11:12] andre__: yeah it's firefox [17:11:25] bleb: which version? [17:11:43] 68.11 [17:11:52] Naleksuh: I'm guessing it's template/module caching... [17:12:14] Naleksuh: page needs purging, https://www.mediawiki.org/w/index.php?title=Template:MWReleases looks correct [17:12:28] what i would really prefer is to have the bar not be sticky so i can use the full height of my screen [17:12:29] bleb: ask Mozilla to backport their fix to version 68? :) [17:12:31] is this not possible? [17:12:37] bleb: I hope not. [17:12:41] you hope not [17:13:09] andre__ Nope i've purged it several times its just not working [17:13:35] The fact it's right on https://www.mediawiki.org/wiki/Template:MWReleases... [17:13:39] Naleksuh: ah, or maybe null edit, don't know. The template caching will always be a mystery to me [17:13:45] i understand wikimedia updating skins to be friendly to mobile users and people who don't value vertical screen space [17:13:51] Though... [17:13:51] This page contains release notes for a future version of MediaWiki. [17:13:51] The latest version that users should install or upgrade to is 1.35.0. [17:14:02] but dont you think they should be more conservative when it comes to preferences pages that everyone has to use [17:14:03] That did not work either [17:14:18] and especially things that can't be changed in preferences [17:14:18] Reedy : Yep and 34 says its "stable" and not "legacy" [17:14:22] So the text is one part behind [17:14:31] bleb: I don't see how seeing a few more options on the full height of the screen is better than having to always manually scroll down on mobile screens just because of changing a single option on top of the page. [17:15:16] andre__: you don't have to manually scroll if you have an end key [17:15:22] bleb: no, being "conservative" in itself is not a value. being user friendly might be, and that seems to be the case by having a floating bar. [17:15:33] bleb: yeah, and I don't have an "end key" on my mobile phone. [17:16:07] is it not possible to detect if someone is using a mobile phone [17:16:20] bleb: what would that change? [17:16:48] you could serve mobile optimized features to mobile phone users [17:16:57] and leave desktop users alone [17:16:58] bleb: that is already the case and has been for years [17:17:04] ok [17:17:26] bleb: I don't see how it's relevant for websites to know if the device that displays the website can make calls [17:17:49] andre__: it's correlated with whether the device has an end key [17:17:52] Naleksuh: https://www.mediawiki.org/w/index.php?title=Template%3AMW_version%2Fstatus&type=revision&diff=4132692&oldid=4101923 [17:17:52] :) [17:18:01] >This page contains release notes for a stable version of MediaWiki. [17:18:01] >The current version is 1.35.0. The legacy support version is 1.34.4. The legacy long-term support version is 1.31.10. [17:18:02] that looks better [17:18:37] bleb: Let me write it again: I have a mobile phone. My mobile phone has no "end key" (whatever that is). Hence detecting whether you are on a mobile phone is irrelevant. [17:18:42] reedy : should 34 say it's a legacy version? [17:18:59] Yeah, I think that's right [17:19:04] As it's not the current/newest release [17:19:41] andre__: desktop users use something called a keyboard [17:19:49] keyboards have an end key which scrolls to the bottom [17:19:55] bleb: Yes. How is that relevant? [17:20:45] andre__: because it means you don't have to manually scroll to the bottom in order to get to the save button, if it weren't sticking to the screen and taking up vertical space [17:20:50] bleb: Tablet users might prefer to use the desktop version of the website instead of the mobile version. Tablet users might not have an end key on their virtual keyboard. [17:22:29] bleb: It's okay that something might work for you and your device. That does not mean that it will also work for everyone else and their devices. [17:22:42] right [17:22:43] likewise [17:22:51] the current design does not work for me on my device [17:23:12] so the ideal would be to accommodate everyone [17:23:34] ...which is impossible. [17:23:39] short of that, for things that every user is forced to interact with, be conservative [17:23:50] Plus it's unclear to me why it does not work for you on your device. [17:24:03] meaning, allow tablet or phone users to pick software that has home and end functionality [17:24:27] (...apart from your old browser version as one reason) [17:24:41] yes [17:24:44] tablet or phone users are free to pick whatever software they want to run on their systems. [17:24:54] nobody forces you to run an older Firefox version, I'd say. :) [17:25:08] MW 1.34.2: Upgrading to MW 1.35.0. I moved the folders to a temp folder. I uploaded the new MW to the one it will reside in. Do I now trigger the update.php and move my Local Settings in after the fact? thx [17:25:16] firefox forced me to via the megabar ;) [17:25:22] andre__: Does this argument work for IE6 users? [17:25:28] bleb: Your personal choices. [17:25:32] yes [17:25:41] foreclosurepedia: LocalSettings.php needs to be in place for update.php to know how to connect to the database [17:25:43] bleb: You are free to run Windows 3.1, sure. I can't stop you from doing that. [17:25:49] same for any tablet user that uses a browser that cant easily scroll to the bototm [17:26:00] so move it over now and then trigger the update correct? thanx [17:26:15] Reedy: Depends on my company's policy about their systems, and/or if I have money for a newer Windows license :) [17:26:40] bleb: Indeed... so you should fix your browser [17:27:00] andre__: why is it my responsibilty to fix my browser, and not tablet users responsibility to fix theirs? [17:27:21] I imagine it's easier to do it on your desktop/laptop than for someone on a tablet [17:27:26] (in most cases) [17:27:41] bleb: because you're describing a situation and consider it a problem, while I don't, I guess. [17:28:33] I guess it's not very reasonable to force MediaWiki to not add new functionalities just because some users don't want to update their software or they resist to changes [17:28:59] it would be unreasonable not to do that [17:29:08] Plus the usual question in software development is always how many corner cases to cover, and how much to care about either ancient OS/browser versions and/or working around bugs in not so ancient versions. Which all creates maintenance costs for years to come. [17:29:55] if you choose to use an old browser version, you should expect that the rest of the world will move on without you and sites will eventually start breaking more and more over time [17:30:14] if that is not acceptable to you, do not use an unsupported browser [17:30:54] is firefox esr an unsupported browser [17:30:55] or use web.archive.org and visit only old versions of those pages :) [17:31:20] bleb: Your version 68 is [17:32:29] Hello. Is Mediawiki 1.35.0 supports visual writer without proc_open() ? [17:32:46] ellif: Hi! What is visual writer? [17:32:49] ah [17:33:08] i guess my distro hasnt tracked with mozilla [17:34:40] its too bad skins dont also apply to preferences pages [17:34:40] @andre__ sorry, the Visual editor [17:35:09] thats always been a great thing about mediawiki, if they start messing with the default skin you can select and old skin that is better for you [17:35:27] but this is not so for the preferences page [17:37:01] because I have heard of parasoid needs of proc_open() and My server admin says that It can be used in php 7.2 but not over php7.3 [17:37:51] might be a question for #mediawiki-parsoid [17:37:57] Heard where? [17:38:04] Allowing proc_open on 7.2 but not 7.3 is... odd [17:38:39] I am now in one of cpanel server [17:39:31] proc_open() still exists in 7.3 (and 7.4) [17:40:07] many shared hosts block the use of that function for security reasons, but I'd expect them to block it across all PHP versions they provide, not just one of them [17:43:22] He said that the hander of php 7.3 and php 7.4 is fgci and 72 is suphp [19:45:00] Hi, is the upgrade notes for 1.35 for upgrading from 1.34 or 1.31? [19:52:33] It kinda applies to both [19:53:05] Anything in particular? [19:54:03] Reedy: I wanted a quick glance into the configuration changes [19:54:24] Most of it will directly apply to 1.34 I guess [19:54:28] across versions without having to read release notes for each version [19:54:29] Certainly in terms of deprecations etc [19:54:45] yeah I'm upgrading from 1.31 [19:55:02] not that I'm using any configs out of the ordinary [20:52:42] cscott: hey, did you see the failing test for the #transliterate patch I'm working on? [20:52:45] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/627938 [20:53:03] I can't figure out why it isn't working in the test even though I set wgUsePigLatinVariant=true. it works when I test it locally [20:53:24] Let me take a look [20:53:31] occasionally we do get weird failures on CI that you can't replicate locally [20:53:31] thanks! [20:53:51] can the tests in parserTests.txt manipulate any of the wg* settings? [20:55:49] it's not super obvious to me why it would be failing but I don't even know where to look [21:12:54] Upgrading from MW 1.34 to 1.35. Updater hung at Existing Wiki even when I try to restart it: https://digitalmatrixgroup.com/mw-config/?page=Language [21:18:57] Running PHP 7.3 ... all the PHP versions are specific to .1, .2, .3, .4 and nothing in between. [21:21:32] foreclosurepedia: have you tried adding the LocalSettings manually on the server instead of going thru the install wizard? [21:22:19] Actually, my provider did it and now if you go to the domain itself it triggers a 500 error. I have my previous localsettings.php in there [21:23:00] is there a way to reboot the upgrade/install or bypass? thanx [21:23:08] !update.php [21:23:08] update.php is a script that updates the database tables. You usually need to run it after upgrading MediaWiki or installing certain extensions. For details, see [21:23:54] is there a way to execute from the web? I am on shared hosting [21:25:22] It would be how you tried [21:25:33] If you have your localsettings in place, the installer should ask for the upgrade key from it [21:26:44] from here: https://digitalmatrixgroup.com/mw-config/ it literally stops cannot do anything [21:27:20] clicking the restart sends it back to the same loop [21:31:24] As https://digitalmatrixgroup.com/mw-config/?page=ExistingWiki is 500-ing... [21:31:26] !500 [21:31:26] A blank page or HTTP 500 error usually indicates a fatal PHP error. For information on debugging (including viewing errors), see . [21:32:47] Yeah only the /mw-config loads. Do you think it is the version of PHP as it is 7.3? Should I try 7.4 as there is no in between? [21:33:33] As long as it's 7.3.19 or newer, it shouldn't be an issue [21:35:12] Switched it to 7.4 as there is no in between and still the same. I think I will just redo it from scratch and see what shakes out. Thanks for feedback! [21:36:08] I'm not sure just reinstalling it from scratch is the best idea [21:36:16] Surely your provider should provide some logs to give a clue [21:51:49] cscott: did you find anything? [21:52:33] I think there are some limitations -- we might need to reset a service after making a chance. [21:52:55] Sorry I got sidetracked with another task, let me look now. [22:05:48] mediawiki not working after reboot. Need help [22:06:37] not working? [22:08:26] yeah, what does not working mean? [22:11:48] After reboot, I tried to access the mediawiki but could not. I need help in making sure that I have restarted the server correctly. My work choice might be wrong but I am handling this for the first time. [22:12:04] word* [22:12:07] What do you mean could not? [22:12:13] What happens when you try and access it? [22:14:00] I know only one way to access which is through web browser. I am not aware of anything what is going on behind the curtain [22:14:09] What happens when you try and access it? [22:14:47] I get ERR_CONNECTION_TIMED_OUT [22:15:27] ok, so that sounds like the web server isn't running. or you're connecting to the wrong address [22:15:48] what web server are you using? [22:16:02] joomla [22:16:17] joomla isn't a webserver... it's a CMS [22:16:20] joomla is not a webserver [22:16:36] it's also not relevant for mediawiki as far as I know [22:16:57] i am sorry. It is apache [22:17:27] Neel: let's see if 'sudo systemctl status apache2' works for you [22:19:34] active (running) [22:20:02] Neel: what address are you connecting to? [22:20:04] in the browser [22:22:06] mutante what should I expect the output to be [22:23:21] Neel: kind of expected it to show some kind of error and NOT "active (running)" since you got a timeout that seemed likely but since it's not.. we just know it must be another problem [22:23:38] so let's go with ningu's next question [22:25:01] since the webserver is up but you don't get any error or message from it and it just times out.. it could be things like firewalling (a manually adjusted iptables rule was removed due to the reboot) or server had a manually configured IP that is not the same anymore after reboot [22:29:55] Ok, got it working. Check the most recent patch set. [22:30:31] cscott: thanks! so why did it work locally? [22:30:40] How does sharing a URL helps? I am not denying but I want to be confortable sharing address that I use in the browser. [22:31:07] Neel: if you don't want to share it then we can't check it for you. but you can still check it yourself [22:31:22] make sure the ip address of the server corresponds to what you're using to connect [22:31:51] Because mediawiki services are a huge ball of initialization order dependencies. [22:32:17] Probably you had $wgUsePigLatinVariant in your Local settings.php ? [22:32:47] ah yeah, I did. good point [22:32:51] And so that ensured that the various services got created "knowing" about en-x-piglatin [22:33:11] Which means I should probably also amend this patch by one line, hang on. [22:34:30] okay. Thank you for understanding. If I type ip address as url. I am able to get to the website. The machine that runs mediawiki is also running the website for our organization [22:34:48] @Reedy took your advice and kicked it back to them as they were doing it thus far. thx! [22:34:51] Neel: ok, so how is that different from the address that was failing? [22:36:10] I meant www.arma ...... [22:37:42] Neel: you were doing something before that didn't work, and now it works. what did you change? [22:40:58] so if I type www.arma.vuse.vanderbilt.edu, it won't load the website. but if I type the ip address it does [22:41:08] I have not changed anything [22:41:29] ** server can't find www.arma.vuse.vanderbilt.edu: NXDOMAIN [22:41:34] Does that address resolve for you? [22:42:17] no [22:42:59] That's your problem then [22:43:03] It's not a MediaWiki issue [22:43:33] yes. I think I have to consult my IT staff [22:43:49] Yeah, that's likely [22:44:27] it works if you drop the "www" part, btw [22:44:33] (the DNS part) [22:45:12] arma.vuse.vanderbilt.edu is a thing, but not with 'www' [22:45:21] that's something to tell the IT people [22:45:31] I think I have to make sure that the domain name of the website is associated with the correct ip address [22:46:03] yea, first thing you need is the name you type in has _any_ IP address associated with it [22:46:17] and then you need to make sure that IP is also the one used by your webserver [22:46:41] and finally.. that your webserver has a config snippet for the name you are typing [22:46:49] a ServerName that matches it