Page MenuHomePhabricator

RobinHood70 (Robert Morley)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Friday

  • Clear sailing ahead.

User Details

User Since
Oct 25 2014, 1:38 AM (346 w, 4 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
RobinHood70 [ Global Accounts ]

Recent Activity

Sun, May 23

RobinHood70 added a comment to T283391: Provide method to inject argument values when viewing template pages.

I thought it might be helpful to the discussion to provide a link to the template documentation: https://en.uesp.net/wiki/UESPWiki:MetaTemplate

Sun, May 23, 9:09 PM · MediaWiki-Parser

Sat, May 22

RobinHood70 added a comment to T283391: Provide method to inject argument values when viewing template pages.

Sorry, I had my extensions mixed up. I've been meaning "Semantic" whenever I said "Scribunto", though both are something we may end up using at some point. I corrected it in my latest message, but wasn't going to go back and edit every message I might've said it in.

Sat, May 22, 9:31 AM · MediaWiki-Parser
RobinHood70 added a comment to T283391: Provide method to inject argument values when viewing template pages.

The current version of the extension was written by a hobby programmer (albeit one who had remarkable insight into how the MW parser works) back between MW 1.10 through 1.15 or so, and has been hacked only enough to get it working as the years have gone by. One of the main modules is actually written entirely in global space! So, probably not something we'd want to release as is, even if we could. More importantly, however, It's her code, so not really ours to decide what to do with. We do have the code publicly available if you want to have a look at it, but not "public" public, as in intended for others to use. https://github.com/uesp/uesp-wikimetatemplate

Sat, May 22, 8:33 AM · MediaWiki-Parser
RobinHood70 added a comment to T283391: Provide method to inject argument values when viewing template pages.
Sat, May 22, 7:12 AM · MediaWiki-Parser
RobinHood70 added a comment to T283391: Provide method to inject argument values when viewing template pages.

TemplateSandbox, as I understand it, still requires the sandboxed templates be saved each time you make a change. What we're doing is injecting values during Show Preview and as the template code gets processed, so you can literally just preview/fix/preview/fix until you're sure the template is working correctly. Once it is, you can save it without having to copy anything anywhere, cuz you're working on the normal template page itself. This is much faster and more convenient than any kind of sandboxed process I've used on other wikis.

Sat, May 22, 3:07 AM · MediaWiki-Parser

Fri, May 21

RobinHood70 renamed T283391: Provide method to inject argument values when viewing template pages from Provide method to inject argument values when previewing template pages to Provide method to inject argument values when viewing template pages.
Fri, May 21, 9:49 PM · MediaWiki-Parser
RobinHood70 created T283391: Provide method to inject argument values when viewing template pages.
Fri, May 21, 8:33 PM · MediaWiki-Parser

May 10 2021

RobinHood70 added a comment to T236809: Refactor Parser.php to allow alternate parser (Parsoid).

Re-reading, I realize now that my initial comment came out much more acerbic than I intended, and undoubtedly set the wrong tone for my later comments, so I apologize for that. I also picked up this comment, which I'd somehow missed the first time around.

May 10 2021, 11:32 PM · MW-1.36-notes (1.36.0-wmf.8; 2020-09-08), MediaWiki-extensions-Variables, MW-1.35-notes (1.35.0-wmf.36; 2020-06-09), Parsing-Active-Work, Patch-For-Review, Parsoid, MediaWiki-Parser
RobinHood70 added a comment to T236809: Refactor Parser.php to allow alternate parser (Parsoid).

Yup, here it is: https://github.com/uesp/uesp-wikimetatemplate

May 10 2021, 10:53 PM · MW-1.36-notes (1.36.0-wmf.8; 2020-09-08), MediaWiki-extensions-Variables, MW-1.35-notes (1.35.0-wmf.36; 2020-06-09), Parsing-Active-Work, Patch-For-Review, Parsoid, MediaWiki-Parser
RobinHood70 added a comment to T236809: Refactor Parser.php to allow alternate parser (Parsoid).

I'm not trying to make "charged statements", and I apologize if I'm coming across that way. I'm just presenting my personal view and the views from a few other wikis that I've dealt with. I'm not trying to say it's representative of anyone else, and I'm not trying to be contentious. I'm just saying that not everybody's at the same place you are.

May 10 2021, 9:43 PM · MW-1.36-notes (1.36.0-wmf.8; 2020-09-08), MediaWiki-extensions-Variables, MW-1.35-notes (1.35.0-wmf.36; 2020-06-09), Parsing-Active-Work, Patch-For-Review, Parsoid, MediaWiki-Parser
RobinHood70 added a comment to T236809: Refactor Parser.php to allow alternate parser (Parsoid).

I wasn't trying to be difficult or insulting; I was just presenting the reality that I, personally, have seen. As a user of mostly small- to medium-sized wikis, most of which lag a fair bit behind the current version, I think my view of things is very different from yours where, as you say, you're supporting primarily large wikis with very different needs. All I was trying to say, really, was that while we may not have the page count/page views of the larger wikis, there is nevertheless a set of wikis that will prefer the legacy parser for one reason or the other. It may not even be for technical reasons such as ours, it might be simply a matter of processing power, preference, or whatever else. As I said in the beginning, and as has been on display throughout this thread, the attitude here is clearly "this is the direction we're going, get on board", and from the perspective of these smaller wikis that are behind by several versions, that's practically an overnight shift and it comes as a slap in the face.

May 10 2021, 9:28 PM · MW-1.36-notes (1.36.0-wmf.8; 2020-09-08), MediaWiki-extensions-Variables, MW-1.35-notes (1.35.0-wmf.36; 2020-06-09), Parsing-Active-Work, Patch-For-Review, Parsoid, MediaWiki-Parser
RobinHood70 added a comment to T236809: Refactor Parser.php to allow alternate parser (Parsoid).

Thank you for the explanation and the offer to engage with our requirements. Perhaps as the migration to Parsoid continues, better solutions will present themselves, but for us, right now the reality is that we've got 1700+ templates affecting over 75k content pages (not to mention those that affect non-content pages, like talk and redirect pages, bringing us to 300k pages overall). Having had our custom extension in place for 12 years now, most of our templates rely on it at this point, and we have only a handful of template coders to maintain them. So, hopefully you can understand that migrating to something that will essentially break all of that isn't just a pain point for us, it's simply not a viable option. While I would hope that this isn't the case, the reality may well have to be that we stop upgrading at whatever the latest version is that will support our needs.

May 10 2021, 8:39 PM · MW-1.36-notes (1.36.0-wmf.8; 2020-09-08), MediaWiki-extensions-Variables, MW-1.35-notes (1.35.0-wmf.36; 2020-06-09), Parsing-Active-Work, Patch-For-Review, Parsoid, MediaWiki-Parser
RobinHood70 added a comment to T236809: Refactor Parser.php to allow alternate parser (Parsoid).

We're not interested in migrating to Parsoid, nor were we aware that this was to become integrated rather than simply yet another extension, so wikis like ours likely ignored any calls for feedback, if they were aware of them at all. I certainly don't recall seeing anything about it in the few things I pay attention to/mailing lists I'm subscribed to, but that could well be what I just mentioned...the assumption that this was an optional component.

May 10 2021, 8:05 PM · MW-1.36-notes (1.36.0-wmf.8; 2020-09-08), MediaWiki-extensions-Variables, MW-1.35-notes (1.35.0-wmf.36; 2020-06-09), Parsing-Active-Work, Patch-For-Review, Parsoid, MediaWiki-Parser
RobinHood70 added a comment to T236809: Refactor Parser.php to allow alternate parser (Parsoid).

I'm not angry, really, so much as I see this sort of WMF-centric thinking from the developers often, and I think there needs to be some better feedback mechanism than simply trusting wfDeprecated() and the like to tell the developers what's in use and what's not. The reality outside of WMF wikis is that most lag several versions behind the current. Just browsing around, I easily found wikis between 1.25 and 1.33; I found none at 1.34 or above. So, deprecating something in 1.34 and then removing it in 1.35 or 1.36 because nobody complained or was logged as using the feature is not really a good plan for wikis like these. I think, if nothing else, there needs to be some kind of communication of planned deprecations/removals that allows extension developers who may not be at the current version to be made aware of breaking changes in advance and be able to say "Hey, we're still using this. We need a path forward."

May 10 2021, 7:35 PM · MW-1.36-notes (1.36.0-wmf.8; 2020-09-08), MediaWiki-extensions-Variables, MW-1.35-notes (1.35.0-wmf.36; 2020-06-09), Parsing-Active-Work, Patch-For-Review, Parsoid, MediaWiki-Parser

May 9 2021

RobinHood70 added a comment to T236809: Refactor Parser.php to allow alternate parser (Parsoid).

The attitude I'm seeing here from WMF is rather concerning. Essentially, it's "it's been decided". Well, that's lovely for WMF, but what about the rest of the wikis out there who maybe don't use (or perhaps even want/need) Parsoid, who don't use the Visual Editor, who don't use Flow, etc.? What do we do?

May 9 2021, 6:18 AM · MW-1.36-notes (1.36.0-wmf.8; 2020-09-08), MediaWiki-extensions-Variables, MW-1.35-notes (1.35.0-wmf.36; 2020-06-09), Parsing-Active-Work, Patch-For-Review, Parsoid, MediaWiki-Parser

May 2 2021

RobinHood70 created T281635: CleanupAncientTables.php runs even without --force.
May 2 2021, 6:06 AM · MW-1.35-notes, MW-1.36-notes, MW-1.37-notes (1.37.0-wmf.4; 2021-05-04), MediaWiki-Maintenance-system

Nov 1 2019

RobinHood70 updated the task description for T237074: Wanted Pages uses significantly non-optimal query.
Nov 1 2019, 12:44 AM · MediaWiki-Special-pages
RobinHood70 updated the task description for T237074: Wanted Pages uses significantly non-optimal query.
Nov 1 2019, 12:42 AM · MediaWiki-Special-pages
RobinHood70 created T237074: Wanted Pages uses significantly non-optimal query.
Nov 1 2019, 12:41 AM · MediaWiki-Special-pages

Oct 23 2019

RobinHood70 added a comment to T235477: ApiWatch result should emit namespace.

Good start, but there's a standard function to add title and namespace (the main concern being that 'ns' is the standard key for namespace). I'm not really a PHP programmer, but I believe the first couple of lines should look like this:

$res = [];
ApiQueryBase::addTitleInfo( $res, $title );
Oct 23 2019, 8:19 AM · MW-1.35-notes (1.35.0-wmf.4; 2019-10-29), User-DannyS712, Platform Team Workboards (Clinic Duty Team), MediaWiki-API

Oct 15 2019

RobinHood70 added a comment to T235476: ApiQueryExtLinksUsage euprop needs sanity check.

Okay, fair enough on both counts. After reporting this, I found a bunch more modules that also allow empty prop values and produce no meaningful output as a result, so if anything's done about it at all, it should probably be a larger project. For the count option, you're right, that would have to be a new option of some kind if it wasn't going to be a breaking change. I believe most database engines can count grouped records well enough as long as the relevant fields are indexed, but MW supports such a wide array of database engines that it would need testing on the whole lot, so that's probably a bigger change than I was thinking.

Oct 15 2019, 5:59 PM · Platform Engineering, MediaWiki-API
RobinHood70 renamed T235477: ApiWatch result should emit namespace from ApiWatch emits title but not namespace to ApiWatch result should emit namespace.
Oct 15 2019, 8:48 AM · MW-1.35-notes (1.35.0-wmf.4; 2019-10-29), User-DannyS712, Platform Team Workboards (Clinic Duty Team), MediaWiki-API
RobinHood70 created T235477: ApiWatch result should emit namespace.
Oct 15 2019, 8:48 AM · MW-1.35-notes (1.35.0-wmf.4; 2019-10-29), User-DannyS712, Platform Team Workboards (Clinic Duty Team), MediaWiki-API
RobinHood70 created T235476: ApiQueryExtLinksUsage euprop needs sanity check.
Oct 15 2019, 8:44 AM · Platform Engineering, MediaWiki-API

Oct 13 2019

RobinHood70 added a comment to T235246: ExpandTemplates XML tree fails with only template argument.

Just to add a bit more info, It occurred to me to try the equivalent query in the API, and it works fine there, producing the expected:
<root><tplarg><title>1</title><part><name index=\"1\"/><value/></part></tplarg></root>.

Oct 13 2019, 10:13 AM · MediaWiki-Parser, MediaWiki-Special-pages

Oct 11 2019

RobinHood70 added a comment to T235207: Some MediaWiki API call examples show an empty result set due to hardcoded "Main Page" title.

I just checked, and I'm thinking of the old manually documented examples (Template:ApiEx). They all pointed at enwiki. I finished the API portion of my project quite some time ago, so I haven't had much call to look at the live docs since then.

Oct 11 2019, 10:05 PM · Platform Engineering, Patch-For-Review, Documentation, MediaWiki-API
RobinHood70 created T235246: ExpandTemplates XML tree fails with only template argument.
Oct 11 2019, 4:57 AM · MediaWiki-Parser, MediaWiki-Special-pages

Oct 10 2019

RobinHood70 added a comment to T235207: Some MediaWiki API call examples show an empty result set due to hardcoded "Main Page" title.

I hadn't actually thought to check that, Reedy. Oops! That's odd, though. I could swear most of the examples used to work. Did they maybe point to en-wiki or something? Or am I just remembering the old manual documentation? <shrug>

Oct 10 2019, 7:13 PM · Platform Engineering, Patch-For-Review, Documentation, MediaWiki-API
RobinHood70 created T235207: Some MediaWiki API call examples show an empty result set due to hardcoded "Main Page" title.
Oct 10 2019, 6:37 PM · Platform Engineering, Patch-For-Review, Documentation, MediaWiki-API

Sep 27 2019

RobinHood70 created T234003: Vector tooltip(s).css typo.
Sep 27 2019, 3:18 AM · MW-1.34-notes (1.34.0-wmf.25; 2019-10-01), User-DannyS712, Readers-Web-Backlog (Tracking), Vector

Mar 5 2019

RobinHood70 created T217636: Upright option for images should have better validation.
Mar 5 2019, 9:18 AM · MediaWiki-Parser

Feb 25 2019

RobinHood70 added a comment to T216968: Iwbacklinks returns pageid as string instead of int.

That was fast! It looks like there's another report here that just came in recently. I hadn't noticed it before I posted.

Feb 25 2019, 12:11 AM · MW-1.31-release-notes, MW-1.27-release-notes, MW-1.32-notes, MW-1.30-release-notes, MW-1.33-notes (1.33.0-wmf.19; 2019-02-26), Patch-For-Review, MediaWiki-API

Feb 24 2019

RobinHood70 updated the task description for T216968: Iwbacklinks returns pageid as string instead of int.
Feb 24 2019, 9:09 PM · MW-1.31-release-notes, MW-1.27-release-notes, MW-1.32-notes, MW-1.30-release-notes, MW-1.33-notes (1.33.0-wmf.19; 2019-02-26), Patch-For-Review, MediaWiki-API
RobinHood70 created T216968: Iwbacklinks returns pageid as string instead of int.
Feb 24 2019, 9:06 PM · MW-1.31-release-notes, MW-1.27-release-notes, MW-1.32-notes, MW-1.30-release-notes, MW-1.33-notes (1.33.0-wmf.19; 2019-02-26), Patch-For-Review, MediaWiki-API

Jun 19 2018

RobinHood70 created T197730: API Help for FileRepoInfo incorrectly displays apiurl as a property.
Jun 19 2018, 11:08 PM · MW-1.32-notes (WMF-deploy-2018-07-10 (1.32.0-wmf.12)), Patch-For-Review, MediaWiki-Platform-Team (MWPT-Q4-Apr-Jun-2018), MediaWiki-API

Mar 15 2017

RobinHood70 created T160559: PopulateLogSearch.php does not update protection information.
Mar 15 2017, 6:14 PM · MediaWiki-Maintenance-system

Feb 2 2017

RobinHood70 created T157070: Watchlist token doesn't work in API.
Feb 2 2017, 7:22 PM · Growth-Team-Filtering, Growth-Team, MediaWiki-Watchlist

Jan 4 2017

RobinHood70 added a comment to T154324: ApiLogin returns failure on re-login by same user.

Good to know. Thanks for putting me onto that; at some point in the future, I'll likely strip out all the coding for older versions and add features like assertuser in their place. At the moment, it does me no good, though, since most of the sites I'm targetting are using anywhere between 1.19 to 1.26. Outside MediaWiki sites themselves, I rarely come across sites that are on 1.28+.

Jan 4 2017, 9:45 PM · MediaWiki-API

Dec 30 2016

RobinHood70 added a comment to T154324: ApiLogin returns failure on re-login by same user.

Now that I've understood what's going on, and adjusted my bot to compensate, no, but it was an unexpected point of failure, and the error message was uniquely unhelpful in figuring out the real problem.

Dec 30 2016, 4:35 PM · MediaWiki-API
RobinHood70 created T154324: ApiLogin returns failure on re-login by same user.
Dec 30 2016, 3:50 PM · MediaWiki-API

Dec 20 2016

RobinHood70 added a comment to T153704: ApiTag forces old-style boolean.

I should add that the API layer is nominally complete now, give or take a couple of new modules like clientlogin that I'll tackle later on...so I'm probably finished with the ream of bug reports now. :)

