Page MenuHomePhabricator

Allow page-specific inclusion of <script>s, etc. in header
Closed, ResolvedPublic


Author: ayg

Consider It would be tremendously
useful on all sorts of pages . . . but it requires 6 KB of Javascript to be
included. Not good. Consider, however, if the code could be added by an admin
to a special namespace, say [[Include:Sorttable.js]], and then the text
"{{Include:Sorttable.js}}" would add that page's wikitext to the page in
question via a <script> in the header? Any page where a sortable table would be
used could include that, for great increase and functionality with no needless
bandwidth loss.

Obviously, only certain specially-designated pages could be included, namely
ones in the Include: namespace. The file would presumably be Javascript, but it
could be applied to CSS as well if that would be useful to someone.

Version: 1.20.x
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:20 PM
bzimport set Reference to bz6883.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

Now feasible thanks to ParserOutput::$mHeadItems et al.

rd232 wrote:

*** Bug 31958 has been marked as a duplicate of this bug. ***

Yes, Bug 31958 (marked as duplicate) contains some scenarios. The above-mentioned include namespace should be the existing Mediawiki: namespace, but what is still missing is a parserfunction that injects a javascript from Mediawiki-namespace into a specific article page, to support custom functionalities developed by the community according to community needs for specific purposes.

This issue is coming up repeatedly still, when enhanced functionality is only needed on one page that is directly visited. If the page is visited by a link, the ?withJS link directive solve the challenge mostly, but doesn't work when visiting the page. Very hacky gadgets have been used where the gadget runs by default and checks every single page "am I on this one special page, if so run this script" - needlessly running that on every page. While gadgets work for things that are highly repeated well, minor cases still suffer. Would like to see this get implemented along the lines of <templatestyles>, and would be fine with keeping the same restrictions on ?withJS (i.e. file must be in the MediaWiki space).

Aklapper lowered the priority of this task from Medium to Low.Mar 10 2020, 2:15 AM

I think this should be two different extensions, one that would add pages like MediaWiki:Main.js and MediaWiki:Template.js that would run in specific namespaces. This extension would also have pages like MediaWiki:Main.css and MediaWiki:Template.css for loading styles into specific namespaces. This would be similar to the MediaWiki:Vector.js and MediaWiki:Vector.css pages. This would be called NamespaceScripts.

The other extension would add the <templatescripts> tag that would allow JavaScript in the MediaWiki namespace to be run on the pages with the tag. This would be similar to Extension:TemplateStyles but for JavaScript and would be called TemplateScripts.

I was originally thinking this should be one extension, but it wouldn't make sense to no have the CSS pages like MediaWiki:Main.css and MediaWiki:Template.css.

Or I guess support for pages and namespaces options could be added to Extension:Gadgets so the gadget is only loaded when needed.

"namespace" might be ok for gadgets, but having to load lists of pages in to gadgets seems like a bad strategy

"namespace" might be ok for gadgets, but having to load lists of pages in to gadgets seems like a bad strategy

I figured that, so I think it's best to have the namespaces option for gadgets to add css and js to namespaces and the templatescripts extension for individual pages. Although I think the pages option for gadgets might be useful for gadgets that modify specific pages such as AfD or for gadgets that add custom pages to Special:Blankpage.

An application of this feature came up on en-WP here.

The extension UseResource is now available, it allows for the inclusion of both JavaScript and CSS in the MediaWiki namespace.

@BrandonXLF has the new extension undergone the Wikimedia-extension-review-queue review process that seems to be necessary to have it added on any WMF projects (would want to test in testwiki first)

Xaosflux changed the task status from Open to Stalled.Feb 20 2021, 10:17 AM

So I guess this will be blocked on T275272

@Xaosflux: I don't see why that would be blocking? This task is about the MediaWiki software itself, not about some Wikimedia websites.

@Aklapper - good point, suppose that extension's creation could be the resolution of this (maybe once it leaves "beta" as it is currently marked) - doubt this will go to core as even TemplateStyles is an extension?

Aklapper changed the task status from Stalled to Open.Feb 20 2021, 5:55 PM
Krinkle claimed this task.
Krinkle added a subscriber: Krinkle.

I'm declining this as core feature request since it is asking for a very specific technical solution that many years ago was already effectively decided not to be implemented, but has effectively been solved another way already more than 10 years ago, and also improved and iterated upon may times since then.

This task originates from our bugzilla install and was created there in 2006. Shortly after in 2007, the "Gadgets" extension was created which allowed end-users to create scripts on the wiki which users could opt-in to. There is also now the option to enable gadgets by default (see And things like "MediaWiki:Common.js" also still exist which allow for more powerful and complex loading strategies based on categories or templates used. For example, some wikis use this to append a special editnotice parameter to the Edit link for BLP articles. With these aforementioned capabilities, one can essentially do everything imaginable already.

While this task originally suggested a relation to user scripts, its examples for sorting tables and collapsing elements are actually core features. And the performance concern there was addressed in 2011 when ResourceLoader introduced a module system to MediaWiki with core, skins and extensions community having the ability to load these on a page-by-page bases via the OutputPage::addModules() method.

To improve performance of gadgets with conditional loading, we can already do this via "MediaWiki:Common.js" to encode the conditional strategy there, or use an "init + core" split gadget where one loads the other. A proposal exists to provide a shortcut for making this easier to do within the Gadgets extension. This can be discussed further at T63007.

@Krinkle forgive me if I misread you, but if your suggestion is to load common.js up with a list of conditionals for "if page = x" or "if page contains x" for any page this could be desired on that seems like a lot of overhead, not to mention scalability, as this would have to run on every single page view - am I missing something there? How is this not equivalent to templatestyles vs common.css?

if your suggestion is to load common.js up with a list of conditionals for "if page = x" or "if page contains x" for any page this could be desired on that seems like a lot of overhead, not to mention scalability, as this would have to run on every single page view - am I missing something there?

I was describing something that works today. Optimisations don't exist in isolation and conditionally loading is just that: an optimisation. It's worth it (in the current system) to sometimes use a condition in Common.js as alternative to unconditionally loading the entire gadget and its dependencies on every page view. I think downloading one line of code for every gadget we decide not to load scales better than always loading all gadgets and all dependencies.

But, its not perfection indeed, and that's why tasks like T63007 exist and are open.