Per the below, protocol-relative URLs are now enabled on
test.wikipedia.org and will be rolled out to the rest of the wikis
over the course of the next few weeks. What this means is that URLs
used in the interface will now look like //example.com instead of
http://example.com , so we can support both HTTP and HTTPS without
splitting our cache.
The API, in most cases, will not output protocol-relative URLs, but
will continue to output http:// URLs no matter whether you call it
over HTTP or HTTPS. This is because we don't expect API clients to be
able to resolve these correctly, and that the context of these URLs
(which is needed to resolve them) will frequently get lost along the
way. And we don't wanna go breaking clients, now, do we? :)
The exceptions to this, as far as I am aware, are:
* HTML produced by the parser will have protocol-relative URLs in <a
href="..."> tags etc.
* prop=extlinks and list=exturlusage will output URLs verbatim as they
appear in the article, which means they may output protocol-relative
URLs
If you are getting protocol-relative URLs in some other place, that's
probably a bug (or maybe it's intentional and I forgot to list it
here), so please let me know, or e-mail this list, or file bug, if you
see that happening.
Roan Kattouw (Catrope)
---------- Forwarded message ----------
From: Ryan Lane <rlane32(a)gmail.com>
Date: Thu, Jul 14, 2011 at 8:55 PM
Subject: [Wikitech-l] Protocol-relative URLs enabled on test.wikipedia.org
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Over the past couple days Roan Kattouw and I have been pushing out
changes to enable protocol-relative URL support. We've gotten to a
point where we think it is stable and working.
We've enabled this on test.wikipedia.org, and plan on running it for
two weeks before enabling it elsewhere. Please test if everything is
working properly, especially with regards to the API and bots. Report
bugs in bugzilla if any are found.
- Ryan
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Forwarding to the announce list. Apologies to the mediawiki-api list
for double-posting.
---------- Forwarded message ----------
From: Bryan Tong Minh <bryan.tongminh(a)gmail.com>
Date: Thu, Oct 6, 2011 at 10:14 PM
Subject: Re: [Mediawiki-api] [Mediawiki-api-announce] API XML output
now has a namespace
To: mediawiki-api(a)lists.wikimedia.org
Cc: MediaWiki API announcements & discussion
<mediawiki-api-announce(a)lists.wikimedia.org>
On Thu, Oct 6, 2011 at 1:47 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:
> Per https://bugzilla.wikimedia.org/show_bug.cgi?id=24781 , the XML
> output returned by the API has a namespace since 1.18.
>
Per the discussion on the bug, this list, and elsewhere, I have
reverted the unconditional addition of the XML namespace. Once r99135
[1] has been deployed, the API will no longer output an XML namespace
unless the includexmlnamespace has been set.
Bryan
[1] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/99135
Per https://bugzilla.wikimedia.org/show_bug.cgi?id=24781 , the XML
output returned by the API has a namespace since 1.18.
1.17: <api>
1.18: <api xmlns="http://www.mediawiki.org/xml/api/">
Apparently this breaks for some people using XPATH expressions,
although comments on Bugzilla indicated this shouldn't be the case,
and since I don't know anything about XML namespaces I trusted my
fellow MW devs who said it wouldn't be a problem :)
Roan
With MediaWiki 1.18 now being deployed to WMF wikis (the final set of
wikis is slated to get 1.18 tonight starting at 23:00 UTC), I've heard
reports of people using list=categorymembers&cmnamespace=6 and getting
an empty result, even though there are files in the category. This is
a symptom of the cmnamespace workaround that was introduced about two
years ago.
However, we now have the cmtype parameter that can be used to replace
most uses of cmnamespace, and doesn't suffer from any of its flaws (no
nasty hacks to work around slow DB queries, no incomplete or empty
results):
To only list files, use &cmtype=file (previously &cmnamespace=6)
To only list subcategories, use &cmtype=subcat (previously &cmnamespace=14)
To only list 'normal' pages that aren't files or subcategories, use
&cmtype=page (previously
&cmnamespace=0|1|etc|everything|except|six|and|fourteen)
You can combine values for cmtype, e.g. &cmtype=file|subcat to list
both files and subcategories. The default value for cmtype is
file|subcat|page (i.e. list everything).
Roan