Mediawiki-api

mediawiki-api@lists.wikimedia.org

1 participants
1265 discussions

how to show changes in the watchlist mail notification
by Javier del Pozo 07 Nov '12

07 Nov '12

Hello, I need to customize my mediawiki to send added lines in the mail notification of changes (of a watchlist). Can you help me? Thanks, Javi

2 1

Re: [Mediawiki-api] List of broken image links?
by Jani Patokallio 04 Nov '12

04 Nov '12

On 11/4/12 11:00 PM, mediawiki-api-request(a)lists.wikimedia.org wrote: > Date: Sun, 4 Nov 2012 05:56:31 -0500 > From: Betacommand <Betacommand(a)gmail.com> > Subject: Re: [Mediawiki-api] List of broken image links? > > what version of mediawiki are you running? 1.19.1 -- this is for newly minted WMF project Wikivoyage.org. Cheers, -jani

2 1

List of broken image links?
by Jani Patokallio 04 Nov '12

04 Nov '12

Greetings, Is there a sensible way to find all broken (red) image links in a MediaWiki installation? That is, without having to do this: for all pages in wiki (list=allpages) for all image links in each page (prop=images) check if each image exists on that wiki if not, check again if it exists on commons Cheers, -jani

2 1

Curious about logins...
by Prunka, Sean 31 Oct '12

31 Oct '12

Our wiki (running 1.15.3) has a requirement to be logged in to view any pages other than login and the Main_Page. By default this extends to the API, but I'm having trouble understanding how to do the logins from an external PHP app w/ fopen. (can't get the cookies set up.) (We cannot use Snoopy, and the mangmt would prefer to not use cURL.) I am allowed to allow API calls w/o a login, given that our environment is closed, and not accessible to (or from) the Internet. Is there a way to leave the required login in place for direct visits to our wiki, but turn it off for API calls? Alternately, is there an example login script for PHP that uses fopen, instead of cURL or Snoopy that I could modify for our needs? Thanks in advance, Sean Prunka

2 2

Request for pages that don't exist no longer return an error code in xml
by Robert Chin 17 Oct '12

17 Oct '12

Is it intentional that pages that don't exist no longer return an error message? Previously a request for something like: http://en.wikipedia.org/w/api.php?action=parse&page=testest&format=xml&redi… Would return some friendly xml error that I could parse: <errors> <error code="missingtitle" info="The page you specified doesn't exist" /> </errors> Now it just returns an empty page. Is there some new way to detect if an invalid page has been requested or is this simply a bug? Thanks, Robert

2 1

Fwd: Please notice and report glitches - changes coming
by Sumana Harihareswara 12 Oct '12

12 Oct '12

Sorry for the spam, but the ContentHandler changes especially may affect you -- if you have any time this weekend or next week to do some testing, we'd appreciate it. Thanks. -Sumana -------- Original Message -------- Subject: Please notice and report big glitches - changes coming Date: Fri, 12 Oct 2012 17:14:05 -0400 From: Sumana Harihareswara <sumanah(a)wikimedia.org> Organization: Wikimedia Foundation To: Coordination of technology deployments across languages/projects <wikitech-ambassadors(a)lists.wikimedia.org> On Monday we start deploying a new version of MediaWiki, 1.21wmf2, to the sites, starting with mediawiki.org and 2 test wikis (https://www.mediawiki.org/wiki/MediaWiki_1.21/Roadmap). 1.21wmf2 will have 3 big new things in it and we need your help to test on the "beta" test site http://deployment.wikimedia.beta.wmflabs.org/wiki/Main_Page now to see if there are any really critical bugs. 1) The new ContentHandler ( https://www.mediawiki.org/wiki/ContentHandler ) might affect handing of CSS and JavaScript pages, import/export (including PDF export), and API stuff, especially when rendering and editing. I'd suggest we also look out for issues in template rendering, images and media handling, localisation, and mobile device access. (merged on Oct 9) 2) High-resolution image support. This work-in-progress will try to give higher-res images to high-density screens that can support it, like new Retina displays. More info at https://gerrit.wikimedia.org/r/#/c/24115/ . One of the bigger risks of the high res stuff is load-based, since we may see substantial new load on our image scalers. So *all* image scaling might be impacted. (merged on Oct 11) 3) "Sites" is a new backend to represent and store information about sites and site-specific configuration. This code is meant to replace the current interwiki code, but does not do so just yet. Still, keep an eye out for site-specific configuration or interwiki issues. Right now the version of MediaWiki on the beta cluster dates from 9 Oct and thus has ContentHandler but not the high-res image support or Sites. So please test on the beta sites now and look out for these issues on your sites in the weeks ahead. https://www.mediawiki.org/wiki/Category:MediaWiki_test_plans has some ideas on how to find errors. Thanks! With your help we can find bugs early and get them fixed before they affect lots of readers and editors. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

