[Mediawiki-api] [Mediawiki-api-announce] Change to action=login response when login fails due to session loss

[Brad Jorsch (Anomie)]

Since April 2010,[1] when no lgtoken is passed to the Action API
action=login it will return a "NeedToken" response including the token to
use. While this method of fetching the login token was deprecated in
January 2016,[2] it is still present for the benefit of clients that have
not yet been updated and is not (yet) being removed.

The NeedToken response was also being returned when an lgtoken was supplied
but could not be validated due to session loss. While this made sense back
in 2010 when the NeedToken response was the only way to fetch the login
token, these days it is mainly confusing[3] and a way for clients with
broken cookie handling to wind up in a loop.

With the merge of Gerrit change 586448,[4] the API will no longer return
NeedToken when lgtoken was supplied. If the token cannot be validated due
to session loss, a "Failed" response will be returned with a message
referring to session loss as the problem.

This change should be deployed to Wikimedia sites with 1.35.0-wmf.28 or
later, see https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a
schedule.

Note that the change HAS NOT been deployed to Wikimedia sites as of the
time of this email. If your client's ability to log in broke on 6 April
2020, the cause is most likely an unrelated change to Wikimedia's
infrastructure that caused some HTTP headers to be output with HTTP/2
standard casing, i.e. "set-cookie" rather than the traditional
"Set-Cookie". See https://phabricator.wikimedia.org/T249680 for details and
further discussion of that situation.

[1]: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/64677
[2]:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/000102.html
[3]: https://phabricator.wikimedia.org/T249526
[4]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/586448

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] Change to action=login response when login fails due to session loss

[Brad Jorsch (Anomie)]

Since April 2010,[1] when no lgtoken is passed to the Action API
action=login it will return a "NeedToken" response including the token to
use. While this method of fetching the login token was deprecated in
January 2016,[2] it is still present for the benefit of clients that have
not yet been updated and is not (yet) being removed.

The NeedToken response was also being returned when an lgtoken was supplied
but could not be validated due to session loss. While this made sense back
in 2010 when the NeedToken response was the only way to fetch the login
token, these days it is mainly confusing[3] and a way for clients with
broken cookie handling to wind up in a loop.

With the merge of Gerrit change 586448,[4] the API will no longer return
NeedToken when lgtoken was supplied. If the token cannot be validated due
to session loss, a "Failed" response will be returned with a message
referring to session loss as the problem.

This change should be deployed to Wikimedia sites with 1.35.0-wmf.28 or
later, see https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a
schedule.

Note that the change HAS NOT been deployed to Wikimedia sites as of the
time of this email. If your client's ability to log in broke on 6 April
2020, the cause is most likely an unrelated change to Wikimedia's
infrastructure that caused some HTTP headers to be output with HTTP/2
standard casing, i.e. "set-cookie" rather than the traditional
"Set-Cookie". See https://phabricator.wikimedia.org/T249680 for details and
further discussion of that situation.

[1]: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/64677
[2]:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/000102.html
[3]: https://phabricator.wikimedia.org/T249526
[4]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/586448

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

Re: [Mediawiki-api] Parameter type for complex data types

[Brad Jorsch (Anomie)]

On Tue, Feb 25, 2020 at 3:17 PM Matthew Dowdell 
wrote:

> I haven't seen it mentioned in the docs so far, but is there support for
> defining the interface using swagger/openapi? Given how tied into MediaWiki
> the server will be it seems unlikely, but I figured it was worth asking in
> case it was on a roadmap somewhere.
>

Not for the Action API or the MediaWiki REST API. The closest current plan
I'm aware of is a suggestion to generate a swagger/openapi spec *from* the
MediaWiki REST API (for use by clients that can do something useful with
such a spec), but that's kind of the opposite of what you asked about.

RestBase/RestRouter does use swagger, I think.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Parameter type for complex data types

[Brad Jorsch (Anomie)]

On Mon, Feb 24, 2020 at 6:01 PM Matthew Dowdell 
wrote:

> This module takes POST requests, so I'd just send it as part of the
> request body, but when it comes to deserialising it, I'm not really sure
> what to deserialise it to as everything seems to assume primitive values,
> e.g. strings, integers, etc. when it comes to setting the parameter type.
>

The Action API is generally based around a "form" model, and submission of
complex data structures is generally discouraged. If you really need to do
so anyway, you might accept data as a JSON string, or possibly you might
use the "templated parameters" added in 1.32.

MediaWiki now (since 1.34) also has a REST API. There the convention is to
accept JSON data structures via POST or PUT, ideally validated against a
JSON Schema of some sort.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Parameter validation error codes

[Brad Jorsch (Anomie)]

On Sat, Feb 22, 2020 at 4:34 PM Bartosz Dziewoński 
wrote:

> On 2020-02-22 10:59, Chen Xinyan wrote:
> > Just out of curiosity, is there any recommended way to parse out "which"
> parameter goes wrong. For example, we have "unknown_action" before. Now it
> gets merged into "badvalue", and the response looks like this:
> >
> > ...
> >
> > Do I have to parse into .error.info content to know the parameter name?
>
> For a long-term solution, I'd recommend filing a task to make the API
> return this data in another way.
>

As I said in the original announcement, "If you have a use case where
knowing which parameter triggered the error is needed, please let us know
(by replying to this message or by filing a request in Phabricator) and
we'll add the necessary error metadata."

What's the use case, other than just curiosity?

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Parameter validation error codes

[Brad Jorsch (Anomie)]

The error codes that may be changing are some of those representing invalid
values for API parameters. Notably, the following will change:

   - "noX", indicating that a required parameter was not specified, becomes
   "missingparam".
   - "unknown_X", indicating that an unrecognized value was specified for
   an enumerated-value parameter, becomes "badvalue".
   - "too-many-X", indicating that too many values were supplied to a
   multi-valued parameter, becomes "toomanyvalues".
   - "baduser_X", "badtimestamp_X", and so on become "baduser",
   "badtimestamp", and so on.

Note this is not a comprehensive list, other codes may be changing as well.

These changes make the error codes more predictable, at the expense of not
indicating in the code which parameter specifically triggered the error. If
you have a use case where knowing which parameter triggered the error is
needed, please let us know (by replying to this message or by filing a
request in Phabricator) and we'll add the necessary error metadata.

The human-readable text is also changing for some of these errors (with or
without error code changes), and for a few the error metadata may be
changing (e.g. "botMax" changes to "highmax" for limit-type warnings in
non-back-compat error formats).

This change will most likely go out to Wikimedia wikis with 1.35.0-wmf.19.
See https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a schedule.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Stricter validation of integer-type parameters

[Brad Jorsch (Anomie)]

Various unusual values for integer-type parameters to the Action API will
no longer be accepted. Acceptable values will consist of an optional sign
(ASCII `+` or `-`) followed by 1 or more ASCII digits.

Values that were formerly allowed, and will now result in a "badinteger"
error, include:

   - Values with extraneous whitespace, such as " 1".
   - "1.9", formerly interpreted as "1".
   - "1e1", formerly interpreted as either "1" or "10" at various times.
   - "1foobar", formerly interpreted as "1"
   - "foobar", formerly interpreted as "0".

Most clients should already be using correct formats, unless they are
taking direct user input without validation.

This change will most likely go out to Wikimedia wikis with 1.35.0-wmf.19.
See https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a schedule.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] BREAKING CHANGE: Stricter validation of integer-type parameters

[Brad Jorsch (Anomie)]

Various unusual values for integer-type parameters to the Action API will
no longer be accepted. Acceptable values will consist of an optional sign
(ASCII `+` or `-`) followed by 1 or more ASCII digits.

Values that were formerly allowed, and will now result in a "badinteger"
error, include:

   - Values with extraneous whitespace, such as " 1".
   - "1.9", formerly interpreted as "1".
   - "1e1", formerly interpreted as either "1" or "10" at various times.
   - "1foobar", formerly interpreted as "1"
   - "foobar", formerly interpreted as "0".

Most clients should already be using correct formats, unless they are
taking direct user input without validation.

This change will most likely go out to Wikimedia wikis with 1.35.0-wmf.19.
See https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a schedule.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api-announce] BREAKING CHANGE: Parameter validation error codes

[Brad Jorsch (Anomie)]

The error codes that may be changing are some of those representing invalid
values for API parameters. Notably, the following will change:

   - "noX", indicating that a required parameter was not specified, becomes
   "missingparam".
   - "unknown_X", indicating that an unrecognized value was specified for
   an enumerated-value parameter, becomes "badvalue".
   - "too-many-X", indicating that too many values were supplied to a
   multi-valued parameter, becomes "toomanyvalues".
   - "baduser_X", "badtimestamp_X", and so on become "baduser",
   "badtimestamp", and so on.

Note this is not a comprehensive list, other codes may be changing as well.

These changes make the error codes more predictable, at the expense of not
indicating in the code which parameter specifically triggered the error. If
you have a use case where knowing which parameter triggered the error is
needed, please let us know (by replying to this message or by filing a
request in Phabricator) and we'll add the necessary error metadata.

The human-readable text is also changing for some of these errors (with or
without error code changes), and for a few the error metadata may be
changing (e.g. "botMax" changes to "highmax" for limit-type warnings in
non-back-compat error formats).

This change will most likely go out to Wikimedia wikis with 1.35.0-wmf.19.
See https://www.mediawiki.org/wiki/MediaWiki_1.35/Roadmap for a schedule.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

Re: [Mediawiki-api] Request to block ActionApi-Client

[Brad Jorsch (Anomie)]

You would have to contact Wikimedia's Site Reliability Engineering team
with a request like this. Your best way forward is probably to file a task
in Phabricator <https://phabricator.wikimedia.org/> and tag it with
#Operations.

On Mon, Jan 27, 2020 at 11:08 PM Frank Wunderlich 
wrote:

> Hello,
>
> in 2016 I wrote a small Android app, that is making use of the Wikipedia
> ActionApi  to search for articles at the current location of a user.
> Due to legal considerations I am currently trying to take down the app.
> It’s not available any more in the Google PlayStore, but there are still
> installations out there.
> That’s why I want to make these installations unusable by deactivating all
> backend services, that the app is using.
> Unfortunately the app is (partially) directly communicating with wikipedia
> servers and not via a proxy under my control.
> The app sends a special User-Agent HTTP header with every request to
> identify itself:
>
> tagorama/v1.0.0.283-release (http://tagorama.rocks/; info@tagorama.rocks)
>
> Is there any way for you to block requests from this app?
> Who would I contact?
>
> Thanks for your help,
> Frank Wunderlich
> ___
> Mediawiki-api mailing list
> Mediawiki-api@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] BREAKING CHANGE: Format of blockexpiry timestamps from list=users and list=allusers

[Brad Jorsch (Anomie)]

The format of block expiry timestamps returned from list=users and
list=allusers has long been inconsistent. It was being returned in an
internal format (e.g. "20190918201053"), rather than the ISO 8601 format
used by the rest of the API (e.g. "2019-09-18T20:10:53Z").

The 'blockexpiry' property from these two modules will be changing to the
standard ISO 8601 format with 1.34.0-wmf.24. See
https://www.mediawiki.org/wiki/MediaWiki_1.34/Roadmap for a schedule of
deployment to Wikimedia wikis.

This change also brings the block information returned by list=users and
list=allusers fully in line with that already used for meta=userinfo and
'blocked' errors from various actions.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Format of blockexpiry timestamps from list=users and list=allusers

[Brad Jorsch (Anomie)]

The format of block expiry timestamps returned from list=users and
list=allusers has long been inconsistent. It was being returned in an
internal format (e.g. "20190918201053"), rather than the ISO 8601 format
used by the rest of the API (e.g. "2019-09-18T20:10:53Z").

The 'blockexpiry' property from these two modules will be changing to the
standard ISO 8601 format with 1.34.0-wmf.24. See
https://www.mediawiki.org/wiki/MediaWiki_1.34/Roadmap for a schedule of
deployment to Wikimedia wikis.

This change also brings the block information returned by list=users and
list=allusers fully in line with that already used for meta=userinfo and
'blocked' errors from various actions.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Reporting of edit failures due to AbuseFilter and SpamBlacklist

[Brad Jorsch (Anomie)]

When saving an edit is prevented by the AbuseFilter or SpamBlacklist
extensions, the error is currently reported as a successful API response
with a 'failure' code in the body.[1][2]

In the future, these will be reported as standard API errors.[3][4]

This change should be deployed to Wikimedia wikis with 1.34.0-wmf.23. See
https://www.mediawiki.org/wiki/MediaWiki_1.34/Roadmap for a schedule.

Clients that do not need to specially handle failures due to AbuseFilter or
SpamBlacklist will likely need no changes, as they probably already include
code to generically handle API error responses.

Clients that do handle AbuseFilter or SpamBlacklist failures specially will
need to be updated to check for error codes 'abusefilter-warning',
'abusefilter-disallowed', and/or 'spamblacklist' and handle them as they do
the current AbuseFilter and SpamBlacklist failures, if they want to
preserve their current special handling.

Note that edit failures due to CAPTCHAs from ConfirmEdit are not being
changed at this time. They will continue to be reported as before.[5]

[1]: AbuseFilter: https://phabricator.wikimedia.org/P8988
[2]: SpamBlacklist: https://phabricator.wikimedia.org/P8990
[3]: AbuseFilter: https://phabricator.wikimedia.org/P8989
[4]: SpamBlacklist: https://phabricator.wikimedia.org/P8991
[5]: ConfirmEdit: https://phabricator.wikimedia.org/P9076

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] empty extract field with exintro=True

[Brad Jorsch (Anomie)]

On Sat, Aug 24, 2019 at 7:02 AM Bertel Teilfeldt Hansen 
wrote:

> Hi Mediawiki-api mailing listers!
>
> I'm trying to get the intro to a list of Wikipedia pages using the
> "extracts" property with "exintro=True". This works fine for most sites,
> but for a few of them the API returns an empty extract field. See for
> example:
>
> https://en.wikipedia.org/w/api.php?action=query=extracts=Anthem=True
>
> When looking at the page "https://en.wikipedia.org/wiki/Anthem; there
> definitely seems to be text before the first section, so I think I should
> be getting something. Indeed without the "exintro" parameter, I get the
> expected return.
>
> Any idea why this occurs?
>

