Jump to content

Template talk:If preview

From MTRNord's Wiki
(Redirected from Module talk:If preview)
Latest comment: 24 days ago by Zackmann08 in topic Visual editor not working with this

Template:Permanently protected

Merge with Ifpreview

Template:Ping Should Template:Ifpreview be merged into this? They do the exact same thing, although {{Ifpreview}} allows named arguments. That said, it's essentially unused, so maybe backwards compatibility doesn't matter. Daask (talk) 07:28, 28 March 2018 (UTC)Reply

Preview warning and hatnotes moving to templatestyles

Page watchers may be interested in Template:Slink Izno (talk) 23:57, 28 April 2021 (UTC)Reply

Fix documentation please

Template:Resolved

  • /doc now says: "use the main()". Which is incorrect (should be: main).
And: "use the _warning()". Which is incorrect (should be: _warning).


  • Also, there is no overview of parameters to be used. (how do I enter the _warning_text?).
-DePiep (talk) 18:57, 20 June 2021 (UTC)Reply
resolved: this pertains to the Module documentation, not this template. -DePiep (talk) 07:53, 22 June 2021 (UTC)Reply

Use in module

Re: Module:If preview

I tried to use _warning() in Module:Authority control/sandbox but the warning is displayed in-situ and not at the top of the page where it should be. Am I doing something wrong? — Martin (MSGJ · talk) 16:34, 30 December 2022 (UTC)Reply

@Izno can you advise on this please - did it used to work or am just misremembering something? — Martin (MSGJ · talk) 10:59, 19 July 2023 (UTC)Reply
_warning has always been placed at the location where the warning would normally be emitted. If you want it to appear at the top of the article only, mw.addWarning is the only function that does that. You may otherwise be confused here because outputs of _warning are most common due to infoboxes, which are always at the top of the page. Izno (talk) 16:14, 19 July 2023 (UTC)Reply
Quite possible that I am misremembering! Did you consider using mw.addWarning rather than the REVISIONID hack? — Martin (MSGJ · talk) 16:57, 19 July 2023 (UTC)Reply
REVISIONID is the supported way to check for preview and is how both this system's warning and ifpreview worked before I touched it.
Besides that, because mw.addWarning appears in a different place than in situ, and I know that people have been sensitive on the point before, that would be a consensus-needed to change.
Identical messages are also de-duplicated somewhere in addWarning's call stack. I don't know how relevant that is generally. See some previous discussion for CS1. Izno (talk) 17:16, 19 July 2023 (UTC)Reply
Useful, thanks. It seems that addWarning does not work with the live preview, which is a serious limitation — Martin (MSGJ · talk) 17:43, 19 July 2023 (UTC)Reply
Yes, I suppose that's true. It might be worth a task to see if it's even feasible to act on that. Izno (talk) 18:42, 19 July 2023 (UTC)Reply

Template-protected edit request on 28 March 2024

Template:Edit template-protected In the function p._warning please add before the return call: mw.addWarning(warning). This will put the preview warning at the top of the preview in addition to inline in the wikitext. Awesome Aasim 23:29, 28 March 2024 (UTC)Reply

{{Done}}. SilverLocust 💬 19:54, 31 March 2024 (UTC)Reply
Template:Reply The edit has been reverted because it resulted in Module:Parameter validation/default config emitting erroneous preview warnings. Templates like Template:Marriage and any others with {{#invoke:Parameter validation|validateparams|module_options = Module:Parameter validation/default config}} would always give the incorrect preview warnings:
Template:Tqb
(You can see the erroneous preview warnings with the example in the below quote box. Preview an edit of this section to see the warnings.)

Template:Quotebox

Apparently the options in the (default) config are evaluated when the options table is intially loaded in as a variable (i.e., before those options are actually needed, and even if they will not be needed), since those function calls aren't stored unevaluated in the table (e.g., as a string or sub-table). And evaluating those first three options involves calling _warning and thus (until the edit was reverted) calling mw.addWarning.
That being said, I am not presently sure how this should be fixed. SilverLocust 💬 06:00, 1 April 2024 (UTC) (and subsequently edited)Reply
Additionally, in looking now at the section above this, there is a comment that mw.addWarning should not be added here without consensus due to some previous sensitivity. (Part of why I thought this wouldn't be controversial was because Template:Preview warning/doc already said — erroneously — that the warning always appears at the top, and because it seemed self-evident that a "preview warning" should use MediaWiki's built-in preview warning function, mw.addWarning.) SilverLocust 💬 08:32, 1 April 2024 (UTC) (and subsequently edited)Reply
That sounds like bad code to me. The only other thing I can think of is maybe a module that when preprocessed emits the preview warning. A warning should not be emitted if there is a code problem, so calling the function beforehand creates a ton of headaches. If the config needs to fetch the default text for preview warnings it should be calling a getter to get the message not a function that builds the warning. Awesome Aasim 08:41, 1 April 2024 (UTC)Reply

Template-protected edit request on 29 August 2024

Template:Edit template-protected Please implement my changes in the sandbox.

I addressed some of the concerns above, and added a new function warn that calls both mw.addWarning and adds the warning to the preview, as well as consoleWarning. I also added Module:Arguments for better argument processing, and added a parameter "consolewarning" that would emit a warning in the "script warning" section of the edit window where it is desired. This should ensure backwards compatibility. Awesome Aasim 18:17, 29 August 2024 (UTC)Reply

Yes please! If using mw.addWarning() is for some reason controversial, the obvious solution is to do that via a separate function (or, I guess, an argument to an existing one). Flipping the default (making mw.addPreview() opt-out would make more sense, but seems more effort than it's worth. on enWP; on enWS where I import it I'd swap it in a heartbeat if I could without creating merge issues for myself). Xover (talk) 10:49, 1 September 2024 (UTC)Reply
Template:Done — Martin (MSGJ · talk) 19:58, 9 September 2024 (UTC)Reply

Edit request 15 July 2025

Template:Edit template-protected

Description of suggested change: Add support for dark mode.

Diff: (in Module:If preview/styles.css#L-7 Template:TextDiff Dabao qian (talk) 06:31, 15 July 2025 (UTC)Reply

Template:Done * Pppery * it has begun... 22:29, 16 July 2025 (UTC)Reply

Bug if transcluded?

Anyone else experience a bug where this module thinks a page is being previewed when the page is actually being transcluded. waddie96 ★ (talk) 10:07, 29 September 2025 (UTC)Reply

Visual editor not working with this

Template:Ping It has come to my attention that this super useful module does not seem to function with the Visual editor. This may need to raised as a bug with the editor rather then with this module, but I wanted to check here first... Is this something that can be resolved on this end? This is causing major headaches as people using the VE continue to introduce unknown parameters that they would know were unknown if the preview warning showed... Would love any insight you can share. (Courtesy ping to Template:U who made me aware of this issue). Zackmann (Talk to me/What I been doing) 18:41, 4 April 2026 (UTC)Reply

This is not something we can fix in wikitext. You will need to file a task about it. I do not know if it will be resolved or not. Izno (talk) 23:37, 5 April 2026 (UTC)Reply
Understood. Don't know enough about how these 2 work to know where the issue lies. Thanks for the guidance. Zackmann (Talk to me/What I been doing) 01:23, 6 April 2026 (UTC)Reply