[03:02:20] shalom [03:17:14] DeepChill: Shalom to you! [03:17:55] Yaron, I was looking for you [03:40:28] hello, I've got a broken mediawiki. The server that it's on was upgraded from deb8 to deb9, php5 was nuked, and php7 was installed. I think that mw is still looking for php5, when php7 is sitting right there all nice and pretty. Here's the message from my apache2 error.log: [03:40:30] whats-in-a-name [03:40:31] that's not it [03:40:42] PHP Fatal error: require_once(): Failed opening required '/var/www/html/wiki/includes/PHPVersionCheck.php' (include_path='.:/usr/share/php') in /var/www/html/wiki/index.php on line 36 [03:40:43] that's it [03:41:01] mw version 1.28 [03:42:34] I looked around in LocalSettings.php and couldn't find anything mentioning php version [03:43:33] tried setting up a different instance of mediawiki and it pulls the correct version of php, but after plugging in the mysql details, it doesn't seem to be populating with site data, so that's why I'm trying to fix the broken mw [04:28:39] whats-in-a-name: that indicates some of your mediawiki files are missing. Try re-downloading and re-extracting the tarball [04:29:15] thank you Skizzerz I will give that a go [04:32:19] Need. Help. [04:39:15] Skizzerz, I gave that a go, copying over the files without replacing any files that were already there (I didn't want to overwrite any config stuff from mw), and it only copied over one readme file. I made sure to get the right version of mediawiki. Needless to say the missing readme file was not the issue. I'm still getting my errors and the website's index is coming back 500 [04:47:33] overwriting files fixed it Skizzerz [04:47:36] tyvm <3 [06:39:27] Hello everyone (: [06:41:31] Could you pls tell me if this is the right channel for asking for help with a technical mediawiki problem I got after an update to 1.30 [07:10:52] snaker yes it is. [07:16:49] okay, thank you. so if somebody can give me a hint that would be great, here's the problem: I successfully upgraded from an old wikimedia 1.25.3 to the current 1.30. I ran the updatescript afterwards and my site is showing up and everthings working but with one exception: no thumbnails are shown in firefox or chrome, but in IE it works ... all thumbnails are on their place (as they were befoe my upgrade of course) but for any reason they will not be [07:16:50] shown. I found someone with a similar problem but it was not my solution: https://stackoverflow.com/questions/25286346/images-not-displayed-in-wiki-pages-after-upgrade [07:19:00] Same problem btw when I upload a new picture and link it. Upload works fine but linking with file:picture.jpg|thumb only generates a link to the JPG (which works). embedding a pictrue in full size works afaik. [07:19:42] I installed a new blank wiki on my server and there the embedding with |thumb works fine. [07:20:48] unfortunately it's only a intranetsite so I can't browse you through the wiki but of course I can provide screenshots if needed [07:24:58] you can probably fix thumbnail issues by making sure permissions weren't changed from the webserver account when upgrading [07:28:58] sorry, i didn't mentioned it ;) of course rights a set right. that's what i first checked. but I would wonder if this could be a problem bc i duplicated my wiki-folder, replaced the files with the new one, checked the localsettings.php (i replaced the extension registration "require_once" with the new "wfLoadExtension") and ran php update.php, ran the [07:31:23] so rights are right, 0755 recursive for the images folder [07:34:44] new uploaded image works without |thumb [07:38:01] here's a screenshot of a Test page with the file "cat.jpg": https://dms.maxfeld.com/index.php/s/uPOABkH5Tg1YqOG [07:40:47] the image is now at: /var/www/wiki/images/d/d1/Cat.jpg [07:41:27] and the thumbs are here: /var/www/wiki/images/thumb/d/d1/Cat.jpg/120px-Cat.jpg (and 600px-Cat.jpg, 450px-Cat.jpg, 300px-Cat.jpg) [07:41:46] so everything looks good from a technical point of view [08:04:07] interesting: if I click on the link that is shown instead of the thumb i will be redirected to the picture-site (mywiki.bla/index.php/Test#/media/File:Cat.jpg) but if I do a rightclick on the link an hit "show image" in firefox I will be related to a new site called "5x" which not exist ... [14:36:02] why you banned me [14:36:09] i m not a hacker [14:37:27] zingur has been banned me because of i m a wallhacker, this is such a stupidness of him. who made this game server? [14:37:44] who make him an admin? [14:38:07] i dont know about hacking [14:38:26] fuck off salo kamino [14:38:37] natural game ko hara nahi pate to esa karte ho [15:44:15] I am facing error while following https://www.mediawiki.org/wiki/Gerrit/Tutorial to install git-review So please help me to fix this Issue https://usercontent.irccloud-cdn.com/file/T4q7k5Iv/error.png [15:51:38] Gopa: which exact steps are you following? [15:51:58] Gopa: Your screenshot does not tell us which command you entered, and why. [15:52:29] (and why are you root in your screenshot?) [15:52:29] andre__: sudo apt-get install git-review [15:52:33] my guess is he tried apt-get install git-review [15:52:49] it's funny that git-review depends on mercurial :D [15:53:01] yeah [15:53:49] Gopa: see my other questions above. [15:53:52] git-review is a piece of shiiiiining software. [15:54:13] doesn't even break on non-ascii characters in the commit message [15:54:17] [15:54:52] I see you can remove the ability for * to read; is it possible to do the same for a single Namespace? [15:56:14] !cms [15:56:14] Wikis are designed for openness, to be readable and editable by all. If you want a forum, a blog, a web authoring toolkit or corporate content management system, perhaps don't use wiki software. There is a nice overview of free tools available at including the possibility to try each system. For ways to restrict access in MediaWiki, see !access. [15:56:26] !access [15:56:26] For information on customizing user access, see . For common examples of restricting access using both rights and extensions, see . [15:57:55] yeah. this I've been trying to avoid because we have 10 years of cruft that I don't want to convert to a different platform [15:58:50] MediaWiki hasn't been designed to keep some pages as "secret". You either allow all pages to be read, or all private. Otherwise the information can be leaked quite easily in a lot of ways [16:00:21] yeah, I know [16:00:32] I've heard 100 times, and now it's bit me too [16:07:56] It's one of the most requested features. You'd think we'd make some investment in it. [16:08:30] shauno: you may try https://www.mediawiki.org/wiki/Extension:Lockdown but someone with good knowledge of MediaWiki may be able to extract text from those namespaces [16:11:31] also, you could have several wikis [16:12:04] several wikis is right up there with burn it down as attractiveness goes [16:12:34] Ivy: we don't because "our" focus for developing MediaWiki is Wikimedia sites. No large investments are made into features that only benefit 3rd parties. [16:13:39] shauno: Lockdown allows you to configure read access per namespace, but it's never 100% secure. [16:13:59] it's also marked as incompatible [16:15:02] shauno: *sigh* as the original authors of this nasty hack, i can only say... sorry, no time to rewrite it. [16:15:34] oh I understand. I couldn't take it on either. I'm just frustrated because the topic we've been avoiding for years, has finally been brought up by the wrong person [16:16:18] DanielK_WMDE: There are plenty of use-cases within Wikimedia for this functionality. [16:16:36] DanielK_WMDE: Instead, we spin up private wikis instead because that's "easier." [16:16:48] Or rely on Special pages. [16:16:58] Ivy: collect them, write them down, and make the case [16:17:18] it *is* easier. it's really hard to make read permissions secure in mw [16:17:38] the assumption that reading is ok is sprinkled all over the codebase [16:18:04] It's difficult to get outside parties to invest in MediaWiki when we won't invest in features they want. [16:18:15] Sure, it'd be a big change. [16:19:13] Ivy: tech strategy wrt 3rd party users is a topic at the dev summit. please contribute here: https://phabricator.wikimedia.org/T183312 [16:19:29] also relevant: https://phabricator.wikimedia.org/T183318 [16:19:51] Ah, the dev summit. Where people get together to discuss starting to think about creating a working group to focus on improving code review. [16:20:41] Thanks for links. [16:21:31] andre__: Thank you sir I will check that [16:21:36] from my pov, interest is https://lists.wikimedia.org/pipermail/mediawiki-enterprise/2013-August/thread.html (or "the month mw-enterprise died") [16:22:04] Gopa: what is "that"? [16:23:35] andre__: I also tried with out going in to root but also I am facing same error [16:24:09] Gopa: https://www.mediawiki.org/wiki/Gerrit/git-review#Linux does offer more options? [16:24:19] Gopa: Regarding the issue you run into: If Ubuntu has broken package dependencies, you may want to contact Ubuntu packagers to fix packaging on Ubuntu. Not much we can do about it, I'm afraid. :( [16:26:11] andre__: Ok I will go through it thankyou for your suggestion [16:29:20] shauno: a long-term plan of mine is to resurrect Lockdown (or make a different but similar extension, depending on scope of changes), but I haven't found the motivation to do it yet [17:28:23] Hi guys, I would like to add a translate page to my manual: https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki_on_Windows_Server_2012_R2 [17:29:20] !e Translate [17:29:21] https://www.mediawiki.org/wiki/Extension:Translate [17:29:34] Unfortunately I need some permissions to mark this manual for translation. It is still a draft ... [17:30:05] Lanthanis: Sec. [17:30:10] @bawolff - This article / manual is located at the MediaWiki site [17:30:56] And I would like to create the manual in German and translate it to English afterwards [17:31:08] :) [17:31:14] That page has instructions on how to install the ext [17:31:58] I don't want to install it bc it is installed at MediaWiki.org [17:32:07] I think they're saying that they wish to translate that page on mw.org [17:32:12] it is already* [17:32:21] Indeed [17:33:14] Lanthanis: I made you a translation admin. [17:33:21] So you can probably approve translations now. [17:33:23] Thank you very much Ivy [17:33:26] No problem! [17:33:36] Have a nice evening! [17:33:40] You too. [18:19:49] On an attempted upgrade to MW 1.30 (from 1.29), I had a bevy of problems that forced a quick retreat. It started with this, upon attempting to access the site: Fatal error: Class 'MapCacheLRU' not found in /home/develo12/public_html/rst/includes/interwiki/ClassicInterwikiLookup.php on line 113 [18:23:17] I presumed that had something to do with not having updated the database. So, per the advice in the update instructions (https://www.mediawiki.org/wiki/Manual:Upgrading#Web_updater), it was off to /mw-config to run the database update. [18:24:08] MichaelBolton: did you unpach the 1.30 files over the old 1.29 (overwriting things), or over a new empty directory? [18:24:14] *unpack [18:24:46] Thanks Vulpix. Copied unpacked files via FTP. [18:25:09] but overwriting the old 1.29 or on a new directory? [18:25:09] that didn't quite answer Vulpix's question [18:25:21] in any case, you should unpack it to a *new* directory instead of overwriting the existing files [18:25:38] then copy LocalSettings and images over [18:25:52] I unpacked to a new file on a local machine. [18:25:57] I unpacked to a new file on a local machine. [18:26:01] FOLDER, not file. [18:26:17] on the server, the new files should go in a new dir [18:26:21] not overwriting the old files [18:26:27] So, yes, Skizzerz, I followed your instructions. [18:26:36] what you did on your local machine is largely irrelevant [18:26:42] OK, so no I didn't. [18:27:09] otherwise you have the old files sitting there too, and that can mess things up when files were deleted in the new version [18:27:16] but you still have vestiges of the old ones lying around [18:27:20] The documentation (https://www.mediawiki.org/wiki/Manual:Upgrading#Web_browser) isn't very clear on that. [18:27:46] overwriting will typically work just fine for point upgrades though (e.g. 1.30.0 to 1.30.1) [18:27:51] Skizzerz: Yes, I would have had vestiges. [18:28:08] it is very clear about this: https://www.mediawiki.org/wiki/Manual:Upgrading#Using_a_tarball_package [18:29:43] If https://www.mediawiki.org/wiki/Manual:Upgrading#Web_browser and https://www.mediawiki.org/wiki/Manual:Upgrading#Using_a_tarball_package disagree, then that's a problem. [18:30:03] MichaelBolton: those are two separate steps [18:30:06] step 1 is make a backup [18:30:10] step 2 is upload the new files [18:30:13] step 3 is run the updater [18:30:18] the web browser thing is step [18:30:19] *step 3 [18:30:24] the tarball thing is step 2 [18:30:44] anyway [18:31:05] I recommend renaming the existing directory on the server where the mw files are to something else (like if it's "w" right now maybe rename to "w-old") [18:31:21] then uploading the 1.30 to a brand new directory on the server named whatever the old one used to be [18:31:34] then copying over LocalSettings.php, custom extensions, custom skins, and images to the new directory [18:31:38] (from the old one) [18:32:04] where "custom extensions" and "custom skins" means "extensions/skins not already present in the tarball" [18:32:07] Thank you for that. That sounds important to be clarified in the page I cited. [18:32:29] after that you can proceed with navigating to /mw-config in your browser to finish the upgrade process [18:32:53] or you can rename it at the end, to minimize downtime (new files to /wiki-new, once all is good rename /wiki to /wiki-old and /wiki-new to /wiki) [18:33:04] well if it's broken right now, it's already down :P [18:33:27] ah, yes, but for future updates [18:33:27] Indeed, that would be true. But, yay backups. [18:34:59] Here are the instructions from the page I cited: [18:35:07] FTP or graphical [18:35:28] If you cannot access the command line on your server, download the MediaWiki tarball to your local computer and use 7zip to extract the tarball on your local PC. [18:35:31] After you extracted the files locally, use your favorite FTP client software to upload directories and files to the server. [18:35:33] yeah, the note above still applies to that [18:36:00] it could be a bit more clear [18:36:10] I would change the latter line to ** to a new folder on the server ** [18:36:26] likely by removing that section entirely [18:36:35] since the "using a tarball package" section already mentions FTP [18:38:08] the mw install/upgrade process is pretty terrible as far as web applications go [18:38:55] The docs look out of sequence on that point. I'm happy to help clarify it, if I can ask for your help in vetting it. [18:39:53] go for it [18:40:09] if something seems wrong I or someone else will come back around and fix it up later [18:40:25] note that the page is semiprotected [18:40:36] so you'd need to already have an autoconfirmed account to edit it