Dec 20 2016, 7:12 PM · MW-1.29-release-notes, MW-1.29-release (WMF-deploy-2017-01-03_(1.29.0-wmf.7)), Patch-For-Review, MediaWiki-API
RobinHood70 added a comment to T153704: ApiTag forces old-style boolean.

Unfortunately, it's nothing that would be useful to you for your testing procedures. I've been developing a C# bot framework that implements about 98% of the API. So, as I've been going through each module to determine what the inputs and results are for all of them, I've been noting the discrepancies.

Dec 20 2016, 7:10 PM · MW-1.29-release-notes, MW-1.29-release (WMF-deploy-2017-01-03_(1.29.0-wmf.7)), Patch-For-Review, MediaWiki-API
RobinHood70 created T153775: ApiWatch sets missing to 1 instead of true.
Dec 20 2016, 6:57 PM · MW-1.29-release-notes, MW-1.29-release (WMF-deploy-2017-01-03_(1.29.0-wmf.7)), Patch-For-Review, MediaWiki-API
RobinHood70 created T153733: ApiQueryWatchlist throws exception when wltype blank or invalid.
Dec 20 2016, 2:48 AM · MW-1.29-release-notes, MW-1.29-release (WMF-deploy-2017-01-03_(1.29.0-wmf.7)), Patch-For-Review, MediaWiki-API