"exintro" assumes that the first heading tag ( to ) indicates the
end of the intro. In the HTML of that page, the {{TOC_Right}} causes the
table of contents to be before the visible text, and the table of contents
includes an , so it chops it off there.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] [Mediawiki-api-announce] Change to handling of POSTs without Content-Type on Wikimedia wikis due to PHP 7 migration

[Brad Jorsch (Anomie)]

On Sat, Aug 17, 2019 at 2:38 AM Ran Ari-Gur  wrote:

> Does this mean that if a client doesn't set the Content-Type header, and
> it sends some parameters in the URI query string and some parameters in the
> HTTP request body, then the latter are now sometimes ignored (and
> eventually will always be ignored)?
>

Yes, it does.


> If so, then this is a bit worrisome, in that safety-checks like
> starttimestamp=... and assertuser=1 wouldn't do their jobs, so actions
> might go through that aren't supposed to.
>

Since the "token" parameter is required to be in the POST body, the action
should fail due to that being missing if the "action" parameter is in the
query string.


> Is it possible for MediaWiki to detect that there was a message body but
> no Content-Type, and return an explicit error in that case?
>

It should be possible to detect a POST with no Content-Type, that's a good
idea. I doubt there's much point in trying to differentiate the rare case
of a POST with an empty body, particularly since the client should still be
including the content type even with that.

I filed https://phabricator.wikimedia.org/T230735 with the suggestion.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] Change to handling of POSTs without Content-Type on Wikimedia wikis due to PHP 7 migration

[Brad Jorsch (Anomie)]

According to RFC 7231 § 3.1.1.5,[1] a POST request that does not include a
Content-Type header may be interpreted by the server in one of two ways:

   1. It may assume application/octet-stream. In this case, PHP and the
   Action API will not see the request as having any parameters, and so
   will probably serve the auto-generated help page.[2]
   2. It may "sniff" the content type. It's likely enough to correctly
   guess application/x-www-form-urlencoded in this case, and therefore PHP and
   the Action API will see the request as having the intended parameters.

It turns out that HHVM and PHP 7 (at least as used at Wikimedia) differ in
their behaviors: PHP 7 seems to choose option 1, while HHVM chooses option
2.

Thus, clients that have been generating POST requests to Wikimedia wikis'
Action APIs without a Content-Type header will have been receiving expected
results from HHVM but will now start receiving unexpected results as
Wikimedia's migration to PHP 7 proceeds.[3] Affected clients should be
updated to include the Content-Type header in their requests.

See https://phabricator.wikimedia.org/T230526 for some details on this
issue.


[1]: https://tools.ietf.org/html/rfc7231#section-3.1.1.5
[2]: As seen for example at https://www.mediawiki.org/w/api.php.
[3]: See https://phabricator.wikimedia.org/T176370 for progress on the
migration.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] Change to handling of POSTs without Content-Type on Wikimedia wikis due to PHP 7 migration

[Brad Jorsch (Anomie)]

According to RFC 7231 § 3.1.1.5,[1] a POST request that does not include a
Content-Type header may be interpreted by the server in one of two ways:

   1. It may assume application/octet-stream. In this case, PHP and the
   Action API will not see the request as having any parameters, and so
   will probably serve the auto-generated help page.[2]
   2. It may "sniff" the content type. It's likely enough to correctly
   guess application/x-www-form-urlencoded in this case, and therefore PHP and
   the Action API will see the request as having the intended parameters.

It turns out that HHVM and PHP 7 (at least as used at Wikimedia) differ in
their behaviors: PHP 7 seems to choose option 1, while HHVM chooses option
2.

Thus, clients that have been generating POST requests to Wikimedia wikis'
Action APIs without a Content-Type header will have been receiving expected
results from HHVM but will now start receiving unexpected results as
Wikimedia's migration to PHP 7 proceeds.[3] Affected clients should be
updated to include the Content-Type header in their requests.

See https://phabricator.wikimedia.org/T230526 for some details on this
issue.


[1]: https://tools.ietf.org/html/rfc7231#section-3.1.1.5
[2]: As seen for example at https://www.mediawiki.org/w/api.php.
[3]: See https://phabricator.wikimedia.org/T176370 for progress on the
migration.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Improved timestamp support

[Brad Jorsch (Anomie)]

An upgrade to the timestamp library used by MediaWiki is resulting in two
changes to the handling of timestamp inputs to the action API. There will
be no change to timestamps output by the API.

All of these changes should be deployed to Wikimedia wikis with
1.34.0-wmf.10.

Historically MediaWiki has ignored timezones in supported formats that
include timestamps, treating them as if the timezone specified were UTC. In
the future, specified timezones will be honored (and converted to UTC).

Historically some invalid formats were accepted, such
as "2019-05-22T12:00:00.1257" or "Wed, 22 May 2019 12:00:00 A potato".
Due to improved validation, these will no longer be accepted.

Support for ISO 8601 and other formats has also been improved. See
https://www.mediawiki.org/wiki/Timestamp for details on the formats that
will be supported.
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] BREAKING CHANGE: Improved timestamp support

[Brad Jorsch (Anomie)]

An upgrade to the timestamp library used by MediaWiki is resulting in two
changes to the handling of timestamp inputs to the action API. There will
be no change to timestamps output by the API.

All of these changes should be deployed to Wikimedia wikis with
1.34.0-wmf.10.

Historically MediaWiki has ignored timezones in supported formats that
include timestamps, treating them as if the timezone specified were UTC. In
the future, specified timezones will be honored (and converted to UTC).

Historically some invalid formats were accepted, such
as "2019-05-22T12:00:00.1257" or "Wed, 22 May 2019 12:00:00 A potato".
Due to improved validation, these will no longer be accepted.

Support for ISO 8601 and other formats has also been improved. See
https://www.mediawiki.org/wiki/Timestamp for details on the formats that
will be supported.
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

Re: [Mediawiki-api] Error formats

[Brad Jorsch (Anomie)]

On Mon, Jun 3, 2019 at 1:35 PM Suhas Sumukh  wrote:

> What is the exact output when error formats is "raw". The "params"
> sometimes contains strings, arrays and even a hash map.
>
It's a representation of the MediaWiki i18n message data. Most parameters
are strings or integers, but some are "magic" arrays or hashes indicating
special formatting. And you can even have nested i18n messages as
parameters.

Unfortunately the exact format isn't very well specified at the moment.
What we probably need to do is enhance the MessageSpecifier interface with
those kinds of "magic" arrays and such, and possibly even define a
serialization format in MessageSpecifier.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Remote login user/client with API call

[Brad Jorsch (Anomie)]

On Wed, May 29, 2019 at 2:11 AM Valerio Bozzolan  wrote:

> AFAIK the parameters for the action 'clientlogin' are 'lgname' and
> 'lgpassword' and not 'username' and 'password'.
>

You are confusing action=clientlogin with the older action=login.


On Tue, May 28, 2019 at 5:35 PM Daniel Edery  wrote:

> The response that I get back is:
>
> {"warnings":{"main":{"*": "Unrecognized parameters: username, password."}}
> [...]
>
> What am I missing to correctly remote login a user?
>
It seems that your wiki is not configured for the normal password-based
login. What do you get if you request
api.php?action=query=authmanagerinfo=login on your wiki?

P.S. Please wrap your long lines, or at least don't embed them in a 
styled with white-space: nowrap.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Action API action=logout will require a CSRF token

[Brad Jorsch (Anomie)]

With the merge of Icb674095,[1] use of API action=logout will require a
CSRF token. This was considered a security issue, so the usual deprecation
process was not followed. See T25227[2] for details.

Clients that do not use a CSRF token with action=logout will receive a
badtoken error message ***and will not be logged out***.

This change should be deployed to Wikimedia wikis with 1.34.0-wmf.3. See
https://www.mediawiki.org/wiki/MediaWiki_1.34/Roadmap for a schedule.

Overall client impact is expected to be relatively low, as gathered
statistics indicate there are relatively few users of this API call. None
the less, maintainers should check their code for use of action=logout and
update as necessary to maintain expected operation.

[1]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/504565
[2]: https://phabricator.wikimedia.orgdo not use /T25227
<https://phabricator.wikimedia.org/T25227>
[3]: https://phabricator.wikimedia.org/T25227#4902709

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] [Mediawiki-api-announce] Deprecation of list=allusers 'recenteditcount' result property

[Brad Jorsch (Anomie)]

This deprecated property, announced in July 2014, will be removed in
MediaWiki 1.34. On Wikimedia sites, the removal will likely be deployed
with 1.34.0-wmf.2, which is scheduled for next week.

If your client is still using the "recenteditcount" property rather than
"recentactions", you should update your code ASAP.

On Tue, Jul 1, 2014 at 3:48 PM Brad Jorsch (Anomie) 
wrote:

> When list=allusers is used with auactiveusers, a property
> 'recenteditcount' is returned in the result. In bug 67301[1] it was pointed
> out that this property is including various other logged actions, and so
> should really be named something like "recentactions".
>
> Gerrit change 130093,[2] merged today, adds the "recentactions" result
> property. "recenteditcount" is also returned for backwards compatability,
> but will be removed at some point during the MediaWiki 1.25 development
> cycle.
>
> Any clients using this property should be updated to use the new property
> name. The new property will be available on WMF wikis with 1.24wmf12, see
> https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule.
>
>
>  [1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=67301
>  [2]: https://gerrit.wikimedia.org/r/#/c/130093/
>
> --
> Brad Jorsch (Anomie)
> Software Engineer
> Wikimedia Foundation
>


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api-announce] Deprecation of list=allusers 'recenteditcount' result property

[Brad Jorsch (Anomie)]

This deprecated property, announced in July 2014, will be removed in
MediaWiki 1.34. On Wikimedia sites, the removal will likely be deployed
with 1.34.0-wmf.2, which is scheduled for next week.

If your client is still using the "recenteditcount" property rather than
"recentactions", you should update your code ASAP.

On Tue, Jul 1, 2014 at 3:48 PM Brad Jorsch (Anomie) 
wrote:

> When list=allusers is used with auactiveusers, a property
> 'recenteditcount' is returned in the result. In bug 67301[1] it was pointed
> out that this property is including various other logged actions, and so
> should really be named something like "recentactions".
>
> Gerrit change 130093,[2] merged today, adds the "recentactions" result
> property. "recenteditcount" is also returned for backwards compatability,
> but will be removed at some point during the MediaWiki 1.25 development
> cycle.
>
> Any clients using this property should be updated to use the new property
> name. The new property will be available on WMF wikis with 1.24wmf12, see
> https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule.
>
>
>  [1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=67301
>  [2]: https://gerrit.wikimedia.org/r/#/c/130093/
>
> --
> Brad Jorsch (Anomie)
> Software Engineer
> Wikimedia Foundation
>


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

Re: [Mediawiki-api] Problem with different versions

[Brad Jorsch (Anomie)]

On Wed, Jan 23, 2019 at 3:22 AM Czuma, Marek <
marek.cz...@contractors.roche.com> wrote:

> Hi,
> I work on project using API of portal based on Media Wiki.
> Unfortunately they changed media wiki version from 1.16 to 1.30.
>

The output format for some log events' parameters was changed in MediaWiki
1.25, as part of making the formatting more regularized and allowing
extensions to format their event parameters.

The original announcement of this change can be read at
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2015-April/79.html


> Earlier in endpoint list: logevents I got response with field move.
> Unfortunately, we don't have 'move' field in response now. I don't know
> what is it (one thing I know: move field had 2 fields: new_ns and
> new_title).
> I now also that now in response we can find 'params' field, which has also
> 2 fields: target_ns and target_title.
>

Yes, that is the change that was made. You should be able to switch from
using the 'move' field to the 'params' field.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] DEPRECATION: Action API uncaught exception error codes

[Brad Jorsch (Anomie)]

Currently the codes for uncaught exceptions include the class name, for
example "internal_api_error_ReadOnlyError", or
"internal_api_error_DBQueryError", or possibly something like
"internal_api_error_MediaWiki\Namespace\FooBarException". As you can see in
that last example, that can get rather ugly and complicates recent attempts
to verify that all error codes use a restricted character set.

Thus, we are deprecating these error codes. In the future all such errors
will use the code "internal_api_error". The date for that change has not
yet been set.

If a client for some reason needs to see the class of the uncaught
exception, this is available in a new 'errorclass' data property in the API
error. This will be returned beginning in 1.33.0-wmf.8 or later, see
https://www.mediawiki.org/wiki/MediaWiki_1.33/Roadmap for a schedule. Note
that database errors will report the actual class, such as
"MediaWiki\rdbms\DBQueryError", rather than the old unprefixed name that
had been being maintained for backwards compatibility.

Clients relying on specific internal error codes or detecting internal
errors by looking for a "internal_api_error_" prefix should be updated to
recognize "internal_api_error" and to use 'errorclass' in preference to
using any class name that might be present in the error code.

In JSON format with errorformat=bc, an internal error might look something
like this:

{
"error": {
"code": "internal_api_error_InvalidArgumentException",
"info": "[61e9f71eedbe401f17d41dd2] Exception caught: Testing",
"errorclass": "InvalidArgumentException",
"trace": "InvalidArgumentException at ..."
},
"servedby": "hostname"
}

With modern errorformats, it might look like this:

{
"errors": [
{
"code": "internal_api_error_InvalidArgumentException",
"text": "[61e9f71eedbe401f17d41dd2] Exception caught: Testing",
"data": {
"errorclass": "InvalidArgumentException"
}
}
],
"trace": "InvalidArgumentException at ...",
"servedby": "hostname"
}


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api] [Mediawiki-api-announce] DEPRECATION: Action API uncaught exception error codes

[Brad Jorsch (Anomie)]

Currently the codes for uncaught exceptions include the class name, for
example "internal_api_error_ReadOnlyError", or
"internal_api_error_DBQueryError", or possibly something like
"internal_api_error_MediaWiki\Namespace\FooBarException". As you can see in
that last example, that can get rather ugly and complicates recent attempts
to verify that all error codes use a restricted character set.

Thus, we are deprecating these error codes. In the future all such errors
will use the code "internal_api_error". The date for that change has not
yet been set.

If a client for some reason needs to see the class of the uncaught
exception, this is available in a new 'errorclass' data property in the API
error. This will be returned beginning in 1.33.0-wmf.8 or later, see
https://www.mediawiki.org/wiki/MediaWiki_1.33/Roadmap for a schedule. Note
that database errors will report the actual class, such as
"MediaWiki\rdbms\DBQueryError", rather than the old unprefixed name that
had been being maintained for backwards compatibility.

