https://bugzilla.wikimedia.org/show_bug.cgi?id=40124
--- Comment #29 from Bartosz Dziewoński <[email protected]> --- (In reply to comment #28) > Indeed. This bug is imho either wontfix of duplicate of bug 21897. I have already said it, but I will repeat – this is intended not only for gadgets, but also (or even primarily) for user scripts, as there isn't even a notion of gadgets in core MediaWiki. > Gadgets 2.0 is being implemented and the preferences work has also seen a lot > of progress. It isn't an idea, it is a branch with a lot of work already put > into it. Where? There isn't even a mention at https://www.mediawiki.org/wiki/Extension:Gadgets . Is it being tested somewhere? Is it actually runnable? Is it going to be deployed to Wikimedia wikis within, say, a month? A year? A lot of work was already put into Perl 6. Doesn't mean it will happen anywhere soon. > I doesn't make sense to implement this in MediaWiki core because nobody will > be > maintaining it, and it will not be used by core itself or any extension. It > would be a temporary solution that will only solve a very small part of the > problem (what about backend validation and sanitisation, front-end user > interface to set, read and manage the settings, registry/namespace to avoid > conflicts with other gadgets etc.) > - you can't do this in mediawiki core without facing the fact that we would > be > expecting that gadget authors do all the above themselves - for every gadget. I have already said this, I will repeat for you: there is https://pl.wikipedia.org/wiki/MediaWiki:Gadget-gConfig.js , which implements all of what you've written above that is possible to implement client-side, and has documentation in English (in the code) and in Polish (at [[w:pl:WP:Narzędzia/gConfig]]). If you wish to use it in MW core, I can release it under the GNU GPL (in addition to the other licenses). We can't do 'backend validation and sanitisation' for user JS. Nor can we do 'registry/namespace to avoid conflicts with other gadgets'. It's just not possible, unless you change the very basic idea here to no longer be user scripts. > Instead, keep the current situation: use cookies or localStorage or whatever > it > is you're using. Native preferences don't exist yet, too bad. They're on > their > way. What doesn't exist can't be used, but rushing the track with another > temporary solution that only solves part of the probelm - side-by-side - does > not solve the problem. Cookies and localStorage have the important issue that they're not transferred to other computers, and they can be pretty easily lost, which is unacceptable for user preferences. "Native" preferences don't have any of these flaws. > You're more than welcome to help out with the implementation in the Gadgets > extension that will provide all of this natively, but avoid more temporary > solutions that we can't support that we know will lead to unstable > security/usability. The "unstable security" you're talking about here seems to be just fear mongering, unless you can provide examples of what you're talking about that can't be accomplished without the use of the preferences. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
