May 25 2023
Nov 28 2017
Imported as https://codein.withgoogle.com/dashboard/tasks/5928597153906688/ -- but I do not need it published yet
If I'm not mistaken, this would be a reasonable GCI task. I would be willing to mentor.
Nov 30 2016
Nov 29 2016
@FilipGCI It is preferred if you wait until you can claim the corresponding GCI task before claiming the task here.
I'll mentor this as a beginner task in Google-Code-In-2016. https://codein.withgoogle.com/dashboard/tasks/6396571428061184/
Nov 26 2016
Nov 22 2016
I'd be willing to mentor this as well.
Nov 1 2016
I will mentor this in Google Code-In 2016.
I'd love to mentor this year! Tomorrow I will find a few good first task tasks I'd like to mentor and I'll add myself to the wiki.
Sep 8 2016
@Mrjohncummings It was never merged. Awaiting code review in Gerrit.
Sep 4 2016
@Mrjohncummings Sorry this has taken longer than I originally intended! I'll be uploading a patch in just a few minutes. I am implementing what you had mentioned with the link test saying "Link", but I wonder if it would be better to use the article title instead.
Aug 30 2016
I can work on this in the next few days.
Jun 3 2016
I'll do this
Can't this be accomplished using the APIQueryAfterExecute hook?
Apr 24 2016
This is working correctly on the beta cluster
As previously mentioned, this change needs to be tested on the WMF cluster in case non-standard headers are filtered out.
Has something changed? The google search linked in the task description no longer seems to show extraneous entries.
I'm going to do this.
Mar 13 2016
Feb 5 2016
Feb 4 2016
Feb 2 2016
Jan 27 2016
So what do I need to do next, now that theres a working patch?
Jan 18 2016
@Tgr: Sorry I didn't have much time to work on this task today. I submitted a small patch for vagrant but I'm having some trouble adding a check to see if the requested database actually exists (ie. is in $wgLocalDatabases). I'm trying to add a check into Maintenance.php or doMaintenance.php, but I can't find a place to put the check after $wgLocalDatabases is actually populated. (At what point is $wgLocalDatabases expected to be populated? I assume they should be available after LocalSettings are loaded?)
Jan 16 2016
I'd like to work on this next. (Nemo told me I could claim it here to 'book' it :P)
Jan 15 2016
Jan 14 2016
I'm working on some if not all of this task for GCI under the mentorship of @Tgr. (Should this task be on the Google-Code-In-2015 project, since it's already imported and published? However, it is a multi-part task.)
Jan 13 2016
Just subscribing in case @Pranavmk98 decides not to claim this, as I'd be interested in this one too.
Jan 8 2016
@Tgr: There wasn't any red I don't believe. If it was trying to run the updates on the main wiki instead of the commonswiki it would pretend to succeed anyway, as it did in T122868 (silently fallback to default wiki)
Jan 6 2016
Jan 5 2016
This might be blocked by T122868.
Jan 3 2016
Jan 1 2016
Dec 31 2015
Dec 30 2015
Dec 29 2015
Dec 28 2015
I claimed this on GCI.
Claimed this on GCI.
Dec 27 2015
This is really a core mediawiki bug, right? The change needs to be made to core API files.
Claimed on GCI...it was a little easier than I expected...
Since the blocking task was completed, could this task get published @Aklapper? Thanks.
Dec 26 2015
Looks like jenkins was playing tricks on me, as an even-numbered build machine has also failed the same way. I suspect increasing the timeout will help as in the patch linked here. (The patch isn't actually mine...gerritbot just thinks it was because I added this bug to its commit message)
Whoops, forgot to claim this here.
I'm going to try to do this using a --rootpage parameter as opposed to an arbitrary prefix parameter, as you suggested in the previous changeset which this was attempted:
This needs to be removed from the GCI website as this task is closed.
Dec 25 2015
This should be removed from the GCI site since its fixed.
Dec 23 2015
I have claimed this on the GCI website.
Dec 21 2015
Here's a simple patch which, from my initial tests, seems to fix the problem. It just sets the wsEditToken session data to an empty string on logout (similar to how wsUserID is set to 0). I don't know if this is the only session data that needs to be reset, or whether setting this on logout is the best place to put this.
This issue has confused me greatly - what good are tokens if the session cookie is whats's being looked at anyways in terms of identifying the user?
Dec 19 2015
I've claimed this on the GCI website.
Dec 16 2015
I claimed this on GCI.
Dec 14 2015
Dec 12 2015
I've claimed this on GCI.
Dec 11 2015
I have claimed this on the GCI site.