SWAT reserved on Wednesday 23rd:

\o/ Thanks @Lea_Lacroix_WMDE

We're getting close, but the whiskers are missing :-D

Also we could argue about getting a goat nose and dog eyes if that makes making it cute easier..

Wow that really was asap! Thanks! - But I just realized, that I forgot one essential requirement:

In T190717#4210310, @MoritzMuehlenhoff wrote:

In T190717#4210047, @Lea_WMDE wrote:

Hi @MoritzMuehlenhoff, we have news :)

• The changes for mobile are now part of the last master (should be version 1.7) now. So we are ready for beta again

Great! Can you make sure a release is cut/uploaded to https://releases.wikimedia.org/wikidiff2/, then I'll upgrade the package and update beta early next week.

In T193621#4210034, @thiemowmde wrote:

I see my name, but I have no idea what to do on this page: https://tools.wmflabs.org/openstack-browser/project/Mwfileimport. An introduction would be lovely.

I will add Thiemo to the maintainers list just now.

@thiemowmde @Tobi_WMDE_SW
So the extension master is pulled via cron job every few minutes. Core updates need to be done manually though. This is done now.

@Lea_WMDE this can be tested by comparing the diffs on

In T190717#4190164, @MoritzMuehlenhoff wrote:

In the mean time deployment-prep was also migrated to stretch, so as a preparatory step I'll prepare wikidiff 1.6.0 builds for stretch and update deployment-prep with that. When done, I'll ping this task. We need to re-run the tests made in beta with the new Debian version / underlying upgraded stack. I don't expect any issues, just due diligence.

@Lea_WMDE : I've built wikidiff 1.6.0 for Debian stretch (what Beta is now running compared to the previous tests) and upgraded deployment-prep/beta to that build. I would be great if the tests done a few weeks ago could be re-run with the new build.

I added another test for the uncovered path in getHandle by creating a file with insufficient permission. The throwExceptionIfOnShortWrite part will be harder to hit though since we have to limit the size of the file system. ... It could work with the mikey179/vfsStream lib though.

I added another test for the uncovered path in getHandle by creating a file with insufficient permission. The throwExceptionIfOnShortWrite part will be harder to hit though since we have to limit the size of the file system. ... It could work with the mikey179/vfsStream lib though.

In T189028#4191086, @Lea_WMDE wrote:

@WMDE-Fisch Do you remember the solution we found during the vienna hackathon we found for preventing jumping java script? Was it one of the mentioned ones already?

After digging deeper into MW core here and the FileImporter I came to the conclusion ( also with feedback from @Addshore and @thiemowmde ) that:

• changing the order of the import is not advisable since broken file imports could end up with no page attached
• removing the revision cannot be done in a good justifiable way
• avoiding the revision in the first place is the definite way to go here

! In T193620#4190563, @thiemowmde wrote:

@WMDE-Fisch, my impression is that these ForTheCommonGood config files are way ahead of the CommonsHelper2 ones. The syntax is more powerful, the config files are generally longer, and appear much more closely maintained (a lot of replacements CommonsHelper2 doesn't and can't do). However, I still suggest to stick to the CommonsHelper2 config for the MVP, for one particular reason: we really don't want to execute regular expressions anyone can edit. The CommonsHelper2 config syntax currently avoids this, as far as I can see.

For the record. Before our changes the same thing would have looked like this

So I simply added

.mw-diff-inline-moved-destination {
        background: PaleTurquoise;
        margin: 3px 0;
}

In T189439#4178290, @Lea_WMDE wrote:

Thanks for the test cases! Am I right to assume that all the cases that have links are the ones that we produce, whereas all error cases of T189570 that don't have a linked example are the ones that are mediawiki core errors and thus not handled by this patch?

The above patch is a PoC showing, that we can get the lists of templates and categories from the API of the source wiki. That's also how the CommensHelper2 tool is doing getting them. Since this pretty cheap and gives us clear and clean results we should definitely go this way.

Comments on that @thiemowmde @Andrew-WMDE - otherwise could be moved to Demo.

• ForTheCommonGood has it's own config file format that is read. Using partly reg ex for what should be done.
• MTC! does some hardcoded things to normalize or remove stuff

In T192352#4157566, @Lea_WMDE wrote:

@WMDE-Fisch how big is the re-investigation? It sounds like this is the one way to go, doesn't it?

In T189439#4165016, @Lea_WMDE wrote:

@WMDE-Fisch would it be possible to send back to the import preview page for warnings and fixable situations, and to show the error page if this is a real blocker?

Problems that occur after hitting the import button (such as abusefilter rule failures) also lead to that error page

The current version of the patch only catches the errors thrown by our own interface and redirect them to the new error page as stated in the ticket. Checking all the cases and redirecting more error should be handled individually when dealing with the full list in T189570