Clients relying on specific internal error codes or detecting internal
errors by looking for a "internal_api_error_" prefix should be updated to
recognize "internal_api_error" and to use 'errorclass' in preference to
using any class name that might be present in the error code.

In JSON format with errorformat=bc, an internal error might look something
like this:

{
"error": {
"code": "internal_api_error_InvalidArgumentException",
"info": "[61e9f71eedbe401f17d41dd2] Exception caught: Testing",
"errorclass": "InvalidArgumentException",
"trace": "InvalidArgumentException at ..."
},
"servedby": "hostname"
}

With modern errorformats, it might look like this:

{
"errors": [
{
"code": "internal_api_error_InvalidArgumentException",
"text": "[61e9f71eedbe401f17d41dd2] Exception caught: Testing",
"data": {
"errorclass": "InvalidArgumentException"
}
}
],
"trace": "InvalidArgumentException at ...",
"servedby": "hostname"
}


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] Deprecation of the disabletidy parameter to action=parse

[Brad Jorsch (Anomie)]

Now that MediaWiki has a pure-PHP tidying implementation, we are
deprecating non-tidy output.[1] Further, the future rewrite of Parsoid in
PHP[2] and its merge to core will have "tidying" as an integral feature.

Thus, the disabletidy parameter to action=parse is being deprecated and
will be removed at some point in the future. Clients should stop using the
parameter and begin using tidied HTML output.

This change should be deployed to Wikimedia wikis with 1.32.0-wmf.24 or
later, see https://www.mediawiki.org/wiki/MediaWiki_1.32/Roadmap for a
schedule.

[1]: https://phabricator.wikimedia.org/T198214
[2]: https://phabricator.wikimedia.org/tag/parsoid-php/

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] Deprecation of the disabletidy parameter to action=parse

[Brad Jorsch (Anomie)]

Now that MediaWiki has a pure-PHP tidying implementation, we are
deprecating non-tidy output.[1] Further, the future rewrite of Parsoid in
PHP[2] and its merge to core will have "tidying" as an integral feature.

Thus, the disabletidy parameter to action=parse is being deprecated and
will be removed at some point in the future. Clients should stop using the
parameter and begin using tidied HTML output.

This change should be deployed to Wikimedia wikis with 1.32.0-wmf.24 or
later, see https://www.mediawiki.org/wiki/MediaWiki_1.32/Roadmap for a
schedule.

[1]: https://phabricator.wikimedia.org/T198214
[2]: https://phabricator.wikimedia.org/tag/parsoid-php/

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

Re: [Mediawiki-api] Page's Intro Is Empty In the API Response

[Brad Jorsch (Anomie)]

It's probably a side effect of a change in MediaWiki that went out this
week. Try purging the pages with the empty response.

On Thu, Sep 6, 2018 at 1:06 PM, Tal Barda <412tal...@gmail.com> wrote:

> Hi there!
>
> I'm trying to generate 10 random articles in Hebrew using this request:
>
> https://he.wikipedia.org/w/api.php?format=xml=
> query=random=10=0=extracts&
> explaintext
>
> As you can see, I'd like to get their intro, but some of the articles'
> intro is empty in the API response, even though it's not empty in Wikipedia
> itself.
>
> I have tried to make the same request in English, and I the problem didn't
> happen.
>
> This is the first time I encounter this weird problem after making this
> request in my App for over a year... Am I missing something? Is there any
> new information that I should add to the request or it's just a bug?
>
> Thanks!
>
> ___
> Mediawiki-api mailing list
> Mediawiki-api@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
>


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] Deprecations and changes in API action=compare

[Brad Jorsch (Anomie)]

In preparation for multi-content revisions (MCR), we've made[1] several
changes to action=compare. These changes should be deployed to Wikimedia
wikis with 1.32.0-wmf.19 or later. The changes should also be available on
the Beta Cluster[2] soon for testing.

*== Supplying content using templated parameters ==*

For MCR, when specifying content (as with the `fromtext` and `totext`
parameters) we need the ability to specify content for each "slot" in the
page. The way this works for action=compare is that (1) the base revision
is determined using the parameters that identify the page and/or revision
(`fromtitle`/`totitle`, `fromrev`/`torev`, and so on), then (2) the new
`fromslots`/`toslots` parameter specifies which slots are being changed,
and then (3) new parameters for each value of `fromslots`/`toslots` specify
the content for each of those slots.

In the API help, these new parameters for each value of
`fromslots`/`toslots` are described as "templated parameters" and have a
placeholder in their names. Where the help describes "totext-{slot}", it's
meaning that if you supply "toslots=foo|bar" then there would be
corresponding parameters "totext-foo" and "totext-bar" to supply the text
for those two slots.

In Special:ApiSandbox, input fields for "totext-foo" and "totext-bar" will
appear when you enter those value for "toslots".

In the future templated parameters will be introduced for action=edit and
action=parse as well, and other modules as the need arises.

*== Deprecations and changes in action=compare ==*

The following parameters are deprecated, with replacements as indicated.

   - `fromtext` is replaced with `fromtext-main` with `fromslots=main`.
   - `fromcontentmodel` is replaced with `fromcontentmodel-main` with
   `fromslots=main`.
   - .`fromcontentformat` is replaced with `fromcontentformat-main` with
   `fromslots=main`.
   - `totext` is replaced with `totext-main` with `toslots=main`.
   - `tocontentmodel` is replaced with `tocontentmodel-main` with
   `toslots=main`.
   - .`tocontentformat` is replaced with `tocontentformat-main` with
   `toslots=main`.

The `fromsection` and `tosection` parameters are also deprecated with no
direct replacement. The intended use case for these parameters was to
simulate a diff of a section edit, by supplying the edited section's text
as `totext` and supplying `fromsection` to extract just the section being
edited from the current revision. This use case is now supported by
specifying `totext-main` as the edited section's text and supplying
`tosection-main` to identify the section being edited, which will be
combined into the existing content as for a section edit. This will result
in a diff more closely matching that returned for a section edit from the
web UI with respect to line numbers and context lines.

By default action=compare will return one HTML blob combining the diffs of
all slots, much as is shown in the web UI. The new `slots` parameter may be
used to get separate HTML blobs for each slot's diff and to limit which
slots' diffs are returned..

*== Other notes ==*

Note that the already-deprecated[3] diffing parameters to revision-related
modules, such as the rvdifftotext parameter to action=query=revisions,
will not be updated for MCR. Code using these parameters should be updated
to use action=compare instead.

[1]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/448160
[2]: e.g. https://en.wikipedia.beta.wmflabs.org/w/api.php?modules=compare
[3]:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2017-June/000134.html


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api] [Mediawiki-api-announce] Deprecations and changes in API action=compare

[Brad Jorsch (Anomie)]

In preparation for multi-content revisions (MCR), we've made[1] several
changes to action=compare. These changes should be deployed to Wikimedia
wikis with 1.32.0-wmf.19 or later. The changes should also be available on
the Beta Cluster[2] soon for testing.

*== Supplying content using templated parameters ==*

For MCR, when specifying content (as with the `fromtext` and `totext`
parameters) we need the ability to specify content for each "slot" in the
page. The way this works for action=compare is that (1) the base revision
is determined using the parameters that identify the page and/or revision
(`fromtitle`/`totitle`, `fromrev`/`torev`, and so on), then (2) the new
`fromslots`/`toslots` parameter specifies which slots are being changed,
and then (3) new parameters for each value of `fromslots`/`toslots` specify
the content for each of those slots.

In the API help, these new parameters for each value of
`fromslots`/`toslots` are described as "templated parameters" and have a
placeholder in their names. Where the help describes "totext-{slot}", it's
meaning that if you supply "toslots=foo|bar" then there would be
corresponding parameters "totext-foo" and "totext-bar" to supply the text
for those two slots.

In Special:ApiSandbox, input fields for "totext-foo" and "totext-bar" will
appear when you enter those value for "toslots".

In the future templated parameters will be introduced for action=edit and
action=parse as well, and other modules as the need arises.

*== Deprecations and changes in action=compare ==*

The following parameters are deprecated, with replacements as indicated.

   - `fromtext` is replaced with `fromtext-main` with `fromslots=main`.
   - `fromcontentmodel` is replaced with `fromcontentmodel-main` with
   `fromslots=main`.
   - .`fromcontentformat` is replaced with `fromcontentformat-main` with
   `fromslots=main`.
   - `totext` is replaced with `totext-main` with `toslots=main`.
   - `tocontentmodel` is replaced with `tocontentmodel-main` with
   `toslots=main`.
   - .`tocontentformat` is replaced with `tocontentformat-main` with
   `toslots=main`.

The `fromsection` and `tosection` parameters are also deprecated with no
direct replacement. The intended use case for these parameters was to
simulate a diff of a section edit, by supplying the edited section's text
as `totext` and supplying `fromsection` to extract just the section being
edited from the current revision. This use case is now supported by
specifying `totext-main` as the edited section's text and supplying
`tosection-main` to identify the section being edited, which will be
combined into the existing content as for a section edit. This will result
in a diff more closely matching that returned for a section edit from the
web UI with respect to line numbers and context lines.

By default action=compare will return one HTML blob combining the diffs of
all slots, much as is shown in the web UI. The new `slots` parameter may be
used to get separate HTML blobs for each slot's diff and to limit which
slots' diffs are returned..

*== Other notes ==*

Note that the already-deprecated[3] diffing parameters to revision-related
modules, such as the rvdifftotext parameter to action=query=revisions,
will not be updated for MCR. Code using these parameters should be updated
to use action=compare instead.

[1]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/448160
[2]: e.g. https://en.wikipedia.beta.wmflabs.org/w/api.php?modules=compare
[3]:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2017-June/000134.html


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Cannot create page

[Brad Jorsch (Anomie)]

On Fri, Aug 17, 2018 at 11:45 AM, Matthew H. Cahn  wrote:
> r = requests.get(baseUrl, params=params)
>
> print(r)
> print(r.text)
>
> params = {'action': 'edit',
>   'title': 'TestPage3',
>   'summary': 'Test summary',
>   'text': 'article content',
>   'token': '+\\'}

You should be using the token in the response (r) here, not
hard-coding the current anonymous-user "+\" token.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation

___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Some missing parameter error codes are changing

[Brad Jorsch (Anomie)]

It was noticed[1] that the error messages for "missing parameter" errors
were not including the module prefix, for example a query to
action=query=search could complain that the "search" parameter must be
set when the actual parameter name is "srsearch". This extends to the error
code, which in this example is "nosearch" rather than "nosrsearch".

This is now fixed, and should be deployed to Wikimedia sites with MediaWiki
1.32.0-wmf.15 and later. See
https://www.mediawiki.org/wiki/MediaWiki_1.32/Roadmap for a schedule.

If your client is checking for specific missing parameter error codes, it
may need to be updated for the changed codes.

[1]: https://phabricator.wikimedia.org/T200155

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Passing too many values for a multi-valued parameter waring is becoming an error

[Brad Jorsch (Anomie)]

The API has traditionally ignored values beyond the allowed limit,
returning a warning for this situation since 2008(!). It's long past time
for this error situation to actually raise an error, as requested in
https://phabricator.wikimedia.org/T41936.

This is happening in https://gerrit.wikimedia.org/r/433742. It should be
deployed to Wikimedia wikis with 1.32.0-wmf.6 or later, see
https://www.mediawiki.org/wiki/MediaWiki_1.32/Roadmap for the schedule.

Logs indicate that few clients on Wikimedia wikis are hitting the warning.
You can check your client by seeing if you're receiving a "Too many values
supplied for parameter" warning, or by using Special:ApiFeatureUsage for
your client's user agent and looking for a "too-many-X" code.

If your client is affected, the solution is to divide the values into
batches of the appropriate size. Generally the limit is 50 values for
clients without the apihighlimits right and 500 for clients with that
right. The limits for any particular parameter are documented in the
auto-generated help and are available in machine-readable format via
action=paraminfo.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] MediaWiki API v1.19.7; edit token request; empty response

[Brad Jorsch (Anomie)]

On Tue, May 1, 2018 at 3:38 PM, tom schulze <tom.schu...@posteo.de> wrote:

> I am trying to receive an edit token for the MediaWiki 1.19 API,
>

1.19 is really old. If this is your own wiki, you really should upgrade. If
it's someone else's, you should encourage them to upgrade.


