לא יודע
חסום לי
בתאריך יום א׳, 29 בדצמ׳ 2019 ב-14:01 מאת <
mediawiki-api-request@lists.wikimedia.org>:
> Send Mediawiki-api mailing list submissions to
> mediawiki-api(a)lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
> or, via email, send a message with subject or body 'help' to
> mediawiki-api-request(a)lists.wikimedia.org
>
> You can reach the person managing the list at
> mediawiki-api-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mediawiki-api digest..."
>
>
> Today's Topics:
>
> 1. API search issue (Alessandro Vallin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 29 Dec 2019 11:42:50 +0100
> From: Alessandro Vallin <alessandro.vallin(a)gmail.com>
> To: mediawiki-api(a)lists.wikimedia.org
> Subject: [Mediawiki-api] API search issue
> Message-ID:
> <CAO6zDE6nJkUJShL1S=
> M8Jg2qT-KZUjK3uQ3pVt-5Z-YFVatxxw(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Good morning
>
> I am using the following API search, which used to return title, content
> and link of a Wikipedia entry:
>
>
> https://it.wikipedia.org/w/api.php?action=opensearch&search=alessandro%20le…
>
> Just recently I noticed that it is always returning an empty content part
> ([""]):
>
> ["alessandro leogrande",["Alessandro Leogrande"],[""],["
> https://it.wikipedia.org/wiki/Alessandro_Leogrande"]]
>
> Can you please give me any insight?
> Thanks,
> Alessandro
>
Hi all,
action=helppanelquestionposter is an API meant for internal use by the
GrowthExperiments extension's web UI, but it has not been formally marked
as internal, so I'm announcing the recent changes [1] to it just in case:
- the 'email' and 'resendconfirmation' parameters have been removed;
- the 'email' response field has been removed;
- the API is now marked as internal.
The functionality provided by the API is not really useful outside of the
web-based workflow it supports, and can be approximated with other, public
APIs, so this is not expected to cause problems to any clients.
[1]
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/5…
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
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-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
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&prop=extracts&titles=Anthem…
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?
Best,
Bertel
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
Hello Everyone,
Sorry for posting here. I am Jay Prakash. As part of my
GSoC project, I have developed the sample code in PHP, Javascript, and
MediaWiki JS to demonstrate the use of MediaWiki Action API modules. I
want/seek review, valuable suggestions, and feedback on the sample code
format and accuracy. Please give us your valuable suggestions and feedback
at T228549.[1]
Thank you :)
User:Jayprakash12345
Intern, GSoC 2019 w/o Wikimedia Foundation
[1] https://phabricator.wikimedia.org/T228549
Hello everyone.
Please see this link: https://phabricator.wikimedia.org/T212907
The problem in short description is that in some wikis there is a problem
with number of articles. Specially the big articles. When any article
exceed the transclusion limit of the templates, then the templates in the
bottom will not be shown. Also the article loads very very slow.
Then I find out that if we use Rest API
https://www.mediawiki.org/api/rest_v1/ to get the content of the pages that
contain the same problem, then it will loads very fast, and the problem
disappear.
So Aklapper ask to post this question in this email list. See the Phab ID
for more details.
Best regards.
Ahmed.
Hi,
API:Etiquette (https://www.mediawiki.org/wiki/API:Etiquette)page says there
is no hard and fast limit on API read requests,but how many requests have
MediaWiki had access restrictions in the past?
Regards,
Kazuma