Template talk:If preview

Merge with Ifpreview

@Evad37: 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)

Preview warning and hatnotes moving to templatestyles

Page watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles Izno (talk) 23:57, 28 April 2021 (UTC)

Fix documentation please

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)

resolved: this pertains to the Module documentation, not this template. -DePiep (talk) 07:53, 22 June 2021 (UTC)

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)

@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)

_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)

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)

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)

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)

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)

Template-protected edit request on 28 March 2024

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)

{{Done}}. SilverLocust 💬 19:54, 31 March 2024 (UTC)

@Awesome Aasim: 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:

Script warning: templatename used with unknown parameter(s): paramname.
Script warning: templatename used with deprecated parameter(s): paramname.
Script warning: templatename used with duplicate parameter(s): paramandvalue.

(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.)

Example

​

(m. 2020)​

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)

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)

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)

Template-protected edit request on 29 August 2024

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)

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)

 Done — Martin (MSGJ · talk) 19:58, 9 September 2024 (UTC)