Administrator might want to delete the file straight away, instead of tagging it as "Now Commons". Also, on English Wikipedia a few exported files are tagged as Keep local, and not as "Now Commons". I think it's good if adding "Now Commons" was easier, but it would be also good if FileImporter would ask for confirmation to tag the source page, or there was another way to skip editing the source wiki.

Thanks for the hint @Pikne! It sounds like confirmation would be a good idea.

In T160181, Fisch left this final breadcrumb:

While working on this and starting a first approach with calling the API of the source wiki via CentralAuth token, we decided that the proper/better to do this is would be submitting a job on the sourcewiki that does the edit

This sounds like a good approach, but leaves us in a bad place if the job fails. I propose that we try to combine this source wiki job with a notification. If the source wiki job fails, then the importing user receives a notification about the failure, which includes the text that should still be appended to the source file. This is of course subject to the "two-phase commit" problem, where we probably cannot guarantee that the failure notification is sent in 100% of cases, but "good enough" is probably good enough. We might also want to notify on success, depending on configuration and user preferences?

I'm not sure we need a central auth token. These seem to be used for CORS requests from the client, for example if we redirected to a page which then made the API edits from the importing user's browser. On the other hand, I still don't know what the alternatives are.

I might be missing something here but couldn't we simply do the following:

After a successful import with FileImporter,

1. we automatically redirect the user back to the source wiki
2. we let FileExporter take care of tagging the file
3. once the user confirms the changes to the source file
4. they are automatically redirected to the new file on the destination wiki

(pro) process would work for third-party wikis
(pro) no need for job queues or notifications
(con) one extra button click on the user's side (although users may want the confirmation page anyway)

I fiddled with this some time now, basically trying to get an example working for me on my local multi-wiki setup. - It felt a bit like history repeating because a was doing the same thing when originally working on T160181: Display new location in source wiki .

Although I'm still not able to get my local multi-wiki work as needed to do cross-wiki requests, I'm quite confident, that we can do these. The Echo extension is doing something similar when triggering notifications on foreign wikis and even have implemented a class for these cross-wiki requests [1]. Back in the days while exploring T160181 I also created a patch for the FileImporter roughly by c&p of the Echo class with adjustments made to fit into our setup [2].

Reading through the old stuff I think we did not really stop working on that because it's impossible, it was more because we were undecided if a job is not the better way to do it. And then we stalled it. ( Now I think a job is not better, it's best we go for the cross wiki edit. )

So, anyone else wants to give a multi wiki setup a try? ^^'

[1] https://gerrit.wikimedia.org/g/mediawiki/extensions/Echo/+/a334ab5d34c00a223e7d8f75b1b7b67751bbbfd8/includes/ForeignWikiRequest.php
[2] https://gerrit.wikimedia.org/r/386205/

Local vagrant environment with the centralauth role enabled is behaving well, I'll use that to debug our proof-of-concept patch tomorrow.

The patch works as intended, now. Only two minor changes: I had to change the action=edit request to a POST, and we needed an intermediate call to obtain a csrftoken. This approach will be fine!

Vagrant tips:

vagrant roles enable centralauth fileimporter

Upload a test file to http://centralauthtest.wiki.local.wmftest.net:8080
Import the file from http://dev.wiki.local.wmftest.net:8080/wiki/Special:ImportFile