Hi, All,
I found in some of the UPLOAD update, there is no page id:
<rc type="log" ns="6" title="File:Lucian A. Sperta- Nunez.jpg" rcid="
114549183" pageid="0" revid="0" old_revid="0" user="Azarel63"oldlen="0"
newlen="0" timestamp="2014-01-05T11:09:38Z" comment="User created page with
UploadWizard" logid="77242320" logtype="upload"logaction="upload" img_sha1="
sf9t03wg27tl73nnde3jzfuxncefux9" img_timestamp="2014-01-05T11:09:36Z"/>
<rc type="log" ns="6" title="File:Gingerbread spices (annotated).jpg" rcid="
114549185" pageid="30485540" revid="0" old_revid="0"user="SKopp" oldlen="0"
newlen="0" timestamp="2014-01-05T11:09:37Z" comment="User created page with
UploadWizard" logid="77242318"logtype="upload" logaction="upload" img_sha1="
q84abqjr2n4bmn7o6j4uovpl5ufs2gq" img_timestamp="2014-01-05T11:09:37Z"/>
The first one has no page id but the second one has.
Does anybody can tell me the differences?
Thanks,
Ethan Liu
Hi, in response to bug 54607 [1], we've changed the semantics of the
mobileformat parameter to action=parse
== Summary ==
Previously, it used to accept strings 'html' or 'wml', later just
'html' and modify the structure of output (see below). This was problematic
because you needed to retrieve the HTML from output in different ways,
depending on whether mobileformat is specified or not. Now,
mobileformat is a boolean parameter, that is if there's a 'mobileformat'
parameter in request, it will be treated as "the output should be
mobile-friendly", regardless of value. And the output structure will
be the same. For compatibility with older callers,
mobileformat=(html|wml) will be special-cased to return the older
structure at least for 6 month from now. These changes will start
being rolled out to the WMF sites starting from tomorrow, Tuesday
October 24th and this process will be complete by October 31st.
== Examples ==
=== Non-mobile parse ===
api.php?action=parse&format=xml
{
"parse": {
"title": "...",
"text": {
"*": "foo"
}
}
}
api.php?action=parse&format=json
<?xml version="1.0"?>
<api>
<parse title="..." displaytitle="...">
<text xml:space="preserve">foo</text>
</parse>
</api>
=== Parse that outputs mobile HTML, old style ===
api.php?action=parse&format=json&mobileformat=html
{
"parse": {
"title": "API",
"text": "foo"
}
}
api.php?action=parse&format=xml&mobileformat=html
<?xml version="1.0"?>
<api>
<parse title="..." text="foo" displaytitle="...">
</parse>
</api>
=== Parse that outputs mobile HTML, new style ===
api.php?action=parse&format=...&mobileformat
Same as for non-mobile parses.
== FAQ ==
Q: I didn't use mobileformat before, does anything change for me?
A: No.
Q: I use mobileformat=html, will my bot/tool be broken now?
A: No, you will have 6 months to switch to new style.
Q: I'm only planning to use mobileformat, what should I do?
A: Just use the new style.
Q: How did this format discrepancy appear in the first place?
A: To err is human.
-----
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=54607
--
Best regards,
Max Semenik ([[User:MaxSem]])
The 'basic info' for every page includes its wikidata page id, e.g.
http://en.wikipedia.org/w/index.php?title=Roy_Dowling&action=info
But I don't see anyway to retrieve this. I might have thought it would be
a property that could be retrieved as part of a query, but I don't see it.
Am I missing something or is it not available yet?
Thanks,
Tom
Gerrit change 135283 <https://gerrit.wikimedia.org/r/#/c/135283/> will
cause action=logevents to return an error if both the letitle and leprefix
parameters are specified. Previously specifying both of these parameters
would apply both filters, making leprefix pointless if letitle matches the
prefix or returning no results if not.
The expected impact of this change is low, as no uses of this parameter
combination were logged in the time period checked.
If any client is affected by this change, it may simply remove leprefix
when letitle is specified.
This change will be deployed to WMF wikis with 1.24wmf7, see
https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule.
--
Brad Jorsch (Anomie)
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
Gerrit change 133955 <https://gerrit.wikimedia.org/r/#/c/133955/>, which I
plan to merge on Thursday for deployment to WMF wikis with
1.24wmf7<https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap>,
will cause the API to report an error when action=edit is used with the
"redirect" parameter and none of "appendtext", "prependtext", or
"section=new" are used. This will occur regardless of whether the page
being edited is actually a redirect.
API action=edit has a "redirect" parameter, which will automatically edit
the target page if the supplied title is a redirect. The original intention
of this feature was to be used in combination with appendtext or
section=new for posting notifications to user talk pages without having to
first check whether the page is a redirect (see bug
24330<https://bugzilla.wikimedia.org/show_bug.cgi?id=24330>).
But as currently implemented it will perform the edit even when replacement
page text is supplied, which is extremely prone to error: while reviewing
the patch proposing this change, I reviewed several scripts and bots that
were logged as submitting API requests with this combination of parameters
and every one would make erroneous edits when the target page is a redirect.
Clients not using the "redirect" parameter to action=edit or clients that
use it in combination with "appendtext", "prependtext", or "section=new"
will not be affected by this change. Affected clients have several options
for coping with this change, such as:
- Stop supplying the "redirect" parameter to action=edit, which will
edit the redirect page itself.
- When fetching the page content to transform it for the edit, use the
"redirect" parameter to action=query and submit the edit to the target page
directly (and without using the "redirect" parameter to action=edit) rather
than via the redirect title.
- Use appendtext, prependtext, or section=new instead of loading the
page's wikitext and appending or prepending content on the client side.
- Detect the redirect when fetching the page content and treat the
unexpected redirect as an error condition. Or handle the error returned by
action=edit in whatever manner is appropriate to your script, bot, or tool.
See https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the
deployment schedule.
--
Brad Jorsch (Anomie)
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
https://pythonhosted.org/mediawiki-utilities/
"MediaWiki Utilities is an open source (MIT Licensed) library developed
by Aaron Halfaker for extracting and processing data from MediaWiki
installations, slave databases and xml dumps." It's Python, and requires
Python 3 or later.
For instance, check out
https://pythonhosted.org/mediawiki-utilities/core/api.html .
"Session – Constructs an API session with a MediaWiki installation.
Contains convenience methods for accessing prop=revisions,
list=usercontribs, meta=siteinfo, list=deletedrevs and list=recentchanges."
--
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation