At the moment, in mw.site.interwikiMap, URLs stored in the database
with relative protocols are converted to http or https depending
on the protocol of the user who last requested that the page be parsed.
However, this URL isn't updated for users pulling pages from the page
cache, so they may see links with an incorrect protocol. Module authors
can work round this by using mw.uri objects and the isProtocolRelative
property, but it would be simpler just to use relative URLs from the
outset.
Change-Id: If0a169cfd1597e09706fc0e6d5cdcc821ba8d06a
This makes the interwiki map available to Lua modules. The code is
based on the API interwiki map code in core (the appendInterwikiMap
method of includes/api/ApiQuerySiteInfo.php.) Everything that the
API includes is added, apart from iw_api and iw_wikiid, which I
couldn't think of a use for from Lua modules.
Accessing the interwiki map would be useful for modules like
enwiki's Module:InterwikiTable,[1] as it would stop module writers
having to duplicate the data.
[1] https://en.wikipedia.org/wiki/Module:InterwikiTable
Change-Id: Ie8ad2582aaf5e422824f7da51714a347bb4041d1
Scribunto currently supports libraries with PHP callbacks that are
loaded on startup, and pure-Lua libraries that may be loaded from the
module with require().
This change allows for libraries with PHP callbacks to also be loaded
with require().
Change-Id: Ibdc1f4ef51b1c8644c3d4c98d57755b5c06447a5
If someone goes and adds aliases for namespaces that don't actually
exist (as was done in I94c34799, for example), Scribunto will run into
issues when trying to create its mw.site.namespace objects.
Let's ignore those bogus aliases so we don't go breaking everything just
because someone did something stupid.
Change-Id: I16acd97f587de320cf61becb829cc66794cbb119
The PHP call that makes mw.site.namespaces work case-insensitively
doesn't handle non-standard spaces/underscores. So standardize them
before the call.
Bug: 56216
Change-Id: I4758478b126858fb581614f64eb15472f42fef51
Users are reporting disappointment that using pairs on title objects
doesn't let them see the fields available. It's easy enough to add a
__pairs metamethod to allow pairs to work on title objects, so let's do
that.
The same can be done for mw.uri objects.
For mw.message objects, we can easily enough change the implementation
to be like mw.language objects, which doesn't have this problem.
For mw.site.stats, we may as well just remove the load-on-demand feature
since it will be demanded as soon as the environment is cloned for the
first module.
Change-Id: Ie5a3b5684b2bb6c090f9994baa03977687688929