r105161 MediaWiki - Code Review archive

Repository:MediaWiki
Revision:< r105160‎ | r105161 | r105162 >
Date:10:14, 5 December 2011
Author:hashar
Status:reverted (Comments)
Tags:
Comment:
Skip replaceInternalLinks2 for js/css pages

Just skip the whole replaceInternalLinks2 parser function whenever we hit
js/css pages. Previous patch r103476 only handled Category links which was
not enough.
Modified paths:
  • /trunk/phase3/includes/parser/Parser.php (modified) (history)

Diff [purge]

Index: trunk/phase3/includes/parser/Parser.php
——@@ -1643,6 +1643,12 @@
16441644 * @private
16451645 */
16461646 function replaceInternalLinks( $s ) {
 1647+ if( $this->getTitle()->isCssOrJsPage() ) {
 1648+ # bug 32450 : js and script pages in MediaWiki: namespace do not want
 1649+ # to get their code or comments altered. Think about js string:
 1650+ # var foobar = "[[Category:" + $catname + "]];
 1651+ return $s;
 1652+ }
16471653 $this->mLinkHolders->merge( $this->replaceInternalLinks2( $s ) );
16481654 return $s;
16491655 }
——@@ -1913,14 +1919,6 @@
19141920
19151921 if ( $ns == NS_CATEGORY ) {
19161922 wfProfileIn( __METHOD__."-category" );
1917 - if( $this->getTitle()->isCssOrJsPage() ) {
1918 - # bug 32450 : js and script pages in MediaWiki: namespace do not want
1919 - # to get their code or comments altered. Think about js string:
1920 - # var foobar = "[[Category:" + $catname + "]];
1921 - $s .= "[[$text]]$trail";
1922 - wfProfileOut( __METHOD__."-category" );
1923 - continue;
1924 - }
19251923 $s = rtrim( $s . "\n" ); # bug 87
19261924
19271925 if ( $wasblank ) {

Follow-up revisions

RevisionCommit summaryAuthorDate
r105664* Revert r103476, r105161 and implement the fix for bug 32858 (a.k.a. bug 324......tstarling10:32, 9 December 2011
r107449Revert the fix for bug 32858 (r105664, r105161, r103476): no consensus, backw...tstarling22:50, 27 December 2011

Past revisions this follows-up on

RevisionCommit summaryAuthorDate
r103476(bug 32450) MediaWiki: .js|.css pages parsed [[Category:#]] links...hashar16:46, 17 November 2011

Comments

#Comment by Hashar (talk | contribs)   10:15, 5 December 2011

Geshi syntax highlighting still working though ;-)

#Comment by Brion VIBBER (talk | contribs)   18:49, 6 December 2011

Is this intended to prevent the links from being registered as well as keeping them from showing in the UI?

In my testing it seems to be saving them; a [[Category:Pages about JS]] added to a comment in my User:Brionv/vector.js makes the page show up in the category, though it's not removed from text view or listed on the page itself.

#Comment by Hashar (talk | contribs)   21:36, 6 December 2011

This commit only fix bug 32450 " Scripts pages in MediaWiki: namespace parsed like wiki pages" which merely ask MediaWiki to stop altering JavaScript code on rendering. Ideally links should not be saved in the database. Neither previous r103476 nor this revision take care of that.

links tables being updated is bug 17525 "css and .js pages should not store entries in Categorylinks table/Templatelinks table" which I did not investigate.

I should have been clearer about that :-(

#Comment by Krinkle (talk | contribs)   21:44, 6 December 2011

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 regular [[links]] from inline js/css code comments on js/css pages.

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

#Comment by Brion VIBBER (talk | contribs)   21:48, 6 December 2011

Sounds kinda like it's just affecting the view, but .... I'm a bit unclear on what's where in there too.

#Comment by Tim Starling (talk | contribs)   10:01, 9 December 2011

As far as I can tell, it's not affecting page views. There was a report about the categories showing up at the bottom of the page, but that might have just been speculation. I couldn't reproduce it and the original bug reporters didn't mention it. It's hard to see how it could happen, since on page view, the page is not parsed and the parser cache is not tried. I'm pretty sure this is purely an issue with WikiPage::prepareTextForEdit() and WikiPage::doEditUpdates(), neither of which check for CSS/JS pages.

#Comment by Platonides (talk | contribs)   17:41, 8 December 2011

We should decide if we allow everything or nothing. See bugzilla:32858.

Status & tagging log