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 :)
Wed, Oct 9
Tue, Oct 8
Fri, Oct 4
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?
Mon, Sep 30
Sat, Sep 28
Wed, Sep 25
Sat, Sep 21
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?
Fri, Sep 20
Sep 11 2019
Sep 8 2019
Aug 24 2019
Aug 22 2019
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.
Aug 16 2019
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 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. :)