yes, I think it should focus on looking at the existing methods and not new ones, since there doesn't seem to be a lack of the former :)

Actually I really like this idea for a session, it's kind of hard for a newcomer to actually being able to "see the wiki running", even if they did not even start with all the possible services we provide on top of MediaWiki core. I would, however, propose to keep the focus of this to a specific area in the beginning, probably MediaWiki core, as this is something most people will most likely run into, otherwise it could be an endless discussion?

What is the expected outcome of this session, is it mainly focussed on getting people, who are not familiar with our "system test level" to give an overview, so that they can provide valuable feedback, ideas and concerns in the session building on top of that?
Or is this session focussed on finding patterns and anti-patterns we're using or utilizing at the moment in order to try to have detailed focus-areas where we can invest time to imrprove and hopefully get rid of used anti-patterns?

Ok, then this is your actual problem: Adding the requires section is perfectly fine, however, for this to work you need to bump the manifest version from 1 to 2. However, your remaining extension.json is still version 1 of the manifest (the schema verification, if you run it, will most likely fail). E.g. the config section was massively overhauled in version 2 of the manifest, see the docs:

That looks completely unrelated from what I see. Can you post the full extension.json file, so we can reproduce the error locally? Is the error still occuring?

https://github.com/wikimedia/hyperswitch/pull/109

That highly depends on how the electron service is working :P So, honestly, I don't know as I don't know the source of the electron service.

What exactly do you mean with "the page refuse to reload"?

Is related to change 425913.

Can you "unsinstall" the extensions one by one until the error disappears? Then you probably have the extension which causes the error :)

@kostajh Thanks for your answer! :) I know found my problem, it was not related to the phpunit setup at all (as I already thought, as the unit tests worked well). It was related to the fact, that I use docker to run php, as well as my database and the webserver. And I simply missed to tell IntelliJ that it needs to start the php container for running the tests on the same network as the database in order to be able to connect to it. Now, both, the unit and integration tests run perfectly fine in my extension!

Is there a simple way how to trigger addurl only if url was added directly by the edit?

I support this, too, having wmf-deployment people able to deploy is their main reason why this group exists.

They are stored in LogStash, as (almost?) all logs :-). NDA is required to access.

@Anomie You're absolutely right, I did not think about bisecting the problem *thumbsup*

From my point of view, it could be closed given that moving of cards is possible on the task itself now, so it's not blocking us from using a mobile device to work :)

Basically, these edits needed to add a new (or changed) external URL, otherwise ConfirmEdit would not trigger with the addurl trigger. As far as I understand the code correctly, the link does not need to be added by the edit itself, it could've been added by a new or updated template or something like that.

Thanks to everyone involved in this! I finally can execute unit tests in my ide (integration tests are still throwing an unexpected error, however, this seems to be related to IntelliJ, as they run on the cli). This is absolutely awesome, as it will make developing tests and features much more easy! Kudos to everyone who helped getting this done! :)

One more thing that frustates me a lot (and directly pays in into the developer Productivity vision in my opinion) is, that MediaWiki makes it complicated to run tests for people who didn't know how it's done specifically in MediaWiki. Like phpunit tests. You can't run them out of IntelliJ at all (as far as I know, I'm not sure how this is in other IDEs) and you can't run them easily with the default phpunit commands (which you may know from other PHP projects already). So a new MediaWiki developer needs to go through a lot of documentation first in order to know how to run tests.

I played a bit with the first solution, however, it turns out that, even if we move the password field into a second step (which would mean, that the AbstractPasswordPrimaryAuthenticationProvider needs to return a UI AuthenticationResponse in the beginPrimaryAuthentication step), there's the problem thet AuthManager requires a response from continuePrimaryAuthentication to be non-ABSTAIN (which makes kind of sense). However, this means, that there can only be one password authentication provider listening for the second, new, UI step, however, core ships with 2 already (temporary and local passwords).

This is how the app now looks like:

This is done in the extension and the Android app itself, too :)

TODO: Creating an extension homepage on mediawiki.org (and then updating the project description) is welcome. :)