Patch is up. In the future either InlineDifferenceEngine::getSlotHeader or InlineDiffFormatter should be improved so that slot headers look sanely, but that's not an immediate blocker, it's blocked on the main diff patch and slot headers need to be changed anyway when SlotRoleHandler lands, so that can wait.
Mon, Aug 13
Vagrant throws this every time it tries to do something with MediaWiki (that is, run some maintenance script) so the full log is not super useful.
This is not really an MCR problem (trying to show mobile diffs of Wikidata edits has the same issue) but will occur in many more places due to MCR. It's not a phase 1 blocker (we can preserve the current behavior with a simple patch as long as only main slots exist). It might be a phase 2 blocker if we want to show diffs of file page edits on mobile (which we do currently) but can be worked around by writing a custom InlineEntityContentDiffView engine for the Wikibase + mobile combination. Dealing with it in general is more complex. We might want to handle inline / non-inline at the DifferenceEngine::getEngine() level.
Went through the high and medium priority steps of the test plan.
- MobileFrontend diffs break (use TextSlotDiffRenderer instead of InlineDifferenceEngine). MobileFrontend hand-creates the InlineDiffRenderer so it does not get used for the main slot; I don't think the diff patch can be improved to prevent that from happening (DifferenceEngine::getSlotDiffRenderers() could check its own class and replace TextSlotDiffRenderers with itself when it's not the base class, but that's scary and would probably break way more things). It needs to be fixed in MobileFrontend (and other extensions using a similar pattern).
- Diffing with non-existent old revisions is somewhat broken due to a previous patch (T201218: Viewing page's first revision via diff gives error).
- There are a bunch of callers which pass in a content object so non-main slots get ignored (edit conflict, for example). I think that's outside scope (better to keep patches small when possible) but should be tracked and eventually converted.
- I get an exception when I try to make a Wikibase slot in a non-Wikibase namespace. I think that's expected.
- Couldn't figure out what "diff should reflect user language" for Wikibase means.
- Could not test VisualEditor (npm has random failures, probably because it hogs up all the memory and gets killed, and I haven't found a good way to detect or repair broken installs). Will have to test it on Beta.
This is basically T197136: Tie certain user rights to elevated security plus T197153: Make some providers optional for reauthentication, with extra configuration options for OATHAuth.
Works fine these days, our HHVM version has been upgraded presumably.
No, haven't seen since. The patch was https://gerrit.wikimedia.org/r/c/mediawiki/core/+/451663 FWIW.
Sat, Aug 11
Fri, Aug 10
I don't see that error, can you provide more specific reproduction steps?
Or just drop the idea of a transitional format and keep the main slot one level higher forever (or at least until the next change that really needs to be a BC break). Old clients will not break, MCR-aware clients will maybe need very slightly less elegant parsing code, which does not seem like a bad trade-off.
Someone just added it (the file is dated to two hours ago). Thanks!
Thu, Aug 9
@daniel any thoughts? Is this generic enough that maybe it should be discussed as an IRC? Or is it still in just-do-it-land?
These are not RL modules, just plain style tags with the CSS inlined.
If you do not load the page HTML, where does VE get the HTML from that gets displayed in the editable area?
Wed, Aug 8
Ideally this would run on gerrit, not developers' machines. That does not seem to be case though.
Tue, Aug 7
With the largest wikis already opted in, it's not too big a deal, it can be done in a regular SWAT window IMO. I'll add it now.
(BTW I'm taking "everywhere" as all wikis including private etc. - there doesn't seem to be any reason not to do it.)
No, it was a one-time thing, on last Thursday. Maybe some kind of deploy artifact with different versions of the code running in different contexts? Although that specific part of the code hasn't been touched for a year. Anyway, weird one-off, not worth the effort of investigating more unless it reoccurs.
@SpeedyGonsales right-hidden is/was a Commons hack to prevent a gadget from being used by anyone. Apparently whoever ported the gadget didn't bother to port the message as well. IIRC these days ResourceLoader has a hidden option so the hack is not needed anymore.
Anyway, this has nothing to do with editing, permissions shown on Special:Gadgets are for enabling gadgets.
At a glance there's just a page.delete / page.undelete event (or mediawiki.revision-visibility-change if it's revision deletion).
Running the job manually from mwscript works fine. Does this failure happen on every job run or just some fraction of the attempts?
T200346: wmf.14 failing to execute ThumbnailRender jobs "error: ThumbnailRenderJob::run: HTTP request failure" probably masked this error until recently.
Change tags are added after the revision has been created and saved (and they can be added or removed much later, although that probably does not really happen in practice). So that would be some major refactoring, if at all desirable.
There is no way to do that, one of the goals is to have the same configuration of JS editing permissions on all wikis to make central monitoring easier. Feel free to add all your admins to the interface-admin group though if you think they all need access.
The styles are part of the page content (https://ru.wikipedia.org/api/rest_v1/page/html/Северное_море). Surely VE must load that?
Mon, Aug 6
The logstash errors (the error field, not the message) are all along the lines of ThumbnailRenderJob::run: incorrect HTTP status 404 when hitting //ms-fe.svc.eqiad.wmnet/wikipedia/commons/thumb/1/1c/Foo.tif/-Foo.tif.png
I wonder if there are git hooks we could setup on the deployment servers to address this without having to put any logic into scap?
Weird. ImageHandler::makeParamString would throw an exception if the width wouldn't be specified, and that's not happening.
@IKhitron copied the permissions, please go ahead and empty the interface-editor group.
I think this writeup misses the main problem: in MediaWiki, live revisions are associated with a page ID but deleted revisions are associated with a title. That allows for all kind of weird things through the creative use of delete/undelete and page move - merging pages, splitting a page into multiple parts, transferring parts of a page history into another page etc. This violates the assumption behind having a stable page identifier: that the page is an "atomic" building block that can be tracked over time as a single entity. Fixing that (if it should be fixed) is more of an UX / user expectations issue than a technical one.
I don't think this is viable as an edit warning if it cannot differentiate between problems in the wikitext of the current page and problems in templates (which is probably not possible with the PHP parser). Most articles are just text and the problems will come from the infobox, navbox etc. templates they include, so there will be lots of non-actionable warnings confusing editors. The Linter approach seems more feasible.
Have we tried merge=union? That seems vastly simpler.
Sun, Aug 5
Reading rMW9dafa73b2f28: Test only against protection for deleting more closely, I don't think it requires edit rights for deletion. It only requires that the user is not prevented from editing by a page protection.
I think this can be closed in favor of the more specific T200176: Deletion of user js and css requires deletion and edituser* rights. Or am I misunderstanding what you are asking for?
T200176: Deletion of user js and css requires deletion and edituser* rights has more discussion on this.
There isn't anything particularly secret about this and in any case it's being discussed in a number of public places so let's open it up.
Global renaming bypasses any local restrictions
Needs to be tested. @Qgil do we have a test site? Or can I just test on the live site? (Pretty simple patch, probably not worth the effort of setting up a local test environment.)
Putting the template with the styles after the table might result in a FOUC (although not a huge deal as long as it's just colors and no layout-related rules).
Re-login is not any different from login. It will clear the session (in general if the session times out there is no way to recover it), so you'll need new CSRF tokens.
That's what project/title is for: action=query&meta=readinglists&rlproject=en.wikipedia.org&rltitle=Spain
That's not the alt text, it's the caption (as understood by MediaWiki - ie. the first unnamed parameter in the image markup). What you are asking for is to use the caption parameter of the infobox instead of the MediaWiki caption. That should be fixed in the infobox.
$wgHashedUploadDirectory is just convenience for setting $wgLocalFileRepo (and the same goes for $wgHashedSharedUploadDirectory and $wgForeignFileRepos) so (as proposed) this wouldn't change the fact that a file repo can have an arbitrary level of hash directories (including zero).
I think this is way too harsh for the current MediaWiki hook system (which makes it pretty much impossible to predict when certain callbacks are going to run). Getting an anonymous user is not a big deal most of the time; getting an exception is. (Although arguably an anonymous user exposing the IP is problematic and maybe should be replaced with some kinda system user created for this purpose.)
Fri, Aug 3
Asked about it upstream: https://meta.discourse.org/t/change-communication-with-matrix-from-notice-to-message/93874
Not sure what caused the bot to un-identify. Halted it for now.
Can you empty the old group? It should probably be removed from all users before the definition is deleted.
Also, do we need to run initSiteStats.php on all wikis? (Is that even feasible on large ones?)
the styles.css page isn't transcluded into other pages (that is, it's not actually a template)