Mediawiki-api

mediawiki-api@lists.wikimedia.org

1 participants
1265 discussions

Parser Cache
by Chris Thomas 27 Apr '13

27 Apr '13

Hi, I am requesting a number of pages to be parsed on Wikipedia. Generally I am being returned the text, as expected. For some higher traffic pages, I am instead receiving a notice about it being cached. Could someone give me some pointers as to how I am meant to handle this? I’m guessing I need to make a new request to the parser, cache, using the provided key (see below). Does anyone have a link to a page, that explains this behaviour? Notice text is below… Cheers Chris Thomas "<ol> <li>REDIRECT <a href="/wiki/Stonehenge" title="Stonehenge">Stonehenge</a></li> </ol>   "

2 2

[Mediawiki-api-announce] BREAKING CHANGE: Wikidata langlinks handling in action=parse, list=allpages, list=langbacklinks, prop=langlinks
by Brad Jorsch 25 Apr '13

25 Apr '13

Language links added by Wikidata are currently stored in the parser cache and in the langlinks table in the database, which means they work the same as in-page langlinks but also that the page must be reparsed if these wikidata langlinks change. The Wikidata team has proposed to remove the necessity for the page reparse, at the cost of changing the behavior of the API with regard to langlinks. Gerrit change 59997[1] (still in review) will make the following behavioral changes: * action=parse will return only the in-page langlinks by default. Inclusion of Wikidata langlinks may be requested using a new parameter. * list=allpages with apfilterlanglinks will only consider in-page langlinks. * list=langbacklinks will only consider in-page langlinks. * prop=langlinks will only list in-page langlinks. Gerrit change 60034[2] (still in review) will make the following behavioral changes: * prop=langlinks will have a new parameter to request inclusion of the Wikidata langlinks in the result. A future change, not coded yet, will allow for Wikidata to flag its langlinks in various ways. For example, it could indicate which of the other-language articles are Featured Articles. At this time, it seems likely that the first change will make it into 1.22wmf3.[3] The timing of the second and third changes are less certain. [1]: https://gerrit.wikimedia.org/r/#/c/59997 [2]: https://gerrit.wikimedia.org/r/#/c/60034 [3]: https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap -- Brad Jorsch Software Engineer Wikimedia Foundation _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

2 1

API change request
by Liu Chenheng 23 Apr '13

23 Apr '13

Hello, All. I have a request here: I listen to the recent change list, and to the "page restore" action, I receive the log like this: <rc type="log" ns="0" title="William Pierce, Jr." rcid="565524106" pageid="38932317" revid="0" old_revid="0" user="Secret" oldlen="0" newlen="0" timestamp="2013-03-27T04:02:12Z" comment="5 revisions restored: keep the original redirect" logid="48107996" logtype="delete" logaction="restore"/> It's said that it restores 5 revisions but not tells me what are the 5 revisions. But in the log of "revision restore/delete", we can get the list of the affected revisions. Is it possible to do some changes of the API in order to support this feature. Thanks.

1 0

Using the API on WikiData ?
by Nicolas Vervelle 16 Apr '13

16 Apr '13

Hi, Is it possible to use the API on WikiData, for example to remove or update some interwiki links ? How do you do that ? I'd like to create a few bot tools for deleting / renaming categories, and I'd need to update the interwiki on WikiData ? Thanks Nico

3 4

A question about restore and delete page
by Liu Chenheng 16 Apr '13

16 Apr '13

Hello! I have a problem here: Do the restore and delete page action can cancel out each other? i.e. delete a page and then restore this page, equals we do nothing of this page. I listened the recent changes, and got more than 5 revisions of this page: http://en.wikipedia.org/w/index.php?title=William_Pierce,_Jr.&redirect=no And then I got a delete page action, later I got a restore page action, as you can see from the log: <rc type="log" ns="0" title="William Pierce, Jr." rcid="565524106" pageid=" 38932317" revid="0" old_revid="0" user="Secret" oldlen="0"newlen="0" timestamp="2013-03-27T04:02:12Z" comment="5 revisions restored: keep the original redirect" logid="48107996" logtype="delete"logaction="restore"/> it only restored 5 revisions but not specified what the 5 revisions were. In my opinion, the restore and delete page actions should cancel out each other like the restore and delete revision actions.

3 4

[Mediawiki-api-announce] Non-functional xmldoublequote parameter to format=xml being removed in 1.22wmf2
by Brad Jorsch 10 Apr '13

