en

[00:00:49] put another way, what is the advantage to doing the way you are in that patchset? [00:01:13] if it's just for cleaning up MobileFrontend.php, we can still put the module definitions in another file and include it in MobileFrontend.php [00:03:40] awjr: mm.. core uses it.. [00:04:02] i assume RL uses it to actually load $wgResourceModules or whatever? [00:05:05] New patchset: Jdlrobson; "Bug 47882: Redefine default modules for Minerva Skin" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/63589 [00:05:53] awjr: i guess we could use array_merge.. [00:06:19] jdlrobson: or you could just leave them as they are and just stick em into a separate file that you include in MobileFrontend.php [00:06:27] awjr: not really clear why it's discouraged :( [00:06:33] jdlrobson: im tryig to find out [00:10:11] jdlrobson: is there a reason though to not just stick the definitions in another file and include() it in MobileFrontend.php? that would be easiest and probably lightest weight anyway [00:17:54] New review: awjrichards; "what is the advantage to this approach? i still dont totally understand why, but using the ResourceL..." [mediawiki/extensions/MobileFrontend] (master) C: -1; - https://gerrit.wikimedia.org/r/63997 [00:18:29] jdlrobson: awjr: not really clear why it's discouraged [00:19:00] awjr: I'm happy to do you as you suggest my main goal is indeed readability.. [00:19:04] yeah, im still waiting to hear about that from a RL dev [00:19:58] let's do that then, jdlrobson, that will be more readable too (as it's closer to how this stuff is normally done and certainly how adding RL modules is documented) [00:24:41] awjr: k fixing up now [00:25:05] cool [00:28:01] New patchset: Jdlrobson; "Move ResourceLoader modules to their own file" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/63997 [00:28:02] awjr:^^^ [00:30:41] Change merged: Jdlrobson; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/63966 [00:31:14] ok last q jdlrobson, why not stick the boilerplates in the include as well? [00:31:25] awjr: boiler plate is used elsewhere [00:31:34] well $wgMFMobileResourceBoilerplate is [00:32:00] (other one isn't so i'll move back) [00:32:16] well that's ok, the file is getitng included so it functions exactly the same as if it were in MobileFrontend.php [00:32:31] i think it would be nice to have all the resources stuff in one place [00:32:46] New patchset: Jdlrobson; "Move ResourceLoader modules to their own file" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/63997 [00:33:59] New patchset: Jdlrobson; "Move ResourceLoader modules to their own file" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/63997 [00:34:06] awjr: ^^ (me didn't realize how globals work in php o_O) [00:34:13] New review: Krinkle; "(1 comment)" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/63997 [00:34:51] :p [00:36:11] New review: Krinkle; "I'd recommend using the register module modules and return an array from Resources.php and include t..." [mediawiki/extensions/MobileFrontend] (master) C: -1; - https://gerrit.wikimedia.org/r/63997 [00:36:25] New review: Krinkle; "s/register module modules/register module hook/" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/63997 [00:36:37] didn't mean to -1, just a suggestion:) [00:38:06] hahah Krinkle so like i did originally :) [00:38:09] awjr: ^^ [00:38:17] jdlrobson: really? [00:38:22] interesting [00:38:26] Krinkle: see patch set 2 [00:38:32] @_@ [00:38:42] awjr, jdlrobson do you know why there's starttimestamp if there's also basetimestamp in http://www.mediawiki.org/wiki/API:Edit#Editing_pages? [00:38:48] jdlrobson: I didn't see, but I suspected it because you added $localBasePath as global in one the files, presumably a remnant of that [00:38:58] Krinkle: yeh.. [00:39:02] and probably how you discovered the inappropiate access to wgResourceModules [00:39:09] Krinkle: the docs say that that hook should *not* be used? [00:39:14] or possibly yurik too (my previous message) [00:39:14] jdlrobson: so I wonder, why did you move away from that? [00:39:17] https://www.mediawiki.org/wiki/Manual:Hooks/ResourceLoaderRegisterModules < Krinkle [00:39:20] awjr: really? [00:39:22] hm.. [00:39:24] Warning: Usage of this hook is discouraged. Use $wgResourceModules. See also ResourceLoader/Migration guide (developers). [00:39:24] Krinkle: because i told him too, based on the docs :p [00:39:34] s/told/asked [00:39:42] jdlrobson: Well, there's a hybrid possility [00:40:12] jdlrobson: Register an onSetup hook (wgExtensionFunctions) and plug in the array from there. That's still in time before wgResourceModules is interpreterd. [00:40:21] Krinkle: this also explains why includes/specials/UnlistedSpecialMobilePage.php was changed :) <- with the new way the old way was broken :) [00:41:00] jdlrobson: that old way would also be broken for detecting existence of core modules, or from other extensions loaded after MF [00:41:01] * jdlrobson confused now [00:41:30] lol so Krinkle are you saying that that hook is safe to use and we should disregard the docs' discouragement? [00:41:31] Krinkle: true but using the old way wgResourceModules was breaking mobile frontend modules [00:41:37] awjr: no [00:41:43] awjr: I'm not encouraging use of that hook [00:41:46] k [00:41:53] awjr: I was recommending using the global, but from onSetup instead of global scope [00:41:57] oh i see [00:42:02] why do that though? [00:42:15] what's the advantage? [00:42:18] well, that's the only way you can if you won't want to do it from the main file [00:42:27] there's no advantage, but that's the whole point of this commit. [00:42:33] * jdlrobson needs to go very soon... [00:42:36] otherwise why do it at all. [00:42:48] nono, the point of the commit is to just clean up MobileFrontend.php so it's not a bagillion lines long [00:43:01] awjr: You should see wmf-config/CommonSettings.php :P [00:43:18] Krinkle: lol i know, i curse every time i have to make a config change :p [00:43:30] we settled on just moving the $wgResourceModules definitions into a separate file and including it in MobileFrontend.php [00:43:40] lightweight, simple, clean [00:43:51] * jdlrobson still very confused [00:43:55] I think it is fine to be in the main file. Moving it out if imho non-standard. I mean, what if you'd register a 100 hooks, move those out too? [00:43:55] do i need to change the patchset? [00:43:56] ? [00:44:14] Krinkle: resources/Resources.php is out of the main file... [00:44:27] jdlrobson: you mean in core? [00:44:31] Krinkle: yup [00:44:37] jdlrobson: core isn't an extension [00:44:54] I'm merely pointing out that it's a convention to have 4 files in the main php file: info, hooks, modules and config. [00:44:54] well most extensions are not as big as MobileFrontend I'd argue.. [00:44:56] this is a special case [00:45:07] 4 sections* [00:45:23] and our big MobileFrontend.php is becoming a bitch to manage [00:45:35] onSetup runs right after extensions are loaded and a common way to extend configuration [00:45:56] yeah but we don't need to extend configuration, i dont see the value in executing another function [00:46:16] awjr: wgResourceModules is configuration [00:46:24] yes i know [00:46:34] and it already exists, we just want to move it to tidy things up :) [00:47:02] we don't need to do more than that and i think it would be wasteful to introduce more function calls for something that really doesn't need it [00:47:47] If you're both ok with it I don't care. I just think that using require_once and a secondary global scope file is slightly confusing since it isn't obvious that that second file is run in the global scope and you wouldn't see it anywhere else. For little extra complexity you can use a pattern that developers are familiar with: use onSetup hook and include the array from that file there. [00:48:51] function call overhead is marginal in php, especially if you're going to include a separate file. [00:48:56] i think you would be hard pressed to find a developer familiar with a setup hook that wasn't familiar with require_once... [00:49:11] awjr: That's not what I said [00:49:41] I'm saying it is a (to my knowledge) inexistent pattern to set configuration from a secondary file that is included and run in the global scope from the main php file [00:50:13] anyway, I've made the suggestion. I'm fine either way. [00:50:40] awjr: i leave it to you.. i'm just confused :) [00:51:34] jdlrobson: I'll say hello, hopefully less confusing [00:51:50] I'm projected in the meeting room [00:52:18] hehehe ok, thanks Krinkle, your point is taken under advisement :) [00:54:28] awjr: so just went to speak to Krinkle on the hangout - he says both ways are interesting and isn't really against either [00:55:10] i personally like patch set 2 as it just returns an array rather than doing an array merge and is consistent with core but that's just my preference [00:55:14] either being global scope vs. setup hook. awjr's conclusion about rl hook (as opposed to setup ook) is correct and that is indeed discouraged. [00:55:37] (ignore my last line then ;-)) [00:55:55] as stated i just want cleaner code so happy with how you want to go about it [00:55:57] yeah, i totally understand what he's saying and generally feel the same way (not really caring too much), but my gut says keeping all the resource definitions in one place is tidier and more straightforward/lightweight than messing with setup functions [00:55:58] jdlrobson: you can return an array and do the merge only one in the set up hook [00:56:02] i need to run though and see an injured rob moen [00:56:06] That'll have you the best of both. [00:56:17] if we use a setup function, we'd have to move the boilerplate definitions back to MobileFrontend.php so they're vailable in the global scope [00:56:24] awjr: that's true [00:56:28] awjr: the set up hook will put them in 1 place and in a separate file too [00:56:42] perhaps I didn't explain correctly what I meant (I wasn't being very elaborate) [00:56:52] onSetup: wgResourceModules.merge( include Resources.php ) [00:56:54] Krinkle: for the $wgResourceModule definitions yes, but we do some other tricks in there [00:56:56] basically that [00:57:04] i'll let you two flesh out the details.. i gotta run :) ps. Krinkle when you get a chance -> https://gerrit.wikimedia.org/r/#/c/63584/ [00:57:07] yeah, i totally get what you're saying:) [00:57:13] * jdlrobson waves goodbye [00:57:50] awjr: you're probably confused a bit since you missed a short bit of the conversation in the google hangout [00:57:52] but yeah, we have some other RL-related things (that are not $wgResourceModule items) that we need to keep in the global scope [00:57:57] awjr: so basically we don't need to change anything [00:58:28] we all want it in a separate file, and jon prefers returning an array instead of setting wgResourceModules directly in that separate file [00:58:44] oh i missed the returning an array preference [00:58:49] that leaves only the option to merge it into the wgResourceModules array from the Setup hook [00:59:03] yeah, and moving the boilerplate global vars back into MobileFrontend.php [00:59:04] so basically instead of: [00:59:05] MF.php [00:59:11] require( Resource.php ) [00:59:14] Resources.php [00:59:30] merge( wgResourceModules, array( ... ) ) [00:59:32] instead of that [00:59:34] this: [00:59:37] MF.php [00:59:41] hook[onSetup] [00:59:43] hooks.php [00:59:59] onSetup: merge( wgResourceModules, include Resources.php ) [01:00:08] and resources.php will return the array [01:00:21] hehehe Krinkle, yes, i get it! [01:00:35] my hesitation is not for lack of understanding [01:03:19] New review: Krinkle; "So scratch my last suggestion. The register modules hook is discouraged. However I agree with Jon th..." [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/63997 [01:04:20] awjr: sorry, after all this back and forth, I figured I'd go verbose to ensure you understood which one I meant [01:04:27] great [01:05:06] hehehe no worries Krinkle, i appreciate it :) [01:10:45] New patchset: awjrichards; "Move ResourceLoader modules to their own file" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/63997 [01:15:44] New review: awjrichards; "Clearly there 999 ways to skin this cat. I don't see the advantage to keeping the definitions of $wg..." [mediawiki/extensions/MobileFrontend] (master); V: 2 C: 1; - https://gerrit.wikimedia.org/r/63997 [01:27:06] New patchset: Shirayuki; "Give grep a chance to find the usages" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/63590 [05:39:37] New patchset: Yurik; "Refactored two confirmation funds into one" [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64019 [06:15:39] New patchset: Yurik; "TEMPORARY: Log lots of info to catch a bug" [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64020 [06:28:59] New patchset: Yurik; "(Bug 48528) TEMPORARY: Log lots of info to catch a bug" [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64020 [06:31:42] Change merged: jenkins-bot; [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64020 [07:00:49] New patchset: MaxSem; "Profiling" [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64025 [08:01:24] New patchset: Yurik; "Revert "(Bug 48528) TEMPORARY: Log lots of info to catch a bug"" [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64030 [08:01:42] Change merged: Yurik; [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64030 [11:14:03] New review: MaxSem; "Weee!" [mediawiki/extensions/MobileFrontend] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/63590 [11:14:24] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/63590 [11:21:42] New review: MaxSem; "(1 comment)" [mediawiki/extensions/MobileFrontend] (master) C: -1; - https://gerrit.wikimedia.org/r/63907 [14:08:52] why are all contents stripped on https://zh.m.wikipedia.org/wiki/Wikipedia:2012%E5%B9%B4%E9%A6%96%E9%A0%81%E8%A8%AD%E8%A8%88%E5%BB%BA%E8%AD%B0/%E5%9F%B7%E8%A1%8C%E6%94%B9%E7%89%88 [14:09:07] compare https://zh.wikipedia.org/wiki/Wikipedia:2012%E5%B9%B4%E9%A6%96%E9%A0%81%E8%A8%AD%E8%A8%88%E5%BB%BA%E8%AD%B0/%E5%9F%B7%E8%A1%8C%E6%94%B9%E7%89%88 - this is our new main page design [14:10:37] Which exact content do you refer to? All sections like 特色条目 or 你知道吗 are listed and explandable for me [14:24:14] andre__: I don't see them expandable ... anything missing? [14:25:22] Don't know. Browser information would be handy now :P [14:25:35] Clicking on them and nothing happens? [14:28:42] wassup? [14:31:57] andre__: nothing happens [14:32:12] MaxSem: I see all contents stripped on https://zh.m.wikipedia.org/wiki/Wikipedia:2012%E5%B9%B4%E9%A6%96%E9%A0%81%E8%A8%AD%E8%A8%88%E5%BB%BA%E8%AD%B0/%E5%9F%B7%E8%A1%8C%E6%94%B9%E7%89%88 [14:32:14] only section headers are left [14:32:34] liangent: what browser? [14:32:36] I! want! browser! info! [14:33:01] it's main page [14:33:16] it is handled differently from anything else [14:33:44] MaxSem: it's not the main page defined in MediaWiki:Mainpage currently [14:33:50] MaxSem: that's not the main page [14:33:53] but it works fine for us [14:33:54] eh [14:34:00] brion: andre__: firefox / desktop [14:34:02] we're trying to get liangent to say what browser the problem occurs in :) [14:34:23] liangent, works for me for Firefox 18 on Linux [14:34:43] liangent: i have no problems in firefox 20 or Aurora build on mac os x [14:34:45] version info would be welcome, and OS. [14:34:56] the sections are collapsed, but they expand when clicked [14:35:06] do they not expand when you click them liangent ? [14:35:38] lololo [14:35:41] does it happen only with this page or with other pages as well? [14:35:56] liangent, are you running in beta mode or something? [14:36:43] Any error output in "Tools > Web Developer > Error Console"? [14:36:53] MaxSem: dragon mode [14:36:59] lolololo [14:37:07] brion, your bug ^^^ :P [14:38:01] oho [14:38:08] happens in beta too [14:38:09] liangent: i can reproduce it in dragons mode :) [14:38:12] but not normal mode [14:38:54] basically, we remove section content in beta and then add it with JS [14:38:58] but! [14:39:08] for reference, always lead with "i'm in beta mode" or "i'm in dragon mode" :D [14:39:09] some browsers don't have JS;) [14:40:00] * MaxSem grumbles like an old fart that he always grumbled that it's a bad idea [14:40:23] well, i don't see any JS errors in console [14:43:18] ok seems to be a namespace thing [14:43:23] https://zh.m.wikipedia.org/wiki/Bug_test_page_1 <- sections work [14:43:28] https://zh.m.wikipedia.org/wiki/Wikipedia:Bug_test_page_1 <- sections don't work [14:43:58] * MaxSem facepalms [14:45:31] //$formatter->enableRemovableSections( $context->isBetaGroupMember() && !$isFilePage ); [14:45:41] ^^ the way to go [14:45:42] :P [14:45:43] https://bugzilla.wikimedia.org/show_bug.cgi?id=48540 [15:14:40] brion: it would be better to have those test pages placed on a testwiki as examples [15:14:53] or our patrollers may tag them for deletion soon later [15:14:58] liangent: feel free to move em [15:14:59] especially the one in main namespace [15:22:22] andre__: we should really try to have MF bug reporters say the mode they're using first [15:23:15] hmm. [17:03:17] hey mhurd [17:03:26] brion: he brion! [17:03:28] i've got laundry problems so i'm at the home office again today [17:03:35] New patchset: Jdlrobson; "Make special page headers work on desktop / skin cleanup" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/64088 [17:03:35] New patchset: Jdlrobson; "Skin: Enable history link on desktop" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/64089 [17:03:36] New patchset: Jdlrobson; "Skin: Remove dead code" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/64090 [17:03:39] brion: sounds good! [17:03:40] watching google io sessions while i work :) [17:03:48] hehe nice [17:04:13] brion: oh any chance to kick the tires on the >500 patch? [17:04:14] i should throw on wwdc sessions on another screen and let them fight it out [17:04:22] brion: hahahah! [17:04:37] mhurd, gimme a sec, testing something on android real quick [17:04:57] brion: no rush! [17:05:49] i'm hoping this download interface actually works on 2.3... wish me luck [17:06:34] brion: *fingers crossed* [17:12:28] brion: so i was able to parse the "parsetree" xml to get descriptions whether one or multiple language version are present. used NSXMLParser. the obj is passed the xml, and it invokes a callback block with a dictionary having language keys and description values. seems to work well. does this sound close? [17:13:33] mhurd, sounds reasonable yeah [17:14:08] brion: only weird thing is wiki markup in returned descriptions - recommendations for handling them? [17:15:22] heh [17:15:33] mhurd, just pull the raw text for now, we'll figure that out later :) [17:15:51] brion: sounds good [17:16:26] New patchset: Yurik; "Revert "Revert "(Bug 48528) TEMPORARY: Log lots of info to catch a bug""" [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64092 [17:16:57] Change merged: jenkins-bot; [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64092 [17:17:41] brion: should i button it up w/ read-only categories and descriptions for now? [17:19:23] brion: then i could jump right back on making them editable, but we'd have a clean intermediate in case it gets tricky [17:21:19] mhurd, yeah start there and i'll take a look over the impl before you dive into the rest [17:21:37] brion: will do! :) [17:22:01] for some reason android studio has all my new source open but it's installing a version to my device without the new menu item. what... the.... fuck... [17:24:47] huh… is that the new ide announced yesterday? [17:25:13] yeah [17:25:22] i may go back to stock IntelliJ if i can't fix it ;) [17:29:22] brion: i'm really interested in playing w/ studio… hope it works! [17:31:22] ok got the project fixed [17:31:37] now it's dying on android 2.3 because "Can only download HTTP URIs", and I gave it HTTPS. *headdesk* [17:31:43] well i can work around that later :) [17:31:50] brion: lol [17:32:05] ok lemme shuffle computers and free up the mac to review the ios stuff (it's streaming videos right now :) [17:37:06] * MaxSem throws some shit into the fan in mobile-l:P [17:43:26] brion, do you know why there's starttimestamp if there's also basetimestamp in http://www.mediawiki.org/wiki/API:Edit#Editing_pages? [17:43:51] brion_, ^ [17:44:00] jgonera: not really sure [17:44:03] it's all so fuzzy :) [17:44:16] do you know someone who can know? ;) [17:44:24] if i don't know, nobody knows [17:44:26] haha [17:44:50] I guess I'll have to dive into the source of the API [17:44:56] "Timestamp of the base revision" vs. "Timestamp when you obtained the edit token" [17:45:02] it predates the api [17:45:14] jgonera, need help? [17:45:21] it's from the web form interface [17:45:48] yeah, but why would the API care about the "Timestamp when you obtained the edit token" [17:46:06] it doesn't seem to prevent any conflicts when editing, doesn't seem to be relevant [17:46:11] jgonera: it probably doesn't care [17:47:22] [Commons-iOS] brion pushed 2 new commits to master: http://git.io/OOMZig [17:47:22] Commons-iOS/master fa805a2 Monte Hurd: Over 500 uploads... [17:47:22] Commons-iOS/master 9d22370 Brion Vibber: Merge pull request #68 from montehurd/over500Uploads... [17:47:35] brion: yay! [17:49:33] jgonera, so starttime is used only for detecting whether you started editing while the page was there if it was deleted by the time you submit your changes [17:50:12] does that mean that I should obtain the token _before_ showing the edit form to the user? [17:50:52] (instead of obtaining it just before submitting the changes) [17:51:44] jgonera: start time is meant to be the time you started presenting the edit form [17:51:56] the edit form, since version (something), includes an edit token in it [17:52:05] so it happens that you show the form and get the token at the same time [17:52:21] starttime/basetime/edittime all predates edit tokens, though [17:53:28] jgonera: ok start time is used for EditPage::wasDeletedSinceLastEdit() [17:53:31] and… nothing else i think [17:53:35] uh, but logically speaking wouldn't it just make sense to attach the timestamp of a revision I'm changing and then just check on the server if this is the latest revision has this exact timestamp? why do we need all those timestamps of showing a form or starting the editing? [17:53:57] for edit conflict detection, nothing else [17:54:11] you can i'm sure just use the revision timestamp [17:54:26] don't expect logic in this shit [17:54:37] we wrote it in 2002-2003 and didn't know what we were doing [17:54:59] but... let's say that Alice and Bob start editing revision with timestamp X, Alice submits first, then when Bob submits we already can see that his changes are conflicting... [17:55:02] ok, I see ;) [17:55:08] I'll experiment with this a bit [17:55:11] :) [17:55:22] and see what gives desired results [18:01:01] adam is still missing. something is wrong with his IRC :( [18:01:10] jgonera, as experience shows, just use both:) [18:01:50] I'll try skipping starttimestamp and check what happens, if it's skipped it becomes wfTimestampNow(); [18:03:32] you already know what happens: edge case with page deletion while you were editing it;) [18:04:59] ok, right, so it just recreates the article [18:09:16] yurik, you there? [18:11:22] great, the token API doesn't return any timestamp which means I'd have to generate it cient-side in JS, which means it won't be reliable anyway... [18:13:23] heh [18:13:38] jgonera, just use the revision timestamp, i think it'll be fine :) [18:13:58] can't we do NTP from JS these days?:) [18:14:45] you could do an XHR and get the Date header ;) [18:14:46] dfoy, ping [18:14:58] MaxSem, sup [18:14:59] yurik: hello [18:15:25] dfoy, so i figured out the bug (thanks PHP magic!) [18:15:35] but that doesn't solve how it got there [18:15:38] yurik: Great! what was it? [18:15:59] twice the same one? hm.. actually $deleteTime > $this->starttime doesn't make much sense anyway, I mean, why don't we just check in the DB if the page is deleted or not on edit submission without any timestamps? [18:17:15] well, the bug itself - there was a funky "isset($config['name']) " that i removed because it didn't make any sense - we always have "name" defined in the confg. Turns out that also prevented us from seeing the case when $config was null (no X-CS), while also having URL parameter renderZeroRatedBanner=true [18:17:24] dfoy, ^ [18:17:46] thanks to this bug, we now know that we have more substantial issues ;) [18:18:18] i just re-enabled logging of this bug, will collect more data for a while, see who is causing this probelm [18:18:32] oh well, I'll just use the same timestamp twice, you're right [18:19:48] yurik: ok so could still be having an incomplete IP range, or other problem? [18:21:33] brion, MaxSem, last question. is there any way of saving a few sections (but not the whole page) using a single API request? generators? [18:22:09] generators are a query concept [18:22:20] not applicable to any other actions:) [18:22:54] you must either save one section or whole page [18:22:54] ok, so I just need to send a request per every section [18:22:56] nooooooooooo [18:23:20] well, how do I save it if someone edits 2 sections out of 20 then? [18:23:31] save whole page [18:23:36] after all, on desktop it's the same [18:23:46] how? I can't parse wikitext in JS [18:23:47] that's actually less load on server [18:24:08] but we're writing an editor for editing single sections... [18:24:08] jgonera, eek! pretty sure you can only do multiple sections by saving the whole pagge, yeah [18:24:27] could just save two edits... [18:24:27] to let em edit single sections [18:24:46] brion, torches and pitchforks! [18:25:33] imagine someone making changes to 3 sections of a large page [18:25:41] 3 purges, 3 parses [18:25:41] ok, let me explain better: the editor opens a single section for editing (it's mobile, little space), _but_ there are prev/next buttons to load different sections into the editor. edits to sections are persisted in JS and when someone hits Save we want to save the sections they edited [18:25:53] hm... [18:26:17] so I should just fetch the whole wikitext of a page, and split it into sections using a regex in JS? [18:26:22] MaxSem: heads up i'm messing around with the MobileFormatter and am going to need your help soon ;-) [18:27:11] jdlrobson, Ik zal er zijn [18:27:17] MaxSem, brion ^ [18:27:25] MaxSem: it will also fix https://bugzilla.wikimedia.org/show_bug.cgi?id=41569 [18:27:38] jgonera, you can't reliably split to sections in JS [18:27:49] so what do I do?! [18:28:23] can we assume that people won't edit like 20 sections on mobile and just live with those 2-3 requests? [18:28:32] mmm, ditch that concept [18:28:49] that's not an option I'm afraid [18:29:00] anyway, we do the same on desktop, don't we? [18:29:05] no [18:29:12] anyone can click an edit link next to a section [18:29:13] either 1 section or whole page [18:29:15] and do it several times [18:29:21] that's what I'm saying [18:29:25] New patchset: Yurik; "(Bug 48528) Fix bug with null Zero config" [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64100 [18:29:30] so they can do 1 section 20 times [18:29:52] if you doo to many too small edits, you will have [[banhammer|social problems]] [18:31:30] jgonera, I think we might need to tweak parser to split source to sections. by the way, are you aware of transcluded page editing via section links? [18:31:49] that is, some section edit links might lead to editing other pages;) [18:31:53] ok, so let's get back to "you can't reliably split to sections in JS" then. why can't I just look for second level headings ( ==sth== ) and use them to split the wikitext into chunks? [18:32:00] how are you going to support that?:) [18:32:15] can you give me an example of that? [18:32:18] Template:foo: [18:32:27] awjr, is adam around? sorry to bug you :) [18:32:30] == I'm a foo == [18:32:41] main page: [18:32:49] == Section 1 == [18:32:52] {{foo}} [18:32:59] == Section 2 == [18:33:11] MaxSem, generators have been extended to work with any action [18:33:37] dfoy, yes, still an incomplete query range, i will make logging more permanent to catch these things [18:33:53] you'll have 3 sections, but by clicking on edit for "I'm a foo", you go to title=Template:Foo&action=edit§ion=1 [18:34:41] MaxSem, now all you need is to adjust individual module to accept generator parameters (there are a few modules that already do that, like "purge" i think) [18:34:45] jgonera, if you go against the parser armed with just regexes, parser will eat you;) [18:34:48] ok, so what would the API return if I requested wikitext for section "I'm a foo"? [18:36:46] it would return the same thing as clicking edit next to this section on desktop, right? [18:38:15] New patchset: Yurik; "Revert "(Bug 48528) TEMPORARY: Log lots of info to catch a bug"" [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64101 [18:38:28] Change merged: Yurik; [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/64101 [18:39:20] jgonera, see the internal representation yourself: https://en.wikipedia.org/w/api.php?action=parse&format=jsonfm&page=Wikipedia%3ARequests%20for%20adminship&prop=sections [18:39:36] note fromtitle [18:39:37] MaxSem, I'll use more than one request (or a generator if yurik says it's possible) to save various sections and we can monitor how many sections people tend to edit. It's quite possible that 90% of people will stick to editing just a small thing in a single section on their phone and the remaining 10% won't go over 2-3 sections either [18:39:55] ok [18:40:01] it's a workflow we allow on desktop anyway, by clicking edit next to a section and e.g. opening each section in a separate tab [18:40:01] I warned ya!:) [18:40:19] yurik, need your advice on API. currently, GeoData works as a list module - thus you can return only one point per page. however, now there's a use case where we might need to return multiple coordinates from a page [18:40:35] so it looks like we need action=geosearch? [18:40:51] ok, nothing;s going to be worse than the wrath of the community after we spammed Commons with crappy photos ;) [18:45:19] MaxSem, you should probably do it as a property module, not list [18:45:32] because prop is for having multiple items per page [18:45:52] yeah, I thought about that - but it doesn't fit the use case either [18:46:03] MaxSem, could you give an example? [18:46:11] so we need to find coordinates around a point [18:46:44] solr returns a bunch of points sorted by distance along with their pag_id's [18:47:44] MaxSem, not sure about the problem yet :) [18:47:45] some of points may belong to the same page [18:47:53] yurik, where can I read more about generators in actions other than query? [18:48:00] so prop of what are you going to request? [18:48:06] jgonera, take a look at purge action i think [18:48:49] MaxSem, ok, yes, list is your best bet. You will simply need a parameter - unique vs non-unique results [18:49:06] i think we already had that in a number of other cases [18:49:12] yurik, and return non-unique pages? [18:49:23] MaxSem, yep [18:49:35] doesn't it use a dictionary of page_id => page_info in some places? [18:49:45] each list result can be anything you want [18:49:54] i think you are thinking of props :) [18:50:00] they are a dict [18:50:44]