Dec 19 2016

RobinHood70 added a comment to T153518: API RevisionDelete forces old-style booleans.

Anomie: That fix is filed under the wrong task.

Dec 19 2016, 7:18 PM · MW-1.29-release (WMF-deploy-2017-01-03_(1.29.0-wmf.7)), MW-1.29-release-notes, Patch-For-Review, good first task, MediaWiki-API
RobinHood70 added a project to T153704: ApiTag forces old-style boolean: MediaWiki-API.
Dec 19 2016, 7:07 PM · MW-1.29-release-notes, MW-1.29-release (WMF-deploy-2017-01-03_(1.29.0-wmf.7)), Patch-For-Review, MediaWiki-API
RobinHood70 created T153704: ApiTag forces old-style boolean.
Dec 19 2016, 7:07 PM · MW-1.29-release-notes, MW-1.29-release (WMF-deploy-2017-01-03_(1.29.0-wmf.7)), Patch-For-Review, MediaWiki-API
RobinHood70 created T153693: ApiMove throws exception on invalid talk space.
Dec 19 2016, 5:47 PM · MW-1.29-release-notes, MW-1.29-release (WMF-deploy-2017-01-03_(1.29.0-wmf.7)), Patch-For-Review, MediaWiki-API

Dec 17 2016

RobinHood70 created T153518: API RevisionDelete forces old-style booleans.
Dec 17 2016, 3:42 AM · MW-1.29-release (WMF-deploy-2017-01-03_(1.29.0-wmf.7)), MW-1.29-release-notes, Patch-For-Review, good first task, MediaWiki-API

