Open source enthusiast, mathematics buff.
What's the argument against?, I mean what's the problem of currently using reflection object directly where convenient? (These are only used, or generally allowed only in tests I believe).
Thu, Oct 29
@Shubham656jain, You'd need to change the signature from 'current' to 'desired' as given in the task description.
Wed, Oct 28
In the original report at https://github.com/MatmaRex/patchdemo/issues/166 it is said FlaggedRevs is also affected, but FlaggedRevs is not using Hook handler system (extension.json) and so its callback should be working fine in theory because it would be loaded same ways as other extensions (that're not using Hook handler and not affected here)
Tue, Oct 27
This is because the entire namespace has been protected with that same level: T254280. There's no need for duplication.
If an anonymous user creates article in draft namespace and it's later moved (with all the history) to content namespace, the end result is, I think, just as if they created it there. For instance, this article https://en.wikipedia.org/wiki/Rakeem_Buckles is created by IP today and it's in content namespace. You'd have to pay attention to the move null entry to get what's happening. The definition of 'new pages' as used in the stats does not seems to exclude such pages.
I couldn't reproduce this with Chrome 86. Also couldn't with Mac's Preview. I am not sure whether this might be caused by Chrome's upstream change (need to know the versions you used though). I think there was once such corruption and it was traced to upstream Chromium change.
The link already exists on the page as can be seen in the version of the page a day before that edit
Mon, Oct 26
This is not a duplicate.
Fri, Oct 23
Purge the page https://en.wikipedia.org/wiki/Hirsutism?action=purge, it will return back to normal.
Thu, Oct 22
There are open patches for this: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/571411, https://gerrit.wikimedia.org/r/c/mediawiki/core/+/594533
OK, that's good to hear.
Since Wiktionary is case-sensitive on first character ($wgCapitalLinks is set to false), searching lower-case titles on mobile could be frustrating if > auto capitalization is enabled. The fix is just adding autocapitalize="off" to the search <input> element.
Let me clarify one thing here to avoid misunderstanding after the change, because this task description is assuming something which will not happen.
Wed, Oct 21
The method is named correctly. Apparently this is T245183 hitting harder
Intentionally thrown by extension: includes/Content/MassMessageListDiffEngine.php#29
@Clarakosi For code review
Tue, Oct 20
Sat, Oct 17
It does not seem to be AbuseFilter fault. AbuseFilter uses ArticleDeleteHook to filter deletion action (in this case). It founds the deletion should be disallowed (as configured) and the hook requires boolean return value to decide on whether to proceed with the deletion or not. So it's obvious, the only option for AbuseFilter is to return false to abort the deletion. It also sets the correct error message by modifying the supplied error variable in the hook. That's all it could do.
Thu, Oct 15
CX needs to unset the link. I have already wrote patch for that.
I see. Some of these issues have been lingering for close to four years and more are being filed e.g T265402, T233845, so I thought it'd be good to fix them, I see that's not the case now and that's fine.
This is caused by using mixture of core special page (AMC mode) and sending request from there to MobileFontend mobile special page. In desktop request cur_id is a valid substitute for page title. However, Jon made it clear in T174194 that there is no desire to continue fixing these mobile special page issues severally, instead, they should all wait for the eventual switch of the pages to use the original core special pages directly.
Both Timeless and Vector do not set the tag but they do generate the same trace as posted
How do they generate the trace?, give clear steps to reproduce
Tue, Oct 13
Have wrote patch for this in T246567
I'm seeing a very weird bug with MW 1.35 and the Citizen Skin (uses mustache).
Using the Timeless with ?useskin=timeless the robot tag disappears (correct behaviour).
...I've narrowed it down to line 1019 in Article.php.
If it's not happening in 'Timeless', then how are you sure the issue is not from the skin where you're seeing it?. It seems strange also to be skin specific.
Mon, Oct 12
Maybe create a VersionInfo service, analogous to GitInfo (not yet a service though itself), but they should all be.
Fri, Oct 9
I think it's trivial to fix this. :-).
I think there's a need to discuss this more before attempting implementing
Thu, Oct 8
@Johan , Yes basically. But it's not the merge history that breaks itself, it's only the source page. Also the fix now is to record the page as deleted (instead of leaving it in corrupted state), I think that's important to mention
This fixes a bug, so it's not a new feature. The merged task T225189 has more simpler steps to reproduce
Wed, Oct 7
Tue, Oct 6
In my view, if there's no expiry, then 'watchlistexpiry' should not appear in the result, that simply signifies that there's no expiry as the name suggests. That'd also be consistent with the conventional 'watch' action. (If you're not watching, the 'watched' status will not be included in the result at all).
Sat, Oct 3
I didn't say for all commands. It's for ALTER, that's the source of the error being discussed
I have an idea for simple fix to this, since the big switch is clearly not happening anytime soon.
Thu, Oct 1
It's trivial to fix, if someone is committing to review patch for that
It does not return an object, there is no object to return
This can be fixed in mw.title.lua by checking that php.getExpensiveData( t.fullText ) on line 209 is not nil before iterating over it with pairs.
That's not the root cause of the problem, it merely propagates to there, and so that's no right place to tackle the issue
Sep 30 2020
This error has origin from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/629403. and other caching side effects, as I noticed it first after pulling that patch at the time. The patch was a revert, but it has since been restored again (with modification).
The page needs rewrite. But any significant rewrite even for supported extension would really take time. But LiquidThreads is essentially dead and ought to be undeployed T187487.
Watchlist entries are duplicated not sure whether it was added after this task or not though.
Sep 29 2020
Note that this is not an error per se. If you don't select any revision that does not make sense and so you'll be redirected to an error page, the "return to mainpage" is meant to guide you and everything back to normalcy. There are many pages (that are not normal to come by) that have that generic return message also.
Sep 28 2020
@Jdlrobson I'd need your help on how to reproduce the problem that $wgULSPosition ='none' hack is supposed to solve in MobileFrontend. Because me I am not seeing anything if I removed it (MobileFrontendHooks.php#L123).
This will be temporarily fixed by having Scribunto content model to support redirects, there are some patches on that already. But to fix it once and for all, I can see two options: HistoryMerge needs to recognize these content models and delete the source page if no revision is remaining, since there's nothing more to see. It'll just be like how a move without leaving a redirect is currently treated. Otherwise this exception will always be thrown as these pages have all their revisions living elsewhere after the merge.
The other way is to make it mandatory for every content model to support redirect. That seems radical and may have its own downsides.
This needs to be fixed in includes/engines/LuaCommon/TitleLibrary.php if someone is interested. In PHP side, standalone '#' string will construct a valid title object with title text morphed to empty string (because of stripping of illegal chars) which will cause it to eventually just redirects to whatever the mainpage is.
If you want fix it, you can propose a patch. FYI this needs to be done in includes/Title.php
Sep 27 2020
Sep 25 2020
Glad to know the issue is already known and being discussed. Yes, either of these two themes may apparently be better than the one in T259890#6493908.
Some of the colors are really not good on white background.
Sep 24 2020
Just a note that this is still occuring as of today https://gerrit.wikimedia.org/r/c/mediawiki/core/+/629514