Module talk:Page

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

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://en.wikipedia.org/?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

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.