> however all I get is an empty response.
>
> I created a gist
> <https://gist.github.com/tomschulze/16fcdf8b88f285ab29365e4e558cb5f5>
> with my python code.
>
You're missing parameters in params_edit_token. Try adding 'titles' with at
least one title (doesn't have to exist) and 'intoken' with value 'edit'.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Limit The Results Number of Each Page In The API Response

[Brad Jorsch (Anomie)]

On Fri, Mar 23, 2018 at 6:18 AM, Tal Barda <412tal...@gmail.com> wrote:

> My problem is with the "lhlimit" parameter. I'd like to get 10 results for
> each page, but it's currently gives my 10 results for ALL of the pages,
> which means I have to call "lhcontinue" each time.
>
> Is it possible to get 10 results for each page when asking for multiple
> pages?
>

No. You can get more results total by increasing lhlimit, but trying to
limit results per page gets complicated in the API module's code, and would
be even more complicated to provide continuation.


>  Or should I make a different call for each article in order to achieve
> this?
>

That would be one way to do it.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Articles of WikiProject Democratic Republic of the Congo

[Brad Jorsch (Anomie)]

On Sat, Feb 17, 2018 at 4:33 PM, Brian Wolff <bawo...@gmail.com> wrote:

> https://en.wikipedia.org/w/api.php?action=query=
> categorymembers=Category:WikiProject_Democratic_Republic_of_the_
> Congo_articles=max seems to work fine.
>
> If i were to guess why its not on list=projectpages, id say that
> wikiproject democratic republic of the congo is not a full on wikiproject
> itself but just a subproject of wikiproject africa.
>

That would be the case. list=projectpages depends on something using the
{{#assessment:}} parser function to "tag" the page with the project. On
enwiki this is typically done by Template:WPBannerMeta (specifically,
Template:WPBannerMeta/core), but that template (currently) just does it for
the main project, not for task forces.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Files moved to Commons

[Brad Jorsch (Anomie)]

On Fri, Jan 26, 2018 at 9:16 AM, Victor Shepelev
<zverok.offl...@gmail.com> wrote:
>
> Is there a way to tell actually non-existent files from files that are 
> included from commons, through API?


Use prop=imageinfo and look at the "imagerepository". If it's not the
empty string, the image exists. If it's "local" then the image exists
locally. Otherwise, it's on a foreign repo such as Commons. On any WMF
wiki except test2wiki, Commons (with the value "shared") is currently
the only non-local possibility.

https://en.wikipedia.org/w/api.php?action=query=File:Logo_of_the_Verkhovna_Rada_of_Ukraine.svg=imageinfo


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation

___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Whitespace-only values to multi-valued parameters will no longer be considered empty sets

[Brad Jorsch (Anomie)]

There's an inconsistency in the handling of multi-value parameters where if
you pass a value consisting of only whitespace[1] it will be interpreted as
an empty set rather than as a single value consisting of whitespace. For
example, https://www.mediawiki.org/w/api.php?action=query= correctly
handles the query as specifying no titles, but
https://www.mediawiki.org/w/api.php?action=query=%20 is also treated
as specifying no titles rather than specifying a title consisting of a
space character.

With Gerrit change 405609,[2] the behavior will be changed so that the
latter query will behave more like
https://www.mediawiki.org/w/api.php?action=query=_ in reporting that
the supplied title is invalid. The plan is that this will be deployed to
WMF wikis with 1.31.0-wmf.20 on February 6–8, see
https://www.mediawiki.org/wiki/MediaWiki_1.31/Roadmap for the schedule.

Passing an empty string as the value of a multi-valued parameter will
continue to be treated as a set of zero elements rather than a one-element
set containing the empty string.

Most clients should handle this change without major issue, as the
resulting response is consistent with the response when any other invalid
title is submitted. Clients that want to continue treating whitespace-only
input as no input should begin checking for whitespace-only input before
submitting it to the API.

[1]: Specifically: spaces (U+0020), tabs (U+0009), line feeds (U+000A), and
carriage returns (U+000D).
[2]: https://gerrit.wikimedia.org/r/#/c/405609/

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] New warning due to removal of nonfunctional tgprop=name from action=query=tags

[Brad Jorsch (Anomie)]

The tags query module has a tgprop parameter to specify which properties of
the tag should be returned. One of these properties was 'name', but the
name was always included in the response regardless of whether this
property was included in tgprop.

Since most uses aren't specifying 'name' but we can assume clients are
depending on the name being included (since there's otherwise no way to
identify which tag is which), we've removed the nonfunctional 'name' as a
valid option for tgprop. This will result in a warning that 'name' is not a
valid value for tgprop for those few clients that are specifying 'name'
there.

This change will not affect the functionality of any clients unless the new
warning somehow breaks them. It should be deployed to WMF wikis with
1.31.0-wmf.18 or later. Clients can safely stop specifying 'name' in tgprop
immediately, though, since it doesn't do anything.

For further information, see https://phabricator.wikimedia.org/T185058.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Question about 'Api-User-Agent'

[Brad Jorsch (Anomie)]

On Thu, Dec 7, 2017 at 11:17 AM, Nikola I.  wrote:

> About: xhr.setRequestHeader( 'Api-User-Agent', 'Example/1.0' );
>

Your problem here has nothing to do with this header. Also, you'd want to
specify something more identifying than "Example/1.0".


> Failed to load https://en.wikipedia.org/w/api.php?action=query=
> links=json=Bulgaria=JSON_CALLBACK:
> Response to preflight request doesn't pass access control check:
> No 'Access-Control-Allow-Origin' header is present on the requested
> resource.
> Origin 'https://s.codepen.io' is therefore not allowed access.
>

The API only responds with CORS headers if the URL contains an "origin"
parameter. For accessing from an external site like codepen.io, you'd want
to specify "origin=*".

And you would not want to use the "callback" parameter in that situation,
"callback" is intended for accessing a remote resource by adding a 

[Mediawiki-api] [Mediawiki-api-announce] Minor BREAKING CHANGE in handling of pltitles, tltemplates, clcategories, and imimages parameters with invalid titles

[Brad Jorsch (Anomie)]

Previously, if none of the values supplied for the pltitles, tltemplates,
clcategories, or imimages parameters to prop=links, prop=templates,
prop=categories, or prop=images were valid titles, the parameter would be
ignored and all links, templates, categories, or images would be returned.

With the merge of Gerrit change 347879,[1] this situation will result in no
links, templates, categories, or images being returned, as none match the
invalid titles supplied.

Note that submitting an empty value for one of these parameters will
continue to ignore the parameter and return all links, templates,
categories, or images, since this seems to be relatively common practice.

[1]: https://gerrit.wikimedia.org/r/#/c/347879/

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] Minor BREAKING CHANGE in handling of pltitles, tltemplates, clcategories, and imimages parameters with invalid titles

[Brad Jorsch (Anomie)]

Previously, if none of the values supplied for the pltitles, tltemplates,
clcategories, or imimages parameters to prop=links, prop=templates,
prop=categories, or prop=images were valid titles, the parameter would be
ignored and all links, templates, categories, or images would be returned.

With the merge of Gerrit change 347879,[1] this situation will result in no
links, templates, categories, or images being returned, as none match the
invalid titles supplied.

Note that submitting an empty value for one of these parameters will
continue to ignore the parameter and return all links, templates,
categories, or images, since this seems to be relatively common practice.

[1]: https://gerrit.wikimedia.org/r/#/c/347879/

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

Re: [Mediawiki-api] "see also" parser strange output

[Brad Jorsch (Anomie)]

On Wed, Aug 23, 2017 at 10:32 AM, Max Vlasov <max.vla...@gmail.com> wrote:

> I'm using two step approach to retrieve "see also" section links from
> articles by retrieving sections and using the section index for links
> action.
> Today I noticed that for the article "Synchronous programming language"
> this gives unexpected results.
>
> The page
>   https://en.wikipedia.org/w/api.php?action=parse=
> sections=Synchronous%20programming%20language=xml
>
> returns
> ...  
> and the following query
>
> https://en.wikipedia.org/w/api.php?action=parse=
> links=Synchronous%20programming%20language=4=xml
>
> gives a long list of links very different to the actual correct list shown
> in the wikipedia article. Other usage of the same algorithm with other
> articles works correctly.
>
> Is this a bug?
>

No, it's not a bug. The "See also" section on that article also happens to
contain the navbox, so you're getting all the links from the navbox as well
as the links you expect.

Most articles don't have this problem because the "References" and
"External links" sections usually come after "See also", as described at
https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Layout#ORDER. So
the navboxes would wind up being part of those sections instead.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Q = Bot and move without redirect

[Brad Jorsch (Anomie)]

On Tue, Jun 27, 2017 at 12:17 PM, Kai Sommer <som...@leibniz-gei.de> wrote:

>   ["rights"]=>
>   array(17) {
> [0]=>
> string(13) "autoconfirmed"
> [1]=>
> string(17) "editsemiprotected"
> [2]=>
> string(14) "nominornewtalk"
> [3]=>
> string(10) "autopatrol"
> [4]=>
> string(8) "writeapi"
> [5]=>
> string(4) "read"
> [6]=>
> string(10) "createpage"
> [7]=>
> string(10) "createtalk"
> [8]=>
> string(4) "move"
> [9]=>
> string(13) "move-subpages"
> [10]=>
> string(18) "move-rootuserpages"
> [11]=>
> string(18) "move-categorypages"
> [12]=>
> string(4) "edit"
> [13]=>
> string(9) "minoredit"
> [14]=>
> string(5) "purge"
>     [15]=>
> string(15) "applychangetags"
> [16]=>
> string(10) "changetags"
>   }
>

That list of rights looks like you're using OAuth or BotPasswords for the
bot login, which means you probably did not select a grant that includes
the 'suppressredirect' right.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Q = Bot and move without redirect

[Brad Jorsch (Anomie)]

On Tue, Jun 27, 2017 at 11:10 AM, Kai Sommer <som...@leibniz-gei.de> wrote:

> # the problem
> I can move the page. − But the parameter "noredirect" (value = 1) seems to
> be ignored. So every moved page exists with the redirect after moving …
>
> # my guess
> I guess there is something not correct with the (implementation of the)
> user right "suppressredirect" (which is required for using the API
> parameter "noredirect"; see [0]).
>

It works fine when I try it on my local test wiki. Although I'm using
MediaWiki master rather than 1.27.3.


> # one more point
> If I query the API (api.php) for the moved page with the parameters
> * prop=contributors
> * titles=$MYPAGENAME
> * pcrights=suppressrevision
>

suppressrevision and suppressredirect are different rights.
prop=contributors is also a poor method to check rights,
action=query=allusers=suppressredirect would make much more
sense. Or, while logged in as your bot, try
action=query=userinfo=groups|rights.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] DEPRECATION: prop=revisions diff and parse parameters

[Brad Jorsch (Anomie)]

In the action API, there are two ways to parse a page/revision: using
action=parse, or using the rvparse parameter to action=query=revisions.
Similarly, there are two ways to get a diff: using action=compare, or using
parameters such as rvdiffto to action=query=revisions. And then
there's action=expandtemplates versus the rvexpandtemplates parameter to
prop=revisions. This is a somewhat annoying bit of code duplication.

Further, the prop=revisions versions of these features have somewhat
strange behavior. rvparse forces rvlimit=1. rvdiffto and related parameters
will sometimes output "notcached" with no way to directly handle the
situation.

This, the 'rvdifftotext', 'rvdifftotextpst', 'rvdiffto',
'rvexpandtemplates', 'rvgeneratexml', 'rvparse', and 'rvprop=parsetree'
parameters to prop=revisions are all deprecated, as are the similarly named
parameters to prop=deletedrevisions, list=allrevisions, and
list=alldeletedrevisions.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Backlinks list order

[Brad Jorsch (Anomie)]

On Sat, Jun 3, 2017 at 3:24 AM, Max Vlasov <max.vla...@gmail.com> wrote:

> Are there any other reason to use linkshere instead of backlinks?
>

linkshere can take multiple titles as input.

On Sat, Jun 3, 2017 at 3:58 AM, Martin Domdey <anima...@gmx.net> wrote:

> Do we get data from different wikibase table columns using API linkshere
> or using API backlinks?
>

Neither returns "wikibase table columns". They both return data from the
MediaWiki pagelinks table.


> Why is the one "less complicated and hacky" than the other?
>

backlinks does multiple queries to do some sort of redirect resolution, but
at the same time is limited to a single title parameter. Its queries could
probably use some improvement.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Backlinks list order

[Brad Jorsch (Anomie)]

On Fri, Jun 2, 2017 at 11:25 AM, Max Vlasov <max.vla...@gmail.com> wrote:

> The docs say backlinks are sorted by titles (https://www.mediawiki.org/
> wiki/API:Backlinks  "Ordered by linking page title").
>

That's not correct. Fixed the doc.

They're actually ordered by linking pageid if you don't specify multiple
values for blnamespace, or by namespace then pageid if you do.

It may be better to use prop=linkshere rather than list=backlinks. That
module is much less complicated and hacky.


> So is it possible to implement other kind of sort, for example, something
> like PageRank for backlinks, so the links are sorted by the number of links
> coming to them?
>

No. The database structure doesn't allow efficient querying with any
ordering other than the ordering used here. Number of incoming links in
particular would be extremely slow, or with some rather significant changes
to the code and database it might be able to be improved to merely being
very slow.

BTW, Google's "PageRank" is, as far as I know, more complicated than just
"number of incoming links".


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Interpretation of rvstartid and rvendid parameters to prop=revisions

[Brad Jorsch (Anomie)]

Most of the time, the ordering implied by revision ID number and the
ordering implied by revision timestamp are the same. Differences occur
mainly when revisions are imported from another wiki, however there may be
other situations that can cause this.

The database queries that were formerly used to handle the rvstartid and
rvendid parameters were found to be very inefficient.[1] As of Gerrit
change 349448,[2] these parameters are now equivalent to using the
timestamps of the corresponding revisions for rvstart and rvend.

This change should be deployed to WMF wikis with 1.30.0-wmf.1, see
https://www.mediawiki.org/wiki/MediaWiki_1.30/Roadmap for the schedule.

 [1]: https://phabricator.wikimedia.org/T163495#3200490
 [2]: https://gerrit.wikimedia.org/r/#/c/349448/

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Why are coordinates not listed for some pages in API query?

[Brad Jorsch (Anomie)]

On Mon, May 1, 2017 at 7:14 PM, Bjoern Hassler <bjohas...@gmail.com> wrote:

> not sure whether this is an API issue, or something to do with the way
> coordinates are stored.
>

Neither.


> If you look at this query, you'll see that for some of the pages
> coordinates are listed, for others they are not:
>
> https://de.wikipedia.org/w/api.php?action=query=
> coordinates=categorymembers=Kategorie:Ur-_und_Fr%C3%
> BChgeschichte_(Menorca)=500
> <https://de.wikipedia.org/w/api.php?action=query=coordinates=categorymembers=Kategorie:Ur-_und_Fr%C3%BChgeschichte_%28Menorca%29=500>
>

That's because you're leaving colimit at its default of 10 and there are
more than 10 pages with coordinates in the request, so you'll need to use
query continuation to fetch the rest of the data and merge it in. See
https://www.mediawiki.org/wiki/API:Query#Continuing_queries. You might also
specify a larger limit, e.g. colimit=500 or colimit=max, to reduce the need
for continuation.

Another thing to watch for is that there are two types of coordinates,
"primary" and "secondary". By default, only primary coordinates are
returned. If you need secondary coordinates as well, you'll need to
specify coprimary=all
in your request.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] Proposal to deprecate parsing and diffs in the action API action=query=revisions

[Brad Jorsch (Anomie)]

TL;DR: I'm proposing deprecating a bunch of parameters. See
https://phabricator.wikimedia.org/T164106.

In the action API, there are two ways to parse a page/revision: using
action=parse, or using the rvparse parameter to action=query=revisions.
Similarly, there are two ways to get a diff: using action=compare, or using
parameters such as rvdiffto to action=query=revisions. And then
there's action=expandtemplates versus the rvexpandtemplates parameter to
prop=revisions. This is a somewhat annoying bit of code duplication.

Further, the prop=revisions versions of these features have somewhat
strange behavior. rvparse forces rvlimit=1. rvdiffto and related parameters
will sometimes output "notcached" with no way to directly handle the
situation.

