[13:39:00] anomie, tgr: I'd like to finalize the MCR-SlotRoleHandler and MCR-PageUpdater specs today. Please let me know if any unresolved major issues remain. [13:39:17] yeah, working on that [13:39:18] I cut the discussion on the talk page a bit short to avoid diving into too many rabbit holes. [13:39:29] ah, cool, thank you. [13:39:57] i chanegd the draft quite a bit in response to your comments last week. [13:40:46] in particular, RenderedRevision now uses SlotRoleHandler, instead of the other way around. [13:41:53] This means no cached access to vanilla per-slot ParserOutput. I hope this won't become an issue… [13:42:03] * DanielK_WMDE goes to find food [15:43:40] so I'm using https://www.mediawiki.org/wiki/API:Search but I need to get the deleted pages... how would I do that? (obviously it will need proper authentication, but the sandbox doesn't return the deleted page from this endpoint.. unless the sandbox doesn't use auth?) [15:45:57] davidwbarratt: deleted pages are not indexed by the search engine afaik [15:46:39] understandable. :) is there another endpoint I could use? [15:46:59] dpends on what you are trying to do [15:47:40] well I'm trying to run a search (on titles) to find a deleted page [15:48:38] davidwbarratt: what exactly do you mean by "search"? exact match? prefix? substring? folded? [15:49:03] uhh, probably prefix, it's an autocomplete form field [15:49:50] I'm not sure we have an API for that. I guess the best we have is https://www.mediawiki.org/wiki/API:Alldeletedrevisions [15:50:17] ah, it has adrprefix=foo [15:50:20] that should do it [15:50:35] the namespace has to be supplied separately though [15:51:12] this is going to be case sensitive I suppose [15:51:53] https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&list=alldeletedrevisions&adrprop=user%7Ccomment%7Ccontent&adrprefix=Foo [15:57:08] ah! interesting, well that's helpful [15:57:29] don't really need the revisions, but if that's the best we have then that will do [15:59:45] davidwbarratt: mediawiki internally has no concept of deleted pages. only of deleted revisions (with a title attached). [16:00:14] davidwbarratt: this is an artifact of how the schema has evolved. it's generally not considered a good thing. but that's what we have [16:00:33] ooo, so that's interesting, so when you delete a page, are you just deleting all of the revisions? [16:00:42] yes [16:01:02] by copying them to a different db table, and deleting them from the original table [16:01:18] again - this is generally not considered a good thing, but that's how it works :) [16:01:43] so that means... if it's undeleted, it gets a new pageid? [16:01:50] just makring the page entry as deleted would be so much simpler, no?... [16:02:10] it used to be the case that they get a nwe page id. and new revision ids. [16:02:22] these days, both are stoed in the archive table, and restored [16:02:29] DanielK_WMDE aha, yeah I think it would be much easier. :P [16:02:56] there is a bit of confusion there since pages can be renamed, so the same title can have multiple different ids at different times (and vice versa). that makes undeletion semantics... fun... [16:03:46] not to speak of selective undeletion of some but not all revisions. and the fact that people use delete/undelete as a way to merge histories of two pages. [16:04:37] (manic cackling in the background) [16:04:48] so.... perhaps there should be an API that returns what is in the archive table? [16:06:22] that'S the API i just inked you to [16:06:48] yeah, you can delete the page, restore half the revisions, move the resulting page away without leaving a redirect, and restore the remaining revisions [16:06:52] alldeletedrevisions is essentially a select against the archive table [16:07:10] so there isn't really a guarantee of the page ID being the same, but these days at least we try [16:08:06] DanielK_WMDE well it doesn't appear to give you the page id... [16:08:29] DanielK_WMDE or at least what the page id used to be [16:08:32] or maybe I just don't have the right prop [16:09:13] davidwbarratt: you want the ids prop i think [16:09:20] should be in there [16:09:23] if not, should be easy to add [17:36:33] whoaaa, new gerrit interface can show all the diffs on one page. the future is here! [17:46:42] anomie: sorry for the mess on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/439289 :( [17:48:18] hashar: No problem. [17:52:50] MatmaRex: ooh, how? [17:52:57] "show diffs" [17:52:58] neat :D [17:53:32] yeah. there are also those little triangle things near each filename to toggle the inline diff individually [17:55:51] also it can hide all the comments that are not comments [17:56:45] it gets better with 2.16! [17:56:53] easier to open a diff on the same screen [17:57:00] it has lots of coolness: +0, mark as WIP, mark as ignored [17:58:33] paladox: are the avatars also blocked on 2.16? [17:58:37] nope [17:58:42] we can do them when ever [17:58:45] davidwbarratt: FYI, if you're using API:Search then the answer is usually "figure out how to do it via Special:Search, and do it the same way". For getting deleted titles, there's a task requesting that at https://phabricator.wikimedia.org/T192023. I don't know if anyone plans to work on it soon. There's currently no way to get the ar_page_id because no one has proposed a use for it beyond "I want all the data for no good reason", since the only [17:58:45] use for it is internally reusing the page_id (if possible) on undeletion. [17:58:55] i have a repo for this [17:59:19] https://gerrit.wikimedia.org/r/admin/projects/All-Avatars [17:59:22] tgr ^^ [18:00:02] Also, the ar_page_id thing has a task too: https://phabricator.wikimedia.org/T183398 [18:09:38] tgr we just need to hook this https://gerrit.wmfusercontent.org up to gerrit's apache. [18:15:18] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/439497 and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/306863 are the last two reasonable 1.31 blockers that need review :) [18:20:01] anomie ah, thanks! [18:22:30] fis there any... uhh... desire? to move towards a "soft delete" concept where the page stays in the page table but with a flag instead of being removed? or... alternatively, it would be nice if this was abstracted via the API anyways (i.e. if you query for a pageid and it's misisng then the details, i.e. the page name, etc. will come from the archive table) [18:22:30] *is [18:25:06] davidwbarratt: i think this desire has existed for close to ten years now :) [18:25:10] davidwbarratt: That would be something of an epic project. There's probably a task for it somewhere. For the most part trying to paper over that is probably outside the scope of the API. [18:30:30] DanielK_WMDE do you know of a task? [18:30:32] legoktm: https://github.com/Mediawiki-wysiwyg/WYSIWYG-CKeditor/blob/wysiwyg_mw130_462/WYSIWYG/extension.json#L47-L48 [18:30:49] >.< [18:30:57] tgr, anomie: quick confirmation before I wrap up for the day: are you both fine with a) SlotRoleReg::getRoleHandler only taking the role, and any logic depending on the content model would have to be inside the SlotRoleHandler and b) RenderedRevision does the in-place caching, and does it only for "for-combined-output" ParserOutput objects for each slot, not for per-slot "vanilla" ParserOutput. [18:31:57] DanielK_WMDE: (a) Sure. (b) Also sure. If we want "vanilla" caching we could do it directly via ParserCache. [18:32:16] (assuming appropriate modifications to ParserCache) [18:32:40] ok. then I think all major questions and disagreements are resolved. Please verify https://www.mediawiki.org/wiki/User:Daniel_Kinzler_(WMDE)/MCR-SlotRoleHandler [18:42:20] DanielK_WMDE: I still don't like (a). I don't think it's a big deal though. As for caching vanilla POs, it seems useful, but trivial to add later if needed, right? [18:45:07] tgr: yes, easy enough to add. [18:46:36] as to getSlotRoleHandler only taking the role: it dook me a long time to yield and arrive at this conclusion. the detail that did it was the following: if the concrete SlotRoleHandler instance can depend in arbitrary ways on the title, then what key do I use to cache the instances? How do I know when to re-use a cached instance? [18:47:18] SlotRoleHandlers couldn't be singletons, we'd have to re-create them all the time. [18:47:25] possible, but not so pretty [18:48:15] so I came back to what anomie proposed: just have one SlotROleHandler per role, and if we need it to behave different based on some aspect of the concrete content, figure that out inside the SlotROleHandler. [18:48:43] This also has the advantage of letting us proceed with a simple interface, and the option to add complexity later if needed. [18:55:06] DanielK_WMDE: indeed, SlotRoleHandler would be constructed with a Title and/or Content object in that case. I think that would be fine; the alternative is to pass that Title or content (or content model) to every function that might have a different behavior based on it [18:55:36] but it's not too bad either way, and not too hard to change in the future either [19:02:52] tgr: since getSlotOutput() needs a full RevisionRecord anyway, it also has the Title, so no problem there. [19:03:08] indeed [19:03:10] The only method that was affected by this is SlotROleHandler::getDefaultContentModel [19:03:18] that seems a small price to pay [19:03:56] getSlotHeading and such [19:04:13] I agree it's not too bad [19:04:30] I don't really think the slot heading should depend on the title. that would be confusing. [19:05:12] you mentioned changing content models elsewhere... while this should be possible in generaly, I'd like to be very restrictive about it. It should only be done for very specific use cases. it should not be a generic function of the ui [19:11:53] that's probably wise [19:16:27] :P [20:28:00] we could create a polygerrit plugin that display on mediawiki/core or any other repo that has a wmf branch the status for which group is on which version. [20:33:36] oh wow [20:33:48] they are making a awsome change table on the change screen! [20:34:49] stuff like [20:34:50] https://phabricator.wikimedia.org/F22040373 [20:35:15] and https://phabricator.wikimedia.org/F22040506 and https://phabricator.wikimedia.org/F22040625 [21:30:14] no_justification: are you in the office today? [21:32:19] Um I'm not in the office ever again.... [21:32:39] Till a party [21:32:40] Did you miss that email...? [21:36:41] pretty sure he replied to it :) [21:40:33] no_justification: wasn't sure if there was a last day thing [21:40:54] (e.g. June 11) [21:43:57] That email, like most of mine, contained many errors [21:44:03] Notably, dates [21:44:10] rofl [21:56:42] true ^