action=raw handles section=1 fine, but not section=T-1

I made a proof of concept at https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/587314/ that adds a ComplexStorageOperationFactory implementing a MergeHistoryFactory interface and a MovePageFactory interface. Some issues:

• If MergeHistory ever needs config values injected, there will be issues with the standard $options->assertRequiredOptions( self::CONSTRUCTOR_OPTIONS );, because the different interfaces will need different options, and there isn't an easy way to check which one is desired
• The tests using FactoryArgTestTrait only cover half of the combined factory, and it only works because one of the objects being created uses all of the available dependencies. If MergeHistory needs a service that MovePage doesn't, it will no longer be possible to use the FactoryArgTestTrait test
• Since MergeHistory accepts an option parameter in its constructor, its awkward to require that the services be passed

In short, I don't think a shared factory is going to work

In T52329#6037502, @Amire80 wrote:

In T52329#6037466, @DannyS712 wrote:

This just came up as an issue on enwikinews - wherever the original content is hosted must be compatible / released with CC-BY-2.5 to be able to use it on enwikinews

Do you have a link?

This just came up as an issue on enwikinews - wherever the original content is hosted must be compatible / released with CC-BY-2.5 to be able to use it on enwikinews

In T249565#6037254, @RoySmith wrote:

Oh, I blocked it on enwiki. I didn't realize that was the wrong place. Should I just unblock it there?

In T249565#6037156, @RoySmith wrote:

Just for the record, as the admin who performed the block, I have no objection to any other admin unblocking, once there's agreement that it's appropriate to do so.

In T249565#6037136, @Bugreporter wrote:

Is it the time to unblock EmausBot?

Done in 8.4.1, though without a help icon :(

I closed T227705: Add "help" link to Special:BlankPage as declined; will need to implement manually

In T227705#5330329, @Huji wrote:

https://www.mediawiki.org/wiki/Manual:Special_pages#Custom_special_pages does not provide the relevant information (for one thing, it never even mentions Special:BlankPage so for a non-technical user that help page is completely useless).
I am tempted to outright decline this task. It is up to the wikis with those user scripts to also create a pertinent help page and/or a script that would show a help link.

Without more info this cannot be addressed

@Addshore if you end up with a list of duplicates and can share it with me I can delete the items

Granted indefinitely

@Darylgolden can you give a specific url that was copied?

In T249561#6034925, @gerritbot wrote:

Change 586484 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/extensions/TwoColConflict@master] Don't create a Revision object for Linker::revUserTools
https://gerrit.wikimedia.org/r/586484

In T249565#6034783, @NickK wrote:

Logging here an unfortunate consequence: it is now possible to create a duplicate item linked to the same page.
Behaviour to reproduce:

1. https://uk.wikipedia.org/wiki/Кнайпа displayed as not linked to any Wikidata item.
2. https://de.wikipedia.org/wiki/Kneipe displayed as linked to https://www.wikidata.org/wiki/Q19754932 (the ukwiki article is linked to it as well)
3. A null edit on ukwiki does not help it link to Wikidata (still not linked)
4. To force linking I used a link on the sidebar in ukwiki and I add link to Kneipe on dewiki. The result is https://www.wikidata.org/wiki/Q89610534

I think it would be a good idea to block editing on Wikidata at the moment to avoid further damage.

In T249565#6034709, @Bugreporter wrote:

In T249565#6034676, @Bugreporter wrote:

Note in Wikidata EmausBot is creating a lot of duplicated items: https://www.wikidata.org/wiki/Special:NewPages

