RobinHood70

the edit to the page with the tables

Sorry, I should have probably left a note after reverting. I agree that having empty (but existent cells) is better than having non-existent cells. I only reverted your edit because it caused some of the text that was supposed to in the first column to appear in the second column. As an example, the text This action is disabled by default in <code>DefaultSettings.php</code> moved from the function column to the example column (and it belongs on the function column). Cheers. Bawolff 22:51, 4 November 2010 (UTC)

I'm sorry...I never even noticed! I'll have another look at it and try again. My bad! RobinHood70 23:12, 4 November 2010 (UTC)

Adding img_id and oi_img_id

You may be interested in bug 71198, which would add img_id and oi_img_id. That way, you could do a prop=imageinfo query that would grab the image info for, say, 500 or 5,000 images, which you would specify using an imgid parameter. Later, of course, it will be a prop=fileinfo query. Leucosticte (talk) 19:43, 24 September 2014 (UTC)

Thanks! – RobinHood70 ^talk 19:52, 24 September 2014 (UTC)

Fixed at Template:API-head

Re API:Allredirects, we were fixing it over at Template:API-head. Cheers, John Vandenberg (talk) 02:00, 22 February 2015 (UTC)

I was just about to look at that. You got there before I did and confused my royally by fixing it! :P Thanks! – Robin Hood  ^(talk) 02:01, 22 February 2015 (UTC)

No worries. If you are bored, you could help me roll out Template:API-head onto the API pages. I am going to be doing API:Lists first. I am standardising them before setting up a bot to build these pages from the API paraminfo. See Thread:Project:Current issues/Api documentation bot. John Vandenberg (talk) 02:09, 22 February 2015 (UTC)

While I haven't been adding API-head to the pages, I've actually been updating each page as I create my bot-framework version of it. A bot is probably a good idea in the long run, though, since we can more easily add info as each version is released. For bot creators, it would be ideal if historical info was kept for a reasonable amount of time. I still come across wikis running on versions below 1.20...I found one on 1.15 a while ago, though I don't remember where off-hand. That's good info to know when programming. Anyway, I digress. I'll go have a look at the Props page and see what I can do there. – Robin Hood  ^(talk) 02:33, 22 February 2015 (UTC)

Yea, the pywikibot team is now doing the same thing. We add a decorator on our API methods, and require new contributions determine this info.([1]) We're nearly supporting v1.14 without any loss of functionality (except features which dont exist) and I've got most tests passing with v1.11 [2], but there is some serious opposition to the concept of supporting v.11. hehe. Which bot framework are you developing? John Vandenberg (talk) 02:46, 22 February 2015 (UTC)

The properties page is done now. Unfortunately, that's about all I'm up to tonight. Let me know if you need any more help on anything. I have historical copies of the MediaWiki code almost back to the beginning if there's any research needed of that nature. If nothing else, helping out here keeps me away from the content dispute I'm on on WP. This is why I like editing here, we don't really tend to get much of that. :) – Robin Hood  ^(talk) 03:03, 22 February 2015 (UTC)

UESP off-topic

I gained most of my knowledge on the Unofficial Elder Scrolls Pages.

Ahha-ha, as a trailing-edge gamer I'm spending too much time on http://www.uesp.net/wiki/Skyrim:Useful_Potions trying to figure out what to make when I return from a quest. So much homework!! :) -- SPage (WMF) (talk) 07:22, 24 February 2015 (UTC)

I made potions a fair bit for a while, but then I found I was constantly carrying all kinds of potions and getting bogged down. These days, I mostly just keep health and one or two magicka and stamina potions, except at the early levels. Careful how much time you spend at UESP, though. Speaking as a self-confessed addict, I think it's only fair to warn you that people have come to UESP and never left. :D – Robin Hood  ^(talk) 15:36, 24 February 2015 (UTC)

Api properties split

Hi, thanks for working on API pages. I'm trying to write some articles for "dev.wikimedia.org" but they refer to the API pages so I'm looking at them too.

Who else works on these pages? Is there a mw:Project:Documentation for us? I see User:Shirayuki localizing them and a bunch of people improving them.

You recently split Api:Properties, I'm curious why?

A few things I noticed looking at Api:Categories