1 0

Ignore template links?
by Brian Keegan 11 Oct '12

11 Oct '12

Hi all, I'm trying to scrape some data from en.wiki about the outlinks from the body of articles. However, the API returns article outlinks contained within templates. While I can write a routine to get a list of all the templates and identify the article links inside these templates to remove from the outlinks, this is problematic if a link appears in both the body and a template. Thus if article X has a link to Y in the body as well as links to Y an Z in templates, I want to capture Y but not Y & Z. Ideally, I'd like to either (1) be able to count the number of times an article links out to another article (if X links to Y twice) and then iterate this count down for each appearance in a template or (2) count only the links occurring in the body and not parsing the links in templates. Thank you in advance for your suggestions! Best, Brian

3 2

Parse action - number of characters limit
by Łukasz Czyż 27 Sep '12

27 Sep '12

Hello I want to parse some variable-length wiki texts using 'parse' action. My problem is that API returns error if wiki text length exceeds some value, say 1000 characters. In such a case API returns well-formatted HTML page informing about unexpected error and it encourages to try again later. It doesn't look like expected behavior, rather like some fast-coded check. API documentation doesn't say anything about upper length limit. Is there a way to deal with that? I wouldn't like solution like 'splitting text into parts and parsing them separately' because it can be really problematic in some cases e.g. with very long lists ('#' markers). Łukasz

3 4

extracting external link portion of a wiki page
by Gunaratna, Dalkandura Arachchige Kalpa Shashika Silva 18 Sep '12

18 Sep '12

Hi, I have been using mediaWiki API to get categories a page belongs to using 'query' for 'action' and 'category' for 'prop'. Now I want to get external link part of a page. For example, Amoxicillin wikipedia page http://en.wikipedia.org/wiki/Amoxicillin has a table like structure in the external links section down in the bottom of the page having links to many other related concepts to Amoxicillin. I want to retrieve links of those related concepts. Currently, I am looking for a way to get these details. I am not sure yet whether I can do it through the API or I just have to process the page to get those details. If there is a way to get these details through MediaWiki API, please respond. Thank you very much in advance. regards, Kalpa

5 6

X-Frame-Options header
by Chris Steipp 31 Aug '12

31 Aug '12

Hi, I wanted to call attention on this list to a small change [1] in the api that we just released as part of a security update [2]. We previously had not set X-Frame-Option headers on the result of api queries. This could leave a site open to a variety of UI redressing attacks, so the WMF sites now set the X-Frame-Option: header to 'DENY' on API results. This will also be the default configuration for new downloads. If you need to show the result of an API query in an iframe, you can set the $wgApiFrameOptions = false to disable the header. However, I would encourage everyone to keep the header, as it will help prevent this type of attack. [1] - https://bugzilla.wikimedia.org/show_bug.cgi?id=39180 [2] - http://lists.wikimedia.org/pipermail/mediawiki-announce/2012-August/000119.…

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Mediawiki-api