[00:08:26] Anyone from MW dev team explain what we are seeing here: https://github.com/SimpleMachines/smf-mw-auth/issues/10#issuecomment-254368526 [01:13:18] SleePy: from first look, it looks like a bug in MediaWiki [01:17:42] SleePy: filed https://phabricator.wikimedia.org/T148486 [01:18:25] Thanks legoktm. That is what I was thinking. Somehow either null or somehow the IP isn't validating as v4 or v6. [01:18:55] The code lets it return on if its valid ip4 or not valid ip6. Which is weird is weird it allows that [01:19:41] SleePy: yeah. Also, I noticed your extension is using $wgAuth, which is deprecated since 1.27, we have a new authmanager plugin system which you should probably convert to [01:20:34] ooh, Guess I will have to look into the documentation for that then. This was built a long time ago and just updated and maintained. Do plan on getting it working for the next LTS release [01:21:37] 1.27 is the LTS :) [01:21:54] Yes, but the LTS after that. Don't remember what it was [01:22:24] Looks like from a quick search I would be implanting MediaWiki\Auth\PrimaryAuthenticationProvider [01:22:25] 1.30? that's about a year and a half away... [01:22:30] https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager are the docs [01:23:44] Yep thats what I found. Will have to read up on that and look at some example configs. The SMF auth handles everything from login, updating access levels and creating the user if it doesn't exist, so will need to check into it all. [01:24:34] awesome :) [01:47:40] Actually I'm not sure if I can use the PrimaryAuthenticationProvider. We handle logins directly if they have a valid logged in session from SMF. So session provider almost sounds like what we want but it doesn't sound like it handles any auth part. [01:50:47] SleePy: maybe you need both? anomie and tgr are usually the go-to people for authmanager/sessionmanager help fwiw [01:51:49] the SessionProvider authenticates based on information that is present in every request [01:51:52] Possibly. Trying to locate example auth plugins right now. Don't always find mw extensions easy to locate [01:52:26] the AuthenticationProvider is for handling a separate login action [01:53:06] Ok, then it would be session handler. We would validate the login via our methods and then tell MW to log that user in if its a valid login (or create the account if non exists) [01:54:25] if a login happens at all, it should probably happen via an AuthenticationProvider [01:55:06] you will run into all kinds of trouble if you just build your own login/signup system that the framework is not aware of [01:55:18] The only thing we do with login is if they go to the login page, it redirects into our login page, we handle the login and create cookies, then send them back to MW, where the auth validates the cookie and signs them into MW [01:56:07] AuthenticationProvider can handle redirects [01:56:21] you can check the GoogleLogin extension for an example [02:00:49] will do [05:54:07] !admin a l v a r o m o l i n a y j e m s e a m a n [05:54:07] To recreate the admin user, run "php maintenance/createAndPromote.php" on the command line. [05:54:12] !ops [05:54:31] Goaaaaaaaaal! [06:27:40] I installed OAuth extension but how i can make mediawiki accessable without password through other website? [06:59:30] I'd like to an edit summary list for use to select summary description directly, how can I do this? [07:02:05] ctmarco: it would be easier to help if you explained what you want [07:02:49] me? [07:03:56] Everytime when I add article, I will add an edit summary to remark [07:04:01] (see http://xyproblem.info/ ) [07:04:17] but some repeat summary are used all the time [07:04:41] so I'm thinking if I can make a frequent used list for edit summary [07:05:05] just click item, and make it insert to summary edit text area [07:05:12] that will be nice [07:47:03] JHK: there's https://en.wikipedia.org/wiki/MediaWiki:Gadget-defaultsummaries.js I'm not sure if you can add custom edit summaries without editing the code [07:48:40] How can i under this table still a table ? {| class="wikitable" style="float:left; margin-right:1em" |+ Linke Tabelle ! Überschrift 3 || Überschrift 4 |- | Feld 1 || Feld 2 |} {| class="wikitable" style="float:left; margin-right:1em" |+ Linke Tabelle ! Überschrift 1 || Überschrift 2 |- | Feld 1 || Feld 2 |} [07:53:31] #wikipedia-de [12:20:55] wondering if this sounds worthy of a bug report. [12:21:32] for years I've built my wiki by doing a git checkout from 1_27 (or 1_26, etc. ie from the version branch) [12:22:33] that has always worked fine, however at the moment its causing a failure during 'php maintenance/update.php --quick' which is resolved if I switch to the 1.27.1 tag [12:22:56] what's teh error? [12:23:18] the failure is that the update.php complains [12:23:20] MediaWiki 1.27.1 Updater wikimedia/cdb: 1.4.1 installed, ^1.4 required. mediawiki/chameleon-skin: 1.4.0 installed, ^1.4 required. mediawiki/semantic-media-wiki: 2.4.1 installed, ~2.4 required. mediawiki/semantic-result-formats: 2.2 installed, 2.2.* required. Error: your composer.lock file is not up to date. Run "composer update" to install newer dependencies [12:23:32] have you run composer? [12:23:35] however running the composer update triggers this message [12:23:54] ./composer.phar update > ComposerHookHandler::onPreUpdate Loading composer repositories with package information Updating dependencies (including require-dev) Nothing to install or update Generating optimized autoload files [12:24:12] and re-running it doesn't change the response from update.php [12:24:57] what version of composer? [12:25:17] Composer version 1.2.1 2016-09-12 11:27:19 [12:25:26] freshly installed only minutes earlier [12:25:43] installed via curl -sS https://getcomposer.org/installer | php [12:26:24] scary [12:26:43] curl pipe php? or the error? [12:26:52] or both [12:26:55] curl pipe php, yeah [12:26:59] the error is confusing, not scary [12:27:32] Are you able to break your site for a few minutes? [12:27:38] yes [12:27:55] mv vendor vendor.old [12:28:00] and run composer update again? [12:29:33] I do note, that with newer composer like that, on the 1.27.1 you'll get some other weird messages [12:29:41] https://github.com/wikimedia/mediawiki/tree/REL1_27 [12:29:55] I backported a fix to the rEL1_27 branch for it, but not released yet [12:29:56] https://github.com/wikimedia/mediawiki/commit/9b27d90b57065c2b75993287fb9adbd941f504b5 [12:30:04] So you might be better not using the 1.27.1 tag, but just follow the branch [12:30:35] I don't think it'd fix the issue above, but it's possibly related [12:33:00] https://dpaste.de/EDqD you can ignore the first 25 lines [12:33:45] have you git pulled recently? [12:34:06] extremely . I'm on 9b27d90b [12:35:11] what local modifications have you made to composer.json? [12:35:13] for smw etc? [12:36:54] https://dpaste.de/V9f7 [12:36:57] I'm gonna have to run.. Gotta take my macbook in for repair. For the third time this year. Lucky m [12:37:30] why bump cdb? [12:37:58] I note, we don't actually use modifiers in the normal one... [12:38:11] Which sounds related to teh problem [12:38:14] I don't do anything fancy, I'm running this line [12:38:17] run('php composer.phar require wikimedia/cdb') [12:38:42] as for what upstream dependency led me to that, at the moment I do not honestly know [12:39:00] but I'm not explicitly asking for ^1.4 [12:39:18] if you feel that's the source of trouble, I can drop it and rebuild [12:39:30] Just drop the ~ and ^ [12:39:31] Actually [12:39:35] I know this is an issue [12:39:42] I proposed a fix, but it was deemed not wanted behaviour [12:39:58] https://gerrit.wikimedia.org/r/#/c/300891/ [12:40:07] Replace the modifications you made with explicit versions [12:41:55] please clarify, I currently have these lines in my build script [12:41:56] https://dpaste.de/UtRv [12:42:04] what do you suggest instead? [12:47:08] Reedy, you say "Just drop the ~ and ^" but (to the extent I understand composer) those aren't part of my process for cdb. Can you please clarify what I should be doing differently? [13:26:56] Hiii [13:47:44] if cariaso comes back... [13:48:10] literally, remove the ~and such [14:42:53] Reedy got pulled into a work thing, but have seen your comment in the chatlogs [14:46:02] cariaso: So you can do that for the two semantic ones... [14:46:15] Might be worth hard coding one for CDB too so it doesn't do ~1.4 or whatever [15:56:20] is ?preload= in vanilla mediawiki? [15:56:28] I can't remember if it's pulled in from inputbox [15:57:18] yeah, it seems to be [16:53:15] Reedy, changing eliminate ^ and ~ was not sufficient as shown at https://dpaste.de/MfuT -- they don't seem to accept 1.4 as equivalent to 1.4.0, ultimate specifying the .0 did allow the build to continue [19:17:11] I am on ubuntu it claims I need mbstring [19:17:12] and xml what do I do? [19:18:13] Install them? [19:18:25] yes I'm not sure of the packages [19:18:30] what version of ubuntu? [19:18:33] 6.04.1 LTS [19:18:37] 16.04.1 LTS [19:18:48] so php7? [19:19:14] apt-get install php7.0-mbstring php7.0-xml [19:19:14] Yes, it is php7 on 16.04 repositories [19:20:38] hmm already installed [19:21:03] http://askubuntu.com/questions/772397/mbstring-is-missing-for-phpmyadmin-in-ubuntu-16-04 this can be helpful [19:21:04] restarted your webserver [19:21:36] yeah should have tried that, but there was a confusing comment about the packages being renamed in the wiki [19:23:05] great [19:23:52] mildly interesting to note restarting the system did not suffice so it had to reset some persistent settings somewhere [19:24:17] restarting the service worked [19:45:42] Hi :) Does someone work on math formula rendering in MediaWiki ? [19:45:58] someone does, yeah [19:46:15] (I mean, someone in here, because there is an existing extension) [19:46:36] The main person isn't about... [19:46:55] wrong phrasing, I am looking for someone who works on math rendering [19:48:37] I have a few questions and i'm not sure where I should ask [19:48:56] Nalou: Just ask here, and maybe someone can help you [19:49:07] ok! [19:49:21] happy to help as well [19:50:18] Some background: I work on wikisource mainly on scientific books. I use the math extension a lot to render... math. [19:51:23] The wikisource working is that pages are corrected in a specific sub-space and are transcluded in the main space after [19:51:47] in the end, it creates a whole book which can but cut in several subpages for chapters, etc. [19:52:41] but, the thing is I (and others too) chose to use to display all characters which appear in a math formula. [19:53:05] Also pages are way too heavy because of SVG rendering [19:54:15] I saw on the internet that MathJax can render nicelly math formula, even in text. [19:54:21] do you have a specific question, or are you mainly concerned about performance of SVG rendering? [19:54:41] hum it's more about the future of math rendering in mediawiki [19:54:56] we are actually using MathJax server side, as that is lighter weight than doing it client side [19:54:58] see T148576 [19:54:58] T148576: Security review request: Electron render service - https://phabricator.wikimedia.org/T148576 [19:55:03] err https://www.mediawiki.org/wiki/Mathoid [19:55:28] certain simple display math is rendered as plain text / HTML [19:55:54] I read about mathoid before coming here [19:55:55] ok [19:56:05] but anything that requires special fonts is rendered to display MathML, and falls back to SVG or PNG for browsers that don't support MathML [19:56:21] ok [19:57:30] we did some limited benchmarking before introducing SVGs, and found that little difference vs. PNGs [19:57:30] i only have one exemple of what seems to be an HTML5 design website which uses MathJax [sorry it's in French, but math is universal ;)]: http://femto-physique.fr/mecanique_des_fluides/mecaflu_complement1.php [19:58:35] i may not be skilled enough in web tech, but is there any possibility that MediaWiki will utimately use the same kind of math rendering ? [19:59:39] as I said, we use it for simple math [19:59:58] it won't work reliably across browsers for complex math [20:00:22] ok [20:00:39] even MathML is less than reliable because of font issues, and is only supported in Firefox at this point [20:00:47] it's due to a lack of support in web browser? [20:00:48] ok [20:01:33] at this point, server-generated SVG is pretty much the best we can do that scales well, supports accessibility, and works consistently across devices [20:02:34] the MathJax team is developing server-side generation further though, and might push the boundary of what can be rendered in HTML over time [20:03:37] ok, thanks for the explanation [20:03:57] Nalou: we have several volunteers working on math; you might want to contact them if you are interested in helping [20:04:07] for the website I posted before, it renders well to me because I have the proper fonts installed and an up-to-date web browser ? [20:04:26] Moritz Schubotz is the author of mathoid, and very knowledgeable [20:04:38] he can be reached as @physikerwelt on phabricator [20:04:59] Nalou: math fonts are critical, yes [20:05:07] things like integrals fall apart otherwise [20:06:46] ok [20:06:50] (thanks for the contact, I'm afraid I don't have the knowledge to help them :() [20:07:15] also see http://pbelmans.ncag.info/blog/2015/12/21/on-towards-mathjax-3-0/ [20:08:20] Moritz also wrote a paper about mathoid, see https://arxiv.org/pdf/1404.6179.pdf [20:08:41] thanks for all those information [20:09:01] you are welcome! [20:10:50] the link with my concern about math books on Wikisource is that I'm worried that people might want to switch to plain html characters using code like α. Because if one day we can render proper math using LaTeX formulation, we might need to rewrite everything [20:12:09] "Today, more then 10 years later, less than 20% of people visiting the English [20:12:09] Wikipedia, currently use browsers that support MathML " [20:12:43] from Moritz paper in 2014, not very encouraging :( [20:14:46] Nalou: is there an actual performance issue, and are people actually using entities over ? [20:15:53] I don't think there is a performance issue, pages are just using a lot of and it takes naturally a lot of time to load [20:16:12] but the SVG rendering is awesome :) I really like it [20:16:56] it's just slow and some people seem to not remember when the internet was slow ^^ [20:17:56] if you have a particular case that is especially slow, could you report that on phabricator? [20:18:34] if there are significant issues, we could consider inlining SVGs to avoid the need to load them separately [20:19:25] but doing so has downsides as well, so we'd need good data to back up such a decision [20:19:45] I am wondering about converting wiki content to a desktop publishing application [20:21:29] in his paper, Moritz indicates the average time needed to load the Fourier transform page (https://en.wikipedia.org/wiki/Fourier_transform) and it's a time comparable to the one needed to load the page I talk about so I don't think there is an issue. It's long to me too [20:22:33] but if I encounter an issue, I'll let you know on phabricator [20:23:03] Nalou: thank you! [20:25:25] Maybe one day the full TeXlive distribution will be supported by MediaWiki [20:25:30] and people will use updated web browsers [20:25:33] with a nice set of UTF8-friendly fonts... [20:25:52] One day :p [20:26:55] Thanks for the awesome work, it's already great to be able to write math and have a nice rendering [20:27:46] and thank you for your answers [20:28:30] Nalou: https://www.google.com/get/noto/ [20:28:40] UTF8 friendly font that Google is working on. [20:29:09] « When text is rendered by a computer, sometimes characters are displayed as “tofu”. » [20:29:11] hahaha [20:29:29] great idea, I was not aware of it. [20:44:13] bye! [21:39:54] or webfonts... :P [22:03:49] tgr, Reedy: I figured out the problem (lighttpd and php-cgi told me more for some reason.) I was calling $user->getID() when $user was false. [22:04:12] gj [23:06:49] MTres19: feel free to file a bug if the error did not show up in the logs [23:07:17] I think MediaWiki error handling is not well tested on PHP7 [23:58:10] tgr: Okay.