Community Wishlist Survey 2021/Bots and gadgets/Allow loading gadgets from wikitext
The survey has concluded. Here are the results!
Allow loading gadgets from wikitext
- Proposed solution: Have a parser tag similar to TemplateStyles that includes a ResourceLoader module indicated in its argument.
- More comments: Care should be taken in order not to allow arbitrary code to be loaded by untrusted users (the parser tag in wikitext can be added and edited even by anonymous users). While the contents of ResourceLoader modules can be changed by only select people, probably the safest solution is to create a “namespace” (e.g.
ext.gadget.includeable.*) for this purpose within gadgets, and disallow loading any other RL module. Disallowed modules can be loaded by making them dependencies of allowed gadgets. (Dependency is safe, as gadget dependencies can be edited only by trusted interface admins.)
- Phabricator tickets: phab:T17075 from 2008, T241524
- Proposer: Tacsipacsi (talk) 00:49, 26 November 2020 (UTC)
- An alternative could be to have one default hidden gadget with the classnames/criteria -> script loading sequences... —TheDJ (talk • contribs) 12:53, 26 November 2020 (UTC)
- Comment I think as proposed this would make security and performance very difficult to uphold. However the idea of allowing a gadget to be enabled "by default" but limited to a subset of pages makes sense. We already support narrowing the default by skin, platform, and user rights. We could for example add support for limiting to categories. Then to initiate it from a template one would add the article to a (hidden) category. This would place the security control with the gadget configuration (the gadget definition specifies its categories, the page does not directly require a gadget), and would also encourage more re-usable logic with less effort (e.g. many articles and templates already have existing categories that you can make use of). It also means gadgets can be merged, split or renamed without their loading breaking as there would not be a direct connection between the two. Perhaps the proposal could be edited to focus more focussed on the problem and use case, and leave the implementation details to be decided by developers and other stakeholders if/when it is worked on. --Krinkle (talk) 20:30, 11 December 2020 (UTC)
- Adding a ResourceLoader module from a parser function doesn't seem problematic to me performance-wise; a number of parser hooks already do that. In terms of security, the only issue I can think of is that it must not allowed to work on "safe" pages like login (via a system message; probably it shouldn't work in system messages at all).
- Categories would be nice for tracking where a script is used, but we could also just (ab)use the templatelinks table like we do for TemplateStyles. Tgr (talk) 08:51, 13 December 2020 (UTC)
- @Krinkle: If we were to use categories to decide whether or not to load a gadget, renaming gadgets would be easier, but renaming categories would be more difficult—and the consequences are far less obvious, fixing a typo in a category name would stop the gadget from working for no apparent reason. Furthermore, if one renames a category, they probably won’t be able to adjust the gadget configuration afterwards (as they’re not necessarily an interface admin). Also, gadget naming is an internal detail completely transparent for users, while category names are user-visible, so they’re much more likely needed to be changed. I think gadget renaming is already mostly impossible, as there’s no other permanent identifier for gadgets, so renaming a gadget would likely revert it back to its initial state for everyone (i.e. turn it on in case of default gadget, turn it off otherwise). I see your concerns (although I agree with Tgr in that they’re unlikely to be actual issues), but the point of easing renames is simply false IMO. Split and merger is probably really more convenient with the category-based system, but it still doesn’t outweigh the renaming issues. Also, I don’t like polluting the categories with such technicalities.
- Security-wise: what issue do you think would appear that isn’t handled by the proposed tag-based system, but would be handled by your category-based one? IAs are already in control of what could be possibly loaded (with the namespace system), while what’s actually loaded can be controlled by anyone anyway (through adding either the parser tag or the category).
- @Tgr: Entirely disabling it in messages could be the way to go, but Common.js is also disabled in these contexts, so there should be a way in MW core to determine whether risky RL modules can be loaded. (There are some MediaWiki messages like s:MediaWiki:proofreadpage_index_template that are practically templates stored in the MediaWiki namespace, and may benefit from this feature. I don’t know if these can be programmatically distinguished from the cookie prompt on the login page, which should certainly not have anything like this.) —Tacsipacsi (talk) 21:43, 14 December 2020 (UTC)
- I think it would be better to implement phab:T204201.
- That has much broader capabilities and gives more benefit at various circumstances.
- The common approach is to look for elements with certain classes after DOM has been loaded, then proceed. If that could be narrowed to a particular namespace it would save a lot of client execution time already.
- Using a category, even a hidden maintenance category, might distract attention of editors. Equipping some elements with a class is very silent.
- However, the improvements suggested in phab:T204201 may introduce more Cirrus filters like
transcludes). They should use underscore page titles and leave spaces as separators.
- The target is to reduce the amount of gadgets to be loaded in a page but could never be useful under predictable and easily detectable conditions.
- I don’t think it is promising to introduce new Wikisyntax, new elements, new parser functions for making page contents triggering gadget execution. There are page properties and various criteria in T204201 which will deliver the same result but with less efforts and wider applicability.
--PerfektesChaos (talk) 14:21, 18 March 2021 (UTC)
- Support Would be useful to have DannyS712 (talk) 18:02, 8 December 2020 (UTC)
- Support Sgd. —Hasley 18:31, 8 December 2020 (UTC)
- Support would be useful Teemeah (talk) 20:39, 8 December 2020 (UTC)
- Support Would be useful tufor (talk) 20:53, 8 December 2020 (UTC)
- Support Think I'd rather see a more generic such as extending templatestyle to templatescript ala phab:T8883 — xaosflux Talk 02:19, 9 December 2020 (UTC)
- Support Pols12 (talk) 02:20, 10 December 2020 (UTC)
- Support - yona B. (D) 07:12, 10 December 2020 (UTC)
- Support Aadarshashutosh (talk) 14:05, 10 December 2020 (UTC)
- Support Libcub (talk) 18:12, 10 December 2020 (UTC)
- Support BoldLuis (talk) 10:50, 11 December 2020 (UTC)
- Support James Martindale (talk) 17:48, 11 December 2020 (UTC)
- Support Ahecht (TALK
PAGE) 18:24, 11 December 2020 (UTC)
- Support SD0001 (talk) 20:37, 11 December 2020 (UTC)
- Support SkSlick (talk) 19:36, 12 December 2020 (UTC)
- Support Tgr (talk) 08:12, 13 December 2020 (UTC)
- Support Edgars2007 (talk) 09:47, 13 December 2020 (UTC)
- Support Kaviraf (talk) 20:01, 13 December 2020 (UTC)
- Support Terra ❤ (talk) 11:24, 14 December 2020 (UTC)
- Support Never do anything to large numbers of pages unless it's actually necessary. — SMcCandlish ☺ ☏ ¢ >ʌⱷ҅ᴥⱷʌ< 05:06, 15 December 2020 (UTC)
- Support This proposal combines the utility of having page scripts with the security and caution of eliminating overhead for irrelevant pages. Vanisaac (talk) 01:53, 16 December 2020 (UTC)
- Support Gustmd7410 (talk) 17:26, 19 December 2020 (UTC)
- Support Regardless of the pros and cons of implementation methods, this seems like a good idea suffering from bikeshedding neglect. Faster page loads are good, wasting bandwidth is wasting resources. This page load 14 scripts. HLHJ (talk) 00:23, 20 December 2020 (UTC)
- Support Samat (talk) 21:49, 20 December 2020 (UTC)