10 Apr '13

It was recently noticed[1] that the xmldoublequote parameter to format=xml has been broken since r55641,[2] merged in August 2009 and released with MediaWiki 1.16. Since it has been broken for over 3.5 years, it was decided to just remove the parameter.[3] Background: The xmldoublequote parameter was added in response to bug 11401,[4] as a workaround for the fact that XPath 1.0 did not specify any mechanism for escaping quotes in string literals. It caused all attribute values and text content to be double-encoded, e.g. a double quote would be represented as &quot;, and an ampersand would be represented as &amp;. Workaround: XPath 2.0, released in 2007, does include a quoting mechanism. Clients using XPath 1.0 may use string concatenation as a workaround.[5] [1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=46626 [2]: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/55641 [3]: https://gerrit.wikimedia.org/r/#/c/58261/ [4]: https://bugzilla.wikimedia.org/show_bug.cgi?id=11401 [5]: e.g. http://stackoverflow.com/questions/6937525/escaping-xpath-literal-with-pyth… -- Brad Jorsch Software Engineer Wikimedia Foundation _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

1 0

Re: [Mediawiki-api] [Wikitech-l] Provisional API extension for CAPTCHA on action=createaccount
by Brion Vibber 09 Apr '13

09 Apr '13

Ok, I've redone the whole shebang, hoping this'll pass muster. If not, I can do a larger refactor of the whole ConfirmEdit extension, maybe make a fresh one and introduce better machine-readable hook points into the API and form. But I hope this'll do for now. :) > MediaWiki core: https://gerrit.wikimedia.org/r/53793 > ConfirmEdit ext: https://gerrit.wikimedia.org/r/53794 > > test rig: https://github.com/brion/mw-createaccount-test Major changes from previous approach: * instead of falling through if in API mode (dangerous if using the new extension on old core), we check the captcha in the same consistent place in a hook from LoginForm. * We add a fairly generic hook that allows extensions to add return data via the createaccount API if they threw an abort instead of sending a generic error. This is used to append the captcha data. * We return result='needcaptcha' explicitly if we need to pass a captcha * Captcha data is not available until after you have a token, so this requires making two requests if you want to show a captcha before prompting for username/password. If y'all would prefer totally fresh interfaces with a consistent machine-readable API... I can do that too, but it'd be spiffy if we could do the less invasive change first. :) -- brion On Mon, Mar 25, 2013 at 1:38 AM, S Page <spage(a)wikimedia.org> wrote: > On Thu, Mar 14, 2013 at 3:55 PM, Brion Vibber <bvibber(a)wikimedia.org> > wrote: > > > MediaWiki core: https://gerrit.wikimedia.org/r/53793 > > ConfirmEdit ext: https://gerrit.wikimedia.org/r/53794 > > > > So far I've tested it with the default 'math captcha' mode, with this > test > > rig: https://github.com/brion/mw-createaccount-test > > This is great to see. > > Using your test rig or Special:APISandbox, the API return warns about > "Unrecognized parameters: 'wpCaptchaId', 'wpCaptchaWord" when I get > the captcha wrong. > > It seems if the user gets the captcha wrong, there's no explicit > indication like captcha-createaccount-fail ('Incorrect or missing > confirmation code.'). Instead the API reports a generic Failure > result, and the UI presents a new captcha. > > ConfirmEdit has a getMessage() to provide action-specific text like > fancycaptcha-createaccount. Perhaps the API should pass that back as > well. Otherwise the UI has to know the details of the captcha in use > so it can get a message for it. > > The current CreateAccount form submission to Special:UserLogin reports > many form errors like username exists, password wrong, etc. before it > runs the AbortNewAccount hook where ConfirmEdit checks the captcha. > But APICreateAccount runs the APICreateAccountBeforeCreate hook early, > before it dummies up a login form and calls the same validation. So > users will go through the frustration of getting the captcha right > before being told their username isn't available or their password > isn't long enough. > > There's also the weirdness that ApiCreateAccount winds up checking the > CAPTCHA twice. AIUI, here's the program flow: > > ApiCreateAccount() > Runs APICreateAccountBeforeCreate hook (captcha may abort) > Creates a login forms and call $loginForm->addNewaccountInternal(); > addNewaccountInternal(): > Does a bunch of form validation > Runs AbortNewAccount hook (captcha may abort, also > TitleBlacklist, AntiSpoof, etc. may abort) > > If ApiCreateAccount() could tell there was a captcha failure within > addNewaccountInternal and could ask the captcha to addCaptchaAPI() to > the result, then we wouldn't need the new APICreateAccountBeforeCreate > hook. > > It would be nice if captcha was always checked on its own hook instead > of sharing a hook with other extensions. That would let a future > validation API run the username past TitleBlacklist and AntiSpoof > without getting shot down by the captcha. > > Cheers, > -- > =S Page software engineer on E3 >

1 0

Re: [Mediawiki-api] Problem with generating email tokens
by Sumana Harihareswara 08 Apr '13

08 Apr '13

Prabhavathi, if you write about your project to the Wikimedia researchers' mailing list https://lists.wikimedia.org/mailman/listinfo/wiki-research-l and check out the resources available at https://meta.wikimedia.org/wiki/Research:Index , especially https://en.wikipedia.org/wiki/Wikipedia:Ethically_researching_Wikipedia , you might find more help. I hope you are able to add to the important body of research around Wikipedia users' behavior while still respecting the community you're engaging with. (By the way, did you already check with your advisor to see whether you need an IRB okay for this? http://cphs.berkeley.edu/ ) best, Sumana Harihareswara UC Berkeley class of 2002 -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation > Date: Sun, 7 Apr 2013 23:20:34 -0700 > From: Prabhavathi Matta <prabha.matta(a)gmail.com> > To: mediawiki-api(a)lists.wikimedia.org > Subject: [Mediawiki-api] Problem with generating email tokens > Message-ID: > <CAPe0CmRbs2z1uCPgD5xhEazs3zs6KKOCw-6xveR9=vCn768sMA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > I am working on an UC Berkeley research project to analyze wikipedia users' > behaviour. As a part of the project, I am developing an application which > sends a survey to a random sample of recent users. I am using mwclient code > to send emails though API. After testing around 3-4 times, the email tokens > are not getting generated anymore. I tried to send mails from different > login user. It still gives the same error. > > When I tried to send email from website > http://en.wikipedia.org/wiki/Special:EmailUser. It says," As an anti-spam > measure, you are limited from performing this action too many times in a > short space of time, and you have exceeded this limit. Please try again in > a few minutes." It has been 8 hours since and I still get the same message. > > Does this mean, I exceeded limit for my ip address or for that user? When > I googled it, the rate limit seems to be about 1000 api calls. I have sent > mails only to 3-4 test users for 5 times maximum. > > Which is a better way of sending emails to wikipedia users - Toolserver or > wikimedia API? How should I handle sending bulk emails(about 100) without > getting the "throttled message"? > > Please help. > > Thanks, > Prabha > UC Berkeley

2 1

Problem with generating email tokens
by Prabhavathi Matta 08 Apr '13

08 Apr '13

Hi, I am working on an UC Berkeley research project to analyze wikipedia users' behaviour. As a part of the project, I am developing an application which sends a survey to a random sample of recent users. I am using mwclient code to send emails though API. After testing around 3-4 times, the email tokens are not getting generated anymore. I tried to send mails from different login user. It still gives the same error. When I tried to send email from website http://en.wikipedia.org/wiki/Special:EmailUser. It says," As an anti-spam measure, you are limited from performing this action too many times in a short space of time, and you have exceeded this limit. Please try again in a few minutes." It has been 8 hours since and I still get the same message. Does this mean, I exceeded limit for my ip address or for that user? When I googled it, the rate limit seems to be about 1000 api calls. I have sent mails only to 3-4 test users for 5 times maximum. Which is a better way of sending emails to wikipedia users - Toolserver or wikimedia API? How should I handle sending bulk emails(about 100) without getting the "throttled message"? Please help. Thanks, Prabha UC Berkeley

6 7

About continuation of RecentChanges
by Liu Chenheng 02 Apr '13

02 Apr '13

I used the new style to request recent changes, i.e. http://en.wikipedia.org/w/api.php?action=query&list=recentchanges&continue= and then I simply copied the information <continue continue="-||" rccontinue="2013-04-02T10:26:26Z|567310672" /> to request the prev changes: http://en.wikipedia.org/w/api.php?action=query&list=recentchanges&continue= -||&rccontinue=2013-04-02T10:26:26Z|567310672 However, the results returned to me were not the correct rcid from 567310672 Is there anything wrong? Thanks.

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api