[15:58:09] Hi! Has anyone else encountered issues with outlook and safelinks concerning user confirmation by email? When I create a user and get the confirmation link, my wiki tells me it doesn't work. If I send it to gmail without safelinks it works fine though. Also, wikipedia's confirmation works even with safelinks [15:58:58] Is Outlook modifying it? [15:59:03] Yes [15:59:18] It makes it all weird and unreadable, but it works for the wikipedia one even though it looks messed up [15:59:48] :( [16:00:09] So I'm wondering if there is some setting I need to change on mediawiki to make it accept the safelinks version of the verification [16:00:32] I would assume my browser "translated" it back into its pure form, but I know nothing about this [16:02:57] You'd have to look at the URL in the browser HTML and see what it ends up after you've clicked and redirected [16:04:44] That's a good tip. I will do that and see if I can find out anything [16:06:21] hey Reedy, is there an easy way to determine what older version of MediaWiki supports what PHP/mysql versions? [16:07:37] you can check the release notes for the version, it'll state what PHP and MySQL versions it supports [16:08:21] https://www.mediawiki.org/wiki/Compatibility#PHP [16:08:27] https://www.mediawiki.org/wiki/Compatibility#Database [16:08:33] nice :) [16:08:34] even better :) [16:08:38] thanks, thats great [16:09:15] That's odd, the html code on the link that doesn't work appears to have the correct link in it. So it was translated correctly [16:09:17] and correct me if im wrong please, but you extract the .tar file and overwrite all files, then run the update.php file? [16:09:55] Basically [16:10:09] Windows gets a bit funny with casing of files, as some will be renamed [16:10:19] So it is sometimes easier to extract to a clean directory [16:10:28] And of course take backups of db and files on disk [16:10:53] !upgrade [16:10:53] http://www.mediawiki.org/wiki/Manual:Upgrading [16:10:55] !update [16:10:55] 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 [16:10:58] meh [16:11:10] extracting to a clean directory also ensures that, in the event files are deleted in a new version, that the old version doesn't stick around. Generally won't cause issues if they do, but no reason to clutter up the install with unused files [16:11:30] does that work on a windows server too? [16:11:38] sure? [16:11:47] nothing about the mediawiki update process is OS-specific [16:11:50] oh yeah, duh.. php.exe [16:11:51] sorry [16:11:56] Windows is case insensitive, so it gets upset [16:12:10] So wehn Foobar.php is renamed to FooBar.php... It can cause problems [16:13:10] haven't ever heard of that particular thing being an issue before, /me does some research [16:13:47] yeah would think windows wouldnt care [16:13:56] linux , i could see issues w/ case [16:14:46] Sure, but if PHP is looking for a specific case, and it doesn't exist... It causes issues, because MW put the newer contents in the old file name etc [16:14:56] We've definitely seen people report bugs with this before [16:15:12] isnt that up to the OS though? [16:15:25] to php (on windows) FooBar.php is the same as foobar.php [16:16:18] To Windows it is [16:16:20] Inside PHP it isn't [16:18:31] ZeroWarz: https://lists.wikimedia.org/pipermail/mediawiki-l/2020-March/048327.html [16:18:44] and https://lists.wikimedia.org/pipermail/mediawiki-l/2020-March/048330.html [16:18:50] Basically, that's is what can happen [17:08:47] So, the new docker-compose environment uses version 3.7 of the docker-compose.yml file, but that's not supported by the version of docker-compose that ships with ubuntu 19.10. That only supports 3.3. [17:08:53] Is that a known problem? [17:09:55] you'd have to ask kostajh why 3.7 was chosen [17:09:55] https://github.com/wikimedia/mediawiki/commit/89083ea868453372ebfec9a861336ae55aae1508 [17:10:02] Dunno if it was arbitary, or what version he had locally [17:10:18] IIRC, there's plenty of docker packages in deb etc if you want to use the docker repos [17:11:22] duesen: there’s a Phab task about this. You can download the latest stable of docker-compose from the link in DEVELOPERS.md [17:11:54] We started with the latest version, because, it made sense to start there rather than some arbitrarily earlier version [17:12:23] T246021 [17:12:23] T246021: Downgrade docker-compose.yml version - https://phabricator.wikimedia.org/T246021 [17:13:27] >But Docker's documentation tells you to install docker-compose via curl, or pip, or to run as a container and not to install via your package manager. [17:13:29] heh [17:13:37] So many things in these sorts of situations :) [17:13:52] kostajh: thanks. [17:15:47] And looking at that task again, it looks like we don’t document what to do in the DEVELOPERS file. We probably should [17:21:20] trying to install with pip. install is successful, but i can't find the executable [17:21:26] where would it usually be? [17:21:31] it'S not in /usr/bin [17:22:23] `/usr/local/bin/docker-compose`? [17:23:55] duesen: do you install other stuff with pip? If so you probably have modified your $PATH to find the bin directory [17:24:02] I would install with curl [17:24:39] I hate installing stuff with curl. no updates, not integrity checks. just random things loaded from random places executing on my system [17:25:41] ok, found it in /usr/local/bin/docker-compose, though one shell still wants it in /usr/bin/docker-compose for some reason. [17:25:52] ¯\_(ツ)_/¯ [17:26:03] anyway. trying to run it gives me: ImportError: No module named ssl_match_hostname [17:26:07] yay dependency hell [17:26:35] yeah. Pip / python hell. I prefer a non self-updating curl’ed script any day of the week [17:27:03] but that doesn't solve dependency hell either, does it? [17:27:26] in my experience, it just gets worse. sticking to apt avoids that [17:27:39] https://stackoverflow.com/questions/42695004/importerror-no-module-named-ssl-match-hostname-when-importing-the-docker-sdk-fo [17:28:09] anyway. I think i'll postpone this experiment until tomorrow. [17:28:44] kostajh: are you up for some co-working tomorrow? maybe i can pester you about this over coffee ;) [17:30:59] duesen: yea sounds good [17:31:07] The run as container version doesn’t seem bad [17:31:10] https://github.com/docker/compose/blob/9f373b0b867838a4f194f665c4099b5ba6b67345/script/run/run.sh [17:31:57] https://docs.docker.com/compose/install/ under “alternate install” [17:31:58] i need to run a container to buld the containers that i can then run to debug mediawiki?.... [17:31:59] *sigh* [17:32:06] by brain hurts [17:32:44] the solutions offered for the ssl_match_hostname issue don't work for me. running into conflicts when trying to install that package [17:33:13] The “run compose” with container approach CI should probably lay be preferred since so far we have tried not to include any other dependencies (eg Python) on the host [17:33:38] *CI is a typo there [17:36:00] gping back to mw-docker-dev for now [17:36:32] though xdebug isn't working with that for me any more [17:36:46] * duesen is annoyed with technology [17:39:42] Yeah I had trouble with xdebug with MDD also. It should be straightforward with the core environment. [18:44:43] so according to that compatibility page... MW 1.15 can take PHP 5.3.3+ until 1.26 [18:44:52] what PHP file do I use to get it updated? [18:44:53] https://usercontent.irccloud-cdn.com/file/ZamjHJLR/image.png [18:47:55] ZeroWarz: it should not matter, unless you're compiling your own extensions for PHP. try the first one [18:48:15] what is NTS? [18:49:55] No Thread Support [18:50:01] i think it stands for "not thread safe", but i don't remember what that really means. [18:50:12] hm, or maybe that [18:50:58] i have php-5.5.16-nts-Win32-VC11-x86 installed and it works 🤷‍♂️ [18:51:54] something about not taking into account possible changes between reading and writing by other parts of the program, iirc [18:56:43] MatmaRex: yeah im just trying not to break too much :) [19:02:54] crap.. broke it ;) lol [19:37:19] kostajh: Do you know what Flow's generatecss.php script is used for? (if anything) [19:37:40] It matched a code search for wgResourceModules as part of T247265 [19:37:43] T247265: Export extension.json "ResourceModules" as attribute instead of config - https://phabricator.wikimedia.org/T247265 [19:37:58] which will remain supported for writing to, but no longer supported to read a complete registry from. [19:37:59] Krinkle: first I’ve heard of it! [19:38:19] I could look later... [19:38:52] well, if it hasn't been used it's probably fine to remove or leave as-is for now. [21:05:54] alright php gurus.. updated to 5.3.3 and can get to phpinfo.php, but trying to access mediawiki or phpmyadmin (anything really) I get a 404 not found [21:30:22] in which folder is each? [21:30:47] i copied phpinfo.php into default site, and my media wiki folder [21:30:50] i can get that to open [21:30:57] but i cant open index.php for mediawiki, or phpmyadmin, etc [21:31:09] missing something, no idea what [21:31:19] apparently php changed big time in 5.3 to fastcgi or whatever [21:31:32] if phpinfo.php is in the same folder as mediawiki/index.php [21:31:36] if one works, so should the other [21:31:41] but mw, according to the compatibility site, should work with that php version [21:31:46] yep! [21:31:58] it could give an error when run, but not a 404 [21:32:00] my thoughts exactly [21:32:19] does that mean like.. the media wiki files are incompatible? [21:32:24] but yeah shouldnt be a 404 [21:32:54] you could for instance miss a php extension [21:33:23] in fact, the installer is designed to detect that kind of things and not to break [21:33:52] what installer? mw? [21:34:34] mediawiki has an installer [21:34:37] im not touching mw really.. simply trying to upgrade the php version at the moment [21:34:47] if you don't have a LocalSettings.php, it leads you there [21:34:59] tryin to get php on a newer version, so then I can upgrade mw.. then migrate to new server eventually [21:35:17] yeah im just trying to use the current mw thats installed on this old box, 1.15 [21:35:21] and update php on it [21:36:03] you should really jump to php 7 [21:36:17] i will.. but i cant with 1.15 :) [21:36:20] thats the end goal [21:36:25] https://www.mediawiki.org/wiki/Compatibility#PHP [21:36:36] you install last php 7 [21:36:39] then last mediawiki [21:36:51] no need for intermediate steps [21:37:06] Reedy said i should take steps :\ [21:37:07] you keep a sql dump as a backup, of course [21:37:21] it shouldn't be needed [21:37:34] big jumps are less tested, but they should work [21:37:54] yeah i only noted that if you had less than 1.5 of mw, you need to do other stuff [21:38:02] but greater than 1.5, you should be able to get to latest [21:38:06] if i read that right [21:38:35] make a full backup [21:38:40] a database dump [21:38:45] vm's, all backed up [21:38:52] good [21:38:53] yeah mysql version would be newer too [21:39:05] then you can always safely go back if needed [21:39:19] i'd simply jump to last version :P [21:39:42] So.. install mysql (latest) and php (latest) on newer windows server... copy over the wiki folder from old server to new server.. [21:39:49] create a site pointing to it [21:40:00] then extract new mediawiki over old mediawiki files [21:40:05] and run update? [21:40:40] I would actually extract the files from last mediawiki version [21:41:04] follow the install steps, and connect to the db [21:41:31] then copy the contents from the old LocalSettings.php that you may need [21:41:36] and the upload folder [21:41:52] you will end up with a cleaner site [21:44:49] connect to the db.. you mean a fresh db? [21:47:04] if you provide the details of an old db, it will pick it and update it [21:47:12] but you could also setup a new db [21:47:22] as a way to test the new mediawiki is working fine [21:47:48] i was scared to put in the old info / db name, wasnt sure what it would've done [21:51:32] it would go ahead and update it [22:31:18] dumped mysql and restored it on new server [22:31:31] copied over mw folder to new server.. copied mw1.30.2 over the top of that [22:32:02] tried to launch /mw-config/index.php and it says missing "fileinfo" but from what i can tell, its there [22:32:21] and btw, reason I didnt go latest, is cause php is alreadyon this box and im not sure what might break if i update php [22:46:56] Just because the file is there, doesn't mean it's loaded [22:53:16] ZeroWarz: do not copy one MediaWiki version over another. This may leave leftover files behind that may cause problems. On major upgrades always unpack on an empty directory and copy over LocalSettings.php [22:56:32] i atually did that [22:56:36] sorry for miswording [22:56:42] the wiki loaded but no images, etc [22:56:45] tryin to figure that out [22:57:13] user uploaded images? or images in the skins etc? [22:58:18] user uploaded i believe [22:58:35] i figured out fileinfo thing [22:58:35] Are they in page content? [22:58:42] php was using some random php.ini file that i wasnt editing [22:58:51] Did you copy the images folder from your old install? [22:59:38] not yet [22:59:42] started from scratch again [22:59:49] i got the wiki loaded [23:05:21] https://usercontent.irccloud-cdn.com/file/MqeI2l6E/image.png [23:05:23] old / working [23:05:38] https://usercontent.irccloud-cdn.com/file/smVKj7dX/image.png [23:05:42] new / missing stuff :) [23:06:06] I'm guessing that's some extension [23:07:47] hmm :) [23:08:06] not sure why the logo wont load either [23:08:16] $wgLogo not set in new LocalSettings? [23:08:19] there it goes, hard refresh [23:08:23] logo is there now [23:08:31] its SUPER slow on the new one too [23:08:38] takes like 5-10 seconds to load a page [23:08:49] Likely caching [23:17:17] Reedy: if i put those lines in [[ ]]'s then it turns it into a hyper link [23:17:23] but it still says too much [23:18:00] https://usercontent.irccloud-cdn.com/file/T0biGwvA/image.png [23:18:43] A wiki link is like [[Foo|Bar]] [23:19:34] Do you have an entry for wgUrlProtocols in your LocalSettings? [23:20:28] yes I see file:// in ther [23:20:31] was just lookin [23:22:19] hmm works fine like that in old version of mw [23:39:36] when I upload an image with a summery text, can that summery text be automatically used as a caption for that image on a page? If I put that image on multiple pages, then the caption only has to be put in a single place, instead of every page that contains the image. [23:41:35] No [23:41:44] You could use a template or something instead [23:41:57] Okay [23:41:59] bah cant figure this out. wonder its its some syntax change from old mw 1.15 to new 1.30 [23:43:08] ZeroWarz: I doubt it [23:44:27] yeah you would know better than i on that [23:46:14] $wgUrlProtocols[] = 'file://'; [23:46:16] That works fine for me [23:46:20] Just had to purge the page after setting it [23:49:26] you made change in localsettings.php then refreshed mediawiki page? [23:49:57] I used ?action=purge because a simple refresh didn't change the display [23:51:07] wtf im confused.. hold on [23:51:12] might be confusing old/new local settings [23:53:16] lols [23:53:31] yeah i dont even see a $wgUrlProtocols on new server.. sigh [23:53:53] best way is to edit LocalSettings.php or can you do that from mediawiki itself somwhere? [23:54:20] On windows? Don't use notepad [23:54:29] Notepad++ is fine though [23:54:47] Im going to copy the old localsettings.php to the new install and see what happens [23:54:51] think we tried it before and site wouldnt load [23:56:11] now I get a 500 error when I do that [23:56:30] guess i just have to use the new LocalSettings.php and add things that are missing from old one [23:56:47] or look at your server logs :P [23:58:27] doesnt say anything really.. just url with "500" at the end