Module talk:Page

example

{{#invoke:Page|id|Nazi Party}} generates:

21736

Modified by Gangleri (talk) 12:39, 17 December 2015 (UTC)[reply]

wgCurRevisionId

att: / cc: @Darklama, @Liangent, @Wnt Hi! It is possible to add wgCurRevisionId to the list of parameters? One application is described under note a) at https://wiki.riteme.site/?curid=14574453#shortest_url . Kind regards Gangleri (talk) 12:39, 17 December 2015 (UTC)[reply]

Script errors

@Petr Matas: I'm trying to understand your recent changes to Module:Page which look great in principle but which have a glitch that is generating script errors in articles (current list).

In callAssert, what is this?

    local result = { func(...) }

I would have expected use of pcall. The following join should be string.concat table.concat and that is the immediate problem. If I get some time later I will try following instinct and replace the above with pcall. Johnuniq (talk) 00:06, 18 August 2018 (UTC)[reply]

On a closer look, I see that pcall was not wanted. The code is not catching an error in the call, it's detecting whether the call returned nil. Even closer inspection showed that throwing error() is not wanted either. I have never seen this module or its templates (apparently {{Correct title}} and {{Pageid to title}}) before so my quick work needs checking. However, {{Correct title}} uses #iferror to test certain things and the error span class returned in the text is caught by #iferror. Throwing an error puts the article in Category:Pages with script errors which is very undesirable. At any rate I fixed the immediate problem and the number of articles in the error category is down from 88 to 14. I'll investigate those 14 in due course. Johnuniq (talk) 02:25, 18 August 2018 (UTC)[reply]

The line local result = { func(...) } stores the (possibly multiple) values returned from the function in a table. Its counterpart is return unpack(result), which returns the contents of the table as multiple values.

To avoid throwing an error from the module, I have encapsulated the entire main in pcall. This way we can keep using error(), I hope. Thus, pcall at other places becomes unnecessary. Petr Matas 09:47, 18 August 2018 (UTC)[reply]

That looks good. To avoid a maze of dependencies I wouldn't call Module:Error but I agree it has the advantage of being only one place to accommodate any change to how the error class works in the future. In callAssert there is no reason to use mw.ustring.format rather than the more efficient string.format. However, that's unimportant. I was going to add that the error category is now empty but I see that a problem in another module has filled it up again! Keeps me employed. Johnuniq (talk) 10:11, 18 August 2018 (UTC)[reply]