[20:45:29] I am getting a fatal error " „UnexpectedValueException“ for https://commons.wikimedia.org/w/index.php?title=Category:Argenta_(company)&action=edit [21:59:02] "[W@Nf1wpAIC0AABZ2NAYAAABI] 2018-11-07 21:57:43: Errore irreversibile di tipo "UnexpectedValueException" " <- where and how should I report an error like this? [22:00:40] Technical Advice IRC meeting starting in 60 minutes in channel #wikimedia-tech, hosts: @tgr & @nuria - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting [22:04:38] because in it.wikt I conflict my self and this error appears every time I try to see the preview of a new page [22:05:41] the conflict of edit appears also in preview (?) not when i save the page� [22:08:17] Wim_b: https://phabricator.wikimedia.org/ [22:08:48] although since you already reported it here I can look into it [22:10:16] tgr: do you want me to save this anyway on phab? [22:10:19] Wim_b: how do you conflict yourself over a non-existing page? [22:10:52] I conflict my self when I click "preview" :p [22:11:07] when I save is all ok� :) [22:11:17] nah, seems to be T205942 [22:11:18] T205942: Some edit submits get fatal InvalidArgumentException "The title does not refer to an existing page" from TwoColConflict extension - https://phabricator.wikimedia.org/T205942 [22:12:27] I still don't get why TwoColConflict is involved in a preview, but they seem to have a patch merged [22:12:32] just not deployed yet [22:12:33] when i. click "preview" in a new page, appears the error "[W@Nf1wpAIC0AABZ2NAYAAABI] ... "UnexpectedValueException" " [22:13:10] yeah but why is TwoColConflict even invoked there, it's supposed to run on edit conflicts [22:13:30] anyway, looks like the relevant team is on it [22:15:56] for now, I have disabled TwoColConflict to be able to use the preview and the error is gone [22:16:51] Relatedly, I clicked an edit section link on [[meta:Meta talk:Adminstrators]], and immediately get thrown into an edit conflict resolution - I've neither made a change, nor even seen the normal edit box yet [22:22:00] there's a deployment scheduled to 12h UTC tomorrow to fix this [22:22:11] until then, probably disabling the beta feature is best [22:26:05] sure� TY :) [22:50:13] Technical Advice IRC meeting starting in 10 minutes in channel #wikimedia-tech, hosts: @tgr & @nuria - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting [23:00:21] is tgr here/ [23:00:28] hola! [23:00:36] Hi everyone! [23:00:48] welcome to the Tech Advice meeting [23:01:32] feel free to ask nuria and me about any topic [23:01:56] this time, you can also ask in Spanish or Hungarian [23:02:19] * bd808 lurks [23:02:44] a mai műszaki tanácsadáson magyarul is tudtok kérdezni [23:06:18] I keep wondering if we are failing to advertise this once per month session well enough or if it is just at a bad time for folks with questions :/ [23:06:39] Hi, im wondering how do i debug a mw import xml file? [23:06:40] bd808: it is very west coasty time [23:06:44] im getting this error: https://phabricator.wikimedia.org/P7774 [23:06:45] This might be a stupid idea, but I was thinking about it earlier and I'm here. How much work would be required to allow users to give other users permission to edit a specific user page? Thinking for situations like working on large scripts. Alternatively, would it be possible to create a "scripts" namespace to allow collaboration on scripts. This would be nice for when users leave, are banned, or just stop maintaining their scripts. It could [23:06:45] either be locked behind a new group or under template protection. [23:06:48] (the file is 19gb) [23:07:52] Sorry for the wall-o-text. [23:08:25] zchrykng: seems that your question is about how to collaborate better with scripts? [23:08:52] zchrykng: it is not tied per se to user pages right? [23:09:05] nuria: Yeah, that is the thrust of the question. :) [23:09:16] paladox: that "page line 65535" is suspicious. 2**N - 1 numbers always make me think of overflow/truncation problems [23:09:26] oh ah [23:09:51] maybe a bug in https://github.com/WikiTeam/wikiteam [23:09:53] zchrykng: is gerrit not a good tool? that is the tool most commonly used is used for "code" collaborations [23:11:02] nuria: honestly, I wasn't aware of gerrit until now. Will check it out later and get back to you. [23:11:58] paladox: did you use XML_PARSE_BIG_LINES ? [23:12:03] see e.g. http://php.net/manual/en/domnode.getlineno.php#113529 [23:12:14] nope [23:12:26] does mw use that? [23:12:45] zchrykng: ok, you need a user and password that will be different from your wiki user: https://gerrit.wikimedia.org [23:13:08] zchrykng: in general MediaWiki tries to be pretty light on permission control [23:13:14] zchrykng: if you are thinking of collaborating on code that the wikimedia foundation does not need to deploy github is also an option [23:13:18] no ACLs and such [23:14:07] so regardless of how hard it would be technically (probably not super hard) it's not likely to happen [23:14:18] zchrykng: gerrit is the code review and git repository hosting system that Wikimedia technical contributors use for our free and open source projects. If you decide you want to try using it, there is more information at https://www.mediawiki.org/wiki/Gerrit [23:15:09] user-owned scripts are a problem, but the solution is more likely to be 1) transitioning to community ownership or 2) moving to a system that's better suited for individual ownership and control than MediaWiki [23:15:38] Yeah, totally understand. I was mainly thinking of user scripts. Is there a deployment pipeline for GitHub -> User script page? Or is it a build your own situation? [23:16:18] I think tgr was working on something like that as a side project :) [23:16:49] I was hoping for some kind of solution that would allow new editors to pick up discarded scripts without having to get everyone currently using it to notice and switch over when maintainers change. [23:16:57] 1) is part of the plan for Gadgets, except no one is actually working on Gadgets :( [23:17:00] see https://www.mediawiki.org/wiki/Gadgets_3.0 [23:17:32] 2) is a side project of mine, yeah. https://phabricator.wikimedia.org/T187749 [23:18:36] Okay will check those out, thanks! [23:18:59] there is definitely interest in this, both from the security side (scripts loaded from user namespace have probably been the main vector for Wikimedia projects getting hacked) and the power contributor support side [23:19:35] e.g. there was a bunch of discussion at the Wikimedia Technical Conference a few weeks ago [23:20:01] but no concrete plans at this point [23:20:03] Didn't figure I was the only person who thought there was problem. [23:20:46] if you are looking for something right now, I think frwiki has a github -> MediaWiki namespace sync bot [23:21:13] Any place I can sign up to hear about developments? I'm sure I can't help on the dev side, but would like to hear about discussions. [23:21:52] Not doing anything complex at this point was more asking for potential future stuff. [23:21:54] also, you can still add suggestions to the Community Wishlist until end of this week :) [23:22:11] Ah, yeah. Will do that. [23:22:24] https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019 [23:22:39] enterprisey will vote for it at least. XD [23:23:18] you can subscribe to the phab task, not sure what other place there is for updates [23:23:57] T36958 is the Gadgets task [23:23:58] T36958: Gadgets 3.0: Implement ability to create wiki-modules at a user level - https://phabricator.wikimedia.org/T36958 [23:24:31] T187749 is the git sync task [23:24:32] T187749: Make it possible to use code from an external repository for editor-controlled Javascript/CSS - https://phabricator.wikimedia.org/T187749 [23:26:18] Thanks! [23:29:05] paladox: https://codesearch.wmflabs.org/search/?q=XML_PARSE_BIG_LINES&i=nope&files=&repos= [23:29:09] apparently not [23:29:22] hmm [23:29:23] ok [23:29:30] i've commited a hack in our fork [23:29:36] to increase the lines [23:29:37] :) [23:31:34] Is this the channel for the technical advice IRC meeting? [23:31:40] yup [23:32:04] Cool [23:32:48] I was wondering, is there a JS function that goes from HTML elements to wikitext ranges? [23:33:06] enterprisey: yes yes [23:33:14] Whoa really [23:33:21] That would be useful [23:33:27] enterprisey: yes to "is this teh place to ASK questions" [23:33:30] *the [23:33:34] Ah I see [23:33:50] I was going to write the function myself but wanted to maybe save myself a little work [23:33:59] enterprisey: what do you mean with " wikitext ranges" [23:34:10] Start and end indices [23:34:40] enterprisey: I see, start and end indices of markup? [23:34:49] E.g. if a page contains "Hi" in a div, and I call this function and pass in the div, I should get [0, 2] [23:34:51] Yeah [23:35:16] enterprisey: you mean in an editor window? [23:35:17] Sorry that's wrong, just the text "Hi" without a div [23:35:34] tgr: from a user script, in regular "view" mode [23:36:20] I can approximate this with a Parsoid round-trip but it's inefficient [23:36:26] so in *regular* view mode that's highly unlikely [23:36:47] the Parsoid view contains wikitext annotations and you can probably use those to get a position [23:36:56] It comes up very frequently writing a certain sort of user script [23:37:01] ...the Parsoid HTML... [23:37:06] Yeah I was looking through the Parsoid docs [23:37:37] but that HTML is not used except in a few fringe cases (e.g. when you save a VisualEditor edit but don't reload the page) [23:37:41] It would be nice to be able to do this without multiple API calls, though [23:38:10] you could replace the page content with the one from Parsoid, I guess [23:38:25] Yeah, the trivial way is use Parsoid to get the annotated HTML, add "flag" elements around the target element, send it back to wikitext, and diff to find the "flags" [23:40:07] And I haven't tried this in practice, but it might be tricky to recover the flags in all cases - but that's just because there are many difficult cases for this function [23:41:22] My bad [23:42:15] Parsoid has element IDs which are probably easy to convert into positions on the server side: https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec/Element_IDs [23:42:44] so if this use case is common enough, it should be easy to build a nicer API than adding flag elements [23:42:56] but you'd still have to start with the Parsoid HTML [23:43:07] Yeah, agreed [23:43:25] The Element IDs look very cool, I'll look into those more [23:43:25] I very much doubt you can do anything useful with the PHP parser output in this regard [23:45:30] Yeah, I can try working on the "nicer API", I was just wondering if it already existed [23:45:36] Thanks for the help! [23:46:26] by nicer API I mean an endpoint which gives you a map of element ID to wikitext position or range [23:46:58] I don't know much about the Parsoid internals but I imagine that would be trivial to create as a parsing byproduct [23:47:44] and they are already working on splitting up the result of a parse into separate API endpoints (page HTML + page metadata) so it shouldn't be conceptually hard to add another one [23:48:27] of course #mediawiki-parsoid is a better place for these questions