Open source enthusiast, mathematics buff.
Fri, Oct 22
Seems this is resolved somehow.
In order to see the warning, you have to preview.
I am seeing the warning without previewing. (The one for previewing is still there though, and styled differently)
|Warning Warning shown for Publish||Warning shown for Preview|
Wed, Oct 20
The override is in MinervaNeue (now).
Mon, Oct 11
Mon, Oct 4
Sun, Oct 3
Wed, Sep 29
...(with numerical keys that I guess correspond to the count for each matched pattern) if there are multiple matches.
...I guess returning an object in all cases would work, assuming that the numerical keys are important and represent how many times the edit hit each URL pattern.
The numeric keys are not count for matched patterns; the are array indexes. They're non-consecutive because duplicate elements have been removed and the array is not reindexed.
Sep 24 2021
The stub threshold feature has been removed entirely T284917. I guess that renders this task invalid
Sep 23 2021
Sep 22 2021
Sep 21 2021
Sep 19 2021
This is already being fixed at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/721770
Sep 17 2021
It's different. 'Go' takes you directly to the page (if it exists) else to Special:Search. 'Search' takes you to Special:Search (always)
You might not see it because your account probably doesn't have permission to upload files on the wiki.
This is not a server configuration issue, thus I'm closing this ticket. If there are any questions, please refer to https://meta.wikimedia.org/wiki/Tech - thanks!
This upload link cannot be changed on wiki. $wgUploadNavigationUrl may need to be modified.
Sep 13 2021
This is still a regression since it breaks expected (and correct) behavior. Colon escaping of these links in main namespace is almost always wrong.
Sep 4 2021
Aug 30 2021
@Jdlrobson have you descoped this? See the second patch
Aug 21 2021
I will work on it. It's low-priority MediaWiki-Core-Skin-Architecture work that's why
Aug 11 2021
There's no pre-filled GET processing (e.g. https://meta.wikimedia.org/wiki/Special:UrlShortener/https://fr.wikipedia.org/wiki/Variable_m%C3%A9tasyntaxique doesn't pre-fill the input)
There's. You have to use the url parameter: https://meta.wikimedia.org/wiki/Special:UrlShortener?url=https://fr.wikipedia.org/wiki/Variable_m%C3%A9tasyntaxique
Aug 8 2021
Intention of both T287616 and T223824 is to let existing users to continue using these skins with no change in behavior, so the API should support these skins since they are not really disabled. We can either go with T237856#5656455 or just add the skipped skins to the allowed values (which will avoid listing the internal skins; albeit they're already supported with ?useskin parameter anyway).
Aug 7 2021
It should probably also be made first in the list (given it's a more general option than the other individual skin options that may appear there).
Jul 31 2021
Jul 30 2021
Jul 26 2021
Jul 14 2021
Jul 3 2021
The description needs correction, see my comment at T285402#7195506
Note this is not quite right, the new core pref will not apply to MonoBook yet (MonoBook does not set Skin->options['responsive'] unconditionally).
Jul 1 2021
Jun 29 2021
Jun 28 2021
I suggest to initially honor both. Send a notice that all those with 'monobook-responsive' should switch to the general pref, then after sometime TBD remove the preference from MonoBook OR write a script to automatically migrate users. I am not sure how many (active) people are using that preference though, and the numbers can give hint which way might be better.
Jun 27 2021
Jun 25 2021
Jun 21 2021
The link is added by RevisionJumper gadget, which is hosted on dewiki.
Jun 18 2021
I believe your submission T220719#5104780 does not seem to agree with what you're saying now. Additionally, even in "function calls" it's not true that they're heavily spaced; foo () is disallowed albeit it's valid syntax in PHP.
What's the duration of the vote? How will people (beyond those subscribed here know a polling is going on?)
Jun 17 2021
Is this duplicate of T261087?
CSS convention does not apply to PHP
MediaWiki favors a heavily-spaced style for optimum readability.
Therefore, it seems like a no-brainer to use function () : type.
I don't think this deductive submission is valid. If it were, then ( bool ) $foo would have already been allowed on similar premise.
Jun 15 2021
It was fixed as part of d238db85b8d8
Jun 11 2021
This basically happens during fresh installation and is really not looking good.
Jun 9 2021
May 29 2021
For the subtitle links and the error message, the provided request parameter is used without strict validation because validation of the username (which will lead to normalizing such names) is not desirable because of IP usernames. The contributions query uses user_id not username, that's why a successful result is returned and displayed.
It seems it has been removed entirely now T283146: Remove --reuse-db option from phpunit.php
May 25 2021
May 24 2021
T220450 needs to be done eventually. But for short term, I was initially thinking of adding some logic to specify that "generate schema for this table only if the db is not postgres." But we can also create the table for "future use" if there's no problem with that.
May 19 2021
May 18 2021
This is caused by T268341: Possible XSS in SpecialGlobalUsage (CVE-2020-35622)
May 17 2021
May 11 2021
I don't think that message ever allows wikitext. Also the message is shown in the protection form dropdown where wikitext will seemingly not work well too. You should either delete the message (revert to the canonical one) or just remove the wikilink
May 10 2021
May 7 2021
May 6 2021
May 5 2021
Apr 27 2021
Apr 19 2021
Apr 17 2021
Apr 15 2021
Apr 8 2021
Apr 5 2021
Apr 4 2021
Apr 1 2021
Mar 28 2021
There's a script that does something like that https://www.mediawiki.org/wiki/Manual:RemoveUnusedAccounts.php. You need to check the limitations and what it considers 'unused'
Mar 26 2021
Mar 25 2021
Pointless is the same as "doesn't make sense" No one says it's harmful.
Mar 24 2021
Mar 22 2021
This is still happening
15:33:29 [0-1] AssertionError [ERR_ASSERTION] in "Page should be restorable" 15:33:29 Input A expected to strictly equal input B: 15:33:29 + expected - actual 15:33:29 15:33:29 - 'BeforeEach-name-0.5544652739983722-Iñtërnâtiônàlizætiøn has been restored\n\nConsult the deletion log for a record of recent deletions and restorations.\n\nRetrieved from "http://127.0.0.1:9412/index.php/Special:Undelete"' 15:33:29 + 'BeforeEach-name-0.5544652739983722-Iñtërnâtiônàlizætiøn has been restored\n\nConsult the deletion log for a record of recent deletions and restorations.' 15:33:29 [0-1] FAILED in chrome - /tests/selenium/specs/page.js
The fix for this (b38e0e8) may send a db query looking for revision with rev_id 0 which does not make sense.
Mar 21 2021
I ran this test in isolation with the evil hack given in T187581#4674890, both on PHP 7 and 8 but I cannot reproduce the failure. Maybe something has fixed elsewhere.