Mon, Sep 11
Sat, Sep 9
@Anomie has been doing some comment-related stuff recently...
Fri, Sep 8
Mon, Aug 28
This task is old and dusty, and most likely the issue has been resolved since 2014, particularly now that T60085 has been fixed.
abuse of the rights to edit texts may harm the site's reputation, but not the privacy of its users
Aug 19 2017
The import system has always assumed that any revisions attributed to user "X" in the import XML (that is, user X on the source wiki) should belong to the user X that exists on the target wiki, if such a user exists. In the pre-SUL days, this assumption was rather shaky at best, and is still troublesome when importing across wiki clusters. But in a world of SUL finalisation, the assumption is actually pretty reliable, so I don't see this as such a big problem as it used to be. That's not to say we shouldn't still fix it, though.
Aug 16 2017
Aug 14 2017
Aug 8 2017
Aug 5 2017
I can't seem to add Wikidata to this project for some reason... adding Lydia in the hope she can put the task in the right project :)
Aug 3 2017
No more reports since 19 July... is this still UBN? Per Anomie's comment quoted above, it's possible that this may have been fixed by virtue of fixing T169261.
Aug 2 2017
Jul 31 2017
I had an hour-long train ride with nothing to do, so I wrote up a guide to the approach used by For the Common Good.
The task is still valid, so I think it should stay open.
Jul 27 2017
I was hoping to work on it this month, but various IRL things happened so that I wasn't able to. I do plan to get to it eventually, but note that this task is not assigned to me, so anyone else may of course claim it if they wish.
Jul 26 2017
Jul 23 2017
Special:Interwiki is just a window into MediaWiki's internal interwiki system, so it sounds like you are seeking a change to the way MediaWiki (or MobileFrontend) handles interwiki links on mobile sites.
Jul 22 2017
.10 is now everywhere :)
Jul 16 2017
Jul 15 2017
Jul 14 2017
I would have left out the non-WMF-installed extensions on purpose, hoping that the extension maintainers would read the 1.29 release notes and remove the functions themselves. I'm surprised I missed CheckUser though...
Jul 13 2017
Ooh, clever! The plus sign would have to be in bold, or the changed user group coloured, or something else to make it stand out. But I like it.
getIRCActionText() would be for the IRC recent changes firehose channels, not for Special:Log. The formatting logic for Special:Log/rights would be in RightsLogFormatter.php.
Jul 11 2017
I was attempting to search for the "suffix" -happy (as in trigger-happy), in case it helps understand where I was going with my search.
Jul 10 2017
Jul 7 2017
I haven't really been working on the codebase much, so I haven't seen it recently. But it was an annoying intermittent failure at the time. If you think it is fixed, feel free to close the task.
Jul 4 2017
@Nikerabbit, do you think this is a configuration issue specific to testwiki, or a DB inconsistency? Or something else?
Jun 26 2017
Jun 25 2017
Jun 23 2017
Importing this XML file into a clean wiki with only Scribunto installed works fine for me in master (1.30.0-alpha) and in 1.27.1.
Adding MW-1.29-release just so this is on the radar of the releasing team when 1.29 tarballs are created.
Jun 22 2017
an "undo summary" should be enough to avoid a missing summary-prompt
Jun 21 2017
Adding @MaxSem to this so we're all on the same page.
Jun 20 2017
If you don't use Edge regularly you must not have anything to autocomplete :) I don't know what ID or name Edge is using to determine the entries in the list - possibly this is the autocomplete list for inputs with no ID or name.
Jun 19 2017
Jun 13 2017
This happens because the full history of the India article is massive, and the exported XML file is larger than the server can handle (PHP fatal error: request has exceeded memory limit).
Jun 2 2017
May 29 2017
May 25 2017
@NHarateh_WMF, why did you close this as "invalid"? Is there some reason why this task shouldn't be pursued?
May 24 2017
This has been fixed by running a maintenance script to remove invalid data from the database. If this error is seen on any more special pages, please reopen the task.
I'm going to mark this task resolved, as Special:Categories should now be working on all WMF wikis. I've created T166198: Invalid DB key being added to categorylinks table on zhwikibooks about the categorylinks issue. Thanks @Reedy, you're a legend!
Seems to be a MediaWiki bug. I created https://zh.wikibooks.org/wiki/User:This,_that_and_the_other/test (page id 23795) with the text [[Category:Blender 3D︰從入門到精通|插图集 ]] and a brand new invalid categorylinks row got added:
May 23 2017
The wikis that still need cleanup are:
- afwiki, arzwiki, azwiki, bewiki, bnwiki, bnwikisource, brwiki, cawikisource (same rows as before, with same primary key values) - so nothing in medium.log (F8114681) was fixed until it got down to cswiki
- commonswiki - 1 invalid pagelinks row (we didn't run this over the pagelinks table on large wikis before, so this one wouldn't have been found last time around)
- trwiki - 2 invalid titles in the page table, which need to be repaired by hand
- zhwiki, zhwiktionary, zhwikibooks - many invalid categorylinks entries persist. The script was clearly run with --fix on these sites, because the invalid category rows are gone. Might need to investigate what's happening here
@Reedy did that script ever finish?
May 20 2017
May 19 2017
The script's help reminds you to redirect stdout to a text file :)
May 18 2017
More of the same in large.log, except for trwiki which actually has two invalid titles in the page table. The script can't fix those, so they'll need to be repaired manually.
Virtually all of the invalid rows in medium.log are category and categorylinks rows with spaces in the title. There are a few invalid titles in the logging tables as well:
May 17 2017
@Reedy, want to try running this script again, initially as a dry run?
May 14 2017
We could get a shell user to do a mwgrep for wpSummary to identify affected scripts.
May 10 2017
May 9 2017
May 7 2017
May 6 2017
May 5 2017
May 4 2017
Thanks @hashar. I'll be sure to follow that advice!
May 2 2017
I created some new screenshots.
May 1 2017
It uses varchar instead of being a foreign key to another table or at least it's not a hash for faster lookup
I assume the reason it (and tag_summary) were written using varchar tag names as identifiers was to avoid having to make an additional join whenever you query ct_tag or ts_tag. We don't really care about the speed of lookups on ct_tag in general. On the other hand, whether this actually matters from a performance perspective is something @jcrespo would know more about.
Apr 30 2017
I can't help but notice that the Wikipedia logo in the top-left is missing in the initial screenshot. Is this just a coincidence?
See my previous comment. MW's built-in search is intentionally basic. If you would like this functionality on your own wiki, you need to install one of the search extensions.
You cannot modify the styling of Special:Preferences or Special:UserLogin. This is intentional. I understand that it is done so that users can reset their styles if they have set them incorrectly.
Apr 29 2017
Apr 28 2017
Apr 27 2017
I just looked into this. The reason why this is hard is that the Echo event occurs on the central wiki (metawiki in our case) but needs to be inserted into another wiki's database, which appears to be completely unsupported by Echo's infrastructure.
Actually may not need this...
On the basis that it is no longer occurring.