Dec 16 2016

RobinHood70 added a comment to T153474: Protections collection in ApiProtect result needs stronger naming.

Yeah, I'd thought of that. It's a kludge, but you could potentially just add the type and leave the existing information alone. A client could then read the type, and from that, they'd have the key to read in the value.

Dec 16 2016, 6:14 PM · MediaWiki-API
RobinHood70 created T153474: Protections collection in ApiProtect result needs stronger naming.
Dec 16 2016, 5:01 PM · MediaWiki-API

Aug 7 2016

RobinHood70 created T142319: Invalid section links in search results.
Aug 7 2016, 4:54 AM · Discovery-Search, Discovery, CirrusSearch

Jul 28 2016

RobinHood70 added a comment to T141283: setHook (et al) allows silly tag names.

Just a note on this: based on the tests in PreprocessorTest.php, it seems MW breaks convention and deliberately allows tags with spaces.

Jul 28 2016, 6:23 AM · MediaWiki-Parser

Jul 26 2016

RobinHood70 added a comment to T141283: setHook (et al) allows silly tag names.

Yes. I realize it's not going to be a priority, but if the code is going to check for stupidly named hooks at all, which it already does, I think it should at least cover off basic correct syntax by excluding spaces, single-quotes, double-quotes, equals signs, and slashes. That would be the easy change, since it's just a matter of typing the extra characters into the Regex (and maybe making that a static Regex or whatever PHP supports, rather than repeating the same one in every function). Using the XML spec would probably be even better from a purely technical standpoint, but is probably overkill in this context.

