Apparently assigning to $wgHooks at the top of the file breaks every
other hook, somehow. So we need to set it in setUp(), but prevent the
interwiki prefix from being queried beforehand when the dataProvider is
run. Fun.
Change-Id: I8535942e3a0e47d9a5b2ea11c1b0b63c5acf2cc5
* mw.ustring.sub( '', 1 ) errors in LuaStandalone
* Default value for ustring.maxStringLength and ustring.maxPatternLength
should be infinity, not nil
* mw.ustring.find() returns one value instead of two in "plain" mode.
Change-Id: I5e65c4ec3a05f0e6930ce7ab7fd4ac72bea95e7f
Remove unused parameters from the require() argument lists of two
modules, left over from an earlier phase of development.
Change-Id: Ib55d19fb9adffed2153a9cb3788533c4b70b5e26
getParser() sometimes returns null (eg: on saving edits). In that case,
don't try injecting link information into the (non-existent)
ParserOutput object.
Change-Id: Ief544922228615fbf674305bff95f874d56b7866
Clean up the modules in engines/LuaCommon/lualib:
* Fix luabit/bit.lua to return its table instead of trying to set the
global directly.
* Fix luabit/hex.lua to return its table instead of trying to set the
global directly.
* luabit/noki.lua is useless for our purposes
* luabit/utf8.lua is redundant to mw.ustring
* stringtools uses coroutines, which we don't support
Also fix a parser test that has apparently been broken for a long time.
Change-Id: I1284cddb6e9b94327964cb1077d8dbdf7def6d06
Note that fetching any title besides the one for the current page is
considered "expensive". It also records the title fetched in the
ParserOutput so it will be listed in pagelinks, just like #ifexists.
This also moves the ToString test formatter into TestFramework.lua, so
TitleLibraryTests.lua can use it too.
Change-Id: I799f3289a37fe1349b6bca5758829acf82cb718f
In phpunit 3.6.10, assertEquals considered two NaNs to be equivalent.
Somewhere between that and phpunit 3.7.14, this behavior changed so NaNs
are no longer considered equivalent.
Change-Id: I2c664498eb34cf5119a2eaaa96a6be57b821ab94
Add the ability for modules to be documented using a /doc subpage, which
is automatically transcluded onto the module page.
To get the transcluding to work right, I wound up having to change from
the deprecated-in-1.21 ArticleViewCustom hook to ContentHandler, as
there didn't seem to be any other way to get the ParserOutput into the
links tables. Which means Scribunto now needs MediaWiki 1.21 rather
than 1.20.
Change-Id: Id487097c2a505c11f92a3404f5d3ee98beb2570c
People sometimes want to load large tables of constant data from a
module. Using require(), this has to be reparsed every time, which can
be slow.
mw.loadData() will load the just data once, and return a table with a
metatable cleverly designed to give read-only access to the loaded data.
Change-Id: Icec192bdbe6cfca7902fd5cb5d0e217bd8399637
Subpages should probably be enabled by default for the Module namespace,
considering that we're planning on using /doc subpages for
documentation.
Change-Id: Ie9d192f807e8d5cd04484f6418fd5fa64e0d3117
Otherwise there is a circular reference and the engine is not destroyed
until the end of the request.
Change-Id: I9c98fe449c19d22e771e11d485e5516059c45329
Added a language library. Introduced functions which are easy and safe,
most of them already have parser function interfaces.
Change-Id: I4465150f3e16493a15a056f7ddb7787bdf3b0373
Allowing a module to call mw.makeProtectedEnvFuncs() lets it bypass the
allowEnvFuncs setting. It can also be used to manipulate the global
tables that other modules' sandboxes will be copied from.
And for paranoia's sake, let's tighten up what setfenv is allowed to
set. This requires changing a unit test, because it is no longer
sane to do something like
env.setfenv, env.getfenv = mw.makeProtectedEnvFuncs( { [env] = true }, {} )
Nothing real does this, it was only in the unit test.
Change-Id: I8e0d83bb0980ee869af3ac4413afd211717ca92f
The Lua manual says this:
For this function, a '^' at the start of a pattern does not work as an
anchor, as this would prevent the iteration.
I had interpreted that to mean that a pattern starting with '^' would
never match in gmatch. But further testing reveals that the '^' is just
treated as a literal character: string.gmatch( "foo ^bar baz", "^%a+" )
will match "^bar".
Change-Id: Id91d6ee2db753ce1d6a4f6ae27764691d9e9fdc4