Last modified: 2014-09-01 09:41:39 UTC
When exporting a wiki page as PDF, the PDF file contains a section called "License". At least for pages under a Creative Commons License, this includes an URL to the text of the license. This URL is plain text (not hyperlinked) and contains no protocol specifier (//creativecommons.org/licenses/by-sa/3.0/ instead of http://creativecommons.org/licenses/by-sa/3.0/). While this may be an instance of protocol neutral links, I think that it would be more helpful if these were complete links (starting with either http:// or https://). Browsers generally seem to interpret links starting with a slash as file:// links (at least on Linux). How to reproduce: 1) Go to http://www.mediawiki.org/ or http://en.wikipedia.org/. 2) In the sidebar, click "Print/export" and then "Download as PDF" 3) Wait for the rendering to finish and download the PDF 4) Open the PDF file, scroll to the last page and look at the "License" section
Protip for whoever implements this: It should basically be an instance of finding any links prefixed with "//" in the page and replacing it with a proper link. It shouldn't be all too difficult. If one of the Collection devs agrees, I'd like to add the "easy" keyword here.
The license text is configurable - therefore I propose to change the text to include a protocol for the URL. Currently the link is not even detected being a link (b/c of the missing protocol) therefore I can't simply add the protocol to the link. And I am reluctant to use a regex on all of the license text and replace stuff that looks like a link without a protocol.
This is because by default mw-rights-url is used. If the system can't handle protocol relative urls, just put it trough wfExpandUrl( url, PROTO_CURRENT ), before outputting; Or actually, due to possible lack of protocol awareness in caching layer of PDF rendered documents, it should probably be wfExpandUrl( url, PROTO_HTTP ); This makes me wonder however about the protocol relative capabilities of the rest of the renderer. We have these things all over the place.
https://gerrit.wikimedia.org/r/31069
changeset abandoned
Patch abandoned only because followup questions were not answered by reviewers, e.g. "WHICH configuration variable is used to import that fragment".
*** Bug 46891 has been marked as a duplicate of this bug. ***