Jul 26 2016, 7:10 PM · MediaWiki-Parser

Jul 25 2016

RobinHood70 updated the task description for T141283: setHook (et al) allows silly tag names.
Jul 25 2016, 5:54 PM · MediaWiki-Parser
RobinHood70 created T141283: setHook (et al) allows silly tag names.
Jul 25 2016, 5:53 PM · MediaWiki-Parser

Jul 13 2016

RobinHood70 added a comment to T28411: Entries for non-existent categories with no members should be deleted from the 'category' table.

I agree with Nicolas_Raoul here. There's nothing wrong with the app, the server should not be storing useless, deleted categories that have neither pages on the wiki, nor any category tags associated with them. As I said almost two years ago, this is a resource leak, and a malicious user could theoretically add to the table indefinitely, not that that's likely.

Jul 13 2016, 3:02 AM · Patch-For-Review, MediaWiki-Categories

Nov 15 2015

RobinHood70 created T118675: Feedwatchlist missing help for wltype entries.
Nov 15 2015, 5:04 AM · MW-1.27-release (WMF-deploy-2015-11-17_(1.27.0-wmf.7)), MW-1.27-release-notes, Patch-For-Review, MediaWiki-Documentation, Documentation, MediaWiki-API

Nov 12 2015

RobinHood70 created T118515: Feedrecentchanges missing categories help.
Nov 12 2015, 10:25 PM · MW-1.27-release (WMF-deploy-2015-11-17_(1.27.0-wmf.7)), MW-1.27-release-notes, MediaWiki-API

