This is a change in behavior caused by rMWb5237cfc1b47: HTMLForm: Allow distinguishing between form views and submission attempts to fix T29676.
Actually, it seems that trying to add a column anywhere in that table causes this. Adding rows, or deleting rows/column, is fine.
Looks like this will just be part of the regular release schedule. For Commons specifically, the change should be deployed today around 19:00-21:00 UTC, or 4-6 hours from now (https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20170524T1900).
Thanks for the reminder, I'll do it.
Okay, so skipping over the offtopic discussion, the current status of this task is the same as a year ago when I wrote this comment:
Looks like https://www.mediawiki.org/wiki/Manual:Skinning_Part_2 got updated, thanks for doing it (and I made some minor tweaks too).
Thank you both for working on this!
@HiW Matthias wrote the fix (and I just merged it), but it's not deployed on Wikimedia sites yet. It will be deployed per the usual schedule: https://www.mediawiki.org/wiki/MediaWiki_1.30/Roadmap on 23-25 May. (Although maybe we should deploy it sooner in a SWAT window – @Jdforrester-WMF?)
I looked at this again during the 2017 hackathon and updated the patch. The feature is now implemented and seems to work fine, but I've ran into some CI troubles. But hopefully this will actually move forward soon!
No, looks like a bug. That example definitely worked last time I checked that patch. Looks like it was broken by the last patchset.
Mon, May 22
Sun, May 21
Possibly fixed by https://gerrit.wikimedia.org/r/#/c/354558/ ?
It was removed in rEMFRfc9576c02ccd: Hygiene: Kill no longer cached ResourceLoader modules, apparently.
Sat, May 20
Are we done fixing the large wikis too, or just checking them?
I suppose we need to run the updateCollation.php script on beta now to verify?
For reference, there has been an older patch for this task at https://gerrit.wikimedia.org/r/#/c/318690/ (unfinished).
This is fixed by the revert?
Perhaps the infobox has been changed not to trigger this problem. The underlying issue is still present:
I don't see this problem anymore.
I submitted a patch to change this (see T165854: Change OOUI EditPage inputs to keep the old 'id' attributes on the <input> elements). I hope you haven't updated too many gadgets that will need to be fixed again :( (The ones that used $( 'input#wpSummary, #wpSummary > input' ) etc. should work fine with the proposed HTML too, no further changes needed.)
For most basic bits, it will mostly keep working – we still use a normal HTML <input> and it can still be interacted with using the usual DOM methods. Things might start behaving funny if we infuse the widget, but the things editors care about (like submitting the form with the edit summary) will work just fine.
Fri, May 19
The hookEvent call and the warning is coming from the OnlineStatus extension you have installed.
It also prevents you from editing the images visually… please don't do that :) It helps for the specific case nl.wp had a problem with (T161408), but unless the content you wrap is already mostly made up of templates, it will result in worse interface in VE (and it's clutter in the page source).
I bisected and this appears to have been caused by rGOJU1dcc221214b1: MediaWiki theme: Fix IE 7 oversized buttons.
This was broken once a long time ago, but we fixed it. Someone must have unfixed it recently. This is not an issue e.g. in this super-old version: https://doc.wikimedia.org/oojs-ui/v0.12.8/demos/
That doesn't really make sense for me. The database not being there is a pretty exceptional case. It deserves to throw exceptions. If your code is doing Title->getRestrictionTypes() while the wiki doesn't even have the concept of a Title yet, it's a bug in your code.
I wanted to check it out again but your wiki (http://www.hypoverse.com/) seems to be down…
This is a specific case of T107745, it's possible we can solve this problem without doing the entire thing, maybe before 2020 ;) especially if it's okay to require minor wikitext changes to do so.
Wed, May 17
I don't see any warnings when viewing the site.
I'll save you the grep, here are the non-zero entries:
Hmm. I think this probably ends up using the language you have set in preferences on Commons, which is English for new users. Possibly all we need is to pass a 'uselang' parameter to the API queries on target wiki, matching the language of the user on the source wiki… I'm not sure if that will be enough, I haven't worked with this code for a while.
Tue, May 16
We have the code to emit Referrer-Policy, and it's enabled on production wikis ('origin-when-cross-origin' by default, 'no-referrer' on private wikis), but it doesn't seem to actually be in the output headers… Maybe it's filtered out by Varnish or something?
We emit X-Frame-Options: DENY on all "sensitive" pages (pretty much everything that displays a form, e.g. action=edit or special pages). We probably can't do that on all pages (neither DENY nor SAMEORIGIN), since various community tools rely on including pages from Wikimedia wikis in frames (for example, Wikidata Game: https://tools.wmflabs.org/wikidata-game/#mode=commonscat).
There are no regular deployments this week (due to several teams having offsite meetings, and pre-hackathon travels), so this will probably go live next week.
Mon, May 15
Hiding and showing the '.oo-ui-outlineControlsWidget' element (applying 'display: none' in the inspector and then removing it) fixes the issue for me. Does that also work for you on Macs?
I see a different but similar issue on Windows, I suppose it's because of differences in scrollbar handling.
Under what circumstances are you getting this? This error seems to indicate that your code is not allowed to access the database at the time, for whatever reason (e.g. for code running in the MediaWiki installer, where the database does not exist yet).
This sounds like a fairly harmless issue and it should be easy to fix, so I'm leaving it for some new developer to look at :)
This sounds like T141894. Perhaps the patch there just needs backporting.
Looks like it has been fixed in rSTIM9613a9d4bc09: Fix MWException about passing an array named data to Html::element by @Bawolff.
This would be indeed convenient. Hopefully it'll be a simple change.
Sun, May 14
- For the font – OOjs UI widgets will use whatever font the page uses. Browsers usually use a serif font as the default, while in MediaWiki we use a sans-serif font. To include sane defaults for this and other options, you can just add the OOjs UI demo stylesheet to your page: https://github.com/wikimedia/oojs-ui/blob/master/demos/styles/demo.css (this is probably easier than extracting them from MediaWiki and the effect should be the same)
- For the missing icon – you'll need to include the specific stylesheets, for example <link rel="stylesheet" href="dist/oojs-ui-mediawiki-icons-content.css">. Syntax like <link rel="stylesheet" src="oojs-ui-mediawiki-icons-*.css"> won't work. See the demo for the list of "icon packs": https://doc.wikimedia.org/oojs-ui/master/demos/#icons-mediawiki-ltr-desktop
Fri, May 12
Thu, May 11
This is broken since OOjs UI v0.19.0, released on 2017-01-31, and deployed with 1.29.0-wmf.11 on 2017-02-07/09. (But again, it's only broken when the upload dialog is launched from WikiEditor, not from VisualEditor.)
It's only totally broken when used from the wikitext editor, it works when used from the visual editor. Given that no one noticed a drop in the uploads when it broke, it seems most users use it from the visual editor.
This only affects the tool usage in WikiEditor, not in VisualEditor.
This change should fix the problem: https://fr.wikisource.org/w/index.php?title=MediaWiki:Common.js&diff=6723802&oldid=6425474
I applied this change to fix those important scripts on Commons (Cat-a-lot and Navigation Popups): https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=243659552&oldid=242815770
Heh, funny thing, I refreshed the page and now it's broken. Here's how the broken version looks like, for comparison:
Please clarify what the issue is. I see the collapsible boxes on https://fr.wikisource.org/wiki/Utilisateur:Rical#Dates_d.27inscriptions_en_cat.C3.A9gorie and they can be expanded and collapsed for me. Can you upload a screenshot of what you're seeing?
This seems to have been resolved on-wiki with https://en.wiktionary.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=42867887&oldid=42211374. I'm pretty sure the underlying issue is the same as T165031.
Note that it's already loaded through ResourceLoader (as part of the 'site'/'site.styles' modules), but ResourceLoader doesn't know how to "follow" the @import rules, so they are not followed and loaded in separate requests.
The page source includes the following call for me, which is normally used for style-only modules to indicate that their CSS is loaded and should not be loaded again. For some reason 'ext.gadget.Cat-a-lot' is among them, and so it is not being loaded. This obviously makes no sense, and I have no idea what could be causing this.
I don't think it's possible. Users could still technically disable this gadget. But you can advise them in its description that it's a really bad idea to do so.
@Andyrom75 Then I would recommend turning the entire MediaWiki:Common.css into a gadget that is enabled by default. This lets you use multiple CSS pages without annoying @import rules. We have the site styles on https://www.mediawiki.org/ set up that way, for example, as the "Site (styles)" gadget (https://www.mediawiki.org/wiki/Special:Gadgets). Compared to @import, this also lets the styles load faster, since they go through the ResourceLoader minification and they all load in a single request.