So, I propose deprecating all of these parameters. The parameters that
would be deprecated are the 'rvdifftotext', 'rvdifftotextpst', 'rvdiffto',
'rvexpandtemplates', 'rvgeneratexml', 'rvparse', and 'rvprop=parsetree'
parameters to prop=revisions, and the similarly named parameters to
prop=deletedrevisions, list=allrevisions, and list=alldeletedrevisions.

Following the normal action API deprecation policy, they'd output warnings
but would continue to function until usage drops sufficiently or until it
becomes too much trouble to fix them, and they wouldn't receive new feature
development.
If anyone would object to this plan, please reply at
https://phabricator.wikimedia.org/T164106, or here if you really hate
Phabricator. If there aren't major objections, I'll probably do the
deprecation in the next week or two. Thanks.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] How does yourdictionary obtains structured information from Wiktionary?

[Brad Jorsch (Anomie)]

On Mon, Apr 17, 2017 at 10:35 AM, Furkan Gözükara <monstermmo...@gmail.com>
wrote:

> So i wonder, are there any APIetc that does provide structured
> information? Or they have written their own custom crawler and parser?
>

There's an experimental REST API, see
https://en.wiktionary.org/api/rest_v1/#!/Page_content/get_page_definition_term



-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Wikipedia most viewed pages data

[Brad Jorsch (Anomie)]

On Thu, Apr 6, 2017 at 2:19 PM, Anandroid Inc <anandrd...@gmail.com> wrote:

> Thanks for the great api provided for all the wiki info.
> I am looking for a combination of right parameters which will return me
> most viewed pages with the page url, article snippet, thumbnail image url.
> Hope you can help with this.
>

With the action API, you can use generator=mostviewed to generate the
pages, and prop=info|extracts|pageimages to fetch the requested properties.
For example, using the API Sandbox,

https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query=json=extracts%7Cinfo%7Cpageimages=mostviewed=max=1=url=max


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] Change in behavior for list=allpages=(redirects|nonredirects)

[Brad Jorsch (Anomie)]

For performance reasons,[1] when "miser mode" is enabled, as it is on WMF
wikis, queries to list=allpages using apfilterredir=redirects and
apfilterredir=nonredirects may begin returning fewer than the requested
aplimit results before continuation. In extreme cases, zero results may be
returned.

This change[2] has just been made and will be deployed in the next few
hours so Special:AllPages may be re-enabled.

This is not classified as a breaking change since the API has reserved the
right (since 2009[3] if not earlier) to do this sort of thing as it may
become necessary.

[1]: https://phabricator.wikimedia.org/T160916
[2]: https://gerrit.wikimedia.org/r/#/c/343681/
[3]: https://phabricator.wikimedia.org/rSVN46845

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] [discovery] Some Issues on API:Opensearch

[Brad Jorsch (Anomie)]

On Thu, Feb 23, 2017 at 10:42 PM, b...@yahoo-inc.com <b...@yahoo-inc.com>
wrote:

> The usage of Parsing wikiText API is expected to be released in mid March,
> and is going to send 900 rps at peak plus 150 rps in average.
> Please let me know if there's any concern or advice.
>

You'd probably do best to contact the Wikimedia Technical Operations team
with a question like that.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Passwords and other sensitive fields for authentication must be in the POST body

[Brad Jorsch (Anomie)]

As was previously announced, passing the lgpassword or lgtoken parameters
to action=login in the query string rather than the POST body will begin to
return an error starting with 1.29.0-wmf.13. See
https://www.mediawiki.org/wiki/MediaWiki_1.29/Roadmap for the deployment
schedule.

On Mon, Oct 31, 2016 at 2:44 PM, Brad Jorsch (Anomie) <bjor...@wikimedia.org
> wrote:

> Over the past 30 days, there has been exactly one hit to
> action=clientlogin with sensitive data in the query string, and none to
> action=createaccount, action=linkaccount, and action=changeauthenticationdata.
> Beginning in 1.29.0-wmf.1 (to be deployed this week) these actions will now
> begin throwing errors if sensitive fields are included in the query string.
>
> Over the past 30 days, logins have been attempted via action=login for 28
> different user names[1] with sensitive data (lgpassword or lgtoken) in the
> query string. This will continue to work for now; my current plan is to
> turn that warning into an error on February 15, 2017.
>
>
> [1]: I can't post the list publicly at this time. If you want to know if
> you're one of the 28, put your user agent into https://meta.wikimedia.org/
> wiki/Special:ApiFeatureUsage and look for "login-params-in-query-string".
>
>
> On Fri, Aug 19, 2016 at 3:24 PM, Brad Jorsch (Anomie) <
> bjor...@wikimedia.org> wrote:
>
>> For improved safety, passwords and other sensitive fields for
>> authentication should not be included in the request URI during a POST.
>> Instead, they should be in the POST body where they are less likely to be
>> included in log files. With the merge of Gerrit change 305545,[1] the API
>> will now produce a warning if such fields are detected in the URI. This
>> should be deployed to WMF wikis with 1.28.0-wmf.16, see
>> https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.
>>
>> This affects the following modules and fields:
>> * action=login: 'lgpassword'
>> * action=clientlogin, action=createaccount, action=linkaccount, and
>> action=changeauthenticationdata: Any fields reported as "sensitive" by
>> action=query=authmanagerinfo or by UI or REDIRECT responses.
>> Currently, this affects the 'password' and 'retype' fields.
>>
>> The 'lgtoken' field for action=login will now also issue a warning if
>> placed in the request URI. The error code for other tokens being in the
>> request URI has changed from 'mustposttoken' to 'mustpostparams'.
>>
>> To check if your client's user agent is detected making such submissions,
>> you can also use ApiFeatureUsage[2] and look for
>> '-params-in-query-string' once 1.28.0-wmf.16 is rolled out to
>> wikis your client is logging in to.
>>
>> It is planned that these warnings will be changed to errors during 1.29.
>> Let's avoid having a repeat of T142155,[3] update your code ASAP instead of
>> waiting until it breaks. Thanks.
>>
>>  [1]: https://gerrit.wikimedia.org/r/#/c/305545/
>>  [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
>>  [3]: https://phabricator.wikimedia.org/T142155
>>
>> --
>> Brad Jorsch (Anomie)
>> Senior Software Engineer
>> Wikimedia Foundation
>>
>
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
>



-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Localized (translated) version of sections

[Brad Jorsch (Anomie)]

On Fri, Jan 27, 2017 at 10:57 AM, Max Vlasov <max.vla...@gmail.com> wrote:

> Is there a way to get a localized version of section names of an article,
> for example "See also"?  Currently my question is related to section names,
> but in general I would like to get language equivalent for other semantic
> entities. Are there docs about such things? I tried to find but failed.
>

For section names, no. There's nothing special about the title of the "See
also" section versus any other section on any other page, unless the wiki
is specifically loading i18n messages for section headings like Commons
does.

For interface messages, you'd need to determine the message key. Then you
can query them from the API (action=query=allmessages) or you can look
on the wiki in the MediaWiki namespace. For example, the text of the "edit"
tab in the Vector skin comes from the message 'vector-view-edit', so if you
want to see what that is in German on your wiki you could check
MediaWiki:vector-view-edit/de[1] or
api.php?action=query=allmessages=vector-view-edit=de.[2]


 [1]: https://en.wikipedia.org/wiki/MediaWiki:Vector-view-edit/de
 [2]:
https://en.wikipedia.org/w/api.php?action=query=allmessages=vector-view-edit=de

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Some Issues on API:Opensearch

[Brad Jorsch (Anomie)]

On Wed, Jan 25, 2017 at 2:09 AM, <b...@yahoo-inc.com> wrote:

> While I was developing some services based on API:Opensearch, I found that
> the response of the same url request can be either Simplified Chinese or
> Traditional Chinese. To be more specific, I would love to know how can I
> determine the response language form from API layer ( Or other factors that
> may have impact ) ? Since the document of API:Opensearch doesn't seem to
> take language into consideration,
>

The OpenSearch Suggestions extension specification[1] does not allow for
returning additional metadata such as language with the response. You may
want to look at the prefixsearch query module[2] instead which allows for
returning the same results in a different format, although I don't know the
details of how language variants are handled in the search output.


 [1]:
http://www.opensearch.org/Specifications/OpenSearch/Extensions/Suggestions/1.1
 [2]: https://www.mediawiki.org/wiki/API:Prefixsearch

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Client-login attemps unsuccesful

[Brad Jorsch (Anomie)]

On Thu, Jan 19, 2017 at 4:01 PM, Gergo Tisza <gti...@wikimedia.org> wrote:

> On Thu, Jan 19, 2017 at 7:25 AM, Brad Jorsch (Anomie) <
> bjor...@wikimedia.org> wrote:
>
>> Because backslash is the escape character in JSON strings, and so needs
>> to be escaped to represent an actual backslash. If your JSON decoder is not
>> properly transforming that token into a native string ending with a single
>> backslash then your JSON decoder is fundamentally broken and should
>> probably be replaced.
>>
>
> I wonder if it would be worth for the API to issue a more specific warning
> when a token has been submitted but it does not have the format that tokens
> normally do. Something like "you submitted the token abc1234 \ but you
> were expected to submit the token abc1234+\ which in the raw request
> should look like abc1234%2B%5C" might make it easier for people to figure
> out on their own what they are doing wrong.
>

OTOH, every check of this sort we add is more code complexity. And I note
if you're using multipart/form-data, it shouldn't look like "abc1234%2B%5C".


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Disabling the API without disabling search suggestions?

[Brad Jorsch (Anomie)]

https://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions
comes to mind here.

You might try to hack something up by blacklisting certain API modules with
ApiCheckCanExecute and the like, but such things aren't really supported.
$wgDisableAPI itself probably doesn't make much sense anymore and may
eventually be removed.

On Mon, Jan 9, 2017 at 12:35 PM, Daniel Barrett <d...@cimpress.com> wrote:

> Max Semenik <maxsem.w...@gmail.com> asks:
> >Why are you disabling the API in the first place? Maybe, there's a better
> solution?
>
> I am creating a wiki (for a specialized project) that lets anonymous users
> read articles, but that is all they can do. They cannot log in, cannot view
> article history, cannot view Special Pages, or use any other wiki features.
> Basically, it's a wiki for a few writers and thousands of anonymous
> readers. MediaWiki is a great platform because the articles are highly
> interlinked like an encyclopedia.
>
> Unfortunately, when the API is enabled, anybody can still access all the
> hidden information (article history, etc.). That's why I want to block the
> API. But then I kill search suggestions. :-)
>
> I'm grateful for any advice you may have. Thank you.
> DanB
>
> ___
> Mediawiki-api mailing list
> Mediawiki-api@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>



-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] [Mediawiki-api-announce] DEPRECATION: Use of action=purge via GET is deprecated

[Brad Jorsch (Anomie)]

Correction: that's the deployment on February 7–9. I looked at the wrong
page of my calendar.

Sorry for the noise.

On Wed, Dec 28, 2016 at 11:11 PM, Brad Jorsch (Anomie) <
bjor...@wikimedia.org> wrote:

> After reviewing usage of this deprecated feature, I've directly notified
> the few remaining major users on their talk pages and plan to change the
> deprecation to an error in time for the deployment on February 3–5, 2017.
>
> On Wed, Sep 14, 2016 at 12:43 PM, Brad Jorsch (Anomie) <
> bjor...@wikimedia.org> wrote:
>
>> To operate correctly, action=purge needs to write to the database, which
>> means it should be done using a POST rather than a GET request.
>>
>> As of Gerrit change 310560,[1] action=purge will begin emitting a warning
>> when used via GET. This should be deployed to WMF wikis with 1.28.0-wmf.20,
>> see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the
>> schedule.
>>
>> Clients that use action=paraminfo to determine whether to use GET or POST
>> for an action should automatically switch to POST; any others should
>> manually switch to using POST for this action as soon as possible.
>>
>> To check if your client's user agent is detected making such submissions,
>> you can also use ApiFeatureUsage[2] and look for 'purge-via-GET' once
>> 1.28.0-wmf.20 is rolled out to wikis your client is using.
>>
>> It is planned that this warning will be changed to an error during 1.29.
>> Let's avoid having a repeat of T142155,[3] update your code ASAP instead of
>> waiting until it breaks. Thanks.
>>
>>  [1]: https://gerrit.wikimedia.org/r/#/c/310560/
>>  [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
>>  [3]: https://phabricator.wikimedia.org/T142155
>>
>> --
>> Brad Jorsch (Anomie)
>> Senior Software Engineer
>> Wikimedia Foundation
>>
>
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
>



-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] [Mediawiki-api-announce] DEPRECATION: Use of action=purge via GET is deprecated

[Brad Jorsch (Anomie)]

After reviewing usage of this deprecated feature, I've directly notified
the few remaining major users on their talk pages and plan to change the
deprecation to an error in time for the deployment on February 3–5, 2017.

On Wed, Sep 14, 2016 at 12:43 PM, Brad Jorsch (Anomie) <
bjor...@wikimedia.org> wrote:

> To operate correctly, action=purge needs to write to the database, which
> means it should be done using a POST rather than a GET request.
>
> As of Gerrit change 310560,[1] action=purge will begin emitting a warning
> when used via GET. This should be deployed to WMF wikis with 1.28.0-wmf.20,
> see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the
> schedule.
>
> Clients that use action=paraminfo to determine whether to use GET or POST
> for an action should automatically switch to POST; any others should
> manually switch to using POST for this action as soon as possible.
>
> To check if your client's user agent is detected making such submissions,
> you can also use ApiFeatureUsage[2] and look for 'purge-via-GET' once
> 1.28.0-wmf.20 is rolled out to wikis your client is using.
>
> It is planned that this warning will be changed to an error during 1.29.
> Let's avoid having a repeat of T142155,[3] update your code ASAP instead of
> waiting until it breaks. Thanks.
>
>  [1]: https://gerrit.wikimedia.org/r/#/c/310560/
>  [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
>  [3]: https://phabricator.wikimedia.org/T142155
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
>



-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] provisioning new user with API

[Brad Jorsch (Anomie)]

On Thu, Dec 22, 2016 at 4:33 PM, Scott Koranda <skora...@gmail.com> wrote:

> Should the createtoken be passed as part of the query string or in the
> POST body?
>

POST body.


> If you have time and could point me to the source code for the
> createaccount action I will examine it and see if I can discern what I
> should be passing in.
>