Oct 29 2015

RobinHood70 renamed T117022: Abnormal Scribunto hook causes output anomaly in siteinfo.showhooks from Abnormal Scribunto hook causes output anomaly in siteinfo.showhooks. to Abnormal Scribunto hook causes output anomaly in siteinfo.showhooks.
Oct 29 2015, 6:50 AM · MW-1.27-release-notes, MW-1.27-release (WMF-deploy-2015-11-03_(1.27.0-wmf.5)), Patch-For-Review, MediaWiki-extensions-Scribunto, MediaWiki-API
RobinHood70 created T117022: Abnormal Scribunto hook causes output anomaly in siteinfo.showhooks.
Oct 29 2015, 6:39 AM · MW-1.27-release-notes, MW-1.27-release (WMF-deploy-2015-11-03_(1.27.0-wmf.5)), Patch-For-Review, MediaWiki-extensions-Scribunto, MediaWiki-API

Oct 27 2015

RobinHood70 added a comment to T38220: The stashimageinfo module shouldn't be a prop querymodule (it doesn't accept titles and doesn't work with generators).

Sorry, I clued into how old this task was and that there was a new one a little after commenting. That's certainly a novel idea.

Oct 27 2015, 5:52 PM · MediaWiki-API

Oct 26 2015

RobinHood70 added a comment to T38220: The stashimageinfo module shouldn't be a prop querymodule (it doesn't accept titles and doesn't work with generators).

