⚓ T198758 Load .json configuration files via ResourceLoaderWikiModule

⚓ T198758 Load .json configuration files via ResourceLoaderWikiModule
Page Menu
Phabricator
Create Task
Maniphest
T198758
Load .json configuration files via ResourceLoaderWikiModule
Closed, Resolved
Public
Actions
Edit Task
Edit Related Tasks...
Create Subtask
Edit Parent Tasks
Edit Subtasks
Merge Duplicates In
Close As Duplicate
Edit Related Objects...
Edit Commits
Edit Mocks
Mute Notifications
Protect as security issue
Assigned To
SD0001
Authored By
Tgr
Jul 3 2018, 8:20 PM
2018-07-03 20:20:22 (UTC+0)
Tags
MediaWiki-ResourceLoader
(Accepted Enhancement)
MediaWiki-extensions-Gadgets
(Backlog)
Performance-Team
(Blocked (old))
MW-1.38-notes (1.38.0-wmf.16; 2022-01-03)
User-notice-archive
(Backlog)
Referenced Files
None
Subscribers
AfroThundr3007730
Aklapper
Amorymeltzer
BethNaught
DannyS712
deryckchan
Galobtter
View All 27 Subscribers
Description
We are trying to limit JS editing to as few accounts as possible to reduce the likelihood of XSS compromises (
T190015
); configuration should be moved to JSON files to remain widely available for editing. There is no way currently to load a JSON page with ResourceLoader though; loading with AJAX has suboptimal performance. There should be a more efficient way to load such files.
One concrete use case is
the geonotice config
on enwiki; this should be moved to JSON but loading it blocks banner display so performance is key.
Current AJAX-based method
getJSON
mw
util
getUrl
'MediaWiki:Citoid-template-type-map.json'
action
'raw'
).
then
function
data
console
log
'The data is:'
data
);
);
Details
Related Changes in Gerrit:
Subject
Repo
Branch
Lines +/-
Support JSON files in gadgets
mediawiki/extensions/Gadgets
master
+218
-45
resourceloader: Disable supportsURLLoading() for packaged wiki modules
mediawiki/core
master
+8
-0
resourceloader: Add support for JSON pages in ResourceLoaderWikiModule
mediawiki/core
master
+110
-14
Customize query in gerrit
Related Objects
Search...
Task Graph
Mentions
Status
Subtype
Assigned
Task
Resolved
SD0001
T198758
Load .json configuration files via ResourceLoaderWikiModule
Resolved
Catrope
T133462
Provide standard-compatible way to load multi-file packages (not plain concatenation)
Mentioned In
T300000: Use capitallinkoverride for gadget namespace
T298834: Create separate user right for editing json files in gadget namespace
T298334: Validations for gadget definitions
T190015: Create separate user group for editing sitewide CSS/JavaScript that does not include administrators by default
Mentioned Here
T156210: Support translation of JSON blobs in Translate
T133462: Provide standard-compatible way to load multi-file packages (not plain concatenation)
T190015: Create separate user group for editing sitewide CSS/JavaScript that does not include administrators by default
Event Timeline
There are a very large number of changes, so older changes are hidden.
Show Older Changes
MusikAnimal
awarded a token.
Jul 3 2018, 8:24 PM
2018-07-03 20:24:18 (UTC+0)
MusikAnimal
subscribed.
MGChecker
subscribed.
Jul 3 2018, 8:58 PM
2018-07-03 20:58:01 (UTC+0)
Imarlier
moved this task from
Inbox, needs triage
to
Backlog: Maintenance, non-prioritized
on the
Performance-Team
board.
Jul 9 2018, 8:06 PM
2018-07-09 20:06:31 (UTC+0)
Jdforrester-WMF
subscribed.
Jul 18 2018, 8:29 AM
2018-07-18 08:29:27 (UTC+0)
stjn
subscribed.
Jul 20 2018, 5:26 PM
2018-07-20 17:26:29 (UTC+0)
Comment Actions
As another example where this would be helpful: in Russian Wikipedia sysops and bureaucrats frequently edit
a gadget for showing users with advanced groups
so that it would stay up-to-date. If there won’t be a more comfortable solution such as JSON, quite a lot people might argue either for workarounds that undermine security (such as content model change?) or for giving those rights to them by default when they don’t really edit any other pages.
Krinkle
subscribed.
Edited
Jul 20 2018, 5:48 PM
2018-07-20 17:48:45 (UTC+0)
Comment Actions
Two quick thoughts:
Interface: We'll need a find a transport method for the JSON file, and a way for the JS code to read its contents. It's probably best to build this on top of
T133462
, which would provide a built-in way for multiple files to be exported by a module (rather than concatenated). The read method could be something like
require('./foo.json')
Edit rights: While inclusion of JSON files seems useful, I do not think we should have separate edit rights for the JS/CSS file of a gadget and the JSON files.
Krinkle
added a comment.
Jul 20 2018, 5:50 PM
2018-07-20 17:50:13 (UTC+0)
Comment Actions
In
T198758#4441617
@stjn
wrote:
As another example where this would be helpful: in Russian Wikipedia sysops and bureaucrats frequently edit
MediaWiki:Gadget-markadmins.js
You might be interested in the bot that Wikimedia Commons uses for
MediaWiki:Gadget-markAdmins-data.js
stjn
added a comment.
Jul 20 2018, 5:54 PM
2018-07-20 17:54:45 (UTC+0)
Comment Actions
In
T198758#4441675
@Krinkle
wrote:
You might be interested in the bot that Wikimedia Commons uses for
MediaWiki:Gadget-markAdmins-data.js
It is a viable solution, but there are some user groups for us that are present only in the name, like ArbCom members and clerks.
Krinkle
triaged this task as
Low
priority.
Jul 20 2018, 6:52 PM
2018-07-20 18:52:17 (UTC+0)
Krinkle
moved this task from
Inbox
to
Accepted Enhancement
on the
MediaWiki-ResourceLoader
board.
Krinkle
moved this task from
Backlog: Maintenance, non-prioritized
to
Blocked (old)
on the
Performance-Team
board.
BethNaught
subscribed.
Jul 23 2018, 11:49 AM
2018-07-23 11:49:12 (UTC+0)
IKhitron
subscribed.
Jul 24 2018, 12:56 PM
2018-07-24 12:56:42 (UTC+0)
Tgr
added a comment.
Jul 27 2018, 2:12 PM
2018-07-27 14:12:56 (UTC+0)
Comment Actions
In
T198758#4441652
@Krinkle
wrote:
Edit rights: While inclusion of JSON files seems useful, I do not think we should have separate edit rights for the JS/CSS file of a gadget and the JSON files.
JS/CSS is dangerous in the hands of a malicious user, JSON not really. For Gadgets 2.0, not sure if there is any use case for different people editing the JSON files and the rest; current permissions are just how MediaWiki: pages are handled, and I think it's reasonable to make JSON editing available to more users there, as it tends to be used for bot control and such (not necessarily in gadgets).
Translation might be a use case for wider access, although
T156210: Support translation of JSON blobs in Translate
is the nicer solution there.
Jack_who_built_the_house
subscribed.
Aug 1 2018, 9:03 PM
2018-08-01 21:03:09 (UTC+0)
SerDIDG
subscribed.
Aug 1 2018, 9:04 PM
2018-08-01 21:04:12 (UTC+0)
MBH
subscribed.
Aug 2 2018, 11:41 AM
2018-08-02 11:41:44 (UTC+0)
Jack_who_built_the_house
added a comment.
Edited
Aug 2 2018, 12:05 PM
2018-08-02 12:05:14 (UTC+0)
Comment Actions
Right now many people who ask for
interface-admin
(see
T190015
) permissions in ruwiki are worried about the ability to edit gadgets data. But with the current state where the integration of JSON with gadgets is poor, the ability to load external JSON for gadgets is very limited. Hence, the efforts to integrate JSON with ResourceLoader as soon as possible are essential from the perspective of the
interface-admin
flag purpose.
Tgr
added a comment.
Aug 2 2018, 12:36 PM
2018-08-02 12:36:28 (UTC+0)
Comment Actions
For 99% of gadgets ResourceLoader integration makes little difference. geonotice is unusually performance-sensitive but something like the admin coloring gadget is not. Just loading it via a plain API query with a short smaxage should be fine.
Jack_who_built_the_house
added a comment.
Aug 2 2018, 3:20 PM
2018-08-02 15:20:46 (UTC+0)
Comment Actions
Right now we have at least 3 widely used gadgets that would need such query, probably there will be more. Having 5–10 additional requests doesn't seem to make negligable difference. Many such gadgets also add elements that shift content on pages which in turn causes misclicks, so the earlier they run the better. Anyway, is it so difficult to implement? I thought splitting large JS files into modules according to the semantics of different code parts and loading them, together with other modules, in one package is exactly what ResourceLoader is for.
Krinkle
added a subtask:
T133462: Provide standard-compatible way to load multi-file packages (not plain concatenation)
Aug 2 2018, 3:47 PM
2018-08-02 15:47:25 (UTC+0)
Krinkle
changed the task status from
Open
to
Stalled
Aug 2 2018, 4:19 PM
2018-08-02 16:19:49 (UTC+0)
Comment Actions
Please remember that I have accepted the feature request, but this will not be implemented in the short-term while other projects take priority.
Regarding the efficiency issues, nobody is being forced to use a JSON page fetched over AJAX. In fact, I would recommend against it for exactly the reasons you state. Fetching it would be inefficient, makes the code harder to maintain, and would render more slowly.
So, for today - use a JS page instead. That is the current best practice, and is supported by ResourceLoader. Place the data on a JS page (not a JSON page). They work the same way, in the same namespace, with the same protection level. The JSON would be prepended by a simple statement, such as
MyGadget.data = { }
MyGadget.setData({ })
or
mw.hook('myGadget.data').fire({ })
. ResourceLoader, through Gadgets, can already combine these into a single bundle - together with the rest of the gadget - in a single request.
@Jack_who_built_the_house
Anyway, is it so difficult to implement?
Concatenating the plain text as saved onto a
.js
page and a
.json
page together would be easy, but the result would be invalid syntax. It will not work the way you want. To do this, we need to build a communication channel between
load.php
(server-side) and
mw.loader
(client-side) for sending this data, and then we need to build a way for your gadget JS code to find the data.
Task
T133462
is about building that channel (for multiple chunks of JS code). Once that exists, we can also use that channel for JSON data. To find the data, we will build a
require()
function that will work similar to what many web developers have seen in other environments (Node.js, AMD, UMD, etc.). This makes it easy to learn from tutorials that explain JavaScript in general (instead of new things to learn just for Gadgets on Wikipedia).
@Jack_who_built_the_house
the efforts to integrate JSON with ResourceLoader as soon as possible are essential from the perspective of the
interface-admin
flag purpose.
Sorry, but I do not understand the link between JSON integration and
interface-admin
We currently have a single group ("sysop") that grants the ability to protect pages, block users, and modify and deploy software (Gadgets) saved to JS and CSS pages. This has many downsides: Communities have to entrust a user with all of it, or nothing. Hackers compromising an admin account will be capable of all the above, even if the admin only intended to use one or the other.
Separating these groups, has benifits:
Reduce security risk: Users will only ask the rights they wanted. Community stays in control of granting the rights.
Communities can give sysop rights without worrying about cybersecurity.
Communities can give interface-admin rights without worrying about deletion/blocking policy and trusted activity in that area. I have seen several times that very good volunteer developers was active as software developer, but not as general editor/content reviewer. This makes it difficult to become sysop.
Tgr
added a comment.
Aug 2 2018, 4:36 PM
2018-08-02 16:36:24 (UTC+0)
Comment Actions
In
T198758#4472884
@Krinkle
wrote:
They work the same way, in the same namespace, with the same protection level.
JS requires
editsitejs
which is soon going to be restricted to
interface-admin
. JSON requires
editsitejson
which sysops will keep (and it has a separate grant for OAuth that does not involve sitewide JS editing permissions).
Jack_who_built_the_house
added a comment.
Aug 2 2018, 4:41 PM
2018-08-02 16:41:12 (UTC+0)
Comment Actions
@Krinkle
Thanks for the detailed explanation.
@Tgr
Yes, that's the link between JSON integration and
interface-admin
that I'm talking about. Right now we have 1) gadgets data on JS pages, 2) sysops actively editing some of this data. So, people ask for
interface-admin
flag that they could do without if the gadgets data was on JSON pages.
Tgr
added a comment.
Aug 2 2018, 5:05 PM
2018-08-02 17:05:27 (UTC+0)
Comment Actions
I guess you could attempt a horrible hack where you change the content model of a JS page to wikitext and transclude the JSON into it (and wrap with a variable assignment). No idea if it would actually work though...
KTC
subscribed.
Aug 8 2018, 2:40 PM
2018-08-08 14:40:48 (UTC+0)
Skalman
subscribed.
Aug 10 2018, 7:43 PM
2018-08-10 19:43:32 (UTC+0)
Tommy_Kronkvist
subscribed.
Aug 10 2018, 8:42 PM
2018-08-10 20:42:51 (UTC+0)
TheDJ
subscribed.
Aug 14 2018, 11:05 AM
2018-08-14 11:05:10 (UTC+0)
Xaosflux
subscribed.
Aug 16 2018, 6:13 PM
2018-08-16 18:13:33 (UTC+0)
Pharos
subscribed.
Aug 27 2018, 5:52 PM
2018-08-27 17:52:18 (UTC+0)
Amorymeltzer
subscribed.
Aug 30 2018, 2:54 PM
2018-08-30 14:54:22 (UTC+0)
deryckchan
subscribed.
Aug 30 2018, 9:57 PM
2018-08-30 21:57:33 (UTC+0)
RP88
subscribed.
Aug 30 2018, 10:03 PM
2018-08-30 22:03:44 (UTC+0)
Izno
subscribed.
Sep 22 2018, 8:19 PM
2018-09-22 20:19:45 (UTC+0)
Comment Actions
en.wp has proposed to have a bot
sync from an admin-protected
page. Obviously, we need to make sure there is consensus, but once we establish that, I suspect that we may be able to run it on other wikis.
ToBeFree
awarded a token.
Sep 23 2018, 4:10 AM
2018-09-23 04:10:18 (UTC+0)
ToBeFree
subscribed.
AfroThundr3007730
subscribed.
Sep 23 2018, 5:58 AM
2018-09-23 05:58:49 (UTC+0)
Xaosflux
added a comment.
Sep 30 2018, 4:31 AM
2018-09-30 04:31:13 (UTC+0)
Comment Actions
@Izno
Please note, we think making a bot to sync json pages to js pages is far from ideal, and having this be able to work server-side in a way that "data" can be edited outside of "code" would be much preferred. For anyone following you can check on the bot build progress here:
Galobtter
subscribed.
Feb 5 2019, 9:54 AM
2019-02-05 09:54:13 (UTC+0)
Krinkle
closed subtask
T133462: Provide standard-compatible way to load multi-file packages (not plain concatenation)
as
Resolved
Feb 7 2019, 3:20 AM
2019-02-07 03:20:28 (UTC+0)
Krinkle
changed the task status from
Stalled
to
Open
Feb 19 2019, 9:59 PM
2019-02-19 21:59:28 (UTC+0)
Krinkle
edited projects, added
Performance-Team (Radar)
; removed
Performance-Team
Comment Actions
(No longer blocked/stalled per
T133462
. ) Moving to radar as this isn't currently resourced through a specific product need.
Krinkle
moved this task from
Limbo
to
Watching
on the
Performance-Team (Radar)
board.
Feb 19 2019, 9:59 PM
2019-02-19 21:59:36 (UTC+0)
DannyS712
subscribed.
Mar 22 2019, 5:45 AM
2019-03-22 05:45:30 (UTC+0)
DannyS712
added a comment.
Mar 22 2019, 5:48 AM
2019-03-22 05:48:29 (UTC+0)
Comment Actions
I don't know if this is useful, but I wrote a javascript function ("get_JSON" at
) to parse a JSON page and return a JSON object (as opposed to plain text).
Nirmos
subscribed.
Mar 22 2019, 6:16 AM
2019-03-22 06:16:54 (UTC+0)
Comment Actions
There is
$.getJSON
SerDIDG
added a comment.
Mar 22 2019, 6:23 AM
2019-03-22 06:23:52 (UTC+0)
Comment Actions
@DannyS712
, additionally to previous comment, there is a simple way to get raw page content -
DannyS712
added a comment.
Edited
Mar 22 2019, 6:28 AM
2019-03-22 06:28:00 (UTC+0)
Comment Actions
Well nevermind then
those don't appear to work on foreign wikis due to constraints about cross-wiki requests
Krinkle
updated the task description.
(Show Details)
Mar 22 2019, 10:39 PM
2019-03-22 22:39:18 (UTC+0)
Krinkle
updated the task description.
(Show Details)
Krinkle
edited projects, added
MediaWiki-extensions-Gadgets
; removed
MediaWiki-User-Interface
Apr 7 2021, 3:16 PM
2021-04-07 15:16:41 (UTC+0)
Comment Actions
Re-framing specifically about gadgets and RL support in the WikiModule class.
For other site/user scripts, this is unlikely to happen as it would require additional modules to be registered and has imho too little added value over action=raw imports. Note that if/when user scripts themselves can be a proper module, with a definition somewhere, then this would naturally work by basically being a "
personal gadget
".
SD0001
claimed this task.
Oct 17 2021, 11:49 AM
2021-10-17 11:49:23 (UTC+0)
gerritbot
added a comment.
Oct 17 2021, 4:22 PM
2021-10-17 16:22:42 (UTC+0)
Comment Actions
Change 731283 had a related patch set uploaded (by SD0001; author: SD0001):
[mediawiki/core@master] Support JSON files in ResourceLoaderWikiModule
gerritbot
added a project:
Patch-For-Review
Oct 17 2021, 4:22 PM
2021-10-17 16:22:43 (UTC+0)
Comment Actions
Change 731284 had a related patch set uploaded (by SD0001; author: SD0001):
[mediawiki/extensions/Gadgets@master] Support JSON files in gadgets
MBH
unsubscribed.
Oct 17 2021, 4:58 PM
2021-10-17 16:58:10 (UTC+0)
Krinkle
edited projects, added
Performance-Team
; removed
Performance-Team (Radar)
Nov 18 2021, 10:01 PM
2021-11-18 22:01:36 (UTC+0)
gerritbot
added a comment.
Dec 16 2021, 4:50 PM
2021-12-16 16:50:41 (UTC+0)
Comment Actions
Change 731283
merged
by jenkins-bot:
[mediawiki/core@master] resourceloader: Add support for JSON pages in ResourceLoaderWikiModule
ReleaseTaggerBot
added a project:
MW-1.38-notes (1.38.0-wmf.16; 2022-01-03)
Dec 16 2021, 5:00 PM
2021-12-16 17:00:27 (UTC+0)
SerDIDG
awarded a token.
Dec 17 2021, 3:15 AM
2021-12-17 03:15:58 (UTC+0)
gerritbot
added a comment.
Dec 21 2021, 4:35 PM
2021-12-21 16:35:56 (UTC+0)
Comment Actions
Change 749207 had a related patch set uploaded (by SD0001; author: SD0001):
[mediawiki/core@master] resourceloader: Disable supportsURLLoading() for packaged wiki modules
gerritbot
added a comment.
Dec 21 2021, 11:20 PM
2021-12-21 23:20:14 (UTC+0)
Comment Actions
Change 749207
merged
by jenkins-bot:
[mediawiki/core@master] resourceloader: Disable supportsURLLoading() for packaged wiki modules
SD0001
added a comment.
Dec 24 2021, 6:08 PM
2021-12-24 18:08:49 (UTC+0)
Comment Actions
Notes on testing the patch:
Add gadget definition in MediaWiki:Gadgets-definition:
*json-test [ ResourceLoader | default | package ] | json-test.js | json-test.json
Create MediaWiki:Gadget-json-test.js:
console.log('in json-test.js');
var data = require('./json-test.json');
console.log(data);
Create MediaWiki:Gadget-json-test.json:
{ "key": "value", "key2": "value2"}
You should now see the json data showing up in the console.
SD0001
mentioned this in
T298334: Validations for gadget definitions
Dec 27 2021, 3:51 PM
2021-12-27 15:51:36 (UTC+0)
TheDJ
added a comment.
Dec 28 2021, 4:31 PM
2021-12-28 16:31:10 (UTC+0)
Comment Actions
reminder, we need to update the various documentation pages.
gerritbot
added a comment.
Dec 28 2021, 4:46 PM
2021-12-28 16:46:57 (UTC+0)
Comment Actions
Change 731284
merged
by jenkins-bot:
[mediawiki/extensions/Gadgets@master] Support JSON files in gadgets
Maintenance_bot
removed a project:
Patch-For-Review
Dec 28 2021, 5:10 PM
2021-12-28 17:10:21 (UTC+0)
TheDJ
closed this task as
Resolved
Dec 28 2021, 8:58 PM
2021-12-28 20:58:07 (UTC+0)
Izno
added a project:
User-notice
Dec 28 2021, 9:13 PM
2021-12-28 21:13:54 (UTC+0)
Comment Actions
This might be worth announcing in Tech News, something along the lines of:
"Gadgets will soon be able to have json files as explicit dependencies. This change allows basic configuration to be modified by administrators without the interface administrator permission, such as with the Geonotice gadget."
JJMC89
moved this task from
To Triage
to
In current Tech/News draft
on the
User-notice
board.
Dec 28 2021, 9:57 PM
2021-12-28 21:57:24 (UTC+0)
TheDJ
added a comment.
Dec 28 2021, 10:19 PM
2021-12-28 22:19:28 (UTC+0)
Comment Actions
Added to
and updated
IKhitron
added a comment.
Dec 29 2021, 3:24 AM
2021-12-29 03:24:50 (UTC+0)
Comment Actions
So, what's the right page name, mydata.json or Gadget-mydata.json as usual?
stjn
added a comment.
Dec 29 2021, 4:51 PM
2021-12-29 16:51:24 (UTC+0)
Comment Actions
Might be a good idea to mention somewhere (in Tech News item?) that gadget writers should exercise caution and make sure not to use strings from these pages as unescaped HTML.
Jack_who_built_the_house
added a comment.
Edited
Dec 30 2021, 3:53 AM
2021-12-30 03:53:52 (UTC+0)
Comment Actions
Now that this lucky day is near (great credit to SD0001), I want to remind that, with this patch, MediaWiki makes a small step to reduce the attack surface involving Interface admins. After data is moved to
.json
that is bundled with the gadget, people who hold this flag solely due to a need to edit some data stored in JS will no longer need it and can have their permissions revoked with no worries.
Quiddity
subscribed.
Jan 6 2022, 9:36 PM
2022-01-06 21:36:51 (UTC+0)
Comment Actions
Tech News entry - It currently says this in
Please edit it, if needed, within the next 24 hours.
(p.s. Thanks to Izno for drafting and JJMC89 for adding!)
Gadgets are now able to have JSON files as explicit dependencies. This change allows basic configuration to be modified by administrators without the interface administrator permission, such as with the Geonotice gadget.
Docs link - I would like to link that Tech News entry to some specific (and translatable) docs, so that people can find more info.
I am not sure which of these 3 (or other?) pages to link to. Please advise?
: (p.s. Thanks to
@TheDJ
for updating the first two!)
Docs updates - I see
2 questions above
from IKhitron and stjn that possibly need to be answered, and the answers documented in the appropriate wikipage(s). Please could someone help with that?
IKhitron
added a comment.
Jan 6 2022, 9:48 PM
2022-01-06 21:48:11 (UTC+0)
Comment Actions
I think I already get an answer from these links. Although, I coudn't make all this work yet.
IKhitron
added a comment.
Jan 7 2022, 2:17 PM
2022-01-07 14:17:05 (UTC+0)
Comment Actions
Well, FYI. It works now, and the problem was misleading documentation of the new future. It's better to rewrite it, I think. To tell about file names, about try and catch, and more.
TheDJ
added a comment.
Jan 8 2022, 12:33 AM
2022-01-08 00:33:51 (UTC+0)
Comment Actions
Well, FYI. It works now, and the problem was misleading documentation of the new future. It's better to rewrite it, I think. To tell about file names, about try and catch, and more.
Go right ahead.
TheDJ
added a comment.
Jan 8 2022, 12:44 AM
2022-01-08 00:44:09 (UTC+0)
Comment Actions
In
T198758#7602980
@Quiddity
wrote:
Docs link - I would like to link that Tech News entry to some specific (and translatable) docs, so that people can find more info.
I am not sure which of these 3 (or other?) pages to link to. Please advise?
: (p.s. Thanks to
@TheDJ
for updating the first two!)
I'd go for this one.
Docs updates - I see
2 questions above
from IKhitron and stjn that possibly need to be answered, and the answers documented in the appropriate wikipage(s). Please could someone help with that?
So, what's the right page name, mydata.json or Gadget-mydata.json as usual?
Page names are Gadget-mydata.json. But Gadget- is a prefix (almost a namespace) that the gadget system itself doesn't see. So in the gadget definitions and when using require() you refer to that page as mydata.json. This is all described on
and
Might be a good idea to mention somewhere (in Tech News item?) that gadget writers should exercise caution and make sure not to use strings from these pages as unescaped HTML.
Something like: Interface admins should review that all data used from these json files is properly escaped where needed by the gadget.
SD0001
mentioned this in
T298834: Create separate user right for editing json files in gadget namespace
Jan 8 2022, 4:37 PM
2022-01-08 16:37:25 (UTC+0)
Sakretsu
awarded a token.
Jan 8 2022, 5:53 PM
2022-01-08 17:53:56 (UTC+0)
Quiddity
moved this task from
In current Tech/News draft
to
Already announced/Archive
on the
User-notice
board.
Jan 13 2022, 10:04 PM
2022-01-13 22:04:05 (UTC+0)
SD0001
mentioned this in
T300000: Use capitallinkoverride for gadget namespace
Jan 25 2022, 9:30 AM
2022-01-25 09:30:44 (UTC+0)
Ladsgroup
edited projects, added
User-notice-archive
; removed
User-notice
Aug 13 2022, 1:54 PM
2022-08-13 13:54:58 (UTC+0)
Log In to Comment
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct.
Wikimedia Foundation
Code of Conduct
Disclaimer
CC-BY-SA
GPL
Credits