https://phabricator.wikimedia.org/diffusion/MW/browse/master/includes/api/ApiAMCreateAccount.php,
although you'll probably quickly find your way to other files.

BTW, I updated https://www.mediawiki.org/wiki/API:Account_creation for
MediaWiki 1.27 and later.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] How to get full list of references for a Wiki revision through the API?

[Brad Jorsch (Anomie)]

On Tue, Dec 20, 2016 at 1:18 PM, Bertel Teilfeldt Hansen <
geilfe...@gmail.com> wrote:

> Hi Mediawiki-api mailing listers!
>
> I'm trying to extract the full list of references for different revisions
> of Wikipedia pages. This seemed like it would be easy enough with
> "prop=references", but I keep getting the following error:
>
> "error": {
> "code": "citestoragedisabled",
> "info": "Cite extension reference storage is not enabled.",
> "*": "See https://en.wikipedia.org/w/api.php for API usage."
> }
>
> Even the example on the API's documentation page returns this error 
> (https://en.wikipedia.org/w/api.php?action=help=query%2Breferences).
>
> Why does this occur? And is there no way of getting references through the 
> API?
>
> As the message says, it occurs when reference storage is not enabled (i.e.
when $wgCiteStoreReferencesData is false).

Even if reference storage is enabled, note that prop=references always
returns the references for the current revision of the page. It does not
provide references for old revisions.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Fixing old-style boolean response fields for formatversion=2

[Brad Jorsch (Anomie)]

With formatversion=1, boolean response fields are typically returned as the
empty string when true and are absent from the response when false. With
formatversion=2, boolean response fields in JSON and PHP formats are
supposed to be returned as native boolean true when true, and either native
boolean false or absent from the response when false.

Any boolean response fields that use the formatversion=1 semantics with
formatversion=2 should be fixed. Please file tasks in Phabricator if you
encounter such fields.[1] Clients using formatversion=2 should be prepared
for such response fields to be fixed without further warning.

 [1]:
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tag=MediaWiki-API


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] BREAKING CHANGE: Fixing old-style boolean response fields for formatversion=2

[Brad Jorsch (Anomie)]

With formatversion=1, boolean response fields are typically returned as the
empty string when true and are absent from the response when false. With
formatversion=2, boolean response fields in JSON and PHP formats are
supposed to be returned as native boolean true when true, and either native
boolean false or absent from the response when false.

Any boolean response fields that use the formatversion=1 semantics with
formatversion=2 should be fixed. Please file tasks in Phabricator if you
encounter such fields.[1] Clients using formatversion=2 should be prepared
for such response fields to be fixed without further warning.

 [1]:
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tag=MediaWiki-API


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api-announce] BREAKING CHANGE: Error code and other message reporting changes

[Brad Jorsch (Anomie)]

With the merge of Gerrit change 321406,[1] come some breaking changes to
the formatting of errors and warnings from some modules. These changes
should be on Beta Labs shortly, and should be deployed to WMF wikis with
1.29.0-wmf.6.

   - Error codes returned by some modules have changed. Notably, codes from
   query submodules will no longer include the module prefix, e.g. if you
   supply a bad continuation parameter for prop=revisions it will report error
   code 'badcontinue' instead of 'rvbadcontinue'. Other codes may have changed
   as well, e.g. for list=allpages the error for attempting to use redirects=1
   in generator mode is now 'invalidparammix' instead of 'params'.
   - If you're attempting to parse the human-readable 'info' text of
   errors, that text may have changed. Use cases should be submitted in
   Phabricator[2] as feature requests to include the needed data in a
   machine-readable format alongside the error message.
   - action=emailuser may return a "Warnings" status, and now returns
   'warnings' and 'errors' subelements (as applicable) instead of 'message'.
   - action=imagerotate returns an 'errors' subelement rather than
   'errormessage'.
   - action=move now reports errors when moving the talk page as an array
   under key 'talkmove-errors', rather than using 'talkmove-error-code' and
   'talkmove-error-info'. The format for subpage move errors has also changed.
   - action=rollback no longer returns a "messageHtml" property on errors.
   Use errorformat=html if you're wanting HTML formatting of messages.
   - action=upload now reports optional stash failures as an array under
   key 'stasherrors' rather than a 'stashfailed' text string.
   - action=watch reports 'errors' and 'warnings' instead of a single
   'error'

This same change brings the ability to request errors and warnings in
languages other than English and formats other than plain text. See the new
'errorformat', 'errorlang', and 'errorsuselocal' parameters to the 'main'
module.


 [1]: https://gerrit.wikimedia.org/r/#/c/321406/
 [2]:
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tag=MediaWiki-API

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Error code and other message reporting changes

[Brad Jorsch (Anomie)]

With the merge of Gerrit change 321406,[1] come some breaking changes to
the formatting of errors and warnings from some modules. These changes
should be on Beta Labs shortly, and should be deployed to WMF wikis with
1.29.0-wmf.6.

   - Error codes returned by some modules have changed. Notably, codes from
   query submodules will no longer include the module prefix, e.g. if you
   supply a bad continuation parameter for prop=revisions it will report error
   code 'badcontinue' instead of 'rvbadcontinue'. Other codes may have changed
   as well, e.g. for list=allpages the error for attempting to use redirects=1
   in generator mode is now 'invalidparammix' instead of 'params'.
   - If you're attempting to parse the human-readable 'info' text of
   errors, that text may have changed. Use cases should be submitted in
   Phabricator[2] as feature requests to include the needed data in a
   machine-readable format alongside the error message.
   - action=emailuser may return a "Warnings" status, and now returns
   'warnings' and 'errors' subelements (as applicable) instead of 'message'.
   - action=imagerotate returns an 'errors' subelement rather than
   'errormessage'.
   - action=move now reports errors when moving the talk page as an array
   under key 'talkmove-errors', rather than using 'talkmove-error-code' and
   'talkmove-error-info'. The format for subpage move errors has also changed.
   - action=rollback no longer returns a "messageHtml" property on errors.
   Use errorformat=html if you're wanting HTML formatting of messages.
   - action=upload now reports optional stash failures as an array under
   key 'stasherrors' rather than a 'stashfailed' text string.
   - action=watch reports 'errors' and 'warnings' instead of a single
   'error'

This same change brings the ability to request errors and warnings in
languages other than English and formats other than plain text. See the new
'errorformat', 'errorlang', and 'errorsuselocal' parameters to the 'main'
module.


 [1]: https://gerrit.wikimedia.org/r/#/c/321406/
 [2]:
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tag=MediaWiki-API

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: action=clearhasmsg will require POST

[Brad Jorsch (Anomie)]

With the merge of Gerrit change 324224,[1] action=clearhasmsg will return
an error if used via GET rather than POST. The change should be deployed to
WMF wikis with 1.29.0-wmf.5, see https://www.mediawiki.org/
wiki/MediaWiki_1.29/Roadmap for the schedule.

This should have very low impact: analysis of logs indicates that only
Huggle[2] is using it, and Huggle has already been updated.

 [1]: https://gerrit.wikimedia.org/r/#/c/324224/
 [2]: https://en.wikipedia.org/wiki/Wikipedia:Huggle

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] [Mediawiki-api-announce] DEPRECATION: Passwords and other sensitive fields for authentication must be in the POST body

[Brad Jorsch (Anomie)]

Over the past 30 days, there has been exactly one hit to action=clientlogin
with sensitive data in the query string, and none to action=createaccount,
action=linkaccount, and action=changeauthenticationdata. Beginning in
1.29.0-wmf.1 (to be deployed this week) these actions will now begin
throwing errors if sensitive fields are included in the query string.

Over the past 30 days, logins have been attempted via action=login for 28
different user names[1] with sensitive data (lgpassword or lgtoken) in the
query string. This will continue to work for now; my current plan is to
turn that warning into an error on February 15, 2017.


[1]: I can't post the list publicly at this time. If you want to know if
you're one of the 28, put your user agent into
https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage and look for
"login-params-in-query-string".


On Fri, Aug 19, 2016 at 3:24 PM, Brad Jorsch (Anomie) <bjor...@wikimedia.org
> wrote:

> For improved safety, passwords and other sensitive fields for
> authentication should not be included in the request URI during a POST.
> Instead, they should be in the POST body where they are less likely to be
> included in log files. With the merge of Gerrit change 305545,[1] the API
> will now produce a warning if such fields are detected in the URI. This
> should be deployed to WMF wikis with 1.28.0-wmf.16, see
> https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.
>
> This affects the following modules and fields:
> * action=login: 'lgpassword'
> * action=clientlogin, action=createaccount, action=linkaccount, and 
> action=changeauthenticationdata:
> Any fields reported as "sensitive" by action=query=authmanagerinfo
> or by UI or REDIRECT responses. Currently, this affects the 'password' and
> 'retype' fields.
>
> The 'lgtoken' field for action=login will now also issue a warning if
> placed in the request URI. The error code for other tokens being in the
> request URI has changed from 'mustposttoken' to 'mustpostparams'.
>
> To check if your client's user agent is detected making such submissions,
> you can also use ApiFeatureUsage[2] and look for 
> '-params-in-query-string'
> once 1.28.0-wmf.16 is rolled out to wikis your client is logging in to.
>
> It is planned that these warnings will be changed to errors during 1.29.
> Let's avoid having a repeat of T142155,[3] update your code ASAP instead of
> waiting until it breaks. Thanks.
>
>  [1]: https://gerrit.wikimedia.org/r/#/c/305545/
>  [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
>  [3]: https://phabricator.wikimedia.org/T142155
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
>



-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api-announce] DEPRECATION: Passwords and other sensitive fields for authentication must be in the POST body

[Brad Jorsch (Anomie)]

Over the past 30 days, there has been exactly one hit to action=clientlogin
with sensitive data in the query string, and none to action=createaccount,
action=linkaccount, and action=changeauthenticationdata. Beginning in
1.29.0-wmf.1 (to be deployed this week) these actions will now begin
throwing errors if sensitive fields are included in the query string.

Over the past 30 days, logins have been attempted via action=login for 28
different user names[1] with sensitive data (lgpassword or lgtoken) in the
query string. This will continue to work for now; my current plan is to
turn that warning into an error on February 15, 2017.


[1]: I can't post the list publicly at this time. If you want to know if
you're one of the 28, put your user agent into
https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage and look for
"login-params-in-query-string".


On Fri, Aug 19, 2016 at 3:24 PM, Brad Jorsch (Anomie) <bjor...@wikimedia.org
> wrote:

> For improved safety, passwords and other sensitive fields for
> authentication should not be included in the request URI during a POST.
> Instead, they should be in the POST body where they are less likely to be
> included in log files. With the merge of Gerrit change 305545,[1] the API
> will now produce a warning if such fields are detected in the URI. This
> should be deployed to WMF wikis with 1.28.0-wmf.16, see
> https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.
>
> This affects the following modules and fields:
> * action=login: 'lgpassword'
> * action=clientlogin, action=createaccount, action=linkaccount, and 
> action=changeauthenticationdata:
> Any fields reported as "sensitive" by action=query=authmanagerinfo
> or by UI or REDIRECT responses. Currently, this affects the 'password' and
> 'retype' fields.
>
> The 'lgtoken' field for action=login will now also issue a warning if
> placed in the request URI. The error code for other tokens being in the
> request URI has changed from 'mustposttoken' to 'mustpostparams'.
>
> To check if your client's user agent is detected making such submissions,
> you can also use ApiFeatureUsage[2] and look for 
> '-params-in-query-string'
> once 1.28.0-wmf.16 is rolled out to wikis your client is logging in to.
>
> It is planned that these warnings will be changed to errors during 1.29.
> Let's avoid having a repeat of T142155,[3] update your code ASAP instead of
> waiting until it breaks. Thanks.
>
>  [1]: https://gerrit.wikimedia.org/r/#/c/305545/
>  [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
>  [3]: https://phabricator.wikimedia.org/T142155
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
>



-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

Re: [Mediawiki-api] Editor doesn't work

[Brad Jorsch (Anomie)]

This mailing list is for help with the MediaWiki action API. You might want
to try https://www.mediawiki.org/wiki/Project:Support_desk or one of the
mailing lists linked from there.

On Thu, Oct 27, 2016 at 6:49 AM, Doro Erharter <d...@zimd.at> wrote:

> Dear all,
>
>
>
> We are using MediaWiki Version: 1.26.3 so the WikiEditor should be
> preinstalled. But since it didn't even show up on the "special pages" -
> "version" under the section "installed extensions", I searched the internet
> and thought I will just install the extension myself.
>
>
>
> I followed the instructions on the extension: WikiEditor page:
> https://www.mediawiki.org/wiki/Extension:WikiEditor
>
> but the WikiEditor still doesn't show up under "installed extensions".
>
>
>
> The LocalSettings.php had the line wfLoadExtension( 'WikiEditor' );
> already included from the beginning.
>
> I tried changing it, using the configuration suggestions of the WikiEditor
> page, and I also tried a suggestion of the Extension_Talk, where someone
> used the old method: require_once "$IP/extensions/WikiEditor/WikiEditor.php";
> but it didn't work with this line either.
>
>
>
> I tried clearing browser cache, too, didn't make a difference. Now I am
> out of guesses how we could make the extension work.
>
>
>
> Who can help me
>
> Karima & Doro
>
>
>
>
>
> --
>
> Dipl. Ing.in Dorothea Erharter
>
> Geschäftsführerin
>
> ZIMD Zentrum für Interaktion, Medien & soziale Diversität
>
> +43 (0) 699-1136 9902
>
> Währingerstraße 81/12
>
> 1180 Wien
>
>
>
> ___
> Mediawiki-api mailing list
> Mediawiki-api@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
>


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Action login doesn't return a lgtoken anymore

[Brad Jorsch (Anomie)]

On Tue, Oct 18, 2016 at 4:14 PM, Gergo Tisza <gti...@wikimedia.org> wrote:

> If you haven't been following API deprecation notices for the last ten or
> so months, https://lists.wikimedia.org/pipermail/
> mediawiki-api/2016-January/003686.html might also be of interest.
>

More generally, if you haven't been following API deprecation notices then
you should subscribe to the mediawiki-api-announce list[1] and look through
its archives[2] for the past year or so. There aren't many.

 [1]: https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
 [2]: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] DEPRECATION: Use of action=purge via GET is deprecated

[Brad Jorsch (Anomie)]

