Page MenuHomePhabricator

Allow per-page (e.g. by means of a tag on the page) Mediawiki-namespace-based javascript inclusion
Closed, DuplicatePublic


BACKGROUND: Mediawiki has very small core of php developers. As a CMS, it is ages behind the abilities of Drupal 7 or other current systems. Unless building on the strength of the wiki concept, improving the ability of community members to develop and deploy javascript editors etc. without requiring server access, Mediawiki may fall behind even further. With jQuery and the resource loader renovated, opportunities are now excellent to pursue this path.

Presently can be provided by php-developers (the small and - for good reason - tightly controlled community), by admins for all pages, or for individual users (self-created or as personally enabled widgets). For all pages is often too dangerous to become a basis for agile improvements, for one self is not very motivating.

ENHANCEMENT REQUEST: What may be be missing is a hook that enables Mediawiki-ns-based javascript on a specific page (apologies if I overlook an existing feature).

I propose to add a tag to load admin-provided scripts from the Mediawiki namespace. It could be
but should always be limited to the Mediawiki namespace.

Such javascript is only executed for page on which the tag is present (in practice, the tag will most likely be included through templates). This could be the ground on which more agile experiments can be run, and on which topic-specific functionality is deployed by the community for the community.

Version: 1.20.x
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:55 PM
bzimport set Reference to bz31958.
bzimport added a subscriber: Unknown Object (MLST).

Why would you want per-page JS? What kind of use case does this address that Gadgets doesn't already address?

Why would you want per-page JS? What kind of use case does this address that
Gadgets doesn't already address?

It would allow specific functionality needed only on certain pages to be tested and deployed only on these pages (and tested on yet a subset of those). This would allow specific code (interactive timeline, decision trees (click on on "Step-by-step identification" - the Javascript is needed only page having such a decision tree, but must be globally deployed), special galleries, etc.

The enable the community to develop functionality needed by the community that is either not foreseen by developers, or not implemented due to resource constraints.

Mediawiki is a publishing platform, but gadgets provide only authoring tools. Even there they are used only by a tiny fraction of editors. They are important and provide an agile development path for code later to be widely deployed. But I believe they don't cover any reader experience.

In fact, (not Gadget) is close to what I request here, so reviewing the suitability of this extension to be used on the large communities of Wikipedia would be one way of fulfilling this enhancement request.

rd232 wrote:

Wikimedia Commons has this functionality right now, via being included in Common.js. Try a random imagefile and stick &withJS=MediaWiki:VisualFileChange.js on the end of the URL.

That is interesting. But can you have a template on the page that automatically causes specific javascript to be loaded? Our use case is that the page has special functionality available to all users.

I believe adding this to mediawiki core would not only allow to have more interactive content (Yes, such content needs testing, deployment consensus, AND a careful design to have a fallback view when interactivity is broken), which is why I think the functionality should be such:

  • A page in a user namespace searches for the corresponding javascript in User:Name/Mediawiki:JavascriptName.js
  • A page in any other namespace searches for the corresponding javascript in Mediawiki:JavascriptName.js which is writeable only by admins.

rd232 wrote:

*** This bug has been marked as a duplicate of bug 6883 ***

Xaosflux reopened this task as Open.EditedMar 6 2020, 2:55 PM
Xaosflux added a subscriber: Xaosflux.

marking to correct duplicate T8883