Getting this again out of the history again :D How would such a functionality look like from the API point of view?
Mon, Nov 18
I took a look into the test, however, this one is huuuugggeee, complicated and I can not really understand the intent of it, and as it is working pretty fine locally all the time, I don't feel very comfortable to work on this :( Maybe the person who can fix this, could also take a look into the test and try to make it easier to read and understand? :)
Fri, Nov 15
Yep, encountered this multiple times now as well, thought it was related to some changes in master, but it's flaky :(
Thu, Nov 14
Wed, Nov 13
@Jdlrobson Are you available to mentor this task? :) I would probably also co-mentor it, but I'm a bit out of MobileFrontend for quite some time and having someone who can also take a look would be very nice :)
Tue, Nov 12
Our notes from the session:
Sun, Nov 10
Sat, Nov 9
Sun, Nov 3
Would it make sense to reduce the scope of the GCI task to convert a single txt file to markdown, instead of expecting that one student is converting all of them? :)
Imported into GCI as https://codein.withgoogle.com/dashboard/tasks/5619920755228672/ I'll mentor this task :)
Awesome! Thanks for the clarification :)
Sat, Nov 2
I added a screenshot of how the screen looks at the moment :)
Awesome, thanks @Urbanecm :) I published the task!
Imported into Google-Code-in-2019 as https://codein.withgoogle.com/dashboard/tasks/5176453134548992/
I'm mentoring this task as well :)
it might relate to my missing knowledge of the codebase, however, GCI students will not have any context as well, so: Can you give a bit more context of the problem? Why is an "is_staff" check problematic and what is the expected replacement? Checking for a specific permission? Adding a new one or re-using an existing one? Once this is clarified, I would be happy to publish this task on the GCI website :)
Oct 9 2019
Oct 8 2019
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 :)
Oct 4 2019
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?
Sep 30 2019
Sep 28 2019
Sep 25 2019
Sep 21 2019
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?
Sep 20 2019
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).