To operate correctly, action=purge needs to write to the database, which
means it should be done using a POST rather than a GET request.

As of Gerrit change 310560,[1] action=purge will begin emitting a warning
when used via GET. This should be deployed to WMF wikis with 1.28.0-wmf.20,
see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.

Clients that use action=paraminfo to determine whether to use GET or POST
for an action should automatically switch to POST; any others should
manually switch to using POST for this action as soon as possible.

To check if your client's user agent is detected making such submissions,
you can also use ApiFeatureUsage[2] and look for 'purge-via-GET' once
1.28.0-wmf.20 is rolled out to wikis your client is using.

It is planned that this warning will be changed to an error during 1.29.
Let's avoid having a repeat of T142155,[3] update your code ASAP instead of
waiting until it breaks. Thanks.

 [1]: https://gerrit.wikimedia.org/r/#/c/310560/
 [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
 [3]: https://phabricator.wikimedia.org/T142155

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] New features: Alternative multi-value separator and Unicode normalization warnings

[Brad Jorsch (Anomie)]

Both of these changes should be deployed to WMF wikis with 1.28.0-wmf.17,
see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.

== Alternative multi-value separator ==

With the merging of Gerrit change 305126,[1] if a value for a multi-valued
parameter must contain pipe characters (U+007C, "|"), it will now be
possible to use the Unit Separator character (U+001F) instead. As this
character is not otherwise valid input for any strings in MediaWiki, its
use here should not conflict with any valid input. To signal that you're
using this feature, the whole multi-value parameter must also be prefixed
with the Unit Separator character.

For example, you can now use meta=allmessages to parse the
"search-rewritten" message with the text "foo|bar" as $1 and "foo|baz" as
$2:
https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query=allmessages=search-rewritten=1=%1Ffoo|bar%1Ffoo|baz
<https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query=allmessages=search-rewritten=1=%1Ffoo%7Cbar%1Ffoo%7Cbaz>

Client libraries should consider updating to use this feature when asked to
send a multi-valued parameter with one or more values containing pipe
characters.


== Unicode normalization warnings ==

The API has always expected input as NFC-normalized Unicode represented as
UTF-8. Non-NFC-normalized UTF-8 input would be silently normalized, and in
the query string non-UTF-8 input would be interpreted as being in a
fallback encoding (such as Windows-1252) and converted to Unicode. This
sometimes led to subtle bugs when input was unexpectedly converted.

With the merging of Gerrit change 306491,[2] the API will now issue a
warning when input was subject to such conversion, which is hoped to make
it more obvious to clients when their input was subject to conversion.

When this happens in the 'titles' parameter for ApiPageSet-using modules,
the response will also include the conversion of each title in the existing
'normalized' element. Since the API result cannot directly represent
non-normalized data, these entries will have the 'from' element
percent-encoded and a 'fromencoded' boolean will be included alongside to
indicate this. This normalization step is separate from the existing Title
normalization (uppercasing the first letter and replacing underscores with
spaces), so two entries may be generated in the 'normalized' element.

See
https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query=a%CC%8A=2
for an example showing the new warning and normalization entries.


 [1]: https://gerrit.wikimedia.org/r/#/c/305126/
 [2]: https://gerrit.wikimedia.org/r/#/c/306491/


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] DEPRECATION: Passwords and other sensitive fields for authentication must be in the POST body

[Brad Jorsch (Anomie)]

For improved safety, passwords and other sensitive fields for
authentication should not be included in the request URI during a POST.
Instead, they should be in the POST body where they are less likely to be
included in log files. With the merge of Gerrit change 305545,[1] the API
will now produce a warning if such fields are detected in the URI. This
should be deployed to WMF wikis with 1.28.0-wmf.16, see
https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.

This affects the following modules and fields:
* action=login: 'lgpassword'
* action=clientlogin, action=createaccount, action=linkaccount, and
action=changeauthenticationdata: Any fields reported as "sensitive" by
action=query=authmanagerinfo or by UI or REDIRECT responses.
Currently, this affects the 'password' and 'retype' fields.

The 'lgtoken' field for action=login will now also issue a warning if
placed in the request URI. The error code for other tokens being in the
request URI has changed from 'mustposttoken' to 'mustpostparams'.

To check if your client's user agent is detected making such submissions,
you can also use ApiFeatureUsage[2] and look for
'-params-in-query-string' once 1.28.0-wmf.16 is rolled out to wikis
your client is logging in to.

It is planned that these warnings will be changed to errors during 1.29.
Let's avoid having a repeat of T142155,[3] update your code ASAP instead of
waiting until it breaks. Thanks.

 [1]: https://gerrit.wikimedia.org/r/#/c/305545/
 [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
 [3]: https://phabricator.wikimedia.org/T142155

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] DEPRECATION: Passwords and other sensitive fields for authentication must be in the POST body

[Brad Jorsch (Anomie)]

For improved safety, passwords and other sensitive fields for
authentication should not be included in the request URI during a POST.
Instead, they should be in the POST body where they are less likely to be
included in log files. With the merge of Gerrit change 305545,[1] the API
will now produce a warning if such fields are detected in the URI. This
should be deployed to WMF wikis with 1.28.0-wmf.16, see
https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.

This affects the following modules and fields:
* action=login: 'lgpassword'
* action=clientlogin, action=createaccount, action=linkaccount, and
action=changeauthenticationdata: Any fields reported as "sensitive" by
action=query=authmanagerinfo or by UI or REDIRECT responses.
Currently, this affects the 'password' and 'retype' fields.

The 'lgtoken' field for action=login will now also issue a warning if
placed in the request URI. The error code for other tokens being in the
request URI has changed from 'mustposttoken' to 'mustpostparams'.

To check if your client's user agent is detected making such submissions,
you can also use ApiFeatureUsage[2] and look for
'-params-in-query-string' once 1.28.0-wmf.16 is rolled out to wikis
your client is logging in to.

It is planned that these warnings will be changed to errors during 1.29.
Let's avoid having a repeat of T142155,[3] update your code ASAP instead of
waiting until it breaks. Thanks.

 [1]: https://gerrit.wikimedia.org/r/#/c/305545/
 [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
 [3]: https://phabricator.wikimedia.org/T142155

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

Re: [Mediawiki-api] API login

[Brad Jorsch (Anomie)]

On Fri, Aug 5, 2016 at 5:41 PM, John <phoenixoverr...@gmail.com> wrote:

> Why in the hell has basic API logins stopped working?
>

To close the loop, this was presumably T142155. More detail is in <
https://phabricator.wikimedia.org/T142155#2529503>.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] BREAKING CHANGE: Removal of lgtoken, cookieprefix, and sessionid response values from action=login

[Brad Jorsch (Anomie)]

These response values, deprecated in December 2015, will no longer be
returned in the response to action=login. This change should be deployed to
WMF wikis with 1.28.0-wmf.13, see
https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.

Note that the lgtoken *parameter* to action=login is not removed, nor is
the 'token' response value included along with a NeedToken response.

This is expected to have a low client impact, since proper handling of the
Set-Cookie headers (rather than manually building cookies using these
response values) has been effectively required for some time now.


The original deprecation announcement is quoted below:

On Tue, Dec 15, 2015 at 11:11 AM, Brad Jorsch (Anomie) <
bjor...@wikimedia.org> wrote:

> Long ago, the only mechanism for session management in MediaWiki was
> certain cookies set by the User class. When ApiLogin was written, in
> addition to setting these cookies as usual it also returned some of the
> values needed to construct these cookies on the client. Presumably this was
> to make things easier for clients that somehow couldn't handle the standard
> cookie headers.
>
> Then CentralAuth came along. Now, constructing the cookies manually would
> log you in to the local wiki only, without taking advantage of the SUL
> mechanism.
>
> Then T55032[1] happened, and clients that were using the
> manual-construction mechanism had to update their code because one of the
> cookie names changed and that wasn't part of the data being returned.
>
> And soon, we'll have SessionManager and AuthManager, which will make it
> possible for login to easily happen in ways that don't involve cookies at
> all.
>
> So it's time to eliminate the pretense that clients can manually construct
> the cookies instead of handing the standard HTTP cookie headers. Tentative
> plan is to deprecate them now and then remove them sometime during 1.28; if
> anyone objects to this schedule, please raise your concerns in
> https://phabricator.wikimedia.org/T121527.
>
>
>  [1]: https://phabricator.wikimedia.org/T55032
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
>



-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Removal of lgtoken, cookieprefix, and sessionid response values from action=login

[Brad Jorsch (Anomie)]

These response values, deprecated in December 2015, will no longer be
returned in the response to action=login. This change should be deployed to
WMF wikis with 1.28.0-wmf.13, see
https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.

Note that the lgtoken *parameter* to action=login is not removed, nor is
the 'token' response value included along with a NeedToken response.

This is expected to have a low client impact, since proper handling of the
Set-Cookie headers (rather than manually building cookies using these
response values) has been effectively required for some time now.


The original deprecation announcement is quoted below:

On Tue, Dec 15, 2015 at 11:11 AM, Brad Jorsch (Anomie) <
bjor...@wikimedia.org> wrote:

> Long ago, the only mechanism for session management in MediaWiki was
> certain cookies set by the User class. When ApiLogin was written, in
> addition to setting these cookies as usual it also returned some of the
> values needed to construct these cookies on the client. Presumably this was
> to make things easier for clients that somehow couldn't handle the standard
> cookie headers.
>
> Then CentralAuth came along. Now, constructing the cookies manually would
> log you in to the local wiki only, without taking advantage of the SUL
> mechanism.
>
> Then T55032[1] happened, and clients that were using the
> manual-construction mechanism had to update their code because one of the
> cookie names changed and that wasn't part of the data being returned.
>
> And soon, we'll have SessionManager and AuthManager, which will make it
> possible for login to easily happen in ways that don't involve cookies at
> all.
>
> So it's time to eliminate the pretense that clients can manually construct
> the cookies instead of handing the standard HTTP cookie headers. Tentative
> plan is to deprecate them now and then remove them sometime during 1.28; if
> anyone objects to this schedule, please raise your concerns in
> https://phabricator.wikimedia.org/T121527.
>
>
>  [1]: https://phabricator.wikimedia.org/T55032
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
>



-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] ApiParse: Deprecation of prop=headitems (and removal of partial ResourceLoader code)

[Brad Jorsch (Anomie)]

The 'headitems' property for action=parse has been deprecated, and using it
will return a warning. If constructing a page from scratch, you should use
prop=headhtml instead. If updating an existing on-wiki page, use
prop=modules|jsconfigvars and load them into the existing ResourceLoader
code with mw.config.set() and mw.loader.using().

Also, the 'headitems' property will no longer return code related to
ResourceLoader. Loading ResourceLoader would require additional data that
is not sent by 'headitems', and given the deprecation it's not worth the
trouble to add that data.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

Re: [Mediawiki-api] please unsubscribe me I can't

[Brad Jorsch (Anomie)]

You've both been unsubscribed.

For anyone else with this sort of issue, you should be able to unsubscribe
yourself by sending mail to mediawiki-api-requ...@lists.wikimedia.org with
subject "unsubscribe".

On Mon, Jun 27, 2016 at 3:59 AM, Robert Jozef <robijo...@gmail.com> wrote:

> Me too. robijo...@gmail.com
>
>
> ponedjeljak, 27. lipnja 2016. korisnik François Colonna <
> f.colonnaces...@free.fr> napisao je:
>
>>
>> Hello
>>
>> could you please unsubscribe me.
>> I have got an issue with mailman : I could not received my password and
>> thus login.
>>
>> Thanks
>>
>> François Colonna
>>
>> ___
>> Mediawiki-api mailing list
>> Mediawiki-api@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>>
>
> ___
> Mediawiki-api mailing list
> Mediawiki-api@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
>


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Retrieving the maximum allowed size for an article ?

[Brad Jorsch (Anomie)]

On Fri, Jun 24, 2016 at 11:58 AM, Nicolas Vervelle <nverve...@gmail.com>
wrote:

> Is it possible to know through the API what is the maximum allowed size
> for an article on a given wiki ?
>

It doesn't look like it. But it would be easy enough to expose
$wgMaxArticleSize through ApiQuerySiteinfo. File a task in Phabricator?


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Backlinks behaviour with redirects having also content

[Brad Jorsch (Anomie)]

On Mon, May 30, 2016 at 4:57 AM, Nicolas Vervelle <nverve...@gmail.com>
wrote:

> So, my guess is "redirects" then "linkshere" for Spin-off and all
> redirects given by the first request?
>

Yes, that should do it.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] Get HTML of a wiki page (like wget)?

[Brad Jorsch (Anomie)]

On Tue, Apr 5, 2016 at 4:58 PM, Bartosz Dziewoński <matma@gmail.com>
wrote:

> You can do this with the action=parse API.
> https://www.mediawiki.org/wiki/API:Parsing_wikitext#parse


Note this doesn't give the *full* HTML as you'd get by fetching the article
from the web UI, as it omits the wrapping HTML from the skin and other
chrome. I don't think there's any way to fetch the full page HTML including
skin and other chrome from the API.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] Changes and deprecation in login and createaccount tokens

[Brad Jorsch (Anomie)]

With the merge of Gerrit change 264309,[1] there are two changes to the
handling of login and createaccount tokens. The changes should be deployed
to WMF wikis with 1.27.0-wmf.12, see
https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap for the schedule.

Neither of these changes should break existing API clients, unless the
client is treating API warnings as errors or is doing something unusual
with these tokens.

The first change is that login and createaccount tokens now use the same
token generation mechanism as other CSRF tokens, but not the special case
that results in other CSRF tokens always being "+\" when not logged in.
This means that login and createaccount tokens will be longer, will end in
"+\", and include an embedded timestamp so a potential future change could
have them expire after a defined time period rather than lasting for the
duration of the session.

The second change is that login and createaccount tokens will now be able
to be fetched via action=query=tokens, in the same manner as other
CSRF tokens. Fetching them by submitting an action=login or
action=createaccount request without a token (to receive a NeedToken
response) is now deprecated, and a warning will be returned along with the
NeedToken response indicating this deprecation. There is no plan to
actually remove the NeedToken response from action=login at this time, and
any future plan for its removal will be announced separately with
appropriate lead time. The NeedToken response will remain in
action=createaccount until the previously-announced breaking change to that
module,[2] and will be removed from action=createaccount along with that
breaking change.


 [1]: https://gerrit.wikimedia.org/r/#/c/264309/
 [2]:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/000101.html

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] Upcoming BREAKING CHANGES: Changes to interactive login and account creation