And due to this, rebuilding wb_items_per_site may results in some errors (see https://www.wikidata.org/wiki/Wikidata:True_duplicates)

In T249565#6034676, @Bugreporter wrote:

Note in Wikidata EmausBot is creating a lot of duplicated items: https://www.wikidata.org/wiki/Special:NewPages

In T249565#6034514, @Ahmad252 wrote:

+ Now on Commons; e.g. on https://commons.wikimedia.org/wiki/Commons:Deletion_requests/File:صورة_شخصية_له.jpg.

In T249561#6034370, @gerritbot wrote:

Change 586459 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Accept RevisionRecord in Linker methods
https://gerrit.wikimedia.org/r/586459

In T219279#6034047, @Anomie wrote:

In T219279#6033852, @DannyS712 wrote:

But, what happens to the redirects I left behind (including when I moved the files to a name other than the bot would have) - are they deleted?

If the uppercased target name doesn't exist, the redirect will be moved to that name.
If the uppercased target name does exist, the script will rename it to the name suffixed with "(former Unicode lowercase)".[1] If https://gerrit.wikimedia.org/r/c/mediawiki/core/+/585900 gets merged in time and the "(former Unicode lowercase)" would wind up pointing to the unsuffixed name or the unsuffixed name is a redirect to the same target as the suffixed name, the script will then delete the suffixed redirect.
[1]: That should be fixed for the file namespace, where extensions matter...

In T219279#6033847, @Anomie wrote:

In T219279#6033762, @DannyS712 wrote:

I assumed since the title would be unreachable it wouldn't work

Hmm. The file redirect would probably work, except the maintenance script won't actually leave a redirect behind at the soon-to-be-unreachable title because it will soon be unreachable. So yeah, do the moves and cleanup of references manually if you can.
The planned process is like this:

1. We move all the pages to the new uppercased titles. No redirects are left behind, so links to the lowercased titles will no longer work.
2. We remove the override that's preventing MediaWiki from uppercasing these letters. Now all the links start working again, just like links to "example" automatically target "Example".
3. We run the script again, which will hopefully find nothing to do (but might if someone did something in between when we did #1 and #2).
4. Produce a list of any "former Unicode lowercase" titles actually created, for communities to clean up.

We hope that the time spent in between #1 and #2 will only be a few minutes. We could as well do #2 first and then #1, but links would still be broken in between the two steps.

In T219279#6033659, @Framawiki wrote:

The titles will be by user "Maintenance script" beginning 13 April 2020.

If someone can update global userpage of this account with up to date information, that would be awesome :)

In T219279#6033694, @Anomie wrote:

In T219279#6033667, @DannyS712 wrote:

Since the old title will not work anymore,

Don't file redirects work?

In T219279#6012187, @holger.knust wrote:

Suggestion for User-notice
Mediawiki is upgrading to a newer version of Unicode. Some characters that did not have an uppercase before do now. Titles beginning with one of these characters will be moved. A list of these title can be seen at https://phabricator.wikimedia.org/P10817. The titles will be by user "Maintenance script" beginning 13 April 2020. You may rename them ahead of time if you wish and the new title can be different from the one the script would rename it to.

The UndeleteShowRevision hook is entirely unused; it can just be hard deprecated. If a use case emerges, it can be added back as UndeleteShowRevisionRecord with a RevisionRecord instead

In T244556#6030921, @thiemowmde wrote:

How is any of the assertion listed in this tasks description an issue? What do we win by disallowing one form?

In T249446#6032500, @Pchelolo wrote:

Conceptually MergeHistory looks exactly the same as MovePage - it's a class lying one level up from storage layer, made to do a complex task consisting of a collection of individual storage operations.
We already have a MovePageFactory, so adding a MergeHistoryFactory we're going to be setting up the pattern for classes like this. I donno how many more classes like this we have. If that's a lot, we should probably invent something more complex then adding a factory per class, if so far it's not a lot, I think we can live with interface-per-utility class and share an implementation or merge them all together into a ComplexStorageOperationFactory (name is horrible) interface. At least MovePage and MergeHistory seem to have very similar dependencies.

https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems

• The issue did not occur in chrome's incognito mode
• The issue did not occur with the remember flag enabled
• The issue did not occur on other wikis

...and its happening again

In T249380#6029976, @Majavah wrote:

How will this affect Toolforge database replicas or database dumps?

In T244556#6029861, @gerritbot wrote:

Change 585973 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/tools/codesniffer@master] Add a sniff for using assertNull instead of assertSame with null
https://gerrit.wikimedia.org/r/585973

Drafting at https://meta.wikimedia.org/wiki/User:DannyS712/Global_watchlist/Updates/Update_6

Done in 8.4.0