Page MenuHomePhabricator
Search Advanced Search
    • Diffusion Commit
    • ·Closed
    Improve error messages in mw.html This sets the location of errors raised by mw.html.lua to the calling module, rather than inside mw.html.lua itself. Some errors also now display the type and position in the argument list of the argument that caused the error, via the new verifyString function. This should make it easier for module writers to locate errors in their code. Also, the format of the error changes has been switched from "Error message: Explanation" to "error message (explanation)", in line with other Scribunto library error messages. Type errors generated with verifyString have been changed to "bad argument #n in 'html:foo' (expected bar, got baz)", in line with the checktype function in the libraryUtil library. Change-Id: If9cf9a52bd4b1bb42cc7f9f1f1096828710cbc52
    • Diffusion Commit
    • ·Closed
    Improve error messages in mw.html Use the libraryUtil functions to do type checking in mw.html. This sets the location of errors raised by mw.html.lua to the calling module rather than inside mw.html.lua itself, which should make it easier for module writers to locate errors in their code. Some functions in mw.html accept multiple types, so add a checkTypeMulti function to libraryUtil.lua to make these kinds of functions easy to check. And while we're at it, add test cases for libraryUtil.lua as well. Change-Id: If9cf9a52bd4b1bb42cc7f9f1f1096828710cbc52
    • Diffusion Commit
    • ·Closed
    Improve error messages in mw.html Add more information to error messages in mw.html. This includes the error level, the function name, and the position of the argument in the argument list. Where possible, use the functions in libraryUtil.lua to do this. Some functions in mw.html accept multiple types, so add a checkTypeMulti function to libraryUtil.lua to make these kinds of functions easy to check. And while we're at it, add test cases for libraryUtil.lua as well. Change-Id: If9cf9a52bd4b1bb42cc7f9f1f1096828710cbc52
    • Diffusion Commit
    • ·Closed
    Improve error messages in mw.html Add more information to error messages in mw.html. This includes the error level, the function name, and the position of the argument in the argument list. Where possible, use the functions in libraryUtil.lua to do this. Some functions in mw.html accept multiple types, so add a checkTypeMulti function to libraryUtil.lua to make these kinds of functions easy to check. And while we're at it, add test cases for libraryUtil.lua as well. Change-Id: If9cf9a52bd4b1bb42cc7f9f1f1096828710cbc52
    • Diffusion Commit
    • ·Closed
    Improve error messages in mw.html Add more information to error messages in mw.html. This includes the error level, the function name, and the position of the argument in the argument list. Where possible, use the functions in libraryUtil.lua to do this. Some functions in mw.html accept multiple types, so add a checkTypeMulti function to libraryUtil.lua to make these kinds of functions easy to check. And while we're at it, add test cases for libraryUtil.lua as well. Change-Id: If9cf9a52bd4b1bb42cc7f9f1f1096828710cbc52
    • Diffusion Commit
    • ·Closed
    Improve error messages in mw.html Add more information to error messages in mw.html. This includes the error level, the function name, and the position of the argument in the argument list. Where possible, use the functions in libraryUtil.lua to do this. Some functions in mw.html accept multiple types, so add a checkTypeMulti function to libraryUtil.lua to make these kinds of functions easy to check. And while we're at it, add test cases for libraryUtil.lua as well. Change-Id: If9cf9a52bd4b1bb42cc7f9f1f1096828710cbc52
    • Diffusion Commit
    • ·Closed
    Improve error messages in mw.html Add more information to error messages in mw.html. This includes the error level, the function name, and the position of the argument in the argument list. Where possible, use the functions in libraryUtil.lua to do this. Some functions in mw.html accept multiple types, so add a checkTypeMulti function to libraryUtil.lua to make these kinds of functions easy to check. And while we're at it, add test cases for libraryUtil.lua as well. Change-Id: If9cf9a52bd4b1bb42cc7f9f1f1096828710cbc52
    • Diffusion Commit
    • ·Closed
    Add mw.site.interwikiMap 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
    • Diffusion Commit
    • ·Closed
    Add mw.site.interwikiMap 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
    • Diffusion Commit
    • ·Closed
    Use protocol-relative URLs in mw.site.interwikiMap At the moment relative URLs returned by mw.site.interwikiMap use the protocol for the current incoming request rather than a true relative URL. However, allowing the same property to have different values for different users breaks the cache consistency and may be confusing for module writers. This change fixes this by using true relative URLs. Change-Id: If0a169cfd1597e09706fc0e6d5cdcc821ba8d06a
    • Diffusion Commit
    • ·Closed
    Standardise URI query fields with multiple values This patch standardises the handling of URI query fields with multiple values in the mw.uri library. This involves two things: 1. Altering mw.uri.buildQueryString to produce foo[0]=bar&foo[1]=baz, instead of foo=bar&foo=baz. (The square brackets are HTML-encoded.) 2. For query arrays passed from Lua to PHP, normalise array values to start from 0, not 1. Bug: T93059 Change-Id: I3ed9529deb7a63dbabdc58d7afb3b0cea9307a7f
    • Diffusion Commit
    • ·Closed
    Standardise URI query fields with multiple values This patch standardises the handling of URI query fields with multiple values in the mw.uri library. This involves two things: 1. Altering mw.uri.buildQueryString to produce foo[0]=bar&foo[1]=baz, instead of foo=bar&foo=baz. (The square brackets are HTML-encoded.) 2. For query arrays passed from Lua to PHP, normalise array values to start from 0, not 1. Bug: T93059 Change-Id: I3ed9529deb7a63dbabdc58d7afb3b0cea9307a7f
    • Diffusion Commit
    • ·Closed
    Remove undocumented parseQueryString parameters The i and j parameters to mw.uri.parseQueryString are not documented, and aren't used anywhere else in Scribunto. They are also overwritten by default values near the start of the function, so their use seems to be limited. It's probably best just to remove them. Change-Id: I11241e0f6be262d199f272381706e03c60dbf5f1
    • Diffusion Commit
    • ·Closed
    Standardise URI query formatting This patch standardises URI queries in the mw.uri library so that they have the same formatting as URI queries generated from PHP. In particular: 1. For duplicate keys, mw.uri.buildQueryString now produces foo[0]=bar&foo[1]=baz, instead of foo=bar&foo=baz. (The square brackets are URI-encoded.) 2. mw.uri.buildQueryString can now handle nested query tables. mw.uri.buildQueryString{ foo = { bar = { baz = 'qux' } } } will now produce "foo[bar][baz]=qux". (Again, square brackets are URI-encoded.) 3. mw.uri.parseQueryString can now handle keys like "foo[]", "foo[0]" and "foo[bar][baz]". 4. Query arrays passed to PHP from Lua are normalised to start at 0, not 1. Bug: T93059 Change-Id: I3ed9529deb7a63dbabdc58d7afb3b0cea9307a7f
    • Diffusion Commit
    • ·Closed
    Standardise URI query formatting This patch standardises URI queries in the mw.uri library so that they have the same formatting as URI queries generated from PHP. In particular: 1. For duplicate keys, mw.uri.buildQueryString now produces foo[0]=bar&foo[1]=baz, instead of foo=bar&foo=baz. (The square brackets are URI-encoded.) 2. mw.uri.buildQueryString can now handle nested query tables. mw.uri.buildQueryString{ foo = { bar = { baz = 'qux' } } } will now produce "foo[bar][baz]=qux". (Again, square brackets are URI-encoded.) 3. mw.uri.parseQueryString can now handle keys like "foo[]", "foo[0]" and "foo[bar][baz]". 4. Query arrays passed to PHP from Lua are normalised to start at 0, not 1. Bug: T93059 Bug: T105851 Change-Id: I3ed9529deb7a63dbabdc58d7afb3b0cea9307a7f
    • Diffusion Commit
    • ·Closed
    Standardise URI query formatting This patch standardises URI queries in the mw.uri library so that they have the same formatting as URI queries generated from PHP. In particular: 1. For duplicate keys, mw.uri.buildQueryString now produces foo[0]=bar&foo[1]=baz, instead of foo=bar&foo=baz. (The square brackets are URI-encoded.) 2. mw.uri.buildQueryString can now handle nested query tables. mw.uri.buildQueryString{ foo = { bar = { baz = 'qux' } } } will now produce "foo[bar][baz]=qux". (Again, square brackets are URI-encoded.) 3. mw.uri.parseQueryString can now handle keys like "foo[]", "foo[0]" and "foo[bar][baz]". 4. Query arrays passed to PHP from Lua are normalised to start at 0, not 1. Bug: T93059 Bug: T105851 Change-Id: I3ed9529deb7a63dbabdc58d7afb3b0cea9307a7f
    • Diffusion Commit
    • ·Closed
    Standardise URI query formatting This patch standardises URI queries in the mw.uri library so that they have the same formatting as URI queries generated from PHP. In particular: 1. For duplicate keys, mw.uri.buildQueryString now produces foo[0]=bar&foo[1]=baz, instead of foo=bar&foo=baz. (The square brackets are URI-encoded.) 2. mw.uri.buildQueryString can now handle nested query tables. mw.uri.buildQueryString{ foo = { bar = { baz = 'qux' } } } will now produce "foo[bar][baz]=qux". (Again, square brackets are URI-encoded.) 3. mw.uri.parseQueryString can now handle keys like "foo[]", "foo[0]" and "foo[bar][baz]". 4. Query arrays passed to PHP from Lua are normalised to start at 0, not 1. Bug: T93059 Bug: T105851 Change-Id: I3ed9529deb7a63dbabdc58d7afb3b0cea9307a7f
    • Diffusion Commit
    • ·Closed
    Standardise URI query formatting This patch standardises URI queries in the mw.uri library so that they have the same formatting as URI queries generated from PHP. In particular: 1. For duplicate keys, mw.uri.buildQueryString now produces foo[0]=bar&foo[1]=baz, instead of foo=bar&foo=baz. (The square brackets are URI-encoded.) 2. mw.uri.buildQueryString can now handle nested query tables. mw.uri.buildQueryString{ foo = { bar = { baz = 'qux' } } } will now produce "foo[bar][baz]=qux". (Again, square brackets are URI-encoded.) 3. mw.uri.parseQueryString can now handle keys like "foo[]", "foo[0]" and "foo[bar][baz]". 4. Query arrays passed to PHP from Lua are normalised to start at 0, not 1. Bug: T93059 Bug: T105851 Change-Id: I3ed9529deb7a63dbabdc58d7afb3b0cea9307a7f
    • Diffusion Commit
    Use the new registration format Convert PageBlock.php to extension.json as detailed at https://www.mediawiki.org/wiki/Manual:Extension_registration Change-Id: I97933aea8a73b33ad8b0cc18d1ec27e85f5213e5
    • Diffusion Commit
    Updated mediawiki/extensions Project: mediawiki/extensions/PageBlock 87d61c6412c5377817e08dd074f44c9a5953b209 Use the new registration format Convert PageBlock.php to extension.json as detailed at https://www.mediawiki.org/wiki/Manual:Extension_registration Change-Id: I97933aea8a73b33ad8b0cc18d1ec27e85f5213e5
    • Diffusion Commit
    Fix accidental global in mw.uri.parseQueryString The result of the type function should be compared against the string "table", not the global variable. This bug probably went undetected until now, as "table" is also the global variable for the Lua table library. Change-Id: Ia28fa10388bfc587d95b522bfa8f3524b4a3ee5f
    • Diffusion Commit
    Updated mediawiki/extensions Project: mediawiki/extensions/Scribunto d59d8522902b61990376c8b41e4a7d0463cbd6f7 Fix accidental global in mw.uri.parseQueryString The result of the type function should be compared against the string "table", not the global variable. This bug probably went undetected until now, as "table" is also the global variable for the Lua table library. Change-Id: Ia28fa10388bfc587d95b522bfa8f3524b4a3ee5f
    • Diffusion Commit
    Add a getter method for ComboBoxWidget text inputs Without a getter method, there doesn't seem to be an obvious way to get the combo box's text widget without resorting to using the "input" property, which presumably should be kept private. Bug: T102205 Change-Id: I306f12cf86c1285edd36999f5bd95595cd7ee08d
    • Diffusion Commit
    Add a vagrant role for the SandboxLink extension Change-Id: I276e5e133033c6cacaf5dabff71c1184ce5d02bf
    • Diffusion Commit
    Updated mediawiki/extensions Project: mediawiki/extensions/Scribunto ad34c2bd941c760ffc3639108ee807032a70bffe Use protocol-relative URLs in mw.site.interwikiMap 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
    • Diffusion Commit
    Updated mediawiki/extensions Project: mediawiki/extensions/Scribunto c58c528d289d274c09542715c176c697884565bc Add mw.site.interwikiMap 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
    • Diffusion Commit
    Updated mediawiki/extensions Project: mediawiki/extensions/Scribunto 98f25aa9a19fed33140d04e5a60a89effa2a926e Improve error messages in mw.html Add more information to error messages in mw.html. This includes the error level, the function name, and the position of the argument in the argument list. Where possible, use the functions in libraryUtil.lua to do this. Some functions in mw.html accept multiple types, so add a checkTypeMulti function to libraryUtil.lua to make these kinds of functions easy to check. And while we're at it, add test cases for libraryUtil.lua as well. Change-Id: If9cf9a52bd4b1bb42cc7f9f1f1096828710cbc52
    • Diffusion Commit
    Use protocol-relative URLs in mw.site.interwikiMap 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
    • Diffusion Commit
    Add mw.site.interwikiMap 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
    • Diffusion Commit
    Improve error messages in mw.html Add more information to error messages in mw.html. This includes the error level, the function name, and the position of the argument in the argument list. Where possible, use the functions in libraryUtil.lua to do this. Some functions in mw.html accept multiple types, so add a checkTypeMulti function to libraryUtil.lua to make these kinds of functions easy to check. And while we're at it, add test cases for libraryUtil.lua as well. Change-Id: If9cf9a52bd4b1bb42cc7f9f1f1096828710cbc52
    • Diffusion Commit
    Simplify mw.text.listToText Simplify the logic in mw.text.listToText so that we don't need to add or remove anything from the original table we were passed. Change-Id: I3efcbba1b9adc9a9e32e366e355cb742376cd91b