If anyone is using action=parse with prop=modules and not including either
jsconfigvars or encodedjsconfigvars in the prop parameter, you will start
receiving a warning suggesting you do so.
Also, action=expandtemplates will now have prop=modules, jsconfigvars, and
encodedjsconfigvars available.
This change should be deployed to WMF wikis with 1.26wmf9, see
https://www.mediawiki.org/wiki/MediaWiki_1.26/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
On Wed, Jun 3, 2015 at 10:04 AM, Brian Gerstle <bgerstle(a)wikimedia.org>
wrote:
> My question is: why does the default behavior need to change? Wouldn't
> continuing with the default behavior allow people to continue using the
> "rawcontinue" behavior for as long as we want to support it—without making
> any changes?
>
The decision to change the default came out of the same concerns that led
to the improved action=help output and some of the other work I've been
doing lately: We want to lower the barriers for using our API, which means
that the default shouldn't be something user-hostile.
The raw continuation is deceptively simple: it looks straightforward, but
if you're using it with a generator, multiple prop modules, and meta or
list modules, your client code has to know when to ignore the returned
continuation for the generator, when to remove a module from prop and then
when to re-add it, and when to remove the meta or list modules. I wouldn't
be that surprised to learn that more people have it wrong than correct if
their code supports using prop modules with generators.
The new continuation actually is simple: you send the equivalent of
array_merge( $originalParams, $continueParams ) and it just works.
Yes, some of the same could be said for making format=json&formatversion=2
the default. In this case the formatversion=1 output is just annoying
rather than actually hostile (although representing boolean true as a
falsey string comes close), so at this time there's no plan to make that
breaking change.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
I feel that bot operators should actively pay attention to the technical
aspects of the community and the mailing lists. So, the bot operator who
never updates their software, doesn't pay attention to the announcements,
and ignores api warnings should be blocked after the deadline. Bot
operators do not operate in a vacuum, and should never run bots just for
the sake of running them.
Community should always be able to find and communicate with the bot
operators.
Obviously we should not make sudden changes (except in the
security/breaking matters), and try to make the process as easy as
possible. The rawcontinue param is exactly that, simply adding it will keep
the logic as before.
Lastly, I again would like to promote the idea discussed at the hackathon
-- a client side minimalistic library that bigger frameworks like pywikibot
rely on, and that is designed in part by the core developers. See the
proposal at
https://www.mediawiki.org/wiki/Requests_for_comment/Minimalistic_MW_API_Cli…
On Jun 3, 2015 2:29 PM, "John Mark Vandenberg" <jayvdb(a)gmail.com> wrote:
> On Wed, Jun 3, 2015 at 3:42 AM, Brad Jorsch (Anomie)
> <bjorsch(a)wikimedia.org> wrote:
> > ...
> > I've compiled a list of bots that have hit the deprecation warning more
> > than 10000 times over the course of the week May 23–29. If you are
> > responsible for any of these bots, please fix them. If you know who is,
> > please make sure they've seen this notification. Thanks.
>
> Thank you Brad for doing impact analysis and providing a list of the
> 71 bots with more than 10,000 problems per week. We can try to solve
> those by working with the bot operators.
>
> If possible, could you compile a list of bots affected at a lower
> threshold - maybe 1,000. That will give us a better idea of the scale
> of bots operators that will be affected when this lands - currently in
> one months time.
>
> Will the deploy date be moved back if the impact doesnt diminish by
> bots being fixed?
>
> --
> John Vandenberg
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
As has been announced several times (most recently at
https://lists.wikimedia.org/pipermail/wikitech-l/2015-April/081559.html),
the default continuation mode for action=query requests to api.php will be
changing to be easier for new coders to use correctly.
*The date is now set:* we intend to merge the change to ride the deployment
train at the end of June. That should be 1.26wmf12, to be deployed to test
wikis on June 30, non-Wikipedias on July 1, and Wikipedias on July 2.
If your bot or script is receiving the warning about this upcoming change
(as seen here
<https://www.mediawiki.org/w/api.php?action=query&list=allpages>, for
example), it's time to fix your code!
- The simple solution is to simply include the "rawcontinue" parameter
with your request to continue receiving the raw continuation data (
example
<https://www.mediawiki.org/w/api.php?action=query&list=allpages&rawcontinue=1>).
No other code changes should be necessary.
- Or you could update your code to use the simplified continuation
documented at https://www.mediawiki.org/wiki/API:Query#Continuing_queries
(example
<https://www.mediawiki.org/w/api.php?action=query&list=allpages&continue=>),
which is much easier for clients to implement correctly.
Either of the above solutions may be tested immediately, you'll know it
works because you stop seeing the warning.
I've compiled a list of bots that have hit the deprecation warning more
than 10000 times over the course of the week May 23–29. If you are
responsible for any of these bots, please fix them. If you know who is,
please make sure they've seen this notification. Thanks.
AAlertBot
AboHeidiBot
AbshirBot
Acebot
Ameenbot
ArnauBot
Beau.bot
Begemot-Bot
BeneBot*
BeriBot
BOT-Superzerocool
CalakBot
CamelBot
CandalBot
CategorizationBot
CatWatchBot
ClueBot_III
ClueBot_NG
CobainBot
CorenSearchBot
Cyberbot_I
Cyberbot_II
DanmicholoBot
DeltaQuadBot
Dexbot
Dibot
EdinBot
ElphiBot
ErfgoedBot
Faebot
Fatemibot
FawikiPatroller
HAL
HasteurBot
HerculeBot
Hexabot
HRoestBot
IluvatarBot
Invadibot
Irclogbot
Irfan-bot
Jimmy-abot
JYBot
Krdbot
Legobot
Lowercase_sigmabot_III
MahdiBot
MalarzBOT
MastiBot
Merge_bot
NaggoBot
NasirkhanBot
NirvanaBot
Obaid-bot
PatruBOT
PBot
Phe-bot
Rezabot
RMCD_bot
Shuaib-bot
SineBot
SteinsplitterBot
SvickBOT
TaxonBot
Theo's_Little_Bot
W2Bot
WLE-SpainBot
Xqbot
YaCBot
ZedlikBot
ZkBot
--
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