Actually, a List module would probably make even more sense. (D'oh!)

Oct 26 2015, 9:12 PM · MediaWiki-API
RobinHood70 added a comment to T38220: The stashimageinfo module shouldn't be a prop querymodule (it doesn't accept titles and doesn't work with generators).

Behaviourally, this would make more sense as a Meta module. That still leaves it as a query module, for whatever internal reasons there are for that, but gets it out of the prop space where it really doesn't belong at all. I'm not 100% sure of this, but it might even still be able to inherit from ApiQueryImageInfo, with little or no change.

Oct 26 2015, 9:09 PM · MediaWiki-API

Oct 15 2015

demon awarded T91203: ApiUpload allows overrun without error a Pterodactyl token.
Oct 15 2015, 8:58 PM · Security, Reading-Infrastructure-Team-Old (Don't use), Patch-For-Review, MediaWiki-API
demon awarded T91205: ApiUpload needs sanity check on chunk size a Pterodactyl token.
Oct 15 2015, 8:49 PM · Security, MW-1.26-release, MW-1.27-release (WMF-deploy-2015-10-27_(1.27.0-wmf.4)), MW-1.27-release-notes, MW-1.23-release, MW-1.24-release, MW-1.25-release, Vuln-DoS, Security-Core, Reading-Infrastructure-Team-Old (Don't use), Patch-For-Review, MediaWiki-API
RobinHood70 created T115564: ApiQuery iwurl conflicts with prop=iwlinks iwurl.
Oct 15 2015, 5:51 AM · MediaWiki-API

Sep 11 2015

RobinHood70 added a comment to T108449: ERR_SPDY_PROTOCOL_ERROR on Commons files with Chrome and Avast.

Looking around some more, it seems not to be a MediaWiki specific issue at all. This reddit thread gives some insight. https://www.reddit.com/r/chrome/comments/3j1oqk/beta_or_canary_users_have_versions_later_than_44/

Sep 11 2015, 12:50 AM · Browser-Support-Google-Chrome, Commons
RobinHood70 added a comment to T108449: ERR_SPDY_PROTOCOL_ERROR on Commons files with Chrome and Avast.

I'm getting this error repeatedly on mediawiki.org. Nothing loads at all on most attempts, and gives the above error. Sometimes, I'll get the requested page, but with no CSS at all. So far, I'm not getting the error on any other site, including the original Commons link. Exiting and restarting the browser *might* help, but that might just be a fluke.

Sep 11 2015, 12:41 AM · Browser-Support-Google-Chrome, Commons

Jul 13 2015

RobinHood70 added a comment to T63894: Allmessages returns un-normalized name.

I'm not sure if normalizing on its own is sufficient. There might need to be a "normalized" block as well, like there is with a page query, so you can map the input value to the output value.

Jul 13 2015, 4:43 PM · WMF-deploy-2015-07-21_(1.26wmf15), MW-1.26-release, Patch-For-Review, MediaWiki-API

Jun 18 2015

Ricordisamoa awarded T102645: API query siteinfo namespaces collection should be an array in JSON v2 a Dislike token.
Jun 18 2015, 3:57 AM · MediaWiki-API

Jun 17 2015

RobinHood70 added a comment to T102645: API query siteinfo namespaces collection should be an array in JSON v2.

I don't have any strong opinion on object vs array in formatversion=2 here, but the id field will stay either way.

Jun 17 2015, 5:59 PM · MediaWiki-API
RobinHood70 added a comment to T102645: API query siteinfo namespaces collection should be an array in JSON v2.

@TTO: Yes, I can see where you're coming from. It's one of the pitfalls of working in a different language is that I see the JSON as data to be parsed, not a fully realized data object, as it obviously would be when working in JavaScript. As Anomie says, though, even in JS, it becomes usage-dependent as to which way is easiest to deal with. In the end, at least for me, the difference is minor, so if the decision is to go back to an object, and possibly remove the id field as redundant, I can deal with that.

Jun 17 2015, 2:28 PM · MediaWiki-API
RobinHood70 added a comment to T102645: API query siteinfo namespaces collection should be an array in JSON v2.

@TTO: Not at all. I was assuming that people would map the JSON to a more useful collection. It never occurred to me that would actually work with the JSON directly without parsing it. In the context of parsing it, in most languages, parsing a key-value pair is more work (albeit only slightly) than having all the data in the same place (i.e., one element of the array), so it seemed to me that the logical way to go was to convert it to an array.

Jun 17 2015, 6:13 AM · MediaWiki-API

Jun 16 2015

RobinHood70 created T102645: API query siteinfo namespaces collection should be an array in JSON v2.
Jun 16 2015, 4:32 PM · MediaWiki-API

Jun 14 2015

RobinHood70 added a comment to T65966: Failed jobs never cleared from job table.

I'm not convinced that this is fixed from what I see in JobQueueDB.php in the latest nightly. I won't claim to understand all the code, but I think jobs that have been attempted, but failed, are still never being recycled. I can confirm this behaviour as of 1.22, but don't currently have a wiki higher than that where I've been able to confirm it. It seems to be related to either the claimTTL setting (as I originally speculated) or the fact that the job_token/job_token_timestamp fields are still populated in a failed job.

Jun 14 2015, 8:57 PM · MediaWiki-JobQueue

Jun 1 2015

RobinHood70 removed a member for Triagers: RobinHood70.
Jun 1 2015, 6:52 PM

May 27 2015

RobinHood70 added a comment to T71132: Special:BlockList displays 500 items instead of default 50.

Actually, I just figured it out. It's the Recent Changes setting that controls it. In earlier versions (confirmed up to 1.22), the preferences menu text makes it appear that that only controls Recent Changes when, in fact, it appears to control several things, including logs, as seen in the more modern preferences menu.

May 27 2015, 2:02 AM · WMF-deploy-2015-07-28_(1.26wmf16), MW-1.26-release, Patch-For-Review, MediaWiki-Special-pages
RobinHood70 added a comment to T71132: Special:BlockList displays 500 items instead of default 50.
May 27 2015, 1:56 AM · WMF-deploy-2015-07-28_(1.26wmf16), MW-1.26-release, Patch-For-Review, MediaWiki-Special-pages

Apr 13 2015

RobinHood70 updated the task description for T95867: Sidebar allows duplicate element IDs.
Apr 13 2015, 1:08 AM · MediaWiki-General
RobinHood70 created T95867: Sidebar allows duplicate element IDs.
Apr 13 2015, 1:07 AM · MediaWiki-General

Mar 23 2015

RobinHood70 added a comment to T90528: Generated API Help doesn't indicate the MediaWiki versions that support a module and parameters..

Maybe rather than trying to use the PHP-side docs as primary on the wiki, we should change it to a "see live docs" link and have that as an option that you can click on if the wiki page appears to be out of date. I think that'll give us the best of both worlds: the wiki can still document all the historical info and provide any custom formatting or topic-specific notes that might be required, while the live docs can be used, as Anomie says, as a quick reference.

Mar 23 2015, 5:20 PM · Documentation, MediaWiki-API
RobinHood70 added a comment to T90528: Generated API Help doesn't indicate the MediaWiki versions that support a module and parameters..

Would splitting modules into functional and documentation submodules be a useful model here? The API itself could then remain light and fairly clean, only linking to the documentation if needed, while documentation submodules would be off to the side, accessible by the documentation routines to allow documenting the older stuff. The one concern that jumps out at me is that, depending how it's done, lazy programmers could fail to document current and new features at all. This is already a problem with the wiki documentation vs. live modules and obviously, we don't want to simply move the problem to another venue.

Mar 23 2015, 2:10 PM · Documentation, MediaWiki-API

Mar 2 2015

RobinHood70 added a comment to T91203: ApiUpload allows overrun without error.

The filesize can never be bigger than $wgMaxUploadSize, so they can't keep increasing it indefinitely.

Mar 2 2015, 10:29 PM · Security, Reading-Infrastructure-Team-Old (Don't use), Patch-For-Review, MediaWiki-API
RobinHood70 added a comment to T91205: ApiUpload needs sanity check on chunk size.

How does this differ from someone just stashing a lot of 1-byte files? Or uploading only the first chunk for many different filenames?

Mar 2 2015, 10:23 PM · Security, MW-1.26-release, MW-1.27-release (WMF-deploy-2015-10-27_(1.27.0-wmf.4)), MW-1.27-release-notes, MW-1.23-release, MW-1.24-release, MW-1.25-release, Vuln-DoS, Security-Core, Reading-Infrastructure-Team-Old (Don't use), Patch-For-Review, MediaWiki-API

Mar 1 2015

RobinHood70 added a comment to T11018: Temporary upload stash not cleared when uploads cancelled.

I can confirm that this behaviour still occurs as of 1.24.

Mar 1 2015, 8:35 PM · Multimedia, TestMe, MediaWiki-Uploading
RobinHood70 updated the task description for T91205: ApiUpload needs sanity check on chunk size.
Mar 1 2015, 7:08 PM · Security, MW-1.26-release, MW-1.27-release (WMF-deploy-2015-10-27_(1.27.0-wmf.4)), MW-1.27-release-notes, MW-1.23-release, MW-1.24-release, MW-1.25-release, Vuln-DoS, Security-Core, Reading-Infrastructure-Team-Old (Don't use), Patch-For-Review, MediaWiki-API
RobinHood70 changed Security from default to security-bug on T91205: ApiUpload needs sanity check on chunk size.
Mar 1 2015, 7:00 PM · Security, MW-1.26-release, MW-1.27-release (WMF-deploy-2015-10-27_(1.27.0-wmf.4)), MW-1.27-release-notes, MW-1.23-release, MW-1.24-release, MW-1.25-release, Vuln-DoS, Security-Core, Reading-Infrastructure-Team-Old (Don't use), Patch-For-Review, MediaWiki-API
RobinHood70 updated the task description for T91205: ApiUpload needs sanity check on chunk size.
Mar 1 2015, 6:56 PM · Security, MW-1.26-release, MW-1.27-release (WMF-deploy-2015-10-27_(1.27.0-wmf.4)), MW-1.27-release-notes, MW-1.23-release, MW-1.24-release, MW-1.25-release, Vuln-DoS, Security-Core, Reading-Infrastructure-Team-Old (Don't use), Patch-For-Review, MediaWiki-API
RobinHood70 created T91205: ApiUpload needs sanity check on chunk size.
Mar 1 2015, 6:55 PM · Security, MW-1.26-release, MW-1.27-release (WMF-deploy-2015-10-27_(1.27.0-wmf.4)), MW-1.27-release-notes, MW-1.23-release, MW-1.24-release, MW-1.25-release, Vuln-DoS, Security-Core, Reading-Infrastructure-Team-Old (Don't use), Patch-For-Review, MediaWiki-API
RobinHood70 created T91203: ApiUpload allows overrun without error.
Mar 1 2015, 6:44 PM · Security, Reading-Infrastructure-Team-Old (Don't use), Patch-For-Review, MediaWiki-API

Feb 25 2015

RobinHood70 created T90780: ApiBlock throws exception when re-blocking non-blocked user.
Feb 25 2015, 8:27 PM · Patch-For-Review, MediaWiki-User-management

Feb 3 2015

RobinHood70 updated the task description for T88397: redirecttitle in API:Search returns title object instead of text.
Feb 3 2015, 5:18 AM · MediaWiki-Core-Team, Patch-For-Review, MediaWiki-API
RobinHood70 updated the task description for T88397: redirecttitle in API:Search returns title object instead of text.
Feb 3 2015, 5:13 AM · MediaWiki-Core-Team, Patch-For-Review, MediaWiki-API
RobinHood70 updated the task description for T88397: redirecttitle in API:Search returns title object instead of text.
Feb 3 2015, 4:56 AM · MediaWiki-Core-Team, Patch-For-Review, MediaWiki-API
RobinHood70 created T88397: redirecttitle in API:Search returns title object instead of text.
Feb 3 2015, 4:54 AM · MediaWiki-Core-Team, Patch-For-Review, MediaWiki-API

Jan 13 2015

RobinHood70 created T86607: Add mechanism to Special pages to filter output.
Jan 13 2015, 12:16 AM · MediaWiki-Special-pages