Page MenuHomePhabricator

Scripts pages in MediaWiki: namespace parsed like wiki pages
Closed, ResolvedPublic


Author: lambdav

Since MediaWiki 1.18 script pages of the MediaWiki namespace (having .js and .css extensions) are parsed like any other pages (link, category, ...).

This is a problem because it creates weird category names like for the following example script:
which was added in the following category:

The problem is more critical when the script include some string like "{{subst:" because when the script is modified the template is substituted in the source code.

Script pages should not be parsed as other Wiki pages.

Version: 1.18.x
Severity: major



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:07 AM
bzimport set Reference to bz32450.

I can reproduce the issue in both REL1_18@r103457 and trunk@r103448

Any content such as [[Category:foo]] is parsed and the MediaWiki:bar.js page is added to that category.

Patch send for REL1_19 with r103476

Code review will let us know if we want to backport this.

Please note I have not tested how it worked in 1.17. This might or might not be a 1.18 regression.

lambdav wrote:

I think it's a regression because when I modified these scripts, I haven't seen the problem when MW 1.17 was in use on Wikimedia projects.

Thanks for r103476 about Category.
What about the {{subst: problem in scripts ?

There were stored in database before 1.17, but not shown at the bottom of the page, see bug 17525. This is maybe changed with 1.18.

(In reply to comment #4)

Thanks for r103476 about Category.
What about the {{subst: problem in scripts ?

Please be careful as many systems currently DEPEND on the fact:

  • that subst: is expanded on saving js/css
  • that tables pagelinks/imageslinks/globalfileusage are populated for [[links]] from js/css comments.

Is this about about the population of those tables or about action=view ? (or both).

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

lambdav wrote:

But this bug has been opened before 32858...

I merged several bugs to bug 32858 since it seemed to be the most clear.