• the {{API-head }} doesn't identify this as a submodule of action=query
• maybe the individual pages should be subpages of API:Properties or Api:Query, that way they have crumbtrail back to their parent.
• the introductory text "Gets a list of all categories used on the provided pages." and the {{API-head }} desctext "List all categories the page(s) belong to." are redundant.
• Api:Categories might be able to be just {{Api help|query+categories}}, but some of the other query submodules have information about versions as you pointed out.
• the link in the generated help returned by getHelpUrls() is https://www.mediawiki.org/wiki/API:Properties#categories_.2F_cl , they'll need to be updated

Thanks. -- SPage (WMF) (talk) 08:14, 24 February 2015 (UTC)

By and large, the API documentation pages are catch as catch can, and there's no formal process for them that I'm aware of. I've found some of them to be woefully out of date, and a few have no documentation at all (mostly less-used or new features). Truth be told, I only started updating them out of self-interest as I designed modules in my bot framework that mirror the API. Of course, now that I've started doing it, I'm admittedly motivated to keep doing it due to the addiction issues I mentioned in the above topic. Seems UESP isn't the only place that has this issue. ;)

Mostly, as you note, I've seen Shirayuki doing the translations. Anomie is also a big help, though his main focus is on editing the API modules themselves. Lately, John Vandenberg has also been doing quite a bit of work and Cgt (recently changed from Cgtdk) has also been popping up here and there.

As for the split, the Properties page was getting a bit long and especially with the Info and Revisions modules being so large, I found it difficult to read through. There was also the issue that the third-level headers repeated between the different modules, so linking to them was impossible without adding manual anchors and after editing one of them, the page would refresh and display the same section from the Info module. Splitting resolves all that. Since the List modules were already split the same way for the same reasons a couple of years ago, it made sense to me to do the same for the Properties and Meta modules as well, even though splitting Meta makes that page look a little bare.

And on to Categories:

• The API-head module has gone through a number of revisions, as you can see, but it does now include a {{{query}}} parameter, so it would be easy enough to add a "Query" to the box somewhere. Distinguishing it between a Property, List, or Meta would take an additional parameter, I think, or at least a change in approach to the existing one (e.g., query=prop).
• I'd have no objections at all to making the various pages subpages of their respective parents, though we'd have to go through and update the getHelpUrls code once again (more on that when I get to that bullet).
• I left the redundant introductory text as is for the moment because I wasn't sure if we wanted to keep the full text in the intro for those reading that, and the quick description in the box for those just looking for a summary, or if it was better to eliminate the redundancy.
• I'm honestly not sure what the best approach is to versioning, and I'm hoping your Phabricator post will generate some ideas. It seems silly to bog down the code with outdated parameter and version info, but I don't see any other easily automated way to do it. The best I can come up with is adding a "Deprecated/Removed Parameters" section to the page that we would update manually, but that still leaves the issue of documenting when a parameter was introduced.
• I've actually done the getHelpUrls work already (see this series of edits), but I've decided that it's better for my health (literally) to stay away from the whole Git/Gerrit updating thing. While it may not seem like it at a glance, I'm actually cognitively impaired and the longer I focus on a difficult task, the more out-of-it and error-prone I get. The entire process around updating the MediaWiki code usually left me with a headache and completely useless for anything but watching TV for a couple hours. It's just not intuitive to me at all. That all being said, I just noticed Anomie's last post there and that may be a solution. I'll have to look into it. I'll wait to do anything until we decide whether we're moving the pages to subpages or not. – Robin Hood  ^(talk) 16:11, 24 February 2015 (UTC)

• For those reading along, I submitted your getHelpUrls() work as gerrit:202368. We can tweak getHelpUrls() if and when we move to subpages, and even without updating the old wiki-page URLs will redirect. -- SPage (WMF) (talk) 02:07, 24 April 2015 (UTC)

Help needed again

Hi RobinHood,

you helped me recently with a answer to a Commons API question. Now I have another related problem. Could You have a look on Talk page and maybe explain a solution therefor? Many thanks. --Arch2all (talk) 10:16, 7 November 2015 (UTC)

A barnstar for you!

	The Technical Barnstar
	For you, a true MW-API hero! Thanks for all your helps! Dalba 18:18, 20 August 2016 (UTC)

API:Filerepoinfo

Tracked in Phabricator
Task T197730

Due to your revert: try the apiurl parameter, it will always fail. The url parameter works and "url" is also a result key. No glue where to change the live doc. @xqt 16:35, 19 June 2018 (UTC)

Ah and btw have a look at the sandbox' pull-down list. There is "url" too but no "apiurl"  @xqt 16:38, 19 June 2018 (UTC)

