Wed, Sep 11
Sun, Sep 8
Sat, Aug 24
Thu, Aug 22
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.
Fri, Aug 16
Aug 11 2019
What exactly do you mean with "the page refuse to reload"?
Is related to change 425913.
Aug 6 2019
Aug 5 2019
Can you "unsinstall" the extensions one by one until the error disappears? Then you probably have the extension which causes the error :)
Jul 29 2019
@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?
Jul 28 2019
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.
Jul 26 2019
@Anomie You're absolutely right, I did not think about bisecting the problem *thumbsup*
Jul 20 2019
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! :)
Jul 18 2019
Jul 7 2019
Jul 2 2019
Jun 1 2019
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.
May 30 2019
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).
May 29 2019
May 27 2019
May 26 2019
This is how the app now looks like:
This is done in the extension and the Android app itself, too :)
May 21 2019
TODO: Creating an extension homepage on mediawiki.org (and then updating the project description) is welcome. :)
I created follow up tasks for this extension under the new PasswordlessLogin tag, so I think this task (as a hackathon task) can be closed :)