[Brad Jorsch (Anomie)]

You may remember the announcement last week about changes for bot login (if
you somehow missed it, see
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/000100.html).
This is the promised follow-up for clients that do interactive login, and
also for anyone doing account creation.

AuthManager is going to be changing how some API modules work. For
interactive user login, you're going to want to change to using
action=clientlogin. The action=createaccount is also going to change to a
more interactive flow. The WIP code for the new API modules is in
https://gerrit.wikimedia.org/r/#/c/265201/; it's not too late to change
stuff in there, but bring good reasons.

Our target is to have this rolling out to WMF wikis by the end of February.

The general procedure for using both of these will be the same:

   1. Fetch the initial field information from the new
   action=query=authmanagerinfo. Using format=json, the relevant part of
   the data structure is an object with keys being field names and values
   being objects that include the data type (string, password, select,
   multiselect, checkbox, button), localized labels, and such.
   2. Convert that field information into UI to display to your users.
   3. Take the user input and post it to action=clientlogin or
   action=createaccount, along with some other information documented in those
   modules.
   4. The response will tell you what to do next:
  - PASS: You're done, it succeeded.
  - FAIL: You're done, it failed. There's a localized "message" field
  to tell you why.
  - UI: More user input is needed. There's a localized "message", and
  there's field information like you got in step 1. You'll repeat steps 2–4
  with the new fields (and with slightly different module
parameters in step
  3).
  The use cases here include requesting the second factor for 2-factor
  auth, prompting the user to reset their password, informing them
that they
  were renamed from "Example" to "Example~enwiki", etc.
  - REDIRECT: It wants you to send the user to another website, e.g.
  pop up a browser or a web view. Once the remote site is done, it'll send
  the user to a URL you specified in step 3, at which time you'll
extract the
  data from that request and repeat steps 3–4. There's also provision for
  skipping the redirect if your app knows how to do a non-web
authentication
  against the provider, e.g. a GoogleLogin extension could provide
data that
  an Android app needs to use some internal Android API to
authenticate with
  a Google account and get the needed data.
  The use case here is for something like "log in with Google", "log in
  with Facebook", generic "log in with OpenID", and so on where you have to
  send the user to some other site.
  - RESTART: This means that the user authenticated ok, but we don't
  know what user account the credentials belong to. You could treat this
  response as if it were UI so they can log in with a different
mechanism, or
  as FAIL, or you could start up action=createaccount to create a
new account.
  The use case here is again something like "log in with Google",
  Google returned success but we don't have any on-wiki account linked with
  that Google account.

Account creation is going to break on day 1, we're not trying to maintain
any backwards compatibility there since it wouldn't be likely to work very
well anyway and there aren't many account creation clients out there.

The old login with action=login will probably continue to work for users
who don't have 2-factor auth, a migrated CentralAuth account (i.e. trying
to log in as Example when you're now Example~enwiki), or anything else that
would make a UI or REDIRECT response be returned, but again we're not
guaranteeing that it won't suddenly stop at some point. Also, the old login
mechanism will start returning a "Aborted" or "Failed" (with a localized
message) rather than "WrongToken", "BadPassword", "Throttled", and so on.
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] Upcoming BREAKING CHANGE: Changes to login for bots

[Brad Jorsch (Anomie)]

MediaWiki's authentication layer is getting a major overhaul. For more
details see the announcement "MediaWiki authentication changes" sent to
wikitech-l[1]; this email will repeat the portion relevant to bots. If you
maintain an interactive application that uses API login, the details of how
this will affect you aren't yet finalized; see the announcement on
wikitech-l for more, or wait for a future announcement to this list once
the details are available.

The "thinks will break" date has not yet been decided, but the goal is to
have it ready by the end of February.

*TL;DR:* Switch your bot to OAuth if possible, or look at
Special:BotPasswords (being deployed next week on WMF wikis) to set up a
new username+password for your bot to use with action=login in the future.

The new authentication features mean that unattended login might no longer
work since the login flow will now natively support user interaction: the
account might have 2-factor enabled, or might need a password reset, or
some other thing that requires user interaction. We've created two ways to
work around this:

   - If possible, switch to OAuth. This week (1.27.0-wmf.10) "owner-only"
   consumers are being rolled out to make this easier for bot operators: log
   into your bot account, go to
   https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration/propose,
   and create a consumer with the "This consumer is for use only by MyBotName"
   checkbox checked.The consumer will be approved for use immediately, no
   waiting or trying to find someone who can approve the consumer for you.
   Owner-only consumers also don't tag every edit, since all the edits will be
   from the one account anyway.
   - If you need to continue using the existing action=login, next week
   (1.27.0-wmf.11) we're rolling out Bot Passwords. This is something like
   OAuth-lite, or Google's application passwords: go to Special:BotPasswords,
   set one up, and then use new bot-password username and password to login as
   you've always done (no code changes, just update your bot's configuration).
   It's already live in Beta Labs if you want to test it out.

action=login with the "main" account password might still continue to work
after the new AuthManager is deployed, as long as nothing requires user
interaction.

For bots that run on third-party wikis, Bot Passwords are in core and are
enabled by default, but it's possible a wiki could disable them. OAuth is
an extension that the wiki may or may not have installed.


 [1]:
https://lists.wikimedia.org/pipermail/wikitech-l/2016-January/084501.html


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api] Public service announcement: Clarification of list=prefixsearch semantics

[Brad Jorsch (Anomie)]

If you're also on wikitech-l, you may have seen the recent announcement[1]
of some work by WMF's Discovery team to improve the search results popped
up by the search box in wiki pages. Assuming it continues to receive
positive feedback, it's rather likely that the code behind their temporary
"action=cirrus-suggest" API module will become the backing engine behind
action=opensearch and list=prefixsearch.

This brought to my attention that "list=prefixsearch" has never been
particularly well-documented, so Gerrit change 260383[2] was submitted and
merged to clarify the issue. Note this isn't a change in behavior, it's a
clarification of the existing behavior to avoid future confusion when that
behavior is improved.

ApiQueryPrefixSearch was added in Gerrit change 123118[3] to be like
action=opensearch but usable as a generator. If your client code is using
list=prefixsearch in the expectation that it would work like the
similarly-named web UI page Special:PrefixIndex, you should review your
usage to make sure that it is actually behaving as you intend. If you are
really wanting a list of titles with a prefix rather than a *search* for
pages "matching" a prefix in some loosely-defined sense, you should be
using list=allpages with the apprefix parameter instead.


 [1]:
https://lists.wikimedia.org/pipermail/wikitech-l/2015-December/084356.html
 [2]: https://gerrit.wikimedia.org/r/#/c/260383/
 [3]: https://gerrit.wikimedia.org/r/#/c/123118/

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Removal of deprecated formats dbg, txt, and yaml

[Brad Jorsch (Anomie)]

Per the RfC a while back[1] and the previous announcement,[2] we're about
to remove the deprecated dbg, txt, and yaml output formats from the API.
This is planned for 1.27.0-wmf.8, which is currently scheduled to be
deployed to WMF wikis starting December 1, 2015.[3]

Users using the yaml format should be able to easily change to json, as the
format is entirely identical.

This removal may impact some tools. If you know of any tool using these
deprecated formats, please encourage them to upgrade before December 1.


 [1]:
https://www.mediawiki.org/wiki/Requests_for_comment/Ditch_crappy_API_formats
 [2]:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2015-July/93.html
 [3]: https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] What means exactly the index parameter in this API search query? It's not what I guess or there is a bug.

[Brad Jorsch (Anomie)]

On Thu, Oct 8, 2015 at 6:42 AM, <soulchai...@tuta.io> wrote:

> Well... My doubt is: what thing exactly refers to the «index» parameter in
> «pages» objects? At first instance, I believed it was the index of the same
> page in the «search» array of objects. That seems logic.
>

That's close. It's the order that the pages were returned in by
generator=search.


> But, when using that, sometimes certain indexes simply don't match (they
> pair «pageid» from one page with «titlesnippet», «snippet», etc from
> another page).
>

You may notice that submitting the same list=search query will sometimes
give different results, i.e. the search engine ordering of results isn't
completely deterministic. When you see such a mismatch between the indexes
in the pages produces by generator=search and the list produced by
list=search, the same thing happened between the two searches.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] Tips for using bots and user scripts with Flow

[Brad Jorsch (Anomie)]

Apologies to those seeing this twice, but it's important enough to announce
widely.

-- Forwarded message --
From: Matthew Flaschen 
Date: Tue, Sep 29, 2015 at 4:05 PM
Subject: [Mediawiki-api] Tips for using bots and user scripts with Flow
To: mediawiki-api@lists.wikimedia.org, EE List 


Flow will start appearing more widely soon when we release a feature to
allow users on certain wikis to opt into Flow on their user talk pages.

The most common thing you'll probably want to do on a Flow page is post a
new topic.

For Pywikibot, that is pretty easy, since they have Flow support now. See
https://www.mediawiki.org/wiki/Manual:Pywikibot/Flow .

For on-wiki scripts, you can use MessagePoster (you don't need to know if
it's a Flow board ahead of time!):

---
var title = new mw.Title( 'titleString' );
var posterPromise = mw.messagePoster.factory.create( title );
posterPromise.done( function ( poster ) {
poster.post( 'This is the topic title', 'This is the body
of a message posted with MessagePoster' );
} );
---

Depend on 'mediawiki.messagePoster' and 'mediawiki.Title'.

In some cases, you might want to check if a link is already there (e.g. to
see if a warning template already included links to a particular policy).
You can use prop=links for this.

Flow is based on an infinitely-scrollable list of topics, each of which is
its own page.  So to use prop=links, you may need to loop through a set of
recent enough topics (e.g. 25) then combine them into a prop=links request,
e.g.
https://www.mediawiki.org/w/api.php?action=query=Topic:Sojpiv245cuiw67c|Topic:Sojs3simnwvh96fk=links
.

pywikibot has support for looping through topics.

Some bots need to check the header of a page for wikitext (e.g. a bot
exclusion template).  This can be done with view-header, but I don't think
pywikibot has support for that yet (but it can be done directly).  See
https://www.mediawiki.org/w/api.php?action=flow=jsonfm=Talk%3AFlow=view-header=wikitext
.

A better way to do this would be templatelinks, but I'm not sure if there
is an API to show templates PageX transcludes.

For other questions, contact us at #wikimedia-collaboration .  Or, if a
certain tool needs Flow support and you're not sure where to start, you can
file a bug (you can also reply here, but a ping in IRC would be
appreciated).

Matt Flaschen
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] How to expand only {{subst:}} and {{safesubst:}}

[Brad Jorsch (Anomie)]

On Sat, Sep 19, 2015 at 7:09 AM, Nicolas Vervelle <nverve...@gmail.com>
wrote:

> Is it possible through the API to give it some wikitext and get in return
> the same wikitext where {{subst:}} and {{safesubst:}} have been replaced,
> as they would be when saving an edit ?
>

Use action=parse with onlypst=1.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Removal for wddx and dump output formats (and reminder of future removal of yaml, txt, and dbg formats)

[Brad Jorsch (Anomie)]

Per the RfC a while back,[1] we've now removed the wddx and dump output
formats from the API. This is expected to be a very low-impact change, as
logs don't show anyone actually using these anymore.

This change should be deployed to WMF wikis with 1.26wmf13, see
https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap for the schedule.

Note that the yaml, txt, and dbg output formats are scheduled for removal
in November 2015. Users using yaml should be able to easily change to json
as it's entirely identical.


 [1]:
https://www.mediawiki.org/wiki/Requests_for_comment/Ditch_crappy_API_formats

-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

[Mediawiki-api-announce] BREAKING CHANGE: Removal for wddx and dump output formats (and reminder of future removal of yaml, txt, and dbg formats)

[Brad Jorsch (Anomie)]

Per the RfC a while back,[1] we've now removed the wddx and dump output
formats from the API. This is expected to be a very low-impact change, as
logs don't show anyone actually using these anymore.

This change should be deployed to WMF wikis with 1.26wmf13, see
https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap for the schedule.

Note that the yaml, txt, and dbg output formats are scheduled for removal
in November 2015. Users using yaml should be able to easily change to json
as it's entirely identical.


 [1]:
https://www.mediawiki.org/wiki/Requests_for_comment/Ditch_crappy_API_formats

-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
Mediawiki-api-announce@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce

[Mediawiki-api] [Mediawiki-api-announce] Deprecation of generatexml parameter to action=parse, prop=revisions, and prop=deletedrevisions

[Brad Jorsch (Anomie)]

With the merge of Gerrit change 216048,[1] the 'generatexml' parameter to
action=parse, action=queryprop=revisions, and
action=queryprop=deletedrevisions is deprecated in favor of a new
'parsetree' prop.

This should be deployed to WMF wikis with 1.26wmf13, see
https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap for the schedule.

 [1]: https://gerrit.wikimedia.org/r/#/c/216048/

-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] PageID on PARSE Api

[Brad Jorsch (Anomie)]

On Wed, Jul 1, 2015 at 12:09 PM, Luigi Assom luigi.as...@gmail.com wrote:

 e.g.
 action=parsetitle=DNA*prop=curid??*


action=querytitles=DNAprop=revisionsrvprop=contentrvparse=1, perhaps?


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Re: [Mediawiki-api] [Mediawiki-api-announce] Changes to meta=siteinfo with formatversion=2

[Brad Jorsch (Anomie)]

On Jun 22, 2015 3:04 PM, Roan Kattouw roan.katt...@gmail.com wrote:


 On Tue, Jun 16, 2015 at 1:36 PM, Brad Jorsch (Anomie) 
bjor...@wikimedia.org wrote:

 Note that formatversion=2 is still considered slightly experimental, in
that backwards-incompatible changes like this can still happen. If you see
any other changes like this that should be made, please report them!

 Starting in 1.26wmf11, the following changes will be made in the output
from meta=siteinfo when formatversion=2 is in use:
 Output from siprop=namespaces will be an array, rather than an object
indexed by namespace number. See T102645.[1]


 This was reverted in https://gerrit.wikimedia.org/r/#/c/219514/ . The
output of siprop=namespaces will not change in 1.26wmf11.

For clarity, the quoted item was undone. The other changes from the
original message are still in effect.
___
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api