You're right that there's no "apiurl" in the sandbox, but that simply means that it's either not applicable to the repo or it's simply not defined if it is applicable. Nevertheless, it's one of the hard-coded options for foreign API repos (see ForeignAPIRepo.php's getInfo() function, if you have the MW source code handy). You can also see it by looking at the live help. – Robin Hood  ^(talk) 17:16, 19 June 2018 (UTC)

Did you ever tried to click that link of the live help sample? The apiurl isn’t recognized. Now try url instead of apiurl. I’ve no glue what is going wrong either with the code or with the doc. But they definitely does not match each other. Best.  @xqt 20:00, 19 June 2018 (UTC)

That's because we're not using InstantCommons on MediaWiki wikis; we're doing it some other way, apparently. If you look at a wiki that is using InstantCommons, like RationalWiki, you'll see that the API query works fine there. You do have a point, though, I think if "apiurl" is going to show up as an error, then it probably shouldn't be showing up in the help at all.

@Anomie: : Any comments? Recapping, it looks like xqt may have a bit of a point here: "apiurl" shows up in the live help for FileRepoInfo, even on wikis like this one where it returns an error. Looking through the code, I can't quite figure out where it's coming from. I assume ForeignAPIRepo is introducing it somehow, since that's the only thing that uses "apiurl", but I can't see how it's doing that without that value also showing up in the Value/Default entries at the bottom of the help entry. I'll continue digging, and if I spot anything and am able to confirm that this is a bug rather than a feature, I'll post something to Phabricator. Well, that turned out to be stupendously simple: it's hard-coded into the "apihelp-query+filerepoinfo-param-prop" help entry in api\i18n\en.json. – Robin Hood  ^(talk) 22:53, 19 June 2018 (UTC)

I see you filed task T197730 for this, I'll follow up there. Anomie (talk) 14:13, 20 June 2018 (UTC)

thanks  @xqt 15:07, 20 June 2018 (UTC)

June 2023

Why at the end of that month, when I tried to look at the logs of any anonymous user (I don't know if it happened to the others), specifically the page creation logs, I got "X.X.X.X isn't a valid username." and there was no result? A couple of days later it was repaired, but I want to know why that happened, greetings 192.34.82.122 15:10, 11 September 2023 (UTC)

One more note: that error message can still be seen (in IPv4 since I haven't experimented in IPv6 so far) if any of the 4 sides exceeds 255 but not more than 999 since 1000 is the first number with 4 digits 192.34.82.122 15:16, 11 September 2023 (UTC)

I'm not affiliated with MediaWiki in any way, and it's been a long time since I've done any MW-related programming, but I think the answer to your initial question is in your "One more note". IP addresses aren't valid if they have values higher than 255 in them, so MediaWiki's probably just looking for user names that have up to three digits in an X.X.X.X format where there are three digits per grouping or less, then flagging any with excessively high numbers as invalid. That would be my guess, anyway. – Robin Hood  ^(talk) 18:41, 11 September 2023 (UTC)

Maybe you didn't understand me well or I didn't express myself well, I will explain it to you in detail, If we search for the logs of an "IP(v4)" that exceeds the limit of 255 (for example 62.256.12.67), we will get "" and ""., and that happens with any number that exceeds 255, up to 999.999.999.999, since if any of the 4 parts there are 4 digits or more (like 2.5.0001.2), instead of that error, we simply get "No matching items in log." (because since it is more than 4 digits, the system does not identify it as an IP, it identifies it as a registrable user (although it cannot be registered because it is blacklisted)), that is clear, What I mean is the following: Why did a bug occur at the end of that month that caused any valid IP to get that same error in the logs? It has already been fixed, although at that time I thought all was lost, but I want to know, why that happened? 👋 193.37.255.2 22:29, 11 September 2023 (UTC)

I'm sorry, I can't help you. I've never worked significantly on the internal MediaWiki code and only worked with it as far as I needed to to design a bot, so I don't have the information you're looking for. Can I ask what led you to my page? – Robin Hood  ^(talk) 01:41, 12 September 2023 (UTC)

Yes of course, on this Topic:Xkjul6wdgyczporh in Help talk:Extension:ParserFunctions you have responded that it is not possible to know if a user is registered or not through a parser function, and that you also don't think of a tricky way to around that limit, so I decided to ask you for help in case you knew even more about MediaWiki 198.7.58.79 02:51, 12 September 2023 (UTC)